Re: [Gen-art] Gen-Art review of draft-ietf-sipcore-rfc3265bis-07.txt

Alexey Melnikov <> Tue, 24 April 2012 15:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3FDF21F87B9; Tue, 24 Apr 2012 08:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.505
X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h-E6KHt8TJZc; Tue, 24 Apr 2012 08:06:18 -0700 (PDT)
Received: from ( [IPv6:2a00:14f0:e000:7c::2]) by (Postfix) with ESMTP id 426CA21F8610; Tue, 24 Apr 2012 08:06:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335279971;; s=selector;; bh=bGWfEmN/Kqlk3MUYRJ5mQixliT/6EKtfO/SfTXFIWO4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=WErpXfn7JrjeRZv9YVuX/yMVHSSHkhKyRxi2dbrW0qr9jR4QbTCxwiANGtB2ZZCmEzsec5 8AY4Ute41iy/8v4Y4K/Qe0FwY0LvnCCnQIQ3/vfsd6u3XbgzIVWZpsCGAa/RQBnF6Z0X/g o/2/9r5Jg5JEc3wkK3DoTlzJtLxmDaA=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Tue, 24 Apr 2012 16:06:11 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <>
Date: Tue, 24 Apr 2012 16:06:27 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: Adam Roach <>
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc:, The IESG <>, Paul Kyzivat <>
Subject: Re: [Gen-art] Gen-Art review of draft-ietf-sipcore-rfc3265bis-07.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Apr 2012 15:06:20 -0000

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 
>> nice.
> 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 
> memory.
>>    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 
>> mentioned
>>      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.