Re: [sip-http-events] pre-submission check for draft-roach-sip-http-subscribe

[Adam Roach <[e-mail]>]

On 12/17/09 1:27 PM, Scott Lawrence wrote:
> On Thu, 2009-12-17 at 12:54 -0500, Scott Lawrence wrote:
>    
>> I've been asked to serve as Document Shepherd for the submission of
>> draft-roach-sip-http-subscribe.  The following are review comments based
>> on the checklist for the proto writeup...
>>      

Thanks. I've generally accepted the suggested changes, except as noted 
below.

New version here:

   http://www.ietf.org/id/draft-roach-sip-http-subscribe-06.txt
   http://tools.ietf.org/rfcdiff?url2=draft-roach-sip-http-subscribe-06.txt



>    Section 3.2, paragraph 3:
>
>         The monitor-group URI corresponds to an RLS service associated with
>         the HTTP server.  This RLS service MUST support subscriptions to
>         request-contained resource lists, as defined in RFC 5367 [8].  This
>         RLS service is not, however, required to accept URI lists that
>         include monitoring URIs that are not associated with resources served
>         by its related HTTP server.  This allows RLS functionality to be
>         implemented without requiring back-end subscriptions.
>
>      The exclusion in this paragraph is important enough that it should
>      be in the capitalized form.  I suggest:
>
>         The monitor-group URI corresponds to an RLS service associated with
>         the HTTP server.  This RLS service MUST support subscriptions to
>         request-contained resource lists as defined in RFC 5367 [8]; the
>         RLS service is NOT REQUIRED to accept URI lists that
>         include monitoring URIs that are not associated with resources served
>         by its related HTTP server.  This allows RLS functionality to be
>         implemented without requiring back-end subscriptions.
>
>      (you might also want to make that "MAY, but is NOT REQUIRED to")
>    

"NOT REQUIRED" is not a 2119 term. "REQUIRED" is functionally equivalent 
to "MUST" -- but the equivalent of "MUST NOT" would be something like 
"REQUIRED NOT TO," which would be cumbersome, even for RFC 2119.

I'm not completely certain what "NOT REQUIRED" would mean as a normative 
statement, unless you want to define it as identical to "MAY" -- in 
which case "MAY, but is NOT REQUIRED to" is somewhat redundant.

I do see value in adding a normative MAY here, since it's not explicitly 
permitted by this text. My proposed edit is:

    The monitor-group URI corresponds to an RLS service associated with
    the HTTP server.  This RLS service MUST support subscriptions to
    request-contained resource lists, as defined in RFC 5367 [9].  This
    RLS service MAY, but is not required to, accept URI lists that
    include monitoring URIs that are not associated with resources served
    by its related HTTP server.  Not requiring such functionality allows
    the RLS to be implemented without requiring back-end subscriptions.

I recognize that this leaves the term "required" in the text in a 
non-capitalized form, and the tools will complain about that fact. 
Normally, I'd insert my rant here about the combination of 2119 and the 
tools hijacking the use of perfectly common English words and making 
them impossible to use in their original sense -- but I imagine you can 
guess how that rant goes, so I'll save you the reading.


>    Section 4.7 paragraph 1:
>
>        NOTIFY messages should be generated whenever the underlying resource
>        indicated by the corresponding HTTP URL has been modified.
>
>      that 'should' either should be capitalized or (better, imho) made
>      'MUST' (that's kind of the point of the whole thing).
>    

There are caveats here, though -- for example, if event rate control is 
in effect, or policy prevents notification, or filters have modified the 
content such that there is no net change, or..., or..., or...

So we can't make it "MUST."

In fact, I don't think we're talking about normatively changing what 
3265 says about notifications -- we're just defining what state 
information is conveyed in notifications. So my inclination would be to 
state it as "NOTIFY messages are generated..."

>    Section 4.7 paragraph 2:
>
>        In the case that the notifier has insufficient information to return
>        any useful information about the underlying HTTP resource, it may
>        return a message body that is zero bytes long.
>
>      that 'may' is clearly normative and should be capitalized.
>    

And, on reflection, this should be a normative MUST, not a normative 
MAY. There's no other alternative.

>    Secion 4.10 uses 'may' twice in ways that could be replaced by
>    'might'.
>    

#insert <rfc2119_hijacking_english_rant>

>      The 'may' can be avoided by rephrasing:
>
>        Failure to ensure access control could expose information that
>        was intended to be confidential (including the actual resource
>        value, in some cases) to unauthrorized users.
>    

#insert <rfc2119_hijacking_english_rant>

> One other technical comment that I didn't notice on my last review of
> 05... in section 4.4 you say:
>
>     Keep in mind that the goal behind selecting
>     subscription durations is to balance server load against time to
>     recover in the case of a failure.
>
> it might be better to specify the nature of the failure -
> specifically, short subscriptions guard against the loss of
> subscription server state.
>    

I think they're both important aspects. I've added another sentence, 
making the paragraph end:

             Keep in mind that the goal behind selecting subscription
             durations is to balance server load against time to
             recover in the case of a failure.  In particular, short
             subscription expiration times guard against the loss
             of subscription server state, albeit at the expense of
             additional load on the server.

/a