Re: [Simple] WGLC Comments on draft-ietf-sip-xcapevent-01

ext Ben Campbell wrote:
> 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:
>
right, it will be rephrased

> 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."
>
much better phrased.

> 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.
>
in practice, the sip notifier must be aware of changes made by another 
protocol, i.e. http in this case. If these servers (notifier & http 
(xcap) daemon) are separated they need some sort of immediate mechanism 
to signal these events. It can be done with some unspecified ways, but 
the most simple one is when they are running on the very same host. 
However, even that simplest case is pretty hard (or complex enough) to 
implement properly (implementation description can be a long story 
although you are using OSS tools, like e.g. linux with Apache + 
xcap_module and some decent Sip stack with all the source code), and the 
intention is to define only the very simplest use-case here. It is not 
ruled out that they were separated but that would be much, much more 
difficult to implement, and there are many obstacles and open issues 
there. So there's magic (outside the scope of this i-d) here how to map 
the sip-uri to the xcap-root-uri, but this, the most simple use-case is 
what i'd expect to be implemented (and maybe, even some minor deployment 
as well ;-)).

Also we agreed with Miguel to be more explicit about this magic, does it 
sound sufficient to you ?
> 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.
>
right, by bad finglish.
> 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..."
right again.
>
> "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.
>
again.
> 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.
I'll try to clarify it by a separation.
>
>
> 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.
good point. there are other ways to introduce DoS as well since 
diff-processing of many resources MAY be way too process-intensive.  
I'll add that in the security section.
>
> 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?
the reason to drop the aggregation mode for that particular resource is 
that once the client have to use http, it might get out-of-sync (with 
"rapidly" changing resources), the rule is to be certain that it will 
not happen. I'll try to clarify.
>
> Also, I suggest reversing the order of paragraphs 3 and 4, as 4 
> introduces the general principle, and 3 is more about corner cases.
>
ok.
> 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.
yep, this was notified by Miguel also

>
>
> 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"
ok.
>
> "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.)
it can try to start in the aggregate mode straight away, but it may 
fail. So the safe way is to disable aggregation first before sync is 
achieved and enable it afterwards. I think I'll add something about this 
into those dreaded examples (in an appendix)
>
>
> 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.
ok, didn't think about that at all.
>
> Paragraph 3 (editorial/clarity):
>
> "...look Section 5.1 of
>    [I-D.ietf-simple-xml-patch-ops]..."
>
> s/look/see
ok.
>
> "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.
>
right.
> 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?
yep this is indeed _difficult_. Easy to write (one sentence only), but 
really, really hard to implement properly ;-). First off there's a 
SHOULD directive fortunately... I'm not 100 % sure if you mean that 
xcap-patching is also disabled. So there's not a big difference in this 
context whether you have aggregation or xcap-patching modes, since in 
the xcap-patching mode you will see changes e.g. from "a" to "b" to "c" 
with all corresponding Etags while in the aggregate mode you'll see e.g. 
only changes from "a" to "c" in the notification body without the 
intermediate state. Certainly aggregation body is smaller but it fails 
to show the versioning history and the diff formats differ, but the end 
result will be the same certainly, i.e. "c". So _if_ you obey the timer, 
you wait for it to expire and then send the result in both cases (and of 
course during this timer interval you wait for any changes in these 
resources, and do something relevant, e.g. store internal object 
states).  If there's not any patching modes applied, then you should 
wait for the timer to expire and send appropriate actions, i.e. 
document(s) has either been created, modified or deleted. IIRC, in 
partial PIDF where we use the exact same patchings there's not a single 
line about this since this timer is inherited from the base PIDF 
package. In summary, you just don't have to do anything mysterious with 
timers except wait for a certain period of time. In practice, it happens 
to be quite a challenging task (but these specs usually _ignore_ the 
implementation PITA ;-))
>
> Section 5, figure 3 (clarity):
>
> It would be nice to see this in context of an actual NOTIFY.
I'll try to digest something into an appendix. That being said, the 
important things are bodies...

>
> Section 6, 2nd paragraph (nit):
>
> There is no need for a bullet list if it contains only one bullet.
right.
>
> 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?
>
yep, besides DoS TLS & S/MIME recommendations some text about identity 
"mapping" between http & sip would be reasonable. Anything else ?

THANKS Ben,

Jari

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple