Re: [Sip] Resend: Draft Shepherd writeup fordraft-ietf-sip-media-security-requirements-07

[Cullen Jennings <fluffy at cisco.com>]

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 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