(1) What type of RFC is being requested?
    A Standards Track RFC.

    Why is this the proper type of RFC?
    The draft standardizes SIP headers, parameters and their
    interpretation by SIP actors.  As such, a Standards Track
    is the proper type of designation.

    Is this type of RFC indicated in the page header?
    Yes, it is.

(2) Technical Summary:
    The move of communications networks to SIP does not ameliorate
    the need to support use cases for interworking and transporting
    legacy PSTN-related information in SIP.  This document defines
    a package and associated semantics that allows SIP endpoints to 
    exchange information related to the ISDN UUS1 service.

    Working Group Summary:
    A WGLC was held from Nov-13-2013 to Nov-29-2013.  As part of the
    WGLC, reviews were performed by WG members (Andrew Allen, Atle
    Monrad and Celine Serrut-Valette) and other members affirmed the
    need to move ahead with the draft.

    There was one area on which consensus was eventually acheived:
    draft-ietf-cuss-sip-uui-isdn uses the value of "isdn-uui" for 
    the "purpose" header field parameter.  Older versions of the 
    draft used the value "isdn-network".  Consequently, there are 
    implementations that use "isdn-network" and doubtlessly, for 
    some valid reasons these implementations are not amenable to 
    change.  Text was added to -06 version of the draft that 
    adequately addressed the issue of implicitly supporting "isdn-
    network" in certain cases.  The participants to the discussion
    are okay with the proposed resolution.

    Document Quality:
    The document has been reviewed by multiple WG members and has 
    been affirmed by many more.  There are no known issues with 
    document quality.  There appear to be existing implementations 
    of the draft, especially since the issue requiring consensus
    (described above) was specifically so that existing code can
    continue to work.

    Personnel:
    Vijay K. Gurbani is the Document Shepherd.  Alissa Cooper is
    the Responsible Area Director.

(3) Document Shepherd has reviewed the document.
    Besides three minor nits that can be fixed during AUTH-48, there
    weren't any substantive issues that will prohibit the document
    from moving forward.

(4) The Document Shepherd does not have any concerns on the depth 
    or the breadth of the reviews that have been accorded to this document.

(5) The document does not need particular reviews from security,
    operations, AAA, DNS, DHCP, XML or internationalization.
    Aspects of the proposed package in the draft are (obviously) 
    related to SIP, but among the working group there have been
    enough personnel with SIP expertise who have vetted the draft
    appropriately.

(6) The Document Shepherd does not have any specific concerns or
    issues with this document that need to be elevated to the
    attention of the AD.

(7) Authors have confirmed that they are not aware of any IPR 
    disclosures related to the draft.  

(8) There has not been any IPR disclosure filed with reference to 
    the draft.

(9) There is solid WG consensus behind the document.  In fact, other
    SDOs remain interested in this document and have urged the
    timely publication of it.  The WG as a whole understand and agrees
    with the contents of this document.

(10) No one has threatened an appeal or otherwise indicated extreme
   discontent with this draft.  About the closes we have come to
   discontent has been regarding the slow movement of this draft
   since other SDOs remain interested in using this draft.

(11) No substantive nits found beyond an outdated reference.

(12) The contents of the document do not merit any formal review
   criteria related to MIB, media or URI types.

(13) Yes, all references are either normative or informative.

(14) There is a normative reference to draft-ietf-cuss-sip-uui
   document.  However, that document has been submitted to IESG
   for publication.

(15) There are no downward normative references.  There is a normative
   reference to an ITU-T document [Q931], but it is the Document
   Shepherd's understanding that the ITU-T document being referenced
   is at the equivalent level of maturity targeted by the draft itself.

(16) The publication of this draft will not change the status of
   any existing RFCs.

(17) The Document Shepherd has reviewed the IANA Considerations
   section of the draft and found it to be consistent with the
   expectation of updating the SIP parameter registry.  In addition,
   the draft also defines a SIP media feature tag that is added
   to the features.sip-tree of the Media Features tag registry.
   The artifacts related to the SIP media feature tag are appropriately
   specified in the IANA Considerations Section.

(18) This document does not establish any new IANA registries.

(19) The document does not contain XML or JSON code, so no automated
   checks are required.  The document does contain ABNF rules, which
   appear adequate as specified.