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

From: Benoit Claise <[email-masked]>
Date: Mon, 22 Sep 2014 12:39:10 +0200

Dear all,

Let me come back to this errata 
http://www.rfc-editor.org/errata_search.php?eid=3980
I have some difficulties to draw the conclusion...

Regards, Benoit
>
>
>
> On Tue, Jul 15, 2014 at 7:48 AM, Klement Sekera -X (ksekera - Pantheon 
> Technologies SRO at Cisco) <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>
> 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
>
>     Klement
>
>     On Tue, 2014-07-15 at 07:35 -0700, Andy Bierman wrote:
>     > On Tue, Jul 15, 2014 at 7:17 AM, Bert Wijnen (IETF)
>     <[email-masked] <mailto:[email-masked]>>
>     > wrote:
>     >
>     > > Well, I added text that explains that if a client wnts to be
>     sure that it
>     > > better
>     > > 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.
>     >
>     >
>     > > Bert
>     > >
>     >
>     > Andy
>     >
>     >
>     > >
>     > > 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]>
>     > >> <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>     > >>
>     > >>     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.
>     > >>
>     > >>
>     > >> 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/07/14 14:39, Martin Björklund wrote:
>     > >>
>     > >>         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]
>     <mailto:[email-masked]>
>     > >>         <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     > >>
>     > >>             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
>     > >>
>     > >>             On Tue, Jul 15, 2014 at 08:58:14AM +0800,
>     > >> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     > >>             wrote:
>     > >>
>     > >>                 I agree instance identifier MUST be present
>     in output.
>     > >>                 /frank
>     > >>
>     > >>
>     > >>                 "Netconf" <[email-masked]
>     <mailto:[email-masked]> <mailto:
>     > >> [email-masked] <mailto:[email-masked]>>>
>     ?? 2014-07-14 20:38:16:
>     > >>
>     > >>                     Benoit Claise <[email-masked]
>     <mailto:[email-masked]> <mailto:
>     > >> [email-masked] <mailto:[email-masked]>>>
>     > >>                     ???:  "Netconf" <[email-masked]
>     <mailto:[email-masked]> <mailto:
>     > >> [email-masked] <mailto:[email-masked]>>>
>     > >>
>     > >>                     2014-07-14 20:38
>     > >>
>     > >>                     ???
>     > >>
>     > >>                     Martin Björklund <[email-masked]
>     <mailto:[email-masked]> <mailto:
>     > >> [email-masked] <mailto:[email-masked]>>>, Randy Presuhn
>     > >>                     <[email-masked]
>     <mailto:[email-masked]> <mailto:randy_presuhn@
>     <mailto:randy_presuhn@>
>     > >> mindspring.com <http://mindspring.com>>>__, "Klement Sekera
>     -X (ksekera -
>     > >>                     Pantheon Technologies SRO at Cisco)" <
>     > >> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>,
>     > >>
>     > >>                     ??
>     > >>
>     > >>                     "[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>" <
>     > >> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>,
>     > >>                     "[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>"
>     > >>                     <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>, "
>     > >> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>"
>     <[email-masked] <mailto:[email-masked]>
>     > >>                     <mailto:[email-masked]
>     <mailto:[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
>     <http://editor.org/errata_search.php?__eid=3980> <
>     > >> http://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]
>     <mailto:[email-masked]> <mailto:randy_presuhn@
>     <mailto:randy_presuhn@>
>     > >> mindspring.com <http://mindspring.com>>>
>     > >>
>     > >>                     wrote:
>     > >>
>     > >>
>     > >>                     Hi -
>     > >>
>     > >>
>     > >>                     From: Benoit Claise <[email-masked]
>     <mailto:[email-masked]> <mailto:
>     > >> [email-masked] <mailto:[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] <mailto:[email-masked]>
>     <mailto:[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]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     > >> https://www.ietf.org/mailman/__listinfo/netconf <
>     > >> https://www.ietf.org/mailman/listinfo/netconf>
>     > >>
>     > >>
>     > >> ------------------------------
>     > >> __--------------------------
>     > >>                 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.
>     > >>
>     > >> _________________________________________________
>     > >>                 Netconf mailing list
>     > >> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     > >> https://www.ietf.org/mailman/__listinfo/netconf <
>     > >> https://www.ietf.org/mailman/listinfo/netconf>
>     > >>
>     > >>
>     > >>
>     > >>             --
>     > >>             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/
>     <http://www.jacobs-university.de/>>
>     > >>
>     > >> _________________________________________________
>     > >>             Netconf mailing list
>     > >> [email-masked] <mailto:[email-masked]>
>     <mailto:[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]>
>     <mailto:[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]>
>     <mailto:[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
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf