[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: roots wasRe: filtering problem
Well, ok but
- if I send a get-config to your agent and I need to validate it on the
manager side, or
- if I build a config on the manager side and I want to validate it
before sending,
I will also need to append a root node before validation, that in any
case need to be defined in the data model schema. Now that I think about
it, you can validate any individual root separately...
This does not seem very natural to me. A root would remove the need to
append a "config" for copy-config as you pointed out.
I might be wrong, but it seems to me that, in most XML implementations,
creating a root node and appending multiple child subtrees from other
XML documents will be a pain and very costly, because you need to change
the document owner of every nodes to have a consistent document. Some
API may make it easier but, IMHO, it would be so much more simple to add
a root.
I understand your point with the consequences of such a change. Maybe,
we could just *recommend* that the data model defines a root node. This
is not a killing issue.
My 2 cents.
Vincent
-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: vendredi 20 juillet 2007 17:03
To: Vincent Cridlig (vcridlig)
Cc: David B Harrington; Balazs Lengyel; tom.petch; netconf@ops.ietf.org
Subject: Re: roots wasRe: filtering problem
Vincent Cridlig (vcridlig) wrote:
> I also think one root including mounted subtrees for various
> namespaces is better than concatenated multiple roots. These multiple
> roots can become children of a main root in any case.
> Otherwise filters will have to apply to many roots, rather than one.
> How do you build the reply in case nodes from various roots are
selected...?
> This can happen when namespaces are reused in various data models to
> include data following a generic structure.
>
Think about what this means.
Let's say there is a top-level element everybody is forced to use,
called <top>, in the NETCONF base namespace.
Every vendor would need to change every agent and every manager to
support this change. NETCONF is supposed to be content-independent.
This doesn't seem so independent.
All vendor and even all IETF data model objects are going to be in
different namespaces, so the child nodes of <top> are all the nodes that
would have appeared in <config> or <filter>, accept moved down one extra
XML layer. It doesn't change the filtering mechanism at all. (This is
the XML equivalent of the Spinal Tap moment - "But this amp goes to
11").
The real problem that exists (if any), is the lack of a consistent XML
container for <copy-config> output. I use the <config> element in the
NETCONF base namespace for this purpose. It doesn't matter so much what
the QName value is for this top-level container, but there does need to
be one. It ensures the <copy-config> output will be valid XML, even if
multiple data models from vendors and the IETF exist in the agent.
> In Xpath, one missing thing IMO is how is built the reply after an
> Xpath get-request. Xpath result is always a node set. Is the reply a
> concatenation of the result nodes, or is it a reconstructed document
> containing the selected nodes? I don't think this is a data model
> dependant question. This aspect is defined in the case of subtree
> filtering and it should be defined also for Xpath.
>
> Regards,
> Vincent
Andy
>
>
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
> On Behalf Of David B Harrington
> Sent: vendredi 20 juillet 2007 7:20
> To: 'Balazs Lengyel'; 'tom.petch'
> Cc: ietf@andybierman.com; netconf@ops.ietf.org
> Subject: 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/>
>
> --
> 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/>