RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite
RFC 4019

Discussed Ted's comment with the editor, and Ted supported the following (from Ghyslain):

I suggest to simply remove "for a certain amount of time" from that
sentence.

The sentence actually means that the decompressor has no reason to
expect a different response for further requests, however this is
still possible. Different modes may be more useful under different
link conditions, and these may change slowly over time for the same
connection. It is left to compressor and decompressor implementations
to adjust the mode of operation based on these link conditions, if
desired.

Note that even if a "silly" decompressor implementation sends further
mode requests for the declined mode after very short period(s), this
would not break the protocol - this would just be a very innefficient
way of implementing a decompressor.

So removing that part of the sentence actually seem to make the
recommendation more clear in that respect, in my opinion.

[Ballot comment]
Reviewed by Brian Carpenter, Gen-ART

He observed the same problem as others; in his words:

It was kind of hard to review since its primary reference (to UDP-Lite)
is wrongly referenced in the text - it's not [1] but [4], and I don't know
where to look for RFCUUUU which is the citation behind [4].

OK, a little research tells me they are referring to RFC 3828.

[Ballot comment]
In Section 5.6, the draft says:

  Upon receiving the Mode parameter set to '0', the decompressor MUST
  stay in its current mode of operation and SHOULD refrain from sending
  further mode transition requests for the declined mode for a certain
  amount of time.

How is "certain amount of time" determined?  If the advice is in some
other document, a pointer would be valuable.  If it is implementation
dependent, then some minimum seems required (as otherwise the SHOULD
refrain is meaningless--an implementation could refrain a clock cycle
and be compliant).

[Ballot comment]
RFC 3828 should appear as a normative reference.  The reference given in
paragraph 3 of Section 1 is to 2119 instead, which is wrong.  (this
should probably be in an RFC Editor's note.)

[Ballot comment]
Do we really want to remove the text from the IANA Considerations section as described in the document?  Sometimes that kind of explanation is helpful to have around in the future.

IANA Last Call Comments:
Upon approval of this document the IANA will assign
2 ROHC profile identifiers.  The IANA Considerations section
was very clear with the instructions for these assignments.