Subject: Re: [Netconf] subtree filter normalization

From: Xiang Li <[email-masked]>
Date: Tue, 05 May 2015 22:05:56 -0500

Hi

On 4/10/2015 1:21 AM, Martin Bjorklund wrote:
> Hi,
>
> Andy Bierman<[email-masked]>  wrote:
>> Hi,
>>
>> I'm trying to rewrite some NETCONF code, and I cannot
>> tell if RFC 6241 allows for subtree filters to be normalized.
>> It is not clear how certain usage should be processed.
>>
>> This text in 6.1, para 1 seems to suggest the filter does not
>> need to follow a schema.
>>
>>     The server does not need to utilize any data-model-
>>     specific semantics during processing, allowing for simple and
>>     centralized implementation strategies.
>>
>>
>> I am not convinced NETCONF is correct here
>> (and I wrote a lot of this subtree text ;-)
>> IMO the server MUST return schema-valid content
>> for YANG modules it advertises,
>> and that requires the filter to be interpreted
>> and the response content normalized.
> This would indeed have been better!  But that's not what the spec
> says...
>
>
>> F0 is the well-behaved example on pg 25:
>>
>> F0:
>>      <filter type="subtree">
>>         <top xmlns="http://example.com/schema/1.2/config">
>>           <users>
>>             <user>
>>               <name>fred</name>
>>             </user>
>>           </users>
>>         </top>
>>       </filter>
>>
>> The RFC does not say if the 'name' select node can be repeated,
>> as in F1:
>>
>> F1:
>>     <filter type="subtree">
>>         <top xmlns="http://example.com/schema/1.2/config">
>>           <users>
>>             <user>
>>               <name>fred</name>
>>               <name>barney</name>
>>             </user>
>>           </users>
>>         </top>
>>       </filter>
>>
>> 6.2.5, bullet 2 says these are ANDed together, so
>> filter F1 would not match anything.  IMO this should only
>> apply to different select leafs.  Duplicate select leafs
>> should be ORed together.  This will help normalization.
> I think the current behavior is correct.  If you want to get both fred
> and barney you have to do:
>
>    <user>
>     <name>fred</name>
>    </user>
>    <user>
>     <name>barney</name>
>    </user>
>
> I don't think there is any reason for a special case when the select
> node is duplicated.  It can actually be confusing.  Assuming the list
> has two keys, what would this mean:
>
>    <user>
>     <given-name>martin</given-name>
>     <given-name>andy</given-name>
>     <surname>bjorklund</surname>
>     <surname>bierman</surname>
>    </user>
>
>> F2:
>>     <filter type="subtree">
>>         <top xmlns="http://example.com/schema/1.2/config">
>>           <users>
>>             <user>
>>               <name>fred</name>
>>             </user>
>>             <user>
>>               <name>fred</name>
>>             </user>
>>           </users>
>>         </top>
>>       </filter>
>>
>> Is F2 allowed? (container user repeated)
>> Is the server required to collapse the entries for return
>> so the rpc-reply is schema-valid?
> In this case the natural reply is schema-valid:
>
>      <top xmlns="http://example.com/schema/1.2/config">
>        <users>
>          <user>
>            <name>fred</name>
>            ...
>          </user>
>          <user>
>            <name>fred</name>
>            ...
>          </user>
>        </users>
>      </top>

But  RFC6241 6.1 also says:

  ...
    Specific data instances are not duplicated in the response in the event that
    the request contains multiple filter subtree expressions that select
    the same data.

Shouldn't the example F2 be considered as "a  request contains multiple 
filter subtree expressions that select the same data" and hence the 
duplicates need to be suppressed?

Thanks
--Xiang

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 May 2015 20:21:48 -0700

> duplicates need to be suppressed?

Perhaps.
I implemented the code a bit more literally.
Duplicate sibling selection nodes are eliminated but not duplicate
subtrees that contain content-match nodes.

Martin pointed out this text that says a schema is not needed,
as an indication that the data returned in the <data> element did not
need to be schema-valid

Maybe the server should be able to detect the duplicate subtrees
in F2, even without a schema, but maybe if the client asks the
same question 3 times, then just answer it 3 times.

> --Xiang

Andy

>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 May 2015 12:50:23 +0200

Martin Bjorklund <[email-masked]> writes:

> Hi,
>
> Andy Bierman <[email-masked]> wrote:
>> Hi,
>> 

Is it? If the example is yangified, "name" would most likely be the list
key, and they we have duplicate keys in the response.

Lada

>> Same applies to F3 and F4.
>
> The way the spec is written (data model agnostic), you'd get a reply
> that mimics the filter input.  The only way for a server to collapse
> the <user>s into a single <users> element, is to utilize the fact that
> "users" is a container.
>
>> F3: variant of F2
>>    <filter type="subtree">
>> F4: variant of F2
> /martin

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Thu, 7 May 2015 20:08:26 +0000

I'm with Andy on this.  I don't think the server should be *required* to filter out the duplicate fred in that example.

Jason

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, May 05, 2015 11:22 PM
To: Xiang Li
Cc: Netconf
Subject: Re: [Netconf] subtree filter normalization

On Tue, May 5, 2015 at 8:05 PM, Xiang Li <[email-masked]> wrote:
>>> I'm trying to rewrite some NETCONF code, and I cannot tell if RFC 
>>> 6241 allows for subtree filters to be normalized.
>>> This text in 6.1, para 1 seems to suggest the filter does not need 
>>> to follow a schema.
>>>
>>> I am not convinced NETCONF is correct here (and I wrote a lot of 
>>> this subtree text ;-) IMO the server MUST return schema-valid 
>>> content for YANG modules it advertises, and that requires the filter 
>>> to be interpreted and the response content normalized.
>>
>>> The RFC does not say if the 'name' select node can be repeated, as 
>>> in F1:
>>>
>>> F1:
>>>     <filter type="subtree">
>>> 6.2.5, bullet 2 says these are ANDed together, so filter F1 would 
>>> not match anything.  IMO this should only apply to different select 
>>> leafs.  Duplicate select leafs should be ORed together.  This will 
>>> help normalization.
>>
>> I think the current behavior is correct.  If you want to get both 
>> fred and barney you have to do:
>>
>>    <user>
>>     <name>fred</name>
>>    </user>
>>    <user>
>>     <name>barney</name>
>>    </user>
>>
>>> Is F2 allowed? (container user repeated) Is the server required to 
>>> collapse the entries for return so the rpc-reply is schema-valid?
>>
> Shouldn't the example F2 be considered as "a  request contains 
> multiple filter subtree expressions that select the same data" and 
> hence the duplicates need to be suppressed?
>

Perhaps.
I implemented the code a bit more literally.
Duplicate sibling selection nodes are eliminated but not duplicate subtrees that contain content-match nodes.

Martin pointed out this text that says a schema is not needed, as an indication that the data returned in the <data> element did not need to be schema-valid

Maybe the server should be able to detect the duplicate subtrees in F2, even without a schema, but maybe if the client asks the same question 3 times, then just answer it 3 times.

Andy

---

From: Xiang Li <[email-masked]>
Date: Thu, 07 May 2015 17:16:58 -0500

> subtrees that contain content-match nodes.
So here "Specific data instances are not duplicated in the response" 
literally
means "duplicated sibling instances"? I think that's fine and it is what I
assumed after reading this paragraph. But then is it  an error if the 
server
suppresses the duplicated subtrees in the response, because the
server did not provide exactly what were asked? Or it is an implementation
specific choice?

Thanks,
-Xiang

---

From: Christian Hopps <[email-masked]>
Date: Sun, 10 May 2015 16:40:16 -0400

I agree as well. In particular I agree with the latter half of:

> Maybe the server should be able to detect the duplicate subtrees in
> F2, even without a schema, but maybe if the client asks the same
> question 3 times, then just answer it 3 times.

Thanks,
Chris.