[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: roots wasRe: filtering problem
I think we need one root, so a get-config will be able to include
everything.
David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
> -----Original Message-----
> From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel
> Sent: Thursday, July 19, 2007 11:14 AM
> To: tom.petch
> Cc: ietf@andybierman.com; netconf@ops.ietf.org
> Subject: Re: roots wasRe: filtering problem
>
> Hello,
> I think the datastore will often have multiple roots. I
> foresee/have heard of the following
> situations that as I understand are all valid in Netconf:
> 1) One root in one namespace, other namespaces might be
> mounted as subtrees
> 2) One root per namespace
> 3) One namespace but with many root elements
> 4) Many roots in many namespaces
>
> Case 2 can be viewed as a the single rooted case 1) where the
> first branching is according to
> the namespace.
>
> Case 3) and 4) I feel the filter should be applied to each
> root and the results of these
> combined under the <data> element in the get/get-config reply.
>
> Comments?
>
> Balazs
>
> tom.petch wrote:
> > This may relate to something that has been bugging me.
> >
> > XPath is - at times - specified in terms of a root, and an
> XML document has a
> > single root element. What is on the wire is an XML
> document but the datastore
> > is not - as Andy has pointed out before.
> >
> > So what is an XPath filter being applied to? The event as
> it would appear on
> > the wire as an XML document? A conceptual document created
> in the datastore for
> > the purposes of filtering? And if the latter, should we -
> we should! - specify
> > a root, either for the purposes of the examples or else for
> everything.
> >
> > RFC4741 is quite discursive about roots but the
> notification I-D is silent; I
> > think that this last needs to change.
> >
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "Martin Bjorklund" <mbj@tail-f.com>
> > To: <ietf@andybierman.com>
> > Cc: <netconf@ops.ietf.org>
> > Sent: Friday, July 13, 2007 4:43 PM
> > Subject: Re: filtering problem
> >
> >
> >> Andy Bierman <ietf@andybierman.com> wrote:
> >>> Hi,
> >>>
> >>> There is another problem with filtering and the examples
> in sec 5: (!!!)
> >>>
> >>> The draft must say exactly where in the <notification> element
> >>> that the <filter> is applied. The current text does not
> say anything.
> >> Agreed.
> >>
> >>> All the examples in sec. 5 are broken because the
> 'notification type'
> >>> layer is missing.
> >> I think it is ok. Specify that the filter is applied to the
> >> 'notificationContent' element as root (which is the
> abstract element).
> >>
> >>> The examples assume the filters can only be
> >>> applied to a conceptual datastore, just like the <rpc> filter.
> >>>
> >>> However, the most commonly needed filter is going to be
> >>> on the notification type itself!
> >>>
> >>> Example (w/o namespaces):
> >>>
> >>> <notification>
> >>> <configChange>
> >>> <configChangeTime>date-time string...</configChangeTime>
> >>> <configChangedBy>fred@example.com</configChangedBy>
> >>>
> <configTarget>/interfaces/interface[name='eth0']</configTarget>
> >>> ...
> >>> </configChange>
> >>> </notification>
> >>>
> >>> For simplicity, assume the manager just wants
> >>> this one notification type. The filter is going to be
> something like:
> >>>
> >>> <filter type="subtree">
> >>> <configChange/>
> >>> </filter>
> >> Yes, and IMO this is consistent with the examples.
> >>
> >>
> >> /martin
> >>
> >>
> >>
> >>> A filter for configChange just on a specific configTarget
> might be:
> >>>
> >>> <filter type="subtree">
> >>> <configChange>
> >>>
> <configTarget>/interfaces/interface[name='eth0']</configTarget>
> >>> </configChange>
> >>> </filter>
> >>>
> >>> The way the draft is now does not reflect how notifications are
> >>> actually structured.
> >>>
> >>>
> >>> Andy
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> 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/>