Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription
draft-ietf-sip-refer-with-norefersub-04

IANA Last Call Comments:
Upon approval of this document the IANA will register a new SIP header field "Refer-Sub" and a new SIP option tag, "norefersub" at the following location: http://www.iana.org/assignments/sip-parameters

Questionnaire from Dean:

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?

Yes. I have reviewed the document and believe it is ready to forward 
to the IESG for publication. One exception is that the abstract is 
not sufficiently descriptive, and I have provided the shepherding AD 
(at her request) with supplementary text.

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 was extensively reviewed in the SIP working group.

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 topic of this draft is relatively isolated to a narrow aspect 
of the Session Initiation Protocol. In essence, this draft merely 
corrects a design shortcoming of RFC 3515,s REFER method which 
applies only to some use cases.

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

This draft has broader consensus in the SIP working group than most 
of our work.

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.

I am unaware of any party indicating even mild, much less extreme, 
discontent.

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

I have so verified, and run a current idnits check. Of course neither 
I nor idnits are perfect.

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?

The references are properly divided.

[AD notes that shepherd left her to check that the state of
the dependencies...]

New abstract from shepherd (with one sentence's grammar fixed by AD :)

  The SIP REFER extension as defined in RFC 3515 by default
  establishes a short-lived event subscription used to notify the party
  sending the REFER request about the execution of that  request. This
  notification is not needed in all cases.  This specification 
  provides a way to prevent this subscription/notification sequence,
  using a new SIP extension header field "Refer-Sub", which may be
  included in a REFER request. A new sip option tag "norefersub" is
  also defined to  provide for declaration and discovery of support
  for this extension.

Much thanks to shepherd for fine questionnaire, abstract and writeup (see
ballot).