Subject: [cuss] Shepherd writeup for draft-ietf-cuss-sip-uui

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Sep 2012 14:53:28 -0500

All: I am the document shepherd for draft-ietf-cuss-sip-uui.

I have completed the shepherd writeup, and it is included below.

--- Begin shepherd writeup

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

draft-ietf-cuss-sip-uui is a Standards Track document (Proposed Standard).
The title page of the draft reflects this RFC type.  I believe that this
is the proper type to categorize this draft because the drafts defines
a new SIP header field, an associated SIP option tag, and establishes
three new sub-registries under SIP parameter registry.  Furthermore, it
also provides guidelines for SIP user agents and intermediaries on how
to handle the new parameter.

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

This document defines a new SIP header field, User-to-User Information 
(UUI),
to transport data between two SIP user agents opaquely.  Also defined is
an extension mechanism for new UUI packages.

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?

There was nothing contentious during the WG process worth noting.
Certain aspects like getting the right semantics for the hex encoding of
the UUI data, whether or not conversion between encodings will be allowed
at gateways, etc., engendered email discussions but consensus was
reached by all concerned parties equitably.

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 reported implementations of earlier version of the draft
from Avaya, Dialogic and Audiocodes.

This is work that other SDOs (3GPP) are waiting for.

Laura Liess and Shida Schubert deserve mention for WGLC related to
this draft.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Vijay K. Gurbani
Responsible AD: Gonzalo Camarillo

(3) Briefly describe the review of this document that was performed
by the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I reviewed the document for completeness, and besides one nit in
Section 1 and an unreferenced reference ([ETSI]), I could not find
anything structurally wrong with the document to warrant a
delay in publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No, The document was reviewed by Laura Liess, who has a long history
of participating in the WG.  The document was also reviewed by Shida
Schubert to ensure compliance to rfc4244bis (History-Info).  With
reviews by Laura and Shida, I believe that the document has been
exposed to both a focused as well as a broad review.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document was reviewed by Shida Schubert to ensure compliance to
rfc4244bis (History-Info).  Additionally, the CUSS mailing list has
subscribers from other related working groups (SIPCORE) and these
subscribers have been contributing a sizeable effort of their time
providing comments on the list.  The document has been a beneficiary
of such comments.

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

I do not have any specific concerns or issues regarding this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79
have already been filed. If not, explain why?

Yes, I sent an email to the authors regarding IPR disclosures on
Sept-17-2012.  I received an email response on the same day from all
authors indicating that they are not aware of any IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR 
disclosures.

As far as I am aware of, there has not been any IPR disclosure filed that
references this document.

(9) 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 WG consensus behind the document is strong.  The WG mailing list has
subscribers from related working groups (SIPCORE) participating in it,
and these subscribers have contributed thoughts and ideas to the draft.
The WG as a whole understands and agrees with the document.

(10) 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 publicly available.)

No one has threatned an appeal or otherwise indicated extreme
discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to
be thorough.

- There are 11 instances of too long lines in the document, the longest
    one being 1 character in excess of 72.
- Unused Reference: 'ETSI' is defined on line 721, but no explicit
   reference was found in the text
- Unused Reference: 'RFC3324' is defined on line 762, but no explicit
   reference was found in the text
- Downref: Normative reference to an Informational RFC: RFC 3324
- Downref: Normative reference to an Informational RFC: RFC 3325
- Downref: Normative reference to an Informational RFC: RFC 6567
- Outdated reference: A later version (-09) exists of
   draft-ietf-sipcore-rfc4244bis-08

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

The document has an IANA considerations section that is appropriately
filled out.  It does not require reviews related to MIBs.

(13) Have all references within this document been identified as either
normative or informative?

Yes, however, there is a reference ([ETSI]) that appears in the list of
Informative References but is not referenced in the text itself.

(14) 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 plan for their completion?

There is one normative reference that refers to an I-D
([I-D.ietf-sipcore-rfc4244bis]).  Besides this, all normative references
refer to RFCs.

(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the
Last Call procedure.

There is one normative reference referring to an Internet-Draft:
[I-D.ietf-sipcore-rfc4244bis]
               Barnes, M., Audet, F., Schubert, S., Elburg, H., and C.
               Holmberg, "An Extension to the Session Initiation Protocol
               (SIP) for Request History Information",
               draft-ietf-sipcore-rfc4244bis-08 (work in progress),
               April 2012.
There are three other downward references that point to RFCs:

  - Downref: Normative reference to an Informational RFC: RFC 3324
  - Downref: Normative reference to an Informational RFC: RFC 3325
  - Downref: Normative reference to an Informational RFC: RFC 6567

Of these, the reference to RFC3224 is a dangling reference and the
authors will be asked to remove this before publication.  So, that
leaves downward references to two RFCs: 3325 (P-Asserted-Identity)
and 6567 (Problem statement for UUI).

In my estimation, retaining these two downward references should not
pose a problem since RFC3325 is well known within the (SIP) community
and RFC6567 is the requirement document for the User-to-User header
itself.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part
of the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

The publication of this document will not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all protocol extensions that the document
makes are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

The IANA Considerations section is sound.  More specifically:
(a) The document updates the existing SIP parameter registry by adding
     a new row that reserves a new header name, User-to-User;
(b) The document updates the existing SIP parameter registry by adding
     three parameters to the new User-to-User header --- encoding,
     content and purpose;
(c) The document establishes three new sub-registries under
      http://www.iana.org/assignments/sip-parameters; these sub-registries
      are described adequately in the document, including providing
      default values where application;
(d) The document reserves a new SIP option tag as per the guidelines of
     Section 27.1 of RFC3261.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

The IANA registries defined in the document have a policy definition
of "RFC Required".  It was felt that having the IETF LC on any
new usages of UUI would be beneficial to bring to the attention of
the IESG any new work that derived from this document.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

I have reviewed Section 4.1 (contains ABNF syntax for User-to-User
header field) and found all production rules to result in appropriate
terminals.  I have also reviewed the IANA consideration section to
make sure that the information required for User-to-User extension
packages is well specified.  I did not find anything of concern in
my review of these sections.

--- End shepherd writeup

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/