Re: WGLC for draft-ietf-sip-199-02

Comments (in major, minor, nit order)

Major:
maj-1) Do we have a constituency willing to finish this work? It has a  
ways to go and the number of commenters has been pretty small. Does  
anyone know of any attempts to implement this yet?

maj-2) -02 is an improvement over -00, but the basic architectural  
intent is still not clear (as evidenced by the remaining open issue in  
section 5 - in fact I think this is the _REAL_ open issue that the  
thing in section 5 is pointing to). An implementer would probably  
benefit from a short overview section that outlined the mechanics.

maj-3) The document defines an option tag but doesn't say what it  
means if it shows up in a Require: header.

maj-4) The Security Considerations section is empty. I've pointed  
already (in my comments to -00) of at least one situation we need to  
discuss here (It said "For instance, I can spoof 199s to affect how a  
call is ultimately answered in ways that are different (from the  
endpoints visibility into what happened point-of-view) from cancels/ 
byes or even other response manipulation.) We need some focused  
discussion to uncover any other issues this new behavior is bringing  
to the system.

maj-5) (I waffled on putting this into minor, but I've made this  
comment before and it hasn't been sufficiently addressed). The  
document needs to be more explicit in explaining how it might be that  
a single 3-6xx response showing up at a proxy might cause it to send  
more than one 199. Something like http://www.nostrum.com/~rjsparks/example.png 
  perhaps.

maj-6) The document should discuss what a proxy should do if a 199  
shows up for an early dialog it's already generated its own 199 about.
(This might happen, for instance, if a 3-6xx and a 199 crossed on the  
wire or were reordered by previous elements on the way to this proxy).

maj-7) Section 7 on backwards compatibility is really confusing and  
doesn't stand up against some edge situations. In particular, it  
doesn't act right when a request comes in that's a retransmission or a  
merge. It could also be misinterpreted (a stretch, but I've seen this  
stretch) to constrain UASes to send a 481 to an ACK. I suggest we get  
together in the hall at IETF73 and collaboratively wordsmith a  
replacement for this section.

maj-8) What is the purpose of section 8? I suspect it should just be  
deleted.

maj-9) Section 9 allows a 199 to contain SDP. Why? This document  
should either forbid that practice or explicitly document why it is  
allowed.


Minor:
min-1) (I waffled on putting this into major): This entire mechanism  
is an optimization, but the word optimization is never used. This is  
(as discussed so far) ONLY an optimization and should be explicitly  
described as such (including documenting the limitations of the  
optimization).

min-2) The document uses "upstream" and "downstream" throughout its  
text. We can probably find a way to replace those terms with something  
less likely to induce confusion especially when translating to other  
languages.

min-3) The abstract shows the architectural confusion I call out in  
maj-2. Its not clear what elements use the 199 in this description.  
The most likely interpretation of the given text is just the UAC.

min-4) The last sentence of the 5th paragraph of the Introduction  
(which starts "When SIP entities upstream receive") says SIP entities  
but talk about things that only UACs can do, specifically terminating  
the session startup.

min-5) Paragraph 1 of section 4 (Client Behavior) can be read to say a  
UAC MUST always insert a Supported:199. It should start with a  
conditional clause such as "If the client wants to receive 199  
responses, then".

min-6) Item 5 in section 4.1 talks about dialogs being "inactive"  
which doesn't have meaning - I think it meant to say "the sessions  
associated with some early dialogs may be set to inactive".

min-7) Section 5 should be titled "User-Agent Server" behavior to  
avoid confusion with Proxies.

min-8) (This will be major later in the review process if it's still  
there when we get there). Section 6 uses 2119 capitalized words to  
restate requirements from other, already published and referenced,  
documents. This is a practice we should work hard to avoid. I suggest  
replacing the first two sentences with "A proxy will forward a  
received 199 response as it is required to forward all other non-100  
provisional responses by RFC 3261." Similarly, the last paragraph of  
section 7 should not use 2119 capitalized words.

min-9) The part of section 6 that talks about the proxy generating  
199s on its own would be clearer if it were structured around the  
generation of multiple 199s for a given 3-6xx with the case of only  
one 199 being generated falling out as a special case. (currently it  
documents the 1 final response makes 1 provisional response and calls  
out the multiple-199 case as an exception/extension later in the  
section).

Nit:
nit-1) "resrouces" occurs several times in section 4.1

nit-2) The document still contains [ref needed] when talking about ICE  
in section 4.1

nit-3) The Note in section 4.1 has a reference to RFC3261 ostensibly  
about SRTP. Did it mean to point to an SRTP document instead?

nit-4) "intial" appears in section 5

nit-5) Suggest replacing "triggers a 199 response" in section 10 with  
"generates a 199 response"

On Nov 11, 2008, at 11:08 AM, Robert Sparks wrote:

> I've had several people comment that their reading list is driven  
> exclusively by what appears on agendas at meetings.
>
> This draft does not appear on any such agenda.
>
> Its probably worth poking people repeatedly to stimulate comments if  
> you want any.
>
> That said, I am assuming that this WGLC is intended to stimulate  
> discussion on the draft instead of meaning "we think this is ready  
> to publish - everybody take a last look at it" kind of LC, since it  
> still contains things like:
>
>> 12.  Security Considerations
>>
>>   TBD
>
> I'll send my comments in a separate message.
>
> RjS
>
>
> On Nov 4, 2008, at 3:20 PM, DRAGE, Keith (Keith) wrote:
>
>> (As WG chair)
>>
>> This mail is to initiate a WGLC on
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-199-02.txt
>>
>> Response Code for Indication of Terminated Dialog
>>
>> Intended Status: Proposed standard
>>
>> This is a two week working group last call so please send your  
>> comments
>> to the list and direct to the editor by the 18th November 2008. As  
>> this
>> date is just after the start of IETF#73, please put this high up your
>> reading list.
>>
>> Normal rules apply - for each please indicate the type of comment you
>> are making to give us some idea of the sort of severity, and if  
>> possible
>> please indicate what sort of fix would be required, or even better,
>> supply revised text.
>>
>> regards
>>
>> Keith
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [email protected] for questions on current sip
>> Use [email protected] for new developments on the application of sip
>
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip