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

Adam Roach <adam@nostrum.com> Wed, 11 April 2012 22:03 UTC

Return-Path: <adam@nostrum.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 4C3D111E80DB; Wed, 11 Apr 2012 15:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.42
X-Spam-Level:
X-Spam-Status: No, score=-101.42 tagged_above=-999 required=5 tests=[AWL=-1.120, BAYES_00=-2.599, MANGLED_SAVELE=2.3, SPF_PASS=-0.001, 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 ZZg+WKGUIosS; Wed, 11 Apr 2012 15:03:10 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4459A11E80CC; Wed, 11 Apr 2012 15:03:07 -0700 (PDT)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3BM34Lj041723 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 17:03:05 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4F85FF98.8000102@nostrum.com>
Date: Wed, 11 Apr 2012 17:03:04 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <CAHBDyN6PN-vp9wXo6fF8G4VfODXjkfbWBaJN8EPopeWfOg9PmQ@mail.gmail.com> <4F840F94.1080703@isode.com>
In-Reply-To: <4F840F94.1080703@isode.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
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: Wed, 11 Apr 2012 22:03:11 -0000

On 4/10/12 5:46 AM, Alexey Melnikov wrote:
>
> 3.2.1.  Identification of Reported Events, Event Classes, and Current
>         State
>
>    When present, the body of the NOTIFY request MUST be formatted into
>    one of the body formats specified in the "Accept" header field of the
>    corresponding SUBSCRIBE request.  This body will contain either the
>    state of the subscribed resource or a pointer to such state in the
>    form of a URI (see Section 5.4.13).
>
> Nit: or the default according to the event package definition, if no 
> Accept
> header field was specified.

I've added text to point this case out.

> 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.1.1.  Detecting Support for SIP Events
>
>    The extension described in this document does not make use of the use
>    of "Require" or "Proxy-Require" header fields; similarly, there is no
>
> Nit: too many "use of".

Fixed.

> 4.1.3.  Receiving and Processing State Information
>
>    To prevent spoofing of events, NOTIFY requests SHOULD be
>    authenticated, using any defined SIP authentication mechanism.
>
> Minor: How can this SHOULD be satisfied? Any reference which might be 
> appropriate here?

Added: "...such as those described in sections 22.2 and 23 of [RFC3261]."

>
> 4.2.1.3.  Authentication/Authorization of SUBSCRIBE Requests
>
>    SIP authentication mechanisms are discussed in [RFC3261].  Note that,
>    even if the notifier node typically acts as a proxy, authentication
>    for SUBSCRIBE requests will always be performed via a "401" response,
>    not a "407;" notifiers always act as a user agents when accepting
>
> Nit: Is the ";" after "407" a typo?

Thanks -- that should have been outside the quotation marks (and 
probably should be a full stop, which I've changed it to).

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

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

> 5.4.3.  SUBSCRIBE Request Bodies
>
>    It is expected that most, but not all, event packages will define
>    syntax and semantics for SUBSCRIBE request bodies; these bodies will
>    typically modify, expand, filter, throttle, and/or set thresholds for
>    the class of events being requested.  Designers of event packages are
>    strongly encouraged to re-use existing MIME types for message bodies
>    where practical.
>
> Nit: MIME types are now called "media types" in more recent IETF RFCs.

Thanks. Fixed in three places.

> I would recommend pointing to the Media Type Registration Procedure 
> document [RFC 4288] here, which points to the IANA registry.

Done.

>
> 5.4.5.  NOTIFY Request Bodies
>
>    Event packages also MUST define which MIME type is to be assumed if
>    none are specified in the "Accept" header field of the SUBSCRIBE
>    request.
>
> The same nit as above.

Fixed.

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

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

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

/a