Functional Description of Event Notification Filtering
draft-ietf-simple-event-filter-funct-05

From Elwyn Davies on the changes from -03 to -04:
I checked the latest versions and they are much improved.

Most of the problems seem to have been fixed (apart from the trivial editorial nits) and the consistency is much improved.

The only substantive issue which I flagged which I have nit seen comments on is the business of possible interaction with ACCEPT formats (S5.3  in functionality).  I am not sure whether this is an issue or not .. needs an expert comment!

Give or take the nits they appear to be ready.

[Ballot discuss]
These documents were reviewed by Elwyn Davies in version -03. I believe that his points are mostly addressed in the -04 versions, but want to make sure - I did not have time to check carefully on all his points before the telechat.

[Ballot comment]
To0 foolow up on Alliosn's comments on the fqdns (need to use example.com)
there are also cases of using net 10 instead of the IP addresses reserved
for examples (RFC3330), like
      Via: SIP/2.0/TCP 10.0.0.1:5060;branch=xjfdsjfk

[Ballot comment]
The documents need a cleanup of their fqdns; mydomain.com,
example1.com, etc. Our readers may not like it, but the rules call for all these to
migrate to example.com...

[Ballot discuss]
I can find no record of the MIME type described in section 8.1 of draft-ietf-simple-filter-format being reviewed on the ietf-types list.

The XML Schema included in section 6 of draft-ietf-simple-filter-format should be registered with IANA as described in sections 3.2 and 4 of RFC 3688.

This same XML Schema includes several extensible attributes and elements, but I can't seem to find any text in the document describing the extensibility framework.  What needs to be done to ensure that extensions are compatible with earlier work?  What needs to be done to avoid namespace collisions?  Please add some text to bound the extension framework.

Section 8.2 of draft-ietf-simple-filter-format registers an XML namespace.  Per Section 3.2 of RFC 3688, there is no XML to be registered when registering an XML namespace.  The XML included in this section should be removed.

[Ballot discuss]
Section 7 of both documents are the same.  It says:
  >
  > The filters in the body in a SIP message has a significant effect on
  > the ways in which the request is handled at a server.  As a result,
  > it is especially important that messages containing this extension be
  > authenticated and authorised.
  >
  What mechanism will be used for authentication?  Please provide a pointer.
  Once authentication is accomplished, the identity of the requestor will
  be known.  What else will be considered in the authorization decision?
  Please provide some guidance.

[Ballot discuss]
I'm having a hard time telling the difference between the two
documents.  They seem to have significant overlap in text if they are
not identical.  Please explain what purpose is served by which
document and why there is so much overlap.

Both documents claim in section 1 that there is a discussion of server
resource consumption in section 7.  I cannot find this discussion and
believe it is important.  I suggest that section 7 discuss whether
filters can loop (I think the answer is no) and on how to avoid
filters taking up too much CPU or storage resource on the server.