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

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Jul 2014 14:38:16 +0200

Dear all,

Let me try to bring some closure on this errata 
http://www.rfc-editor.org/errata_search.php?eid=3980
Before proceeding (I want to check with the IESG if this is allowed to 
introduce a new MUST sentence in an errata), I would like to
1. check that text below is the final proposal
2. understand if there is agreement in the WG. Do someone object this 
change?

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_MUST_be included in the filter output.

Regards, Benoit

> I agree that MUST would be better. But I don't think we can/should do thar change in an errata.
>
> On 20 juni 2014 13:57:24 PDT, Randy Presuhn <[email-masked]> wrote:
>> Hi -
>>
>>> From: Benoit Claise <[email-masked]>
>>> Sent: Jun 20, 2014 2:01 AM
>> ...
>>> Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)
>>>
>>> One last check (till mid next week) for everybody in the WG before I
>>> apply this change below to the errata, and accept it.
>> "SHOULD" is no better than "MAY" or "OPTIONAL" from an
>> interoperability perspective.  "MUST" would be much simpler
>> for all concerned.
>>
>> Randy
>>
>> _______________________________________________
>> Netconf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netconf
>
> /martin
> .
>

---

From: [email-masked]
Date: Tue, 15 Jul 2014 08:58:14 +0800

I agree instance identifier MUST be present in output.
/frank

"Netconf" <[email-masked]> 写于 2014-07-14 20:38:16:

> Benoit Claise <[email-masked]> 
> 发件人:  "Netconf" <[email-masked]>
> 
> 2014-07-14 20:38
> 
> 收件人
> 
> Martin Björklund <[email-masked]>, Randy Presuhn 
> <[email-masked]>, "Klement Sekera -X (ksekera - 
> Pantheon Technologies SRO at Cisco)" <[email-masked]>, 
> 
> 抄送
> 
> "[email-masked]" <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> 主题
> 
> Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)
> 
> Dear all,
> 
> Let me try to bring some closure on this errata http://www.rfc-
> editor.org/errata_search.php?eid=3980
> Before proceeding (I want to check with the IESG if this is allowed 
> to introduce a new MUST sentence in an errata), I would like to
change?
>    (e.g., list key leaf), then they MUST be included in the filter 
output.

> On 20 juni 2014 13:57:24 PDT, Randy Presuhn 
<[email-masked]>
> wrote:

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Jul 2014 13:42:00 +0200

But since the original spec did not say clearly such leafs must be
included, I think the only safe bet for a client is to explicitely
request key leafs in the filter - unless we are sure the _every_
implementation actually returns key leafs (and since nobody knows the
number of implementations around, establishing this fact is hard).

/js

-- 
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 Björklund <[email-masked]>
Date: Tue, 15 Jul 2014 14:39:39 +0200

I agree with Juergen. Thus, I think the new text should use MAY instead of MUST. 

On 15 juli 2014 13:42:00 CEST, Juergen Schoenwaelder <[email-masked]> wrote:
>> ZTE Information Security Notice: The information contained in this
>mail (and any attachment transmitted herewith) is privileged and
>confidential and is intended for the exclusive use of the addressee(s).
>If you are not an intended recipient, any disclosure, reproduction,
>distribution or other dissemination or use of the information contained
>is strictly prohibited.  If you have received this mail in error,
>please delete it and notify us immediately.
>> ZTE Information Security Notice: The information contained in this
>mail (and any attachment transmitted herewith) is privileged and
>confidential and is intended for the exclusive use of the addressee(s).
>If you are not an intended recipient, any disclosure, reproduction,
>distribution or other dissemination or use of the information contained
>is strictly prohibited.  If you have received this mail in error,
>please delete it and notify us immediately.
>

/martin

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 15 Jul 2014 14:47:44 +0200

Or.... maybe use MAY and add that if the client wants to be sure that
such leafs are returned, then the client better asks for those leaf explicitly
in the filter.

Bert

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Jul 2014 06:51:21 -0700

> such leafs are returned, then the client better asks for those leaf

So what is the point of this errata?  The client already MAY include
whatever
nodes it wants in the filter. IMO the new text adds no value and clarifies
nothing.

> Bert
Andy

>> On 15 juli 2014 13:42:00 CEST, Juergen Schoenwaelder <
>> [email-masked]> wrote:
>>
>>>>> 2. understand if there is agreement in the WG. Do someone object
>>>>>
>>>> this
>>>
>>>> change?
>>>>
>>>>> 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
>>>
>>>>>     recursively applied to the sibling sets of each selected node.
>>>>>
>>>> The
>>>
>>>>     algorithm continues until all sibling sets in all subtrees
>>>>>
>>>> specified
>>>
>>>>>     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
>>>
>>>>>     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
>>>
>>>>> One last check (till mid next week) for everybody in the WG before
>>>>>
>>>> I
>>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Jul 2014 16:09:33 +0200

> nodes it wants in the filter. IMO the new text adds no value and clarifies

I think the goal was to _encourage_ servers to include key leafs while
making it clear that doing so is not mandatory and hence (b) encourage
clients to explicitely ask for key leafs.

The current text says "MAY also be included" and RFC 2119 tells me
that MAY means that "an item is truly optional". I think we would have
loved this to be a MUST or at least a SHOULD. With the current MAY,
the only safe bet is to ask explicitely for any 'instance identifying
components'.

This kind of stuff is typically material for an implementors
guidelines document. But we do not have one and I doubt it is worth
starting one for this particular issue.

/js

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 15 Jul 2014 16:17:04 +0200

Well, I added text that explains that if a client wnts to be sure that it better
asks for the leafs in its filter

Bert

On 15/07/14 15:51, Andy Bierman wrote:
>
>
>
> On Tue, Jul 15, 2014 at 5:47 AM, Bert Wijnen (IETF) <[email-masked] <mailto:[email-masked]>> wrote:
>
> So what is the point of this errata?  The client already MAY include whatever
> nodes it wants in the filter. IMO the new text adds no value and clarifies nothing.
>
>
>
>     Bert
>
>
> Andy
>
>
>         On 15 juli 2014 13:42:00 CEST, Juergen Schoenwaelder <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             On Tue, Jul 15, 2014 at 08:58:14AM +0800, [email-masked] <mailto:[email-masked]>
>             wrote:
>
>                 "Netconf" <[email-masked] <mailto:[email-masked]>> 写于 2014-07-14 20:38:16:
>
>                     Benoit Claise <[email-masked] <mailto:[email-masked]>>
>                     发件人:  "Netconf" <[email-masked] <mailto:[email-masked]>>
>
>                     2014-07-14 20:38
>
>                     收件人
>
>                     Martin Björklund <[email-masked] <mailto:[email-masked]>>, Randy Presuhn
>                     <[email-masked] <mailto:[email-masked]>>__, "Klement Sekera -X (ksekera -
>                     Pantheon Technologies SRO at Cisco)" <[email-masked] <mailto:[email-masked]>>,
>
>                     抄送
>
>                     "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
>                     "[email-masked] <mailto:[email-masked]>"
>                     <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked]
>                     <mailto:[email-masked]>>
>
>                     主题
>
>                     editor.org/errata_search.php?__eid=3980 <http://editor.org/errata_search.php?eid=3980>
>                 <[email-masked] <mailto:[email-masked]>>
>
>                     wrote:
>
>
>                     Hi -
>
>
>                     From: Benoit Claise <[email-masked] <mailto:[email-masked]>>
>                     _________________________________________________
>                     Netconf mailing list
>                     [email-masked] <mailto:[email-masked]>
>                     https://www.ietf.org/mailman/__listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>
>
>
>
>                     /martin
>                     .
>
>
>                     _________________________________________________
>                     Netconf mailing list
>                     [email-masked] <mailto:[email-masked]>
>                     https://www.ietf.org/mailman/__listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>
>
>                 ------------------------------__--------------------------
>                 ------------------------------__--------------------------
>                 _________________________________________________
>                 Netconf mailing list
>                 [email-masked] <mailto:[email-masked]>
>                 https://www.ietf.org/mailman/__listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>
>
>
>             --
>             Fax:   +49 421 200 3103         <http://www.jacobs-university.__de/ <http://www.jacobs-university.de/>>
>
>             _________________________________________________
>             Netconf mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/__listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>
>
>
>         /martin
>
>         _________________________________________________
>         Netconf mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>
>
>     _________________________________________________
>     Netconf mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>
>

---

From: Xiang Li <[email-masked]>
Date: Tue, 15 Jul 2014 09:33:16 -0500

> starting one for this particular issue.

While I understand Jurgen's point but isn't this an errata item? If it 
is then
I think it needs to be a "MUST". Current implementations out there that 
do not
return key leafs should fix the bug. Otherwise it should not be added as 
an errata here.

--Xiang Li

-- 
--
Xiang Li,
Seguesoft, Champaign, IL
(217) 721-5341

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Jul 2014 07:35:25 -0700

> asks for the leafs in its filter

The subtree filtering is much more useful if the server supplies missing
keys.
(I guess we agree on that).  Consider a simple use-case: there are 10,000
interface
entries and 1 of them is disabled.  Which one?

   <interfaces>
      <interface>
         <enabled>false</enabled>
      </interface>
   </interfaces>

If I add the <name> leaf to the filter, I will get back 10,000 matches.
If I don't, then all I get back is the filter I sent, confirming there is
indeed 1 disabled interface.
The only useful response is to include the <name> leaf for the 1 entry that
matched.

It seems like SHOULD is more appropriate than MAY.  It does not force old
servers to
be non-compliant like MUST.

Andy

>> [email-masked]
>>             On Tue, Jul 15, 2014 at 08:58:14AM +0800,
>> [email-masked] <mailto:[email-masked]>
>>             wrote:
>>
>>                 "Netconf" <[email-masked] <mailto:
>> [email-masked]>> 写于 2014-07-14 20:38:16:
>>
>>                     <[email-masked] <mailto:randy_presuhn@
>> mindspring.com>>__, "Klement Sekera -X (ksekera -
>>                     Pantheon Technologies SRO at Cisco)" <
>> [email-masked] <mailto:[email-masked]>>,
>>
>>                     抄送
>>
>>                     "[email-masked] <mailto:[email-masked]>" <
>> [email-masked] <mailto:[email-masked]>>,
>>                     <[email-masked] <mailto:[email-masked]>>, "
>> [email-masked] <mailto:[email-masked]>" <[email-masked]
>> http://www.rfc-
>>                     editor.org/errata_search.php?__eid=3980 <
>> http://editor.org/errata_search.php?eid=3980>
>>                     I agree that MUST would be better. But I don't think
>> we can/should
>>                     do thar change in an errata.
>>
>>                     https://www.ietf.org/mailman/__listinfo/netconf <
>> https://www.ietf.org/mailman/listinfo/netconf>
>>
>>
>>
>>
>>                     /martin
>>                     .
>>
>>
>>                     https://www.ietf.org/mailman/__listinfo/netconf <
>> https://www.ietf.org/mailman/listinfo/netconf>
>>
>>
>>                 https://www.ietf.org/mailman/__listinfo/netconf <
>> https://www.ietf.org/mailman/listinfo/netconf>
>>
>>
>>
>>             --
>>             Fax:   +49 421 200 3103         <
>> http://www.jacobs-university.__de/ <http://www.jacobs-university.de/>>
>>
>>             https://www.ietf.org/mailman/__listinfo/netconf <
>> https://www.ietf.org/mailman/listinfo/netconf>
>>
>>
>>
>>         /martin
>>
>>         https://www.ietf.org/mailman/__listinfo/netconf <
>> https://www.ietf.org/mailman/listinfo/netconf>
>>
>>
>>     https://www.ietf.org/mailman/__listinfo/netconf <
>> https://www.ietf.org/mailman/listinfo/netconf>
>>
>>
>>

---

From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" <[email-masked]>
Date: Tue, 15 Jul 2014 14:48:05 +0000

Hi Andy,

just to clarify, your filter would select only the one disabled
interface even if you specified the <name> there. All the other
instances would be dropped, since the content-match on <enabled> is
false.

Klement

On Tue, 2014-07-15 at 07:35 -0700, Andy Bierman wrote:
> >> mindspring.com>>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Jul 2014 08:07:33 -0700

On Tue, Jul 15, 2014 at 7:48 AM, Klement Sekera -X (ksekera - Pantheon

> instances would be dropped, since the content-match on <enabled> is
you're right.

been awhile since I implemented this section.
I notice sec. 6.2.5 also has this 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.

Andy

> > > Well, I added text that explains that if a client wnts to be sure that
> it
> > > better
> > >> On Tue, Jul 15, 2014 at 5:47 AM, Bert Wijnen (IETF) <
> [email-masked]
> > >> <mailto:[email-masked]>> wrote:
> > >>
> > >>     such leafs are returned, then the client better asks for those
> leaf
> > >> explicitly
> > >>     in the filter.
> > >>
> > >>
> > >>         I agree with Juergen. Thus, I think the new text should use
> MAY
> > >> instead of MUST.
> > >>
> > >>             implementation actually returns key leafs (and since
> nobody
> > >> knows the
> > >>             number of implementations around, establishing this fact
> is
> > >> hard).
> > >>
> > >>             /js
> > >>
> > >>                     发件人:  "Netconf" <[email-masked]
> <mailto:
> > >> [email-masked]>>
> > >>
> > >>                     2014-07-14 20:38
> > >>
> > >>                     收件人
> > >>
> > >>                     Before proceeding (I want to check with the IESG
> if
> > >> this is allowed
> > >>
> > >>
> > >>                          (or potentially included) in the filter
> output,
> > >> and which
> > >>
> > >>             sibling
> > >>
> > >>                          subtrees are excluded (pruned) from the
> filter
> > >> output.  The
> > >>
> > >>             server
> > >>
> > >>                          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
> > >>
> > >>                          (or potentially included) in the filter
> output,
> > >> and which
> > >>
> > >>             sibling
> > >>
> > >>                          subtrees are excluded (pruned) from the
> filter
> > >> output.  The
> > >>
> > >>             server
> > >>
> > >>                          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
> > >>
> > >>                     One last check (till mid next week) for everybody
> in
> > >> the WG before
> > >>
> > >>             I
> > >>
> > >>                     interoperability perspective.  "MUST" would be
> much
> > >> simpler
> > >>                     for all concerned.
> > >>
> > >>                     Randy
> > >>
> > >>             mail (and any attachment transmitted herewith) is
> privileged
> > >> and
> > >>             distribution or other dissemination or use of the
> information
> > >> contained
> > >>             mail (and any attachment transmitted herewith) is
> privileged
> > >> and
> > >>             distribution or other dissemination or use of the
> information
> > >> contained
> > >>             Phone: +49 421 200 3587         Campus Ring 1, 28759
> Bremen,
> > >> Germany
> > >>             Fax:   +49 421 200 3103         <
> > >> http://www.jacobs-university.__de/ <http://www.jacobs-university.de/
> >>
> > >>