Subject: Re: [Netconf] subtree filter normalization

From: Martin Bjorklund <[email-masked]>
Date: Fri, 10 Apr 2015 08:21:16 +0200 (CEST)

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>

> 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">
>        <top xmlns="http://example.com/schema/1.2/config">
>          <users>
>            <user>
>              <name>fred</name>
>            </user>
>          </users>
>          </users>
>            <user>
>              <name>fred</name>
>            </user>
>          </users>
>        </top>
>      </filter>
> 
> F4: variant of F2
>    <filter type="subtree">
>        <top xmlns="http://example.com/schema/1.2/config">
>          <users>
>            <user>
>              <name>fred</name>
>            </user>
>          </users>
>        </top>
>       <top xmlns="http://example.com/schema/1.2/config">
>          <users>
>            <user>
>              <name>barney</name>
>            </user>
>          </users>
>        </top>
>      </filter>

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Apr 2015 19:14:52 -0700

> the <user>s into a single <users> element, is to utilize the fact that

Right.  Also applies to some other details:
   - generate list keys first
   - generate identityref
   - generate instance-identifier

I think the client would prefer schema-valid data,
so if the server can understand the schema, it should
figure out how to normalize the data and remove duplicates.

   <filter>
      <users />
       <users>
          <user>
            <name>fred<.name>
          </user>
       </users>
   </filter>

It would be OK for the server to return all user entries
then return the entry for 'fred' again?

I guess this could be called garbage-in/garbage-out
and not a problem.  A future RFC update should
add examples that do not follow the example schema,
and make it clear this is mandatory to support..

Andy