Subject: [Gen-art] Re: genart review: draft-ietf-rohc-sigcomp-sip-06.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 17 Jun 2007 14:15:53 +0300

Hi Robert,

thanks for your comments. Answers inline:

Robert Sparks wrote:
> I have been selected as the General Area Review Team (Gen-ART) reviewer
> for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> 
> Document: draft-ietf-rohc-sigcomp-sip-06.txt
> Reviewer: Robert Sparks
> Review Date: 5/30/07
> IETF LC End Date: 5/29/07
> IESG Telechat date: (if known) 6/7/07
> 
> Summary: This draft is ready for publication as a Proposed Standard RFC.
>                     There are some small nits the submitters and IESG 
> may wish to
>                     consider addressing before publication.
> 
> Comments:
> 
> 1) Section 8 mislead me (an experienced person in these technologies) 
> into misinterpreting
>     what it was saying. My misinterpretation was that it was preventing 
> SIP retransmissions. Its
>     intent was to note that any retransmission had to be recompressed, 
> that it was not valid to
>     cache a previous compression and retransmit that. The following text 
> was suggested as
>     a replacement:
> 
>    "When SIP messages are retransmitted, they need to be re-compressed,
>    taking into account any SigComp states that may have been created or
>    invalidated since the previous transmission. Implementations MUST
>    NOT cache the result of compressing the message and retransmit such
>    a cached result."

OK, I will perform the following change:

OLD:
    SIP retransmissions need to be compressed again before being sent.
    That is, SIP applications MUST NOT retransmit already-compressed
    information.

NEW:
   When SIP messages are retransmitted, they need to be re-compressed,
   taking into account any SigComp states that may have been created or
   invalidated since the previous transmission. Implementations MUST
   NOT cache the result of compressing the message and retransmit such
   a cached result.

> 2) 9.4 discusses drawbacks of stateless compression and states that
>     if a compartment is not available, that the application MAY choose
>     not to compress a given message (putting some non-normative pressure
>     on applications to choose not to do so).  Section 5, however notes that
>     you cannot mix SIP messages and SigComp messages on any given
>     TCP stream and calls out a null decompression algorithm to use to
>     effectively send a "compressed" message that isn't compressed. I think
>     section 9.4 should explicitly call back to this this case to help avoid
>     implementor confusion.

Would the following change address your comment?

OLD:

    The use of stateless compression (i.e., compression without a
    compartment) is not typically worthwhile and may even result in
    message expansion.  Therefore, if a SIP application does not have a
    compartment for a message it needs to send, it MAY choose not to
    compress it even in the presence of the comp=sigcomp parameter.

OLD:

    The use of stateless compression (i.e., compression without a
    compartment) is not typically worthwhile and may even result in
    message expansion.  Therefore, if a SIP application does not have a
    compartment for a message it needs to send, it MAY choose not to
    compress it even in the presence of the comp=sigcomp parameter.
    Section 5 describes how a SIP application can send compressed and
    uncompressed messages over the same TCP connection.

> 3) I have personal heartburn with the decision in the document to scope
>     the use of SigComp in SIP to only those cases where registration state
>     is being maintained. There is no way for endpoints that, for 
> instance, only
>     publish or subscribe to use SigComp the way this document is written.
>     That said, there is real complexity in providing a mechanism that works
>     outside a context like registration, and there is, per the 
> submitters, working
>     group consensus around this restriction. I suggest adding a paragraph
>     explicitly calling out this restriction and briefly discussing why 
> the group
>     decided to accept it.
> 

We can perform the following change in Section 9.3:

OLD:
       Previous revisions of this document also defined compartments
       valid during a SIP transaction or a SIP dialog.  It was decided to
       eliminate those types of compartments because the complexity they
       introduced was higher than the benefits they brought in most
       deployment scenarios.

NEW:

Note that linking the lifetime of SIP/SigComp compartments to 
registration state limits the applicability of this specification. In 
particular, SIP user agents that do not register but, for example, only 
handle PUBLISH or SUBSCRIBE/NOTIFY transactions are not able create 
SIP/SigComp compartments following this specification. Previous 
revisions of this specification also defined compartments valid during a 
SIP transaction or a SIP dialog. Those compartments covered all possible 
SIP entities, including those that do not handle REGISTER transactions. 
However, it was decided to eliminate those types of compartments because 
the complexity they introduced (e.g., edge proxy servers were required 
to keep dialog state) was higher than the benefits they brought in most 
deployment scenarios.

Additionally, per Adam's request, I intend to add the following 
clarification to the last paragraph of Section 9.3:

OLD:
    If, following the rules above, a SIP application is supposed to open
    a compartment for a remote application identifier for which it
    already has a compartment, the SIP application MUST use the already
    existing compartment.  That is, the SIP application MUST NOT open a
    new compartment.

NEW:
    If, following the rules above, a SIP application is supposed to open
    a compartment for a remote application identifier for which it
    already has a compartment (e.g., the SIP application registers
    towards a second registrar using the same edge proxy server as for
    its registration towards its first registrar), the SIP application
    MUST use the already existing compartment.  That is, the SIP
    application MUST NOT open a new compartment.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Robert Sparks <[email-masked]>
Date: Mon, 18 Jun 2007 08:56:15 -0500

These address my comments. Thanks!

RjS

On Jun 17, 2007, at 6:15 AM, Gonzalo Camarillo wrote:

>>                     There are some small nits the submitters and  
>> IESG may wish to
>> 1) Section 8 mislead me (an experienced person in these  
>> technologies) into misinterpreting
>>     what it was saying. My misinterpretation was that it was  
>> preventing SIP retransmissions. Its
>>     intent was to note that any retransmission had to be  
>> recompressed, that it was not valid to
>>     cache a previous compression and retransmit that. The  
>> following text was suggested as
>>     a replacement:
>>     explicitly calling out this restriction and briefly discussing  
>> why the group
>>     decided to accept it.
>
> registration state limits the applicability of this specification.  
> In particular, SIP user agents that do not register but, for  
> example, only handle PUBLISH or SUBSCRIBE/NOTIFY transactions are  
> not able create SIP/SigComp compartments following this  
> specification. Previous revisions of this specification also  
> defined compartments valid during a SIP transaction or a SIP  
> dialog. Those compartments covered all possible SIP entities,  
> including those that do not handle REGISTER transactions. However,  
> it was decided to eliminate those types of compartments because the  
> complexity they introduced (e.g., edge proxy servers were required  
> to keep dialog state) was higher than the benefits they brought in  
> most deployment scenarios.
>
>