Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)

From: Benoit Claise <[email-masked]>
Date: Wed, 04 Jun 2014 10:24:23 +0200

Dear all,

Is this right?

Regards, B
> The following errata report has been submitted for RFC6241,
> "Network Configuration Protocol (NETCONF)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3980
>
> --------------------------------------
> Type: Technical
> Reported by: Klement Sekera <[email-masked]>
>
> Section: 6.2.5
>
> Original Text
> -------------
> o  If any sibling nodes of the selection node are instance identifier
>     components for a conceptual data structure (e.g., list key leaf),
>     then they MAY also be included in the filter output.
>
> Corrected Text
> --------------
> o  If any sibling nodes of a node are instance identifier
>     components for a conceptual data structure (e.g., list key leaf),
>     then they MAY also be included in the filter output.
>
> Notes
> -----
> The intent is to allow the server to always include the key node values and the wording accidentally does not cover this case.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6241 (draft-ietf-netconf-4741bis-10)
> --------------------------------------
> Title               : Network Configuration Protocol (NETCONF)
> Publication Date    : June 2011
> Author(s)           : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed.
> Category            : PROPOSED STANDARD
> Source              : Network Configuration
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> .
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Jun 2014 11:54:38 +0200

I am not sure since in the new text 'node' is rather unspecified.  For
me, it would help to have a example demonstrating what is broken and
how the proposed change fixes things. Ideally, this should be sent to
the WG mailing list.

/js

On Wed, Jun 04, 2014 at 10:24:23AM +0200, Benoit Claise wrote:
> >The intent is to allow the server to always include the key node values 
> >and the wording accidentally does not cover this case.
> >
> >Instructions:
> >-------------

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 04 Jun 2014 12:24:23 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> me, it would help to have a example demonstrating what is broken

Assume this model:

  container servers {
    list server {
      key name;
      leaf name { ... }
      leaf ip { ... }
      leaf port { ... }
    }
  }

and this data on the server:

  <servers>
    <server>
      <name>foo</name>
      <ip>10.0.0.1</ip>
      <port>80</port>
    </server>
    <server>
      <name>bar</name>
      <ip>10.0.0.1</ip>
      <port>25</port>
    </server>
  </servers>

Now, with this filter:

  <servers>
    <server>
      <port>80</port>
      <ip/>
    </server>
  </server>

It is, according to 6241, ok to return:

  <servers>
    <server>
      <name>foo</name>
      <ip>10.0.0.1</ip>
      <port>80</port>
    </server>
  </servers>

(because 'name' is a sibling to the selection node 'ip')

However, with this filter:

  <servers>
    <server>
      <port>80</port>
    </server>
  </server>

a strict interpretation of 6241 seems to suggest that this is illegal
to return:

  <servers>
    <server>
      <name>foo</name>
      <port>80</port>
    </server>
  </servers>

... but that doesn't make much sense.

The intention of the text was to allow keys to be inserted everywhere
in the returned subtrees.

This said, I am not convinced the proposed change fixes this.  The
subtree filter specification text is pretty difficult to interpret...

> and

This thread is sent to the WG ML.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Jun 2014 12:31:09 +0200

> subtree filter specification text is pretty difficult to interpret...

So any key leafs that are child nodes of any Containment Nodes of
the Subtree Filter can be added? Would that be more accurate?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 04 Jun 2014 12:38:55 +0200 (CEST)

> the Subtree Filter can be added? Would that be more accurate?

I think so, but the current text is in section 6.2.5 which talks about
content match nodes.  This is a bit confusing - what happens if you
don't have any content match nodes?

Your sentence belongs to text that discuss subtree filter in general,
maybe somewhere in section 6.3.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Jun 2014 14:11:54 +0200

> maybe somewhere in section 6.3.

Yes, that makes sense to me.

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 19 Jun 2014 11:59:09 +0200

Klement,

Are you fine with this resolution below.
If yes, please update the errata.
If you don't have the right to do, I can do. In this case, provide 
OLD/NEW text.

Regards, Benoit

---

From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" <[email-masked]>
Date: Thu, 19 Jun 2014 12:39:18 +0000

Hi Benoit,

I don't think I can.

If this should be put into section 6.3, then I'd add to this block of
text:

OLD:
   For each sibling set, the server determines which nodes are included
   (or potentially included) in the filter output, and which sibling
   subtrees are excluded (pruned) from the filter output.  The server
   first determines which types of nodes are present in the sibling set
   and processes the nodes according to the rules for their type.  If
   any nodes in the sibling set are selected, then the process is
   recursively applied to the sibling sets of each selected node.  The
   algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed.

NEW:
   For each sibling set, the server determines which nodes are included
   (or potentially included) in the filter output, and which sibling
   subtrees are excluded (pruned) from the filter output.  The server
   first determines which types of nodes are present in the sibling set
   and processes the nodes according to the rules for their type.  If
   any nodes in the sibling set are selected, then the process is
   recursively applied to the sibling sets of each selected node.  The
   algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed. If any sibling nodes of a node 
   are instance identifier components for a conceptual data structure 
   (e.g., list key leaf), then they MAY be included in the filter output.

Ragards,
Klement

---

From: Benoit Claise <[email-masked]>
Date: Thu, 19 Jun 2014 15:06:35 +0200

Martin, Jürgen, WG,

Fine with this?

Regards, B.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jun 2014 07:55:04 -0700

> Fine with this?

Not really.
Why is the requirement to add key leafs a MAY instead of a MUST or SHOULD?
It seems like subtree filters need to be implemented in a consistent manner
to make them really useful.

Andy

---

From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" <[email-masked]>
Date: Fri, 20 Jun 2014 07:32:16 +0000

Adding keys allows the client to identify separate list entities. The
client should be bright enough to request the keys, but if he does not,
a server implementation which is smart enough could supply them
automatically - since without them, most replys would probably be
unusable. But I can imagine a limited environment, where cpu/memory is
scarce and the netconf server could be as simple as possible. Therefore,
I proposed MAY instead of MUST.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 20 Jun 2014 10:06:34 +0200

Klement,

Based on your reasoning, SHOULD is appropriate.
 From RFC 2119:

    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
        may exist valid reasons in particular circumstances to ignore a
        particular item, but the full implications must be understood and
        carefully weighed before choosing a different course.

Regards, Benoit

---

From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" <[email-masked]>
Date: Fri, 20 Jun 2014 08:54:38 +0000

SHOULD instead of MAY is fine.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 20 Jun 2014 11:01:05 +0200

One last check (till mid next week) for everybody in the WG before I 
apply this change below to the errata, and accept it.

Regards, Benoit

---

From: Martin Björklund <[email-masked]>
Date: Fri, 20 Jun 2014 07:09:03 -0700

I don't think SHOULD is appropriate. The existing text uses MAY, and the errata is supposed to clarify in which situations the server is allowed to add keys. The errata is not about changing a MAY to SHOULD. 

On 20 juni 2014 02:01:05 PDT, Benoit Claise <[email-masked]> wrote:
>>>>>>>>>>>> Juergen Schoenwaelder
><[email-masked]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I am not sure since in the new text 'node' is rather
>unspecified.
>>>>>>>>>>>>>    For

/martin

---

From: Benoit Claise <[email-masked]>
Date: Fri, 20 Jun 2014 16:58:37 +0200

Can you please provide some text.

Regards, B.