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

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 03 Jul 2007 14:37:48 +0300

Hi Robert,

perfect. I have put together a new revision of the draft, which I will 
be submitting later today.

http://users.piuha.net/gonzalo/temp/draft-ietf-rohc-sigcomp-sip-07.txt

Cheers,

Gonzalo

Robert Sparks wrote:
> These address my comments. Thanks!
> 
> RjS
> 
> On Jun 17, 2007, at 6:15 AM, Gonzalo Camarillo wrote:
> 
>> 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
> 

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