Re: Pre-release 2 of Notification Update

[Andy Bierman <ietf@andybierman.com>]

tom.petch wrote:
> Sharon
>
> I raised the question of whether a filter would be applied to the event as it
> would appear on the wire, or as it might appear in the datastore (thinking of
> XPath roots and namespaces).  Andy reported back, after a hallway BoF with
> Martin
>
> 'The filtering in Notifications is different for 2 reasons,
> as Martin has described in hallway BoFs...
>    1) the filter applies to the notification message, not the conceptual
>       NETCONF configuration database..'
>
> I would like to see that explicit.  I suggest adding to 3.2.5.2.1 para 1
> "Conceptually, the filter is applied to the event notification as it would
> appear on the wire and not to it as it might appear in the conceptual NETCONF
> database."


Good catch.
This needs more detail I think.
Given a conceptual notification message:

  <notification>
   <fooEvent>
     <eventClass>fault</eventClass>
     <eventSeverity>major</eventSeverity>
     <fooParam>ws1/hd0</fooParam>
   </fooEvent>
  </notification>

Do you want to force the string "/notification" to appear
over and over in every filter, or start the filter at <fooEvent>
instead, and save 13 chars in almost every term in the expression?

Is the <notification> element constrained to contain
exactly one child element?  (I think so.)

Then this section should specify that the <filter> element
in the <create-subscription> is applied to the one and only
child element of the top-level <notification> element.


Andy





> Tom Petch
>
> ----- Original Message -----
> From: "Sharon Chisholm" <schishol@nortel.com>
> To: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Wednesday, August 08, 2007 9:24 PM
> Subject: Pre-release 2 of Notification Update
>
>
> Hi
>
> I'm almost done the update (hopefully). Attached is a pre-release.
> Please let me know if anything was incorrectly executed.
>  <<rfcdiff.pyht_two.htm>>
>
> Disclaimers:
>
> 1. I have not validated much of the schema or examples
> 2. I got a bit confused in the updates to section 5.2. These may still
> have issues.
> 3. I have not done anything about replays in the future. The text
> remains unchanged in this area.
> 4. I need to double check that I have not missed updates.
> 5. There were a few changes (mainly editorial) that I did not make for
> specific reasons which I need to send an email to discuss.
> 6. Not sure if using correct namespace in section 2.1.1.1. Andy said
> what was there was wrong, but it validates for me and there was no
> suggestions. I tried something else, but it didn't validate.
> 7. There was a request to add description of how to define notification
> instances, which has not been added, but there are now two examples (one
> in replayComplete and one in the examples in section 5). Is this
> sufficient?
> 8.  I have not validate that I am always using the correct The URI
> string (NAMESPACE IDENTIFIER) instead of (CAPABILITY IDENTIFIER)
>
> Sharon Chisholm
> Nortel
> Ottawa, Ontario
> Canada
>
>
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>