The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
draft-ietf-sip-sips-09

[Ballot discuss]
The Security Considerations section for this document really needs to be expanded.

At a minimum I would expect pointers to the security considerations in 3261, 4346,
and ietf-sip-outbound.  I would also like to see brief text reminding the reader that sips
is not a guarantee that tls was used on every hop, although it is obviously redundant.

Appendix A needs to be revised or dropped.  Once approved as an RFC, it is certainly
not a "placeholder".  I suggest retaining the text and revising the front matter of Appendix A,
but that is only a suggestion.

Appendix B lacks context, but this can be supplied with a few introductory sentences.
(My reading of Appendix B is that it describes the changes in 3261 as a consequence of
this update, but I am just guessing.)

[Ballot discuss]
The Security Considerations section for this document really needs to be expanded.

At a minimum I would expect pointers to the security considerations in 3261, 4346,
and ietf-sip-outbound.  I would also like to see brief text reminding the reader that sips
is not a guarantee that tls was used on every hop, although it is obviously redundant.

[Ballot comment]
** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)

Section 3.2., paragraph 1:
>    request was delivered securily on each hop, while in fact, in was
  Nit: s/securily/securely/

Section 5.1.1., paragraph 6:
>    To emphasise what is already defined in [RFC3261], UAs MUST NOT use
  Nit: s/emphasise/emphasize/ (also elsewhere)

Section 5.4., paragraph 4:
>    used inconsistenty (e.g,, the Request-URI is a SIPS URI, but the
  Nit: s/inconsistenty/inconsistently/

Section 6.3., paragraph 2:
>    Edge Proxy B. Note that Registar/Authoritative Proxy B preserved the
  Nit: s/Registar/Registrar/ (also elsewhere)

[Ballot comment]
Section 3.2., paragraph 1:
>    request was delivered securily on each hop, while in fact, in was
  Nit: s/securily/securely/

Section 5.1.1., paragraph 6:
>    To emphasise what is already defined in [RFC3261], UAs MUST NOT use
  Nit: s/emphasise/emphasize/ (also elsewhere)

Section 5.4., paragraph 4:
>    used inconsistenty (e.g,, the Request-URI is a SIPS URI, but the
  Nit: s/inconsistenty/inconsistently/

Section 6.3., paragraph 2:
>    Edge Proxy B. Note that Registar/Authoritative Proxy B preserved the
  Nit: s/Registar/Registrar/ (also elsewhere)

IANA Last Call comments:

Action #1:
Upon approval of this document, the IANA will make the following changes in the
"Warning Codes (warn-codes)" registry at
http://www.iana.org/assignments/sip-parameters

Change in registry description:

OLD:
Note:
Warning codes provide information supplemental to the status code in
SIP response messages when the failure of the transaction results
from a Session Description Protocol (SDP) (RFC 2327 [1]) problem.

NEW:
Warning codes provide information supplemental to the status code
in SIP response messages.


Action #2:

Upon approval of this document, the IANA will make the following assignments in
the "Warning Codes (warn-codes)" registry at
http://www.iana.org/assignments/sip-parameters

Code Description Reference
---- --------------------------------------------------- ---------
380 SIPS Not Allowed: The UAS or proxy cannot process the request
[RFC-ietf-sip-sips-08.txt]
because the SIPS scheme is not allowed (e.g., because there are
currently no registered SIPS Contacts).

381 SIPS Required: The UAS or proxy cannot process the request
[RFC-ietf-sip-sips-08.txt]
because the SIPS scheme is required.

We understand the above to be the only IANA Actions for this document.

Document Shepherd Write-Up for draft-ietf-sip-sips


This based on is template for the Document Shepherd Write-Up dated
February 1, 2007.



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

The Document Shepherd for this document is Dean Willis, current
co-chair of the SIP working group. He has reviewed this version of the
document and several previous versions in depth and believes this
version (outside of minor reference issues noted herein) is ready for
forwarding to the 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?

The document has been extensively reviewed within the working group
and received extensive additional refinement from our security area
adviser Eric Rescorla. It entered working group last call as version
-05 on July 9, 2007 and was subsequently reviewed through three
iterations.

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


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

This shepherd has no issues of this sort.

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

This draft enjoys a high level of working group consensus. We've
repeatedly revisited every issue until all known significant issues
(other than the fundamentals of underlying complexity) have been
resolved.


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

This shepherd is unaware of any evidence of extreme discontent with
this document.

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

This shepherd has verified that the document satisfies all I-D
nits. Note that the idnits tool falsely reports a non-compliant IP
address -- the text it cites is actually a chapter-and-paragraph
reference to another document. Also noted is that this document
references both the obsolete RFC 2543 and current RFC 3261. This dual
reference is intentional, as it is the intent of this document to
clarify an issue with RFC 2543 that RFC 3261 also tried to clarify.

Note also that this document references draft-ietf-sip-outbound-11,
which is currently -13. The material referenced has not been affected
by these revisions, and publication of this document by the RF editor
will be blocked pending publication of draft-ietf-sip-outbound anyhow.


    (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 properly divided. There is a normative reference to
draft-ietf-sip-outbound that will probably delay this 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?

The IANA Considerations section is present and appears to be reasonable.


    (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 appears to contain no sections specified in a formal
language.

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

Technical Summary:

This document updates RFC 3261 to provide clarifications and
guidelines concerning the use of the SIPS URI scheme in the Session
Initiation Protocol (SIP).  This document also provides a discussion
of possible future steps in specification.

The SIPS URI scheme was originally documented in RFC 3261, but
experience has shown that the specification therein is incomplete, and
that at least one use case that increased the complexity of the
specification (the "last hop exception") can be eliminated.

Several possible error conditions relating to mismatch of sips vs. sip
on sending and receiving ends exist. This documents adds new SIP error
codes to provide for the detection and correction of these error
conditions.


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

Working Group Summary:

There were several topics of significance that are worth noting.

The foremost is the deprecation of the "last hop exception" from RFC
3261. This exception allowed a proxy/registrar supporting SIPS to
relay requests received using SIPS on to user agent servers that did
not indicate support for SIPS. This increases the complexity of
implementations and weakens the end-to-end assurance of signaling
security provided by SIPS. After extensive debate, the working group
resolved to eliminate this exception and make SIPS fully
end-to-end. Doing so required extensive discussion and annotation on
what "end to end" means in the context of gateways to non-SIP
protocols.

Detection and correction of error conditions resulting where a UAC has
specified a SIPS request and the terminating UAS has not registered a
SIP contact, or where the UAC has specified a SIP request and the
terminating UAS has registered only a SIP contact was another problem
requiring extensive discussion. The "obvious" approach of using 400
class responses created problems when interacting with forking
proxies. The WG concluded on using two new 300-class SIP response
codes to enable request resolution in these scenarios.

During the process of developing this specification, the working group
began to converge on a new process for incrementally updating RFC
3261. As a precursor to this process, this specification contains an
appendix that provides explicit in-context changes to RFC 3261 as
required by this specification. The intent here is to reduce the
complexity of discussions at interoperability events.


          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?

There are several notable implementations of the specification at
varying levels of maturity. The SIPIt interop events have included
SIPS for some time, and the changes in this specification were in-part
driven by experiences at those interop events.

The document' Acknowledgements section cites numerous active
participants for providing detailed review.