[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pre-release 2 of Notification Update

tom.petch wrote:

----- Original Message -----
From: "Andy Bierman" <ietf@andybierman.com>
To: "tom.petch" <cfinss@dial.pipex.com>
Cc: "Sharon Chisholm" <schishol@nortel.com>; "Netconf (E-mail)"
<netconf@ops.ietf.org>
Sent: Tuesday, August 14, 2007 5:54 PM
Subject: Re: Pre-release 2 of Notification Update



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.


My logic is slightly different, that XPath filtering is defined for well-formed
XML documents and well-formed documents can only be relied on on the wire, eg in
having a single root.  If that means that an extra 13 characters appear in each
filter, well ... if we were concerned about 13 characters, would we be using
XML?  (XPath does allow for short cuts so the additional element names would not
be in every filter).



Then why don't you have this concern about filters for <get-config>?

These filters do not start with /rpc/get-config/filter/foo, they
just start with /foo.  I think Martin's suggestion of pointing
at the abstract notificationContent element is fine.


Tom Petch


Andy





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



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