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