[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Simple] RE: WGLC: Event Filtering
Hi Mary,
Thanks for your time and comments. Responses inline...
> -----Original Message-----
> From: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Sent: 14.July.2004 11:31
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Subject: FW: [Simple] RE: WGLC: Event Filtering
>
>
>
> -----Original Message-----
> From: ext Mary Barnes [mailto:mary.barnes at nortelnetworks.com]
> Sent: 14.July.2004 05:11
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); rsparks at dynamicsoft.com
> Cc: simple at ietf.org
> Subject: RE: [Simple] RE: WGLC: Event Filtering
>
>
> 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
Done.
> - 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."
Done.
> - 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)
I agree with you, but I struggled to write some meaningful text. Can you provide me with text? I would really appreciate it.
> - 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.
The number was not according to any implementation experience, but was rather according to guesstimates I made using the presence document as a guide. It is very difficult for a client to estimate the processing power of the server that is generating those notifications and therefore we must recommend a number for the client to follow. Having said that, you are right that some servers might be able to handle more than the recommended number enabling the client to set more filters.
>
>
> 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
Done.
> - 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.
The abstract now reads:
"Filtering is a mechanism for defining the preferred content to be delivered and for specifying the rules for when the content should be delivered. In order to enable this, a format is needed to enable the subscriber to choose when notifications are to be sent to it and what they are to contain. This document presents a solution in the form of an XML document format.
The filtering mechanism is expected to be particularly valuable and primarily applicable to users of mobile wireless access devices."
> - 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."
Done.
> - 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."
Done.
>
> - 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.
As above.
Thanks,
Hisham
>
>
> -----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