RE: [Simple] RE: WGLC: Event Filtering

-----Original Message-----
From: ext Mary Barnes [mailto:mary.barnes at nortelnetworks.com]
Sent: 14.July.2004 16:31
To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
Cc: simple at ietf.org
Subject: RE: [Simple] RE: WGLC: Event Filtering

-----Original Message-----
From: hisham.khartabil at nokia.com [mailto:hisham.khartabil at nokia.com]
Sent: Wednesday, July 14, 2004 4:01 AM
To: Barnes, Mary [NGC:B601:EXCH]
Cc: simple at ietf.org
Subject: RE: [Simple] RE: WGLC: Event Filtering

> -----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

> - 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)

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.

[MB] So, perhaps, the simplest thing is to make it a bit more explicit that this number is a bit arbitrary and YMMV. I would suggest changing the wording in the last sentence of this section from:

" To counter this, the server SHOULD only
   allow filters with no more than about 20 occurrences of the <what>,
   <changed>, <added> and <removed> elements."
To:
" To counter this, the server MUST establish a limit on the number of
   occurrences of the <what>,
   <changed>, <added> and <removed> elements allowed in the filters.
   A default limit of 20 is RECOMMENDED, however, servers MAY raise or lower
   the limit depending upon their specific engineered capacity. "

[MB] I think the MUST is important in that first sentence as that's what satisfies the security requirement to limit the DOS attack.

Ok done. I also added text to the introduction as you suggested for the format draft:

"However, implementers need to be aware of the computational burden on the source of the event notification. This is discussed further in <xref target="security"/>."