[Sip] Publication request for draft-ietf-sip-hichhikers-guide-05

["DRAGE, Keith \(Keith\)" <[e-mail]>]

I have just requested publication of draft-ietf-sip-hichhikers-guide-05

The following is the proto writeup that goes with the publication
request.

PROTO writeup for
http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-
05: "A Hitchhiker's Guide to the Session Initiation Protocol (SIP)"

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

Keith Drage

The document has been reviewed and is ready for forwarding to IESG for
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?

Document history:

-	draft-rosenberg-sip-hitchhikers-guide-00 was submitted 27th
February 2006 and 
expired 31st August 2006.
-	draft-ietf-sip-hitchhikers-guide-00 was submitted 21st June 2006
and expired 21st 
December 2007.
-	draft-ietf-sip-hitchhikers-guide-01 was submitted 9th October
2006 and expired 
19th April 2007.
-	draft-ietf-sip-hitchhikers-guide-02 was submitted 8th March 2007
and expired 8th 
September 2007.
-	draft-ietf-sip-hitchhikers-guide-03 was submitted 5th July 2007
and expired 6th 
January 2008.
-	draft-ietf-sip-hitchhikers-guide-04 was submitted 15th November
2007 and expired 
18th May 2008.
-	draft-ietf-sip-hitchhikers-guide-05 was submitted 24th February
2008 and expires 
27th August 2008.

WGLC was initiated in the SIP WG on draft-ietf-sip-hitchhikers-guide-03
on 15th October 
2007 with comments requested by 29th October 2007.

Review was made and comments were received from: Francois Audet, Mary
Barnes, Andrew 
Booth, Spencer Dawkins, Martin Dolly, John Elwell, Avshalom Houri,
Cullen Jennings, 
Joerg Ott, Brian Stucker, Abigail West. During the course of the work
comments have also 
been made by: Diego Besprosvan, Spencer Dawkins, Keith Drage, John
Elwell, Cary 
Fitzgerald, Miguel Garcia, Vijay Gurbani, Michael Hammer, Alan
Hawrylyshen, Paul Kyzivat, 
Dave Oran, Dan Romascanu, Brian Rosen, Henning Schulzrinne, Henry
Sinnreich, Samir 
Srivastava, Hannes Tschofenig, M Vasudeva, Dean Willis.

It should be noted that once published as an RFC, this is a document
that will need to 
be regularly revised, as and when sufficient new SIP material is
published to justify a 
new version.

There has been a key discussion on the which documents should be
included. In particular 
example documents like draft-ietf-sipping-service-examples have been
specifically 
excluded. This received some discussion in the WGLC and RAI review
without consensus 
being obtained. As this document is probably subject to revision in the
future, if 
experience proves that the decision to exclude these documents was
wrong, then it can be 
reversed in the next published version. There is a fine line in some
cases as to whether 
to include a draft/RFC or not. In these cases we are looking to the
reader community to 
address the positioning of this line in future editions. Attention is
drawn to the 
following statement in the document:

   It is very difficult to enumerate the set of SIP specifications.
   This is because there are many protocols that are intimately related
   to SIP and used by nearly all SIP implementations, but are not
   formally SIP extensions.  As such, this document formally defines a

   o  RFC 3261 and any specification that defines an extension to it,
      where an extension is a mechanism that changes or updates in some
      way a behavior specified there.

   o  The basic SDP specification, RFC 4566 [RFC4566], and any
      specification that defines an extension to SDP whose primary
      purpose is to support SIP.

   o  Any specification that defines a MIME object whose primary purpose
      is to support SIP

   Excluded from this list are requirements, architectures, registry
   definitions, non-normative frameworks, and processes.  Best Current
   Practices are included when they normatively define mechanisms for
   accomplishing a task, or provide significant description of the usage
   of the normative specifications, such as call flows.

   The SIP change process [RFC3427] defines two types of extensions to
   SIP.  These are normal extensions and the so-called P-headers (where
   P stands for "preliminary", "private", or "proprietary", and the "P-"
   prefix is included in the header field name), which are meant to be
   used in areas of limited applicability.  P-headers cannot be defined
   in the standards track.  For the most part, P-headers are not
   included in the listing here, with the exception of those which have
   seen general usage despite their P-header status.

Attention is drawn to the fact that an Informational RFC, RFC 3325, is
listed as a core 
SIP specification. This received widespread discussion on the list at
the time it was 
included, and there was unanimous consensus that it should be so listed.

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

While the document indicates documents outside the SIP WG, the document
underwent the 
RAI review process in parallel with working group last call, and during
this was 
extensively reviewed by experts from those other groups. The document
shepherd considers 
that no further external review from an external specialist is
necessary.

   (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 document summarises a large number of SIP protocol related documents
and does not 
introduce new technical requirements. The document shepherd therefore
has no concerns 
with the document.

There have been no IPR disclosures on 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?

The needs for such a document has been well indicated on the SIP mailing
list. It may be 
concluded that there is strong support throughout the working group, and
throughout the 
RAI area, for such a document.

   (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize 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.)

None indicated.

   (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?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The document has been reviewed against the guidelines in RFC 4485 and it
is believed 
that the document is conformant with those guidelines.

For ID-NITS the checks against idnits 2.08.10 reports the following. It
should be noted 
that these are significantly outdated references to drafts. As the
intent is that the 
document is published with whatever the latest version is that applies,
it does not seem 
relevant to publish a new version to allow IESG and IETF review. The WG
did investigate 
leaving the version number off altogether, but this creates problems in
XML2RFC to do 
this easily. Drafts continue to be published in later versions.

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:
 
------------------------------------------------------------------------
----

     No issues found here.

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:
 
------------------------------------------------------------------------
----

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
 
------------------------------------------------------------------------
----

     No issues found here.

  Miscellaneous warnings:
 
------------------------------------------------------------------------
----

  == Line 1080 has weird spacing: '...ions in the S...'


  Checking references for intended status: Informational
 
------------------------------------------------------------------------
----

  -- Obsolete informational reference (is this intentional?): RFC 2543
     (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265)

  -- Obsolete informational reference (is this intentional?): RFC 2915
     (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404)

  == Outdated reference: A later version (-15) exists of
     draft-ietf-sip-outbound-11

  == Outdated reference: A later version (-07) exists of
     draft-ietf-sip-answermode-06

  == Outdated reference: A later version (-06) exists of
     draft-ietf-mmusic-ice-tcp-05

  == Outdated reference: A later version (-06) exists of
     draft-ietf-sip-certs-05

  == Outdated reference: A later version (-05) exists of
     draft-ietf-sipping-pending-additions-03

  == Outdated reference: A later version (-03) exists of
     draft-ietf-mmusic-sdp-media-capabilities-02

  == Outdated reference: A later version (-08) exists of
     draft-ietf-mmusic-file-transfer-mech-06

  == Outdated reference: A later version (-02) exists of
     draft-ietf-sip-record-route-fix-01

  == Outdated reference: A later version (-02) exists of
     draft-ietf-sip-subnot-etags-01

  == Outdated reference: A later version (-08) exists of
     draft-ietf-sip-sips-07

  == Outdated reference: draft-ietf-rohc-sigcomp-sip has been published
as
     RFC 5049

  == Outdated reference: A later version (-02) exists of
     draft-ietf-simple-simple-01

  == Outdated reference: A later version (-01) exists of
     draft-ietf-sip-dtls-srtp-framework-00

  == Outdated reference: A later version (-05) exists of
     draft-ietf-ecrit-framework-04

  -- Obsolete informational reference (is this intentional?): RFC 2833
     (Obsoleted by RFC 4733, RFC 4734)

  == Outdated reference: A later version (-04) exists of
     draft-ietf-sipping-update-pai-00

  == Outdated reference: A later version (-02) exists of
     draft-ietf-sip-ipv6-abnf-fix-00

  == Outdated reference: A later version (-01) exists of
     draft-ietf-sip-ua-privacy-00

  == Outdated reference: A later version (-02) exists of
     draft-ietf-sip-body-handling-01

  == Outdated reference: A later version (-03) exists of
     draft-ietf-sip-session-policy-framework-02

  == Outdated reference: A later version (-10) exists of
     draft-ietf-sip-connect-reuse-09

  == Outdated reference: A later version (-07) exists of
     draft-ietf-sipping-consent-format-05

  == Outdated reference: A later version (-10) exists of
     draft-ietf-sip-location-conveyance-09


     Summary: 0 errors (**), 23 warnings (==), 3 comments (--).


   (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 document is an informational RFC, contains no RFC 2119 language, and
all the 
references are therefore correctly informative.

   (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations 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 the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

There are, correctly, no IANA considerations from this document.

   (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 contains no material written in a formal language, and as
such there are no 
validation requirements.

   (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
             Relevant content can frequently be found in the abstract
             and/or introduction of the document.  If not, this may be
             an indication that there are deficiencies in the abstract
             or introduction.

          Working Group Summary
             Was there anything in the WG process that is worth noting?
             For example, was there controversy about particular points
             or were there decisions where the consensus was
             particularly rough?

          Document Quality
             Are there existing implementations of the protocol?  Have a
             significant number of vendors indicated their plan to
             implement the specification?  Are there any reviewers that
             merit special mention as having done a thorough review,
             e.g., one that resulted in important changes or a
             conclusion that the document had no substantive issues?  If
             there was a MIB Doctor, Media Type, or other Expert Review,
             what was its course (briefly)?  In the case of a Media Type
             Review, on what date was the request posted?

          Personnel
             Who is the Document Shepherd for this document?  Who is the
             Responsible Area Director?  If the document requires IANA
             experts(s), insert 'The IANA Expert(s) for the registries
             in this document are <TO BE ADDED BY THE AD>.'

Technical summary.

The Session Initiation Protocol (SIP) is the subject of numerous
specifications that 
have been produced by the IETF.  It can be difficult to locate the right
document, or 
even to determine the set of Request for Comments (RFC) about SIP.  This
specification 
serves as a guide to the SIP RFC series.  It lists the specifications
under the SIP 
umbrella, briefly summarizes each, and groups them into categories.

Working group summary.

There is strong consensus in the working group to publish this document.


Document Quality

This document is a summary or compendium of the IETF publications
relating to SIP, and 
as such, contains no requirements or RFC 2119 language, and as such
there is no 
requirement for implementation of this document. The document underwent
thorough review 
by a number of experts in both working group last call, and through the
RAI area review 
process.

It should be noted that once published as an RFC, this is a document
that will need to 
be regularly revised, as and when sufficient new SIP material is
published to justify a 
new version.

Personnel

The document shepherd for this document was Keith Drage. The responsible
Area Director 
was Cullen Jennings. The IANA Expert(s) for the registries in this
document are <TO BE 
ADDED BY THE AD>.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip