SIP-Specific Event Notification
draft-ietf-sipcore-rfc3265bis-09

[Ballot comment]
This is an incredibly well-written protocol document, and so clear that I'm fine with a Yes ballot.

I can't convince myself any of these comments are DISCUSSion worthy, but I do think they all need addressing one way or the other.

1.2

  It is inappropriate to fail to comply with
  "SHOULD"-strength requirements whimsically or for ease of
  implementation.

I think that can be strengthened: "It is violation of a requirement of the specification to fail to comply with 'SHOULD' requirements whimsically or for ease of implementation."

3.1.1

Here and elsewhere, you say that something "MUST be defined by the event package". That's an odd use of MUST, since it's clearly not a protocol requirement for the implementer of the protocol, but rather a requirement for the protocol extension writer. I can see saying that "event packages will make such-and-so REQUIRED" to put implementers on notice that they will find the requirement in the event package, but I do wish you had a non-2119 way of expressing requirements for event package writers.

  A natural consequence of this scheme is that a SUBSCRIBE request with
  an "Expires" of 0 constitutes a request to unsubscribe from an event.

Maybe this is obvious and implicit for someone familiar with SIP, but you do mean "a SUBSCRIBE request *on the same dialog* with an 'Expires' of 0", right? You don't actually get to the fact that a SUBSCRIBE is dialog-creating until 4.1.2.1, but I think you can still make it clear here. Or you can just skip it, since it's covered in 4.1.2.3.

4.1.2.1

  The "Expires" header field in a 200-class response to SUBSCRIBE
  request indicates the actual duration for which the subscription will
  remain active (unless refreshed).

This implies to me (though it's not stated explicitly here) that the response MAY have a different Expires value than provided in the request. Is that true? You say something about this in 4.2.14, but not here.

4.1.3 For 'probation', you say "the client SHOULD retry at a later time". Is that really what you mean? What harm comes to me if I decide not to retry? Couldn't I decide to not retry? Do you mean "MAY retry at a later time", or perhaps "SHOULD NOT retry immediately". Some piece of information is missing here. I suspect this has some parallel to 'deactivitated' and migration, but I don't get it.

4.2.1 Why the out clause for 3515? If it's causing problems, why not just say MUST NOT and update 3515 to deprecate the use?

4.2.2 Seems to me that if a NOTIFY receives a failure response and the subscription is therefore removed, the notifier should *not* send an additional 'terminated' NOTIFY. But the state machine seems to indicate that it should. Was that the intention?

4.5.2 Dialog sharing seems like a mess. Why is this not a SHOULD NOT?

5 Generally: It seems like this entire section might work better as an appendix. It's not part of the protocol per se; it's extension documentation instructions. Also, the 2119 language in this section seems weird, especially in 5.4.1 and 5.4.12. Those seem like inappropriate uses of 2119. The only one I can make a case for is the one in 5.3.2, and even there I'm not convinced. (I notice that for some reason you *didn't* use 2119 language in 5.4.6 and 5.4.7, and *never* used MAY in this section.) Again, it would be nice if you could find a better way to express this. I'm not convinced 2119 is useful or appropriate here.

7.1 2119 language in IANA Considerations sections always worry me. When you say, "Registrations with the IANA MUST include...", are you putting a requirement on IANA? On the Expert Reviewer? I would rather see these removed and instead indicate that it is "required information in the template" or something like that.

7.1.1 s/initial IANA registration for event types will be empty/initial IANA registry for event types will be empty

7.2 Why is "Standards Action" required for this?

8.4

  token-nodot      =  1*( alphanum / "-"  / "!" / "%" / "*"
                            / "_" / "+" / "`" / "'" / "~" )

Do you really want to allow "***---***"? Are you sure you don't want:

  token-nodot      =  alphanum *( ( "-"  / "!" / "%" / "*"
                            / "_" / "+" / "`" / "'" / "~" ) alphanum )

instead?

[Ballot discuss]
This DISCUSS position does not require any immediate action on the
part of the authors.

I have an issue with the state diagram in section 4.1.2 that I would
like to discuss.  In general, I/ve found it important to take care with state diagrams
in protocol specifications to ensure that the state diagram is
correct and, unless otherwise indicated, complete.  I apologize for
not having the time to work through the entire state diagram for
correctness; I did notice that section 4.1.2.2 includes a message
exchange - which, admittedly, does not result in a state change - that
is not reflected in the state diagram.

My suggestion would be to add a disclaimer to the effect that the
state diagram is not normative and that there may be aspects of the
protocol behavior that are not reflected in the statae diagram.  I'm
open to discussion of this suggestion.

[Ballot discuss]
This DISCUSS position does not require any immediate action on the
part of the authors.

I have an issue with the state diagram in section 4.1.2 that I would
like to discuss.  In general, care must be taken with state diagrams
in protocol specifications to ensure that the state diagram is
correct and, unless otherwise indicated, complete.  I apologize for
not having the time to work through the entire state diagram for
correctness; I did notice that section 4.1.2.2 includes a message
exchange - which, admittedly, does not result in a state change - that
is not reflected in the state diagram.

My suggestion would be to add a disclaimer to the effect that the
state diagram is not normative and that there may be aspects of the
protocol behavior that is not reflected in the statae diagram.  I'm
open to discussion of the suggestion.

[Ballot comment]
This is an incredibly well-written protocol document, and so clear that I'm fine with a Yes ballot.

I can't convince myself any of these comments are DISCUSSion worthy, but I do think they all need addressing one way or the other.

1.2

  It is inappropriate to fail to comply with
  "SHOULD"-strength requirements whimsically or for ease of
  implementation.

I think that can be strengthened: "It is violation of a requirement of the specification to fail to comply with 'SHOULD' requirements whimsically or for ease of implementation."

3.1.1

Here and elsewhere, you say that something "MUST be defined by the event package". That's an odd use of MUST, since it's clearly not a protocol requirement for the implementer of the protocol, but rather a requirement for the protocol extension writer. I can see saying that "event packages will make such-and-so REQUIRED" to put implementers on notice that they will find the requirement in the event package, but I do wish you had a non-2119 way of expressing requirements for event package writers.

  A natural consequence of this scheme is that a SUBSCRIBE request with
  an "Expires" of 0 constitutes a request to unsubscribe from an event.

Maybe this is obvious and implicit for someone familiar with SIP, but you do mean "a SUBSCRIBE request *on the same dialog* with an 'Expires' of 0", right? You don't actually get to the fact that a SUBSCRIBE is dialog-creating until 4.1.2.1, but I think you can still make it clear here. Or you can just skip it, since it's covered in 4.1.2.3.

4.1.2.1

  The "Expires" header field in a 200-class response to SUBSCRIBE
  request indicates the actual duration for which the subscription will
  remain active (unless refreshed).

This implies to me (though it's not stated explicitly here) that the response MAY have a different Expires value than provided in the request. Is that true? You say something about this in 4.2.14, but not here.

4.1.3 For 'probation', you say "the client SHOULD retry at a later time". Is that really what you mean? What harm comes to me if I decide not to retry? Couldn't I decide to not retry? Do you mean "MAY retry at a later time", or perhaps "SHOULD NOT retry immediately". Some piece of information is missing here. I suspect this has some parallel to 'deactivitated' and migration, but I don't get it.

4.2.1 Why the out clause for 3515? If it's causing problems, why not just say MUST NOT and update 3515 to deprecate the use?

4.2.2 Seems to me that if a NOTIFY receives a failure response and the subscription is therefore removed, the notifier should *not* send an additional 'terminated' NOTIFY. But the state machine seems to indicate that it should. Was that the intention?

4.5.2 Dialog sharing seems like a mess. Why is this not a SHOULD NOT?

5 Generally: It seems like this entire section might work better as an appendix. It's not part of the protocol per se; it's extension documentation instructions. Also, the 2119 language in this section seems weird, especially in 5.4.1 and 5.4.12. Those seem like inappropriate uses of 2119. The only one I can make a case for is the one in 5.3.2, and even there I'm not convinced. (I notice that for some reason you *didn't* use 2119 language in 5.4.6 and 5.4.7, and *never* used MAY in this section.) Again, it would be nice if you could find a better way to express this. I'm not convinced 2119 is useful or appropriate here.

7.1 2119 language in IANA Considerations sections always worry me. When you say, "Registrations with the IANA MUST include...", are you putting a requirement on IANA? On the Expert Reviewer? I would rather see these removed and instead indicate that it is "required information in the template" or something like that.

7.1.1 s/initial IANA registration for event types will be empty/initial IANA registry for event types will be empty

7.2 Why is "Standards Action" required for this?

8.4

  token-nodot      =  1*( alphanum / "-"  / "!" / "%" / "*"
                            / "_" / "+" / "`" / "'" / "~" )

Do you really want to allow "...---..."? Are you sure you don't want:

  token-nodot      =  alphanum *( ( "-"  / "!" / "%" / "*"
                            / "_" / "+" / "`" / "'" / "~" ) alphanum )

instead?

[Ballot comment]

Clarified my questions in a call with Robert. Be nice if we can document
the reality sometime soon but this isn't the place to do it.

[Ballot discuss]

  The Gen-ART Review by Alexey Melnikov on 10-Apr-2012 started a
  discussion that has not yet reached closure.  At least 3 issues
  need to be resolved:

  (1)  Section 7.2 defines "reason" codes for use in the "Subscription-
  State" header field, and new reason codes require a Standards Action.
  This prevents registration of new Reason Codes in Experimental RFC.
  Please double check that that is intentional.

  (2) IANA reason code registrations require a reference to a published
  document which describes the event package.  Insertion of such values
  takes place as part of the RFC publication process or as the result of
  "inter-SDO liaison activity."  However, Standards Action is not
  appropriate since other SDOs do not publish Standard Track RFCs.

  (3) Ordering of template packages needs to be explained.

[Ballot comment]
Many thanks to Paul for an excellent and thorough PROTO writeup.  A note here: the IPR and copyright stuff you note from the nits checklist is just the boilerplate that's automatically put in by xml2rfc (or manually put in otherwise; it's correct in this document).  We should update the checklist to have current references, and to reflect the current position of that boilerplate in the documents.

I also really like the "SHOULD" note in Section 1.2.

On the IANA Considerations, thanks for retaining the context here, so the original document can be properly obsoleted.  One suggestion:

In the base section 7:
OLD
  (This section is not applicable until this document is published as
  an RFC.)
NEW
  The subsections here are for current reference, carried over from
  the original specification.  The only IANA action requested here is
  to change all registry references that point to RFC 3265, and have
  them point to this RFC.

...or some such text, so that the registries now cite the new document.

[Ballot discuss]
- 4.1.3 says NOTIFY requests SHOULD be authenticated, and points to
sections 22.2 and 23 from rfc 3261, with the specific pointers being
new text presumably added as a result of experience with this. I have
a few questions about that:

1. I believe the S/MIME part of that's just not supported so this
    amounts to a SHOULD for digest authentication.  (Is that right?)

2. Given that these messages may be sent via loads of proxies, how
    likely is it that the intended recipient will know the user's
    password and be able to verify the Authorization header? 

3. Where is the text about what to do if checking the Authorization
    header fails? (It may be there, I mostly checked the diff vs.
    3265 so may have missed it.)

4. Each proxy en-route could do a dictionary attack if it wanted, so
    is this really the best that we can do? If it is, are the threats
    and possible mitigations properly documented? I don't think I
    saw that, but arguably it ought not be here but elsewhere. I
    guess in particular if the same credential is used for other
    purposes this might be a bad thing and worth attacking.

I'm not sure if this is a significant change since 3265 (maybe S/MIME
support was expected to emerge but didn't?), so I'm also not sure what
is the appropriate way to handle this. It may be that the best that
can be done is to simply clarify the real situation wrt security here
and leave it at that, but I'd like to discuss that a bit so we don't
just maintain a fiction. Or maybe I've just gotten the wrong end of
the stick and its all ok.

[Ballot comment]
Section 4.1.2.4., paragraph 4:

>    Due to the potential for both out-of-order messages and forking, the
>    subscriber MUST be prepared to receive NOTIFY requests before the
>    SUBSCRIBE transaction has completed.

+ packet loss which can also lead to NOTIFY requests arriving before the SUBSCRIBE transaction to be completed.

First, a new registry called the "SIP Event-Type Namespace" will be created.

The policy for registration and maintenance of this registry is defined in section 4.1 of RfC 5727.

There are no initial registrations in this registry.

The initial registry will be as follows:

+-----------------+------------+------------+-------------+
|Package Name    | Type      | Contact    | Reference  |
+-----------------+------------+------------+-------------+
|                |            |            |            |
+-----------------+------------+------------+-------------+

Second, a new registry called the "SIP Subscription-State Reason Codes" registry
will be created.

Maintenance and new registrations in the new registry will be through Standards
Action as defined in RFC 5226.

There are initial registrations for this new registry as follows

+----------------------+---------------------+
| Reason Code          | Reference          |
+----------------------+---------------------+
| deactivated          | [ RFC-to-be ]      |
| probation            | [ RFC-to-be ]      |
| rejected            | [ RFC-to-be ]      |
| timeout              | [ RFC-to-be ]      |
| giveup              | [ RFC-to-be ]      |
| noresource          | [ RFC-to-be ]      |
| invariant            | [ RFC-to-be ]      |
| badfilter            | [ RFC-to-be ]      |
+----------------------+---------------------+

Third, in the Header Fields subregistry of the Session Initiation Protocol (SIP)
Parameters registry located at:

http://www.iana.org/assignments/sip-parameters

three new header field names will be added to the registry as follows:

Header Name:  Allow-Events
Compact Form:  u
Reference: [ RFC-to-be ]

Header Name:  Subscription-State
Compact Form:  (none)
Reference: [ RFC-to-be ]

Header Name:  Event
Compact Form:  o
Reference: [ RFC=to-be ]

Fourth, in the Response Code subregistry of the Session Initiation Protocol
(SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters

two new Response Codes will be added to the registry as follows:

Response Code Number:  202
Default Reason Phrase:  Accepted
Reference: [ RFC-to-be ]

Response Code Number:  489
Default Reason Phrase:  Bad Event
Reference: [ RFC-to-be ]

IANA undestands that these four actions are the only actions that are required to be completed upon approval of this document.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (SIP-Specific Event Notification) to Proposed Standard





The IESG has received a request from the Session Initiation Protocol Core

WG (sipcore) to consider the following document:

- 'SIP-Specific Event Notification'

  as a Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-04-03. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  This document describes an extension to the Session Initiation

  Protocol (SIP).  The purpose of this extension is to provide an

  extensible framework by which SIP nodes can request notification from

  remote nodes indicating that certain events have occurred.



  Note that the event notification mechanisms defined herein are NOT

  intended to be a general-purpose infrastructure for all classes of

  event subscription and notification.



  This document represents a backwards-compatible improvement on the

  original mechanism described by RFC 3265, taking into account several

  years of implementation experience.  Accordingly, this document

  obsoletes RFC 3265.  This document also updates RFC 4660 slightly to

  accommodate some small changes to the mechanism that were discussed

  in that document.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc3265bis/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc3265bis/ballot/





No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

Why is this the proper type of RFC?

The document it is replacing is of that type.
It defines normative SIP behavior.

Is this type of RFC indicated in the title page header?

Yes. The intended status is Standards Track.

(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 describes an extension to the Session Initiation
Protocol (SIP).  The purpose of this extension is to provide an
extensible framework by which SIP nodes can request notification from
remote nodes indicating that certain events have occurred.

Note that the event notification mechanisms defined herein are NOT
intended to be a general-purpose infrastructure for all classes of
event subscription and notification.

This document represents a backwards-compatible improvement on the
original mechanism described by RFC 3265, taking into account several
years of implementation experience.  Accordingly, this document
obsoletes RFC 3265.  This document also updates RFC 4660 slightly to
accommodate some small changes to the mechanism that were discussed
in that document.

Working Group Summary

The shepherd reviewed all the discussion (and there was a lot) but found
nothing worthy of bringing up here - it was all resolved.

Document Quality

In my opinion this document is a good one - accomplishing what it set
out to accomplish. It reflects a lot of work done well.

Because this is a revision to an existing RFC, that only tweaks things,
its hard to know if there have been any implementations of *this* draft
prior to its publication as an RFC.

Judging from the number of participants in the discussions, I do expect
that this draft will rapidly become the reference for future event
implementations. This will not cause any major upheavals, because the
changes are minor.

The one place where there might be reluctance to move to the revision is
for the implicit subscription for REFER, because this version doesn't
allow REFER to be done in an existing dialog. Those who have sip
implementations that use in-dialog REFER may choose to continue doing
so. The backward compatibility requirements in this draft will allow
those things to keep working, but it may cause difficulty in claims of
conformance if such an implementation wants to claim conformance to this
draft except for that REFER case. But this is merely collateral damage
for digging out of the issues caused by the introduction of shared
dialogs in RFC 3261.

Personnel

  Who is the Document Shepherd?

Paul Kyzivat

  Who is the Responsible Area Director?

Robert Sparks

(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 read carefully through the draft one last time. I also reviewed the
history of discussion of this draft on the mailing list, including WGLC
comments. I ran a detailed and verbose nit check. I also manually
checked things listed in www.ietf.org/id-info/checklist.html.

In my opinion this document is ready for publication.

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

No.

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

Specialized reviews such as those mentioned don't appear to be needed.

During WGLC questions were raised about security issues:
lack of clarity about use of TLS. But there was general
agreement that the issues are not specific to sub/not,
but rather are generic SIP issues. The individual raising
the issue was asked to retarget it as a more general issue.
It would be inappropriate to attempt to solve this problem
uniquely for sub/not.

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

No concerns.

(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. The author has confirmed that he is aware of no IPR on this.

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

There have been no IPR disclosures against *this* document.

There are old IPR disclosures against RFC3265 or the drafts leading to
it. Since this document updates that, those may apply against it. The
IPR report for 3265 also lists a number of disclosures against related
RFCs, such as 3261 and 2543. But there are no new issues.

The following are against 3265:

https://datatracker.ietf.org/ipr/45/
https://datatracker.ietf.org/ipr/582/

Of those, ipr/45 predates RFC3265 by several months, but ipr/582
postdates it by three years, and so was never considered when 3265 was
in progress.

The following are against other related SIP RFCs:

https://datatracker.ietf.org/ipr/62/
https://datatracker.ietf.org/ipr/579/
https://datatracker.ietf.org/ipr/581/
https://datatracker.ietf.org/ipr/1371/
https://datatracker.ietf.org/ipr/1390/

There was no IPR discussion while considering the bis.

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

There were a lot of people (17) commenting over the almost three years
that this has taken. During the WGLC we had seven people commenting. For
SIPCORE this is good participation, especially for something focused on
technical details rather than new functionality.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize 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 - there were no threats.

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

  -- The document date (February 27, 2012) is 14 days in the past.
      Is this intentional?

Yes, its fine.

  == Missing Reference: 'Roach' is mentioned on line 1763,
      but not defined

  -- Duplicate reference: RFC4660, mentioned in 'RFC4660',
      was also mentioned in 'RFC 4660'.

The above two are artifacts due to syntax (in an IANA registration
template) that looks like a reference but isn't.

The IPR and copyright stuff mentioned in
http://www.ietf.org/id-info/checklist.html is missing. I'm surprised the
nits tool didn't report this. But the references in the checklist seem
wrong, since they refer to 3978, which has been obsoleted by 5378. Its
not clear to me what should be here, or how to get it.

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

N/A (There are no such things to be reviewed)

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

Yes.

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

No.

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

No.

(16) Will publication of this document change the status of any
existing RFCs?

Yes - RFC3265.

Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction?

Yes.

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.

N/A

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

This revision doesn't define any new registries, and doesn't define
anything new in existing registries.

But the RFC it replaced did define new registries and populate them. The
descriptions for defining those registries and the templates for
populating them have been replicated in this document. Because those
registries are already established, this is moot except for historical
consistency.

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

N/A

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

The only formal language used is ABNF.
The ABNF is unchanged from RFC3265.
I did not recheck this.