[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Resend: Draft Shepherd writeup fordraft-ietf-sip-media-security-requirements-07
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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip