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

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?