A Hitchhiker's Guide to the Session Initiation Protocol (SIP)
draft-ietf-sip-hitchhikers-guide-06

[Ballot comment]
Review by Christian Vogt:

Review of draft-ietf-sip-hitchhikers-guide-05

The SIP Hitchhikers Guide is a very useful synopsis of important
SIP-related specifications.  The RFC numbering scheme makes it difficult
to identify specifications of a common subject, so documents such as
this are of great help for navigating through large protocol suits such
as that of SIP.

This Hitchhiker's Guide certainly has publication quality, and it should
be published as soon as possible.  I do, however, have three suggestions
for increasing the usefulness of this document even further.  Perhaps
these could be taken into account before publication:

- The scoping of the Hitchhiker's Guide in section 2, which identifies
  the types of documents that are considered by the guide, is a bit
  complex because it consists of several rules and several exceptions.
  I would assume that the average reader couldn't tell, after all,
  whether documents for a particular purpose are in-scope or not.  Of
  course, I do acknowledge that, with the large set of SIP-related
  documents, it is not easy to come up with a crisp definition of
  which documents are "relevant" and which are not.  But perhaps a
  very simple approach would do the job:  I would suggest to simply
  state that those documents are included that are relevant to SIP or
  SDP in general, or to a large class of applications, and documents
  for a specific application are not.

- Why are neither requirements nor architecture documents in-scope of
  the Hitchhiker's Guide?  Requirements can be essential for defining
  the applicability of a method.  Architectures are important to
  understand how multiple methods fit together.  Shouldn't
  requirements and architecture documents therefore be in-scope of the
  Hitchhiker's Guide?  Of course, not all such documents can be listed
  due to their large number.  But perhaps the most relevant can.

- The first bullet in section 2 defines a SIP "extension" as a
  mechnanism that "changes or updates" SIP.  Since this definition
  differs from the common meaning of the word "extension", I suggest
  using the term "modification" instead.  This would also avoid
  confusion with later parts of the Hitchhiker's Guide, where the term
  "extension" is used in its common meaning.

[Ballot comment]
The Gen-ART Review from Suresh Krishnan said: "This document is well
  written and well categorized. I do have a nagging feeling that this
  document will be outdated by the time it will be published."  So, the
  inclusion of some introduction text that warns readers that this is a
  It is possible to include some text that says something like snapshot
  of the relevant specifications and that updated versions of this
  document will be published periodically.

[Ballot comment]
I believe that this is a very useful document. The following comments would IMO give more clarity:

1. The document refers to a number of work-in-progress specifications, and for this reason I think that defining it in the Introduction as 'a guide to the SIP RFC series' is slightly mis-leading without noting that the document reflects a snapshot of the SIP standardization at the time of the publication and that some of the specifications refered here are work-in-progress and thus subject to change if and until they become RFCs.

2. I think that it would be useful to provide more clarity to the last paragraph in the introduction that makes clear what the document is not.

>  This document itself is not an update to RFC 3261 or an extension to
  SIP.  It is an informational document, meant to guide newcomers,
  implementors and deployers to the many of the specifications
  associated with SIP.

I would suggest to add something on the lines of 'This document does not define any minimal or maximal or other kind of profile for compliance for SIP or SIP-based applications'.

3. I think that the references sections would benefit from some kind of sorting. For a document that tries to make some order in the SIP jungle it is odd thaty there are like eight pages of references without any sorting (or any sorting I could make sense of). Sorting RFCs according to numbers and I-Ds alphabetically would ease the task of the reader who tries to find a reference without necessarily using t3ext search.

4. Section 11 should also include the SIP MIB (RFC 4780)

[Ballot comment]
Regarding RFC 3890, we know it is broken from a offer/answer perspective. Becuase TIAS values only makes fully sense in a sending direction and the reference to the handling of the other b= parameters makes it becomes a what I can receive. The text should maybe mention this.

[Ballot comment]
I believe that this is a very useful document. The following comments would IMO give more clarity:

1. The document refers to a number of work-in-progress specifications, and for this reason I think that defining it in the Introduction as 'a guide to the SIP RFC series' is slightly mis-leading without noting that the document reflects a snapshot of the SIP standardization at the time of the publication and that some of the specifications refered here are work-in-progress and thus subject to change if and until they become RFCs.

2. I think that it would be useful to provide more clarity to the last paragraph in the introduction that makes clear what the document is not.

>  This document itself is not an update to RFC 3261 or an extension to
  SIP.  It is an informational document, meant to guide newcomers,
  implementors and deployers to the many of the specifications
  associated with SIP.

I would suggest to add something on the lines of 'This document does not define any minimal or maximal or other kind of profile for compliance for SIP or SIP-based applications'.

3. I think that the references sections would benefit from some kind of sorting. For a document that tries to make some order in the SIP jungle it is odd thaty there are like eight pages of references without any sorting (or any sorting I could make sense of). Sorting RFCs according to numbers and I-Ds alphabetically would ease the task of the reader who tries to find a reference without necessarily using t3ext search.

[Ballot comment]
Excellent work!

One comment about Section 15 (security mechanisms): should it
mention Digest AKA (RFC 3310/4169)? Although technically it's an
HTTP authentication mechanism, all the examples in RFC 3310 use SIP
(and it has some details that don't actually work so well with HTTP).

For someone trying to understand the SIP security better, other
important pieces of information would be e.g. the "ipsec-3gpp"
mechanism (defined in 33.203 but mentioned in RFC 3329), MIKEY,
Kerberos/NTLM authentication for SIP (publicly documented, but
not in IETF document AFAIK), and RFC 5090 (with many SIP-specific
parts) -- but  I guess the scope has to be limited somehow (covering
all SIP-related 3GPP specs would certainly reach the critical mass
for a black hole :-)

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

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 .