Hi, Dean, This is actually for outbound/please ignore the subject line, right?
Spencer p.s. :-) > > Whoops, I just pasted and sent the wrong version of the writeup. > Here's the correct one. Note that I originally sent this out in June, > but we'll be submitting the SRTP framework too, so you get another > chance here. > > -- > > > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? > > SIP chair Dean Willis is serving as the Document Shepherd for this > document. He has personally reviewed this document and believes it is > as ready for forwarding to the IESG for publication as it is ever > going to get. > > > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? > > The document has been intensively reviewed within the working > group. It was formally reviewed by John Elwell: > > http://www.ietf.org/mail-archive/web/sip/current/msg22870.html. > > which resulted in several small changes. > > > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? > > The shepherd has no such concerns. > > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, > or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this > document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. > > The shepherd has no specific concerns with this document. > > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > > Working group consensus is quite strong for this document. It was > considered "high profile" during the entire cycle, and has been very > thoroughly discussed. Numerous design changes were made in the process > in order to accomodate various points of view. > > > (1.f) Has anyone threatened an appeal or otherwise indicated > extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. > (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) > > The shepherd is unaware of any extreme discontent with this version of > the draft. A previous version that did not require two "outbound > proxy" entries was disparaged on-list, but the document was revised to > accomodate this issue. > > > > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the > document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? > > The document appears to satisfy the various checklist nits. > > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents > that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative > references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. > > References are appropriately divided. There is one reference to a > draft that has been revised, but this does not impact the document. > > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? > > This document specifies seven IANA actions that appear to be valid and > complete. It defines no new registry or expert review process. > > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? > > The document shepherd verified the ABNF using Bill Fenner's checker. > > > > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > > > > Technical Summary > > This document defines a n extension to the Session Initiation Protocol > (SIP) that provides for persistent and reusable connections between > SIP User Agents and SIP Proxy Servers. In particular, this allows > proxy servers to initiate TCP connections or to send asynchronous UDP > datagrams to User Agents in order to deliver requests. However, in a > large number of real deployments, many practical considerations, such > as the existence of firewalls and Network Address Translators (NATs) > or the use of TLS with server-provided certificates, prevent servers > from connecting to User Agents in this way. This specification > defines behaviors for User Agents, registrars and proxy servers that > allow requests to be delivered on existing connections established by > the User Agent. It also defines keep alive behaviors needed to keep > NAT bindings open and specifies the usage of multiple connections from > the User Agent to its Registrar. > > > > > Working Group Summary > > The working group process on this document was exceptionally long. The > first WG version of the draft appeared in the summer of 2005. Working > group last call initiated in the summer of 2006 and extended until the > summer of 2008, requring several iterations of the draft and the > assignment of Francois Audet as a "process champion" for the draft > within the working group. Most delays seem to have been related to > slow cycle time on the part of the authors, but the process was also > delayed by a number of changes occurring during the review cycle. > > Particular sticking points included the keepalive mechanism and a > requirement for binding to multiple outbound proxies if so > configured. The latter was eventually resolved by a widely-accepted > compromise, but the keepalive topic is still being debated. Although > there is a strong consensus for the keepalive technique specified in > this document, there is some reason to believe that there may be a > need for the keeplaive mechanism independently of the outbound > relationship. There is currently a draft proposing such a mechanism. > > This suggests that it might have been more effective to document the > outbound binding and keepalive mechanisms independently. > > > Document Quality > > There are numerous implementations of the protocol, and it has been > tested at SIPit events since 2005. > > _______________________________________________ > 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
