I do have a few comments, mostly editorial/nits, but there is one general concern about the computational burden on the server that's generating these event filtered notifications, as I think that's not been very thoroughly addressed (except in the security section) and I think it needs to be highlighted upfront in these documents.
Mary
----------------------------------------------------------------------
I'll start with my comments on filter-funct.
- Update the document to the new template per the updated guidelines reflecting new IPR policies per RFCs: http://www.ietf.org/ietf/1id-guidelines.txt
- Abstract. Is not particularly informative. I don't think the 1st paragraph is necessary at all as it only talks about things not related to this document. I would remove that and update the 2nd paragraph by changing from:
" This document describes the operations a subscriber performs in order
to define filtering rules, how to handle responses to subscriptions
carrying filtering rules, and how to handle notifications with
filtering rules applied to them. The document also describes how the
notifier behaves when receiving such filtering rules and how a
notification is constructed."
To something like:
" This document describes the operations a subscriber performs in order
to define filtering rules associated with event notification information.
The handling of responses to subscriptions
carrying filtering rules and the handling of notifications with
filtering rules applied to them is described. The document also describes
how the notifier behaves when receiving such
filtering rules and how a notification is constructed."
- Section 7. Certainly, limiting the number of occurrences to 20 would help limit the DoS attacks, however, it seems that the computational intensity of these filters in general should really be highlighted much earlier in the document. I would think this would be useful in the introduction in the 2nd paragraph where the applicability of filtering relative to specific devices is discussed. It may well be a good idea to limit this spec, to systems that must support such devices, due to the computational intensity. Per my next comment, this is an engineering tradeoff, so it's not just a security issue, it's a system capacity and performance issue (for the entity handling the filters)
- Section 7. <Duplicate comment for filter-funct> Related to the previous comment, I also think that 20 is rather arbitrary and it would seem that 20 could certainly be a good default recommendation, but that systems need some engineereing to determine the optimum value. Do you all have concrete implementation experience that might help shed some light on why 20 is a good number? Perhaps, this has been discussed and I just missed it. But, this would be useful information for folks to have. I would think it's possible that implementations could have problems at lower levels or could have it set higher with no problem. Thus, more guidance in adjusting that number would be helpful.
Now, comments on Filter-format, most of which are very similar to the previous comments for filter-funct. I had a few other comments marked on my hardcopy, but I think those have already been brought up:
- Update the document to the new template per the updated guidelines reflecting new IPR policies per RFCs: http://www.ietf.org/ietf/1id-guidelines.txt
- Abstract. Is not particularly informative. I don't think the 1st paragraph is necessary at all as it only talks about things not related to this document. I don't find the 2nd paragraph helps much either. I would suggest replacing the 1st paragraph for the abstract with the 1st 2 paragraphs from section 2, with the recommended rewording suggested below, leaving the current 2nd paragraph as a 3rd paragraph or final sentences of the abstract.
- Section 2. I would suggest clarifying the first paragraph by augmenting the first paragraph by the following change from:
" The filtering mechanism is expected to be particularly valuable to
users of mobile wireless access devices."
To:
" The filtering mechanism is expected to be particularly valuable and primarily applicable to users of mobile wireless access devices."
- Section 2. Related to the next comment on section 7, I think the following should be added at the end of that 2nd paragraph:
" However, implementors need to be aware of the computational burden on the source of the event notification. This is discussed further in section 7."
- Section 7. <Duplicate comment for filter-funct>Certainly, limiting the number of occurrences to 20 would help limit the DoS attacks, however, it seems that the computational intensity of these filters in general should really be highlighted much earlier in the document. I would think this would be useful in the introduction in the 2nd paragraph where the applicability of filtering relative to specific devices is discussed. It may well be a good idea to limit this spec, to systems that must support such devices, due to the computational intensity. Per my next comment, this is an engineering tradeoff, so it's not just a security issue, it's a system capacity and performance issue (for the entity handling the filters)
- Section 7. <Duplicate comment for filter-funct> Related to the previous comment, I also think that 20 is rather arbitrary and it would seem that 20 could certainly be a good default recommendation, but that systems need some engineereing to determine the optimum value. Do you all have concrete implementation experience that might help shed some light on why 20 is a good number? Perhaps, this has been discussed and I just missed it. But, this would be useful information for folks to have. I would think it's possible that implementations could have problems at lower levels or could have it set higher with no problem. Thus, more guidance in adjusting that number would be helpful.
-----Original Message-----
From: hisham.khartabil at nokia.com [mailto:hisham.khartabil at nokia.com]
Sent: Tuesday, July 13, 2004 2:42 AM
To: rsparks at dynamicsoft.com; simple at ietf.org
Subject: [Simple] RE: WGLC: Event Filtering
There are very few days left for the WGLC of these drafts. Please send your comments a.s.a.p. I've had good comments for the filter-format draft but would appreciate some more comments for filter-funct.
Thanks,
Hisham
> -----Original Message-----
> From: ext Robert Sparks [mailto:rsparks at dynamicsoft.com]
> Sent: 30.June.2004 18:07
> To: simple at ietf.org
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Subject: WGLC: Event Filtering
>
>
> This is a SIMPLE working group last call for the following drafts:
>
> http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-f
> ormat-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-simple-event-fi
> lter-funct-01.txt
>
> Please provide comments to the list or chairs by July 16.
>
> Thanks,
> RjS
>
>
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________ Simple mailing list Simple at ietf.org https://www1.ietf.org/mailman/listinfo/simple