Re: "semantically identical" requirements text

["Paul Francis" <yoid2000@home.com>]

Sorry to be so long in replying...its been a hectic few weeks.

>
> Just to add some terminology:
> When we identified the need for such protocols in the ISSLOW work, we
called
> them "announcement protocols" (see RFC2689 section 6.)
> The heuristic compression defined in RFC2508 allowed us to get away
without
> defining such protocols at first; later RFC3006 was added -- not to
control
> the compressor, but to tell admission control about the probable
performance
> of the compressor.
> ROHC follows in the same steps (and can use RFC3006 as is, once we
register
> the "hint" numbers with IANA, which would best be done in conjunction with
> ROHC-over-PPP).

Thanks Carsten, this is useful.

>
> We never really discussed in detail whether the receiver needs to have a
say
> in this.
> After all, it's the sender's packets, and the sender can do with them (or
> grant license to do with them) whatever pleases it.

Never-the-less, if a sender is treating fields as pliant, and the reciever
is treating them as brittle, then we do have a problem is the compression is
pliant (non-transparent).  The thing is, I can't think of a case off hand
where that would happen...

>
> Of course, in a GEHCO (first-hop/last-hop) scenario, it is more natural to
> have the sender control the compressor/decompressor pair on the first-hop
> link and have the receiver control the compressor/decompressor pair on the
> last-hop link.  This makes it possible to run the announcement protocol on
> the link layers of the first/last hop only; no L3 signalling protocol like
> RSVP is needed.
>

Agreed completely.  I think this would cover 99.9% of the cases too.

PF