Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method
draft-ietf-sip-refer-feature-param-01

[Ballot comment]
I agree with Ted on the Ampersand-L-T issue (seems the tracker might eat entities).  Was this an I-D editing error, or did the authors really mean to use entities without the trailing semicolons (legal in HTML, not legal in XML)?

[Ballot discuss]
While the * is seperated from the ( in RFC3515, whitespace between repeat and element is not permitted in ABNF; it would be nice to correct that in this spec - meaning replace "* (SEMI" with "*(SEMI" both places that it appears.

[Ballot discuss]
While the * is seperated from the ( in RFC3515, whitespace between repeat and element is not permitted in ABNF; it would be nice to correct that in this spec - meaning replace "* (SEMI" with "*(SEMI" both places that it appears.

I agree with Ted on the Ampersand-L-T issue (seems the tracker might eat entities).  Was this an I-D editing error, or did the authors really mean to use entities without the trailing semicolons (legal in HTML, not legal in XML)?

[Ballot comment]
I assume that this will get worked out with the RFC Editor, but I found the "&lt" and "&gt"
less effective than simply "<" and ">" would have been:

  Note that if any URI parameters are present, the entire URI must be
  enclosed in "&lt" and "&gt".  If no "&lt" and "&gt" are present, all
  parameters after the URI are header parameters, not URI parameters.

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the
Internet Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?

The document was reviewed by WG chair Dean Willis.

The abstract contained in the current text is inadequate. A more
appropriate abstract has been provided to the shepherding AD and is
provided as the "technical summary" in the following writeup as per
draft-ietf-proto-wgchair-doc-shepherding-05.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The document has been thoroughly reviewed by the working group but
has received minimal attention from outside the working group. The
material involved is relatively narrow in scope, essentially forming
only a bug fix for the existing RFC 3515.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No. The material is rather specific to the SIP working group.

1.d) Do you have any specific concerns/issues with this document
that you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

I have no specific concerns.

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?

There seems to be a relatively broad consensus on the contents of the
document, although there is less than an absolute consensus on its
relative importance. That is, the current constituency of committed
implementors is somewhat less than for most SIP extensions.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.

No.

1.g) Have the chairs verified that the document adheres to all of
the ID nits? (see http://www.ietf.org/ID-Checklist.html).

idnits 1.85 reports the draft as clean. The included ABNF is a very
simple modification of the grammar of RFC 3515. Visual inspection
indicates no nits conformance areas.

1.h) Is the document split into normative and informative
references? Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear
state? (note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until
all such IDs are also ready for publication as RFCs.)

All references are normative (and marked as such) and there are no
pending dependencies.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

* Working Group Summary

* Protocol Quality

1.j) Please provide such a write-up. Recent examples can be
found in the "protocol action" announcements for approved documents.

Technical Summary:

The SIP "Caller Preferences" extension defined in RFC 3840 provides a
mechanism that allows a SIP request to convey information relating
to the originator's capabilities and preferences for handling of that
request. The SIP REFER method defined in RFC 3515 provides a
mechanism that allows one party to induce another to initiate a SIP
request. This document extends the REFER method to use the
mechanism of RFC 3840. By doing so, the originator of a REFER may
inform the recipient as to the characteristics of the target that the
induced request is expected to reach.

Working Group Summary:

This specification is the result of several months of discussion in
the SIP working group. The key issue resolved was around the scope of
capabilities to be expressed, with agreement on the capabilities
expression of RFC 3840 developing during a break-out session at IETF
63. This compromise position received broad support.

Protocol Quality:

The specification was reviewed for quality by the SIP working group
and by SIP chair Dean Willis. It includes only a very small extension
to the REFER method of RFC 3515.