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

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.

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.

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

  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.