Subject: [rohc] Comments to draft-ietf-rohc-sigcomp-06.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 23 May 2002 22:21:05 +0300

Hi:

I have some comments to draft-ietf-rohc-sigcomp-06.txt

1) A general comment: the whole draft is quite descriptive, lacking
   IMHO quite a normative text. May I suggest to review the whole
   draft trying to strength the wording in general?

   A few examples (not a comprehensive list):

   Section 3.3.1, second paragraph: "This parameter
   is set to 0 if the endpoint is stateless." should be 
   replaced by "This parameter *MUST* be set to 0 if the 
   endpoint is stateless."

   Section 5.1, forth paragraph: " The compressor must also 
   ensure that the state item it wishes to access has not been 
   rejected due to a lack of state memory." should become 
   "The compressor *MUST* also ensure that the state item it 
   wishes to access has not been rejected due to a lack of 
   state memory."

   Section 6.1, first paragraph:  "To provide security against 
   the malicious insertion or modification of SigComp messages, 
   a separate instance of the UDVM is invoked to decompress each 
   message." should become "To provide security against the 
   malicious insertion or modification of SigComp messages, a 
   separate instance of the UDVM *MUST be* invoked to
   decompress each message."

   Section 5.2, second paragraph: "If a compression failure 
   occurs then the compressor informs the dispatcher and takes
   no further action." should be "If a compression failure 
   occurs then the compressor *MUST inform* the dispatcher and 
   *SHOULD take* no further action."

2) I noticed a few places where there are references to the 
   dictionary of SIP phrases. Now that the SIP dictionary for
   Sigcomp is released and work is ongoing, should you add an
   informative reference to this draft, so that the reader 
   gets familiar?

3) Section 3.3.1: It is stated that "all endpoints implemented
   SigComp MUST offer a decompression_memory_size of at least
   2048 bytes". I am fine with the requirement. However, we
   have observed that the just the SIP/SDP dictionary is 
   using almost 4 kb. That will make the state_memory_size
   a minimum of 4 kb when SigComp is used together with SIP.
   And I understand that decompression_memory_size will have
   to be always greater than the state_memory_size.

   So, isn't it worthy explaining that, although this 
   document just place a requirement of a minimum 2 kb  
   for the decompression_memory_size, certain applications
   of SigComp (such as SIP) will reinforce this requirement
   to a higher figure??? 

   I was thinking that if SIP requires the dictionary,
   the dictionary is 4 kb, then the minimum state_memory_size
   is 4 kb, and the decompression_memory_size will have to
   be something about 8 kb???

4) Consider to replace the reference to [RFC-2543] by a
   reference to the approved, but not available yet 
   replacing [RFC-3261] (aka draft-ietf-sip-rfc2543bis-09.txt)

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 24 May 2002 00:16:32 +0200

Hi Miguel,

here are some comments on your comments.

>    draft trying to strength the wording in general?

sigcomp is a strange animal with respect to RFC2119.

What it really standardizes is the behavior of the decompressor.
So in some cases, it's not quite clear that we want to mandate some specific 
behavior of the compressor -- the spec contains enough information so the 
compressor implementers know when they'll get into trouble, but there may 
actually good reasons for such behavior.

>    replaced by "This parameter *MUST* be set to 0 if the 

Fair comment (but see also RFC2119 extract below).

>    wishes to access has not been rejected due to a lack of 

Actually, we had a discussion about this before, and the result was that a MUST 
would be too much.  There may be optimistic compressor algorithms that actually 
can deal well with the occasional loss of a message -- we don't want to rule 
them out.

Let me underscore this with an extract from RFC2119:

6. Guidance in the use of these Imperatives

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

>    decompress each message."

But this is really descriptive text.  The actual details are given in section 7.
You can't really implement these details without fulfilling this description.

>    *SHOULD take* no further action."

We are not really making too many requirements on the compressor here, but we 
actually say "The dispatcher MUST report
this failure to the application so that it can try other methods to
deliver the message.".  The first sentence (which you cite) just explains the 
model we have about the interaction between model system components, so it's 
descriptive.

Anyway, I'm not saying that we always did the RFC 2119 thing right here, I'm 
just saying we already put some effort into getting it right and we did want to 
avoid overusing the uppercase keywords.

>    informative reference to this draft, so that the reader 

Good point.
This would become a "work in progress" reference, which is always a bit awkward, 
but probably worth it.

>    to be always greater than the state_memory_size.

This indeed raises some interesting questions.

state_memory_size is about the memory available to *this compartment* -- it 
never includes locally available state, for which the dictionary is an example.

Also, you don't actually need to use the whole dictionary in a compressor -- you 
can download UDVM code that uses STATE-ACCESS to access only part of it.
I know this is a rather lame observation, but I think it is important (at least 
for the construction of later dictionaries for possibly much larger languages).

>    of SigComp (such as SIP) will reinforce this requirement

Again, you don't have to use the full dictionary (or *use* it at all).  The 
requirement will be for the dictionary to be there in all decompressors, not 
necessarily for it to fit in completeness, although I'd be the first to accept 
that it is debatable how useful a 2K UDVM would be for SIP in practice.

>    be something about 8 kb???

I think we should discuss this specifically for SIP, and maybe decide that we 
mandate not only the locally available state but also a larger 
decompression_memory_size for SIP/SDP.

For general sigcomp (for which SIP is just one very important application), 2 K 
min may continue to be the right decision.

>    replacing [RFC-3261] (aka draft-ietf-sip-rfc2543bis-09.txt)

I believe the RFC editor will do that automatically -- just in case this does 
not happen, I'm taking note of this.

Gruesse, Carsten

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 24 May 2002 10:54:54 +0300

Carsten:

I am fine with all your answers.

/Miguel