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

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 24 April 2012 15:06 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FDF21F87B9; Tue, 24 Apr 2012 08:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.505
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-E6KHt8TJZc; Tue, 24 Apr 2012 08:06:18 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (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; d=isode.com; s=selector; i=@isode.com; 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 [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <T5bBYgAg25I3@rufus.isode.com>; Tue, 24 Apr 2012 16:06:11 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F96C173.3020706@isode.com>
Date: Tue, 24 Apr 2012 16:06:27 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: Adam Roach <adam@nostrum.com>
References: <CAHBDyN6PN-vp9wXo6fF8G4VfODXjkfbWBaJN8EPopeWfOg9PmQ@mail.gmail.com> <4F840F94.1080703@isode.com> <4F85FF98.8000102@nostrum.com>
In-Reply-To: <4F85FF98.8000102@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: gen-art@ietf.org, The IESG <iesg@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [Gen-art] Gen-Art review of draft-ietf-sipcore-rfc3265bis-07.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=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.
Ok.

>>
>> 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:
>
> http://tools.ietf.org/html/draft-ietf-sipcore-rfc3265bis-07#section-4.4.4
>
> 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.