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

Re: Pre-release 2 of Notification Update

To: "Andy Bierman" <ietf@andybierman.com>
Subject: Re: Pre-release 2 of Notification Update
From: "tom.petch" <cfinss@dial.pipex.com>
Date: Wed, 15 Aug 2007 15:14:29 +0200
Cc: "Sharon Chisholm" <schishol@nortel.com>, "Netconf (E-mail)" <netconf@ops.ietf.org>
References: <713043CE8B8E1348AF3C546DBE02C1B4104459C1@zcarhxm2.corp.nortel.com> <021601c7de7e$7d54bf20$0601a8c0@pc6> <46C1D041.5090706@andybierman.com> <000201c7df0c$370dc780$0601a8c0@pc6> <46C2D354.8070803@andybierman.com>
Reply-to: "tom.petch" <cfinss@dial.pipex.com>

----- 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: Wednesday, August 15, 2007 12:20 PM
Subject: 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>?
>
Because the format of the datastore is  undefined and may or may not look like
an XML document, may or may not have a single root, so there are no existing
rules for us to follow.

The notification on the wire is defined, to be an XML document (ie with a single
root element), and XPath has some rules (start at the root) so I think we need a
good reason not to follow them.

(If I reuse someone else's technology, then I prefer not to introduce my own
proprietary tweak lest I be accused of behaving like ... - I have just been
reading articles describing how some large players in the IT world do this to
IETF RFC:-).

> 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.
>
It's ok; I would prefer the root of the document on the wire but can be
persuaded otherwise.

I also take Martin's comment about omitting reference to the conceptual data
store.

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


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

References:
- Pre-release 2 of Notification Update
  - From: "Sharon Chisholm" <schishol@nortel.com>
- Re: Pre-release 2 of Notification Update
  - From: "tom.petch" <cfinss@dial.pipex.com>
- Re: Pre-release 2 of Notification Update
  - From: Andy Bierman <ietf@andybierman.com>
- Re: Pre-release 2 of Notification Update
  - From: "tom.petch" <cfinss@dial.pipex.com>
- Re: Pre-release 2 of Notification Update
  - From: Andy Bierman <ietf@andybierman.com>

Prev by Date: Re: Pre-release 2 of Notification Update
Next by Date: Re: Pre-release 2 of Notification Update
Previous by thread: Re: Pre-release 2 of Notification Update
Next by thread: Re: Pre-release 2 of Notification Update
Index(es):
- Date
- Thread