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

From: Robert Sparks <[email-masked]>
Date: Wed, 30 May 2007 22:14:47 -0700

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."

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.

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.

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