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
