[sip-http-events] IEST submission: draft-roach-sip-http-subscribe-06

["Scott Lawrence" <[e-mail]>]

As its Document Shepherd, I have requested that the IESG consider

    draft-roach-sip-http-subscribe-06.txt

for publication; the following is the proto writeup that I sent:

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

Document Shepherd: Scott Lawrence <[e-mail]>

I have personally reviewed a few versions of this document, including
the latest (06) draft.

I believe this version is ready for IESG review and publication.

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

This document is not the product of a Working Group - it began as an
individual submission from the author and got considerable attention
from experts in the HTTP and SIP communities.  Based on discussion on
the DISPATCH working group list during the summer of 2009, a consensus
was reached that it was close enough to complete that a WG was not
needed.

A mailing list for interested parties to help finalize the document
was established in early August 09, which produced a few additional
versions of the draft.

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

I believe that the draft has had sufficient review from both the SIP
and HTTP protocol perspectives, and that it adequately provides advice
to implementors regarding operational and security issues.

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

I have no outstanding 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?

There seems to be broad consensus that the document is useful.  I have
seen no objections to the concept or to the particulars of this
embodiment of that concept during the discussions (some questions, but
no opposition).  The discussions over the last few months have mostly
clarified and extended the suggested functionality to expand its
applicability.

(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.)

No.

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See the Internet-Drafts Checklist
      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?

Yes.

(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].

The references are split into separate normative and informative
sections appropriately.

There is one normative reference to an Internet Draft, which is also
intended to be standards track :

   [9]   Nottingham, M., "Web Linking",
         draft-nottingham-http-link-header-06 (work in progress),
         July 2009.

   at this writing, that draft is in the state:

     Waiting for AD Go-Ahead::Revised ID Needed

(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 [RFC5226]. 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?

The document does contain an appropriate IANA considerations section,
which adds entries to registries that either already exist or are
established by the normative dependency described above.

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

There is one ABNF definition in the document.  It validates correctly.