[Sip] WGLC Comments on draft-ietf-sip-xcapevent-01

[Ben Campbell <ben at estacado.net>]

Hi,

I have reviewed draft-ietf-sip-xcapevent-01 for WGLC, and have some  
comments. Apologies in advance for getting this in late.

General:

While I do not have many major technical concerns, I think the  
presentation could use some work. I share Miguel's concern that the  
organization of section 4.1 needs work.  More specifics below:

Specific Comments:

Section 4.1 Paragraph 2 (editorial):

"Once these nodes will be
    created, the notification bodies will indicate their content."

I find this sentence confusing. I suggest something like "If this node  
is later created, the notification body will indicate its content."

Section 4.4, paragraph 1(clarity):
"The usage of hierarchical lists and <entry>
    references, etc. can thus be omitted."

You say that the usage of hierarchical lists and <entry> references  
can be omitted. Are they actually being forbidden in this context, or  
do you just mean to say that they are optional? If features of the  
resource list format are forbidden, then this draft needs normative  
language saying explicitly what is not to be used. If you just mean to  
say that they are optional, what are the interoperability issues if  
one device chooses to use them but the peer does not understand them?

"As it is
    anticipated that the XCAP server will be collocated with the SIP
    notifier, the subscriber MAY use relative XCAP URIs."

Is it the authors' intention to require this collocation? That seems  
to be an architectural consequence of allowing relative URIs, unless  
we assert that if an implementation is architected differently, it is  
up to the implementation to be able to dereference relative URIs.

Paragraph 2(editorial):

"If no Accept header is specified to a SUBSCRIBE request, the NOTIFY
    messages will also contain bodies in this MIME type."

I am confused by the word "also" in this context--does this imply that  
the body in this MIME type is in addition to some other body? I think  
you just mean to say that the default is xcap-diff+xml if the Accept  
header is ommitted, but the wording is confusing.

Section 4.7, first paragraph(clarity):

"Once there are superfluous resource
    selections in the requested URI list, the notifier SHOULD NOT  
provide
    overlapping similar responses for these resources."

The sentence is confusing. "Once there are..." implies that there  
_will_ eventually be superfuous resource selections. I think you mean  
to say "If there are..."

"Only the
    resources where the authenticated user has read privilege, will be
    included in the XCAP-Diff format."

That seems like a normative statement that needs normative language.

The  last half of the paragraph is hard to follow, as it intermingles  
three distinct ideas each worthy of its own paragraph. That is, 1)  
Subscriber must have read permissions to see things, 2) Subscriptions  
to elements that don't exist yet are still kept in case the element is  
created in the future, and 3) What happens if the subscriber switches  
event parameters in a re-subscribe.

Also, have we thought about the performance and DoS implications of  
requiring the notifier to keep subscription state for elements that  
may or may not exist at some point in the future? I'm not saying there  
is a problem, but it raises a warning flag to me. I'm willing to  
believe it is okay, but it might be worth some text explaining that.

Paragraph 3 (clarity):

I'm not sure what the MUST applies to here--are you saying that the  
server MUST check for the condition you list as an example, or simply  
that, if the notifier chooses not to send XML-Patch-Ops patches for  
reasons of local policy, it MUST fall back to xcap-patching mode?

Also, I suggest reversing the order of paragraphs 3 and 4, as 4  
introduces the general principle, and 3 is more about corner cases.

Paragraph 5 (clarity):

"RFC 3265 [RFC3265]
    proposes utilization of a "version" attribute information to state
    deltas in chapter 4.4.  Partial-PIDF-Notify
    [I-D.ietf-simple-partial-notify] requires that notifiers will not
    send a new request to the same dialog unless a successful response
    (200 OK) has been received for the last request.  The latter applies
    also to this "xcap-diff" event package."

This is confusing--you mention the version attribute but don't seem to  
indicate its use here. Why mention it at all, except maybe in a  
paragraph explaining why it wasn't chosen? OTOH, you do require the  
partial-pidf-notify approach--this needs some normative language,  
unless it is elsewhere and I missed it.

section 4.8, paragraph 1 (editorial/clarity):

"  However,
    once all atomic XCAP modifications are indicated with both previous
    and new ETags of each resource, it is easy to chain the modification
    list for a document and possibly omit some of the patches based on
    the received ETag (with HTTP) of a document."

s/"once all"/"since all"

"After that the
    subscriber MAY send a re-subscription to start the diff  
"aggregation"
    on the server."

Does this mean to imply the subscriber cannot start out with  
aggregation turned on? (I think this may be another case of presenting  
the edge case without presenting the primary use case first.)

Paragraph 2: (substantive)

You cannot safely use non-sequential CSeq to detect missing NOTIFY  
requests. For example, if the NOTIFY request is challenged by an  
intervening proxy, the subscriber will see non-sequential CSeq values.  
It may be unusual for NOTIFY to get challenged, but unless we forbid  
it, then we cannot depend on CSeq for this purpose.

Paragraph 3 (editorial/clarity):

"...look Section 5.1 of
    [I-D.ietf-simple-xml-patch-ops]..."

s/look/see

"It is
    hardly reasonable to signal this error to the notifier even if the
    error exists in the notifier process."

I think there is an implication here that should be stated explicitly,  
that is, the subscriber does not send a non-2XX response to a NOTIFY  
because of an inability to apply the patch.

Section 4.10 (substantive)

It's not clear to me how this interacts with the "aggregation"  
mechanism. In particular, if the notifier has more than one change in  
the 5 second window, but the subscriber did not allow aggregation, how  
is it handled?

Section 5, figure 3 (clarity):

It would be nice to see this in context of an actual NOTIFY.

Section 6, 2nd paragraph (nit):

There is no need for a bullet list if it contains only one bullet.

Section 7, Security Considerations (substantive)

I think we need more here. What sort of authentication is adequate  
(particularly for authenticating the notifier.) Does the potential  
sensitive content create any need for privacy and integrity protection  
beyond that generically needed for SIP-Events?















_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip