Telechat Review of draft-ietf-sipcore-rfc3265bis-

Request Review of draft-ietf-sipcore-rfc3265bis
Requested rev. no specific revision (document currently at 09)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-04-19
Requested 2012-04-05
Authors Adam Roach
Draft last updated 2012-04-24
Completed reviews Genart Last Call review of -?? by Alexey Melnikov
Genart Telechat review of -?? by Alexey Melnikov
Secdir Telechat review of -?? by Tero Kivinen
Assignment Reviewer Alexey Melnikov 
State Completed
Review review-ietf-sipcore-rfc3265bis-genart-telechat-melnikov-2012-04-24
Review completed: 2012-04-24


Hi Adam,
Sorry I've missed your reply earlier.

On 11/04/2012 23:03, Adam Roach wrote:

On 4/10/12 5:46 AM, Alexey Melnikov wrote:


Also, it might be good to reference RFC 3986 for URIs here.

Given that SIP uses URIs everywhere, I'm not sure what benefit is 

derived by referencing the URI syntax draft here.


4.4.4.  Allow-Events header field usage

   The "Allow-Events" header field does not include a list of the etvent

 typo: event

I don't find "etvent" in the document:

Is it possible you accidentally edited a local copy of the file prior 

to your review?

It is possible. Not a big deal either way.

I also don't find this typo in the source (which would surprise me in 

any case, as I made sure to run the -07 version through a spell checker).

   template packages supported by an implementation.  If a subscriber
   wishes to determine which event template packages are supported by a
   notifier, it can probe for such support by attempting to subscribe to
   the event template packages it wishes to use.

Can you clarify how such request would look like? An example would be 


I'm not sure what you're asking for here. It would be a SUBSCRIBE 

message, with an "Event" header field set to name the template you 

want to use. Basically it just says "we don't negotiate templates -- 

just try it and see if it fails." 

So my understanding is that it is not possible to just request a 

template event (it needs to be combined with something else)? I think 

some explanation and/or examples of this would be good, I don't think 

this is very clear in the document.


7.2.  Reason Codes

   This document further defines "reason" codes for use in the
   "Subscription-State" header field (see Section 4.1.3).

   Following the policies outlined in "Guidelines for Writing an IANA
   Considerations Section in RFCs" [RFC5226], new reason codes require a
   Standards Action.

Minor: This would prevent registration of new Reason Codes in an 

Experimental RFC (for example). I would like to double check that 

that is intentional.

It never came up explicitly during working group discussions, to my 


   Registrations with the IANA include the reason code being registered
   and 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.

I don't think Standards Action allows for "inter-SDO liaison 

activity", unless such documents from other SDOs are published as 

Standard Track RFCs. So I find your text confusing: either your 

registration procedure should also allow for direct IESG approvals 

(to allow registrations from other SDOs with no RFCs), or you should 

remove "as the result of inter-SDO liaison activity".

You're right. I suspect we really intended to make this registrable by 

external SDOs, meaning we probably really wanted Specification 

Required. I'm leaving this as-is for now, and will need to coordinate 

with our AD to iron out where to go with this.

Ok, I will tell Russ that these 2 issues are still pending resolution.

8.4.  Augmented BNF Definitions

   event-type        =  event-package *( "." event-template )

Minor: Does this mean that multiple template packages can be applied?
Is there any ordering for them?

Yes, and yes.

How would "foo.A.B" differ from "foo.B.A"?

Right now, we have only one template defined -- but imagine that we 

did define a new "list" template event package (we almost did this 

some years ago) which is used to aggregate several resources into a 

single subscription.

"Event: presence.winfo.list" would subscribe to the aggregation of 

several watcher-info documents into a single list.

"Event: presence.list.winfo" would subscribe to the watcher-info state 

of the indicated list.

Ok, so the ordering is important. Is this documented anywhere?

Nit: id-nits complains:

  -- Duplicate reference: RFC4660, mentioned in 'RFC4660', was also 


     in 'RFC 4660'.

"[RFC 4660]" reference is used in section 7.2.

id-nits is wrong. It incorrectly thinks that the paragraph starting 

with [RFC4660] on page 40 is trying to define a reference.

I thought it was a reference, but this is not a big deal.