Outbound is already pub requested and write up is done so I think Dean just had a cut and paste slip up here.
On Sep 19, 2008, at 8:17 AM, Spencer Dawkins wrote: > 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
