From nobody Tue Apr 3 03:57:32 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E9012E89A for ; Tue, 3 Apr 2018 03:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXCg1vXXwVnA for ; Tue, 3 Apr 2018 03:57:28 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0CD12E899 for ; Tue, 3 Apr 2018 03:57:28 -0700 (PDT) Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id AC4371AE0312; Tue, 3 Apr 2018 12:57:26 +0200 (CEST) Date: Tue, 03 Apr 2018 12:57:25 +0200 (CEST) Message-Id: <20180403.125725.1554298520008064611.mbj@tail-f.com> To: otilibil@eurecom.fr Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180326131751.28bgdvrf8kokc4k4@webmail.eurecom.fr> References: <20180326131751.28bgdvrf8kokc4k4@webmail.eurecom.fr> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Comments on draft-ietf-netmod-schema-mount-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 10:57:30 -0000 Hi, Thank you for your review. Comments inline. otilibil@eurecom.fr wrote: > Hi members, > > I comment on that draft: > > * Instead of "it is often necessary that an existing module (or a set of modules) is added to the data model starting at a non-root location", this would read better: "it is often necessary that an existing module (or a set of modules) be added to the data model at locations other than the root." (Section 1) Ok, fixed. > * 'The "mount-point" statement MUST NOT be used in a YANG version 1 module' Why this documents keeps YANG 1 off from its scope? (Section 3.1) The reason for this is that otherwise it is not possible to invoke mounted RPC operations, and receive mounted notifications. I have clarified this in the text. > * 'Specifically, a server that doesn?t support the NMDA, MAY implement revision 2016-06-21 of "ietf-yang-library" [RFC7950] under a mount point' [RFC7895] defines "ietf-yang-library", not [RFC7950] (Section 6) Fixed. > * Why not "Tree Diagram" instead of "Data Model"? The wording has become a Best Practice (Section 8) I don't think I have seen "Tree Diagram" as the title of such a section. See e.g. RFC 8344. > * Idem, "This document...has the following diagram" captures better the Best Practice than "This document...has the following structure" (Section 8) The full text is: This document defines the YANG 1.1 module [RFC7950] "ietf-yang-schema-mount", which has the following structure: it says that the *module* has a structure. > * Same remark on restricting to YANG 1.1: "The ?mount-point? statement MUST NOT be used in a YANG version 1 module, neither explicitly nor via a ?uses? statement (description of the extension "mount-point") See above. > * Should this sentence refers only to [RFC6020]? "This document registers a YANG module in the YANG Module Names registry [RFC6020]" (Section 10) This is correct. > * The document cites /schema-mounts as "The schema defined by this state data provides detailed information about a server implementation may help an attacker identify the server capabilities and server implementations with known bugs" I think this section should warn also on: > ** Section 2.1.2 and 4 of [RFC7895] (the list 'module' contains the leaf 'schema': from which anyone may retrieve a YANG module) > ** Section 3 of [RFC6022] (it defines the RPC 'get-schema'; with which anyone may get a YANG module) > ** and Section 5 of [RFC8341] (reminding administrators to set user rights accordingly, and giving their defaults values). There is an ongoing discussion about adding text re. mounted modules and how NACM is used to protect them. I think this needs to be handled in a generic way, rather than listing some mounted modules. /martin > > Regards, > Ariel > > [RFC6020] https://tools.ietf.org/html/rfc6020 > [RFC7895] https://tools.ietf.org/html/rfc7895 > [RFC7950] https://tools.ietf.org/html/rfc7950 > [RFC8341] https://tools.ietf.org/html/rfc8341 > > > ------------------------------------------------------------------------------- > This message was sent using EURECOM Webmail: http://webmail.eurecom.fr > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Apr 3 05:17:16 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F24127522 for ; Tue, 3 Apr 2018 05:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mA7SxcFz7dw for ; Tue, 3 Apr 2018 05:17:11 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 77AC81204DA for ; Tue, 3 Apr 2018 05:17:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.48,400,1517871600"; d="scan'208";a="7875511" Received: from thorgal.eurecom.fr ([10.3.2.220]) by drago2i.eurecom.fr with ESMTP; 03 Apr 2018 14:17:10 +0200 Received: (from apache@localhost) by thorgal.eurecom.fr (8.14.4+Sun/8.14.4/Submit) id w33CHAsU008222; Tue, 3 Apr 2018 14:17:10 +0200 (CEST) X-Authentication-Warning: thorgal.eurecom.fr: apache set sender to otilibil@eurecom.fr using -f Received: from reverse.completel.net (reverse.completel.net [92.103.89.82]) by webmail.eurecom.fr (Horde MIME library) with HTTP; Tue, 03 Apr 2018 14:17:10 +0200 Message-ID: <20180403141710.68ok0uv00s0kggk0@webmail.eurecom.fr> Date: Tue, 03 Apr 2018 14:17:10 +0200 From: otilibil@eurecom.fr To: Martin Bjorklund Cc: netmod@ietf.org References: <20180326131751.28bgdvrf8kokc4k4@webmail.eurecom.fr> <20180403.125725.1554298520008064611.mbj@tail-f.com> In-Reply-To: <20180403.125725.1554298520008064611.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) X-Originating-IP: 92.103.89.82 X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36 Archived-At: Subject: Re: [netmod] Comments on draft-ietf-netmod-schema-mount-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 12:17:14 -0000 Thanks, Martin; A question in line: Regards, Ariel Quoting Martin Bjorklund : > Hi, > > Thank you for your review. Comments inline. > > otilibil@eurecom.fr wrote: >> Hi members, >> >> I comment on that draft: >> >> * Instead of "it is often necessary that an existing module (or a =20 >> set of modules) is added to the data model starting at a non-root =20 >> location", this would read better: "it is often necessary that an =20 >> existing module (or a set of modules) be added to the data model at =20 >> locations other than the root." (Section 1) > > Ok, fixed. > >> * 'The "mount-point" statement MUST NOT be used in a YANG version 1 =20 >> module' Why this documents keeps YANG 1 off from its scope? =20 >> (Section 3.1) > > The reason for this is that otherwise it is not possible to invoke > mounted RPC operations, and receive mounted notifications. I have > clarified this in the text. > >> * 'Specifically, a server that doesn?t support the NMDA, MAY =20 >> implement revision 2016-06-21 of "ietf-yang-library" [RFC7950] =20 >> under a mount point' [RFC7895] defines "ietf-yang-library", not =20 >> [RFC7950] (Section 6) > > Fixed. > >> * Why not "Tree Diagram" instead of "Data Model"? The wording has =20 >> become a Best Practice (Section 8) > > I don't think I have seen "Tree Diagram" as the title of such a > section. See e.g. RFC 8344. > >> * Idem, "This document...has the following diagram" captures better =20 >> the Best Practice than "This document...has the following =20 >> structure" (Section 8) > > The full text is: > > This document defines the YANG 1.1 module [RFC7950] > "ietf-yang-schema-mount", which has the following structure: > > it says that the *module* has a structure. > >> * Same remark on restricting to YANG 1.1: "The ?mount-point? =20 >> statement MUST NOT be used in a YANG version 1 module, neither =20 >> explicitly nor via a ?uses? statement (description of the extension =20 >> "mount-point") > > See above. > >> * Should this sentence refers only to [RFC6020]? "This document =20 >> registers a YANG module in the YANG Module Names registry =20 >> [RFC6020]" (Section 10) > > This is correct. > >> * The document cites /schema-mounts as "The schema defined by this =20 >> state data provides detailed information about a server =20 >> implementation may help an attacker identify the server =20 >> capabilities and server implementations with known bugs" I think =20 >> this section should warn also on: >> ** Section 2.1.2 and 4 of [RFC7895] (the list 'module' contains =20 >> the leaf 'schema': from which anyone may retrieve a YANG module) >> ** Section 3 of [RFC6022] (it defines the RPC 'get-schema'; with =20 >> which anyone may get a YANG module) >> ** and Section 5 of [RFC8341] (reminding administrators to set =20 >> user rights accordingly, and giving their defaults values). > > There is an ongoing discussion about adding text re. mounted modules > and how NACM is used to protect them. I think this needs to be > handled in a generic way, rather than listing some mounted modules. > I find the [RFC6022], [RFC7895], and [RFC8341] worth to be mentioned =20 in the Security Considerations. Does the discussion intend to include =20 them in that section? > > /martin > > > >> >> Regards, >> Ariel >> >> [RFC6020] https://tools.ietf.org/html/rfc6020 >> [RFC7895] https://tools.ietf.org/html/rfc7895 >> [RFC7950] https://tools.ietf.org/html/rfc7950 >> [RFC8341] https://tools.ietf.org/html/rfc8341 >> >> >> -------------------------------------------------------------------------= ------ >> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > ----------------------------------------------------------------------------= --- This message was sent using EURECOM Webmail: http://webmail.eurecom.fr From nobody Tue Apr 3 07:37:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FFE127863 for ; Tue, 3 Apr 2018 07:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkHQLMFnIaTy for ; Tue, 3 Apr 2018 07:37:54 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BECC127735 for ; Tue, 3 Apr 2018 07:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3067; q=dns/txt; s=iport; t=1522766274; x=1523975874; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=NAoTRag7zRy6TdSzBby8gwj6d/SsNFgQtiLi0zygXkE=; b=bbo/feBxIvpJnVV5u/dhHZ5Y3Q39eejMLGUF58RLhP7ngRCKCkgxX7Yv 6eGm8VTyrv5k/BAkaUxJte6WDxyZNmVku6HCE7j4pTZkNIBjtOkZ1TTIk +DXiKvfQwHzbfpOn6snTSxxWtfx2c34Ev8DLf3qmgSrWAWx6O21svFSy6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAACLkMNa/xbLJq1ZBBkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGEI28og1+IAF6NcimBD4sSh0OBegsYC4QVSwKEYTQYAQI?= =?us-ascii?q?BAQEBAQECayiFIwEBAQMBASEPAQU2CxAJAhgCAiYCAicwEwYCAQGFCQ+RPJs?= =?us-ascii?q?8ghyEVYNvgiWBCYgsP4EugjQugmYrAQGBUlaCNIJUAocikBkIhVKCTYYKBoE?= =?us-ascii?q?wOoMfgjeEd4kVgUuFHYElHDiBUjMaCBsVOoJDCZBFPjCOPQEB?= X-IronPort-AV: E=Sophos;i="5.48,401,1517875200"; d="scan'208";a="2926555" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2018 14:37:52 +0000 Received: from [10.63.23.169] (dhcp-ensft1-uk-vla370-10-63-23-169.cisco.com [10.63.23.169]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w33EbpnV014618; Tue, 3 Apr 2018 14:37:52 GMT To: otilibil@eurecom.fr References: <20180330164544.pazut2dfxc08840w@webmail.eurecom.fr> From: Robert Wilton Cc: netmod@ietf.org Message-ID: <40e7e93c-c112-78a1-647c-1f30b95cd689@cisco.com> Date: Tue, 3 Apr 2018 15:37:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180330164544.pazut2dfxc08840w@webmail.eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Fwd: Re: How to grep through a YANG? With grepyang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 14:37:57 -0000 Hi Ariel, This looks like an interesting/useful tool. Have you considered hooking into pyang as a pyang extension? pyang is one of the defacto standard tools that folks interacting with yang often use.  If your aim to get widespread usage of your tool making it a pyang extension may be one way to achieve that. E.g. this would then allow your tool to generate tree output for selected yang subtree(s) nodes that you find, or other nice things. Thanks, Rob On 30/03/2018 15:45, otilibil@eurecom.fr wrote: > Hi all, > grepyang has got a new feature: it could grep for a node through a > module: > > # ./grepyang cancel-commit ietf-netconf@2011-06-01.yang > 853:  rpc cancel-commit { > 854:    if-feature confirmed-commit; > 855:    description > 856:      "This operation is used to cancel an ongoing confirmed commit. > 857:       If the confirmed commit is persistent, the parameter > 858:       'persist-id' must be given, and it must match the value of the > 859:       'persist' parameter."; > 860:    reference "RFC 6241, Section 8.4.4.1"; > 861: > 862:    input { > 863:      leaf persist-id { > 864:        type string; > 865:        description > 866:          "This parameter is given in order to cancel a persistent > 867:           confirmed commit.  The value must be equal to the value > 868:           given in the 'persist' parameter to the > operation. > 869:           If it does not match, the operation fails with an > 870:          'invalid-value' error."; > 871:      } > 872:    } > 873:  } > > Now it can grep for a node with a greped node: > > # ./grepyang input cancel-commit ietf-netconf@2011-06-01.yang > 853:  rpc cancel-commit { > 862:    input { > 863:      leaf persist-id { > 864:        type string; > 865:        description > 866:          "This parameter is given in order to cancel a persistent > 867:           confirmed commit.  The value must be equal to the value > 868:           given in the 'persist' parameter to the > operation. > 869:           If it does not match, the operation fails with an > 870:          'invalid-value' error."; > 871:      } > 872:    } > 873:  } > > pyang lacks such features; that's why I have been working on grepyang. > > It is out on Github (https://github.com/ariel-anieli/grepyang); feel > free to play around with it. > > If you find it of any interest, have some remarks, or see it needs > enhancements; please,  do so: I will work on the issues. > > Regards, > Ariel > > ------------------------------------------------------------------------------- > > This message was sent using EURECOM Webmail: http://webmail.eurecom.fr > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Apr 3 07:56:11 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D053812E86D for ; Tue, 3 Apr 2018 07:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUBKFJ3MRr5m for ; Tue, 3 Apr 2018 07:56:07 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id C87A3127AD4 for ; Tue, 3 Apr 2018 07:56:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.48,401,1517871600"; d="scan'208";a="7876667" Received: from thorgal.eurecom.fr ([10.3.2.220]) by drago2i.eurecom.fr with ESMTP; 03 Apr 2018 16:56:05 +0200 Received: (from apache@localhost) by thorgal.eurecom.fr (8.14.4+Sun/8.14.4/Submit) id w33Eu5xj009001; Tue, 3 Apr 2018 16:56:05 +0200 (CEST) X-Authentication-Warning: thorgal.eurecom.fr: apache set sender to otilibil@eurecom.fr using -f Received: from reverse.completel.net (reverse.completel.net [92.103.89.82]) by webmail.eurecom.fr (Horde MIME library) with HTTP; Tue, 03 Apr 2018 16:56:05 +0200 Message-ID: <20180403165605.2c9o1mru8ssg0w4c@webmail.eurecom.fr> Date: Tue, 03 Apr 2018 16:56:05 +0200 From: otilibil@eurecom.fr To: Robert Wilton Cc: netmod@ietf.org References: <20180330164544.pazut2dfxc08840w@webmail.eurecom.fr> <40e7e93c-c112-78a1-647c-1f30b95cd689@cisco.com> In-Reply-To: <40e7e93c-c112-78a1-647c-1f30b95cd689@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) X-Originating-IP: 92.103.89.82 X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36 Archived-At: Subject: Re: [netmod] Fwd: Re: How to grep through a YANG? With grepyang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 14:56:10 -0000 Hi Rob, My answers inline. Regards, Ariel Quoting Robert Wilton : > Hi Ariel, > > This looks like an interesting/useful tool. > > Have you considered hooking into pyang as a pyang extension? Till today, no; grpeyang is still a rush, needing improvements and =20 cleanups. You suggested a nice idea, indeed. > pyang is one of the defacto standard tools that folks interacting with > yang often use.=C2=A0 If your aim to get widespread usage of your tool > making it a pyang extension may be one way to achieve that. E.g. this > would then allow your tool to generate tree output for selected yang > subtree(s) nodes that you find, or other nice things. Thanks for your feedback, Rob. Then, I will read through the code of =20 pyang, and check the dependencies, if they are any. Who manages the =20 Github repository? > > Thanks, > Rob > > > On 30/03/2018 15:45, otilibil@eurecom.fr wrote: >> Hi all, >> grepyang has got a new feature: it could grep for a node through a module= : >> >> # ./grepyang cancel-commit ietf-netconf@2011-06-01.yang >> 853:=C2=A0 rpc cancel-commit { >> 854:=C2=A0=C2=A0=C2=A0 if-feature confirmed-commit; >> 855:=C2=A0=C2=A0=C2=A0 description >> 856:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "This operation is used to cancel an o= ngoing confirmed commit. >> 857:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the confirmed commit is persi= stent, the parameter >> 858:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 'persist-id' must be given, and = it must match the value of the >> 859:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 'persist' parameter."; >> 860:=C2=A0=C2=A0=C2=A0 reference "RFC 6241, Section 8.4.4.1"; >> 861: >> 862:=C2=A0=C2=A0=C2=A0 input { >> 863:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf persist-id { >> 864:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type string; >> 865:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description >> 866:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "This paramete= r is given in order to cancel a persistent >> 867:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 confirme= d commit.=C2=A0 The value must be equal to the value >> 868:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 given in= the 'persist' parameter to the operation. >> 869:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If it do= es not match, the operation fails with an >> 870:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 'invalid-value= ' error."; >> 871:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> 872:=C2=A0=C2=A0=C2=A0 } >> 873:=C2=A0 } >> >> Now it can grep for a node with a greped node: >> >> # ./grepyang input cancel-commit ietf-netconf@2011-06-01.yang >> 853:=C2=A0 rpc cancel-commit { >> 862:=C2=A0=C2=A0=C2=A0 input { >> 863:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf persist-id { >> 864:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type string; >> 865:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description >> 866:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "This paramete= r is given in order to cancel a persistent >> 867:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 confirme= d commit.=C2=A0 The value must be equal to the value >> 868:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 given in= the 'persist' parameter to the operation. >> 869:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If it do= es not match, the operation fails with an >> 870:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 'invalid-value= ' error."; >> 871:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> 872:=C2=A0=C2=A0=C2=A0 } >> 873:=C2=A0 } >> >> pyang lacks such features; that's why I have been working on grepyang. >> >> It is out on Github (https://github.com/ariel-anieli/grepyang); =20 >> feel free to play around with it. >> >> If you find it of any interest, have some remarks, or see it needs =20 >> enhancements; please,=C2=A0 do so: I will work on the issues. >> >> Regards, >> Ariel >> >> -------------------------------------------------------------------------= ------ This message was sent using EURECOM Webmail: =20 >> http://webmail.eurecom.fr >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . >> ----------------------------------------------------------------------------= --- This message was sent using EURECOM Webmail: http://webmail.eurecom.fr From nobody Tue Apr 3 08:06:01 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BB7127863 for ; Tue, 3 Apr 2018 08:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3hpJHaqC9mb for ; Tue, 3 Apr 2018 08:05:56 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254091.outbound.protection.outlook.com [40.92.254.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85BAA120724 for ; Tue, 3 Apr 2018 08:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ny6xxqmnsr1JrrHHRw+PQFkiRMwDE5YMbV0TC0qcuWQ=; b=Eldi7m2jA3NW+9EgfBwjKQ1KSKhYUwgX1q+bvW+34JxABl3wMII2MBPve56JkSX4k6UVX/CB9VU+EvXvz57op7PD2Uf5NEkJ+zAx+7k7o4/+WrNcyPIxGz3XJmj2Cs0+lZ9Q/qSxUyoj4L9ubYqf3J9ly8fwkbOQ18IW+NRdqE67WMnXfy5RF5N+2DFtwcm0Awo2Nln8cCLhmG28gTZl8hkQ/gq08XaG2Qptz5D4ru9LlQ2sEAm987Lb9vXK8XzV8BXq2pkVvZpMabySQus+5CCtWCaO4vxdHUtYM7xFs+yuJ208TKaiIbgi+0chy35PkT4+6fjYe6hsI2/5dPw5XQ== Received: from HK2APC01FT005.eop-APC01.prod.protection.outlook.com (10.152.248.51) by HK2APC01HT131.eop-APC01.prod.protection.outlook.com (10.152.249.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.8; Tue, 3 Apr 2018 15:05:53 +0000 Received: from HK2PR0401MB1265.apcprd04.prod.outlook.com (10.152.248.53) by HK2APC01FT005.mail.protection.outlook.com (10.152.248.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.631.7 via Frontend Transport; Tue, 3 Apr 2018 15:05:53 +0000 Received: from HK2PR0401MB1265.apcprd04.prod.outlook.com ([fe80::2db2:49db:7b47:d80]) by HK2PR0401MB1265.apcprd04.prod.outlook.com ([fe80::2db2:49db:7b47:d80%4]) with mapi id 15.20.0653.012; Tue, 3 Apr 2018 15:05:53 +0000 From: Rohit Ranade To: Martin Bjorklund CC: "netmod@ietf.org" Thread-Topic: [netmod] Comments on schema mount draft Thread-Index: AQHTxDbT1I3AIjMZP0GUUq533JigqqPiK6iAgAIEP92AAqcggIAIV7nq Date: Tue, 3 Apr 2018 15:05:53 +0000 Message-ID: References: <20180326.101129.936165036878075905.mbj@tail-f.com> , <20180329.092953.1063547768163198657.mbj@tail-f.com> In-Reply-To: <20180329.092953.1063547768163198657.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:2BEFC24E9939EE2E7B095A4AFF07FA838904F4A931A54E4F271D64BC85D897E8; UpperCasedChecksum:FE5396F318A04A5CA8DA40C89A099BBA032F888335E02B0B5DBF429C8A49F577; SizeAsReceived:7292; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [TyBBOQLnnzBuvQZSOOXQ5deAlxWPt7Zbf/+YpjnWC+o=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK2APC01HT131; 7:0DW9yiV/4OfsfZ0/eLO6YIz2XdthCT8egav6YfzSKZHzDwi4MkGn5pi+2k3wakznn02DLKhQBY8Rps7QUOavq3saN3a8itY8oKYMaVTMbnHEsx+0XFALGxif1UiFcalSu4ctZmoUNJm9sKD62ygInUrp6H27LZzxf3pKQcut5eJiZWAvnYeviiHIkXYBiM2/QXdI1cyz0dXTyAyUXrvu7A8mh+Kc1sUUXrKIjdIwqDYMv8jtlZ4NmrkLbRN12yL0 x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:HK2APC01HT131; x-ms-traffictypediagnostic: HK2APC01HT131: x-ms-office365-filtering-correlation-id: dfef127d-bab7-4018-4e68-08d5997464f9 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HK2APC01HT131; BCL:0; PCL:0; RULEID:; SRVR:HK2APC01HT131; x-forefront-prvs: 0631F0BC3D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT131; H:HK2PR0401MB1265.apcprd04.prod.outlook.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: QgjyA1ei+NuBcIYJ4FKXVylnpTenecmjIopYpTrmBuUT8GNwbwKMcBHTHAEvwVK3RUoyYKTuD5m+4SvdAi6bXcvofYw/KcG8G+w+O5zyEBiqtiI/Y+7tsz9GmNNRc3lk38tG/DGtwmPl4IVnUyuDtncJgDpzSyrg/A4k6bHKga4qWnw46zmSy4hoUKkGH8rl spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_KL1PR0401MB12720644E171A6A8AC738545DBA50KL1PR0401MB1272_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dfef127d-bab7-4018-4e68-08d5997464f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2018 15:05:53.1699 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT131 Archived-At: Subject: Re: [netmod] Comments on schema mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 15:06:01 -0000 --_000_KL1PR0401MB12720644E171A6A8AC738545DBA50KL1PR0401MB1272_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluLA0KDQoNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJlc3BvbnNlcy4NCg0KSSBoYXZl IGdvbmUgdGhyb3VnaCB0aGUgTE5FIGRyYWZ0IGFuZCBZQU5HIDEuMSBhbmQgZm91bmQgc29tZSBt b3JlIHN1Z2dlc3Rpb25zLg0KDQoNCg0KMS4gU2VjdGlvbiA1DQoNCiAgICJJZiBhIG1vdW50ZWQg WUFORyBtb2R1bGUgZGVmaW5lcyBhbiBSUEMgb3BlcmF0aW9uLCBjbGllbnRzIGNhbiBpbnZva2UN Cg0KICAgdGhpcyBvcGVyYXRpb24gYXMgaWYgaXQgd2VyZSBkZWZpbmVkIGFzIGFuIGFjdGlvbiBm b3IgdGhlDQoNCiAgIGNvcnJlc3BvbmRpbmcgbW91bnQgcG9pbnQiDQoNCiAgID09PiBCZWxvdyBp cyB0aGUgZXhhbXBsZSBmcm9tIFlhbmcgMS4xIFNlY3Rpb24gNy4xNQ0KDQoNCg0KICAgIDxycGMg bWVzc2FnZS1pZD0iMTAxIg0KDQogICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6 bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQoNCiAgICAgICA8YWN0aW9uIHhtbG5zPSJ1cm46aWV0Zjpw YXJhbXM6eG1sOm5zOnlhbmc6MSI+DQoNCiAgICAgICAgIDxzZXJ2ZXIgeG1sbnM9InVybjpleGFt cGxlOnNlcnZlci1mYXJtIj4NCg0KICAgICAgICAgICA8bmFtZT5hcGFjaGUtMTwvbmFtZT4NCg0K ICAgICAgICAgICA8cmVzZXQ+DQoNCiAgICAgICAgICAgICA8cmVzZXQtYXQ+MjAxNC0wNy0yOVQx Mzo0MjowMFo8L3Jlc2V0LWF0Pg0KDQogICAgICAgICAgIDwvcmVzZXQ+DQoNCiAgICAgICAgIDwv c2VydmVyPg0KDQogICAgICAgPC9hY3Rpb24+DQoNCiAgICAgPC9ycGM+DQoNCg0KDQogICAgIDxy cGMtcmVwbHkgbWVzc2FnZS1pZD0iMTAxIg0KDQogICAgICAgICAgICAgICAgeG1sbnM9InVybjpp ZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQoNCiAgICAgICA8cmVzZXQtZmlu aXNoZWQtYXQgeG1sbnM9InVybjpleGFtcGxlOnNlcnZlci1mYXJtIj4NCg0KICAgICAgICAgMjAx NC0wNy0yOVQxMzo0MjoxMloNCg0KICAgICAgIDwvcmVzZXQtZmluaXNoZWQtYXQ+DQoNCiAgICAg PC9ycGMtcmVwbHk+DQoNCiAgICAgICAgICAgICAgPT0+IEhlcmUgcnBjLXJlcGx5IG9ubHkgaGFz IHRoZSBuYW1lc3BhY2UgYW5kIGFjdGlvbiBuYW1lIGRlZmluZWQgaW4gdGhlIG1vdW50LWluc3Rh bmNlJ3MgbW9kdWxlLg0KDQogICAgICAgICAgICAgIFRoZSBjbGllbnQgbmVlZHMgdG8gc3RvcmUg aW5mb3JtYXRpb24gb2YgdGhlIG1vdW50LWluc3RhbmNlIGZvciB3aGljaCB0aGUgUlBDIHJlcXVl c3Qgd2FzIHNlbnQgYW5kIG9ubHkgdGhlbiBpdCBjYW4gdmFsaWRhdGUgdGhlIHJwYy1yZXBseSBh Z2FpbnN0IHRoZSBkYXRhLW1vZGVsLg0KDQogICAgICAgICAgICAgIFRvIGF2b2lkIHRoaXMgd29y ayBvZiBjbGllbnQsIHdoZXRoZXIgd2UgY2FuIHRoaW5rIG9mIGFkZGluZyBtZXRhLWRhdGEgdG8g cnBjLXJlcGx5IHRvIHByb3ZpZGUgdGhpcyBpbmZvcm1hdGlvbiB0byBjbGllbnQuDQoNCg0KDQoy LiBTZWN0aW9uIDUNCg0KICAgSSB3b3VsZCBwcmVmZXIgdGhlIGFwcHJvYWNoIHRha2VuIGJ5IFlh bmcgMS4xIHdoZXJlIHN0YXRlbWVudHMgZm9sbG93ZWQgYnkgWE1MIGV4YW1wbGVzICAgdG8gaGVs cCBpbiBjbGFyaXR5Lg0KDQogICBFc3BlY2lhbGx5IGZvciB0aGUgUlBDIGFuZCBub3RpZmljYXRp b24gc2VjdGlvbiwgaXQgaXMgYmV0dGVyIHRvIGFkZCBjbGVhciBleGFtcGxlcw0KDQogICBpbiBh ICJVc2FnZSBFeGFtcGxlIiBzdWItc2VjdGlvbiBmb3IgdGhpcyBzZWN0aW9uLg0KDQoNCg0KMy4g WWFuZyBSUEMgYW5kIEFDVElPTiBzdGF0ZW1lbnRzOg0KDQogIElmIHdlIG5lZWQgdG8gdmlldyB0 aGUgUlBDIGRlZmluZWQgaW4gYSBtb2R1bGUgYXMgYW4gQUNUSU9OIGFmdGVyIHNjaGVtYSBtb3Vu dCwgdGhlbg0KDQogIFdoZW5ldmVyIHRoZXJlIGlzIHVwZGF0ZSB0byBSUEMgaW4gc2F5IFlBTkcg MS4yLCB0aGVuIHRoZSBjb3JyZXNwb25kaW5nIGNoYW5nZXMgbXVzdCBiZSBwcmVzZW50IGluIEFD VElPTiBhbHNvLCBpbnRyb2R1Y2luZyBhIGNvdXBsaW5nIGJldHdlZW4gUlBDIGFuZCBBQ1RJT04g c3RhdGVtZW50cy4NCg0KDQoNCjQuIE5FVENPTkYgaGFzIHNvbWUgInJwYyIgd2hpY2ggd29yayBv biBtdWx0aXBsZSBtb3VudC1pbnN0YW5jZXMuDQoNCiAgID09PiBGb3IgZXhhbXBsZSA8ZWRpdC1j b25maWc+ICwgPGdldC1jb25maWc+IG9yIDxsb2NrPi4gV2hldGhlciB3ZSBuZWVkIHRvIGdpdmUg YQ0KDQogICBndWlkZWxpbmUgZm9yIGhvdyB0byBoYW5kbGUgc3VjaCAicnBjIiwgc28gdGhhdCBv dGhlciBwcm90b2NvbHMgd2hpY2ggaW1wbGVtZW50IHNjaGVtYSBtb3VudCAgIGFsc28gYWRhcHQg YWNjb3JkaW5nbHkgPw0KDQogICBFZzogU29tZXRoaW5nIGxpa2UsIGZvciB0cmFuc2FjdGlvbiBt YW5hZ2VtZW50LCBiZXR0ZXIgdG8gb3BlcmF0ZSBvbiBvbmUgbW91bnQtaW5zdGFuY2UuDQoNCg0K DQoNCg0KDQoNCldpdGggUmVnYXJkcywNCg0KUm9oaXQgUg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29t Pg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDI5LCAyMDE4IDEyOjU5OjUzIFBNDQpUbzogcm9oaXRy cmFuYWRlQG91dGxvb2suY29tDQpDYzogbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25l dG1vZF0gQ29tbWVudHMgb24gc2NoZW1hIG1vdW50IGRyYWZ0DQoNCkhpLA0KDQpSb2hpdCBSYW5h ZGUgPHJvaGl0cnJhbmFkZUBvdXRsb29rLmNvbT4gd3JvdGU6DQo+IEhpIE1hcnRpbiwNCj4NCj4g Vy5yLnQgPGdldC1zY2hlbWE+IG9uIHRoZSBtYWluIGRldmljZSwgaXQgd2lsbCBtZWFuIHRoYXQg Zm9yDQo+IHN1Y2Nlc3NmdWwgPGdldC1zY2hlbWE+IGZvciBhbGwgdGhlIHNjaGVtYSBvZiBtb3Vu dGVkIGRldmljZXMsIHRoZQ0KPiBtYWluIGRldmljZSBtdXN0IGJlIHVwZ3JhZGVkIHRvIGhpZ2hl ciB2ZXJzaW9uIGZpcnN0IGFuZCBtdXN0IGNvbnRhaW4NCj4gQUxMIHRoZSBzY2hlbWEgb2YgYWxs IHRoZSBkZXZpY2VzIGJlaGluZCB0aGUgbWFpbiBkZXZpY2UuDQoNClRoaXMgaXMgbm90IHRoZSBp bnRlbnRpb24sIGFuZCBhcyB5b3Ugbm90ZSwgaW4gbWFueSBjYXNlcyB0aGlzIGlzIGp1c3QNCm5v dCBwb3NzaWJsZS4NCg0KVGhlIGNsaWVudCBjYW4gbG9vayBhdCB0aGUgImxvY2F0aW9uIiBsZWFm IGluIHRoZSBtb3VudGVkIFlBTkcgbGlicmFyeQ0KKGluIFlMYmlzOyBpbiBvbGQgWUwgaXQgd2Fz IGNhbGxlZCAic2NoZW1hIikgYW5kIGdldCB0aGUgbW9kdWxlIGZyb20NCnRoZXJlLg0KDQpJZiB0 aGUgbW91bnRlZCBzY2hlbWEgYWxzbyBtb3VudHMgImlldGYtbmV0Y29uZi1tb25pdG9yaW5nIiwg dGhlDQpjbGllbnQgY2FuIGludm9rZSB0aGUgbW91bnRlZCA8Z2V0LXNjaGVtYT4gYXMgYW4gYWN0 aW9uLCBhbmQgcmV0cmlldmUNCnRoZSBzcGVjaWZpYyB2ZXJzaW9uIG9mIHRoZSBtb2R1bGUgdGhh dCBpcyBtb3VudGVkIHRoZXJlLg0KDQo+IFRoaXMgcG9pbnQgbWF5IHByb3ZlIHRvIGJlIHRyaWNr eSBhcyB0aGUgd2hvbGUgdG9wb2xvZ3kgdXBncmFkZSBoYXMgdG8NCj4gYmUgY29uc2lkZXJlZCBh bHdheXMuIEkgZmVlbCB3ZSBjYW4gYWRkIHNvbWUgdGV4dCByZWdhcmRpbmcgdGhpcy4NCj4NCj4g QWxzbyBob3cgdG8g4oCcbW91bnTigJ0gYW4gaW5zdGFuY2Ugb2YgYSBtb3VudC1wb2ludCA/IEJl Y2F1c2Ugb25jZSB0aGlzDQo+IGRyYWZ0IGlzIG91dCwgZWFjaCBpbXBsZW1lbnRlciBtYXkgZGVm aW5lIHByaXZhdGUgUlBDcyBmb3IgbW91bnQgYW5kDQo+IHVuLW1vdW50IGlmIHRoaXMgbW9kdWxl IGRvZXMgbm90IGRlZmluZSBpdC4gV2hldGhlciBhbnkgcGxhbiBhYm91dCBpdA0KPiA/DQoNCk5v dGUgdGhhdCBzY2hlbWEgbW91bnQgaXMgbm90IGFib3V0IG1vdW50aW5nIGRldmljZXM7IHRoYXQg d291bGQgYmUgYQ0KZnV0dXJlIHNwZWNpYWxpemF0aW9uIG9mIHRoaXMgbWVjaGFuaXNtLg0KDQpJ biB0aGUgTE5FIGFuZCBOSSBkcmFmdHMsIGVudGl0aWVzIGFyZSAibW91bnRlZCIgYnkgY3JlYXRp bmcgZW50cmllcw0KaW4gdGhlIGNvcnJlc3BvbmRpbmcgbGlzdHMuICBUaGVyZSBpcyBubyBuZWVk IGZvciBhICJtb3VudCIgcnBjIGluDQp0aGVzZSBjYXNlcy4NCg0KDQovbWFydGluDQoNCg0KDQoN Cj4NCj4NCj4NCj4NCj4gV2l0aCBSZWdhcmRzLA0KPiBSb2hpdCBSDQo+DQo+IFNlbnQgZnJvbSBN YWlsPGh0dHBzOi8vZ28ubWljcm9zb2Z0LmNvbS9md2xpbmsvP0xpbmtJZD01NTA5ODY+IGZvcg0K PiBXaW5kb3dzIDEwDQo+DQo+IEZyb206IE1hcnRpbiBCam9ya2x1bmQ8bWFpbHRvOm1iakB0YWls LWYuY29tPg0KPiBTZW50OiAyNiDgpK7gpL7gpLDgpY3gpJogMjAxOCAxMzo0MQ0KPiBUbzogcm9o aXRycmFuYWRlQG91dGxvb2suY29tPG1haWx0bzpyb2hpdHJyYW5hZGVAb3V0bG9vay5jb20+DQo+ IENjOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gU3ViamVjdDog UmU6IFtuZXRtb2RdIENvbW1lbnRzIG9uIHNjaGVtYSBtb3VudCBkcmFmdA0KPg0KPiBIaSwNCj4N Cj4gVGhhbmsgeW91IGZvciB0aGVzZSBjb21tZW50cywgcmVwbGllcyBpbmxpbmUuDQo+DQo+IFJv aGl0IFJhbmFkZSA8cm9oaXRycmFuYWRlQG91dGxvb2suY29tPiB3cm90ZToNCj4gPiBIaSBBbGws DQo+ID4NCj4gPiBQbGVhc2UgZmluZCBzb21lIGNvbW1lbnRzIGZvciB0aGUgc2NoZW1hIG1vdW50 IGRyYWZ0LiBJZiBJIGZpbmQgYW55DQo+ID4gb3RoZXIgd2lsbCBzZW5kIGluIGFub3RoZXIgbWFp bC4NCj4gPg0KPiA+IEVkaXRvcmlhbDoNCj4gPiA9PT09PT09PT09PT0NCj4gPiAxLiBTZWN0aW9u IDMuMQ0KPiA+ICAgICJUaGUgIm1vdW50LXBvaW50IiBzdGF0ZW1lbnQgTVVTVCBOT1QgYmUgdXNl ZCBpbiBhIFlBTkcgdmVyc2lvbiAxDQo+ID4gICAgbW9kdWxlLiINCj4gPiAgICA9PT4gSXQgaXMg dW5jbGVhciB3aHkgc3VjaCBhIHJlc3RyaWN0aW9uIGlzIHBsYWNlZC4NCj4NCj4gVGhlIHJlYXNv biBpcyB0aGF0IFlBTkcgMSBkb2Vzbid0IHN1cHBvcnQgaW5saW5lIGFjdGlvbnMgYW5kDQo+IG5v dGlmaWNhdGlvbiwgd2hpY2ggbWVhbnMgdGhhdCB0b3AtbGV2ZWwgcnBjcyBhbmQgbm90aWZzIGlu IHRoZQ0KPiBtb3VudGVkIG1vZHVsZSBjYW5ub3QgYmUgaW52b2tlZCB1c2luZyB0aGUgbWVjaGFu aXNtIGRlc2NyaWJlZCBpbg0KPiBzZWN0aW9uIDUuICBJIHdpbGwgdHJ5IHRvIGNsYXJpZnkgdGhp cy4NCj4NCj4gPiAyLiBTZWN0aW9uIDMuMg0KPiA+ICAgICJzdGF0ZSBkYXRhIGluIHRoZSAieWFu Z21udDpzY2hlbWEtbW91bnRzIiINCj4gPiAgICA9PT4gSGVyZSB0aGUgeWFuZyB0cmVlIGRpYWdy YW0gaXMgbm90IHlldCBpbnRyb2R1Y2VkLiBJIGZlZWwgYmV0dGVyIHRvDQo+ID4gICAgaW50cm9k dWNlDQo+ID4gICAgdGhpcyBkaWFncmFtIGFzIGl0IG1ha2VzIGl0IGVhc2llciB0byB1bmRlcnN0 YW5kIHRoZSBkYXRhLW5vZGVzDQo+DQo+IE9rLiAgSSBtb3ZlZCBzZWN0aW9uIDggdG8gYSBuZXcg c2VjdGlvbiAzLjIuDQo+DQo+ID4gMy4gU2VjdGlvbiAzLjINCj4gPiAgICAiRGF0YSBpbiB0aGlz IGNvbnRhaW5lciBpcyBpbnRlbmRlZCB0byBiZSBhcyBzdGFibGUgYXMgZGF0YSBpbiB0aGUNCj4g PiAgICB0b3AtbGV2ZWwgWUFORyBsaWJyYXJ5Ig0KPiA+ICAgID09PiBXaGF0IGlzIHRoZSBtZWFu aW5nIG9mICJhcyBzdGFibGUiIGFzID8gQXMgYSBkZXZlbG9wZXIgLCBJIGFtDQo+ID4gICAgdW5j bGVhciB3aGF0IG5lZWRzDQo+ID4gICAgdG8gYmUgZG9uZSBoZXJlLiBQbGVhc2UgY2xhcmlmeS4N Cj4NCj4gS2VudCBhbHNvIGhhZCBhIGNvbW1lbnQgYXJvdW5kIHRoaXMsIGFuZCB0aGUgdGV4dCBh Ym91dCBzdGFibGUgaXMgbm93DQo+IHJlbW92ZWQuDQo+DQo+ID4gNC4gU2VjdGlvbiAzLjINCj4g PiAgICAiaS5lLiwgaW5zdGFuY2VzIG9mIHRoYXQgbW91bnQgcG9pbnQgTVVTVCBOT1QgY29udGFp biBhbnkgZGF0YSBhYm92ZQ0KPiA+ICAgIHRob3NlIHRoYXQgYXJlIGRlZmluZWQgaW4gdGhlIHBh cmVudCBzY2hlbWEuIg0KPiA+ICAgID09PiBIZXJlICJhbnkgZGF0YSBhYm92ZSIsIG1lYW5zICJh Ym92ZSIgaW4gdGhlIGhpZWFyYXJjaHkgPw0KPg0KPiBObywgdGhpcyB3YXMganVzdCB3cm9uZzsg aXQgc2hvdWxkIGJlICJleGNlcHQiLg0KPg0KPiA+ICAgIE5vdA0KPiA+ICAgIGNsZWFyLCB0aGlz IGlzIHNpbWlsYXINCj4gPiAgICB0byBoYXZpbmcgYSBVU0Igc2xvdCwgYnV0IG5vIGRldmljZSBt b3VudGVkIG9uIGl0IGFzIHlldCBpbiBVTklYDQo+ID4gICAgdGVybXMuIFJpZ2h0ID8NCj4gPiAg ICBUaGUgcXVlcnkgb3V0cHV0IG9uIHBhcmVudC1zY2hlbWEgc2hvdWxkIGdpdmUgZW1wdHkgZGF0 YS4NCj4gPg0KPiA+IDUuIFNlY3Rpb24gMy4yDQo+ID4gICAgIklmIG11bHRpcGxlIG1vdW50IHBv aW50cyB3aXRoIHRoZSBzYW1lIG5hbWUgYXJlIGRlZmluZWQgaW4gdGhlIHNhbWUNCj4gPiAgICBt b2R1bGUgLSBlaXRoZXIgZGlyZWN0bHkgb3IgYmVjYXVzZSB0aGUgbW91bnQgcG9pbnQgaXMgZGVm aW5lZCBpbiBhDQo+ID4gICAgZ3JvdXBpbmcgYW5kIHRoZSBncm91cGluZyBpcyB1c2VkIG11bHRp cGxlIHRpbWVzIC0gdGhlbiB0aGUNCj4gPiAgICBjb3JyZXNwb25kaW5nICJtb3VudC1wb2ludCIg ZW50cnkgYXBwbGllcyBlcXVhbGx5IHRvIGFsbCBzdWNoIG1vdW50DQo+ID4gICAgcG9pbnRzLiIN Cj4gPiAgID09PiBBcyBwZXIgdHJlZSBkaWFncmFtLCAibW91bnQtcG9pbnQiIGhhcyB0d28ga2V5 cy4gU28gZWFjaCBtb2R1bGUNCj4gPiAgIGNhbiBoYXZlIG11bHRpcGxlDQo+ID4gICBtb3VudCBw b2ludHMuIFNvIGhvdyB0byBhcHBseSBpdCAiZXF1YWxseSIgPyBOb3QgY2xlYXIuDQo+DQo+IE5v dGUgdGhhdCB0aGUgc2VudGVuY2Ugc3RhcnRzIHdpdGggIklmIG11bHRpcGxlIG1vdW50IHBvaW50 cyB3aXRoIHRoZQ0KPiBzYW1lIG5hbWUgYXJlIGRlZmluZWQgaW4gdGhlIHNhbWUgbW9kdWxlIiAt LSBzbyB0aGlzIGNsZWFybHkgZG9lc24ndA0KPiBhcHBseSB0byBtb3VudCBwb2ludHMgd2l0aCBk aWZmZXJlbnQgbmFtZXMsIHJpZ2h0Pw0KPg0KPiBGb3IgZXhhbXBsZSwgeW91IGNhbiBoYXZlOg0K Pg0KPiAgIGNvbnRhaW5lciBmb28gew0KPiAgICAgeWFuZ21udDptb3VudC1wb2ludCBteS1tbnQt cG9pbnQ7DQo+ICAgfQ0KPiAgIGNvbnRhaW5lciBiYXIgew0KPiAgICAgeWFuZ21udDptb3VudC1w b2ludCBteS1tbnQtcG9pbnQ7DQo+ICAgfQ0KPg0KPiBUaGVyZSBpcyBqdXN0IG9uZSBlbnRyeSBp biB0aGUgIm1vdW50LXBvaW50IiBsaXN0LCBzbyB0aGF0IGVudHJ5DQo+IGFwcGxpZXMgdG8gYm90 aCB0aGVzZSBtb3VudCBwb2ludHMuICBCb3RoIGFyZSBlaXRoZXIgImlubGluZSIgb3INCj4gInNo YXJlZC1zY2hlbWEiLg0KPg0KPg0KPiA+IDYuIFNlY3Rpb24gMy4yDQo+ID4gICAgSW5zdGVhZCBv ZiAiaW5saW5lIiBhbmQgInNoYXJlZC1zY2hlbWEiLCBJIHN1Z2dlc3QgdG8gdXNlDQo+ID4gICAg InZhcmlhYmxlLXNjaGVtYSIgYW5kDQo+ID4gICAgInNhbWUtc2NoZW1hIg0KPiA+ICAgIFJlYXNv bjogVGhlIGtleSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3byBpcyB0aGF0IGluIG9uZSBjYXNl LCB0aGUNCj4gPiAgICBzY2hlbWEgTUFZIGJlIGRpZmZlcmVudA0KPiA+ICAgIHdoaWxlIGluIHRo ZSBvdGhlciB0aGUgc2NoZW1hIGlzIHNhbWUuIFRoZSBuYW1lIGNhbiBiZSBzaW1pbGFyIHRvIHRo ZQ0KPiA+ICAgIHJlYXNvbi4NCj4NCj4gQXQgdGhpcyBwb2ludCwgd2UgaGF2ZSB0byBsaXZlIHdp dGggdGhlc2UgdGVybXMuICBUaGlzIHdhcyBwYXJ0IG9mIHRoZQ0KPiBjb21wcm9taXNlIGxlYWRp bmcgdG8gdGhpcyBzb2x1dGlvbjsgdGhlcmUgYXJlIG90aGVyIGRvY3VtZW50cyBpbiB0aGUNCj4g UkZDIGVkaXRvcidzIHF1ZXVlIHRoYXQgZGVwZW5kIG9uIHRoZXNlIHRlcm1zLg0KPg0KPiA+IExv Z2ljYWwgUG9pbnQ6DQo+ID4gMS4gQ29uc2lkZXIgdGhlIHRvcG9sb2d5IHdoZXJlIDEgbWFpbiBk ZXZpY2UgaXMgcHJlc2VudCB3aXRoIE4gbG9naWNhbA0KPiA+IGRldmljZXMgYmVoaW5kIGl0Lg0K PiA+ICAgIFdoZW4gdGhlIG1vdW50aW5nIGlzIGRvbmUsIGl0IGlzIHF1aXRlIHBvc3NpYmxlIHRo YXQgc29tZSBvZiBOIGRldmljZXMNCj4gPiAgICBhcmUgaGF2aW5nIGRpZmZlcmVudA0KPiA+ICAg IHZlcnNpb25zIG9mIG1vZHVsZXMuDQo+ID4gICAgVGhpcyBjYW4gbGVhZCB0byBlYWNoIGluc3Rh bmNlIG9mIG1vdW50IHBvaW50LCBoYXZpbmcgZGlmZmVyZW50DQo+ID4gICAgc2NoZW1hLg0KPiA+ ICAgIEhvdyBjYW4gdGhlIGNsaWVudCB1bmRlcnN0YW5kIHRoZSBzY2hlbWEgb2YgZWFjaCBtb3Vu dC1wb2ludCBpbnN0YW5jZQ0KPiA+ICAgID8gUHJlZmVyYWJseSBnZXQtc2NoZW1hIG9mIHRoZXNl IGRldmljZXMgYW5kIHRoZW4ga25vdyB0aGUgbW9kZWwgPw0KPg0KPiBUaGlzIGRyYWZ0IHNheXMg dGhhdCBlYWNoIGluc3RhbmNlIHdpbGwgaGF2ZSBpdHMgb3duIFlBTkcgbGlicmFyeQ0KPiBpbnN0 YW5jZS4gIFNvIHRoZXJlIHRoZSBjbGllbnQgY2FuIGRldGVjdCB3aGljaCB2ZXJzaW9ucyBvZiB0 aGUNCj4gZGlmZmVyZW50IG1vZHVsZXMgZWFjaCBpbnN0YW5jZSBzdXBwb3J0cy4gIFRoZW4gPGdl dC1zY2hlbWE+IGNhbiBiZQ0KPiBpbnZva2VkIHRvIGdldCB0aGUgbW9kdWxlcywgaWYgaXQgaXMg c3VwcG9ydGVkLg0KPg0KPg0KPiAvbWFydGluDQo+DQo= --_000_KL1PR0401MB12720644E171A6A8AC738545DBA50KL1PR0401MB1272_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ DQo8bWV0YSBuYW1lPSJ4X0dlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZp bHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPg0KPCEtLQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIn0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCnAu eF9Nc29Ob3JtYWwsIGxpLnhfTXNvTm9ybWFsLCBkaXYueF9Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZn0NCmE6eF9saW5rLCBzcGFuLnhfTXNvSHlwZXJsaW5r DQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZX0NCmE6eF92aXNpdGVk LCBzcGFuLnhfTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lfQ0KLnhfTXNvQ2hwRGVmYXVsdA0KCXt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlufQ0KZGl2LnhfV29yZFNlY3Rp b24xDQoJe30NCi0tPg0KPC9zdHlsZT4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9InhfV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJ4 X01zb05vcm1hbCI+SGkgTWFydGluLDwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7 PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5UaGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2Vz LjwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+SSBoYXZlIGdvbmUgdGhyb3VnaCB0aGUgTE5F IGRyYWZ0IGFuZCBZQU5HIDEuMSBhbmQgZm91bmQgc29tZSBtb3JlIHN1Z2dlc3Rpb25zLjwvcD4N CjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFs Ij4xLiBTZWN0aW9uIDUgPC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsm bmJzcDsmcXVvdDtJZiBhIG1vdW50ZWQgWUFORyBtb2R1bGUgZGVmaW5lcyBhbiBSUEMgb3BlcmF0 aW9uLCBjbGllbnRzIGNhbiBpbnZva2U8L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyB0aGlzIG9wZXJhdGlvbiBhcyBpZiBpdCB3ZXJlIGRlZmluZWQgYXMgYW4gYWN0aW9u IGZvciB0aGU8L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBjb3JyZXNw b25kaW5nIG1vdW50IHBvaW50JnF1b3Q7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsgPT0mZ3Q7IEJlbG93IGlzIHRoZSBleGFtcGxlIGZyb20gWWFuZyAxLjEgU2VjdGlv biA3LjE1PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgPC9wPg0KPHAg Y2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7cnBjIG1lc3Nh Z2UtaWQ9JnF1b3Q7MTAxJnF1b3Q7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeG1sbnM9JnF1 b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wJnF1b3Q7Jmd0OzwvcD4N CjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZsdDthY3Rpb24geG1sbnM9JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOjEm cXVvdDsmZ3Q7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3NlcnZlciB4bWxucz0mcXVvdDt1cm46 ZXhhbXBsZTpzZXJ2ZXItZmFybSZxdW90OyZndDs8L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbHQ7bmFtZSZndDthcGFjaGUtMSZsdDsvbmFtZSZndDsgPC9wPg0KPHAgY2xhc3M9Inhf TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7cmVzZXQmZ3Q7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3Jlc2V0LWF0Jmd0OzIwMTQtMDctMjlUMTM6NDI6MDBa Jmx0Oy9yZXNldC1hdCZndDs8L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L3Jl c2V0Jmd0OzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvc2VydmVyJmd0OzwvcD4NCjxwIGNsYXNz PSJ4X01zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsv YWN0aW9uJmd0OzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZsdDsvcnBjJmd0OzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3Jw Yy1yZXBseSBtZXNzYWdlLWlkPSZxdW90OzEwMSZxdW90OzwvcD4NCjxwIGNsYXNzPSJ4X01zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHhtbG5zPSZxdW90O3Vybjpp ZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90OyZndDs8L3A+DQo8cCBjbGFz cz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7 cmVzZXQtZmluaXNoZWQtYXQgeG1sbnM9JnF1b3Q7dXJuOmV4YW1wbGU6c2VydmVyLWZhcm0mcXVv dDsmZ3Q7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxNC0wNy0yOVQxMzo0MjoxMlo8L3A+DQo8cCBj bGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bHQ7L3Jlc2V0LWZpbmlzaGVkLWF0Jmd0OzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvcnBjLXJlcGx5Jmd0OzwvcD4NCjxwIGNsYXNzPSJ4 X01zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID09Jmd0OyBIZXJlIHJwYy1yZXBseSBv bmx5IGhhcyB0aGUgbmFtZXNwYWNlIGFuZCBhY3Rpb24gbmFtZSBkZWZpbmVkIGluIHRoZSBtb3Vu dC1pbnN0YW5jZSdzIG1vZHVsZS48L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUaGUgY2xpZW50IG5lZWRzIHRvIHN0b3JlIGluZm9ybWF0aW9uIG9mIHRo ZSBtb3VudC1pbnN0YW5jZSBmb3Igd2hpY2ggdGhlIFJQQyByZXF1ZXN0IHdhcyBzZW50IGFuZCBv bmx5IHRoZW4gaXQgY2FuIHZhbGlkYXRlIHRoZSBycGMtcmVwbHkgYWdhaW5zdCB0aGUgZGF0YS1t b2RlbC48L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBU byBhdm9pZCB0aGlzIHdvcmsgb2YgY2xpZW50LCB3aGV0aGVyIHdlIGNhbiB0aGluayBvZiBhZGRp bmcgbWV0YS1kYXRhIHRvIHJwYy1yZXBseSB0byBwcm92aWRlIHRoaXMgaW5mb3JtYXRpb24gdG8g Y2xpZW50LjwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9 InhfTXNvTm9ybWFsIj4yLiBTZWN0aW9uIDU8L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyBJIHdvdWxkIHByZWZlciB0aGUgYXBwcm9hY2ggdGFrZW4gYnkgWWFuZyAxLjEg d2hlcmUgc3RhdGVtZW50cyBmb2xsb3dlZCBieSBYTUwgZXhhbXBsZXMmbmJzcDsmbmJzcDsgdG8g aGVscCBpbiBjbGFyaXR5LiZuYnNwOyZuYnNwOw0KPC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsmbmJzcDtFc3BlY2lhbGx5IGZvciB0aGUgUlBDIGFuZCBub3RpZmljYXRp b24gc2VjdGlvbiwgaXQgaXMgYmV0dGVyIHRvIGFkZCBjbGVhciBleGFtcGxlczwvcD4NCjxwIGNs YXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGluIGEgJnF1b3Q7VXNhZ2UgRXhhbXBsZSZx dW90OyBzdWItc2VjdGlvbiBmb3IgdGhpcyBzZWN0aW9uLjwvcD4NCjxwIGNsYXNzPSJ4X01zb05v cm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4zLiBZYW5nIFJQQyBhbmQg QUNUSU9OIHN0YXRlbWVudHM6PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsgSWYg d2UgbmVlZCB0byB2aWV3IHRoZSBSUEMgZGVmaW5lZCBpbiBhIG1vZHVsZSBhcyBhbiBBQ1RJT04g YWZ0ZXIgc2NoZW1hIG1vdW50LCB0aGVuPC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJz cDsgV2hlbmV2ZXIgdGhlcmUgaXMgdXBkYXRlIHRvIFJQQyBpbiBzYXkgWUFORyAxLjIsIHRoZW4g dGhlIGNvcnJlc3BvbmRpbmcgY2hhbmdlcyBtdXN0IGJlIHByZXNlbnQgaW4gQUNUSU9OIGFsc28s IGludHJvZHVjaW5nIGEgY291cGxpbmcgYmV0d2VlbiBSUEMgYW5kIEFDVElPTiBzdGF0ZW1lbnRz LjwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9InhfTXNv Tm9ybWFsIj40LiBORVRDT05GIGhhcyBzb21lICZxdW90O3JwYyZxdW90OyB3aGljaCB3b3JrIG9u IG11bHRpcGxlIG1vdW50LWluc3RhbmNlcy48L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyA9PSZndDsgRm9yIGV4YW1wbGUgJmx0O2VkaXQtY29uZmlnJmd0OyAsICZsdDtn ZXQtY29uZmlnJmd0OyBvciAmbHQ7bG9jayZndDsuIFdoZXRoZXIgd2UgbmVlZCB0byBnaXZlIGEN CjwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Z3VpZGVsaW5l IGZvciBob3cgdG8gaGFuZGxlIHN1Y2ggJnF1b3Q7cnBjJnF1b3Q7LCBzbyB0aGF0IG90aGVyIHBy b3RvY29scyB3aGljaCBpbXBsZW1lbnQgc2NoZW1hIG1vdW50Jm5ic3A7Jm5ic3A7IGFsc28gYWRh cHQgYWNjb3JkaW5nbHkgPzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 IEVnOiBTb21ldGhpbmcgbGlrZSwgZm9yIHRyYW5zYWN0aW9uIG1hbmFnZW1lbnQsIGJldHRlciB0 byBvcGVyYXRlIG9uIG9uZSBtb3VudC1pbnN0YW5jZS48L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3Jt YWwiPiZuYnNwOyA8L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzwvcD4N CjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFs Ij5XaXRoIFJlZ2FyZHMsPC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5Sb2hpdCBSPC9wPg0K PHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxociB0YWJpbmRleD0i LTEiIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazsgd2lkdGg6OTglIj4NCjxkaXYgaWQ9Inhf ZGl2UnBseUZ3ZE1zZyIgZGlyPSJsdHIiPjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYi IGNvbG9yPSIjMDAwMDAwIiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxiPkZyb206PC9iPiBNYXJ0 aW4gQmpvcmtsdW5kICZsdDttYmpAdGFpbC1mLmNvbSZndDs8YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIE1hcmNoIDI5LCAyMDE4IDEyOjU5OjUzIFBNPGJyPg0KPGI+VG86PC9iPiByb2hpdHJy YW5hZGVAb3V0bG9vay5jb208YnI+DQo8Yj5DYzo8L2I+IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gQ29tbWVudHMgb24gc2NoZW1hIG1vdW50IGRyYWZ0 PC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8Zm9udCBzaXplPSIy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+ SGksPGJyPg0KPGJyPg0KUm9oaXQgUmFuYWRlICZsdDtyb2hpdHJyYW5hZGVAb3V0bG9vay5jb20m Z3Q7IHdyb3RlOjxicj4NCiZndDsgSGkgTWFydGluLDxicj4NCiZndDsgPGJyPg0KJmd0OyBXLnIu dCAmbHQ7Z2V0LXNjaGVtYSZndDsgb24gdGhlIG1haW4gZGV2aWNlLCBpdCB3aWxsIG1lYW4gdGhh dCBmb3I8YnI+DQomZ3Q7IHN1Y2Nlc3NmdWwgJmx0O2dldC1zY2hlbWEmZ3Q7IGZvciBhbGwgdGhl IHNjaGVtYSBvZiBtb3VudGVkIGRldmljZXMsIHRoZTxicj4NCiZndDsgbWFpbiBkZXZpY2UgbXVz dCBiZSB1cGdyYWRlZCB0byBoaWdoZXIgdmVyc2lvbiBmaXJzdCBhbmQgbXVzdCBjb250YWluPGJy Pg0KJmd0OyBBTEwgdGhlIHNjaGVtYSBvZiBhbGwgdGhlIGRldmljZXMgYmVoaW5kIHRoZSBtYWlu IGRldmljZS48YnI+DQo8YnI+DQpUaGlzIGlzIG5vdCB0aGUgaW50ZW50aW9uLCBhbmQgYXMgeW91 IG5vdGUsIGluIG1hbnkgY2FzZXMgdGhpcyBpcyBqdXN0PGJyPg0Kbm90IHBvc3NpYmxlLjxicj4N Cjxicj4NClRoZSBjbGllbnQgY2FuIGxvb2sgYXQgdGhlICZxdW90O2xvY2F0aW9uJnF1b3Q7IGxl YWYgaW4gdGhlIG1vdW50ZWQgWUFORyBsaWJyYXJ5PGJyPg0KKGluIFlMYmlzOyBpbiBvbGQgWUwg aXQgd2FzIGNhbGxlZCAmcXVvdDtzY2hlbWEmcXVvdDspIGFuZCBnZXQgdGhlIG1vZHVsZSBmcm9t PGJyPg0KdGhlcmUuPGJyPg0KPGJyPg0KSWYgdGhlIG1vdW50ZWQgc2NoZW1hIGFsc28gbW91bnRz ICZxdW90O2lldGYtbmV0Y29uZi1tb25pdG9yaW5nJnF1b3Q7LCB0aGU8YnI+DQpjbGllbnQgY2Fu IGludm9rZSB0aGUgbW91bnRlZCAmbHQ7Z2V0LXNjaGVtYSZndDsgYXMgYW4gYWN0aW9uLCBhbmQg cmV0cmlldmU8YnI+DQp0aGUgc3BlY2lmaWMgdmVyc2lvbiBvZiB0aGUgbW9kdWxlIHRoYXQgaXMg bW91bnRlZCB0aGVyZS48YnI+DQo8YnI+DQomZ3Q7IFRoaXMgcG9pbnQgbWF5IHByb3ZlIHRvIGJl IHRyaWNreSBhcyB0aGUgd2hvbGUgdG9wb2xvZ3kgdXBncmFkZSBoYXMgdG88YnI+DQomZ3Q7IGJl IGNvbnNpZGVyZWQgYWx3YXlzLiBJIGZlZWwgd2UgY2FuIGFkZCBzb21lIHRleHQgcmVnYXJkaW5n IHRoaXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFsc28gaG93IHRvIOKAnG1vdW504oCdIGFuIGlu c3RhbmNlIG9mIGEgbW91bnQtcG9pbnQgPyBCZWNhdXNlIG9uY2UgdGhpczxicj4NCiZndDsgZHJh ZnQgaXMgb3V0LCBlYWNoIGltcGxlbWVudGVyIG1heSBkZWZpbmUgcHJpdmF0ZSBSUENzIGZvciBt b3VudCBhbmQ8YnI+DQomZ3Q7IHVuLW1vdW50IGlmIHRoaXMgbW9kdWxlIGRvZXMgbm90IGRlZmlu ZSBpdC4gV2hldGhlciBhbnkgcGxhbiBhYm91dCBpdDxicj4NCiZndDsgPzxicj4NCjxicj4NCk5v dGUgdGhhdCBzY2hlbWEgbW91bnQgaXMgbm90IGFib3V0IG1vdW50aW5nIGRldmljZXM7IHRoYXQg d291bGQgYmUgYTxicj4NCmZ1dHVyZSBzcGVjaWFsaXphdGlvbiBvZiB0aGlzIG1lY2hhbmlzbS48 YnI+DQo8YnI+DQpJbiB0aGUgTE5FIGFuZCBOSSBkcmFmdHMsIGVudGl0aWVzIGFyZSAmcXVvdDtt b3VudGVkJnF1b3Q7IGJ5IGNyZWF0aW5nIGVudHJpZXM8YnI+DQppbiB0aGUgY29ycmVzcG9uZGlu ZyBsaXN0cy4mbmJzcDsgVGhlcmUgaXMgbm8gbmVlZCBmb3IgYSAmcXVvdDttb3VudCZxdW90OyBy cGMgaW48YnI+DQp0aGVzZSBjYXNlcy48YnI+DQo8YnI+DQo8YnI+DQovbWFydGluPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFdpdGggUmVnYXJkcyw8YnI+DQomZ3Q7IFJvaGl0IFI8YnI+DQomZ3Q7IDxi cj4NCiZndDsgU2VudCBmcm9tIE1haWwmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9nby5taWNyb3NvZnQu Y29tL2Z3bGluay8/TGlua0lkPTU1MDk4NiI+aHR0cHM6Ly9nby5taWNyb3NvZnQuY29tL2Z3bGlu ay8/TGlua0lkPTU1MDk4NjwvYT4mZ3Q7IGZvcjxicj4NCiZndDsgV2luZG93cyAxMDxicj4NCiZn dDsgPGJyPg0KJmd0OyBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kJmx0OzxhIGhyZWY9Im1haWx0bzpt YmpAdGFpbC1mLmNvbSI+bWFpbHRvOm1iakB0YWlsLWYuY29tPC9hPiZndDs8YnI+DQomZ3Q7IFNl bnQ6IDI2IOCkruCkvuCksOCljeCkmiAyMDE4IDEzOjQxPGJyPg0KJmd0OyBUbzogcm9oaXRycmFu YWRlQG91dGxvb2suY29tJmx0O21haWx0bzpyb2hpdHJyYW5hZGVAb3V0bG9vay5jb20mZ3Q7PGJy Pg0KJmd0OyBDYzogbmV0bW9kQGlldGYub3JnJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0 Zi5vcmciPm1haWx0bzpuZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgU3ViamVjdDog UmU6IFtuZXRtb2RdIENvbW1lbnRzIG9uIHNjaGVtYSBtb3VudCBkcmFmdDxicj4NCiZndDsgPGJy Pg0KJmd0OyBIaSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmsgeW91IGZvciB0aGVzZSBjb21t ZW50cywgcmVwbGllcyBpbmxpbmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJvaGl0IFJhbmFkZSAm bHQ7cm9oaXRycmFuYWRlQG91dGxvb2suY29tJmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgSGkg QWxsLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBQbGVhc2UgZmluZCBzb21lIGNvbW1l bnRzIGZvciB0aGUgc2NoZW1hIG1vdW50IGRyYWZ0LiBJZiBJIGZpbmQgYW55PGJyPg0KJmd0OyAm Z3Q7IG90aGVyIHdpbGwgc2VuZCBpbiBhbm90aGVyIG1haWwuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IEVkaXRvcmlhbDo8YnI+DQomZ3Q7ICZndDsgPT09PT09PT09PT09PGJyPg0KJmd0 OyAmZ3Q7IDEuIFNlY3Rpb24gMy4xPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90O1RoZSAmcXVvdDttb3VudC1wb2ludCZxdW90OyBzdGF0ZW1lbnQgTVVTVCBOT1QgYmUgdXNl ZCBpbiBhIFlBTkcgdmVyc2lvbiAxPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1v ZHVsZS4mcXVvdDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgPT0mZ3Q7IEl0IGlz IHVuY2xlYXIgd2h5IHN1Y2ggYSByZXN0cmljdGlvbiBpcyBwbGFjZWQuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFRoZSByZWFzb24gaXMgdGhhdCBZQU5HIDEgZG9lc24ndCBzdXBwb3J0IGlubGluZSBh Y3Rpb25zIGFuZDxicj4NCiZndDsgbm90aWZpY2F0aW9uLCB3aGljaCBtZWFucyB0aGF0IHRvcC1s ZXZlbCBycGNzIGFuZCBub3RpZnMgaW4gdGhlPGJyPg0KJmd0OyBtb3VudGVkIG1vZHVsZSBjYW5u b3QgYmUgaW52b2tlZCB1c2luZyB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbjxicj4NCiZndDsg c2VjdGlvbiA1LiZuYnNwOyBJIHdpbGwgdHJ5IHRvIGNsYXJpZnkgdGhpcy48YnI+DQomZ3Q7IDxi cj4NCiZndDsgJmd0OyAyLiBTZWN0aW9uIDMuMjxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDtzdGF0ZSBkYXRhIGluIHRoZSAmcXVvdDt5YW5nbW50OnNjaGVtYS1tb3VudHMm cXVvdDsmcXVvdDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgPT0mZ3Q7IEhlcmUg dGhlIHlhbmcgdHJlZSBkaWFncmFtIGlzIG5vdCB5ZXQgaW50cm9kdWNlZC4gSSBmZWVsIGJldHRl ciB0bzxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBpbnRyb2R1Y2U8YnI+DQomZ3Q7 ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhpcyBkaWFncmFtIGFzIGl0IG1ha2VzIGl0IGVhc2ll ciB0byB1bmRlcnN0YW5kIHRoZSBkYXRhLW5vZGVzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9rLiZu YnNwOyBJIG1vdmVkIHNlY3Rpb24gOCB0byBhIG5ldyBzZWN0aW9uIDMuMi48YnI+DQomZ3Q7IDxi cj4NCiZndDsgJmd0OyAzLiBTZWN0aW9uIDMuMjxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDtEYXRhIGluIHRoaXMgY29udGFpbmVyIGlzIGludGVuZGVkIHRvIGJlIGFzIHN0 YWJsZSBhcyBkYXRhIGluIHRoZTxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB0b3At bGV2ZWwgWUFORyBsaWJyYXJ5JnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ID09Jmd0OyBXaGF0IGlzIHRoZSBtZWFuaW5nIG9mICZxdW90O2FzIHN0YWJsZSZxdW90OyBhcyA/ IEFzIGEgZGV2ZWxvcGVyICwgSSBhbTxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB1 bmNsZWFyIHdoYXQgbmVlZHM8YnI+DQomZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gYmUg ZG9uZSBoZXJlLiBQbGVhc2UgY2xhcmlmeS48YnI+DQomZ3Q7IDxicj4NCiZndDsgS2VudCBhbHNv IGhhZCBhIGNvbW1lbnQgYXJvdW5kIHRoaXMsIGFuZCB0aGUgdGV4dCBhYm91dCBzdGFibGUgaXMg bm93PGJyPg0KJmd0OyByZW1vdmVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDQuIFNlY3Rp b24gMy4yPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2kuZS4sIGluc3Rh bmNlcyBvZiB0aGF0IG1vdW50IHBvaW50IE1VU1QgTk9UIGNvbnRhaW4gYW55IGRhdGEgYWJvdmU8 YnI+DQomZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhvc2UgdGhhdCBhcmUgZGVmaW5lZCBp biB0aGUgcGFyZW50IHNjaGVtYS4mcXVvdDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJz cDsgPT0mZ3Q7IEhlcmUgJnF1b3Q7YW55IGRhdGEgYWJvdmUmcXVvdDssIG1lYW5zICZxdW90O2Fi b3ZlJnF1b3Q7IGluIHRoZSBoaWVhcmFyY2h5ID88YnI+DQomZ3Q7IDxicj4NCiZndDsgTm8sIHRo aXMgd2FzIGp1c3Qgd3Jvbmc7IGl0IHNob3VsZCBiZSAmcXVvdDtleGNlcHQmcXVvdDsuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTm90PGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNsZWFyLCB0aGlzIGlzIHNpbWlsYXI8YnI+DQomZ3Q7ICZndDsm bmJzcDsmbmJzcDsmbmJzcDsgdG8gaGF2aW5nIGEgVVNCIHNsb3QsIGJ1dCBubyBkZXZpY2UgbW91 bnRlZCBvbiBpdCBhcyB5ZXQgaW4gVU5JWDxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyB0ZXJtcy4gUmlnaHQgPzxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgcXVl cnkgb3V0cHV0IG9uIHBhcmVudC1zY2hlbWEgc2hvdWxkIGdpdmUgZW1wdHkgZGF0YS48YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgNS4gU2VjdGlvbiAzLjI8YnI+DQomZ3Q7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsgJnF1b3Q7SWYgbXVsdGlwbGUgbW91bnQgcG9pbnRzIHdpdGggdGhlIHNh bWUgbmFtZSBhcmUgZGVmaW5lZCBpbiB0aGUgc2FtZTxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBtb2R1bGUgLSBlaXRoZXIgZGlyZWN0bHkgb3IgYmVjYXVzZSB0aGUgbW91bnQgcG9p bnQgaXMgZGVmaW5lZCBpbiBhPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdyb3Vw aW5nIGFuZCB0aGUgZ3JvdXBpbmcgaXMgdXNlZCBtdWx0aXBsZSB0aW1lcyAtIHRoZW4gdGhlPGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvcnJlc3BvbmRpbmcgJnF1b3Q7bW91bnQt cG9pbnQmcXVvdDsgZW50cnkgYXBwbGllcyBlcXVhbGx5IHRvIGFsbCBzdWNoIG1vdW50PGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBvaW50cy4mcXVvdDs8YnI+DQomZ3Q7ICZndDsm bmJzcDsmbmJzcDsgPT0mZ3Q7IEFzIHBlciB0cmVlIGRpYWdyYW0sICZxdW90O21vdW50LXBvaW50 JnF1b3Q7IGhhcyB0d28ga2V5cy4gU28gZWFjaCBtb2R1bGU8YnI+DQomZ3Q7ICZndDsmbmJzcDsm bmJzcDsgY2FuIGhhdmUgbXVsdGlwbGU8YnI+DQomZ3Q7ICZndDsmbmJzcDsmbmJzcDsgbW91bnQg cG9pbnRzLiBTbyBob3cgdG8gYXBwbHkgaXQgJnF1b3Q7ZXF1YWxseSZxdW90OyA/IE5vdCBjbGVh ci48YnI+DQomZ3Q7IDxicj4NCiZndDsgTm90ZSB0aGF0IHRoZSBzZW50ZW5jZSBzdGFydHMgd2l0 aCAmcXVvdDtJZiBtdWx0aXBsZSBtb3VudCBwb2ludHMgd2l0aCB0aGU8YnI+DQomZ3Q7IHNhbWUg bmFtZSBhcmUgZGVmaW5lZCBpbiB0aGUgc2FtZSBtb2R1bGUmcXVvdDsgLS0gc28gdGhpcyBjbGVh cmx5IGRvZXNuJ3Q8YnI+DQomZ3Q7IGFwcGx5IHRvIG1vdW50IHBvaW50cyB3aXRoIGRpZmZlcmVu dCBuYW1lcywgcmlnaHQ/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZvciBleGFtcGxlLCB5b3UgY2Fu IGhhdmU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7IGNvbnRhaW5lciBmb28gezxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeWFuZ21udDptb3VudC1wb2ludCBteS1t bnQtcG9pbnQ7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyB9PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyBj b250YWluZXIgYmFyIHs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHlhbmdtbnQ6 bW91bnQtcG9pbnQgbXktbW50LXBvaW50Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsgfTxicj4NCiZn dDsgPGJyPg0KJmd0OyBUaGVyZSBpcyBqdXN0IG9uZSBlbnRyeSBpbiB0aGUgJnF1b3Q7bW91bnQt cG9pbnQmcXVvdDsgbGlzdCwgc28gdGhhdCBlbnRyeTxicj4NCiZndDsgYXBwbGllcyB0byBib3Ro IHRoZXNlIG1vdW50IHBvaW50cy4mbmJzcDsgQm90aCBhcmUgZWl0aGVyICZxdW90O2lubGluZSZx dW90OyBvcjxicj4NCiZndDsgJnF1b3Q7c2hhcmVkLXNjaGVtYSZxdW90Oy48YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDYuIFNlY3Rpb24gMy4yPGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEluc3RlYWQgb2YgJnF1b3Q7aW5saW5lJnF1b3Q7IGFuZCAmcXVvdDtz aGFyZWQtc2NoZW1hJnF1b3Q7LCBJIHN1Z2dlc3QgdG8gdXNlPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O3ZhcmlhYmxlLXNjaGVtYSZxdW90OyBhbmQ8YnI+DQomZ3Q7ICZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7c2FtZS1zY2hlbWEmcXVvdDs8YnI+DQomZ3Q7ICZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVhc29uOiBUaGUga2V5IGRpZmZlcmVuY2UgYmV0d2VlbiB0 aGUgdHdvIGlzIHRoYXQgaW4gb25lIGNhc2UsIHRoZTxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBzY2hlbWEgTUFZIGJlIGRpZmZlcmVudDxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyB3aGlsZSBpbiB0aGUgb3RoZXIgdGhlIHNjaGVtYSBpcyBzYW1lLiBUaGUgbmFtZSBj YW4gYmUgc2ltaWxhciB0byB0aGU8YnI+DQomZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVh c29uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBBdCB0aGlzIHBvaW50LCB3ZSBoYXZlIHRvIGxpdmUg d2l0aCB0aGVzZSB0ZXJtcy4mbmJzcDsgVGhpcyB3YXMgcGFydCBvZiB0aGU8YnI+DQomZ3Q7IGNv bXByb21pc2UgbGVhZGluZyB0byB0aGlzIHNvbHV0aW9uOyB0aGVyZSBhcmUgb3RoZXIgZG9jdW1l bnRzIGluIHRoZTxicj4NCiZndDsgUkZDIGVkaXRvcidzIHF1ZXVlIHRoYXQgZGVwZW5kIG9uIHRo ZXNlIHRlcm1zLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IExvZ2ljYWwgUG9pbnQ6PGJyPg0K Jmd0OyAmZ3Q7IDEuIENvbnNpZGVyIHRoZSB0b3BvbG9neSB3aGVyZSAxIG1haW4gZGV2aWNlIGlz IHByZXNlbnQgd2l0aCBOIGxvZ2ljYWw8YnI+DQomZ3Q7ICZndDsgZGV2aWNlcyBiZWhpbmQgaXQu PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoZW4gdGhlIG1vdW50aW5nIGlzIGRv bmUsIGl0IGlzIHF1aXRlIHBvc3NpYmxlIHRoYXQgc29tZSBvZiBOIGRldmljZXM8YnI+DQomZ3Q7 ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJlIGhhdmluZyBkaWZmZXJlbnQ8YnI+DQomZ3Q7ICZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgdmVyc2lvbnMgb2YgbW9kdWxlcy48YnI+DQomZ3Q7ICZndDsm bmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBjYW4gbGVhZCB0byBlYWNoIGluc3RhbmNlIG9mIG1vdW50 IHBvaW50LCBoYXZpbmcgZGlmZmVyZW50PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHNjaGVtYS48YnI+DQomZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgSG93IGNhbiB0aGUgY2xp ZW50IHVuZGVyc3RhbmQgdGhlIHNjaGVtYSBvZiBlYWNoIG1vdW50LXBvaW50IGluc3RhbmNlPGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID8gUHJlZmVyYWJseSBnZXQtc2NoZW1hIG9m IHRoZXNlIGRldmljZXMgYW5kIHRoZW4ga25vdyB0aGUgbW9kZWwgPzxicj4NCiZndDsgPGJyPg0K Jmd0OyBUaGlzIGRyYWZ0IHNheXMgdGhhdCBlYWNoIGluc3RhbmNlIHdpbGwgaGF2ZSBpdHMgb3du IFlBTkcgbGlicmFyeTxicj4NCiZndDsgaW5zdGFuY2UuJm5ic3A7IFNvIHRoZXJlIHRoZSBjbGll bnQgY2FuIGRldGVjdCB3aGljaCB2ZXJzaW9ucyBvZiB0aGU8YnI+DQomZ3Q7IGRpZmZlcmVudCBt b2R1bGVzIGVhY2ggaW5zdGFuY2Ugc3VwcG9ydHMuJm5ic3A7IFRoZW4gJmx0O2dldC1zY2hlbWEm Z3Q7IGNhbiBiZTxicj4NCiZndDsgaW52b2tlZCB0byBnZXQgdGhlIG1vZHVsZXMsIGlmIGl0IGlz IHN1cHBvcnRlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAvbWFydGluPGJyPg0K Jmd0OyA8YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_KL1PR0401MB12720644E171A6A8AC738545DBA50KL1PR0401MB1272_-- From nobody Tue Apr 3 08:09:28 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FB4127876 for ; Tue, 3 Apr 2018 08:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XASFhrLO24N7 for ; Tue, 3 Apr 2018 08:09:19 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571F9120724 for ; Tue, 3 Apr 2018 08:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4381; q=dns/txt; s=iport; t=1522768159; x=1523977759; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=veduU31Zc43Rsqyq1XteSrOcbRAl8nd2F3a3z+pAAVU=; b=UOPgU+je5+xl+Ys5ZlEjHvzD83twc221BKm2oTI5qSXhoMADJiexIt07 JsxYPBsdH3zA4vfbmtuwUQXT9DIE1TdmuPoEtQjRbRiDjhxTO/DO16pql Kg2ZPLVgLAf5YcFCDXPQn+B7zEI4b8B46ZPaoBkdyBYTs+9fSb3I9YBdk 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAACbmMNa/xbLJq1ZBBkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGEI28og1+IAF6NcwghgQ+LEodDgXoLGA2EE0sChGI0GAE?= =?us-ascii?q?CAQEBAQEBAmsohSMBAQEDAQEhDwEFNgsQCQIYAgImAgInMBMGAgEBhQkPkTy?= =?us-ascii?q?bPIIchFWDb4IlgQmILD+BLgyCKC6CZisBAYFSgwqCVAKHIpAZCIVSgk2GCga?= =?us-ascii?q?BMDqDH4I3IoRViRWBS4UdgSUcOIFSMxoIGxU6gkMJkEU+MI49AQE?= X-IronPort-AV: E=Sophos;i="5.48,401,1517875200"; d="scan'208";a="2929337" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2018 15:09:15 +0000 Received: from [10.63.23.169] (dhcp-ensft1-uk-vla370-10-63-23-169.cisco.com [10.63.23.169]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w33F9F6r024271; Tue, 3 Apr 2018 15:09:15 GMT To: otilibil@eurecom.fr Cc: netmod@ietf.org References: <20180330164544.pazut2dfxc08840w@webmail.eurecom.fr> <40e7e93c-c112-78a1-647c-1f30b95cd689@cisco.com> <20180403165605.2c9o1mru8ssg0w4c@webmail.eurecom.fr> From: Robert Wilton Message-ID: Date: Tue, 3 Apr 2018 16:09:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180403165605.2c9o1mru8ssg0w4c@webmail.eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Fwd: Re: How to grep through a YANG? With grepyang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 15:09:26 -0000 Hi Ariel, Please see inline ... On 03/04/2018 15:56, otilibil@eurecom.fr wrote: > Hi Rob, > > My answers inline. > > Regards, > Ariel > > Quoting Robert Wilton : > >> Hi Ariel, >> >> This looks like an interesting/useful tool. >> >> Have you considered hooking into pyang as a pyang extension? > Till today, no; grpeyang is still a rush, needing improvements and > cleanups. You suggested a nice idea, indeed. >> pyang is one of the defacto standard tools that folks interacting with >> yang often use.  If your aim to get widespread usage of your tool >> making it a pyang extension may be one way to achieve that. E.g. this >> would then allow your tool to generate tree output for selected yang >> subtree(s) nodes that you find, or other nice things. > Thanks for your feedback, Rob. Then, I will read through the code of > pyang, and check the dependencies, if they are any. Who manages the > Github repository? Martin Bjorklund - he is also the author. Extensions (actually called plugins) don't have to go in the same repro, they can be loaded dynamically. If you want to see an example of a plugin that walks the tree (modifying it as it goes) then you could take a look at: https://github.com/rgwilton/pyang/blob/master/pyang/plugins/ietf_to_state_module.py This takes a pyang tree and generates an extra legacy  "-state" tree from it. Thanks, Rob >> >> Thanks, >> Rob >> >> >> On 30/03/2018 15:45, otilibil@eurecom.fr wrote: >>> Hi all, >>> grepyang has got a new feature: it could grep for a node through a >>> module: >>> >>> # ./grepyang cancel-commit ietf-netconf@2011-06-01.yang >>> 853:  rpc cancel-commit { >>> 854:    if-feature confirmed-commit; >>> 855:    description >>> 856:      "This operation is used to cancel an ongoing confirmed >>> commit. >>> 857:       If the confirmed commit is persistent, the parameter >>> 858:       'persist-id' must be given, and it must match the value >>> of the >>> 859:       'persist' parameter."; >>> 860:    reference "RFC 6241, Section 8.4.4.1"; >>> 861: >>> 862:    input { >>> 863:      leaf persist-id { >>> 864:        type string; >>> 865:        description >>> 866:          "This parameter is given in order to cancel a persistent >>> 867:           confirmed commit.  The value must be equal to the value >>> 868:           given in the 'persist' parameter to the >>> operation. >>> 869:           If it does not match, the operation fails with an >>> 870:          'invalid-value' error."; >>> 871:      } >>> 872:    } >>> 873:  } >>> >>> Now it can grep for a node with a greped node: >>> >>> # ./grepyang input cancel-commit ietf-netconf@2011-06-01.yang >>> 853:  rpc cancel-commit { >>> 862:    input { >>> 863:      leaf persist-id { >>> 864:        type string; >>> 865:        description >>> 866:          "This parameter is given in order to cancel a persistent >>> 867:           confirmed commit.  The value must be equal to the value >>> 868:           given in the 'persist' parameter to the >>> operation. >>> 869:           If it does not match, the operation fails with an >>> 870:          'invalid-value' error."; >>> 871:      } >>> 872:    } >>> 873:  } >>> >>> pyang lacks such features; that's why I have been working on grepyang. >>> >>> It is out on Github (https://github.com/ariel-anieli/grepyang);  >>> feel free to play around with it. >>> >>> If you find it of any interest, have some remarks, or see it needs  >>> enhancements; please,  do so: I will work on the issues. >>> >>> Regards, >>> Ariel >>> >>> ------------------------------------------------------------------------------- >>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> > > > > ------------------------------------------------------------------------------- > > This message was sent using EURECOM Webmail: http://webmail.eurecom.fr > > . > From nobody Thu Apr 5 01:22:04 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767CB126DC2 for ; Thu, 5 Apr 2018 01:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmHO_pijSRzg for ; Thu, 5 Apr 2018 01:22:01 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0126.outbound.protection.outlook.com [104.47.0.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C71120725 for ; Thu, 5 Apr 2018 01:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hPJ9Fz142Yj3Cg+0+l4zhkDp5XFgj3yFRIAx8xaWR7Y=; b=lIjfk0Nmz8WkL1rFyyFBS9kjYlzeia5JgtLaLwmJwbhcwTIeHuqSRs/VvGsWdBKUkbz53iQPhQL2C495WZ0PelTbnmHEcFqq/HGFxTaXzFHCDY/9v4XWrSM3ddDAj7nPoG/kpmHlmwR1G9rZQmi0XzVXRMcdyio7y88Xwi43FMU= Received: from AM4PR07MB1716.eurprd07.prod.outlook.com (10.166.133.24) by AM4PR07MB3507.eurprd07.prod.outlook.com (10.171.190.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.5; Thu, 5 Apr 2018 08:21:58 +0000 Received: from AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::c15e:ad7a:a11e:eff4]) by AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::c15e:ad7a:a11e:eff4%5]) with mapi id 15.20.0653.005; Thu, 5 Apr 2018 08:21:58 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: "netmod@ietf.org" Thread-Topic: An abundant amount of IANA if types... Thread-Index: AdPMtsq1NhXOIRliRzmEujzHOstMAw== Date: Thu, 5 Apr 2018 08:21:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-originating-ip: [135.245.212.207] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB3507; 7:EMI8aMvYPuK6H/Ko+CGaPxQbO0617kVXV7TZ98IoAgDFBtfbF+0yzO+j+8M7EIs9qM3j+C2mUI0ePf0Es8yrGAgMoXn5WM9SKEUMD5uR468RrLvulyJyb5UVKjA8/HYlC2l7PIcjGzU7wdVqBXYBk2XRT+R9av97G2nat3gb6+lLHRW+oU7gimsrxMTAS59jHXK87lzvRM1JM/B95tu3VXDpo5OxUuCn8VuV+j7WjWdFKhqks9FbRw83rqtoJHQJ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b61cc278-1462-47e0-815c-08d59ace4cb9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:AM4PR07MB3507; x-ms-traffictypediagnostic: AM4PR07MB3507: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231221)(11241501184)(806099)(944501327)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR07MB3507; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB3507; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(346002)(39860400002)(39380400002)(199004)(189003)(7696005)(105586002)(26005)(186003)(790700001)(6116002)(5250100002)(55016002)(478600001)(3846002)(5640700003)(53936002)(8676002)(99286004)(33656002)(106356001)(97736004)(2501003)(8936002)(81166006)(2351001)(81156014)(476003)(74316002)(7736002)(486006)(6506007)(14454004)(25786009)(102836004)(5660300001)(3280700002)(54896002)(6306002)(86362001)(2906002)(68736007)(66066001)(316002)(3660700001)(6436002)(9686003)(6916009)(2900100001)(5630700001)(1730700003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3507; H:AM4PR07MB1716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: CvO16oHc+GYGU7T8KV6QD6xqu8ysvQR2qZANioDxBBBgYCQBvyxngAjICP/J0GJ69a4EfVcoPAbrsmLbGWR4lmqL/0RYUlwEMSNPi8ugT/afpzwR8LYQc0O1d+m5zQifnFU4AVJcZkFTdGApsqFeDISlipBxpw6G8N7XlUD5M+3EKJZiNqnwMS8oCslOLUXVjbK5LFbXXWbu08WzJ5X+t+8BSdFdiFGw2K09R9wur+wuiNNHkzB+eqoLPZ291svlDb2fM18c2rJZSvxIBBOx+UKUmvYfSF8knp9N1poPY2g549snczt8JTY0iAwkH+AGxJTLtRAL/OQgHLigSzXvDdvdSV3kovl5WhYMAS/1rMIAWfREYNEOZzYulinWs0jqZxO+zJvExRDksH3J15gD/0G9AbzXy+PquXX/nEMrSzSG3mqDv6KpeeXtFo40ZeOagI34+zk2KULWhnLFqXpdwg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB1716AECAC144285D98B0E1EE94BB0AM4PR07MB1716eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: b61cc278-1462-47e0-815c-08d59ace4cb9 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 08:21:58.2197 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3507 Archived-At: Subject: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 08:22:03 -0000 --_000_AM4PR07MB1716AECAC144285D98B0E1EE94BB0AM4PR07MB1716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We were wondering if it would make sense to introduce features in the IANA = if types YANG model to enable grouping of related interface types. This wo= uld allow implementations to include only the types it really requires (by = supporting the related features but not the others) and (in case of a CLI i= nterface) would reduce the possible completions if an operator would ask fo= r the possible values of the type of an interface. Has this ever been considered/discussed? Best regards, Bart --_000_AM4PR07MB1716AECAC144285D98B0E1EE94BB0AM4PR07MB1716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We were wondering if it would m= ake sense to introduce features in the IANA if types YANG model to enable g= rouping of related interface types.  This would allow implementations = to include only the types it really requires (by supporting the related features but not the others) and (in case of a = CLI interface) would reduce the possible completions if an operator would a= sk for the possible values of the type of an interface.

Has this ever been considered/d= iscussed?

 

Best regards,=

Bart

--_000_AM4PR07MB1716AECAC144285D98B0E1EE94BB0AM4PR07MB1716eurp_-- From nobody Thu Apr 5 05:33:48 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2208C12D883 for ; Thu, 5 Apr 2018 05:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYTlO1gou-ed for ; Thu, 5 Apr 2018 05:33:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0A78D12751F for ; Thu, 5 Apr 2018 05:33:43 -0700 (PDT) Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id A22E11AE047B; Thu, 5 Apr 2018 14:33:41 +0200 (CEST) Date: Thu, 05 Apr 2018 14:33:40 +0200 (CEST) Message-Id: <20180405.143340.1930670144610383537.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180329090305.eqshcqvqo33r5bsf@elstar.local> References: <20180329090305.eqshcqvqo33r5bsf@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] js review of draft-ietf-netmod-schema-mount-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 12:33:46 -0000 Hi, Thank you for this review! Comments inline. Juergen Schoenwaelder wrote: > Here is my review of draft-ietf-netmod-schema-mount-09. > > * Abstract > > This document defines a mechanism to combine YANG modules into the > schema defined in other YANG modules. > > I do not know what this says - I think this text is confusing. What > does it mean to 'combine' YANG modules? What is the notion of > 'schema' used here? Howabout: This document defines a mechanism to add the schema trees defined by a set of YANG modules into the schema tree defined in another YANG module. (see more below on terminology) > Does the text help someone to decide whether > this mechanisms is something worth to study in order to solve a > given modeling problem? (A good abstract would IMHO do that.) > > Note that the mount mechanisms has serious limitations as well that > perhaps need to spelled out right up-front, i.e., it only works with > pre-defined mount-points (augments are much more flexible in this > regard, the schema mount defined here is by its very design not > very flexible. I don't agree that this is a "serious limitation", and I don't think an abstract should list things that the document doesn't do. > * Introduction > > s/Furthermore,// Fixed. > 'In some cases' ... 'often' - hm is this something that is required > occasionally or often? There are more uses of fill words like > 'often' that do not really seem to be needed. Fixed. > s/new generic mechanism/new mechanism/ Fixed. > While I think I understand the difference made between > implementation-time and run-time, the description is somewhat > confusing since the run-time mount will also be exposed via YANG > library and hence defining implementation-time by 'defined by a > server implementor and is as stable as YANG library information of > the server' is somewhat fuzzy. I assume what you mean is that in the > case 2. the mounted schema is fixed at implementation time while in > the case 3. the mounted schema may vary and be discovered at > run-time. However, you do not define things this way but rather talk > about properties that do however not define things. Howabout: OLD: + Run-time: the mounted schema is defined by instance data that is part of the mounted data model. If there are multiple instances of the same mount point (e.g., in multiple entries of a list), the mounted data model may be different for each instance. NEW: + Run-time: the mounted schema can vary at run time and is defined by instance data that is part of the mounted data model. If there are multiple instances of the same mount point (e.g., in multiple entries of a list), the mounted data model may be different for each instance. > * Glossary of New Terms > > o top-level schema: a schema according to [RFC7950] in which schema > trees of each module (except augments) start at the root node. > > You do not import 'schema' from RFC 7950 since, well, it is not > defined in RFC 7950. I think you often mean a schema tree (as > defined in RFC 7950) when you use 'schema'. Well, even this is not > true since a 'schema tree' according to RFC 7950 is scoped to a > module. RFC 8342 defines a 'datastore schema' but then I am not sure > this corresponds to 'schema' as used in this draft. In fact, the > mounted schema may be considered part of the 'datastore schema'. I > think we are handwaving with our terminology here but then perhaps I > am the only one who cares... I have imported "schema tree" from 7950, and changed teh definition of top-level schema to: - top-level schema: a set of modules in which the schema trees of each module (except augments) start at the root node. > What we actually have are schema tree (of a module per RFC 7950) and > a collection of schema trees sharing a common root (this is likely > what is meant with "schema" in this document). And then schema mount > simply provides a mechanism to have additional (statically defined) > roots in a schema. > > * Specification of the Mounted Schema > > I still struggle with the term 'inline' (and to a lesser extend with > 'shared'). I am likely in the minority. These terms are not perfect, but hopefully well-defined. > * Multiple Levels of Schema Mount > > What is a 'subschema'? What is a 'schema level'? Is a subschema the > same as a schema, i.e. a collection of schema trees with a common > root? If we need terms such as 'subschema' or 'schema level', then > we should define them. But perhaps just some tweaking the text to > avoid new terms can solve the issue. I have changed "subschema" to "schema", and removed "schema level": NEW: YANG modules in a mounted schema MAY again contain mount points under which other schemas can be mounted. Consequently, it is possible to construct data models with an arbitrary number of mounted schemas. A schema for a mount point contained in a mounted module can be specified by implementing "ietf-yang-library" and "ietf-yang-schema-mount" modules in the mounted schema, and specifying the schemas exactly as it is done in the top-level schema. > * Referring to Data Nodes in the Parent Schema > > I stumbled across this here but in general is 'data model' the same > as 'schema'? Note that the text in section 4 talks about 'mounted > data model' and 'top-level data model' and 'mounted data model' but > elsewhere you talk about * schemas. Perhaps using just one term is > better and more consistent? Yes, done. Now using "schema" only. > Why are parent-references only useful for the 'shared-schema' case? > An 'inline' mount can't refer to stuff outside the mount jail? Correct. We have debated if this makes sense for inline or not. As it is, the model is designed so that this can be added in the future, if it turns out that this is needed. > Looking at the YANG definition of 'parent-reference', I am left > somewhat clueless in which situations these xpath expressions are > evaluations and when the nodesets are merged with other xpath > expression evaluation results. The YANG module says: When XPath expressions in the mounted schema are evaluated, the 'parent-reference' leaf-list is taken into account. and For the purposes of evaluating XPath expressions whose context nodes are defined in the mounted schema, the union of all these nodesets together with ancestor nodes are added to the accessible data tree. > It seems that these parent references > are the only actual difference between 'inline' and 'shared-schema' > mounts. > > * Data Model > > I have not really understood what the difference between 'inline' > and 'shared-schema' is. I understand that the later can have > 'parent-references' but it is unclear why the other can't and if > there is not strong architectural reason why there have to be two > choices. It also seems that the 'namespace' list is only meaningful > if there are parent references, no? So why is this then global, i.e. > also provided for 'inline' mounts? As you note, the 'namespace' list is global, so there is just one list that covers all mount-points. It's not really correct to state that the 'namespace' list is "provided for 'inline' mounts". > I guess I do not really > understand the distinction. If there are no parent-references, what > is the difference between 'shared-schema' and 'inline'? The difference is that shared-schema can have parent-references, and that all instances of such a mount point have exactly the same schema. > * Security Considerations > > I agree with others that something needs to be said how NACM applies > to mounted schemas. I have added the following (short) section: 7. Interaction with the Network Configuration Access Control Model (NACM) If NACM [RFC8341] is implemented on a server, it can be used to control access to nodes defined by the mounted schema in the same way as for nodes defined by the top-level schema. For example, suppose the module "ietf-interfaces" is mounted in the "root" container in the "logical-network-element" list defined in [I-D.ietf-rtgwg-lne-model]. Then the following NACM path can be used to control access to the "interfaces" container (where the character '\' is used where a line break has been inserted for formatting reasons): /lne:logical-network-elements\ /lne:logical-network-element/lne:root/if:interfaces /martin From nobody Thu Apr 5 05:43:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CAA127201 for ; Thu, 5 Apr 2018 05:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7FHzmL7mR4B for ; Thu, 5 Apr 2018 05:43:51 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 01C99127419 for ; Thu, 5 Apr 2018 05:43:51 -0700 (PDT) Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id D74791AE047B; Thu, 5 Apr 2018 14:43:49 +0200 (CEST) Date: Thu, 05 Apr 2018 14:43:49 +0200 (CEST) Message-Id: <20180405.144349.1531327560930954458.mbj@tail-f.com> To: rohitrranade@outlook.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180329.092953.1063547768163198657.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] Comments on schema mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 12:43:54 -0000 SGksDQoNCg0KUm9oaXQgUmFuYWRlIDxyb2hpdHJyYW5hZGVAb3V0bG9vay5jb20+IHdyb3RlOg0K PiBIaSBNYXJ0aW4sDQo+IA0KPiANCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciByZXNwb25zZXMu DQo+IA0KPiBJIGhhdmUgZ29uZSB0aHJvdWdoIHRoZSBMTkUgZHJhZnQgYW5kIFlBTkcgMS4xIGFu ZCBmb3VuZCBzb21lIG1vcmUgc3VnZ2VzdGlvbnMuDQo+IA0KPiANCj4gDQo+IDEuIFNlY3Rpb24g NQ0KPiANCj4gICAgIklmIGEgbW91bnRlZCBZQU5HIG1vZHVsZSBkZWZpbmVzIGFuIFJQQyBvcGVy YXRpb24sIGNsaWVudHMgY2FuIGludm9rZQ0KPiANCj4gICAgdGhpcyBvcGVyYXRpb24gYXMgaWYg aXQgd2VyZSBkZWZpbmVkIGFzIGFuIGFjdGlvbiBmb3IgdGhlDQo+IA0KPiAgICBjb3JyZXNwb25k aW5nIG1vdW50IHBvaW50Ig0KPiANCj4gICAgPT0+IEJlbG93IGlzIHRoZSBleGFtcGxlIGZyb20g WWFuZyAxLjEgU2VjdGlvbiA3LjE1DQo+IA0KPiANCj4gDQo+ICAgICA8cnBjIG1lc3NhZ2UtaWQ9 IjEwMSINCj4gDQo+ICAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOmJhc2U6MS4wIj4NCj4gDQo+ICAgICAgICA8YWN0aW9uIHhtbG5zPSJ1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOnlhbmc6MSI+DQo+IA0KPiAgICAgICAgICA8c2VydmVyIHhtbG5zPSJ1cm46ZXhh bXBsZTpzZXJ2ZXItZmFybSI+DQo+IA0KPiAgICAgICAgICAgIDxuYW1lPmFwYWNoZS0xPC9uYW1l Pg0KPiANCj4gICAgICAgICAgICA8cmVzZXQ+DQo+IA0KPiAgICAgICAgICAgICAgPHJlc2V0LWF0 PjIwMTQtMDctMjlUMTM6NDI6MDBaPC9yZXNldC1hdD4NCj4gDQo+ICAgICAgICAgICAgPC9yZXNl dD4NCj4gDQo+ICAgICAgICAgIDwvc2VydmVyPg0KPiANCj4gICAgICAgIDwvYWN0aW9uPg0KPiAN Cj4gICAgICA8L3JwYz4NCj4gDQo+IA0KPiANCj4gICAgICA8cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9 IjEwMSINCj4gDQo+ICAgICAgICAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpu czpuZXRjb25mOmJhc2U6MS4wIj4NCj4gDQo+ICAgICAgICA8cmVzZXQtZmluaXNoZWQtYXQgeG1s bnM9InVybjpleGFtcGxlOnNlcnZlci1mYXJtIj4NCj4gDQo+ICAgICAgICAgIDIwMTQtMDctMjlU MTM6NDI6MTJaDQo+IA0KPiAgICAgICAgPC9yZXNldC1maW5pc2hlZC1hdD4NCj4gDQo+ICAgICAg PC9ycGMtcmVwbHk+DQo+IA0KPiAgICAgICAgICAgICAgID09PiBIZXJlIHJwYy1yZXBseSBvbmx5 IGhhcyB0aGUgbmFtZXNwYWNlIGFuZCBhY3Rpb24gbmFtZSBkZWZpbmVkIGluIHRoZSBtb3VudC1p bnN0YW5jZSdzIG1vZHVsZS4NCj4gDQo+ICAgICAgICAgICAgICAgVGhlIGNsaWVudCBuZWVkcyB0 byBzdG9yZSBpbmZvcm1hdGlvbiBvZiB0aGUgbW91bnQtaW5zdGFuY2UgZm9yIHdoaWNoIHRoZSBS UEMgcmVxdWVzdCB3YXMgc2VudCBhbmQgb25seSB0aGVuIGl0IGNhbiB2YWxpZGF0ZSB0aGUgcnBj LXJlcGx5IGFnYWluc3QgdGhlIGRhdGEtbW9kZWwuDQo+IA0KPiAgICAgICAgICAgICAgIFRvIGF2 b2lkIHRoaXMgd29yayBvZiBjbGllbnQsIHdoZXRoZXIgd2UgY2FuIHRoaW5rIG9mIGFkZGluZyBt ZXRhLWRhdGEgdG8gcnBjLXJlcGx5IHRvIHByb3ZpZGUgdGhpcyBpbmZvcm1hdGlvbiB0byBjbGll bnQuDQoNCklmIHRoZSBjbGllbnQgaW52b2tlcyBhbiBhY3Rpb24sIGl0IGlzIGV4cGVjdGVkIHRo YXQgaXQga25vd3MgaG93IHRvDQppbnRlcnByZXQgdGhlIHJlc3VsdC4gIFRoaXMgZG9lcyBub3Qg Y2hhbmdlIHdpdGggdGhlIGludHJvZHVjdGlvbiBvZg0Kc2NoZW1hIG1vdW50LiAgVGhlIGNsaWVu dCBvYnZpb3VzbHkga25vd3MgdGhlIG5hbWUgYW5kIGlucHV0DQpwYXJhbWV0ZXJzIG9mIHRoZSBh Y3Rpb24sIHNvIGl0IHNlZW1zIHJlc29uYWJsZSB0byBleHBlY3QgdGhhdCBpdA0Ka25vd3MgdGhl IG91dHB1dCBwYXJhbWV0ZXJzIGFzIHdlbGwsIHcvbyBhbnkgYWRkaXRpb25hbCBtZXRhIGRhdGEu DQoNCj4gMi4gU2VjdGlvbiA1DQo+IA0KPiAgICBJIHdvdWxkIHByZWZlciB0aGUgYXBwcm9hY2gg dGFrZW4gYnkgWWFuZyAxLjEgd2hlcmUgc3RhdGVtZW50cyBmb2xsb3dlZCBieSBYTUwgZXhhbXBs ZXMgICB0byBoZWxwIGluIGNsYXJpdHkuDQo+IA0KPiAgICBFc3BlY2lhbGx5IGZvciB0aGUgUlBD IGFuZCBub3RpZmljYXRpb24gc2VjdGlvbiwgaXQgaXMgYmV0dGVyIHRvIGFkZCBjbGVhciBleGFt cGxlcw0KPiANCj4gICAgaW4gYSAiVXNhZ2UgRXhhbXBsZSIgc3ViLXNlY3Rpb24gZm9yIHRoaXMg c2VjdGlvbi4NCg0KVGhlIGV4YW1wbGVzIGFyZSBnaXZlbiBpbiB0aGUgYXBwZW5kaXgsIGFuZCB0 aGVyZSBpcyBhIGZvcndhcmQNCnJlZmVyZW5jZSB0byB0aGUgYXBwZW5kaXggZnJvbSBzZWN0aW9u IDUuDQoNCg0KPiAzLiBZYW5nIFJQQyBhbmQgQUNUSU9OIHN0YXRlbWVudHM6DQo+IA0KPiAgIElm IHdlIG5lZWQgdG8gdmlldyB0aGUgUlBDIGRlZmluZWQgaW4gYSBtb2R1bGUgYXMgYW4gQUNUSU9O IGFmdGVyIHNjaGVtYSBtb3VudCwgdGhlbg0KPiANCj4gICBXaGVuZXZlciB0aGVyZSBpcyB1cGRh dGUgdG8gUlBDIGluIHNheSBZQU5HIDEuMiwgdGhlbiB0aGUgY29ycmVzcG9uZGluZyBjaGFuZ2Vz IG11c3QgYmUgcHJlc2VudCBpbiBBQ1RJT04gYWxzbywgaW50cm9kdWNpbmcgYSBjb3VwbGluZyBi ZXR3ZWVuIFJQQyBhbmQgQUNUSU9OIHN0YXRlbWVudHMuDQoNClRoaXMgbW9kdWxlIGlzIHdyaXR0 ZW4gdXNpbmcgWUFORyAxLjEuICBVbmxlc3MgdGhpcyBtb2R1bGUgaXMgdXBkYXRlZCwNCml0IGRv ZXNuJ3QgbWF0dGVyIHdoYXQgWUFORyAyLjAgb3Igd2hhdGV2ZXIgZG9lcy4NCg0KPiA0LiBORVRD T05GIGhhcyBzb21lICJycGMiIHdoaWNoIHdvcmsgb24gbXVsdGlwbGUgbW91bnQtaW5zdGFuY2Vz Lg0KPiANCj4gICAgPT0+IEZvciBleGFtcGxlIDxlZGl0LWNvbmZpZz4gLCA8Z2V0LWNvbmZpZz4g b3IgPGxvY2s+LiBXaGV0aGVyIHdlIG5lZWQgdG8gZ2l2ZSBhDQo+IA0KPiAgICBndWlkZWxpbmUg Zm9yIGhvdyB0byBoYW5kbGUgc3VjaCAicnBjIiwgc28gdGhhdCBvdGhlciBwcm90b2NvbHMgd2hp Y2ggaW1wbGVtZW50IHNjaGVtYSBtb3VudCAgIGFsc28gYWRhcHQgYWNjb3JkaW5nbHkgPw0KPiAN Cj4gICAgRWc6IFNvbWV0aGluZyBsaWtlLCBmb3IgdHJhbnNhY3Rpb24gbWFuYWdlbWVudCwgYmV0 dGVyIHRvIG9wZXJhdGUgb24gb25lIG1vdW50LWluc3RhbmNlLg0KDQpUaGlzIHdvdWxkIG5vdCBi ZSBjb3JyZWN0LiAgSSB0aGluayB5b3UgYXJlIGFzc3VtaW5nIG9uZSB1c2UgY2FzZTsNCndoZXJl IHNjaGVtYSBtb3VudCBpcyB1c2VkIGluIGEgKHByaW1pdGl2ZSkgb3JjaGVzdHJhdG9yIHRoYXQg YWN0dWFsbHkNCnRhbGtzIHRvIG11bHRpcGxlIGRldmljZXMgKHcvbyB0cmFuc2FjdGlvbiBjb250 cm9sKS4NCg0KTm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQganVzdCBkZWZpbmVzIGhvdyB0aGUgKnNj aGVtYSogaXMgYnVpbHQ7IG5vdA0KaG93IGluc3RhbmNlIGRhdGEgaXMgc3RvcmVkIG9yIGFjY2Vz c2VkLg0KDQoNCg0KL21hcnRpbg0KDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBXaXRo IFJlZ2FyZHMsDQo+IA0KPiBSb2hpdCBSDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IEZyb206IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29t Pg0KPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMjksIDIwMTggMTI6NTk6NTMgUE0NCj4gVG86IHJv aGl0cnJhbmFkZUBvdXRsb29rLmNvbQ0KPiBDYzogbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbbmV0bW9kXSBDb21tZW50cyBvbiBzY2hlbWEgbW91bnQgZHJhZnQNCj4gDQo+IEhpLA0K PiANCj4gUm9oaXQgUmFuYWRlIDxyb2hpdHJyYW5hZGVAb3V0bG9vay5jb20+IHdyb3RlOg0KPiA+ IEhpIE1hcnRpbiwNCj4gPg0KPiA+IFcuci50IDxnZXQtc2NoZW1hPiBvbiB0aGUgbWFpbiBkZXZp Y2UsIGl0IHdpbGwgbWVhbiB0aGF0IGZvcg0KPiA+IHN1Y2Nlc3NmdWwgPGdldC1zY2hlbWE+IGZv ciBhbGwgdGhlIHNjaGVtYSBvZiBtb3VudGVkIGRldmljZXMsIHRoZQ0KPiA+IG1haW4gZGV2aWNl IG11c3QgYmUgdXBncmFkZWQgdG8gaGlnaGVyIHZlcnNpb24gZmlyc3QgYW5kIG11c3QgY29udGFp bg0KPiA+IEFMTCB0aGUgc2NoZW1hIG9mIGFsbCB0aGUgZGV2aWNlcyBiZWhpbmQgdGhlIG1haW4g ZGV2aWNlLg0KPiANCj4gVGhpcyBpcyBub3QgdGhlIGludGVudGlvbiwgYW5kIGFzIHlvdSBub3Rl LCBpbiBtYW55IGNhc2VzIHRoaXMgaXMganVzdA0KPiBub3QgcG9zc2libGUuDQo+IA0KPiBUaGUg Y2xpZW50IGNhbiBsb29rIGF0IHRoZSAibG9jYXRpb24iIGxlYWYgaW4gdGhlIG1vdW50ZWQgWUFO RyBsaWJyYXJ5DQo+IChpbiBZTGJpczsgaW4gb2xkIFlMIGl0IHdhcyBjYWxsZWQgInNjaGVtYSIp IGFuZCBnZXQgdGhlIG1vZHVsZSBmcm9tDQo+IHRoZXJlLg0KPiANCj4gSWYgdGhlIG1vdW50ZWQg c2NoZW1hIGFsc28gbW91bnRzICJpZXRmLW5ldGNvbmYtbW9uaXRvcmluZyIsIHRoZQ0KPiBjbGll bnQgY2FuIGludm9rZSB0aGUgbW91bnRlZCA8Z2V0LXNjaGVtYT4gYXMgYW4gYWN0aW9uLCBhbmQg cmV0cmlldmUNCj4gdGhlIHNwZWNpZmljIHZlcnNpb24gb2YgdGhlIG1vZHVsZSB0aGF0IGlzIG1v dW50ZWQgdGhlcmUuDQo+IA0KPiA+IFRoaXMgcG9pbnQgbWF5IHByb3ZlIHRvIGJlIHRyaWNreSBh cyB0aGUgd2hvbGUgdG9wb2xvZ3kgdXBncmFkZSBoYXMgdG8NCj4gPiBiZSBjb25zaWRlcmVkIGFs d2F5cy4gSSBmZWVsIHdlIGNhbiBhZGQgc29tZSB0ZXh0IHJlZ2FyZGluZyB0aGlzLg0KPiA+DQo+ ID4gQWxzbyBob3cgdG8g4oCcbW91bnTigJ0gYW4gaW5zdGFuY2Ugb2YgYSBtb3VudC1wb2ludCA/ IEJlY2F1c2Ugb25jZSB0aGlzDQo+ID4gZHJhZnQgaXMgb3V0LCBlYWNoIGltcGxlbWVudGVyIG1h eSBkZWZpbmUgcHJpdmF0ZSBSUENzIGZvciBtb3VudCBhbmQNCj4gPiB1bi1tb3VudCBpZiB0aGlz IG1vZHVsZSBkb2VzIG5vdCBkZWZpbmUgaXQuIFdoZXRoZXIgYW55IHBsYW4gYWJvdXQgaXQNCj4g PiA/DQo+IA0KPiBOb3RlIHRoYXQgc2NoZW1hIG1vdW50IGlzIG5vdCBhYm91dCBtb3VudGluZyBk ZXZpY2VzOyB0aGF0IHdvdWxkIGJlIGENCj4gZnV0dXJlIHNwZWNpYWxpemF0aW9uIG9mIHRoaXMg bWVjaGFuaXNtLg0KPiANCj4gSW4gdGhlIExORSBhbmQgTkkgZHJhZnRzLCBlbnRpdGllcyBhcmUg Im1vdW50ZWQiIGJ5IGNyZWF0aW5nIGVudHJpZXMNCj4gaW4gdGhlIGNvcnJlc3BvbmRpbmcgbGlz dHMuICBUaGVyZSBpcyBubyBuZWVkIGZvciBhICJtb3VudCIgcnBjIGluDQo+IHRoZXNlIGNhc2Vz Lg0KPiANCj4gDQo+IC9tYXJ0aW4NCj4gDQo+IA0KPiANCj4gDQo+ID4NCj4gPg0KPiA+DQo+ID4N Cj4gPiBXaXRoIFJlZ2FyZHMsDQo+ID4gUm9oaXQgUg0KPiA+DQo+ID4gU2VudCBmcm9tIE1haWw8 aHR0cHM6Ly9nby5taWNyb3NvZnQuY29tL2Z3bGluay8/TGlua0lkPTU1MDk4Nj4gZm9yDQo+ID4g V2luZG93cyAxMA0KPiA+DQo+ID4gRnJvbTogTWFydGluIEJqb3JrbHVuZDxtYWlsdG86bWJqQHRh aWwtZi5jb20+DQo+ID4gU2VudDogMjYg4KSu4KS+4KSw4KWN4KSaIDIwMTggMTM6NDENCj4gPiBU bzogcm9oaXRycmFuYWRlQG91dGxvb2suY29tPG1haWx0bzpyb2hpdHJyYW5hZGVAb3V0bG9vay5j b20+DQo+ID4gQ2M6IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KPiA+ IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBDb21tZW50cyBvbiBzY2hlbWEgbW91bnQgZHJhZnQNCj4g Pg0KPiA+IEhpLA0KPiA+DQo+ID4gVGhhbmsgeW91IGZvciB0aGVzZSBjb21tZW50cywgcmVwbGll cyBpbmxpbmUuDQo+ID4NCj4gPiBSb2hpdCBSYW5hZGUgPHJvaGl0cnJhbmFkZUBvdXRsb29rLmNv bT4gd3JvdGU6DQo+ID4gPiBIaSBBbGwsDQo+ID4gPg0KPiA+ID4gUGxlYXNlIGZpbmQgc29tZSBj b21tZW50cyBmb3IgdGhlIHNjaGVtYSBtb3VudCBkcmFmdC4gSWYgSSBmaW5kIGFueQ0KPiA+ID4g b3RoZXIgd2lsbCBzZW5kIGluIGFub3RoZXIgbWFpbC4NCj4gPiA+DQo+ID4gPiBFZGl0b3JpYWw6 DQo+ID4gPiA9PT09PT09PT09PT0NCj4gPiA+IDEuIFNlY3Rpb24gMy4xDQo+ID4gPiAgICAiVGhl ICJtb3VudC1wb2ludCIgc3RhdGVtZW50IE1VU1QgTk9UIGJlIHVzZWQgaW4gYSBZQU5HIHZlcnNp b24gMQ0KPiA+ID4gICAgbW9kdWxlLiINCj4gPiA+ICAgID09PiBJdCBpcyB1bmNsZWFyIHdoeSBz dWNoIGEgcmVzdHJpY3Rpb24gaXMgcGxhY2VkLg0KPiA+DQo+ID4gVGhlIHJlYXNvbiBpcyB0aGF0 IFlBTkcgMSBkb2Vzbid0IHN1cHBvcnQgaW5saW5lIGFjdGlvbnMgYW5kDQo+ID4gbm90aWZpY2F0 aW9uLCB3aGljaCBtZWFucyB0aGF0IHRvcC1sZXZlbCBycGNzIGFuZCBub3RpZnMgaW4gdGhlDQo+ ID4gbW91bnRlZCBtb2R1bGUgY2Fubm90IGJlIGludm9rZWQgdXNpbmcgdGhlIG1lY2hhbmlzbSBk ZXNjcmliZWQgaW4NCj4gPiBzZWN0aW9uIDUuICBJIHdpbGwgdHJ5IHRvIGNsYXJpZnkgdGhpcy4N Cj4gPg0KPiA+ID4gMi4gU2VjdGlvbiAzLjINCj4gPiA+ICAgICJzdGF0ZSBkYXRhIGluIHRoZSAi eWFuZ21udDpzY2hlbWEtbW91bnRzIiINCj4gPiA+ICAgID09PiBIZXJlIHRoZSB5YW5nIHRyZWUg ZGlhZ3JhbSBpcyBub3QgeWV0IGludHJvZHVjZWQuIEkgZmVlbCBiZXR0ZXIgdG8NCj4gPiA+ICAg IGludHJvZHVjZQ0KPiA+ID4gICAgdGhpcyBkaWFncmFtIGFzIGl0IG1ha2VzIGl0IGVhc2llciB0 byB1bmRlcnN0YW5kIHRoZSBkYXRhLW5vZGVzDQo+ID4NCj4gPiBPay4gIEkgbW92ZWQgc2VjdGlv biA4IHRvIGEgbmV3IHNlY3Rpb24gMy4yLg0KPiA+DQo+ID4gPiAzLiBTZWN0aW9uIDMuMg0KPiA+ ID4gICAgIkRhdGEgaW4gdGhpcyBjb250YWluZXIgaXMgaW50ZW5kZWQgdG8gYmUgYXMgc3RhYmxl IGFzIGRhdGEgaW4gdGhlDQo+ID4gPiAgICB0b3AtbGV2ZWwgWUFORyBsaWJyYXJ5Ig0KPiA+ID4g ICAgPT0+IFdoYXQgaXMgdGhlIG1lYW5pbmcgb2YgImFzIHN0YWJsZSIgYXMgPyBBcyBhIGRldmVs b3BlciAsIEkgYW0NCj4gPiA+ICAgIHVuY2xlYXIgd2hhdCBuZWVkcw0KPiA+ID4gICAgdG8gYmUg ZG9uZSBoZXJlLiBQbGVhc2UgY2xhcmlmeS4NCj4gPg0KPiA+IEtlbnQgYWxzbyBoYWQgYSBjb21t ZW50IGFyb3VuZCB0aGlzLCBhbmQgdGhlIHRleHQgYWJvdXQgc3RhYmxlIGlzIG5vdw0KPiA+IHJl bW92ZWQuDQo+ID4NCj4gPiA+IDQuIFNlY3Rpb24gMy4yDQo+ID4gPiAgICAiaS5lLiwgaW5zdGFu Y2VzIG9mIHRoYXQgbW91bnQgcG9pbnQgTVVTVCBOT1QgY29udGFpbiBhbnkgZGF0YSBhYm92ZQ0K PiA+ID4gICAgdGhvc2UgdGhhdCBhcmUgZGVmaW5lZCBpbiB0aGUgcGFyZW50IHNjaGVtYS4iDQo+ ID4gPiAgICA9PT4gSGVyZSAiYW55IGRhdGEgYWJvdmUiLCBtZWFucyAiYWJvdmUiIGluIHRoZSBo aWVhcmFyY2h5ID8NCj4gPg0KPiA+IE5vLCB0aGlzIHdhcyBqdXN0IHdyb25nOyBpdCBzaG91bGQg YmUgImV4Y2VwdCIuDQo+ID4NCj4gPiA+ICAgIE5vdA0KPiA+ID4gICAgY2xlYXIsIHRoaXMgaXMg c2ltaWxhcg0KPiA+ID4gICAgdG8gaGF2aW5nIGEgVVNCIHNsb3QsIGJ1dCBubyBkZXZpY2UgbW91 bnRlZCBvbiBpdCBhcyB5ZXQgaW4gVU5JWA0KPiA+ID4gICAgdGVybXMuIFJpZ2h0ID8NCj4gPiA+ ICAgIFRoZSBxdWVyeSBvdXRwdXQgb24gcGFyZW50LXNjaGVtYSBzaG91bGQgZ2l2ZSBlbXB0eSBk YXRhLg0KPiA+ID4NCj4gPiA+IDUuIFNlY3Rpb24gMy4yDQo+ID4gPiAgICAiSWYgbXVsdGlwbGUg bW91bnQgcG9pbnRzIHdpdGggdGhlIHNhbWUgbmFtZSBhcmUgZGVmaW5lZCBpbiB0aGUgc2FtZQ0K PiA+ID4gICAgbW9kdWxlIC0gZWl0aGVyIGRpcmVjdGx5IG9yIGJlY2F1c2UgdGhlIG1vdW50IHBv aW50IGlzIGRlZmluZWQgaW4gYQ0KPiA+ID4gICAgZ3JvdXBpbmcgYW5kIHRoZSBncm91cGluZyBp cyB1c2VkIG11bHRpcGxlIHRpbWVzIC0gdGhlbiB0aGUNCj4gPiA+ICAgIGNvcnJlc3BvbmRpbmcg Im1vdW50LXBvaW50IiBlbnRyeSBhcHBsaWVzIGVxdWFsbHkgdG8gYWxsIHN1Y2ggbW91bnQNCj4g PiA+ICAgIHBvaW50cy4iDQo+ID4gPiAgID09PiBBcyBwZXIgdHJlZSBkaWFncmFtLCAibW91bnQt cG9pbnQiIGhhcyB0d28ga2V5cy4gU28gZWFjaCBtb2R1bGUNCj4gPiA+ICAgY2FuIGhhdmUgbXVs dGlwbGUNCj4gPiA+ICAgbW91bnQgcG9pbnRzLiBTbyBob3cgdG8gYXBwbHkgaXQgImVxdWFsbHki ID8gTm90IGNsZWFyLg0KPiA+DQo+ID4gTm90ZSB0aGF0IHRoZSBzZW50ZW5jZSBzdGFydHMgd2l0 aCAiSWYgbXVsdGlwbGUgbW91bnQgcG9pbnRzIHdpdGggdGhlDQo+ID4gc2FtZSBuYW1lIGFyZSBk ZWZpbmVkIGluIHRoZSBzYW1lIG1vZHVsZSIgLS0gc28gdGhpcyBjbGVhcmx5IGRvZXNuJ3QNCj4g PiBhcHBseSB0byBtb3VudCBwb2ludHMgd2l0aCBkaWZmZXJlbnQgbmFtZXMsIHJpZ2h0Pw0KPiA+ DQo+ID4gRm9yIGV4YW1wbGUsIHlvdSBjYW4gaGF2ZToNCj4gPg0KPiA+ICAgY29udGFpbmVyIGZv byB7DQo+ID4gICAgIHlhbmdtbnQ6bW91bnQtcG9pbnQgbXktbW50LXBvaW50Ow0KPiA+ICAgfQ0K PiA+ICAgY29udGFpbmVyIGJhciB7DQo+ID4gICAgIHlhbmdtbnQ6bW91bnQtcG9pbnQgbXktbW50 LXBvaW50Ow0KPiA+ICAgfQ0KPiA+DQo+ID4gVGhlcmUgaXMganVzdCBvbmUgZW50cnkgaW4gdGhl ICJtb3VudC1wb2ludCIgbGlzdCwgc28gdGhhdCBlbnRyeQ0KPiA+IGFwcGxpZXMgdG8gYm90aCB0 aGVzZSBtb3VudCBwb2ludHMuICBCb3RoIGFyZSBlaXRoZXIgImlubGluZSIgb3INCj4gPiAic2hh cmVkLXNjaGVtYSIuDQo+ID4NCj4gPg0KPiA+ID4gNi4gU2VjdGlvbiAzLjINCj4gPiA+ICAgIElu c3RlYWQgb2YgImlubGluZSIgYW5kICJzaGFyZWQtc2NoZW1hIiwgSSBzdWdnZXN0IHRvIHVzZQ0K PiA+ID4gICAgInZhcmlhYmxlLXNjaGVtYSIgYW5kDQo+ID4gPiAgICAic2FtZS1zY2hlbWEiDQo+ ID4gPiAgICBSZWFzb246IFRoZSBrZXkgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28gaXMgdGhh dCBpbiBvbmUgY2FzZSwgdGhlDQo+ID4gPiAgICBzY2hlbWEgTUFZIGJlIGRpZmZlcmVudA0KPiA+ ID4gICAgd2hpbGUgaW4gdGhlIG90aGVyIHRoZSBzY2hlbWEgaXMgc2FtZS4gVGhlIG5hbWUgY2Fu IGJlIHNpbWlsYXIgdG8gdGhlDQo+ID4gPiAgICByZWFzb24uDQo+ID4NCj4gPiBBdCB0aGlzIHBv aW50LCB3ZSBoYXZlIHRvIGxpdmUgd2l0aCB0aGVzZSB0ZXJtcy4gIFRoaXMgd2FzIHBhcnQgb2Yg dGhlDQo+ID4gY29tcHJvbWlzZSBsZWFkaW5nIHRvIHRoaXMgc29sdXRpb247IHRoZXJlIGFyZSBv dGhlciBkb2N1bWVudHMgaW4gdGhlDQo+ID4gUkZDIGVkaXRvcidzIHF1ZXVlIHRoYXQgZGVwZW5k IG9uIHRoZXNlIHRlcm1zLg0KPiA+DQo+ID4gPiBMb2dpY2FsIFBvaW50Og0KPiA+ID4gMS4gQ29u c2lkZXIgdGhlIHRvcG9sb2d5IHdoZXJlIDEgbWFpbiBkZXZpY2UgaXMgcHJlc2VudCB3aXRoIE4g bG9naWNhbA0KPiA+ID4gZGV2aWNlcyBiZWhpbmQgaXQuDQo+ID4gPiAgICBXaGVuIHRoZSBtb3Vu dGluZyBpcyBkb25lLCBpdCBpcyBxdWl0ZSBwb3NzaWJsZSB0aGF0IHNvbWUgb2YgTiBkZXZpY2Vz DQo+ID4gPiAgICBhcmUgaGF2aW5nIGRpZmZlcmVudA0KPiA+ID4gICAgdmVyc2lvbnMgb2YgbW9k dWxlcy4NCj4gPiA+ICAgIFRoaXMgY2FuIGxlYWQgdG8gZWFjaCBpbnN0YW5jZSBvZiBtb3VudCBw b2ludCwgaGF2aW5nIGRpZmZlcmVudA0KPiA+ID4gICAgc2NoZW1hLg0KPiA+ID4gICAgSG93IGNh biB0aGUgY2xpZW50IHVuZGVyc3RhbmQgdGhlIHNjaGVtYSBvZiBlYWNoIG1vdW50LXBvaW50IGlu c3RhbmNlDQo+ID4gPiAgICA/IFByZWZlcmFibHkgZ2V0LXNjaGVtYSBvZiB0aGVzZSBkZXZpY2Vz IGFuZCB0aGVuIGtub3cgdGhlIG1vZGVsID8NCj4gPg0KPiA+IFRoaXMgZHJhZnQgc2F5cyB0aGF0 IGVhY2ggaW5zdGFuY2Ugd2lsbCBoYXZlIGl0cyBvd24gWUFORyBsaWJyYXJ5DQo+ID4gaW5zdGFu Y2UuICBTbyB0aGVyZSB0aGUgY2xpZW50IGNhbiBkZXRlY3Qgd2hpY2ggdmVyc2lvbnMgb2YgdGhl DQo+ID4gZGlmZmVyZW50IG1vZHVsZXMgZWFjaCBpbnN0YW5jZSBzdXBwb3J0cy4gIFRoZW4gPGdl dC1zY2hlbWE+IGNhbiBiZQ0KPiA+IGludm9rZWQgdG8gZ2V0IHRoZSBtb2R1bGVzLCBpZiBpdCBp cyBzdXBwb3J0ZWQuDQo+ID4NCj4gPg0KPiA+IC9tYXJ0aW4NCj4gPg0K From nobody Thu Apr 5 16:32:42 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0ED12D873; Thu, 5 Apr 2018 16:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGsaW4Ldqwjt; Thu, 5 Apr 2018 16:32:38 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6315128C0A; Thu, 5 Apr 2018 16:32:38 -0700 (PDT) Received: from MBP.local ([IPv6:2601:647:4201:9671:5dff:d0f4:bb13:8bf]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w35NWbC5010882 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 5 Apr 2018 23:32:38 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9671:5dff:d0f4:bb13:8bf] claimed to be MBP.local From: joel jaeggli To: NETMOD Working Group Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org References: <1e76e07f-544a-1582-ef71-e804ebd97a14@bogus.com> <33b1ee08-c8dc-ea5b-3246-365f8af1d294@bogus.com> Openpgp: preference=signencrypt Autocrypt: addr=joelja@bogus.com; prefer-encrypt=mutual; keydata= xsDiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfms0fSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPsJjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiazsNNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8HCRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w= Message-ID: Date: Thu, 5 Apr 2018 16:32:37 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <33b1ee08-c8dc-ea5b-3246-365f8af1d294@bogus.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Xg3mZ1GEkmP4ZiXheXyRVPT6TJXV6UaH9" Archived-At: Subject: [netmod] Completion: WGLC - draft-ietf-netmod-schema-mount (version 09) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 23:32:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xg3mZ1GEkmP4ZiXheXyRVPT6TJXV6UaH9 Content-Type: multipart/mixed; boundary="J9Blb1G2ouwFUuRNVmYpu8775Gbho5H12"; protected-headers="v1" From: joel jaeggli To: NETMOD Working Group Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org Message-ID: Subject: Completion: WGLC - draft-ietf-netmod-schema-mount (version 09) References: <1e76e07f-544a-1582-ef71-e804ebd97a14@bogus.com> <33b1ee08-c8dc-ea5b-3246-365f8af1d294@bogus.com> In-Reply-To: <33b1ee08-c8dc-ea5b-3246-365f8af1d294@bogus.com> --J9Blb1G2ouwFUuRNVmYpu8775Gbho5H12 Content-Type: multipart/alternative; boundary="------------B65EC4C459B96113EEE7466C" Content-Language: en-US This is a multi-part message in MIME format. --------------B65EC4C459B96113EEE7466C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This working group last call completed Wednesday April 4th. It looks like there are no outstanding discussion threads going on now, and the recent discussion has mostly been clarificatory. Editorial changes proposed as a result of WGLC review look largely superficial to schema mount itself. https://github.com/netmod-wg/schema-mount/commit/8ba2b284ec861c9ca65e6f7e= e65edba3ab071c36 As this is the second WGLC and is was immediately proceeded by a meeting to discuss the adjustment of the document between draft 08 (1ST WGLC) and draft 09 (2nd WGLC). I think we can conclude that there is consensus to proceed IESG processing and IETF last call. Thanks to everyone who contributed to this significant effort. NETMOD WG Chairs On 3/28/18 7:01 PM, joel jaeggli wrote: > Greetings, > > I hope that we are all recovered from the IETF meeting (or in my case a= n > impromptu ski holiday). > > Today we entered the second week on the last call for > > draft-ietf-netmod-schema-mount > > While I don't expect a lot of commentary given that we devoted an entir= e > meeting slot to it, currently we have a fresh reading of it from Ariel.= > > https://www.ietf.org/mail-archive/web/netmod/current/msg20741.html > > and some subsequent commentary > > This WGLC will conclude Wednesday April 4th. > > Thanks > > joel > > > On 3/21/18 7:04 AM, joel jaeggli wrote: >> Greetings, >> >> We are running a 2 week WGLC again on draft-ietf-netmod-schema-mount i= n >> order to review the proposed changes in draft 09. >> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ >> >> the 08 - 09 diff is available here: >> >> https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-netmod-schema-mount-08&= url2=3Ddraft-ietf-netmod-schema-mount-09 >> >> Please send email to the list indicating your support or concerns. >> >> We are particularly interested in statements of the form: >> >> * I have reviewed this draft and I prefer it to draft-08 >> * I have reviewed this draft and found no issues. >> * I have reviewed this draft and found the following issues: ... >> >> This WGLC will conclude Wednesday April 4th. >> >> Statements indicating there is no known IPR have already been made >> during the previous WGLC. If anyone is aware of new information >> regarding IPR they should make us aware of that as soon as feasible. >> >> Thank you, >> NETMOD WG Chairs >> >> >> >> >> >> > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------B65EC4C459B96113EEE7466C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

This working group last call completed Wednesday April 4th.

It looks like there are no outstanding discussion threads going on now, and the recent discussion has mostly been clarificatory.

Editorial changes proposed as a result of WGLC review look largely superficial to schema mount itself.

https= ://github.com/netmod-wg/schema-mount/commit/8ba2b284ec861c9ca65e6f7ee65ed= ba3ab071c36

As this is the second WGLC and is was immediately proceeded by a meeting to discuss the adjustment of the document between draft 08 (1ST WGLC) and draft 09 (2nd WGLC). I think we can conclude that there is consensus to proceed IESG processing and IETF last call.

Thanks to everyone who contributed to this significant effort.
= 

NETMOD WG Chairs

On 3/28/18 7:01 PM, joel jaeggli wrote= :
Greetings,

I hope that we are all recovered from the IETF meeting (or in my case an
impromptu ski holiday).

Today we entered the second week on the last call for

draft-ietf-netmod-schema-mount

While I don't expect a lot of commentary given that we devoted an entire
meeting slot to it, currently we have a fresh reading of it from Ariel.

https://www.ietf.org/mail-archive/w=
eb/netmod/current/msg20741.html

and some subsequent commentary

This WGLC will conclude Wednesday April 4th.

Thanks

joel


On 3/21/18 7:04 AM, joel jaeggli wrote:

Greetings,

We are running a 2 week WGLC again on draft-ietf-netmod-schema-mount in
order to review the proposed changes in draft 09.

https://datatracker.ietf.org/doc/draf=
t-ietf-netmod-schema-mount/

the 08 - 09 diff is available here:

https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-netmod-schema=
-mount-08&url2=3Ddraft-ietf-netmod-schema-mount-09

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

  * I have reviewed this draft and I prefer it to draft-08
  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...

This WGLC will conclude Wednesday April 4th.

Statements indicating there is no known IPR have already been made
during the previous WGLC. If anyone is aware of new information
regarding IPR they should make us aware of that as soon as feasible.

Thank you,
NETMOD WG Chairs











_______________________________________________
netmod mailing list
net=
mod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--------------B65EC4C459B96113EEE7466C-- --J9Blb1G2ouwFUuRNVmYpu8775Gbho5H12-- --Xg3mZ1GEkmP4ZiXheXyRVPT6TJXV6UaH9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCWsayFQAKCRDwADWrtn9W sszmAJ9LWfvKzP7MKj0WoPWhKX50GGINKgCdFtyusoSQrkrrbkmJGE99B/qV8LM= =qeS9 -----END PGP SIGNATURE----- --Xg3mZ1GEkmP4ZiXheXyRVPT6TJXV6UaH9-- From nobody Thu Apr 5 16:59:39 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4B712E6A3 for ; Thu, 5 Apr 2018 16:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCfvnvrFl1kp for ; Thu, 5 Apr 2018 16:59:35 -0700 (PDT) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D215F12E04B for ; Thu, 5 Apr 2018 16:59:35 -0700 (PDT) From: Alex Campbell To: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Thread-Topic: An abundant amount of IANA if types... Thread-Index: AdPMtsq1NhXOIRliRzmEujzHOstMAwAgxqsZ Date: Thu, 5 Apr 2018 23:59:34 +0000 Message-ID: <1522972773708.26374@Aviatnet.com> References: In-Reply-To: Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.9] Content-Type: multipart/alternative; boundary="_000_152297277370826374Aviatnetcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 23:59:37 -0000 --_000_152297277370826374Aviatnetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I haven't seen any previous discussions on the topic, but we have a similar= problem. Note this is not really to do with YANG itself, so much as the practical li= mitations of the software package that provides our CLI interface. In NETCONF, the existence of extra unused identities doesn't pose any probl= em. ________________________________ From: netmod on behalf of Bogaert, Bart (Nokia - = BE/Antwerp) Sent: Thursday, 5 April 2018 8:21 p.m. To: netmod@ietf.org Subject: [netmod] An abundant amount of IANA if types... Hi, We were wondering if it would make sense to introduce features in the IANA = if types YANG model to enable grouping of related interface types. This wo= uld allow implementations to include only the types it really requires (by = supporting the related features but not the others) and (in case of a CLI i= nterface) would reduce the possible completions if an operator would ask fo= r the possible values of the type of an interface. Has this ever been considered/discussed? Best regards, Bart --_000_152297277370826374Aviatnetcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I haven't seen any previous discussions on the topic, but we have a simi= lar problem.

Note this is not really to do with YANG itself, so much as the practical= limitations of the software package that provides our CLI interface.<= /p>

In NETCONF, the existence of extra unused identities doesn't pose any pr= oblem.


From: netmod <netmod-b= ounces@ietf.org> on behalf of Bogaert, Bart (Nokia - BE/Antwerp) <bar= t.bogaert@nokia.com>
Sent: Thursday, 5 April 2018 8:21 p.m.
To: netmod@ietf.org
Subject: [netmod] An abundant amount of IANA if types...
 

Hi,

 

We were wondering if it would m= ake sense to introduce features in the IANA if types YANG model to enable g= rouping of related interface types.  This would allow implementations = to include only the types it really requires (by supporting the related features but not the others) and (in case of a = CLI interface) would reduce the possible completions if an operator would a= sk for the possible values of the type of an interface.

Has this ever been considered/d= iscussed?

 

Best regards,

Bart

--_000_152297277370826374Aviatnetcom_-- From nobody Fri Apr 6 00:55:22 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0ACA128961 for ; Fri, 6 Apr 2018 00:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqzGgZGFJiPz for ; Fri, 6 Apr 2018 00:55:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E650912426E for ; Fri, 6 Apr 2018 00:55:17 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 7C32362546; Fri, 6 Apr 2018 09:55:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1523001314; bh=gHOS5UAF8ChFwWlZimRXiqYK4KoFIgJJhKGwYlQXsBg=; h=From:To:Date; b=fRUNIkLCXIdqYx6oYLFifo2LhLh3W8nRP6jGObsV909EjsS392kYaupgg+ZyINNW7 HLz11+AzIer4GQvDC2EAT/IaR8msGwZ52XqyuJ+Wyk9Nksb5GMf7aRI8/hjk6xLFX2 kGMjl2Z3Y5pUrcjjk0w0Livq3i4vf0ANkCzECKpA= Message-ID: <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> From: Ladislav Lhotka To: Alex Campbell , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Date: Fri, 06 Apr 2018 09:55:14 +0200 In-Reply-To: <1522972773708.26374@Aviatnet.com> References: <1522972773708.26374@Aviatnet.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 07:55:21 -0000 Hi, I have argued several times in the past that the IANA interface list (and, for that matter, the iana-if-type module) is a useless pile of rubbish because - for some interface classes (Ethernet, tunnels) it is way too coarse-grained - on the other hand, it contains a lot of stuff that nobody will ever use - using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for Ethernet is outright stupid - YANG identities allow for encoding important relationships in interface types,in the flat list all this information is lost - as you say, implementing the iana-if-type module means that all interface types listed therein become valid. So yes, I do believe that it would be useful if authoritative expert groups develop a better structure of interface type identities. Lada On Thu, 2018-04-05 at 23:59 +0000, Alex Campbell wrote: > I haven't seen any previous discussions on the topic, but we have a similar > problem. > Note this is not really to do with YANG itself, so much as the practical > limitations of the software package that provides our CLI interface. > In NETCONF, the existence of extra unused identities doesn't pose any problem. > > From: netmod on behalf of Bogaert, Bart (Nokia - > BE/Antwerp) > Sent: Thursday, 5 April 2018 8:21 p.m. > To: netmod@ietf.org > Subject: [netmod] An abundant amount of IANA if types... > > Hi, > > We were wondering if it would make sense to introduce features in the IANA if > types YANG model to enable grouping of related interface types. This would > allow implementations to include only the types it really requires (by > supporting the related features but not the others) and (in case of a CLI > interface) would reduce the possible completions if an operator would ask for > the possible values of the type of an interface. > Has this ever been considered/discussed? > > Best regards, > Bart > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 6 01:00:54 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802CE12D7F2 for ; Fri, 6 Apr 2018 01:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRAPTSHVjr22 for ; Fri, 6 Apr 2018 01:00:49 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B9CBA128961 for ; Fri, 6 Apr 2018 01:00:49 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id EC9221AE034E; Fri, 6 Apr 2018 10:00:48 +0200 (CEST) Date: Fri, 06 Apr 2018 10:00:48 +0200 (CEST) Message-Id: <20180406.100048.410212105090657982.mbj@tail-f.com> To: lhotka@nic.cz Cc: Alex.Campbell@Aviatnet.com, bart.bogaert@nokia.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 08:00:52 -0000 Ladislav Lhotka wrote: > Hi, > > I have argued several times in the past that the IANA interface list (and, for > that matter, the iana-if-type module) is a useless pile of rubbish because > > - for some interface classes (Ethernet, tunnels) it is way too coarse-grained > > - on the other hand, it contains a lot of stuff that nobody will ever use > > - using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for Ethernet > is outright stupid > > - YANG identities allow for encoding important relationships in interface types,in the flat list all this information is lost > > - as you say, implementing the iana-if-type module means that all interface > types listed therein become valid. > > So yes, I do believe that it would be useful if authoritative expert groups > develop a better structure of interface type identities. I agree. At the time when we did ietf-interfaces, not many people had experience with using identities; and we didn't have YANG 1.1. So we just used what we had in the MIB, but as identities. Now that we have much more experience, it would be great to build a better way to identify interfaces and their properties. /martin > > Lada > > On Thu, 2018-04-05 at 23:59 +0000, Alex Campbell wrote: > > I haven't seen any previous discussions on the topic, but we have a similar > > problem. > > Note this is not really to do with YANG itself, so much as the practical > > limitations of the software package that provides our CLI interface. > > In NETCONF, the existence of extra unused identities doesn't pose any problem. > > > > From: netmod on behalf of Bogaert, Bart (Nokia - > > BE/Antwerp) > > Sent: Thursday, 5 April 2018 8:21 p.m. > > To: netmod@ietf.org > > Subject: [netmod] An abundant amount of IANA if types... > > > > Hi, > > > > We were wondering if it would make sense to introduce features in the IANA if > > types YANG model to enable grouping of related interface types. This would > > allow implementations to include only the types it really requires (by > > supporting the related features but not the others) and (in case of a CLI > > interface) would reduce the possible completions if an operator would ask for > > the possible values of the type of an interface. > > Has this ever been considered/discussed? > > > > Best regards, > > Bart > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Apr 6 01:12:25 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95B9126D74 for ; Fri, 6 Apr 2018 01:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piCNMoSJM9hp for ; Fri, 6 Apr 2018 01:12:20 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on071d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::71d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300E8124B17 for ; Fri, 6 Apr 2018 01:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PqdLwMA0Qf9Nte6n2r1aoKAGjHZ1SaETjbLGsEgTNKo=; b=TUihyCrlzlDDy7JU4JPwrwrYASgZk5BOwrIhOugpgSB8iNPkwdGVQmOe/Rw7O0FF+5FNGGXMOoVc6uiZz6bzMUQkHb8Fg6/2mxwBpAbHjsLQ4Y+MD+2ZdQQpVnbSoCwFb/rkebGWhnm0NgmaY2h8DO7qTkpsEz+hejBqnkHVEs0= Received: from AM4PR07MB1716.eurprd07.prod.outlook.com (10.166.133.24) by AM4PR07MB1379.eurprd07.prod.outlook.com (10.164.82.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.4; Fri, 6 Apr 2018 08:12:17 +0000 Received: from AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::c15e:ad7a:a11e:eff4]) by AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::c15e:ad7a:a11e:eff4%5]) with mapi id 15.20.0653.014; Fri, 6 Apr 2018 08:12:04 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Ladislav Lhotka , Alex Campbell , "netmod@ietf.org" Thread-Topic: [netmod] An abundant amount of IANA if types... Thread-Index: AdPMtsq1NhXOIRliRzmEujzHOstMAwAxc+1cAABYHzA= Date: Fri, 6 Apr 2018 08:12:03 +0000 Message-ID: References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> In-Reply-To: <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-originating-ip: [135.245.212.64] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1379; 7:a33rr1BNx52lEBNXVfqm3uvf/BLtoop5E4Gj0+Qvd2NpZAXtGvK37l7AdKnLvh9i56fqs4a6DoOkFwK7qj/rRY/wVqcAKe02Dn61nuqSGTOwKmi8v94Qgf0w9kLlFMrWUqNuRVxDYOaE3OyDsii3uWBfDlE5dS7TKPRmAP9brglsIEz6TcO6M+ghCz94NyznjvTfdTgtEZd+p1t7fpg3V7MQn8xuD1l3+nrzMPpNuR6cThqkz1lEVEY4Rt2TZqx6 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 800fdfed-424b-4733-5b1e-08d59b9614e6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:AM4PR07MB1379; x-ms-traffictypediagnostic: AM4PR07MB1379: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231221)(11241501184)(806099)(944501327)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:AM4PR07MB1379; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1379; x-forefront-prvs: 0634F37BFF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(346002)(39860400002)(376002)(39380400002)(13464003)(199004)(189003)(377424004)(2906002)(3280700002)(105586002)(446003)(6246003)(25786009)(186003)(97736004)(26005)(6306002)(3846002)(9686003)(102836004)(476003)(229853002)(55016002)(86362001)(6116002)(53936002)(7736002)(486006)(478600001)(114624004)(3660700001)(6436002)(5250100002)(33656002)(59450400001)(81156014)(8676002)(8936002)(966005)(81166006)(74316002)(66066001)(305945005)(2900100001)(53546011)(106356001)(6506007)(2501003)(7696005)(99286004)(76176011)(5660300001)(68736007)(110136005)(11346002)(316002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1379; H:AM4PR07MB1716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: IrxQbmOYslE5RLthGEt5GJJa6kY/K0i1eD1aUZPbjG/LdYDbFfJFNVMh2wh++E0A+HPX4uKDHM4Y/sBWmBbUBpwEChYlXRNZn34BpTvnJw+09Yc9Gdx+xbxmTcs4AdmyzUGPHpRKCcXMy1BVBA1UfT6iAjS0+54HrU4DWD0cXJuu3gooBzr9RGUkJ4z1G94dDztoHRHsIq6VTQZnam8ogq8VpVbBdjmdXL309dlIjAm876AAA4nl1ZA8dmq7JaaAQxBmIwo5frGQytI4PFVUAuuEeSQRIaVSw6qYSLl02zEMugOySirE4v77iwQqF6utFrD8f+M9aULGU2coK5GZ4hTOCNVDmqQnV0rQ8U0S2e6DBj3taKDIICTOR7fjj/4yhnL1dRez49vCES2oGWR/BdQZ9PUF/V46JYLQguxGpol/Z/7+kjjFBvxJg880j/yYwfT06hWSwNx5YqOd0sN9MA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 800fdfed-424b-4733-5b1e-08d59b9614e6 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 08:12:03.9792 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1379 Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 08:12:23 -0000 QWxleCwNCg0KTm90IHN1cmUgaWYgdGhpcyBvbmx5IGhhcyB0byBkbyB3aXRoICJwcmFjdGljYWwg bGltaXRhdGlvbnMgcHJvdmlkaW5nIGEgQ0xJIGludGVyZmFjZSIuLi4gICBJbiBhIG1hY2hpbmUt dG8tbWFjaGluZSBpbnRlcmZhY2UgdGhpcyBpcyBsZXNzIG9mIGEgcHJvYmxlbSBidXQgaW4gYSBo dW1hbi10by1tYWNoaW5lIGludGVyZmFjZSBpdCBzZWVtcyBhIGJpdCBpbXByYWN0aWNhbCB0byBt ZSB0byBmaW5kIGEgc29sdXRpb24gZm9yIGEgcHJvYmxlbSB0byBzY3JvbGwgdGhyb3VnaCBhIGxp c3Qgb2YgMTAwKyBjb21wbGV0aW9ucyBpZiBhbiBvcGVyYXRvciB3b3VsZCBhc2sgZm9yIHRoZSBw b3NzaWJsZSBjb21wbGV0aW9uIGluIGNhc2UgaGUgZG9lcyBub3Qga25vdyB3aGF0IHRvIHByb3Zp ZGUgYXMgaW5wdXQuICBUaGVyZSBhcmUgd2F5cyB0byBsaW1pdCB0aGlzIG91dHB1dCBidXQgaXQg Y2FuIGJlIHNvbHZlZCBvbiBhIG1vZGVsbGluZyBsZXZlbCBhcyB3ZWxsLiAgQXMgSSBpbmRpY2F0 ZWQgaWRlbnRpdGllcyBjYW4gYmUgY29uZGl0aW9uYWwgdG8gYSBmZWF0dXJlIGFuZCBpZiBpbXBs ZW1lbnRhdGlvbnMgY2hvb3NlIG5vdCB0byBpbXBsZW1lbnQgYSBzZXQgb2YgaW50ZXJmYWNlLXR5 cGUgcmVsYXRlZCBmZWF0dXJlcyB0aGUgbGlzdCBiZWNvbWVzIChhIHdob2xlIGxvdCkgc2hvcnRl ciAiYnkgaXRzZWxmIi4gIE5vdyBpYW5hLWlmLXR5cGUgaXMganVzdCBhIGNvbGxlY3Rpb24gb2Yg YWxsIGludGVyZmFjZSB0eXBlcyB0aGF0IGhhdmUgYmVlbiBkZWZpbmVkIG9uY2Ugd2l0aG91dCBh bnkga2luZCBvZiAic3RydWN0dXJlIi4NCg0KUmVnYXJkcywgQmFydA0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTGFkaXNsYXYgTGhvdGthIFttYWlsdG86bGhvdGthQG5pYy5j el0gDQpTZW50OiBGcmlkYXksIEFwcmlsIDYsIDIwMTggOTo1NSBBTQ0KVG86IEFsZXggQ2FtcGJl bGwgPEFsZXguQ2FtcGJlbGxAQXZpYXRuZXQuY29tPjsgQm9nYWVydCwgQmFydCAoTm9raWEgLSBC RS9BbnR3ZXJwKSA8YmFydC5ib2dhZXJ0QG5va2lhLmNvbT47IG5ldG1vZEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtuZXRtb2RdIEFuIGFidW5kYW50IGFtb3VudCBvZiBJQU5BIGlmIHR5cGVzLi4u DQoNCkhpLA0KDQpJIGhhdmUgYXJndWVkIHNldmVyYWwgdGltZXMgaW4gdGhlIHBhc3QgdGhhdCB0 aGUgSUFOQSBpbnRlcmZhY2UgbGlzdCAoYW5kLCBmb3IgdGhhdCBtYXR0ZXIsIHRoZSBpYW5hLWlm LXR5cGUgbW9kdWxlKSBpcyBhIHVzZWxlc3MgcGlsZSBvZiBydWJiaXNoIGJlY2F1c2UNCg0KLSBm b3Igc29tZSBpbnRlcmZhY2UgY2xhc3NlcyAoRXRoZXJuZXQsIHR1bm5lbHMpIGl0IGlzIHdheSB0 b28gY29hcnNlLWdyYWluZWQNCg0KLSBvbiB0aGUgb3RoZXIgaGFuZCwgaXQgY29udGFpbnMgYSBs b3Qgb2Ygc3R1ZmYgdGhhdCBub2JvZHkgd2lsbCBldmVyIHVzZQ0KDQotIHVzaW5nIHRoZSBjYWJh bGlzdGljIChhbmQgd3JvbmcsIGluIGZhY3QpIG5hbWUgImV0aGVybmV0Q3NtYWNkIiBmb3IgRXRo ZXJuZXQgaXMgb3V0cmlnaHQgc3R1cGlkDQoNCi0gWUFORyBpZGVudGl0aWVzIGFsbG93IGZvciBl bmNvZGluZyBpbXBvcnRhbnQgcmVsYXRpb25zaGlwcyBpbiBpbnRlcmZhY2UgdHlwZXMsaW4gdGhl IGZsYXQgbGlzdCBhbGwgdGhpcyBpbmZvcm1hdGlvbiBpcyBsb3N0IA0KDQotIGFzIHlvdSBzYXks IGltcGxlbWVudGluZyB0aGUgaWFuYS1pZi10eXBlIG1vZHVsZSBtZWFucyB0aGF0IGFsbCBpbnRl cmZhY2UgdHlwZXMgbGlzdGVkIHRoZXJlaW4gYmVjb21lIHZhbGlkLg0KDQpTbyB5ZXMsIEkgZG8g YmVsaWV2ZSB0aGF0IGl0IHdvdWxkIGJlIHVzZWZ1bCBpZiBhdXRob3JpdGF0aXZlIGV4cGVydCBn cm91cHMgZGV2ZWxvcCBhIGJldHRlciBzdHJ1Y3R1cmUgb2YgaW50ZXJmYWNlIHR5cGUgaWRlbnRp dGllcy4NCg0KTGFkYQ0KICANCk9uIFRodSwgMjAxOC0wNC0wNSBhdCAyMzo1OSArMDAwMCwgQWxl eCBDYW1wYmVsbCB3cm90ZToNCj4gSSBoYXZlbid0IHNlZW4gYW55IHByZXZpb3VzIGRpc2N1c3Np b25zIG9uIHRoZSB0b3BpYywgYnV0IHdlIGhhdmUgYSANCj4gc2ltaWxhciBwcm9ibGVtLg0KPiBO b3RlIHRoaXMgaXMgbm90IHJlYWxseSB0byBkbyB3aXRoIFlBTkcgaXRzZWxmLCBzbyBtdWNoIGFz IHRoZSANCj4gcHJhY3RpY2FsIGxpbWl0YXRpb25zIG9mIHRoZSBzb2Z0d2FyZSBwYWNrYWdlIHRo YXQgcHJvdmlkZXMgb3VyIENMSSBpbnRlcmZhY2UuDQo+IEluIE5FVENPTkYsIHRoZSBleGlzdGVu Y2Ugb2YgZXh0cmEgdW51c2VkIGlkZW50aXRpZXMgZG9lc24ndCBwb3NlIGFueSBwcm9ibGVtLg0K PiANCj4gRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IEJvZ2FlcnQsIEJhcnQgDQo+IChOb2tpYSAtDQo+IEJFL0FudHdlcnApIDxiYXJ0LmJvZ2FlcnRA bm9raWEuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgNSBBcHJpbCAyMDE4IDg6MjEgcC5tLg0KPiBU bzogbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFtuZXRtb2RdIEFuIGFidW5kYW50IGFtb3Vu dCBvZiBJQU5BIGlmIHR5cGVzLi4uDQo+ICANCj4gSGksDQo+ICANCj4gV2Ugd2VyZSB3b25kZXJp bmcgaWYgaXQgd291bGQgbWFrZSBzZW5zZSB0byBpbnRyb2R1Y2UgZmVhdHVyZXMgaW4gdGhlIA0K PiBJQU5BIGlmIHR5cGVzIFlBTkcgbW9kZWwgdG8gZW5hYmxlIGdyb3VwaW5nIG9mIHJlbGF0ZWQg aW50ZXJmYWNlIA0KPiB0eXBlcy4gIFRoaXMgd291bGQgYWxsb3cgaW1wbGVtZW50YXRpb25zIHRv IGluY2x1ZGUgb25seSB0aGUgdHlwZXMgaXQgDQo+IHJlYWxseSByZXF1aXJlcyAoYnkgc3VwcG9y dGluZyB0aGUgcmVsYXRlZCBmZWF0dXJlcyBidXQgbm90IHRoZSANCj4gb3RoZXJzKSBhbmQgKGlu IGNhc2Ugb2YgYSBDTEkNCj4gaW50ZXJmYWNlKSB3b3VsZCByZWR1Y2UgdGhlIHBvc3NpYmxlIGNv bXBsZXRpb25zIGlmIGFuIG9wZXJhdG9yIHdvdWxkIA0KPiBhc2sgZm9yIHRoZSBwb3NzaWJsZSB2 YWx1ZXMgb2YgdGhlIHR5cGUgb2YgYW4gaW50ZXJmYWNlLg0KPiBIYXMgdGhpcyBldmVyIGJlZW4g Y29uc2lkZXJlZC9kaXNjdXNzZWQ/DQo+ICANCj4gQmVzdCByZWdhcmRzLA0KPiBCYXJ0DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBt YWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kDQotLQ0KTGFkaXNsYXYgTGhvdGthDQpIZWFkLCBDWi5OSUMg TGFicw0KUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQo= From nobody Fri Apr 6 01:18:38 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666A6128961 for ; Fri, 6 Apr 2018 01:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQx0QufdstHu for ; Fri, 6 Apr 2018 01:18:34 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38FD124B17 for ; Fri, 6 Apr 2018 01:18:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DBF90DF3; Fri, 6 Apr 2018 10:18:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 0JsqN5qpx-Xd; Fri, 6 Apr 2018 10:18:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Apr 2018 10:18:31 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4ED620035; Fri, 6 Apr 2018 10:18:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wgtZqmZ0QKvm; Fri, 6 Apr 2018 10:18:31 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08A3020031; Fri, 6 Apr 2018 10:18:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DA28D42AB097; Fri, 6 Apr 2018 10:18:30 +0200 (CEST) Date: Fri, 6 Apr 2018 10:18:30 +0200 From: Juergen Schoenwaelder To: "Bogaert, Bart (Nokia - BE/Antwerp)" Cc: Ladislav Lhotka , Alex Campbell , "netmod@ietf.org" Message-ID: <20180406081830.go3hfajpr4hp6svm@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Bogaert, Bart (Nokia - BE/Antwerp)" , Ladislav Lhotka , Alex Campbell , "netmod@ietf.org" References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 08:18:36 -0000 If we would have a mechanism to deviate an identityref to a subset of identity values supported by an implementation, we would have solved a more generic problem. Yes, the IANA list could be 'nicer' but it will never be 'nice'. /js On Fri, Apr 06, 2018 at 08:12:03AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > Alex, > > Not sure if this only has to do with "practical limitations providing a CLI interface"... In a machine-to-machine interface this is less of a problem but in a human-to-machine interface it seems a bit impractical to me to find a solution for a problem to scroll through a list of 100+ completions if an operator would ask for the possible completion in case he does not know what to provide as input. There are ways to limit this output but it can be solved on a modelling level as well. As I indicated identities can be conditional to a feature and if implementations choose not to implement a set of interface-type related features the list becomes (a whole lot) shorter "by itself". Now iana-if-type is just a collection of all interface types that have been defined once without any kind of "structure". > > Regards, Bart > > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Friday, April 6, 2018 9:55 AM > To: Alex Campbell ; Bogaert, Bart (Nokia - BE/Antwerp) ; netmod@ietf.org > Subject: Re: [netmod] An abundant amount of IANA if types... > > Hi, > > I have argued several times in the past that the IANA interface list (and, for that matter, the iana-if-type module) is a useless pile of rubbish because > > - for some interface classes (Ethernet, tunnels) it is way too coarse-grained > > - on the other hand, it contains a lot of stuff that nobody will ever use > > - using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for Ethernet is outright stupid > > - YANG identities allow for encoding important relationships in interface types,in the flat list all this information is lost > > - as you say, implementing the iana-if-type module means that all interface types listed therein become valid. > > So yes, I do believe that it would be useful if authoritative expert groups develop a better structure of interface type identities. > > Lada > > On Thu, 2018-04-05 at 23:59 +0000, Alex Campbell wrote: > > I haven't seen any previous discussions on the topic, but we have a > > similar problem. > > Note this is not really to do with YANG itself, so much as the > > practical limitations of the software package that provides our CLI interface. > > In NETCONF, the existence of extra unused identities doesn't pose any problem. > > > > From: netmod on behalf of Bogaert, Bart > > (Nokia - > > BE/Antwerp) > > Sent: Thursday, 5 April 2018 8:21 p.m. > > To: netmod@ietf.org > > Subject: [netmod] An abundant amount of IANA if types... > > > > Hi, > > > > We were wondering if it would make sense to introduce features in the > > IANA if types YANG model to enable grouping of related interface > > types. This would allow implementations to include only the types it > > really requires (by supporting the related features but not the > > others) and (in case of a CLI > > interface) would reduce the possible completions if an operator would > > ask for the possible values of the type of an interface. > > Has this ever been considered/discussed? > > > > Best regards, > > Bart > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 6 01:52:06 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC23912EAA4 for ; Fri, 6 Apr 2018 01:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFk5RcDNIYgK for ; Fri, 6 Apr 2018 01:51:53 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EA60812E8C2 for ; Fri, 6 Apr 2018 01:51:52 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id D1B0E1820073; Fri, 6 Apr 2018 10:50:46 +0200 (CEST) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id A41F01820051; Fri, 6 Apr 2018 10:50:44 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , "Bogaert\, Bart \(Nokia - BE\/Antwerp\)" Cc: Alex Campbell , "netmod\@ietf.org" In-Reply-To: <20180406081830.go3hfajpr4hp6svm@elstar.local> References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <20180406081830.go3hfajpr4hp6svm@elstar.local> Mail-Followup-To: Juergen Schoenwaelder , "Bogaert\, Bart \(Nokia - BE\/Antwerp\)" , Alex Campbell , "netmod\@ietf.org" Date: Fri, 06 Apr 2018 10:51:48 +0200 Message-ID: <87h8oora3f.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 08:52:06 -0000 Juergen Schoenwaelder writes: > If we would have a mechanism to deviate an identityref to a subset of > identity values supported by an implementation, we would have solved a > more generic problem. Yes, the IANA list could be 'nicer' but it will > never be 'nice'. Three mechanisms can be used for this: - splitting the identities into separate modules - using features - using deviations (even though vendors frown on them) I also proposed in the past to define the relevant identities in small batches in the same module that defines other data (configuration, state etc.) for the given interface type(s), rather than maintaining the interface types as a separate registry. I do admit that it is also useful to have such a registry but it can be automatically compiled from the existing modules (for example, YANG Catalog could do this). Lada > > /js > > On Fri, Apr 06, 2018 at 08:12:03AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: >> Alex, >> >> Not sure if this only has to do with "practical limitations providing a CLI interface"... In a machine-to-machine interface this is less of a problem but in a human-to-machine interface it seems a bit impractical to me to find a solution for a problem to scroll through a list of 100+ completions if an operator would ask for the possible completion in case he does not know what to provide as input. There are ways to limit this output but it can be solved on a modelling level as well. As I indicated identities can be conditional to a feature and if implementations choose not to implement a set of interface-type related features the list becomes (a whole lot) shorter "by itself". Now iana-if-type is just a collection of all interface types that have been defined once without any kind of "structure". >> >> Regards, Bart >> >> -----Original Message----- >> From: Ladislav Lhotka [mailto:lhotka@nic.cz] >> Sent: Friday, April 6, 2018 9:55 AM >> To: Alex Campbell ; Bogaert, Bart (Nokia - BE/Antwerp) ; netmod@ietf.org >> Subject: Re: [netmod] An abundant amount of IANA if types... >> >> Hi, >> >> I have argued several times in the past that the IANA interface list (and, for that matter, the iana-if-type module) is a useless pile of rubbish because >> >> - for some interface classes (Ethernet, tunnels) it is way too coarse-grained >> >> - on the other hand, it contains a lot of stuff that nobody will ever use >> >> - using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for Ethernet is outright stupid >> >> - YANG identities allow for encoding important relationships in interface types,in the flat list all this information is lost >> >> - as you say, implementing the iana-if-type module means that all interface types listed therein become valid. >> >> So yes, I do believe that it would be useful if authoritative expert groups develop a better structure of interface type identities. >> >> Lada >> >> On Thu, 2018-04-05 at 23:59 +0000, Alex Campbell wrote: >> > I haven't seen any previous discussions on the topic, but we have a >> > similar problem. >> > Note this is not really to do with YANG itself, so much as the >> > practical limitations of the software package that provides our CLI interface. >> > In NETCONF, the existence of extra unused identities doesn't pose any problem. >> > >> > From: netmod on behalf of Bogaert, Bart >> > (Nokia - >> > BE/Antwerp) >> > Sent: Thursday, 5 April 2018 8:21 p.m. >> > To: netmod@ietf.org >> > Subject: [netmod] An abundant amount of IANA if types... >> > >> > Hi, >> > >> > We were wondering if it would make sense to introduce features in the >> > IANA if types YANG model to enable grouping of related interface >> > types. This would allow implementations to include only the types it >> > really requires (by supporting the related features but not the >> > others) and (in case of a CLI >> > interface) would reduce the possible completions if an operator would >> > ask for the possible values of the type of an interface. >> > Has this ever been considered/discussed? >> > >> > Best regards, >> > Bart >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 6 04:36:47 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31B21201FA for ; Fri, 6 Apr 2018 04:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6g3jeLlnmnS for ; Fri, 6 Apr 2018 04:36:42 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64BCE124E15 for ; Fri, 6 Apr 2018 04:36:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 32F16CF5; Fri, 6 Apr 2018 13:36:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 6LItIXAQi--v; Fri, 6 Apr 2018 13:36:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Apr 2018 13:36:41 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B0D820035; Fri, 6 Apr 2018 13:36:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id U1_eWGvYZBgz; Fri, 6 Apr 2018 13:36:40 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A23F520031; Fri, 6 Apr 2018 13:36:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3E58042AB36D; Fri, 6 Apr 2018 13:36:40 +0200 (CEST) Date: Fri, 6 Apr 2018 13:36:39 +0200 From: Juergen Schoenwaelder To: "Bogaert, Bart (Nokia - BE/Antwerp)" , Alex Campbell , "netmod@ietf.org" Message-ID: <20180406113639.rgmxofccvsn7gzw5@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Bogaert, Bart (Nokia - BE/Antwerp)" , Alex Campbell , "netmod@ietf.org" References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h8oora3f.fsf@nic.cz> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 11:36:46 -0000 On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > If we would have a mechanism to deviate an identityref to a subset of > > identity values supported by an implementation, we would have solved a > > more generic problem. Yes, the IANA list could be 'nicer' but it will > > never be 'nice'. > > Three mechanisms can be used for this: > > - splitting the identities into separate modules Whatever module organization you come up with, it won't work for all implementations. > - using features Making every identity a feature will turn the feature system upside down. This is similar to making every leaf a feature. > - using deviations (even though vendors frown on them) If my implementation only supports A and B and C, then a deviation may state exactly that and the problem is solved. Hoping that my specific combination of A and B and C matches a set of modules or some set of features is in my view an illusion. Vendors not shipping proper deviations are essentially telling their customers that they have not yet understood model driven management. We need to change the mindset here instead of polluting our data models with hundreds or thousands of fine grained 'features'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 6 05:00:01 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15978124E15 for ; Fri, 6 Apr 2018 04:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vRM-SYRBX1D for ; Fri, 6 Apr 2018 04:59:57 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0113.outbound.protection.outlook.com [104.47.1.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76861124B18 for ; Fri, 6 Apr 2018 04:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eSZlqhPvioAk2l2ZBOw5bCYeX11WT0sz756gMJn6y6M=; b=nMJD6utRY7tgwHdApBywBzx/EIyVlWA20sXE2y47JXy5KIezokAMsHY3X8Mepv52ccj3LzMQF1JlIEA4DLuqHu5f9QPFfHRaBSu1ACso3D41k3KZTvfCkDjl2iGCkd2ok4V0QM/r5iS1EO0tosl98j99WKQXwWCGkC5YXSwRcMQ= Received: from AM4PR07MB1716.eurprd07.prod.outlook.com (10.166.133.24) by AM4PR07MB3089.eurprd07.prod.outlook.com (10.171.188.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.4; Fri, 6 Apr 2018 11:59:53 +0000 Received: from AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::c15e:ad7a:a11e:eff4]) by AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::c15e:ad7a:a11e:eff4%5]) with mapi id 15.20.0653.014; Fri, 6 Apr 2018 11:59:53 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Juergen Schoenwaelder , Alex Campbell , "netmod@ietf.org" Thread-Topic: [netmod] An abundant amount of IANA if types... Thread-Index: AdPMtsq1NhXOIRliRzmEujzHOstMAwAxc+1cAABYHzAAB2OkngAAIskw Date: Fri, 6 Apr 2018 11:59:53 +0000 Message-ID: References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> In-Reply-To: <20180406113639.rgmxofccvsn7gzw5@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-originating-ip: [135.245.212.64] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB3089; 7:B2B9oxZhvC5VTPiyGnrVHfHfrkGSYMsOkn1Ufc3/ndH0qLs6Ezu2Ahda9PFX0SPl69Pt3J3LL4jY4/RYvimWc0VhtknAUFLiqjych8kn1rbzv5nC+3kSc6NhN/keCNCxHPCP2lvCs4AICXvbvMR/Fk4QZj6qDtdVqqwqknFWW9laxpNWmWHGsgryss8josK5i4BVj+xSplpPp4UGPZifP4I4jFnadBVm3j2MpS5DCIRUFon2Ck+WdL48xho6o91a x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 94e52053-f8b6-4b9d-5fc4-08d59bb5e8a5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:AM4PR07MB3089; x-ms-traffictypediagnostic: AM4PR07MB3089: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231221)(11241501184)(806099)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:AM4PR07MB3089; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB3089; x-forefront-prvs: 0634F37BFF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(39380400002)(39860400002)(376002)(13464003)(199004)(189003)(9686003)(102836004)(33656002)(478600001)(8936002)(81166006)(106356001)(186003)(53936002)(3280700002)(6246003)(81156014)(3660700001)(6436002)(8676002)(66066001)(229853002)(3846002)(6116002)(2906002)(55016002)(25786009)(2900100001)(5660300001)(11346002)(446003)(6306002)(68736007)(316002)(53546011)(76176011)(14454004)(110136005)(97736004)(86362001)(105586002)(2501003)(7736002)(26005)(93886005)(5250100002)(305945005)(74316002)(486006)(476003)(7696005)(99286004)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3089; H:AM4PR07MB1716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1vWTsV4EYHiYAZtOlVsSAUE1zUyj02HLTAul6OTNt7D3J7REgboq1uBAovmBHTIw2/PB1CTL8wQlTRE9AZs8HsGvUj082wW+xpeAZ+ZIZ6UxDrryMZ86BXqw0wwRYLxnfslxywagTM9OZf6EALhFGriukWVl0Xxf5bduciMhsiQQHqbzw0kXYAtfJkiZNWCKJaUMaiFW18xsCKX2eElmEjnJAneNvN1FDD4Dbf7u8+onZV2otuIEVYZMhmRdeNJ9skp1ooDyZQdFJ7LawyCFw7vB4jSkynAjlcSEGXRAlQXZ6SDd5577oFrbjy3szi8lTt/fiYW1knUomBpPhvyhhvBqSzZ8QT7EzsMJnuyq52QzF9HXNn5olm0ONl8+CMFxr1paJEPLkliRGCP24laieEj3fHM7VAePWuYCd2RFOJsxHLI5clVwe47nzRx65sYFVHJEsS3ojwGOEKyFNoFUpg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 94e52053-f8b6-4b9d-5fc4-08d59bb5e8a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 11:59:53.3738 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3089 Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 11:59:59 -0000 Juergen, I was not suggesting to have a feature for all identities but I would assum= e that there are several identities that logically belong to each other so = these could be grouped. If this would still lead to a lot of features I do= not see how a deviation can help out here to reduce the number of identiti= es as you do not have a schema node for identities so to me the only way to= reduce the amount of interface types one supports is to define a YANG modu= le importing ietf-interfaces for the base interface-type identity and defin= ing the set of identities required but then this not really in-line with wh= at is coming from the standardization bodies (you could re-use the same nam= es as used in iana-if-type but this is not very nice). Regards, Bart -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, April 6, 2018 1:37 PM To: Bogaert, Bart (Nokia - BE/Antwerp) ; Alex Campb= ell ; netmod@ietf.org Subject: Re: [netmod] An abundant amount of IANA if types... On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: >=20 > > If we would have a mechanism to deviate an identityref to a subset=20 > > of identity values supported by an implementation, we would have=20 > > solved a more generic problem. Yes, the IANA list could be 'nicer'=20 > > but it will never be 'nice'. >=20 > Three mechanisms can be used for this: >=20 > - splitting the identities into separate modules Whatever module organization you come up with, it won't work for all implem= entations.=20 > - using features Making every identity a feature will turn the feature system upside down. T= his is similar to making every leaf a feature. > - using deviations (even though vendors frown on them) If my implementation only supports A and B and C, then a deviation may stat= e exactly that and the problem is solved. Hoping that my specific combinati= on of A and B and C matches a set of modules or some set of features is in = my view an illusion. Vendors not shipping proper deviations are essentially telling their custom= ers that they have not yet understood model driven management. We need to change the mindset here instead of polluting our data models wit= h hundreds or thousands of fine grained 'features'. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 6 05:01:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAEF124B18 for ; Fri, 6 Apr 2018 05:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn4kTiv7XOlg for ; Fri, 6 Apr 2018 05:01:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E0A1201FA for ; Fri, 6 Apr 2018 05:01:32 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:4431:4fff:fe6e:1c10]) by mail.nic.cz (Postfix) with ESMTPSA id 6AB0162433 for ; Fri, 6 Apr 2018 14:01:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1523016090; bh=jklWU7zyDrQt1ylp2A2orh79dXfyoWaE0tDdDrF+rkg=; h=From:To:Date; b=CyG/s9IQx92Lqw6AU/GG/p2wBpcF+4J7x1+EOYYB3GyE2JpklzcXbck2Ez/9t6tsE OdkLDDd+5pbNCylqdlv4UmBZH/Y0nqCAPUh6JYE4bjOZNy7kH4ov2D+28UdZp4MEok WmRLVkiNE1tpUjAitlnyNNAvRTp3wpNFGmyhaxAQ= Message-ID: <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Fri, 06 Apr 2018 14:01:30 +0200 In-Reply-To: <20180406113639.rgmxofccvsn7gzw5@elstar.local> References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 12:01:39 -0000 On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote: > On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: > > Juergen Schoenwaelder writes: > > > > > If we would have a mechanism to deviate an identityref to a subset of > > > identity values supported by an implementation, we would have solved a > > > more generic problem. Yes, the IANA list could be 'nicer' but it will > > > never be 'nice'. > > > > Three mechanisms can be used for this: > > > > - splitting the identities into separate modules > > Whatever module organization you come up with, it won't work for all > implementations. > > > - using features > > Making every identity a feature will turn the feature system upside > down. This is similar to making every leaf a feature. > > > - using deviations (even though vendors frown on them) > > If my implementation only supports A and B and C, then a deviation may > state exactly that and the problem is solved. Hoping that my specific In fact, deviations cannot delete identity values because they aren't schema nodes, so they are of no use. > combination of A and B and C matches a set of modules or some set of > features is in my view an illusion. An implementation that supports, say, a given type of tunnel interface will implement the module that covers this tunnel type. If the identity for this tunnel interface type is defined in the same module, then all is good. I don't get why this should be an illusion. On the contrary, I think it is the cleanest available solution to this conformance specification problem. > > Vendors not shipping proper deviations are essentially telling their > customers that they have not yet understood model driven management. > We need to change the mindset here instead of polluting our data > models with hundreds or thousands of fine grained 'features'. I agree that zillions of features aren't nice but it seems to be the only solution that we currently have for modules of the iana-if-type style. Having an bulky set of identity values, most of which are of no interest, is IMO much worse and could also be a security issue if implementors aren't careful enough. Lada > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 6 05:24:15 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC116126CD8 for ; Fri, 6 Apr 2018 05:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPiQi8CMVmYT for ; Fri, 6 Apr 2018 05:24:11 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01D41201FA for ; Fri, 6 Apr 2018 05:24:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A0795E71; Fri, 6 Apr 2018 14:24:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ummldjXQddYw; Fri, 6 Apr 2018 14:24:08 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Apr 2018 14:24:09 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7661520035; Fri, 6 Apr 2018 14:24:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id d0GYMt-d1RbT; Fri, 6 Apr 2018 14:24:08 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0291920031; Fri, 6 Apr 2018 14:24:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D3EB542AB42B; Fri, 6 Apr 2018 14:24:06 +0200 (CEST) Date: Fri, 6 Apr 2018 14:24:06 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: netmod@ietf.org Message-ID: <20180406122406.wdba43mr3bxsnyce@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20180329090305.eqshcqvqo33r5bsf@elstar.local> <20180405.143340.1930670144610383537.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180405.143340.1930670144610383537.mbj@tail-f.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] js review of draft-ietf-netmod-schema-mount-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 12:24:14 -0000 On Thu, Apr 05, 2018 at 02:33:40PM +0200, Martin Bjorklund wrote: > Hi, > > Thank you for this review! Comments inline. > > Juergen Schoenwaelder wrote: > > Here is my review of draft-ietf-netmod-schema-mount-09. > > > > * Abstract > > > > This document defines a mechanism to combine YANG modules into the > > schema defined in other YANG modules. > > > > I do not know what this says - I think this text is confusing. What > > does it mean to 'combine' YANG modules? What is the notion of > > 'schema' used here? > > Howabout: > > This document defines a mechanism to add the schema trees defined by > a set of YANG modules into the schema tree defined in another YANG > module. > This is better. > (see more below on terminology) > > > Does the text help someone to decide whether > > this mechanisms is something worth to study in order to solve a > > given modeling problem? (A good abstract would IMHO do that.) > > > > Note that the mount mechanisms has serious limitations as well that > > perhaps need to spelled out right up-front, i.e., it only works with > > pre-defined mount-points (augments are much more flexible in this > > regard, the schema mount defined here is by its very design not > > very flexible. > > I don't agree that this is a "serious limitation", and I don't think > an abstract should list things that the document doesn't do. OK. Remove 'serious' but clearly this schema mount mechanism is not as flexible as it could me. What about this: This document defines a mechanism to add the schema trees defined by a set of YANG modules onto mount points defined in another YANG module. This at least hints at the fact that mount points are rather static citizens. > > While I think I understand the difference made between > > implementation-time and run-time, the description is somewhat > > confusing since the run-time mount will also be exposed via YANG > > library and hence defining implementation-time by 'defined by a > > server implementor and is as stable as YANG library information of > > the server' is somewhat fuzzy. I assume what you mean is that in the > > case 2. the mounted schema is fixed at implementation time while in > > the case 3. the mounted schema may vary and be discovered at > > run-time. However, you do not define things this way but rather talk > > about properties that do however not define things. > > Howabout: > > OLD: > > + Run-time: the mounted schema is defined by instance data that is > part of the mounted data model. If there are multiple instances of > the same mount point (e.g., in multiple entries of a list), the > mounted data model may be different for each instance. > > NEW: > > + Run-time: the mounted schema can vary at run time and is defined by > instance data that is part of the mounted data model. If there are > multiple instances of the same mount point (e.g., in multiple > entries of a list), the mounted data model may be different for each > instance. Better. > > * Glossary of New Terms > > > > o top-level schema: a schema according to [RFC7950] in which schema > > trees of each module (except augments) start at the root node. > > > > You do not import 'schema' from RFC 7950 since, well, it is not > > defined in RFC 7950. I think you often mean a schema tree (as > > defined in RFC 7950) when you use 'schema'. Well, even this is not > > true since a 'schema tree' according to RFC 7950 is scoped to a > > module. RFC 8342 defines a 'datastore schema' but then I am not sure > > this corresponds to 'schema' as used in this draft. In fact, the > > mounted schema may be considered part of the 'datastore schema'. I > > think we are handwaving with our terminology here but then perhaps I > > am the only one who cares... > > I have imported "schema tree" from 7950, and changed teh definition of > top-level schema to: > > - top-level schema: a set of modules in which the schema > trees of each module (except augments) start at the root node. Still sounds complicated and not quite clear. Do you mean this: - top-level schema: a set of schema trees of a set of modules starting at the root node > > What we actually have are schema tree (of a module per RFC 7950) and > > a collection of schema trees sharing a common root (this is likely > > what is meant with "schema" in this document). And then schema mount > > simply provides a mechanism to have additional (statically defined) > > roots in a schema. So what are you planning to do about the term 'schema' used throughout the module? We kind of define what a top-level schema is but leave schema undefined and perhaps we would also benefit from having a term like mounted schema. I am thinking along these lines: schema = collection of schema trees with a common root top-level schema = schema rooted at the root node mounted schema = schema rooted at a mount point parent schema (of a mounted schema) = schema containing the mount point > > * Multiple Levels of Schema Mount > > > > What is a 'subschema'? What is a 'schema level'? Is a subschema the > > same as a schema, i.e. a collection of schema trees with a common > > root? If we need terms such as 'subschema' or 'schema level', then > > we should define them. But perhaps just some tweaking the text to > > avoid new terms can solve the issue. > > I have changed "subschema" to "schema", and removed "schema level": > > NEW: > > YANG modules in a mounted schema MAY again contain mount points > under which other schemas can be mounted. Consequently, it is > possible to construct data models with an arbitrary number of > mounted schemas. A schema for a mount point contained in a mounted > module can be specified by implementing "ietf-yang-library" and > "ietf-yang-schema-mount" modules in the mounted schema, and > specifying the schemas exactly as it is done in the top-level > schema. OK > > Why are parent-references only useful for the 'shared-schema' case? > > An 'inline' mount can't refer to stuff outside the mount jail? > > Correct. We have debated if this makes sense for inline or not. As > it is, the model is designed so that this can be added in the future, > if it turns out that this is needed. OK > > Looking at the YANG definition of 'parent-reference', I am left > > somewhat clueless in which situations these xpath expressions are > > evaluations and when the nodesets are merged with other xpath > > expression evaluation results. > > The YANG module says: > > When XPath expressions in the mounted schema > are evaluated, the 'parent-reference' leaf-list is taken > into account. > > and > > For the purposes of evaluating XPath > expressions whose context nodes are defined in the > mounted schema, the union of all these nodesets > together with ancestor nodes are added to the > accessible data tree. OK. I probably did not read carefully enough. My understanding is now that the set of parent-reference xpath expressions yields a union of nodesets that are becoming part of the context for the evaluation of any xpath expression appearing in a mounted schema. And these parent references are specific to a mount point instance. May make sense. > > It seems that these parent references > > are the only actual difference between 'inline' and 'shared-schema' > > mounts. > > > > * Data Model > > > > I have not really understood what the difference between 'inline' > > and 'shared-schema' is. I understand that the later can have > > 'parent-references' but it is unclear why the other can't and if > > there is not strong architectural reason why there have to be two > > choices. It also seems that the 'namespace' list is only meaningful > > if there are parent references, no? So why is this then global, i.e. > > also provided for 'inline' mounts? > > As you note, the 'namespace' list is global, so there is just one list > that covers all mount-points. It's not really correct to state that > the 'namespace' list is "provided for 'inline' mounts". OK. It seems that for a client capable to support a 'shared schema', the 'inline' schema really is just a special case without parent references. (I wonder whether anything should be said to YANG library version numbers, whether they are always scoped by the mount point or have meaning across mount points; if two YANG library instances in mounted schemas have the same version number, does this imply that these YANG library instances are identical or is this just a version number clash? But then this probably goes across the spirit of not talking about YANG library too much.) > > I guess I do not really > > understand the distinction. If there are no parent-references, what > > is the difference between 'shared-schema' and 'inline'? > > The difference is that shared-schema can have parent-references, and > that all instances of such a mount point have exactly the same > schema. See comment above about YANG library version numbers. I am trying to understand which assumption a client can make to be efficient in both cases (and whether it is possible to be efficient while essentially handling inline and shared-schema using a common approach). > > * Security Considerations > > > > I agree with others that something needs to be said how NACM applies > > to mounted schemas. > > I have added the following (short) section: > > 7. Interaction with the Network Configuration Access Control Model > (NACM) > > If NACM [RFC8341] is implemented on a server, it can be used to > control access to nodes defined by the mounted schema in the same way > as for nodes defined by the top-level schema. > > For example, suppose the module "ietf-interfaces" is mounted in the > "root" container in the "logical-network-element" list defined in > [I-D.ietf-rtgwg-lne-model]. Then the following NACM path can be used > to control access to the "interfaces" container (where the character > '\' is used where a line break has been inserted for formatting > reasons): > > "urn:ietf:params:xml:ns:yang:ietf-logical-network-element" > xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"> > /lne:logical-network-elements\ > /lne:logical-network-element/lne:root/if:interfaces > This helps. Can I also mount NACM into a mount point? If yes, what if both are present? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 6 05:29:07 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0836126DED for ; Fri, 6 Apr 2018 05:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozRj7aYgjY0Q for ; Fri, 6 Apr 2018 05:29:03 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CACF1201FA for ; Fri, 6 Apr 2018 05:29:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 65BD1CDD; Fri, 6 Apr 2018 14:29:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id OcD0Iv2YoUS4; Fri, 6 Apr 2018 14:29:01 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Apr 2018 14:29:02 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E37A20031; Fri, 6 Apr 2018 14:29:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PTBNtt_qKjmG; Fri, 6 Apr 2018 14:29:01 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F24520035; Fri, 6 Apr 2018 14:29:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5EE2042AB51D; Fri, 6 Apr 2018 14:29:01 +0200 (CEST) Date: Fri, 6 Apr 2018 14:29:01 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: netmod@ietf.org Message-ID: <20180406122901.yayqpgrvxmjzu4eo@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 12:29:06 -0000 On Fri, Apr 06, 2018 at 02:01:30PM +0200, Ladislav Lhotka wrote: > On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote: > > On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: > > > Juergen Schoenwaelder writes: > > > > > > > If we would have a mechanism to deviate an identityref to a subset of > > > > identity values supported by an implementation, we would have solved a > > > > more generic problem. Yes, the IANA list could be 'nicer' but it will > > > > never be 'nice'. > > > > > > Three mechanisms can be used for this: > > > > > > - splitting the identities into separate modules > > > > Whatever module organization you come up with, it won't work for all > > implementations. > > > > > - using features > > > > Making every identity a feature will turn the feature system upside > > down. This is similar to making every leaf a feature. > > > > > - using deviations (even though vendors frown on them) > > > > If my implementation only supports A and B and C, then a deviation may > > state exactly that and the problem is solved. Hoping that my specific > > In fact, deviations cannot delete identity values because they aren't schema > nodes, so they are of no use. Putting today's limits of YANG syntax aside for the moment, I still believe implementations need to publish the identities they support without requiring matching features or module definition. > > combination of A and B and C matches a set of modules or some set of > > features is in my view an illusion. > > An implementation that supports, say, a given type of tunnel interface will > implement the module that covers this tunnel type. If the identity for this > tunnel interface type is defined in the same module, then all is good. I don't > get why this should be an illusion. On the contrary, I think it is the cleanest > available solution to this conformance specification problem. > > > > > Vendors not shipping proper deviations are essentially telling their > > customers that they have not yet understood model driven management. > > We need to change the mindset here instead of polluting our data > > models with hundreds or thousands of fine grained 'features'. > > I agree that zillions of features aren't nice but it seems to be the only > solution that we currently have for modules of the iana-if-type style. > > Having an bulky set of identity values, most of which are of no interest, is IMO > much worse and could also be a security issue if implementors aren't careful > enough. If an implementation does not check input, then the code is broken, regardless whether we restrict the identities somewhere or not. I do not buy the security point. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 6 05:31:03 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9D712702E for ; Fri, 6 Apr 2018 05:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dGzOWfgIYc5 for ; Fri, 6 Apr 2018 05:31:00 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5155B126DEE for ; Fri, 6 Apr 2018 05:31:00 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 642201AE034E; Fri, 6 Apr 2018 14:30:59 +0200 (CEST) Date: Fri, 06 Apr 2018 14:30:58 +0200 (CEST) Message-Id: <20180406.143058.1623327976553322598.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: bart.bogaert@nokia.com, Alex.Campbell@Aviatnet.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180406113639.rgmxofccvsn7gzw5@elstar.local> References: <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 12:31:02 -0000 Juergen Schoenwaelder wrote: > On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: > > Juergen Schoenwaelder writes: > > > > > If we would have a mechanism to deviate an identityref to a subset of > > > identity values supported by an implementation, we would have solved a > > > more generic problem. Yes, the IANA list could be 'nicer' but it will > > > never be 'nice'. > > > > Three mechanisms can be used for this: > > > > - splitting the identities into separate modules > > Whatever module organization you come up with, it won't work for all > implementations. > > > - using features > > Making every identity a feature will turn the feature system upside > down. This is similar to making every leaf a feature. > > > - using deviations (even though vendors frown on them) > > If my implementation only supports A and B and C, then a deviation may > state exactly that and the problem is solved. Hoping that my specific > combination of A and B and C matches a set of modules or some set of > features is in my view an illusion. > > Vendors not shipping proper deviations are essentially telling their > customers that they have not yet understood model driven management. > We need to change the mindset here instead of polluting our data > models with hundreds or thousands of fine grained 'features'. One problem is that you can't "deviate-away" support for an identity. /martin From nobody Fri Apr 6 06:04:36 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C27126CC7 for ; Fri, 6 Apr 2018 06:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83hRNkKBHmcD for ; Fri, 6 Apr 2018 06:04:30 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254066.outbound.protection.outlook.com [40.92.254.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1191201FA for ; Fri, 6 Apr 2018 06:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hvEaxPVX2fVBj35m0EvSO66oy+jt5UrxM43ZDaYaPwA=; b=WhDYeJS4cUdvy1w5dpWCH/zOffKdjVLBHQvtPIl/jzrIPR3yyWEaiuhMfTQIzHMxLkvulnRTmpOs8dV1qqN8W+bd1kbcye9jP7NOXf+x5WBrw4ZPHvY+ID2flEVFMUjpA2g1BEP34xo9g3QzP1XcQH5SijC4ui0hjLHN2mNu3rDqZAwRZt322Tr5Pr+PgyVwiRvQuu2P9y2p65UWsX+P+Ikw+GH+fTPzGXvAWQ6foxo4QSDHeBEEg8Va8KiWOM8rzAYRD2YxI6vOrvgiO6D6s76W5y4CPzyTJblgRiVoJpAJoZkKa6/3mCd6O642t3BU5QA1V54yh6akyIzUUokZzw== Received: from PU1APC01FT015.eop-APC01.prod.protection.outlook.com (10.152.252.51) by PU1APC01HT004.eop-APC01.prod.protection.outlook.com (10.152.252.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.8; Fri, 6 Apr 2018 13:04:27 +0000 Received: from HK2PR0401MB1265.apcprd04.prod.outlook.com (10.152.252.56) by PU1APC01FT015.mail.protection.outlook.com (10.152.252.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.8 via Frontend Transport; Fri, 6 Apr 2018 13:04:27 +0000 Received: from HK2PR0401MB1265.apcprd04.prod.outlook.com ([fe80::2db2:49db:7b47:d80]) by HK2PR0401MB1265.apcprd04.prod.outlook.com ([fe80::2db2:49db:7b47:d80%4]) with mapi id 15.20.0653.012; Fri, 6 Apr 2018 13:04:27 +0000 From: Rohit Ranade To: Martin Bjorklund CC: "netmod@ietf.org" Thread-Topic: [netmod] Comments on schema mount draft Thread-Index: AQHTxDbT1I3AIjMZP0GUUq533JigqqPiK6iAgAIEP92AAqcggIAIV7nqgAMAT4CAAZXZ7g== Date: Fri, 6 Apr 2018 13:04:26 +0000 Message-ID: References: <20180329.092953.1063547768163198657.mbj@tail-f.com> , <20180405.144349.1531327560930954458.mbj@tail-f.com> In-Reply-To: <20180405.144349.1531327560930954458.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:FE6C3440F4081A1A158932BD7513C1B45A465653C8B45FFFDCC64CEC5B8F924A; UpperCasedChecksum:C277EA6E15E757FD81E4FF1BBA42574E1FBDD3513528305B4CA87B78BA463EB2; SizeAsReceived:7332; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [xUejEMfoIoWvH24cmzp+T1hjiBLhodx+] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT004; 7:feZFB/DcoMnz9ZFsmQsP4DKL1r3XPCmqnBrv5MSfinYluMAlTRmBAiXJmzvw0cG+tSOwfmvrpm79fR4t9K91LeijIJEgNPNTILL3kWg+cGu+3RXKkoRpR5rxFn/W5e5cmTKXZ1zBYrtUPLw2myUsl4ECmgwU7Pky7v6ZmadONHz7KZStKbX8mCJim7lb8L45P58JozS+MxGopTV0KJe9MDnIEjqywy7I7/JddEaEeNmc6a/bURUUg9kcYSfi2AqA x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:PU1APC01HT004; x-ms-traffictypediagnostic: PU1APC01HT004: x-ms-office365-filtering-correlation-id: 597a19cd-11cf-4705-df35-08d59bbeed5d x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:PU1APC01HT004; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT004; x-forefront-prvs: 0634F37BFF x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT004; H:HK2PR0401MB1265.apcprd04.prod.outlook.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: MKDqZSIaiMx2vQdrpybkQ8jUeVD/mW7ZbKAR7THSaxrOvsAWYBiRkjecdSsABjT+DtmIBRfkg4WjEqkyCCb3odBNupNYpoTsbeTyYrugLNBQwgTXbbFnc7LcFq2iA41p5bSUC39JN5cwZ8MQwnv6qwE9aeKzUbsDe2docWxs0t/WS6N6kFkeCL0ObuOMwNFv spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HK2PR0401MB12652B45BACC5902890EADA4DBBA0HK2PR0401MB1265_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 597a19cd-11cf-4705-df35-08d59bbeed5d X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 13:04:26.3530 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT004 Archived-At: Subject: Re: [netmod] Comments on schema mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 13:04:34 -0000 --_000_HK2PR0401MB12652B45BACC5902890EADA4DBBA0HK2PR0401MB1265_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluLA0KDQoNCg0KRm9yIGJlbG93IHBvaW50Og0KDQrigJwNCg0KPiA0LiBORVRDT05G IGhhcyBzb21lICJycGMiIHdoaWNoIHdvcmsgb24gbXVsdGlwbGUgbW91bnQtaW5zdGFuY2VzLg0K Pg0KPiAgICA9PT4gRm9yIGV4YW1wbGUgPGVkaXQtY29uZmlnPiAsIDxnZXQtY29uZmlnPiBvciA8 bG9jaz4uIFdoZXRoZXIgd2UgbmVlZCB0byBnaXZlIGENCj4NCj4gICAgZ3VpZGVsaW5lIGZvciBo b3cgdG8gaGFuZGxlIHN1Y2ggInJwYyIsIHNvIHRoYXQgb3RoZXIgcHJvdG9jb2xzIHdoaWNoIGlt cGxlbWVudCBzY2hlbWEgbW91bnQgICBhbHNvIGFkYXB0IGFjY29yZGluZ2x5ID8NCj4NCj4gICAg RWc6IFNvbWV0aGluZyBsaWtlLCBmb3IgdHJhbnNhY3Rpb24gbWFuYWdlbWVudCwgYmV0dGVyIHRv IG9wZXJhdGUgb24gb25lIG1vdW50LWluc3RhbmNlLg0KDQpUaGlzIHdvdWxkIG5vdCBiZSBjb3Jy ZWN0LiAgSSB0aGluayB5b3UgYXJlIGFzc3VtaW5nIG9uZSB1c2UgY2FzZTsNCndoZXJlIHNjaGVt YSBtb3VudCBpcyB1c2VkIGluIGEgKHByaW1pdGl2ZSkgb3JjaGVzdHJhdG9yIHRoYXQgYWN0dWFs bHkNCnRhbGtzIHRvIG11bHRpcGxlIGRldmljZXMgKHcvbyB0cmFuc2FjdGlvbiBjb250cm9sKS4N Cg0KTm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQganVzdCBkZWZpbmVzIGhvdyB0aGUgKnNjaGVtYSog aXMgYnVpbHQ7IG5vdA0KaG93IGluc3RhbmNlIGRhdGEgaXMgc3RvcmVkIG9yIGFjY2Vzc2VkLg0K DQrigJ0NCg0KQXMgcGVyIGV4YW1wbGUgc2hvd24gaW4gc2VjdGlvbiA0Og0KDQogICAgICstLXJ3 IG5ldHdvcmstaW5zdGFuY2VzDQoNCiAgICAgICAgKy0tcncgbmV0d29yay1pbnN0YW5jZSogW25h bWVdDQoNCiAgICAgICAgICAgKy0tcncgbmFtZQ0KDQogICAgICAgICAgICstLXJ3IHJvb3QNCg0K ICAgICAgICAgICAgICArLS1ydyByb3V0aW5nDQoNCg0KDQpDb25zaWRlcmluZyDigJxyb2904oCd IGFzIG1vdW50IHBvaW50IDoNCg0KDQoNCldoZW4gcXVlcnlpbmcgZGF0YSBmcm9tIHNjaGVtYSBt b3VudGVkIG1vZGVsczoNCg0KDQoNCjxnZXQtY29uZmlnPg0KDQogIDxmaWx0ZXI+DQoNCiAgICA8 bmV0d29yay1pbnN0YW5jZXM+DQoNCiAgICAgIDxuZXR3b3JrLWluc3RhbmNlPg0KDQogICAgICAg PG5hbWU+MTwvbmFtZT4NCg0KICAgICAgICA8cm9vdD4NCg0KICAgICAgICAgIDxyb3V0aW5nLz4N Cg0KDQoNCkFuZA0KDQoNCg0KPGFjdGlvbj4NCg0KICAgIDxuZXR3b3JrLWluc3RhbmNlcz4NCg0K ICAgICAgPG5ldHdvcmstaW5zdGFuY2U+DQoNCiAgICAgICA8bmFtZT4xPC9uYW1lPg0KDQogICAg ICAgIDxyb290Pg0KDQogICAgICAgICAgPGdldC1jb25maWc+ICAtLSBoYXZpbmcgaWV0Zi1uZXRj b25mIG5zDQoNCiAgICAgICAgICAgIDxmaWx0ZXI+DQoNCiAgICAgICAgICAgICA8cm91dGluZy8+ DQoNCg0KDQpXaWxsIHRoZXNlIHR3byBnaXZlIHRoZSBzYW1lIHJlc3VsdCA/DQoNCg0KDQpXaXRo IFJlZ2FyZHMsDQoNClJvaGl0IFINCg0KDQoNClNlbnQgZnJvbSBNYWlsPGh0dHBzOi8vZ28ubWlj cm9zb2Z0LmNvbS9md2xpbmsvP0xpbmtJZD01NTA5ODY+IGZvciBXaW5kb3dzIDEwDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogTWFydGluIEJqb3JrbHVuZCA8 bWJqQHRhaWwtZi5jb20+DQpTZW50OiBUaHVyc2RheSwgQXByaWwgNSwgMjAxOCA2OjEzOjQ5IFBN DQpUbzogcm9oaXRycmFuYWRlQG91dGxvb2suY29tDQpDYzogbmV0bW9kQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW25ldG1vZF0gQ29tbWVudHMgb24gc2NoZW1hIG1vdW50IGRyYWZ0DQoNCkhpLA0K DQoNClJvaGl0IFJhbmFkZSA8cm9oaXRycmFuYWRlQG91dGxvb2suY29tPiB3cm90ZToNCj4gSGkg TWFydGluLA0KPg0KPg0KPg0KPiBUaGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2VzLg0KPg0KPiBJ IGhhdmUgZ29uZSB0aHJvdWdoIHRoZSBMTkUgZHJhZnQgYW5kIFlBTkcgMS4xIGFuZCBmb3VuZCBz b21lIG1vcmUgc3VnZ2VzdGlvbnMuDQo+DQo+DQo+DQo+IDEuIFNlY3Rpb24gNQ0KPg0KPiAgICAi SWYgYSBtb3VudGVkIFlBTkcgbW9kdWxlIGRlZmluZXMgYW4gUlBDIG9wZXJhdGlvbiwgY2xpZW50 cyBjYW4gaW52b2tlDQo+DQo+ICAgIHRoaXMgb3BlcmF0aW9uIGFzIGlmIGl0IHdlcmUgZGVmaW5l ZCBhcyBhbiBhY3Rpb24gZm9yIHRoZQ0KPg0KPiAgICBjb3JyZXNwb25kaW5nIG1vdW50IHBvaW50 Ig0KPg0KPiAgICA9PT4gQmVsb3cgaXMgdGhlIGV4YW1wbGUgZnJvbSBZYW5nIDEuMSBTZWN0aW9u IDcuMTUNCj4NCj4NCj4NCj4gICAgIDxycGMgbWVzc2FnZS1pZD0iMTAxIg0KPg0KPiAgICAgICAg ICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQo+DQo+ ICAgICAgICA8YWN0aW9uIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6MSI+DQo+ DQo+ICAgICAgICAgIDxzZXJ2ZXIgeG1sbnM9InVybjpleGFtcGxlOnNlcnZlci1mYXJtIj4NCj4N Cj4gICAgICAgICAgICA8bmFtZT5hcGFjaGUtMTwvbmFtZT4NCj4NCj4gICAgICAgICAgICA8cmVz ZXQ+DQo+DQo+ICAgICAgICAgICAgICA8cmVzZXQtYXQ+MjAxNC0wNy0yOVQxMzo0MjowMFo8L3Jl c2V0LWF0Pg0KPg0KPiAgICAgICAgICAgIDwvcmVzZXQ+DQo+DQo+ICAgICAgICAgIDwvc2VydmVy Pg0KPg0KPiAgICAgICAgPC9hY3Rpb24+DQo+DQo+ICAgICAgPC9ycGM+DQo+DQo+DQo+DQo+ICAg ICAgPHJwYy1yZXBseSBtZXNzYWdlLWlkPSIxMDEiDQo+DQo+ICAgICAgICAgICAgICAgICB4bWxu cz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCj4NCj4gICAgICAg IDxyZXNldC1maW5pc2hlZC1hdCB4bWxucz0idXJuOmV4YW1wbGU6c2VydmVyLWZhcm0iPg0KPg0K PiAgICAgICAgICAyMDE0LTA3LTI5VDEzOjQyOjEyWg0KPg0KPiAgICAgICAgPC9yZXNldC1maW5p c2hlZC1hdD4NCj4NCj4gICAgICA8L3JwYy1yZXBseT4NCj4NCj4gICAgICAgICAgICAgICA9PT4g SGVyZSBycGMtcmVwbHkgb25seSBoYXMgdGhlIG5hbWVzcGFjZSBhbmQgYWN0aW9uIG5hbWUgZGVm aW5lZCBpbiB0aGUgbW91bnQtaW5zdGFuY2UncyBtb2R1bGUuDQo+DQo+ICAgICAgICAgICAgICAg VGhlIGNsaWVudCBuZWVkcyB0byBzdG9yZSBpbmZvcm1hdGlvbiBvZiB0aGUgbW91bnQtaW5zdGFu Y2UgZm9yIHdoaWNoIHRoZSBSUEMgcmVxdWVzdCB3YXMgc2VudCBhbmQgb25seSB0aGVuIGl0IGNh biB2YWxpZGF0ZSB0aGUgcnBjLXJlcGx5IGFnYWluc3QgdGhlIGRhdGEtbW9kZWwuDQo+DQo+ICAg ICAgICAgICAgICAgVG8gYXZvaWQgdGhpcyB3b3JrIG9mIGNsaWVudCwgd2hldGhlciB3ZSBjYW4g dGhpbmsgb2YgYWRkaW5nIG1ldGEtZGF0YSB0byBycGMtcmVwbHkgdG8gcHJvdmlkZSB0aGlzIGlu Zm9ybWF0aW9uIHRvIGNsaWVudC4NCg0KSWYgdGhlIGNsaWVudCBpbnZva2VzIGFuIGFjdGlvbiwg aXQgaXMgZXhwZWN0ZWQgdGhhdCBpdCBrbm93cyBob3cgdG8NCmludGVycHJldCB0aGUgcmVzdWx0 LiAgVGhpcyBkb2VzIG5vdCBjaGFuZ2Ugd2l0aCB0aGUgaW50cm9kdWN0aW9uIG9mDQpzY2hlbWEg bW91bnQuICBUaGUgY2xpZW50IG9idmlvdXNseSBrbm93cyB0aGUgbmFtZSBhbmQgaW5wdXQNCnBh cmFtZXRlcnMgb2YgdGhlIGFjdGlvbiwgc28gaXQgc2VlbXMgcmVzb25hYmxlIHRvIGV4cGVjdCB0 aGF0IGl0DQprbm93cyB0aGUgb3V0cHV0IHBhcmFtZXRlcnMgYXMgd2VsbCwgdy9vIGFueSBhZGRp dGlvbmFsIG1ldGEgZGF0YS4NCg0KPiAyLiBTZWN0aW9uIDUNCj4NCj4gICAgSSB3b3VsZCBwcmVm ZXIgdGhlIGFwcHJvYWNoIHRha2VuIGJ5IFlhbmcgMS4xIHdoZXJlIHN0YXRlbWVudHMgZm9sbG93 ZWQgYnkgWE1MIGV4YW1wbGVzICAgdG8gaGVscCBpbiBjbGFyaXR5Lg0KPg0KPiAgICBFc3BlY2lh bGx5IGZvciB0aGUgUlBDIGFuZCBub3RpZmljYXRpb24gc2VjdGlvbiwgaXQgaXMgYmV0dGVyIHRv IGFkZCBjbGVhciBleGFtcGxlcw0KPg0KPiAgICBpbiBhICJVc2FnZSBFeGFtcGxlIiBzdWItc2Vj dGlvbiBmb3IgdGhpcyBzZWN0aW9uLg0KDQpUaGUgZXhhbXBsZXMgYXJlIGdpdmVuIGluIHRoZSBh cHBlbmRpeCwgYW5kIHRoZXJlIGlzIGEgZm9yd2FyZA0KcmVmZXJlbmNlIHRvIHRoZSBhcHBlbmRp eCBmcm9tIHNlY3Rpb24gNS4NCg0KDQo+IDMuIFlhbmcgUlBDIGFuZCBBQ1RJT04gc3RhdGVtZW50 czoNCj4NCj4gICBJZiB3ZSBuZWVkIHRvIHZpZXcgdGhlIFJQQyBkZWZpbmVkIGluIGEgbW9kdWxl IGFzIGFuIEFDVElPTiBhZnRlciBzY2hlbWEgbW91bnQsIHRoZW4NCj4NCj4gICBXaGVuZXZlciB0 aGVyZSBpcyB1cGRhdGUgdG8gUlBDIGluIHNheSBZQU5HIDEuMiwgdGhlbiB0aGUgY29ycmVzcG9u ZGluZyBjaGFuZ2VzIG11c3QgYmUgcHJlc2VudCBpbiBBQ1RJT04gYWxzbywgaW50cm9kdWNpbmcg YSBjb3VwbGluZyBiZXR3ZWVuIFJQQyBhbmQgQUNUSU9OIHN0YXRlbWVudHMuDQoNClRoaXMgbW9k dWxlIGlzIHdyaXR0ZW4gdXNpbmcgWUFORyAxLjEuICBVbmxlc3MgdGhpcyBtb2R1bGUgaXMgdXBk YXRlZCwNCml0IGRvZXNuJ3QgbWF0dGVyIHdoYXQgWUFORyAyLjAgb3Igd2hhdGV2ZXIgZG9lcy4N Cg0KPiA0LiBORVRDT05GIGhhcyBzb21lICJycGMiIHdoaWNoIHdvcmsgb24gbXVsdGlwbGUgbW91 bnQtaW5zdGFuY2VzLg0KPg0KPiAgICA9PT4gRm9yIGV4YW1wbGUgPGVkaXQtY29uZmlnPiAsIDxn ZXQtY29uZmlnPiBvciA8bG9jaz4uIFdoZXRoZXIgd2UgbmVlZCB0byBnaXZlIGENCj4NCj4gICAg Z3VpZGVsaW5lIGZvciBob3cgdG8gaGFuZGxlIHN1Y2ggInJwYyIsIHNvIHRoYXQgb3RoZXIgcHJv dG9jb2xzIHdoaWNoIGltcGxlbWVudCBzY2hlbWEgbW91bnQgICBhbHNvIGFkYXB0IGFjY29yZGlu Z2x5ID8NCj4NCj4gICAgRWc6IFNvbWV0aGluZyBsaWtlLCBmb3IgdHJhbnNhY3Rpb24gbWFuYWdl bWVudCwgYmV0dGVyIHRvIG9wZXJhdGUgb24gb25lIG1vdW50LWluc3RhbmNlLg0KDQpUaGlzIHdv dWxkIG5vdCBiZSBjb3JyZWN0LiAgSSB0aGluayB5b3UgYXJlIGFzc3VtaW5nIG9uZSB1c2UgY2Fz ZTsNCndoZXJlIHNjaGVtYSBtb3VudCBpcyB1c2VkIGluIGEgKHByaW1pdGl2ZSkgb3JjaGVzdHJh dG9yIHRoYXQgYWN0dWFsbHkNCnRhbGtzIHRvIG11bHRpcGxlIGRldmljZXMgKHcvbyB0cmFuc2Fj dGlvbiBjb250cm9sKS4NCg0KTm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQganVzdCBkZWZpbmVzIGhv dyB0aGUgKnNjaGVtYSogaXMgYnVpbHQ7IG5vdA0KaG93IGluc3RhbmNlIGRhdGEgaXMgc3RvcmVk IG9yIGFjY2Vzc2VkLg0KDQoNCg0KL21hcnRpbg0KDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+IFdp dGggUmVnYXJkcywNCj4NCj4gUm9oaXQgUg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4N Cj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDI5LCAyMDE4IDEyOjU5OjUzIFBNDQo+IFRvOiByb2hp dHJyYW5hZGVAb3V0bG9vay5jb20NCj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW25ldG1vZF0gQ29tbWVudHMgb24gc2NoZW1hIG1vdW50IGRyYWZ0DQo+DQo+IEhpLA0KPg0K PiBSb2hpdCBSYW5hZGUgPHJvaGl0cnJhbmFkZUBvdXRsb29rLmNvbT4gd3JvdGU6DQo+ID4gSGkg TWFydGluLA0KPiA+DQo+ID4gVy5yLnQgPGdldC1zY2hlbWE+IG9uIHRoZSBtYWluIGRldmljZSwg aXQgd2lsbCBtZWFuIHRoYXQgZm9yDQo+ID4gc3VjY2Vzc2Z1bCA8Z2V0LXNjaGVtYT4gZm9yIGFs bCB0aGUgc2NoZW1hIG9mIG1vdW50ZWQgZGV2aWNlcywgdGhlDQo+ID4gbWFpbiBkZXZpY2UgbXVz dCBiZSB1cGdyYWRlZCB0byBoaWdoZXIgdmVyc2lvbiBmaXJzdCBhbmQgbXVzdCBjb250YWluDQo+ ID4gQUxMIHRoZSBzY2hlbWEgb2YgYWxsIHRoZSBkZXZpY2VzIGJlaGluZCB0aGUgbWFpbiBkZXZp Y2UuDQo+DQo+IFRoaXMgaXMgbm90IHRoZSBpbnRlbnRpb24sIGFuZCBhcyB5b3Ugbm90ZSwgaW4g bWFueSBjYXNlcyB0aGlzIGlzIGp1c3QNCj4gbm90IHBvc3NpYmxlLg0KPg0KPiBUaGUgY2xpZW50 IGNhbiBsb29rIGF0IHRoZSAibG9jYXRpb24iIGxlYWYgaW4gdGhlIG1vdW50ZWQgWUFORyBsaWJy YXJ5DQo+IChpbiBZTGJpczsgaW4gb2xkIFlMIGl0IHdhcyBjYWxsZWQgInNjaGVtYSIpIGFuZCBn ZXQgdGhlIG1vZHVsZSBmcm9tDQo+IHRoZXJlLg0KPg0KPiBJZiB0aGUgbW91bnRlZCBzY2hlbWEg YWxzbyBtb3VudHMgImlldGYtbmV0Y29uZi1tb25pdG9yaW5nIiwgdGhlDQo+IGNsaWVudCBjYW4g aW52b2tlIHRoZSBtb3VudGVkIDxnZXQtc2NoZW1hPiBhcyBhbiBhY3Rpb24sIGFuZCByZXRyaWV2 ZQ0KPiB0aGUgc3BlY2lmaWMgdmVyc2lvbiBvZiB0aGUgbW9kdWxlIHRoYXQgaXMgbW91bnRlZCB0 aGVyZS4NCj4NCj4gPiBUaGlzIHBvaW50IG1heSBwcm92ZSB0byBiZSB0cmlja3kgYXMgdGhlIHdo b2xlIHRvcG9sb2d5IHVwZ3JhZGUgaGFzIHRvDQo+ID4gYmUgY29uc2lkZXJlZCBhbHdheXMuIEkg ZmVlbCB3ZSBjYW4gYWRkIHNvbWUgdGV4dCByZWdhcmRpbmcgdGhpcy4NCj4gPg0KPiA+IEFsc28g aG93IHRvIOKAnG1vdW504oCdIGFuIGluc3RhbmNlIG9mIGEgbW91bnQtcG9pbnQgPyBCZWNhdXNl IG9uY2UgdGhpcw0KPiA+IGRyYWZ0IGlzIG91dCwgZWFjaCBpbXBsZW1lbnRlciBtYXkgZGVmaW5l IHByaXZhdGUgUlBDcyBmb3IgbW91bnQgYW5kDQo+ID4gdW4tbW91bnQgaWYgdGhpcyBtb2R1bGUg ZG9lcyBub3QgZGVmaW5lIGl0LiBXaGV0aGVyIGFueSBwbGFuIGFib3V0IGl0DQo+ID4gPw0KPg0K PiBOb3RlIHRoYXQgc2NoZW1hIG1vdW50IGlzIG5vdCBhYm91dCBtb3VudGluZyBkZXZpY2VzOyB0 aGF0IHdvdWxkIGJlIGENCj4gZnV0dXJlIHNwZWNpYWxpemF0aW9uIG9mIHRoaXMgbWVjaGFuaXNt Lg0KPg0KPiBJbiB0aGUgTE5FIGFuZCBOSSBkcmFmdHMsIGVudGl0aWVzIGFyZSAibW91bnRlZCIg YnkgY3JlYXRpbmcgZW50cmllcw0KPiBpbiB0aGUgY29ycmVzcG9uZGluZyBsaXN0cy4gIFRoZXJl IGlzIG5vIG5lZWQgZm9yIGEgIm1vdW50IiBycGMgaW4NCj4gdGhlc2UgY2FzZXMuDQo+DQo+DQo+ IC9tYXJ0aW4NCj4NCj4NCj4NCj4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFdpdGggUmVnYXJk cywNCj4gPiBSb2hpdCBSDQo+ID4NCj4gPiBTZW50IGZyb20gTWFpbDxodHRwczovL2dvLm1pY3Jv c29mdC5jb20vZndsaW5rLz9MaW5rSWQ9NTUwOTg2PiBmb3INCj4gPiBXaW5kb3dzIDEwDQo+ID4N Cj4gPiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kPG1haWx0bzptYmpAdGFpbC1mLmNvbT4NCj4gPiBT ZW50OiAyNiDgpK7gpL7gpLDgpY3gpJogMjAxOCAxMzo0MQ0KPiA+IFRvOiByb2hpdHJyYW5hZGVA b3V0bG9vay5jb208bWFpbHRvOnJvaGl0cnJhbmFkZUBvdXRsb29rLmNvbT4NCj4gPiBDYzogbmV0 bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFtu ZXRtb2RdIENvbW1lbnRzIG9uIHNjaGVtYSBtb3VudCBkcmFmdA0KPiA+DQo+ID4gSGksDQo+ID4N Cj4gPiBUaGFuayB5b3UgZm9yIHRoZXNlIGNvbW1lbnRzLCByZXBsaWVzIGlubGluZS4NCj4gPg0K PiA+IFJvaGl0IFJhbmFkZSA8cm9oaXRycmFuYWRlQG91dGxvb2suY29tPiB3cm90ZToNCj4gPiA+ IEhpIEFsbCwNCj4gPiA+DQo+ID4gPiBQbGVhc2UgZmluZCBzb21lIGNvbW1lbnRzIGZvciB0aGUg c2NoZW1hIG1vdW50IGRyYWZ0LiBJZiBJIGZpbmQgYW55DQo+ID4gPiBvdGhlciB3aWxsIHNlbmQg aW4gYW5vdGhlciBtYWlsLg0KPiA+ID4NCj4gPiA+IEVkaXRvcmlhbDoNCj4gPiA+ID09PT09PT09 PT09PQ0KPiA+ID4gMS4gU2VjdGlvbiAzLjENCj4gPiA+ICAgICJUaGUgIm1vdW50LXBvaW50IiBz dGF0ZW1lbnQgTVVTVCBOT1QgYmUgdXNlZCBpbiBhIFlBTkcgdmVyc2lvbiAxDQo+ID4gPiAgICBt b2R1bGUuIg0KPiA+ID4gICAgPT0+IEl0IGlzIHVuY2xlYXIgd2h5IHN1Y2ggYSByZXN0cmljdGlv biBpcyBwbGFjZWQuDQo+ID4NCj4gPiBUaGUgcmVhc29uIGlzIHRoYXQgWUFORyAxIGRvZXNuJ3Qg c3VwcG9ydCBpbmxpbmUgYWN0aW9ucyBhbmQNCj4gPiBub3RpZmljYXRpb24sIHdoaWNoIG1lYW5z IHRoYXQgdG9wLWxldmVsIHJwY3MgYW5kIG5vdGlmcyBpbiB0aGUNCj4gPiBtb3VudGVkIG1vZHVs ZSBjYW5ub3QgYmUgaW52b2tlZCB1c2luZyB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbg0KPiA+ IHNlY3Rpb24gNS4gIEkgd2lsbCB0cnkgdG8gY2xhcmlmeSB0aGlzLg0KPiA+DQo+ID4gPiAyLiBT ZWN0aW9uIDMuMg0KPiA+ID4gICAgInN0YXRlIGRhdGEgaW4gdGhlICJ5YW5nbW50OnNjaGVtYS1t b3VudHMiIg0KPiA+ID4gICAgPT0+IEhlcmUgdGhlIHlhbmcgdHJlZSBkaWFncmFtIGlzIG5vdCB5 ZXQgaW50cm9kdWNlZC4gSSBmZWVsIGJldHRlciB0bw0KPiA+ID4gICAgaW50cm9kdWNlDQo+ID4g PiAgICB0aGlzIGRpYWdyYW0gYXMgaXQgbWFrZXMgaXQgZWFzaWVyIHRvIHVuZGVyc3RhbmQgdGhl IGRhdGEtbm9kZXMNCj4gPg0KPiA+IE9rLiAgSSBtb3ZlZCBzZWN0aW9uIDggdG8gYSBuZXcgc2Vj dGlvbiAzLjIuDQo+ID4NCj4gPiA+IDMuIFNlY3Rpb24gMy4yDQo+ID4gPiAgICAiRGF0YSBpbiB0 aGlzIGNvbnRhaW5lciBpcyBpbnRlbmRlZCB0byBiZSBhcyBzdGFibGUgYXMgZGF0YSBpbiB0aGUN Cj4gPiA+ICAgIHRvcC1sZXZlbCBZQU5HIGxpYnJhcnkiDQo+ID4gPiAgICA9PT4gV2hhdCBpcyB0 aGUgbWVhbmluZyBvZiAiYXMgc3RhYmxlIiBhcyA/IEFzIGEgZGV2ZWxvcGVyICwgSSBhbQ0KPiA+ ID4gICAgdW5jbGVhciB3aGF0IG5lZWRzDQo+ID4gPiAgICB0byBiZSBkb25lIGhlcmUuIFBsZWFz ZSBjbGFyaWZ5Lg0KPiA+DQo+ID4gS2VudCBhbHNvIGhhZCBhIGNvbW1lbnQgYXJvdW5kIHRoaXMs IGFuZCB0aGUgdGV4dCBhYm91dCBzdGFibGUgaXMgbm93DQo+ID4gcmVtb3ZlZC4NCj4gPg0KPiA+ ID4gNC4gU2VjdGlvbiAzLjINCj4gPiA+ICAgICJpLmUuLCBpbnN0YW5jZXMgb2YgdGhhdCBtb3Vu dCBwb2ludCBNVVNUIE5PVCBjb250YWluIGFueSBkYXRhIGFib3ZlDQo+ID4gPiAgICB0aG9zZSB0 aGF0IGFyZSBkZWZpbmVkIGluIHRoZSBwYXJlbnQgc2NoZW1hLiINCj4gPiA+ICAgID09PiBIZXJl ICJhbnkgZGF0YSBhYm92ZSIsIG1lYW5zICJhYm92ZSIgaW4gdGhlIGhpZWFyYXJjaHkgPw0KPiA+ DQo+ID4gTm8sIHRoaXMgd2FzIGp1c3Qgd3Jvbmc7IGl0IHNob3VsZCBiZSAiZXhjZXB0Ii4NCj4g Pg0KPiA+ID4gICAgTm90DQo+ID4gPiAgICBjbGVhciwgdGhpcyBpcyBzaW1pbGFyDQo+ID4gPiAg ICB0byBoYXZpbmcgYSBVU0Igc2xvdCwgYnV0IG5vIGRldmljZSBtb3VudGVkIG9uIGl0IGFzIHll dCBpbiBVTklYDQo+ID4gPiAgICB0ZXJtcy4gUmlnaHQgPw0KPiA+ID4gICAgVGhlIHF1ZXJ5IG91 dHB1dCBvbiBwYXJlbnQtc2NoZW1hIHNob3VsZCBnaXZlIGVtcHR5IGRhdGEuDQo+ID4gPg0KPiA+ ID4gNS4gU2VjdGlvbiAzLjINCj4gPiA+ICAgICJJZiBtdWx0aXBsZSBtb3VudCBwb2ludHMgd2l0 aCB0aGUgc2FtZSBuYW1lIGFyZSBkZWZpbmVkIGluIHRoZSBzYW1lDQo+ID4gPiAgICBtb2R1bGUg LSBlaXRoZXIgZGlyZWN0bHkgb3IgYmVjYXVzZSB0aGUgbW91bnQgcG9pbnQgaXMgZGVmaW5lZCBp biBhDQo+ID4gPiAgICBncm91cGluZyBhbmQgdGhlIGdyb3VwaW5nIGlzIHVzZWQgbXVsdGlwbGUg dGltZXMgLSB0aGVuIHRoZQ0KPiA+ID4gICAgY29ycmVzcG9uZGluZyAibW91bnQtcG9pbnQiIGVu dHJ5IGFwcGxpZXMgZXF1YWxseSB0byBhbGwgc3VjaCBtb3VudA0KPiA+ID4gICAgcG9pbnRzLiIN Cj4gPiA+ICAgPT0+IEFzIHBlciB0cmVlIGRpYWdyYW0sICJtb3VudC1wb2ludCIgaGFzIHR3byBr ZXlzLiBTbyBlYWNoIG1vZHVsZQ0KPiA+ID4gICBjYW4gaGF2ZSBtdWx0aXBsZQ0KPiA+ID4gICBt b3VudCBwb2ludHMuIFNvIGhvdyB0byBhcHBseSBpdCAiZXF1YWxseSIgPyBOb3QgY2xlYXIuDQo+ ID4NCj4gPiBOb3RlIHRoYXQgdGhlIHNlbnRlbmNlIHN0YXJ0cyB3aXRoICJJZiBtdWx0aXBsZSBt b3VudCBwb2ludHMgd2l0aCB0aGUNCj4gPiBzYW1lIG5hbWUgYXJlIGRlZmluZWQgaW4gdGhlIHNh bWUgbW9kdWxlIiAtLSBzbyB0aGlzIGNsZWFybHkgZG9lc24ndA0KPiA+IGFwcGx5IHRvIG1vdW50 IHBvaW50cyB3aXRoIGRpZmZlcmVudCBuYW1lcywgcmlnaHQ/DQo+ID4NCj4gPiBGb3IgZXhhbXBs ZSwgeW91IGNhbiBoYXZlOg0KPiA+DQo+ID4gICBjb250YWluZXIgZm9vIHsNCj4gPiAgICAgeWFu Z21udDptb3VudC1wb2ludCBteS1tbnQtcG9pbnQ7DQo+ID4gICB9DQo+ID4gICBjb250YWluZXIg YmFyIHsNCj4gPiAgICAgeWFuZ21udDptb3VudC1wb2ludCBteS1tbnQtcG9pbnQ7DQo+ID4gICB9 DQo+ID4NCj4gPiBUaGVyZSBpcyBqdXN0IG9uZSBlbnRyeSBpbiB0aGUgIm1vdW50LXBvaW50IiBs aXN0LCBzbyB0aGF0IGVudHJ5DQo+ID4gYXBwbGllcyB0byBib3RoIHRoZXNlIG1vdW50IHBvaW50 cy4gIEJvdGggYXJlIGVpdGhlciAiaW5saW5lIiBvcg0KPiA+ICJzaGFyZWQtc2NoZW1hIi4NCj4g Pg0KPiA+DQo+ID4gPiA2LiBTZWN0aW9uIDMuMg0KPiA+ID4gICAgSW5zdGVhZCBvZiAiaW5saW5l IiBhbmQgInNoYXJlZC1zY2hlbWEiLCBJIHN1Z2dlc3QgdG8gdXNlDQo+ID4gPiAgICAidmFyaWFi bGUtc2NoZW1hIiBhbmQNCj4gPiA+ICAgICJzYW1lLXNjaGVtYSINCj4gPiA+ICAgIFJlYXNvbjog VGhlIGtleSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3byBpcyB0aGF0IGluIG9uZSBjYXNlLCB0 aGUNCj4gPiA+ICAgIHNjaGVtYSBNQVkgYmUgZGlmZmVyZW50DQo+ID4gPiAgICB3aGlsZSBpbiB0 aGUgb3RoZXIgdGhlIHNjaGVtYSBpcyBzYW1lLiBUaGUgbmFtZSBjYW4gYmUgc2ltaWxhciB0byB0 aGUNCj4gPiA+ICAgIHJlYXNvbi4NCj4gPg0KPiA+IEF0IHRoaXMgcG9pbnQsIHdlIGhhdmUgdG8g bGl2ZSB3aXRoIHRoZXNlIHRlcm1zLiAgVGhpcyB3YXMgcGFydCBvZiB0aGUNCj4gPiBjb21wcm9t aXNlIGxlYWRpbmcgdG8gdGhpcyBzb2x1dGlvbjsgdGhlcmUgYXJlIG90aGVyIGRvY3VtZW50cyBp biB0aGUNCj4gPiBSRkMgZWRpdG9yJ3MgcXVldWUgdGhhdCBkZXBlbmQgb24gdGhlc2UgdGVybXMu DQo+ID4NCj4gPiA+IExvZ2ljYWwgUG9pbnQ6DQo+ID4gPiAxLiBDb25zaWRlciB0aGUgdG9wb2xv Z3kgd2hlcmUgMSBtYWluIGRldmljZSBpcyBwcmVzZW50IHdpdGggTiBsb2dpY2FsDQo+ID4gPiBk ZXZpY2VzIGJlaGluZCBpdC4NCj4gPiA+ICAgIFdoZW4gdGhlIG1vdW50aW5nIGlzIGRvbmUsIGl0 IGlzIHF1aXRlIHBvc3NpYmxlIHRoYXQgc29tZSBvZiBOIGRldmljZXMNCj4gPiA+ICAgIGFyZSBo YXZpbmcgZGlmZmVyZW50DQo+ID4gPiAgICB2ZXJzaW9ucyBvZiBtb2R1bGVzLg0KPiA+ID4gICAg VGhpcyBjYW4gbGVhZCB0byBlYWNoIGluc3RhbmNlIG9mIG1vdW50IHBvaW50LCBoYXZpbmcgZGlm ZmVyZW50DQo+ID4gPiAgICBzY2hlbWEuDQo+ID4gPiAgICBIb3cgY2FuIHRoZSBjbGllbnQgdW5k ZXJzdGFuZCB0aGUgc2NoZW1hIG9mIGVhY2ggbW91bnQtcG9pbnQgaW5zdGFuY2UNCj4gPiA+ICAg ID8gUHJlZmVyYWJseSBnZXQtc2NoZW1hIG9mIHRoZXNlIGRldmljZXMgYW5kIHRoZW4ga25vdyB0 aGUgbW9kZWwgPw0KPiA+DQo+ID4gVGhpcyBkcmFmdCBzYXlzIHRoYXQgZWFjaCBpbnN0YW5jZSB3 aWxsIGhhdmUgaXRzIG93biBZQU5HIGxpYnJhcnkNCj4gPiBpbnN0YW5jZS4gIFNvIHRoZXJlIHRo ZSBjbGllbnQgY2FuIGRldGVjdCB3aGljaCB2ZXJzaW9ucyBvZiB0aGUNCj4gPiBkaWZmZXJlbnQg bW9kdWxlcyBlYWNoIGluc3RhbmNlIHN1cHBvcnRzLiAgVGhlbiA8Z2V0LXNjaGVtYT4gY2FuIGJl DQo+ID4gaW52b2tlZCB0byBnZXQgdGhlIG1vZHVsZXMsIGlmIGl0IGlzIHN1cHBvcnRlZC4NCj4g Pg0KPiA+DQo+ID4gL21hcnRpbg0KPiA+DQo= --_000_HK2PR0401MB12652B45BACC5902890EADA4DBBA0HK2PR0401MB1265_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ DQo8bWV0YSBuYW1lPSJ4X0dlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZp bHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPg0KPCEtLQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIn0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCnAu eF9Nc29Ob3JtYWwsIGxpLnhfTXNvTm9ybWFsLCBkaXYueF9Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZn0NCmE6eF9saW5rLCBzcGFuLnhfTXNvSHlwZXJsaW5r DQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZX0NCmE6eF92aXNpdGVk LCBzcGFuLnhfTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lfQ0KcC54X01zb0xpc3RQYXJhZ3JhcGgsIGxpLnhfTXNvTGlzdFBh cmFncmFwaCwgZGl2LnhfTXNvTGlzdFBhcmFncmFwaA0KCXttYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWZ9DQoueF9Nc29DaHBEZWZhdWx0DQoJe30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXttYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW59DQpkaXYueF9Xb3JkU2Vj dGlvbjENCgl7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW59DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbn0NCi0tPg0KPC9zdHlsZT4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9InhfV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJ4X01z b05vcm1hbCI+SGkgTWFydGluLDwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5Gb3IgYmVsb3cgcG9pbnQ6PC9wPg0KPHAgY2xhc3M9 InhfTXNvTm9ybWFsIj7igJw8L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZndDsgNC4gTkVU Q09ORiBoYXMgc29tZSAmcXVvdDtycGMmcXVvdDsgd2hpY2ggd29yayBvbiBtdWx0aXBsZSBtb3Vu dC1pbnN0YW5jZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID09Jmd0 OyBGb3IgZXhhbXBsZSAmbHQ7ZWRpdC1jb25maWcmZ3Q7ICwgJmx0O2dldC1jb25maWcmZ3Q7IG9y ICZsdDtsb2NrJmd0Oy4gV2hldGhlciB3ZSBuZWVkIHRvIGdpdmUgYTxicj4NCiZndDsgPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBndWlkZWxpbmUgZm9yIGhvdyB0byBoYW5kbGUgc3VjaCAm cXVvdDtycGMmcXVvdDssIHNvIHRoYXQgb3RoZXIgcHJvdG9jb2xzIHdoaWNoIGltcGxlbWVudCBz Y2hlbWEgbW91bnQmbmJzcDsmbmJzcDsgYWxzbyBhZGFwdCBhY2NvcmRpbmdseSA/PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVnOiBTb21ldGhpbmcgbGlrZSwgZm9yIHRy YW5zYWN0aW9uIG1hbmFnZW1lbnQsIGJldHRlciB0byBvcGVyYXRlIG9uIG9uZSBtb3VudC1pbnN0 YW5jZS48YnI+DQo8YnI+DQpUaGlzIHdvdWxkIG5vdCBiZSBjb3JyZWN0LiZuYnNwOyBJIHRoaW5r IHlvdSBhcmUgYXNzdW1pbmcgb25lIHVzZSBjYXNlOzxicj4NCndoZXJlIHNjaGVtYSBtb3VudCBp cyB1c2VkIGluIGEgKHByaW1pdGl2ZSkgb3JjaGVzdHJhdG9yIHRoYXQgYWN0dWFsbHk8YnI+DQp0 YWxrcyB0byBtdWx0aXBsZSBkZXZpY2VzICh3L28gdHJhbnNhY3Rpb24gY29udHJvbCkuPGJyPg0K PGJyPg0KTm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQganVzdCBkZWZpbmVzIGhvdyB0aGUgKnNjaGVt YSogaXMgYnVpbHQ7IG5vdDxicj4NCmhvdyBpbnN0YW5jZSBkYXRhIGlzIHN0b3JlZCBvciBhY2Nl c3NlZC48L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPuKAnTwvcD4NCjxwIGNsYXNzPSJ4X01z b05vcm1hbCI+QXMgcGVyIGV4YW1wbGUgc2hvd24gaW4gc2VjdGlvbiA0OjwvcD4NCjxwIGNsYXNz PSJ4X01zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBuZXR3b3Jr LWluc3RhbmNlczwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBuZXR3b3JrLWluc3RhbmNlKiBbbmFt ZV08L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbmFtZTwvcD4NCjxw IGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyByb290PC9wPg0KPHAgY2xhc3M9Inhf TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHJvdXRpbmc8L3A+DQo8 cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+ Q29uc2lkZXJpbmcg4oCccm9vdOKAnSBhcyBtb3VudCBwb2ludCA6Jm5ic3A7IDwvcD4NCjxwIGNs YXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5XaGVu IHF1ZXJ5aW5nIGRhdGEgZnJvbSBzY2hlbWEgbW91bnRlZCBtb2RlbHM6PC9wPg0KPHAgY2xhc3M9 InhfTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZsdDtnZXQt Y29uZmlnJmd0OzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7ICZsdDtmaWx0ZXIm Z3Q7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmx0O25l dHdvcmstaW5zdGFuY2VzJmd0OzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtuZXR3b3JrLWluc3RhbmNlJmd0OzwvcD4NCjxwIGNs YXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs dDtuYW1lJmd0OzEmbHQ7L25hbWUmZ3Q7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3Jvb3QmZ3Q7PC9wPg0K PHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3JvdXRpbmcvJmd0OzwvcD4NCjxwIGNsYXNzPSJ4X01z b05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5BbmQ8L3A+DQo8cCBj bGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jmx0 O2FjdGlvbiZndDs8L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7bmV0d29yay1pbnN0YW5jZXMmZ3Q7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O25ldHdvcmstaW5zdGFuY2UmZ3Q7PC9w Pg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmx0O25hbWUmZ3Q7MSZsdDsvbmFtZSZndDs8L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7cm9vdCZn dDs8L3A+DQo8cCBjbGFzcz0ieF9Nc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Z2V0LWNvbmZpZyZndDsmbmJzcDsgLS0g aGF2aW5nIGlldGYtbmV0Y29uZiBuczwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZsdDtmaWx0ZXImZ3Q7PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmx0O3JvdXRpbmcvJmd0OzwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7 PC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj5XaWxsIHRoZXNlIHR3byBnaXZlIHRoZSBzYW1l IHJlc3VsdCA/IDwvcD4NCjxwIGNsYXNzPSJ4X01zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xh c3M9InhfTXNvTm9ybWFsIj5XaXRoIFJlZ2FyZHMsPC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFs Ij5Sb2hpdCBSPC9wPg0KPHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFz cz0ieF9Nc29Ob3JtYWwiPlNlbnQgZnJvbSA8YSBocmVmPSJodHRwczovL2dvLm1pY3Jvc29mdC5j b20vZndsaW5rLz9MaW5rSWQ9NTUwOTg2Ij4NCk1haWw8L2E+IGZvciBXaW5kb3dzIDEwPC9wPg0K PHAgY2xhc3M9InhfTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxociB0YWJpbmRleD0i LTEiIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazsgd2lkdGg6OTglIj4NCjxkaXYgaWQ9Inhf ZGl2UnBseUZ3ZE1zZyIgZGlyPSJsdHIiPjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYi IGNvbG9yPSIjMDAwMDAwIiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxiPkZyb206PC9iPiBNYXJ0 aW4gQmpvcmtsdW5kICZsdDttYmpAdGFpbC1mLmNvbSZndDs8YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIEFwcmlsIDUsIDIwMTggNjoxMzo0OSBQTTxicj4NCjxiPlRvOjwvYj4gcm9oaXRycmFu YWRlQG91dGxvb2suY29tPGJyPg0KPGI+Q2M6PC9iPiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIENvbW1lbnRzIG9uIHNjaGVtYSBtb3VudCBkcmFmdDwv Zm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGZvbnQgc2l6ZT0iMiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPkhp LDxicj4NCjxicj4NCjxicj4NClJvaGl0IFJhbmFkZSAmbHQ7cm9oaXRycmFuYWRlQG91dGxvb2su Y29tJmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEhpIE1hcnRpbiw8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rIHlvdSBmb3IgeW91ciByZXNwb25zZXMuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEkgaGF2ZSBnb25lIHRocm91Z2ggdGhlIExORSBkcmFmdCBhbmQgWUFO RyAxLjEgYW5kIGZvdW5kIHNvbWUgbW9yZSBzdWdnZXN0aW9ucy48YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDEuIFNlY3Rpb24gNTxicj4NCiZndDsgPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtJZiBhIG1vdW50ZWQgWUFORyBtb2R1bGUgZGVmaW5l cyBhbiBSUEMgb3BlcmF0aW9uLCBjbGllbnRzIGNhbiBpbnZva2U8YnI+DQomZ3Q7IDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhpcyBvcGVyYXRpb24gYXMgaWYgaXQgd2VyZSBkZWZpbmVk IGFzIGFuIGFjdGlvbiBmb3IgdGhlPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGNvcnJlc3BvbmRpbmcgbW91bnQgcG9pbnQmcXVvdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsgPT0mZ3Q7IEJlbG93IGlzIHRoZSBleGFtcGxlIGZyb20gWWFuZyAx LjEgU2VjdGlvbiA3LjE1PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7cnBjIG1lc3NhZ2UtaWQ9JnF1b3Q7MTAxJnF1 b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHhtbG5zPSZxdW90O3VybjppZXRmOnBhcmFtczp4 bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90OyZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2FjdGlvbiB4bWxucz0m cXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6MSZxdW90OyZndDs8YnI+DQomZ3Q7IDxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmx0O3NlcnZlciB4bWxucz0mcXVvdDt1cm46ZXhhbXBsZTpzZXJ2ZXItZmFybSZxdW90 OyZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O25hbWUmZ3Q7YXBhY2hlLTEm bHQ7L25hbWUmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtyZXNldCZndDs8 YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3Jlc2V0LWF0Jmd0 OzIwMTQtMDctMjlUMTM6NDI6MDBaJmx0Oy9yZXNldC1hdCZndDs8YnI+DQomZ3Q7IDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0Oy9yZXNldCZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy9zZXJ2ZXIm Z3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDsvYWN0aW9uJmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L3JwYyZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtycGMt cmVwbHkgbWVzc2FnZS1pZD0mcXVvdDsxMDEmcXVvdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeG1sbnM9JnF1b3Q7dXJuOmlldGY6 cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wJnF1b3Q7Jmd0Ozxicj4NCiZndDsgPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7cmVzZXQt ZmluaXNoZWQtYXQgeG1sbnM9JnF1b3Q7dXJuOmV4YW1wbGU6c2VydmVyLWZhcm0mcXVvdDsmZ3Q7 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIwMTQtMDctMjlUMTM6NDI6MTJaPGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvcmVzZXQt ZmluaXNoZWQtYXQmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDsvcnBjLXJlcGx5Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA9PSZndDsgSGVyZSBycGMtcmVwbHkgb25seSBoYXMgdGhlIG5h bWVzcGFjZSBhbmQgYWN0aW9uIG5hbWUgZGVmaW5lZCBpbiB0aGUgbW91bnQtaW5zdGFuY2UncyBt b2R1bGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSBjbGllbnQgbmVlZHMgdG8gc3RvcmUgaW5mb3JtYXRpb24gb2YgdGhlIG1vdW50LWluc3RhbmNl IGZvciB3aGljaCB0aGUgUlBDIHJlcXVlc3Qgd2FzIHNlbnQgYW5kIG9ubHkgdGhlbiBpdCBjYW4g dmFsaWRhdGUgdGhlIHJwYy1yZXBseSBhZ2FpbnN0IHRoZSBkYXRhLW1vZGVsLjxicj4NCiZndDsg PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUbyBhdm9pZCB0aGlzIHdvcmsg b2YgY2xpZW50LCB3aGV0aGVyIHdlIGNhbiB0aGluayBvZiBhZGRpbmcgbWV0YS1kYXRhIHRvIHJw Yy1yZXBseSB0byBwcm92aWRlIHRoaXMgaW5mb3JtYXRpb24gdG8gY2xpZW50Ljxicj4NCjxicj4N CklmIHRoZSBjbGllbnQgaW52b2tlcyBhbiBhY3Rpb24sIGl0IGlzIGV4cGVjdGVkIHRoYXQgaXQg a25vd3MgaG93IHRvPGJyPg0KaW50ZXJwcmV0IHRoZSByZXN1bHQuJm5ic3A7IFRoaXMgZG9lcyBu b3QgY2hhbmdlIHdpdGggdGhlIGludHJvZHVjdGlvbiBvZjxicj4NCnNjaGVtYSBtb3VudC4mbmJz cDsgVGhlIGNsaWVudCBvYnZpb3VzbHkga25vd3MgdGhlIG5hbWUgYW5kIGlucHV0PGJyPg0KcGFy YW1ldGVycyBvZiB0aGUgYWN0aW9uLCBzbyBpdCBzZWVtcyByZXNvbmFibGUgdG8gZXhwZWN0IHRo YXQgaXQ8YnI+DQprbm93cyB0aGUgb3V0cHV0IHBhcmFtZXRlcnMgYXMgd2VsbCwgdy9vIGFueSBh ZGRpdGlvbmFsIG1ldGEgZGF0YS48YnI+DQo8YnI+DQomZ3Q7IDIuIFNlY3Rpb24gNTxicj4NCiZn dDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBJIHdvdWxkIHByZWZlciB0aGUgYXBwcm9h Y2ggdGFrZW4gYnkgWWFuZyAxLjEgd2hlcmUgc3RhdGVtZW50cyBmb2xsb3dlZCBieSBYTUwgZXhh bXBsZXMmbmJzcDsmbmJzcDsgdG8gaGVscCBpbiBjbGFyaXR5Ljxicj4NCiZndDsgPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyBFc3BlY2lhbGx5IGZvciB0aGUgUlBDIGFuZCBub3RpZmljYXRp b24gc2VjdGlvbiwgaXQgaXMgYmV0dGVyIHRvIGFkZCBjbGVhciBleGFtcGxlczxicj4NCiZndDsg PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBpbiBhICZxdW90O1VzYWdlIEV4YW1wbGUmcXVv dDsgc3ViLXNlY3Rpb24gZm9yIHRoaXMgc2VjdGlvbi48YnI+DQo8YnI+DQpUaGUgZXhhbXBsZXMg YXJlIGdpdmVuIGluIHRoZSBhcHBlbmRpeCwgYW5kIHRoZXJlIGlzIGEgZm9yd2FyZDxicj4NCnJl ZmVyZW5jZSB0byB0aGUgYXBwZW5kaXggZnJvbSBzZWN0aW9uIDUuPGJyPg0KPGJyPg0KPGJyPg0K Jmd0OyAzLiBZYW5nIFJQQyBhbmQgQUNUSU9OIHN0YXRlbWVudHM6PGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7IElmIHdlIG5lZWQgdG8gdmlldyB0aGUgUlBDIGRlZmluZWQgaW4gYSBt b2R1bGUgYXMgYW4gQUNUSU9OIGFmdGVyIHNjaGVtYSBtb3VudCwgdGhlbjxicj4NCiZndDsgPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyBXaGVuZXZlciB0aGVyZSBpcyB1cGRhdGUgdG8gUlBDIGluIHNh eSBZQU5HIDEuMiwgdGhlbiB0aGUgY29ycmVzcG9uZGluZyBjaGFuZ2VzIG11c3QgYmUgcHJlc2Vu dCBpbiBBQ1RJT04gYWxzbywgaW50cm9kdWNpbmcgYSBjb3VwbGluZyBiZXR3ZWVuIFJQQyBhbmQg QUNUSU9OIHN0YXRlbWVudHMuPGJyPg0KPGJyPg0KVGhpcyBtb2R1bGUgaXMgd3JpdHRlbiB1c2lu ZyBZQU5HIDEuMS4mbmJzcDsgVW5sZXNzIHRoaXMgbW9kdWxlIGlzIHVwZGF0ZWQsPGJyPg0KaXQg ZG9lc24ndCBtYXR0ZXIgd2hhdCBZQU5HIDIuMCBvciB3aGF0ZXZlciBkb2VzLjxicj4NCjxicj4N CiZndDsgNC4gTkVUQ09ORiBoYXMgc29tZSAmcXVvdDtycGMmcXVvdDsgd2hpY2ggd29yayBvbiBt dWx0aXBsZSBtb3VudC1pbnN0YW5jZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ID09Jmd0OyBGb3IgZXhhbXBsZSAmbHQ7ZWRpdC1jb25maWcmZ3Q7ICwgJmx0O2dldC1j b25maWcmZ3Q7IG9yICZsdDtsb2NrJmd0Oy4gV2hldGhlciB3ZSBuZWVkIHRvIGdpdmUgYTxicj4N CiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBndWlkZWxpbmUgZm9yIGhvdyB0byBo YW5kbGUgc3VjaCAmcXVvdDtycGMmcXVvdDssIHNvIHRoYXQgb3RoZXIgcHJvdG9jb2xzIHdoaWNo IGltcGxlbWVudCBzY2hlbWEgbW91bnQmbmJzcDsmbmJzcDsgYWxzbyBhZGFwdCBhY2NvcmRpbmds eSA/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVnOiBTb21ldGhpbmcg bGlrZSwgZm9yIHRyYW5zYWN0aW9uIG1hbmFnZW1lbnQsIGJldHRlciB0byBvcGVyYXRlIG9uIG9u ZSBtb3VudC1pbnN0YW5jZS48YnI+DQo8YnI+DQpUaGlzIHdvdWxkIG5vdCBiZSBjb3JyZWN0LiZu YnNwOyBJIHRoaW5rIHlvdSBhcmUgYXNzdW1pbmcgb25lIHVzZSBjYXNlOzxicj4NCndoZXJlIHNj aGVtYSBtb3VudCBpcyB1c2VkIGluIGEgKHByaW1pdGl2ZSkgb3JjaGVzdHJhdG9yIHRoYXQgYWN0 dWFsbHk8YnI+DQp0YWxrcyB0byBtdWx0aXBsZSBkZXZpY2VzICh3L28gdHJhbnNhY3Rpb24gY29u dHJvbCkuPGJyPg0KPGJyPg0KTm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQganVzdCBkZWZpbmVzIGhv dyB0aGUgKnNjaGVtYSogaXMgYnVpbHQ7IG5vdDxicj4NCmhvdyBpbnN0YW5jZSBkYXRhIGlzIHN0 b3JlZCBvciBhY2Nlc3NlZC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQovbWFydGluPGJyPg0KPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdpdGggUmVnYXJkcyw8YnI+DQomZ3Q7IDxicj4N CiZndDsgUm9oaXQgUjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEZyb206IE1hcnRpbiBC am9ya2x1bmQgJmx0O21iakB0YWlsLWYuY29tJmd0Ozxicj4NCiZndDsgU2VudDogVGh1cnNkYXks IE1hcmNoIDI5LCAyMDE4IDEyOjU5OjUzIFBNPGJyPg0KJmd0OyBUbzogcm9oaXRycmFuYWRlQG91 dGxvb2suY29tPGJyPg0KJmd0OyBDYzogbmV0bW9kQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0 OiBSZTogW25ldG1vZF0gQ29tbWVudHMgb24gc2NoZW1hIG1vdW50IGRyYWZ0PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBSb2hpdCBSYW5hZGUgJmx0O3JvaGl0 cnJhbmFkZUBvdXRsb29rLmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IEhpIE1hcnRpbiw8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVy5yLnQgJmx0O2dldC1zY2hlbWEmZ3Q7IG9u IHRoZSBtYWluIGRldmljZSwgaXQgd2lsbCBtZWFuIHRoYXQgZm9yPGJyPg0KJmd0OyAmZ3Q7IHN1 Y2Nlc3NmdWwgJmx0O2dldC1zY2hlbWEmZ3Q7IGZvciBhbGwgdGhlIHNjaGVtYSBvZiBtb3VudGVk IGRldmljZXMsIHRoZTxicj4NCiZndDsgJmd0OyBtYWluIGRldmljZSBtdXN0IGJlIHVwZ3JhZGVk IHRvIGhpZ2hlciB2ZXJzaW9uIGZpcnN0IGFuZCBtdXN0IGNvbnRhaW48YnI+DQomZ3Q7ICZndDsg QUxMIHRoZSBzY2hlbWEgb2YgYWxsIHRoZSBkZXZpY2VzIGJlaGluZCB0aGUgbWFpbiBkZXZpY2Uu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMgaXMgbm90IHRoZSBpbnRlbnRpb24sIGFuZCBhcyB5 b3Ugbm90ZSwgaW4gbWFueSBjYXNlcyB0aGlzIGlzIGp1c3Q8YnI+DQomZ3Q7IG5vdCBwb3NzaWJs ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGNsaWVudCBjYW4gbG9vayBhdCB0aGUgJnF1b3Q7 bG9jYXRpb24mcXVvdDsgbGVhZiBpbiB0aGUgbW91bnRlZCBZQU5HIGxpYnJhcnk8YnI+DQomZ3Q7 IChpbiBZTGJpczsgaW4gb2xkIFlMIGl0IHdhcyBjYWxsZWQgJnF1b3Q7c2NoZW1hJnF1b3Q7KSBh bmQgZ2V0IHRoZSBtb2R1bGUgZnJvbTxicj4NCiZndDsgdGhlcmUuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IElmIHRoZSBtb3VudGVkIHNjaGVtYSBhbHNvIG1vdW50cyAmcXVvdDtpZXRmLW5ldGNvbmYt bW9uaXRvcmluZyZxdW90OywgdGhlPGJyPg0KJmd0OyBjbGllbnQgY2FuIGludm9rZSB0aGUgbW91 bnRlZCAmbHQ7Z2V0LXNjaGVtYSZndDsgYXMgYW4gYWN0aW9uLCBhbmQgcmV0cmlldmU8YnI+DQom Z3Q7IHRoZSBzcGVjaWZpYyB2ZXJzaW9uIG9mIHRoZSBtb2R1bGUgdGhhdCBpcyBtb3VudGVkIHRo ZXJlLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgcG9pbnQgbWF5IHByb3ZlIHRvIGJl IHRyaWNreSBhcyB0aGUgd2hvbGUgdG9wb2xvZ3kgdXBncmFkZSBoYXMgdG88YnI+DQomZ3Q7ICZn dDsgYmUgY29uc2lkZXJlZCBhbHdheXMuIEkgZmVlbCB3ZSBjYW4gYWRkIHNvbWUgdGV4dCByZWdh cmRpbmcgdGhpcy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQWxzbyBob3cgdG8g4oCc bW91bnTigJ0gYW4gaW5zdGFuY2Ugb2YgYSBtb3VudC1wb2ludCA/IEJlY2F1c2Ugb25jZSB0aGlz PGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0IGlzIG91dCwgZWFjaCBpbXBsZW1lbnRlciBtYXkgZGVmaW5l IHByaXZhdGUgUlBDcyBmb3IgbW91bnQgYW5kPGJyPg0KJmd0OyAmZ3Q7IHVuLW1vdW50IGlmIHRo aXMgbW9kdWxlIGRvZXMgbm90IGRlZmluZSBpdC4gV2hldGhlciBhbnkgcGxhbiBhYm91dCBpdDxi cj4NCiZndDsgJmd0OyA/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5vdGUgdGhhdCBzY2hlbWEgbW91 bnQgaXMgbm90IGFib3V0IG1vdW50aW5nIGRldmljZXM7IHRoYXQgd291bGQgYmUgYTxicj4NCiZn dDsgZnV0dXJlIHNwZWNpYWxpemF0aW9uIG9mIHRoaXMgbWVjaGFuaXNtLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBJbiB0aGUgTE5FIGFuZCBOSSBkcmFmdHMsIGVudGl0aWVzIGFyZSAmcXVvdDttb3Vu dGVkJnF1b3Q7IGJ5IGNyZWF0aW5nIGVudHJpZXM8YnI+DQomZ3Q7IGluIHRoZSBjb3JyZXNwb25k aW5nIGxpc3RzLiZuYnNwOyBUaGVyZSBpcyBubyBuZWVkIGZvciBhICZxdW90O21vdW50JnF1b3Q7 IHJwYyBpbjxicj4NCiZndDsgdGhlc2UgY2FzZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgL21hcnRpbjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IFdpdGggUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgUm9oaXQgUjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBTZW50IGZyb20gTWFpbCZsdDs8YSBocmVmPSJo dHRwczovL2dvLm1pY3Jvc29mdC5jb20vZndsaW5rLz9MaW5rSWQ9NTUwOTg2Ij5odHRwczovL2dv Lm1pY3Jvc29mdC5jb20vZndsaW5rLz9MaW5rSWQ9NTUwOTg2PC9hPiZndDsgZm9yPGJyPg0KJmd0 OyAmZ3Q7IFdpbmRvd3MgMTA8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRnJvbTogTWFy dGluIEJqb3JrbHVuZCZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPm1haWx0bzpt YmpAdGFpbC1mLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IDI2IOCkruCkvuCksOCl jeCkmiAyMDE4IDEzOjQxPGJyPg0KJmd0OyAmZ3Q7IFRvOiByb2hpdHJyYW5hZGVAb3V0bG9vay5j b20mbHQ7bWFpbHRvOnJvaGl0cnJhbmFkZUBvdXRsb29rLmNvbSZndDs8YnI+DQomZ3Q7ICZndDsg Q2M6IG5ldG1vZEBpZXRmLm9yZyZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5t YWlsdG86bmV0bW9kQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6 IFtuZXRtb2RdIENvbW1lbnRzIG9uIHNjaGVtYSBtb3VudCBkcmFmdDxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhhbmsgeW91 IGZvciB0aGVzZSBjb21tZW50cywgcmVwbGllcyBpbmxpbmUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IFJvaGl0IFJhbmFkZSAmbHQ7cm9oaXRycmFuYWRlQG91dGxvb2suY29tJmd0OyB3 cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyBIaSBBbGwsPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyBQbGVhc2UgZmluZCBzb21lIGNvbW1lbnRzIGZvciB0aGUgc2NoZW1h IG1vdW50IGRyYWZ0LiBJZiBJIGZpbmQgYW55PGJyPg0KJmd0OyAmZ3Q7ICZndDsgb3RoZXIgd2ls bCBzZW5kIGluIGFub3RoZXIgbWFpbC48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7IEVkaXRvcmlhbDo8YnI+DQomZ3Q7ICZndDsgJmd0OyA9PT09PT09PT09PT08YnI+DQom Z3Q7ICZndDsgJmd0OyAxLiBTZWN0aW9uIDMuMTxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90O1RoZSAmcXVvdDttb3VudC1wb2ludCZxdW90OyBzdGF0ZW1lbnQgTVVT VCBOT1QgYmUgdXNlZCBpbiBhIFlBTkcgdmVyc2lvbiAxPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsgbW9kdWxlLiZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7ID09Jmd0OyBJdCBpcyB1bmNsZWFyIHdoeSBzdWNoIGEgcmVzdHJpY3Rpb24gaXMg cGxhY2VkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgcmVhc29uIGlzIHRoYXQg WUFORyAxIGRvZXNuJ3Qgc3VwcG9ydCBpbmxpbmUgYWN0aW9ucyBhbmQ8YnI+DQomZ3Q7ICZndDsg bm90aWZpY2F0aW9uLCB3aGljaCBtZWFucyB0aGF0IHRvcC1sZXZlbCBycGNzIGFuZCBub3RpZnMg aW4gdGhlPGJyPg0KJmd0OyAmZ3Q7IG1vdW50ZWQgbW9kdWxlIGNhbm5vdCBiZSBpbnZva2VkIHVz aW5nIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluPGJyPg0KJmd0OyAmZ3Q7IHNlY3Rpb24gNS4m bmJzcDsgSSB3aWxsIHRyeSB0byBjbGFyaWZ5IHRoaXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgMi4gU2VjdGlvbiAzLjI8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDtzdGF0ZSBkYXRhIGluIHRoZSAmcXVvdDt5YW5nbW50OnNjaGVtYS1tb3Vu dHMmcXVvdDsmcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyA9PSZn dDsgSGVyZSB0aGUgeWFuZyB0cmVlIGRpYWdyYW0gaXMgbm90IHlldCBpbnRyb2R1Y2VkLiBJIGZl ZWwgYmV0dGVyIHRvPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50cm9k dWNlPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhpcyBkaWFncmFtIGFz IGl0IG1ha2VzIGl0IGVhc2llciB0byB1bmRlcnN0YW5kIHRoZSBkYXRhLW5vZGVzPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9rLiZuYnNwOyBJIG1vdmVkIHNlY3Rpb24gOCB0byBhIG5l dyBzZWN0aW9uIDMuMi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAzLiBTZWN0 aW9uIDMuMjxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0RhdGEg aW4gdGhpcyBjb250YWluZXIgaXMgaW50ZW5kZWQgdG8gYmUgYXMgc3RhYmxlIGFzIGRhdGEgaW4g dGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdG9wLWxldmVsIFlBTkcg bGlicmFyeSZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID09Jmd0 OyBXaGF0IGlzIHRoZSBtZWFuaW5nIG9mICZxdW90O2FzIHN0YWJsZSZxdW90OyBhcyA/IEFzIGEg ZGV2ZWxvcGVyICwgSSBhbTxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVu Y2xlYXIgd2hhdCBuZWVkczxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRv IGJlIGRvbmUgaGVyZS4gUGxlYXNlIGNsYXJpZnkuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IEtlbnQgYWxzbyBoYWQgYSBjb21tZW50IGFyb3VuZCB0aGlzLCBhbmQgdGhlIHRleHQgYWJv dXQgc3RhYmxlIGlzIG5vdzxicj4NCiZndDsgJmd0OyByZW1vdmVkLjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7IDQuIFNlY3Rpb24gMy4yPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsgJnF1b3Q7aS5lLiwgaW5zdGFuY2VzIG9mIHRoYXQgbW91bnQgcG9pbnQg TVVTVCBOT1QgY29udGFpbiBhbnkgZGF0YSBhYm92ZTxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHRob3NlIHRoYXQgYXJlIGRlZmluZWQgaW4gdGhlIHBhcmVudCBzY2hlbWEu JnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgPT0mZ3Q7IEhlcmUg JnF1b3Q7YW55IGRhdGEgYWJvdmUmcXVvdDssIG1lYW5zICZxdW90O2Fib3ZlJnF1b3Q7IGluIHRo ZSBoaWVhcmFyY2h5ID88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgTm8sIHRoaXMgd2Fz IGp1c3Qgd3Jvbmc7IGl0IHNob3VsZCBiZSAmcXVvdDtleGNlcHQmcXVvdDsuPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTm90PGJyPg0KJmd0OyAm Z3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgY2xlYXIsIHRoaXMgaXMgc2ltaWxhcjxicj4NCiZn dDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGhhdmluZyBhIFVTQiBzbG90LCBidXQg bm8gZGV2aWNlIG1vdW50ZWQgb24gaXQgYXMgeWV0IGluIFVOSVg8YnI+DQomZ3Q7ICZndDsgJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyB0ZXJtcy4gUmlnaHQgPzxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoZSBxdWVyeSBvdXRwdXQgb24gcGFyZW50LXNjaGVtYSBzaG91bGQg Z2l2ZSBlbXB0eSBkYXRhLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg NS4gU2VjdGlvbiAzLjI8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVv dDtJZiBtdWx0aXBsZSBtb3VudCBwb2ludHMgd2l0aCB0aGUgc2FtZSBuYW1lIGFyZSBkZWZpbmVk IGluIHRoZSBzYW1lPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbW9kdWxl IC0gZWl0aGVyIGRpcmVjdGx5IG9yIGJlY2F1c2UgdGhlIG1vdW50IHBvaW50IGlzIGRlZmluZWQg aW4gYTxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdyb3VwaW5nIGFuZCB0 aGUgZ3JvdXBpbmcgaXMgdXNlZCBtdWx0aXBsZSB0aW1lcyAtIHRoZW4gdGhlPGJyPg0KJmd0OyAm Z3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgY29ycmVzcG9uZGluZyAmcXVvdDttb3VudC1wb2lu dCZxdW90OyBlbnRyeSBhcHBsaWVzIGVxdWFsbHkgdG8gYWxsIHN1Y2ggbW91bnQ8YnI+DQomZ3Q7 ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBwb2ludHMuJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsmbmJzcDsmbmJzcDsgPT0mZ3Q7IEFzIHBlciB0cmVlIGRpYWdyYW0sICZxdW90O21vdW50 LXBvaW50JnF1b3Q7IGhhcyB0d28ga2V5cy4gU28gZWFjaCBtb2R1bGU8YnI+DQomZ3Q7ICZndDsg Jmd0OyZuYnNwOyZuYnNwOyBjYW4gaGF2ZSBtdWx0aXBsZTxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5i c3A7Jm5ic3A7IG1vdW50IHBvaW50cy4gU28gaG93IHRvIGFwcGx5IGl0ICZxdW90O2VxdWFsbHkm cXVvdDsgPyBOb3QgY2xlYXIuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE5vdGUgdGhh dCB0aGUgc2VudGVuY2Ugc3RhcnRzIHdpdGggJnF1b3Q7SWYgbXVsdGlwbGUgbW91bnQgcG9pbnRz IHdpdGggdGhlPGJyPg0KJmd0OyAmZ3Q7IHNhbWUgbmFtZSBhcmUgZGVmaW5lZCBpbiB0aGUgc2Ft ZSBtb2R1bGUmcXVvdDsgLS0gc28gdGhpcyBjbGVhcmx5IGRvZXNuJ3Q8YnI+DQomZ3Q7ICZndDsg YXBwbHkgdG8gbW91bnQgcG9pbnRzIHdpdGggZGlmZmVyZW50IG5hbWVzLCByaWdodD88YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRm9yIGV4YW1wbGUsIHlvdSBjYW4gaGF2ZTo8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsmbmJzcDsgY29udGFpbmVyIGZvbyB7PGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHlhbmdtbnQ6bW91bnQtcG9pbnQgbXkt bW50LXBvaW50Ozxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNwOyB9PGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7Jm5ic3A7IGNvbnRhaW5lciBiYXIgezxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB5YW5nbW50Om1vdW50LXBvaW50IG15LW1udC1wb2ludDs8YnI+DQomZ3Q7ICZndDsm bmJzcDsmbmJzcDsgfTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGVyZSBpcyBqdXN0 IG9uZSBlbnRyeSBpbiB0aGUgJnF1b3Q7bW91bnQtcG9pbnQmcXVvdDsgbGlzdCwgc28gdGhhdCBl bnRyeTxicj4NCiZndDsgJmd0OyBhcHBsaWVzIHRvIGJvdGggdGhlc2UgbW91bnQgcG9pbnRzLiZu YnNwOyBCb3RoIGFyZSBlaXRoZXIgJnF1b3Q7aW5saW5lJnF1b3Q7IG9yPGJyPg0KJmd0OyAmZ3Q7 ICZxdW90O3NoYXJlZC1zY2hlbWEmcXVvdDsuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgNi4gU2VjdGlvbiAzLjI8YnI+DQomZ3Q7ICZndDsgJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBJbnN0ZWFkIG9mICZxdW90O2lubGluZSZxdW90OyBhbmQgJnF1b3Q7 c2hhcmVkLXNjaGVtYSZxdW90OywgSSBzdWdnZXN0IHRvIHVzZTxicj4NCiZndDsgJmd0OyAmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3ZhcmlhYmxlLXNjaGVtYSZxdW90OyBhbmQ8YnI+DQom Z3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtzYW1lLXNjaGVtYSZxdW90Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlYXNvbjogVGhlIGtleSBkaWZm ZXJlbmNlIGJldHdlZW4gdGhlIHR3byBpcyB0aGF0IGluIG9uZSBjYXNlLCB0aGU8YnI+DQomZ3Q7 ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBzY2hlbWEgTUFZIGJlIGRpZmZlcmVudDxicj4N CiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWxlIGluIHRoZSBvdGhlciB0aGUg c2NoZW1hIGlzIHNhbWUuIFRoZSBuYW1lIGNhbiBiZSBzaW1pbGFyIHRvIHRoZTxicj4NCiZndDsg Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlYXNvbi48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgQXQgdGhpcyBwb2ludCwgd2UgaGF2ZSB0byBsaXZlIHdpdGggdGhlc2UgdGVybXMu Jm5ic3A7IFRoaXMgd2FzIHBhcnQgb2YgdGhlPGJyPg0KJmd0OyAmZ3Q7IGNvbXByb21pc2UgbGVh ZGluZyB0byB0aGlzIHNvbHV0aW9uOyB0aGVyZSBhcmUgb3RoZXIgZG9jdW1lbnRzIGluIHRoZTxi cj4NCiZndDsgJmd0OyBSRkMgZWRpdG9yJ3MgcXVldWUgdGhhdCBkZXBlbmQgb24gdGhlc2UgdGVy bXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgTG9naWNhbCBQb2ludDo8YnI+ DQomZ3Q7ICZndDsgJmd0OyAxLiBDb25zaWRlciB0aGUgdG9wb2xvZ3kgd2hlcmUgMSBtYWluIGRl dmljZSBpcyBwcmVzZW50IHdpdGggTiBsb2dpY2FsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZGV2aWNl cyBiZWhpbmQgaXQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgV2hlbiB0 aGUgbW91bnRpbmcgaXMgZG9uZSwgaXQgaXMgcXVpdGUgcG9zc2libGUgdGhhdCBzb21lIG9mIE4g ZGV2aWNlczxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZSBoYXZpbmcg ZGlmZmVyZW50PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdmVyc2lvbnMg b2YgbW9kdWxlcy48YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGNh biBsZWFkIHRvIGVhY2ggaW5zdGFuY2Ugb2YgbW91bnQgcG9pbnQsIGhhdmluZyBkaWZmZXJlbnQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBzY2hlbWEuPGJyPg0KJmd0OyAm Z3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgSG93IGNhbiB0aGUgY2xpZW50IHVuZGVyc3RhbmQg dGhlIHNjaGVtYSBvZiBlYWNoIG1vdW50LXBvaW50IGluc3RhbmNlPGJyPg0KJmd0OyAmZ3Q7ICZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgPyBQcmVmZXJhYmx5IGdldC1zY2hlbWEgb2YgdGhlc2UgZGV2 aWNlcyBhbmQgdGhlbiBrbm93IHRoZSBtb2RlbCA/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IFRoaXMgZHJhZnQgc2F5cyB0aGF0IGVhY2ggaW5zdGFuY2Ugd2lsbCBoYXZlIGl0cyBvd24g WUFORyBsaWJyYXJ5PGJyPg0KJmd0OyAmZ3Q7IGluc3RhbmNlLiZuYnNwOyBTbyB0aGVyZSB0aGUg Y2xpZW50IGNhbiBkZXRlY3Qgd2hpY2ggdmVyc2lvbnMgb2YgdGhlPGJyPg0KJmd0OyAmZ3Q7IGRp ZmZlcmVudCBtb2R1bGVzIGVhY2ggaW5zdGFuY2Ugc3VwcG9ydHMuJm5ic3A7IFRoZW4gJmx0O2dl dC1zY2hlbWEmZ3Q7IGNhbiBiZTxicj4NCiZndDsgJmd0OyBpbnZva2VkIHRvIGdldCB0aGUgbW9k dWxlcywgaWYgaXQgaXMgc3VwcG9ydGVkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAvbWFydGluPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KPC9kaXY+DQo8L3NwYW4+ PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HK2PR0401MB12652B45BACC5902890EADA4DBBA0HK2PR0401MB1265_-- From nobody Fri Apr 6 06:22:53 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8866A12702E for ; Fri, 6 Apr 2018 06:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBL75iOx0te1 for ; Fri, 6 Apr 2018 06:22:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AFFE1201FA for ; Fri, 6 Apr 2018 06:22:49 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:4431:4fff:fe6e:1c10]) by mail.nic.cz (Postfix) with ESMTPSA id 289476244A; Fri, 6 Apr 2018 15:22:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1523020968; bh=fPWqFLiYCsYxGyga+hLdBT+HyB07bdHzZBSL2oqYrgw=; h=From:To:Date; b=T1qod7AeW4K3XtobemwOrssO48+zczpdyohUk1tJDsj/VTQrIcQ1ZTsX1744D2OFG 9nyZ2KpxAA2ueYKGKhBp1s2vho+5dhFL89bKzsN3kOvoeTcr/42sxnPTUSISTVQhXl BHUHdUHHcqz3pG8B1wZRuQFzxuJBy9JBu64QszO0= Message-ID: <8de7899b9f7c7b61d200c2b6ad11aeca45d712df.camel@nic.cz> From: Ladislav Lhotka To: Juergen Schoenwaelder Cc: netmod@ietf.org Date: Fri, 06 Apr 2018 15:22:47 +0200 In-Reply-To: <20180406122901.yayqpgrvxmjzu4eo@elstar.local> References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> <20180406122901.yayqpgrvxmjzu4eo@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 13:22:52 -0000 On Fri, 2018-04-06 at 14:29 +0200, Juergen Schoenwaelder wrote: > On Fri, Apr 06, 2018 at 02:01:30PM +0200, Ladislav Lhotka wrote: > > On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote: > > > On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: > > > > Juergen Schoenwaelder writes: > > > > > > > > > If we would have a mechanism to deviate an identityref to a subset of > > > > > identity values supported by an implementation, we would have solved a > > > > > more generic problem. Yes, the IANA list could be 'nicer' but it will > > > > > never be 'nice'. > > > > > > > > Three mechanisms can be used for this: > > > > > > > > - splitting the identities into separate modules > > > > > > Whatever module organization you come up with, it won't work for all > > > implementations. > > > > > > > - using features > > > > > > Making every identity a feature will turn the feature system upside > > > down. This is similar to making every leaf a feature. > > > > > > > - using deviations (even though vendors frown on them) > > > > > > If my implementation only supports A and B and C, then a deviation may > > > state exactly that and the problem is solved. Hoping that my specific > > > > In fact, deviations cannot delete identity values because they aren't schema > > nodes, so they are of no use. > > Putting today's limits of YANG syntax aside for the moment, I still > believe implementations need to publish the identities they support > without requiring matching features or module definition. OK, but then I certainly wouldn't call it a deviation. > > > > combination of A and B and C matches a set of modules or some set of > > > features is in my view an illusion. > > > > An implementation that supports, say, a given type of tunnel interface will > > implement the module that covers this tunnel type. If the identity for this > > tunnel interface type is defined in the same module, then all is good. I > > don't > > get why this should be an illusion. On the contrary, I think it is the > > cleanest > > available solution to this conformance specification problem. > > > > > > > > Vendors not shipping proper deviations are essentially telling their > > > customers that they have not yet understood model driven management. > > > We need to change the mindset here instead of polluting our data > > > models with hundreds or thousands of fine grained 'features'. > > > > I agree that zillions of features aren't nice but it seems to be the only > > solution that we currently have for modules of the iana-if-type style. > > > > Having an bulky set of identity values, most of which are of no interest, is > > IMO > > much worse and could also be a security issue if implementors aren't careful > > enough. > > If an implementation does not check input, then the code is broken, Come on, the cyberspace is full of such code. We should do our best to enable schemas that are as strict as possible. In XML, it should have been clear to everybody that hardwired namespace prefixes are broken, and yet they were used so often that eventually the prefix-URL duality was identified as a flaw of XML itself. Lada > regardless whether we restrict the identities somewhere or not. I do > not buy the security point. > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 6 06:27:31 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859351270AB for ; Fri, 6 Apr 2018 06:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwOxFUs_LmFJ for ; Fri, 6 Apr 2018 06:27:28 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E2BD31270B4 for ; Fri, 6 Apr 2018 06:27:11 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 59E621AE034E; Fri, 6 Apr 2018 15:27:10 +0200 (CEST) Date: Fri, 06 Apr 2018 15:27:10 +0200 (CEST) Message-Id: <20180406.152710.818971844955208858.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180406122406.wdba43mr3bxsnyce@elstar.local> References: <20180329090305.eqshcqvqo33r5bsf@elstar.local> <20180405.143340.1930670144610383537.mbj@tail-f.com> <20180406122406.wdba43mr3bxsnyce@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] js review of draft-ietf-netmod-schema-mount-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 13:27:31 -0000 Hi, Juergen Schoenwaelder wrote: > On Thu, Apr 05, 2018 at 02:33:40PM +0200, Martin Bjorklund wrote: > > Hi, > > > > Thank you for this review! Comments inline. > > > > Juergen Schoenwaelder wrote: > > > Here is my review of draft-ietf-netmod-schema-mount-09. > > > > > > * Abstract > > > > > > This document defines a mechanism to combine YANG modules into the > > > schema defined in other YANG modules. > > > > > > I do not know what this says - I think this text is confusing. What > > > does it mean to 'combine' YANG modules? What is the notion of > > > 'schema' used here? > > > > Howabout: > > > > This document defines a mechanism to add the schema trees defined by > > a set of YANG modules into the schema tree defined in another YANG > > module. > > > > This is better. > > > (see more below on terminology) > > > > > Does the text help someone to decide whether > > > this mechanisms is something worth to study in order to solve a > > > given modeling problem? (A good abstract would IMHO do that.) > > > > > > Note that the mount mechanisms has serious limitations as well that > > > perhaps need to spelled out right up-front, i.e., it only works with > > > pre-defined mount-points (augments are much more flexible in this > > > regard, the schema mount defined here is by its very design not > > > very flexible. > > > > I don't agree that this is a "serious limitation", and I don't think > > an abstract should list things that the document doesn't do. > > OK. Remove 'serious' but clearly this schema mount mechanism is not as > flexible as it could me. What about this: > > This document defines a mechanism to add the schema trees defined > by a set of YANG modules onto mount points defined in another YANG > module. > > This at least hints at the fact that mount points are rather static > citizens. Ok. I tweaked it to: This document defines a mechanism to add the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in some YANG module. > > > While I think I understand the difference made between > > > implementation-time and run-time, the description is somewhat > > > confusing since the run-time mount will also be exposed via YANG > > > library and hence defining implementation-time by 'defined by a > > > server implementor and is as stable as YANG library information of > > > the server' is somewhat fuzzy. I assume what you mean is that in the > > > case 2. the mounted schema is fixed at implementation time while in > > > the case 3. the mounted schema may vary and be discovered at > > > run-time. However, you do not define things this way but rather talk > > > about properties that do however not define things. > > > > Howabout: > > > > OLD: > > > > + Run-time: the mounted schema is defined by instance data that is > > part of the mounted data model. If there are multiple instances of > > the same mount point (e.g., in multiple entries of a list), the > > mounted data model may be different for each instance. > > > > NEW: > > > > + Run-time: the mounted schema can vary at run time and is defined by > > instance data that is part of the mounted data model. If there are > > multiple instances of the same mount point (e.g., in multiple > > entries of a list), the mounted data model may be different for each > > instance. > > Better. > > > > * Glossary of New Terms > > > > > > o top-level schema: a schema according to [RFC7950] in which schema > > > trees of each module (except augments) start at the root node. > > > > > > You do not import 'schema' from RFC 7950 since, well, it is not > > > defined in RFC 7950. I think you often mean a schema tree (as > > > defined in RFC 7950) when you use 'schema'. Well, even this is not > > > true since a 'schema tree' according to RFC 7950 is scoped to a > > > module. RFC 8342 defines a 'datastore schema' but then I am not sure > > > this corresponds to 'schema' as used in this draft. In fact, the > > > mounted schema may be considered part of the 'datastore schema'. I > > > think we are handwaving with our terminology here but then perhaps I > > > am the only one who cares... > > > > I have imported "schema tree" from 7950, and changed teh definition of > > top-level schema to: > > > > - top-level schema: a set of modules in which the schema > > trees of each module (except augments) start at the root node. > > Still sounds complicated and not quite clear. Do you mean this: > > - top-level schema: a set of schema trees of a set of modules starting > at the root node > > > > What we actually have are schema tree (of a module per RFC 7950) and > > > a collection of schema trees sharing a common root (this is likely > > > what is meant with "schema" in this document). And then schema mount > > > simply provides a mechanism to have additional (statically defined) > > > roots in a schema. > > So what are you planning to do about the term 'schema' used throughout > the module? We kind of define what a top-level schema is but leave > schema undefined and perhaps we would also benefit from having a term > like mounted schema. I am thinking along these lines: > > schema = collection of schema trees with a common root > top-level schema = schema rooted at the root node > mounted schema = schema rooted at a mount point > parent schema (of a mounted schema) = schema containing the mount point These are good definitions, I have added them. Thank you! > > > * Multiple Levels of Schema Mount > > > > > > What is a 'subschema'? What is a 'schema level'? Is a subschema the > > > same as a schema, i.e. a collection of schema trees with a common > > > root? If we need terms such as 'subschema' or 'schema level', then > > > we should define them. But perhaps just some tweaking the text to > > > avoid new terms can solve the issue. > > > > I have changed "subschema" to "schema", and removed "schema level": > > > > NEW: > > > > YANG modules in a mounted schema MAY again contain mount points > > under which other schemas can be mounted. Consequently, it is > > possible to construct data models with an arbitrary number of > > mounted schemas. A schema for a mount point contained in a mounted > > module can be specified by implementing "ietf-yang-library" and > > "ietf-yang-schema-mount" modules in the mounted schema, and > > specifying the schemas exactly as it is done in the top-level > > schema. > > OK > > > > Why are parent-references only useful for the 'shared-schema' case? > > > An 'inline' mount can't refer to stuff outside the mount jail? > > > > Correct. We have debated if this makes sense for inline or not. As > > it is, the model is designed so that this can be added in the future, > > if it turns out that this is needed. > > OK > > > > Looking at the YANG definition of 'parent-reference', I am left > > > somewhat clueless in which situations these xpath expressions are > > > evaluations and when the nodesets are merged with other xpath > > > expression evaluation results. > > > > The YANG module says: > > > > When XPath expressions in the mounted schema > > are evaluated, the 'parent-reference' leaf-list is taken > > into account. > > > > and > > > > For the purposes of evaluating XPath > > expressions whose context nodes are defined in the > > mounted schema, the union of all these nodesets > > together with ancestor nodes are added to the > > accessible data tree. > > OK. I probably did not read carefully enough. My understanding is now > that the set of parent-reference xpath expressions yields a union of > nodesets that are becoming part of the context for the evaluation of > any xpath expression appearing in a mounted schema. And these parent > references are specific to a mount point instance. May make sense. > > > > It seems that these parent references > > > are the only actual difference between 'inline' and 'shared-schema' > > > mounts. > > > > > > * Data Model > > > > > > I have not really understood what the difference between 'inline' > > > and 'shared-schema' is. I understand that the later can have > > > 'parent-references' but it is unclear why the other can't and if > > > there is not strong architectural reason why there have to be two > > > choices. It also seems that the 'namespace' list is only meaningful > > > if there are parent references, no? So why is this then global, i.e. > > > also provided for 'inline' mounts? > > > > As you note, the 'namespace' list is global, so there is just one list > > that covers all mount-points. It's not really correct to state that > > the 'namespace' list is "provided for 'inline' mounts". > > OK. It seems that for a client capable to support a 'shared schema', > the 'inline' schema really is just a special case without parent > references. (I wonder whether anything should be said to YANG library > version numbers, whether they are always scoped by the mount point > or have meaning across mount points; if two YANG library instances > in mounted schemas have the same version number, does this imply > that these YANG library instances are identical or is this just a > version number clash? But then this probably goes across the spirit > of not talking about YANG library too much.) When you say "version number" do you mean the YANG library checksum? I don't think the YL document guarantees that there can never be clashes. > > > I guess I do not really > > > understand the distinction. If there are no parent-references, what > > > is the difference between 'shared-schema' and 'inline'? > > > > The difference is that shared-schema can have parent-references, and > > that all instances of such a mount point have exactly the same > > schema. > > See comment above about YANG library version numbers. I am trying to > understand which assumption a client can make to be efficient in both > cases (and whether it is possible to be efficient while essentially > handling inline and shared-schema using a common approach). > > > > * Security Considerations > > > > > > I agree with others that something needs to be said how NACM applies > > > to mounted schemas. > > > > I have added the following (short) section: > > > > 7. Interaction with the Network Configuration Access Control Model > > (NACM) > > > > If NACM [RFC8341] is implemented on a server, it can be used to > > control access to nodes defined by the mounted schema in the same way > > as for nodes defined by the top-level schema. > > > > For example, suppose the module "ietf-interfaces" is mounted in the > > "root" container in the "logical-network-element" list defined in > > [I-D.ietf-rtgwg-lne-model]. Then the following NACM path can be used > > to control access to the "interfaces" container (where the character > > '\' is used where a line break has been inserted for formatting > > reasons): > > > > > "urn:ietf:params:xml:ns:yang:ietf-logical-network-element" > > xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"> > > /lne:logical-network-elements\ > > /lne:logical-network-element/lne:root/if:interfaces > > > > This helps. Can I also mount NACM into a mount point? If yes, what if > both are present? Yes you can mount NACM. To keep things simple, I think the inner NACM should not affect the access control done in the parent. Consider the use cases for this. In a NI situation, it doesn't make much sense to mount NACM. In an LNE (or in a "peer mount") situation, it may make sense to mount NACM if the LNE (or device) supports it. In this case, if I try to access any mounted data in the parent, access is controlled by the parent. If I have access, the parent may send a request over to the mounted device to read/write the data. That device will use its local copy of NACM to control access, or some other mechanism. /martin From nobody Fri Apr 6 06:33:08 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC1C1270A3 for ; Fri, 6 Apr 2018 06:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLObmdioW78m for ; Fri, 6 Apr 2018 06:33:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 79E1B12702E for ; Fri, 6 Apr 2018 06:33:01 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id C67F21AE034E; Fri, 6 Apr 2018 15:33:00 +0200 (CEST) Date: Fri, 06 Apr 2018 15:33:00 +0200 (CEST) Message-Id: <20180406.153300.2264288445901236761.mbj@tail-f.com> To: rohitrranade@outlook.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180405.144349.1531327560930954458.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] Comments on schema mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 13:33:07 -0000 SGksDQoNClJvaGl0IFJhbmFkZSA8cm9oaXRycmFuYWRlQG91dGxvb2suY29tPiB3cm90ZToNCj4g SGkgTWFydGluLA0KPiANCj4gDQo+IA0KPiBGb3IgYmVsb3cgcG9pbnQ6DQo+IA0KPiDigJwNCj4g DQo+ID4gNC4gTkVUQ09ORiBoYXMgc29tZSAicnBjIiB3aGljaCB3b3JrIG9uIG11bHRpcGxlIG1v dW50LWluc3RhbmNlcy4NCj4gPg0KPiA+ICAgID09PiBGb3IgZXhhbXBsZSA8ZWRpdC1jb25maWc+ ICwgPGdldC1jb25maWc+IG9yIDxsb2NrPi4gV2hldGhlciB3ZSBuZWVkIHRvIGdpdmUgYQ0KPiA+ DQo+ID4gICAgZ3VpZGVsaW5lIGZvciBob3cgdG8gaGFuZGxlIHN1Y2ggInJwYyIsIHNvIHRoYXQg b3RoZXIgcHJvdG9jb2xzIHdoaWNoIGltcGxlbWVudCBzY2hlbWEgbW91bnQgICBhbHNvIGFkYXB0 IGFjY29yZGluZ2x5ID8NCj4gPg0KPiA+ICAgIEVnOiBTb21ldGhpbmcgbGlrZSwgZm9yIHRyYW5z YWN0aW9uIG1hbmFnZW1lbnQsIGJldHRlciB0byBvcGVyYXRlIG9uIG9uZSBtb3VudC1pbnN0YW5j ZS4NCj4gDQo+IFRoaXMgd291bGQgbm90IGJlIGNvcnJlY3QuICBJIHRoaW5rIHlvdSBhcmUgYXNz dW1pbmcgb25lIHVzZSBjYXNlOw0KPiB3aGVyZSBzY2hlbWEgbW91bnQgaXMgdXNlZCBpbiBhIChw cmltaXRpdmUpIG9yY2hlc3RyYXRvciB0aGF0IGFjdHVhbGx5DQo+IHRhbGtzIHRvIG11bHRpcGxl IGRldmljZXMgKHcvbyB0cmFuc2FjdGlvbiBjb250cm9sKS4NCj4gDQo+IE5vdGUgdGhhdCB0aGlz IGRvY3VtZW50IGp1c3QgZGVmaW5lcyBob3cgdGhlICpzY2hlbWEqIGlzIGJ1aWx0OyBub3QNCj4g aG93IGluc3RhbmNlIGRhdGEgaXMgc3RvcmVkIG9yIGFjY2Vzc2VkLg0KPiANCj4g4oCdDQo+IA0K PiBBcyBwZXIgZXhhbXBsZSBzaG93biBpbiBzZWN0aW9uIDQ6DQo+IA0KPiAgICAgICstLXJ3IG5l dHdvcmstaW5zdGFuY2VzDQo+IA0KPiAgICAgICAgICstLXJ3IG5ldHdvcmstaW5zdGFuY2UqIFtu YW1lXQ0KPiANCj4gICAgICAgICAgICArLS1ydyBuYW1lDQo+IA0KPiAgICAgICAgICAgICstLXJ3 IHJvb3QNCj4gDQo+ICAgICAgICAgICAgICAgKy0tcncgcm91dGluZw0KPiANCj4gDQo+IA0KPiBD b25zaWRlcmluZyDigJxyb2904oCdIGFzIG1vdW50IHBvaW50IDoNCj4gDQo+IA0KPiANCj4gV2hl biBxdWVyeWluZyBkYXRhIGZyb20gc2NoZW1hIG1vdW50ZWQgbW9kZWxzOg0KPiANCj4gDQo+IA0K PiA8Z2V0LWNvbmZpZz4NCj4gDQo+ICAgPGZpbHRlcj4NCj4gDQo+ICAgICA8bmV0d29yay1pbnN0 YW5jZXM+DQo+IA0KPiAgICAgICA8bmV0d29yay1pbnN0YW5jZT4NCj4gDQo+ICAgICAgICA8bmFt ZT4xPC9uYW1lPg0KPiANCj4gICAgICAgICA8cm9vdD4NCj4gDQo+ICAgICAgICAgICA8cm91dGlu Zy8+DQo+IA0KPiANCj4gDQo+IEFuZA0KPiANCj4gDQo+IA0KPiA8YWN0aW9uPg0KPiANCj4gICAg IDxuZXR3b3JrLWluc3RhbmNlcz4NCj4gDQo+ICAgICAgIDxuZXR3b3JrLWluc3RhbmNlPg0KPiAN Cj4gICAgICAgIDxuYW1lPjE8L25hbWU+DQo+IA0KPiAgICAgICAgIDxyb290Pg0KPiANCj4gICAg ICAgICAgIDxnZXQtY29uZmlnPiAgLS0gaGF2aW5nIGlldGYtbmV0Y29uZiBucw0KPiANCj4gICAg ICAgICAgICAgPGZpbHRlcj4NCj4gDQo+ICAgICAgICAgICAgICA8cm91dGluZy8+DQo+IA0KPiAN Cj4gDQo+IFdpbGwgdGhlc2UgdHdvIGdpdmUgdGhlIHNhbWUgcmVzdWx0ID8NCg0KWWVzLCBwcm92 aWRlZCB0aGF0IHRoZSBpZXRmLW5ldGNvbmYgbW9kdWxlIGlzIG1vdW50ZWQuDQoNCg0KL21hcnRp bg0KDQoNCg0KPiANCj4gDQo+IA0KPiBXaXRoIFJlZ2FyZHMsDQo+IA0KPiBSb2hpdCBSDQo+IA0K PiANCj4gDQo+IFNlbnQgZnJvbSBNYWlsPGh0dHBzOi8vZ28ubWljcm9zb2Z0LmNvbS9md2xpbmsv P0xpbmtJZD01NTA5ODY+IGZvciBXaW5kb3dzIDEwDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWls LWYuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgNSwgMjAxOCA2OjEzOjQ5IFBNDQo+IFRv OiByb2hpdHJyYW5hZGVAb3V0bG9vay5jb20NCj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW25ldG1vZF0gQ29tbWVudHMgb24gc2NoZW1hIG1vdW50IGRyYWZ0DQo+IA0KPiBI aSwNCj4gDQo+IA0KPiBSb2hpdCBSYW5hZGUgPHJvaGl0cnJhbmFkZUBvdXRsb29rLmNvbT4gd3Jv dGU6DQo+ID4gSGkgTWFydGluLA0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoYW5rIHlvdSBmb3IgeW91 ciByZXNwb25zZXMuDQo+ID4NCj4gPiBJIGhhdmUgZ29uZSB0aHJvdWdoIHRoZSBMTkUgZHJhZnQg YW5kIFlBTkcgMS4xIGFuZCBmb3VuZCBzb21lIG1vcmUgc3VnZ2VzdGlvbnMuDQo+ID4NCj4gPg0K PiA+DQo+ID4gMS4gU2VjdGlvbiA1DQo+ID4NCj4gPiAgICAiSWYgYSBtb3VudGVkIFlBTkcgbW9k dWxlIGRlZmluZXMgYW4gUlBDIG9wZXJhdGlvbiwgY2xpZW50cyBjYW4gaW52b2tlDQo+ID4NCj4g PiAgICB0aGlzIG9wZXJhdGlvbiBhcyBpZiBpdCB3ZXJlIGRlZmluZWQgYXMgYW4gYWN0aW9uIGZv ciB0aGUNCj4gPg0KPiA+ICAgIGNvcnJlc3BvbmRpbmcgbW91bnQgcG9pbnQiDQo+ID4NCj4gPiAg ICA9PT4gQmVsb3cgaXMgdGhlIGV4YW1wbGUgZnJvbSBZYW5nIDEuMSBTZWN0aW9uIDcuMTUNCj4g Pg0KPiA+DQo+ID4NCj4gPiAgICAgPHJwYyBtZXNzYWdlLWlkPSIxMDEiDQo+ID4NCj4gPiAgICAg ICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQo+ ID4NCj4gPiAgICAgICAgPGFjdGlvbiB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5n OjEiPg0KPiA+DQo+ID4gICAgICAgICAgPHNlcnZlciB4bWxucz0idXJuOmV4YW1wbGU6c2VydmVy LWZhcm0iPg0KPiA+DQo+ID4gICAgICAgICAgICA8bmFtZT5hcGFjaGUtMTwvbmFtZT4NCj4gPg0K PiA+ICAgICAgICAgICAgPHJlc2V0Pg0KPiA+DQo+ID4gICAgICAgICAgICAgIDxyZXNldC1hdD4y MDE0LTA3LTI5VDEzOjQyOjAwWjwvcmVzZXQtYXQ+DQo+ID4NCj4gPiAgICAgICAgICAgIDwvcmVz ZXQ+DQo+ID4NCj4gPiAgICAgICAgICA8L3NlcnZlcj4NCj4gPg0KPiA+ICAgICAgICA8L2FjdGlv bj4NCj4gPg0KPiA+ICAgICAgPC9ycGM+DQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgICA8cnBjLXJl cGx5IG1lc3NhZ2UtaWQ9IjEwMSINCj4gPg0KPiA+ICAgICAgICAgICAgICAgICB4bWxucz0idXJu OmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCj4gPg0KPiA+ICAgICAgICA8 cmVzZXQtZmluaXNoZWQtYXQgeG1sbnM9InVybjpleGFtcGxlOnNlcnZlci1mYXJtIj4NCj4gPg0K PiA+ICAgICAgICAgIDIwMTQtMDctMjlUMTM6NDI6MTJaDQo+ID4NCj4gPiAgICAgICAgPC9yZXNl dC1maW5pc2hlZC1hdD4NCj4gPg0KPiA+ICAgICAgPC9ycGMtcmVwbHk+DQo+ID4NCj4gPiAgICAg ICAgICAgICAgID09PiBIZXJlIHJwYy1yZXBseSBvbmx5IGhhcyB0aGUgbmFtZXNwYWNlIGFuZCBh Y3Rpb24gbmFtZSBkZWZpbmVkIGluIHRoZSBtb3VudC1pbnN0YW5jZSdzIG1vZHVsZS4NCj4gPg0K PiA+ICAgICAgICAgICAgICAgVGhlIGNsaWVudCBuZWVkcyB0byBzdG9yZSBpbmZvcm1hdGlvbiBv ZiB0aGUgbW91bnQtaW5zdGFuY2UgZm9yIHdoaWNoIHRoZSBSUEMgcmVxdWVzdCB3YXMgc2VudCBh bmQgb25seSB0aGVuIGl0IGNhbiB2YWxpZGF0ZSB0aGUgcnBjLXJlcGx5IGFnYWluc3QgdGhlIGRh dGEtbW9kZWwuDQo+ID4NCj4gPiAgICAgICAgICAgICAgIFRvIGF2b2lkIHRoaXMgd29yayBvZiBj bGllbnQsIHdoZXRoZXIgd2UgY2FuIHRoaW5rIG9mIGFkZGluZyBtZXRhLWRhdGEgdG8gcnBjLXJl cGx5IHRvIHByb3ZpZGUgdGhpcyBpbmZvcm1hdGlvbiB0byBjbGllbnQuDQo+IA0KPiBJZiB0aGUg Y2xpZW50IGludm9rZXMgYW4gYWN0aW9uLCBpdCBpcyBleHBlY3RlZCB0aGF0IGl0IGtub3dzIGhv dyB0bw0KPiBpbnRlcnByZXQgdGhlIHJlc3VsdC4gIFRoaXMgZG9lcyBub3QgY2hhbmdlIHdpdGgg dGhlIGludHJvZHVjdGlvbiBvZg0KPiBzY2hlbWEgbW91bnQuICBUaGUgY2xpZW50IG9idmlvdXNs eSBrbm93cyB0aGUgbmFtZSBhbmQgaW5wdXQNCj4gcGFyYW1ldGVycyBvZiB0aGUgYWN0aW9uLCBz byBpdCBzZWVtcyByZXNvbmFibGUgdG8gZXhwZWN0IHRoYXQgaXQNCj4ga25vd3MgdGhlIG91dHB1 dCBwYXJhbWV0ZXJzIGFzIHdlbGwsIHcvbyBhbnkgYWRkaXRpb25hbCBtZXRhIGRhdGEuDQo+IA0K PiA+IDIuIFNlY3Rpb24gNQ0KPiA+DQo+ID4gICAgSSB3b3VsZCBwcmVmZXIgdGhlIGFwcHJvYWNo IHRha2VuIGJ5IFlhbmcgMS4xIHdoZXJlIHN0YXRlbWVudHMgZm9sbG93ZWQgYnkgWE1MIGV4YW1w bGVzICAgdG8gaGVscCBpbiBjbGFyaXR5Lg0KPiA+DQo+ID4gICAgRXNwZWNpYWxseSBmb3IgdGhl IFJQQyBhbmQgbm90aWZpY2F0aW9uIHNlY3Rpb24sIGl0IGlzIGJldHRlciB0byBhZGQgY2xlYXIg ZXhhbXBsZXMNCj4gPg0KPiA+ICAgIGluIGEgIlVzYWdlIEV4YW1wbGUiIHN1Yi1zZWN0aW9uIGZv ciB0aGlzIHNlY3Rpb24uDQo+IA0KPiBUaGUgZXhhbXBsZXMgYXJlIGdpdmVuIGluIHRoZSBhcHBl bmRpeCwgYW5kIHRoZXJlIGlzIGEgZm9yd2FyZA0KPiByZWZlcmVuY2UgdG8gdGhlIGFwcGVuZGl4 IGZyb20gc2VjdGlvbiA1Lg0KPiANCj4gDQo+ID4gMy4gWWFuZyBSUEMgYW5kIEFDVElPTiBzdGF0 ZW1lbnRzOg0KPiA+DQo+ID4gICBJZiB3ZSBuZWVkIHRvIHZpZXcgdGhlIFJQQyBkZWZpbmVkIGlu IGEgbW9kdWxlIGFzIGFuIEFDVElPTiBhZnRlciBzY2hlbWEgbW91bnQsIHRoZW4NCj4gPg0KPiA+ ICAgV2hlbmV2ZXIgdGhlcmUgaXMgdXBkYXRlIHRvIFJQQyBpbiBzYXkgWUFORyAxLjIsIHRoZW4g dGhlIGNvcnJlc3BvbmRpbmcgY2hhbmdlcyBtdXN0IGJlIHByZXNlbnQgaW4gQUNUSU9OIGFsc28s IGludHJvZHVjaW5nIGEgY291cGxpbmcgYmV0d2VlbiBSUEMgYW5kIEFDVElPTiBzdGF0ZW1lbnRz Lg0KPiANCj4gVGhpcyBtb2R1bGUgaXMgd3JpdHRlbiB1c2luZyBZQU5HIDEuMS4gIFVubGVzcyB0 aGlzIG1vZHVsZSBpcyB1cGRhdGVkLA0KPiBpdCBkb2Vzbid0IG1hdHRlciB3aGF0IFlBTkcgMi4w IG9yIHdoYXRldmVyIGRvZXMuDQo+IA0KPiA+IDQuIE5FVENPTkYgaGFzIHNvbWUgInJwYyIgd2hp Y2ggd29yayBvbiBtdWx0aXBsZSBtb3VudC1pbnN0YW5jZXMuDQo+ID4NCj4gPiAgICA9PT4gRm9y IGV4YW1wbGUgPGVkaXQtY29uZmlnPiAsIDxnZXQtY29uZmlnPiBvciA8bG9jaz4uIFdoZXRoZXIg d2UgbmVlZCB0byBnaXZlIGENCj4gPg0KPiA+ICAgIGd1aWRlbGluZSBmb3IgaG93IHRvIGhhbmRs ZSBzdWNoICJycGMiLCBzbyB0aGF0IG90aGVyIHByb3RvY29scyB3aGljaCBpbXBsZW1lbnQgc2No ZW1hIG1vdW50ICAgYWxzbyBhZGFwdCBhY2NvcmRpbmdseSA/DQo+ID4NCj4gPiAgICBFZzogU29t ZXRoaW5nIGxpa2UsIGZvciB0cmFuc2FjdGlvbiBtYW5hZ2VtZW50LCBiZXR0ZXIgdG8gb3BlcmF0 ZSBvbiBvbmUgbW91bnQtaW5zdGFuY2UuDQo+IA0KPiBUaGlzIHdvdWxkIG5vdCBiZSBjb3JyZWN0 LiAgSSB0aGluayB5b3UgYXJlIGFzc3VtaW5nIG9uZSB1c2UgY2FzZTsNCj4gd2hlcmUgc2NoZW1h IG1vdW50IGlzIHVzZWQgaW4gYSAocHJpbWl0aXZlKSBvcmNoZXN0cmF0b3IgdGhhdCBhY3R1YWxs eQ0KPiB0YWxrcyB0byBtdWx0aXBsZSBkZXZpY2VzICh3L28gdHJhbnNhY3Rpb24gY29udHJvbCku DQo+IA0KPiBOb3RlIHRoYXQgdGhpcyBkb2N1bWVudCBqdXN0IGRlZmluZXMgaG93IHRoZSAqc2No ZW1hKiBpcyBidWlsdDsgbm90DQo+IGhvdyBpbnN0YW5jZSBkYXRhIGlzIHN0b3JlZCBvciBhY2Nl c3NlZC4NCj4gDQo+IA0KPiANCj4gL21hcnRpbg0KPiANCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+IFdpdGggUmVnYXJkcywNCj4gPg0KPiA+IFJvaGl0IFINCj4gPg0KPiA+ DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEZyb206IE1h cnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPg0KPiA+IFNlbnQ6IFRodXJzZGF5LCBNYXJj aCAyOSwgMjAxOCAxMjo1OTo1MyBQTQ0KPiA+IFRvOiByb2hpdHJyYW5hZGVAb3V0bG9vay5jb20N Cj4gPiBDYzogbmV0bW9kQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtuZXRtb2RdIENvbW1l bnRzIG9uIHNjaGVtYSBtb3VudCBkcmFmdA0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPiBSb2hpdCBS YW5hZGUgPHJvaGl0cnJhbmFkZUBvdXRsb29rLmNvbT4gd3JvdGU6DQo+ID4gPiBIaSBNYXJ0aW4s DQo+ID4gPg0KPiA+ID4gVy5yLnQgPGdldC1zY2hlbWE+IG9uIHRoZSBtYWluIGRldmljZSwgaXQg d2lsbCBtZWFuIHRoYXQgZm9yDQo+ID4gPiBzdWNjZXNzZnVsIDxnZXQtc2NoZW1hPiBmb3IgYWxs IHRoZSBzY2hlbWEgb2YgbW91bnRlZCBkZXZpY2VzLCB0aGUNCj4gPiA+IG1haW4gZGV2aWNlIG11 c3QgYmUgdXBncmFkZWQgdG8gaGlnaGVyIHZlcnNpb24gZmlyc3QgYW5kIG11c3QgY29udGFpbg0K PiA+ID4gQUxMIHRoZSBzY2hlbWEgb2YgYWxsIHRoZSBkZXZpY2VzIGJlaGluZCB0aGUgbWFpbiBk ZXZpY2UuDQo+ID4NCj4gPiBUaGlzIGlzIG5vdCB0aGUgaW50ZW50aW9uLCBhbmQgYXMgeW91IG5v dGUsIGluIG1hbnkgY2FzZXMgdGhpcyBpcyBqdXN0DQo+ID4gbm90IHBvc3NpYmxlLg0KPiA+DQo+ ID4gVGhlIGNsaWVudCBjYW4gbG9vayBhdCB0aGUgImxvY2F0aW9uIiBsZWFmIGluIHRoZSBtb3Vu dGVkIFlBTkcgbGlicmFyeQ0KPiA+IChpbiBZTGJpczsgaW4gb2xkIFlMIGl0IHdhcyBjYWxsZWQg InNjaGVtYSIpIGFuZCBnZXQgdGhlIG1vZHVsZSBmcm9tDQo+ID4gdGhlcmUuDQo+ID4NCj4gPiBJ ZiB0aGUgbW91bnRlZCBzY2hlbWEgYWxzbyBtb3VudHMgImlldGYtbmV0Y29uZi1tb25pdG9yaW5n IiwgdGhlDQo+ID4gY2xpZW50IGNhbiBpbnZva2UgdGhlIG1vdW50ZWQgPGdldC1zY2hlbWE+IGFz IGFuIGFjdGlvbiwgYW5kIHJldHJpZXZlDQo+ID4gdGhlIHNwZWNpZmljIHZlcnNpb24gb2YgdGhl IG1vZHVsZSB0aGF0IGlzIG1vdW50ZWQgdGhlcmUuDQo+ID4NCj4gPiA+IFRoaXMgcG9pbnQgbWF5 IHByb3ZlIHRvIGJlIHRyaWNreSBhcyB0aGUgd2hvbGUgdG9wb2xvZ3kgdXBncmFkZSBoYXMgdG8N Cj4gPiA+IGJlIGNvbnNpZGVyZWQgYWx3YXlzLiBJIGZlZWwgd2UgY2FuIGFkZCBzb21lIHRleHQg cmVnYXJkaW5nIHRoaXMuDQo+ID4gPg0KPiA+ID4gQWxzbyBob3cgdG8g4oCcbW91bnTigJ0gYW4g aW5zdGFuY2Ugb2YgYSBtb3VudC1wb2ludCA/IEJlY2F1c2Ugb25jZSB0aGlzDQo+ID4gPiBkcmFm dCBpcyBvdXQsIGVhY2ggaW1wbGVtZW50ZXIgbWF5IGRlZmluZSBwcml2YXRlIFJQQ3MgZm9yIG1v dW50IGFuZA0KPiA+ID4gdW4tbW91bnQgaWYgdGhpcyBtb2R1bGUgZG9lcyBub3QgZGVmaW5lIGl0 LiBXaGV0aGVyIGFueSBwbGFuIGFib3V0IGl0DQo+ID4gPiA/DQo+ID4NCj4gPiBOb3RlIHRoYXQg c2NoZW1hIG1vdW50IGlzIG5vdCBhYm91dCBtb3VudGluZyBkZXZpY2VzOyB0aGF0IHdvdWxkIGJl IGENCj4gPiBmdXR1cmUgc3BlY2lhbGl6YXRpb24gb2YgdGhpcyBtZWNoYW5pc20uDQo+ID4NCj4g PiBJbiB0aGUgTE5FIGFuZCBOSSBkcmFmdHMsIGVudGl0aWVzIGFyZSAibW91bnRlZCIgYnkgY3Jl YXRpbmcgZW50cmllcw0KPiA+IGluIHRoZSBjb3JyZXNwb25kaW5nIGxpc3RzLiAgVGhlcmUgaXMg bm8gbmVlZCBmb3IgYSAibW91bnQiIHJwYyBpbg0KPiA+IHRoZXNlIGNhc2VzLg0KPiA+DQo+ID4N Cj4gPiAvbWFydGluDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4g PiA+DQo+ID4gPiBXaXRoIFJlZ2FyZHMsDQo+ID4gPiBSb2hpdCBSDQo+ID4gPg0KPiA+ID4gU2Vu dCBmcm9tIE1haWw8aHR0cHM6Ly9nby5taWNyb3NvZnQuY29tL2Z3bGluay8/TGlua0lkPTU1MDk4 Nj4gZm9yDQo+ID4gPiBXaW5kb3dzIDEwDQo+ID4gPg0KPiA+ID4gRnJvbTogTWFydGluIEJqb3Jr bHVuZDxtYWlsdG86bWJqQHRhaWwtZi5jb20+DQo+ID4gPiBTZW50OiAyNiDgpK7gpL7gpLDgpY3g pJogMjAxOCAxMzo0MQ0KPiA+ID4gVG86IHJvaGl0cnJhbmFkZUBvdXRsb29rLmNvbTxtYWlsdG86 cm9oaXRycmFuYWRlQG91dGxvb2suY29tPg0KPiA+ID4gQ2M6IG5ldG1vZEBpZXRmLm9yZzxtYWls dG86bmV0bW9kQGlldGYub3JnPg0KPiA+ID4gU3ViamVjdDogUmU6IFtuZXRtb2RdIENvbW1lbnRz IG9uIHNjaGVtYSBtb3VudCBkcmFmdA0KPiA+ID4NCj4gPiA+IEhpLA0KPiA+ID4NCj4gPiA+IFRo YW5rIHlvdSBmb3IgdGhlc2UgY29tbWVudHMsIHJlcGxpZXMgaW5saW5lLg0KPiA+ID4NCj4gPiA+ IFJvaGl0IFJhbmFkZSA8cm9oaXRycmFuYWRlQG91dGxvb2suY29tPiB3cm90ZToNCj4gPiA+ID4g SGkgQWxsLA0KPiA+ID4gPg0KPiA+ID4gPiBQbGVhc2UgZmluZCBzb21lIGNvbW1lbnRzIGZvciB0 aGUgc2NoZW1hIG1vdW50IGRyYWZ0LiBJZiBJIGZpbmQgYW55DQo+ID4gPiA+IG90aGVyIHdpbGwg c2VuZCBpbiBhbm90aGVyIG1haWwuDQo+ID4gPiA+DQo+ID4gPiA+IEVkaXRvcmlhbDoNCj4gPiA+ ID4gPT09PT09PT09PT09DQo+ID4gPiA+IDEuIFNlY3Rpb24gMy4xDQo+ID4gPiA+ICAgICJUaGUg Im1vdW50LXBvaW50IiBzdGF0ZW1lbnQgTVVTVCBOT1QgYmUgdXNlZCBpbiBhIFlBTkcgdmVyc2lv biAxDQo+ID4gPiA+ICAgIG1vZHVsZS4iDQo+ID4gPiA+ICAgID09PiBJdCBpcyB1bmNsZWFyIHdo eSBzdWNoIGEgcmVzdHJpY3Rpb24gaXMgcGxhY2VkLg0KPiA+ID4NCj4gPiA+IFRoZSByZWFzb24g aXMgdGhhdCBZQU5HIDEgZG9lc24ndCBzdXBwb3J0IGlubGluZSBhY3Rpb25zIGFuZA0KPiA+ID4g bm90aWZpY2F0aW9uLCB3aGljaCBtZWFucyB0aGF0IHRvcC1sZXZlbCBycGNzIGFuZCBub3RpZnMg aW4gdGhlDQo+ID4gPiBtb3VudGVkIG1vZHVsZSBjYW5ub3QgYmUgaW52b2tlZCB1c2luZyB0aGUg bWVjaGFuaXNtIGRlc2NyaWJlZCBpbg0KPiA+ID4gc2VjdGlvbiA1LiAgSSB3aWxsIHRyeSB0byBj bGFyaWZ5IHRoaXMuDQo+ID4gPg0KPiA+ID4gPiAyLiBTZWN0aW9uIDMuMg0KPiA+ID4gPiAgICAi c3RhdGUgZGF0YSBpbiB0aGUgInlhbmdtbnQ6c2NoZW1hLW1vdW50cyIiDQo+ID4gPiA+ICAgID09 PiBIZXJlIHRoZSB5YW5nIHRyZWUgZGlhZ3JhbSBpcyBub3QgeWV0IGludHJvZHVjZWQuIEkgZmVl bCBiZXR0ZXIgdG8NCj4gPiA+ID4gICAgaW50cm9kdWNlDQo+ID4gPiA+ICAgIHRoaXMgZGlhZ3Jh bSBhcyBpdCBtYWtlcyBpdCBlYXNpZXIgdG8gdW5kZXJzdGFuZCB0aGUgZGF0YS1ub2Rlcw0KPiA+ ID4NCj4gPiA+IE9rLiAgSSBtb3ZlZCBzZWN0aW9uIDggdG8gYSBuZXcgc2VjdGlvbiAzLjIuDQo+ ID4gPg0KPiA+ID4gPiAzLiBTZWN0aW9uIDMuMg0KPiA+ID4gPiAgICAiRGF0YSBpbiB0aGlzIGNv bnRhaW5lciBpcyBpbnRlbmRlZCB0byBiZSBhcyBzdGFibGUgYXMgZGF0YSBpbiB0aGUNCj4gPiA+ ID4gICAgdG9wLWxldmVsIFlBTkcgbGlicmFyeSINCj4gPiA+ID4gICAgPT0+IFdoYXQgaXMgdGhl IG1lYW5pbmcgb2YgImFzIHN0YWJsZSIgYXMgPyBBcyBhIGRldmVsb3BlciAsIEkgYW0NCj4gPiA+ ID4gICAgdW5jbGVhciB3aGF0IG5lZWRzDQo+ID4gPiA+ICAgIHRvIGJlIGRvbmUgaGVyZS4gUGxl YXNlIGNsYXJpZnkuDQo+ID4gPg0KPiA+ID4gS2VudCBhbHNvIGhhZCBhIGNvbW1lbnQgYXJvdW5k IHRoaXMsIGFuZCB0aGUgdGV4dCBhYm91dCBzdGFibGUgaXMgbm93DQo+ID4gPiByZW1vdmVkLg0K PiA+ID4NCj4gPiA+ID4gNC4gU2VjdGlvbiAzLjINCj4gPiA+ID4gICAgImkuZS4sIGluc3RhbmNl cyBvZiB0aGF0IG1vdW50IHBvaW50IE1VU1QgTk9UIGNvbnRhaW4gYW55IGRhdGEgYWJvdmUNCj4g PiA+ID4gICAgdGhvc2UgdGhhdCBhcmUgZGVmaW5lZCBpbiB0aGUgcGFyZW50IHNjaGVtYS4iDQo+ ID4gPiA+ICAgID09PiBIZXJlICJhbnkgZGF0YSBhYm92ZSIsIG1lYW5zICJhYm92ZSIgaW4gdGhl IGhpZWFyYXJjaHkgPw0KPiA+ID4NCj4gPiA+IE5vLCB0aGlzIHdhcyBqdXN0IHdyb25nOyBpdCBz aG91bGQgYmUgImV4Y2VwdCIuDQo+ID4gPg0KPiA+ID4gPiAgICBOb3QNCj4gPiA+ID4gICAgY2xl YXIsIHRoaXMgaXMgc2ltaWxhcg0KPiA+ID4gPiAgICB0byBoYXZpbmcgYSBVU0Igc2xvdCwgYnV0 IG5vIGRldmljZSBtb3VudGVkIG9uIGl0IGFzIHlldCBpbiBVTklYDQo+ID4gPiA+ICAgIHRlcm1z LiBSaWdodCA/DQo+ID4gPiA+ICAgIFRoZSBxdWVyeSBvdXRwdXQgb24gcGFyZW50LXNjaGVtYSBz aG91bGQgZ2l2ZSBlbXB0eSBkYXRhLg0KPiA+ID4gPg0KPiA+ID4gPiA1LiBTZWN0aW9uIDMuMg0K PiA+ID4gPiAgICAiSWYgbXVsdGlwbGUgbW91bnQgcG9pbnRzIHdpdGggdGhlIHNhbWUgbmFtZSBh cmUgZGVmaW5lZCBpbiB0aGUgc2FtZQ0KPiA+ID4gPiAgICBtb2R1bGUgLSBlaXRoZXIgZGlyZWN0 bHkgb3IgYmVjYXVzZSB0aGUgbW91bnQgcG9pbnQgaXMgZGVmaW5lZCBpbiBhDQo+ID4gPiA+ICAg IGdyb3VwaW5nIGFuZCB0aGUgZ3JvdXBpbmcgaXMgdXNlZCBtdWx0aXBsZSB0aW1lcyAtIHRoZW4g dGhlDQo+ID4gPiA+ICAgIGNvcnJlc3BvbmRpbmcgIm1vdW50LXBvaW50IiBlbnRyeSBhcHBsaWVz IGVxdWFsbHkgdG8gYWxsIHN1Y2ggbW91bnQNCj4gPiA+ID4gICAgcG9pbnRzLiINCj4gPiA+ID4g ICA9PT4gQXMgcGVyIHRyZWUgZGlhZ3JhbSwgIm1vdW50LXBvaW50IiBoYXMgdHdvIGtleXMuIFNv IGVhY2ggbW9kdWxlDQo+ID4gPiA+ICAgY2FuIGhhdmUgbXVsdGlwbGUNCj4gPiA+ID4gICBtb3Vu dCBwb2ludHMuIFNvIGhvdyB0byBhcHBseSBpdCAiZXF1YWxseSIgPyBOb3QgY2xlYXIuDQo+ID4g Pg0KPiA+ID4gTm90ZSB0aGF0IHRoZSBzZW50ZW5jZSBzdGFydHMgd2l0aCAiSWYgbXVsdGlwbGUg bW91bnQgcG9pbnRzIHdpdGggdGhlDQo+ID4gPiBzYW1lIG5hbWUgYXJlIGRlZmluZWQgaW4gdGhl IHNhbWUgbW9kdWxlIiAtLSBzbyB0aGlzIGNsZWFybHkgZG9lc24ndA0KPiA+ID4gYXBwbHkgdG8g bW91bnQgcG9pbnRzIHdpdGggZGlmZmVyZW50IG5hbWVzLCByaWdodD8NCj4gPiA+DQo+ID4gPiBG b3IgZXhhbXBsZSwgeW91IGNhbiBoYXZlOg0KPiA+ID4NCj4gPiA+ICAgY29udGFpbmVyIGZvbyB7 DQo+ID4gPiAgICAgeWFuZ21udDptb3VudC1wb2ludCBteS1tbnQtcG9pbnQ7DQo+ID4gPiAgIH0N Cj4gPiA+ICAgY29udGFpbmVyIGJhciB7DQo+ID4gPiAgICAgeWFuZ21udDptb3VudC1wb2ludCBt eS1tbnQtcG9pbnQ7DQo+ID4gPiAgIH0NCj4gPiA+DQo+ID4gPiBUaGVyZSBpcyBqdXN0IG9uZSBl bnRyeSBpbiB0aGUgIm1vdW50LXBvaW50IiBsaXN0LCBzbyB0aGF0IGVudHJ5DQo+ID4gPiBhcHBs aWVzIHRvIGJvdGggdGhlc2UgbW91bnQgcG9pbnRzLiAgQm90aCBhcmUgZWl0aGVyICJpbmxpbmUi IG9yDQo+ID4gPiAic2hhcmVkLXNjaGVtYSIuDQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gNi4gU2Vj dGlvbiAzLjINCj4gPiA+ID4gICAgSW5zdGVhZCBvZiAiaW5saW5lIiBhbmQgInNoYXJlZC1zY2hl bWEiLCBJIHN1Z2dlc3QgdG8gdXNlDQo+ID4gPiA+ICAgICJ2YXJpYWJsZS1zY2hlbWEiIGFuZA0K PiA+ID4gPiAgICAic2FtZS1zY2hlbWEiDQo+ID4gPiA+ICAgIFJlYXNvbjogVGhlIGtleSBkaWZm ZXJlbmNlIGJldHdlZW4gdGhlIHR3byBpcyB0aGF0IGluIG9uZSBjYXNlLCB0aGUNCj4gPiA+ID4g ICAgc2NoZW1hIE1BWSBiZSBkaWZmZXJlbnQNCj4gPiA+ID4gICAgd2hpbGUgaW4gdGhlIG90aGVy IHRoZSBzY2hlbWEgaXMgc2FtZS4gVGhlIG5hbWUgY2FuIGJlIHNpbWlsYXIgdG8gdGhlDQo+ID4g PiA+ICAgIHJlYXNvbi4NCj4gPiA+DQo+ID4gPiBBdCB0aGlzIHBvaW50LCB3ZSBoYXZlIHRvIGxp dmUgd2l0aCB0aGVzZSB0ZXJtcy4gIFRoaXMgd2FzIHBhcnQgb2YgdGhlDQo+ID4gPiBjb21wcm9t aXNlIGxlYWRpbmcgdG8gdGhpcyBzb2x1dGlvbjsgdGhlcmUgYXJlIG90aGVyIGRvY3VtZW50cyBp biB0aGUNCj4gPiA+IFJGQyBlZGl0b3IncyBxdWV1ZSB0aGF0IGRlcGVuZCBvbiB0aGVzZSB0ZXJt cy4NCj4gPiA+DQo+ID4gPiA+IExvZ2ljYWwgUG9pbnQ6DQo+ID4gPiA+IDEuIENvbnNpZGVyIHRo ZSB0b3BvbG9neSB3aGVyZSAxIG1haW4gZGV2aWNlIGlzIHByZXNlbnQgd2l0aCBOIGxvZ2ljYWwN Cj4gPiA+ID4gZGV2aWNlcyBiZWhpbmQgaXQuDQo+ID4gPiA+ICAgIFdoZW4gdGhlIG1vdW50aW5n IGlzIGRvbmUsIGl0IGlzIHF1aXRlIHBvc3NpYmxlIHRoYXQgc29tZSBvZiBOIGRldmljZXMNCj4g PiA+ID4gICAgYXJlIGhhdmluZyBkaWZmZXJlbnQNCj4gPiA+ID4gICAgdmVyc2lvbnMgb2YgbW9k dWxlcy4NCj4gPiA+ID4gICAgVGhpcyBjYW4gbGVhZCB0byBlYWNoIGluc3RhbmNlIG9mIG1vdW50 IHBvaW50LCBoYXZpbmcgZGlmZmVyZW50DQo+ID4gPiA+ICAgIHNjaGVtYS4NCj4gPiA+ID4gICAg SG93IGNhbiB0aGUgY2xpZW50IHVuZGVyc3RhbmQgdGhlIHNjaGVtYSBvZiBlYWNoIG1vdW50LXBv aW50IGluc3RhbmNlDQo+ID4gPiA+ICAgID8gUHJlZmVyYWJseSBnZXQtc2NoZW1hIG9mIHRoZXNl IGRldmljZXMgYW5kIHRoZW4ga25vdyB0aGUgbW9kZWwgPw0KPiA+ID4NCj4gPiA+IFRoaXMgZHJh ZnQgc2F5cyB0aGF0IGVhY2ggaW5zdGFuY2Ugd2lsbCBoYXZlIGl0cyBvd24gWUFORyBsaWJyYXJ5 DQo+ID4gPiBpbnN0YW5jZS4gIFNvIHRoZXJlIHRoZSBjbGllbnQgY2FuIGRldGVjdCB3aGljaCB2 ZXJzaW9ucyBvZiB0aGUNCj4gPiA+IGRpZmZlcmVudCBtb2R1bGVzIGVhY2ggaW5zdGFuY2Ugc3Vw cG9ydHMuICBUaGVuIDxnZXQtc2NoZW1hPiBjYW4gYmUNCj4gPiA+IGludm9rZWQgdG8gZ2V0IHRo ZSBtb2R1bGVzLCBpZiBpdCBpcyBzdXBwb3J0ZWQuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IC9tYXJ0 aW4NCj4gPiA+DQo= From nobody Fri Apr 6 06:55:53 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECA01270A7 for ; Fri, 6 Apr 2018 06:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rKGVehmFTyC for ; Fri, 6 Apr 2018 06:55:49 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050521200FC for ; Fri, 6 Apr 2018 06:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4127; q=dns/txt; s=iport; t=1523022949; x=1524232549; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=fKifEXqWG98gMRuS0IsyR3FDcqFmAG3YJrDSjhqGeW8=; b=NdfBei55WKCSwc+4HCF4DJ7KZWt95fwEdr94dplHF1qsS+6GuSM9CDD5 xu58uL74om6Cj5jMo0pcZz46MSK+R5Miqk0NSSyawoC3a9xKzE/fTKVOe HLZMbn/GNXRMxs0jkQYTLm86lc2bZHT/EcqP5/iz7lWy17TISkZegbgHQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAQCEe8da/xbLJq1UCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDE4F/KINfiF6NdwghgQ+UUguFAwKCWTcVAQIBAQEBAQE?= =?us-ascii?q?CbCiFIgEBAQECASMPAQVRCxAIAgImAgJXBgEMBgIBAReEagipBYIchFeDcII?= =?us-ascii?q?lgQmINj+BDCIMgiguhEWDKoJUApdDCI4tBodEhHyKaYUdgSUyIoFSMxoIGxU?= =?us-ascii?q?6gkOQTz4wjhoBAQ?= X-IronPort-AV: E=Sophos;i="5.48,415,1517875200"; d="scan'208";a="3038163" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2018 13:55:45 +0000 Received: from [10.63.23.169] (dhcp-ensft1-uk-vla370-10-63-23-169.cisco.com [10.63.23.169]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w36DtjBg023835; Fri, 6 Apr 2018 13:55:45 GMT To: Ladislav Lhotka , netmod@ietf.org References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> From: Robert Wilton Message-ID: <4c3be475-0b9c-5837-5d08-115201b43305@cisco.com> Date: Fri, 6 Apr 2018 14:55:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 13:55:51 -0000 At the moment, I would say that the vast majority of the definitions in IANA.yang are just noise because they refer to definitions that are obsolete.  Our OS seems to use only 10% of the 287+ defined IANA types, and that 10% includes technologies such as frame relay, serial, atm, that very much seem to be on their way out. Using hierarchical identities and interface properties seems like a reasonable solution to me (e.g. as described in draft-wilton-netmod-interface-properties-00).  E.g. so rather than having configuration with a direct when statement on a specific list of interface types, instead the when statement can depend on the appropriate interface properties. I also like Lada's suggestion of trying to spread out the IANA definitions to the modules that are defining the technology.  So, if a device implements support for PPP configuration/operational state then it would also naturally define any PPP related interface identities at the same time. If a vendor wants to define their own flavour of Ethernet interface then they can do so in their vendor specific module without requiring all tooling to become aware of it, and allowing the existing Ethernet configuration to work as normal. On 06/04/2018 13:01, Ladislav Lhotka wrote: > On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote: >> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: >>> Juergen Schoenwaelder writes: >>> >>>> If we would have a mechanism to deviate an identityref to a subset of >>>> identity values supported by an implementation, we would have solved a >>>> more generic problem. Yes, the IANA list could be 'nicer' but it will >>>> never be 'nice'. >>> Three mechanisms can be used for this: >>> >>> - splitting the identities into separate modules >> Whatever module organization you come up with, it won't work for all >> implementations. Yes, getting the root of this structure right is perhaps somewhat tricky, but I don't think that it needs to be all encompassing, or perfect. >>> - using features >> Making every identity a feature will turn the feature system upside >> down. This is similar to making every leaf a feature. >> >>> - using deviations (even though vendors frown on them) >> If my implementation only supports A and B and C, then a deviation may >> state exactly that and the problem is solved. Hoping that my specific > In fact, deviations cannot delete identity values because they aren't schema > nodes, so they are of no use. > >> combination of A and B and C matches a set of modules or some set of >> features is in my view an illusion. > An implementation that supports, say, a given type of tunnel interface will > implement the module that covers this tunnel type. If the identity for this > tunnel interface type is defined in the same module, then all is good. I don't > get why this should be an illusion. On the contrary, I think it is the cleanest > available solution to this conformance specification problem. > >> Vendors not shipping proper deviations are essentially telling their >> customers that they have not yet understood model driven management. >> We need to change the mindset here instead of polluting our data >> models with hundreds or thousands of fine grained 'features'. > I agree that zillions of features aren't nice but it seems to be the only > solution that we currently have for modules of the iana-if-type style. > > Having an bulky set of identity values, most of which are of no interest, is IMO > much worse and could also be a security issue if implementors aren't careful > enough. I'm not sure there is a security concern here, but a long list where most of the values are cruft doesn't really seem to help anyone.  It also makes it harder to know which is the right type to use.  E.g. will everyone know that they should use "ethernetCsmacd" rather than "gigabitEthernet" for an optical GE interface that doesn't actually use CSMA/CD ... Thanks, Rob > > Lada > >> /js >> From nobody Fri Apr 6 09:03:42 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E322120724 for ; Fri, 6 Apr 2018 09:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amlyCOcWzpco for ; Fri, 6 Apr 2018 09:03:38 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361A31204DA for ; Fri, 6 Apr 2018 09:03:38 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id v207-v6so1252262lfa.10 for ; Fri, 06 Apr 2018 09:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9H4KD/bvx/9PLFONUhqmQckl9ee35KbL+YrMO2+kwu0=; b=WRJWHstsXAa324Ied8f5lJOhD3+gBJJu1s4rltzsJBMBS3UgG5Z08svwh2mrec9BL+ EbKLp/JBf9tTFZ6qa5bvGu/xNmiUNnOv75R5l00CwPiK1XQL3VgzK9FfWyxPOSerZmoz lIzZ+KEVfV0tNOVgPoMggJtF87Pjcw39q5TZece5qc5J+98gEYoT8yEe8Xk22v7JboqT fkBj0FPcj5HnH1MQ8+z0w11qPaSG4281Y5njDiRVQRRBWs2p5RjjVb4ZDHls4U4UdKeE lu3JfsngivVaryRWJFkbzvkFuqHPcNNSel0Unq2Y6fDN08WVmUBIELBOJ9lPjvZFQhw4 nGpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9H4KD/bvx/9PLFONUhqmQckl9ee35KbL+YrMO2+kwu0=; b=hbGUP1BGHVYIZ55oBWXgjqFWYX4ArciyPlVxhLy96RazXaAk+Tl4+p/VOtZgwciw7y vM2iGhb1D7ibFHFWKBpTU6jy23NUi1u5yTHjmdMQ66GUdGKhmXot7CpldNUqAG/5H+Gv Kek315GD1Q3fv6Hzgt8Jp+upiK3/3EOXnTvbj5mgpE2bwOPxdQNDzzRp5GimWfZtKSuU s5XvjC9fkl4KDfNPFh7EIAyKlP47qIOYjqYFw+2Jm+XRx83EXlo3ZZ4n8yfTMERRAdOL xCaCeu8UNErQLoKCBkWh8vDsD/Olos+f4Oi7gIFvqqPbvw5dxMPhHJJQQ9+aIrrXcYYI 2SvA== X-Gm-Message-State: ALQs6tCMvV4blPzTzxyHZsmb49WhEsJDdnJmgi0uqhUX9WWS7GZwN9rM OHy9WvVVF2/eLt8qyT96vx7iO5akvM9uh4mCLdaltA== X-Google-Smtp-Source: AIpwx4+CccAflIpYEcRl7XyNGIC/4owZH/hWd5kxWD/9D+aHxCF1VIp4PgMW+cuEgFtalVTsCuZWsPHEiq44+ecgWNU= X-Received: by 10.46.56.2 with SMTP id f2mr16606411lja.15.1523030616288; Fri, 06 Apr 2018 09:03:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:5149:0:0:0:0:0 with HTTP; Fri, 6 Apr 2018 09:03:35 -0700 (PDT) In-Reply-To: <4c3be475-0b9c-5837-5d08-115201b43305@cisco.com> References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> <4c3be475-0b9c-5837-5d08-115201b43305@cisco.com> From: Andy Bierman Date: Fri, 6 Apr 2018 09:03:35 -0700 Message-ID: To: Robert Wilton Cc: Ladislav Lhotka , NetMod WG Content-Type: multipart/alternative; boundary="089e0823d90cddc7c505693032a1" Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 16:03:41 -0000 --089e0823d90cddc7c505693032a1 Content-Type: text/plain; charset="UTF-8" Hi, All of these suggested solutions seem OK if one were looking for the most disruptive way to solve the problem. Tossing iana-if-types and starting over would achieve that result. First, this is a server capabilities problem, so it is related to the implementation, not the schema. Second, the if-types that are allowed at any given moment can be specific to the implementation and the interface name. I think this is the 3rd time I have suggested an RPC to solve the actual probem: rpc get-allowed-if-types { description "Retrieve the interface types allowed by the server."; input { leaf name { type if:interface-ref; description "If present, the server will return allowed interface types for this interface name only. If not present, then the server will return all supported interface types."; } } output { leaf-list type { type identityref { base interface-type; } description "Specifies a supported interface type"; } } } Andy On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton wrote: > At the moment, I would say that the vast majority of the definitions in > IANA.yang are just noise because they refer to definitions that are > obsolete. Our OS seems to use only 10% of the 287+ defined IANA types, and > that 10% includes technologies such as frame relay, serial, atm, that very > much seem to be on their way out. > > Using hierarchical identities and interface properties seems like a > reasonable solution to me (e.g. as described in > draft-wilton-netmod-interface-properties-00). E.g. so rather than having > configuration with a direct when statement on a specific list of interface > types, instead the when statement can depend on the appropriate interface > properties. > > I also like Lada's suggestion of trying to spread out the IANA definitions > to the modules that are defining the technology. So, if a device > implements support for PPP configuration/operational state then it would > also naturally define any PPP related interface identities at the same time. > > If a vendor wants to define their own flavour of Ethernet interface then > they can do so in their vendor specific module without requiring all > tooling to become aware of it, and allowing the existing Ethernet > configuration to work as normal. > > > > On 06/04/2018 13:01, Ladislav Lhotka wrote: > >> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote: >> >>> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: >>> >>>> Juergen Schoenwaelder writes: >>>> >>>> If we would have a mechanism to deviate an identityref to a subset of >>>>> identity values supported by an implementation, we would have solved a >>>>> more generic problem. Yes, the IANA list could be 'nicer' but it will >>>>> never be 'nice'. >>>>> >>>> Three mechanisms can be used for this: >>>> >>>> - splitting the identities into separate modules >>>> >>> Whatever module organization you come up with, it won't work for all >>> implementations. >>> >> Yes, getting the root of this structure right is perhaps somewhat tricky, > but I don't think that it needs to be all encompassing, or perfect. > > - using features >>>> >>> Making every identity a feature will turn the feature system upside >>> down. This is similar to making every leaf a feature. >>> >>> - using deviations (even though vendors frown on them) >>>> >>> If my implementation only supports A and B and C, then a deviation may >>> state exactly that and the problem is solved. Hoping that my specific >>> >> In fact, deviations cannot delete identity values because they aren't >> schema >> nodes, so they are of no use. >> >> combination of A and B and C matches a set of modules or some set of >>> features is in my view an illusion. >>> >> An implementation that supports, say, a given type of tunnel interface >> will >> implement the module that covers this tunnel type. If the identity for >> this >> tunnel interface type is defined in the same module, then all is good. I >> don't >> get why this should be an illusion. On the contrary, I think it is the >> cleanest >> available solution to this conformance specification problem. >> >> Vendors not shipping proper deviations are essentially telling their >>> customers that they have not yet understood model driven management. >>> We need to change the mindset here instead of polluting our data >>> models with hundreds or thousands of fine grained 'features'. >>> >> I agree that zillions of features aren't nice but it seems to be the only >> solution that we currently have for modules of the iana-if-type style. >> >> Having an bulky set of identity values, most of which are of no interest, >> is IMO >> much worse and could also be a security issue if implementors aren't >> careful >> enough. >> > I'm not sure there is a security concern here, but a long list where most > of the values are cruft doesn't really seem to help anyone. It also makes > it harder to know which is the right type to use. E.g. will everyone know > that they should use "ethernetCsmacd" rather than "gigabitEthernet" for an > optical GE interface that doesn't actually use CSMA/CD ... > > Thanks, > Rob > > > >> Lada >> >> /js >>> >>> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e0823d90cddc7c505693032a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

All of these suggested solutions se= em OK if one were looking for the most disruptive
way to solve th= e problem.=C2=A0 Tossing iana-if-types and starting over would achieve that= result.

First, this is a server capabilities prob= lem, so it is related to the implementation, not the schema.

=
Second, the if-types that are allowed at any given moment can be= specific to the implementation
and the interface name.

I think this is the 3rd time I have suggested an RPC to sol= ve the actual probem:

=C2=A0 rpc get-allowed-if-ty= pes {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 &q= uot;Retrieve the interface types allowed by the server.";
= =C2=A0 =C2=A0 input {
=C2=A0 =C2=A0 =C2=A0 leaf name {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type if:interface-ref;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 "If present, the server will return allowed interfac= e types for this interface name only.
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0If not present, then the server will return all suppor= ted interface types.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0output {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf-list type {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 type identityref {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base interface-type;
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "Specifies a supported interface type";
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0}


Andy


On Fri, Apr 6, 2018 at 6:= 55 AM, Robert Wilton <rwilton@cisco.com> wrote:
At the moment, I would say that the vast majority of = the definitions in IANA.yang are just noise because they refer to definitio= ns that are obsolete.=C2=A0 Our OS seems to use only 10% of the 287+ define= d IANA types, and that 10% includes technologies such as frame relay, seria= l, atm, that very much seem to be on their way out.

Using hierarchical identities and interface properties seems like a reasona= ble solution to me (e.g. as described in draft-wilton-netmod-interface-properties-00).=C2=A0 E.g. so rather than having configuration with a dire= ct when statement on a specific list of interface types, instead the when s= tatement can depend on the appropriate interface properties.

I also like Lada's suggestion of trying to spread out the IANA definiti= ons to the modules that are defining the technology.=C2=A0 So, if a device = implements support for PPP configuration/operational state then it would al= so naturally define any PPP related interface identities at the same time.<= br>
If a vendor wants to define their own flavour of Ethernet interface then th= ey can do so in their vendor specific module without requiring all tooling = to become aware of it, and allowing the existing Ethernet configuration to = work as normal.



On 06/04/2018 13:01, Ladislav Lhotka wrote:
On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = writes:

If we would have a mechanism to deviate an identityref to a subset of
identity values supported by an implementation, we would have solved a
more generic problem. Yes, the IANA list could be 'nicer' but it wi= ll
never be 'nice'.
Three mechanisms can be used for this:

- splitting the identities into separate modules
Whatever module organization you come up with, it won't work for all implementations.
Yes, getting the root of this structure right is perhaps somewhat tricky, b= ut I don't think that it needs to be all encompassing, or perfect.

- using features
Making every identity a feature will turn the feature system upside
down. This is similar to making every leaf a feature.

- using deviations (even though vendors frown on them)
If my implementation only supports A and B and C, then a deviation may
state exactly that and the problem is solved. Hoping that my specific
In fact, deviations cannot delete identity values because they aren't s= chema
nodes, so they are of no use.

combination of A and B and C matches a set of modules or some set of
features is in my view an illusion.
An implementation that supports, say, a given type of tunnel interface will=
implement the module that covers this tunnel type. If the identity for this=
tunnel interface type is defined in the same module, then all is good. I do= n't
get why this should be an illusion. On the contrary, I think it is the clea= nest
available solution to this conformance specification problem.

Vendors not shipping proper deviations are essentially telling their
customers that they have not yet understood model driven management.
We need to change the mindset here instead of polluting our data
models with hundreds or thousands of fine grained 'features'.
I agree that zillions of features aren't nice but it seems to be the on= ly
solution that we currently have for modules of the iana-if-type style.

Having an bulky set of identity values, most of which are of no interest, i= s IMO
much worse and could also be a security issue if implementors aren't ca= reful
enough.
I'm not sure there is a security concern here, but a long list where mo= st of the values are cruft doesn't really seem to help anyone.=C2=A0 It= also makes it harder to know which is the right type to use.=C2=A0 E.g. wi= ll everyone know that they should use "ethernetCsmacd" rather tha= n "gigabitEthernet" for an optical GE interface that doesn't = actually use CSMA/CD ...

Thanks,
Rob



Lada

/js


_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

--089e0823d90cddc7c505693032a1-- From nobody Fri Apr 6 09:24:20 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C16112025C for ; Fri, 6 Apr 2018 09:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lfh5nRHYI1C2 for ; Fri, 6 Apr 2018 09:24:16 -0700 (PDT) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7181A1200C5 for ; Fri, 6 Apr 2018 09:24:16 -0700 (PDT) Received: by mail-pl0-x230.google.com with SMTP id g20-v6so923711plo.9 for ; Fri, 06 Apr 2018 09:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dGC2L83jtwBWpYwB9ze0EYW+DTUVrlQCo2o5havh0SY=; b=vHnJYgELKy7lA+uHVKkqt7Qi+6dqXDY/O4rEzmnKWJQb4kt4Kyx3e7x3VYRZhtYnMd 41VC5LzKjz75HZ+MIwxM6mTNJkCrvdSifMgoImTZnWP4E6viZXnEryO1RAQz0+CTMS6D /UPTpG5o1wtuiq7wNt+eb8tOxy3dJvTKdgYHvSIZ0MHKsrf6rrXd6nYRqHkacNu7a4rQ Tf+AhSBZFuIXFEIk7aTcoeue6qbz2lRpM9tdF5tTZyWDTaPH/PXMMfJqEWs8jGa5taEx 5wu6oOlevOtzeQgTFH3uusTO/G3IYdU5D7Hx0IbgTUxnevubvjtgFCfY9yGwkv7YoYBs AwoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dGC2L83jtwBWpYwB9ze0EYW+DTUVrlQCo2o5havh0SY=; b=VM2koS/S6Hqt53fK7+ZXl4PUkVARoHXMf0vq8cyxpEdWuWGwtOUpoj8a75r7l51Jjc KDcm2nT24/AS+I6MTIiNkJw2yZZgQ7vt/M5dqI6xWqOmf9p5GYjGwjye507LdANqxgNK KOsdgqkl7XoHmitXBPCScVmQA+QkcsxHOrp2RI/nNc0+jmOuivpoeBNy+X+/s+maLbLt +CZuJ3n4zP9MFvKcEyea+J+C6G+xS+OnPXv/RgParUX9e5ZDQEunmoa/kAhuOqQ6pE5R xvvx11e1hNfAqZsh7PaFipNcT3JQvGJNFMaNenj+2fw5SnZvGTlFn20ahiLBcUjyoI/h 7Dhw== X-Gm-Message-State: ALQs6tB4nGzLgwtx02SprNey2lA5vSvYni+fQv2PCBH8cggJ/nPuMs54 58UsQjMktRUEWsOVvVcn89s= X-Google-Smtp-Source: AIpwx4+vEKsH6nue1UIT5GxMjoFyJBERZ50/ifO3Pm4Q9lHNsv9n0ofAj3XVA+JF8avnG01Q/1OcdA== X-Received: by 2002:a17:902:8205:: with SMTP id x5-v6mr7326896pln.57.1523031855916; Fri, 06 Apr 2018 09:24:15 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:59c2:6e72:fd86:4fbf? ([2601:647:4700:1280:59c2:6e72:fd86:4fbf]) by smtp.gmail.com with ESMTPSA id p1sm4213387pgc.15.2018.04.06.09.24.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Apr 2018 09:24:14 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D49327CC-5C60-41D1-BEAD-E7F6AEC961E6" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 6 Apr 2018 09:24:13 -0700 In-Reply-To: Cc: Robert Wilton , NetMod WG To: Andy Bierman References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> <4c3be475-0b9c-5837-5d08-115201b43305@cisco.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 16:24:20 -0000 --Apple-Mail=_D49327CC-5C60-41D1-BEAD-E7F6AEC961E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Chassis based systems have line cards that support particular interface = types. What happens to the output when a line card is plugged in or out = of the system? In other words, is this a static or a dynamic list? > On Apr 6, 2018, at 9:03 AM, Andy Bierman wrote: >=20 > Hi, >=20 > All of these suggested solutions seem OK if one were looking for the = most disruptive > way to solve the problem. Tossing iana-if-types and starting over = would achieve that result. >=20 > First, this is a server capabilities problem, so it is related to the = implementation, not the schema. >=20 > Second, the if-types that are allowed at any given moment can be = specific to the implementation > and the interface name. >=20 > I think this is the 3rd time I have suggested an RPC to solve the = actual probem: >=20 > rpc get-allowed-if-types { > description > "Retrieve the interface types allowed by the server."; > input { > leaf name { > type if:interface-ref; > description > "If present, the server will return allowed interface = types for this interface name only. > If not present, then the server will return all supported = interface types."; > } > } > output { > leaf-list type { > type identityref { > base interface-type; > } > description > "Specifies a supported interface type"; > } > } > } >=20 >=20 > Andy >=20 >=20 > On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton > wrote: > At the moment, I would say that the vast majority of the definitions = in IANA.yang are just noise because they refer to definitions that are = obsolete. Our OS seems to use only 10% of the 287+ defined IANA types, = and that 10% includes technologies such as frame relay, serial, atm, = that very much seem to be on their way out. >=20 > Using hierarchical identities and interface properties seems like a = reasonable solution to me (e.g. as described in = draft-wilton-netmod-interface-properties-00). E.g. so rather than = having configuration with a direct when statement on a specific list of = interface types, instead the when statement can depend on the = appropriate interface properties. >=20 > I also like Lada's suggestion of trying to spread out the IANA = definitions to the modules that are defining the technology. So, if a = device implements support for PPP configuration/operational state then = it would also naturally define any PPP related interface identities at = the same time. >=20 > If a vendor wants to define their own flavour of Ethernet interface = then they can do so in their vendor specific module without requiring = all tooling to become aware of it, and allowing the existing Ethernet = configuration to work as normal. >=20 >=20 >=20 > On 06/04/2018 13:01, Ladislav Lhotka wrote: > On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote: > On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder > writes: >=20 > If we would have a mechanism to deviate an identityref to a subset of > identity values supported by an implementation, we would have solved a > more generic problem. Yes, the IANA list could be 'nicer' but it will > never be 'nice'. > Three mechanisms can be used for this: >=20 > - splitting the identities into separate modules > Whatever module organization you come up with, it won't work for all > implementations. > Yes, getting the root of this structure right is perhaps somewhat = tricky, but I don't think that it needs to be all encompassing, or = perfect. >=20 > - using features > Making every identity a feature will turn the feature system upside > down. This is similar to making every leaf a feature. >=20 > - using deviations (even though vendors frown on them) > If my implementation only supports A and B and C, then a deviation may > state exactly that and the problem is solved. Hoping that my specific > In fact, deviations cannot delete identity values because they aren't = schema > nodes, so they are of no use. >=20 > combination of A and B and C matches a set of modules or some set of > features is in my view an illusion. > An implementation that supports, say, a given type of tunnel interface = will > implement the module that covers this tunnel type. If the identity for = this > tunnel interface type is defined in the same module, then all is good. = I don't > get why this should be an illusion. On the contrary, I think it is the = cleanest > available solution to this conformance specification problem. >=20 > Vendors not shipping proper deviations are essentially telling their > customers that they have not yet understood model driven management. > We need to change the mindset here instead of polluting our data > models with hundreds or thousands of fine grained 'features'. > I agree that zillions of features aren't nice but it seems to be the = only > solution that we currently have for modules of the iana-if-type style. >=20 > Having an bulky set of identity values, most of which are of no = interest, is IMO > much worse and could also be a security issue if implementors aren't = careful > enough. > I'm not sure there is a security concern here, but a long list where = most of the values are cruft doesn't really seem to help anyone. It = also makes it harder to know which is the right type to use. E.g. will = everyone know that they should use "ethernetCsmacd" rather than = "gigabitEthernet" for an optical GE interface that doesn't actually use = CSMA/CD ... >=20 > Thanks, > Rob >=20 >=20 >=20 > Lada >=20 > /js >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_D49327CC-5C60-41D1-BEAD-E7F6AEC961E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Chassis based systems have line cards that support particular = interface types. What happens to the output when a line card is plugged = in or out of the system? In other words, is this a static or a dynamic = list?

On Apr 6, 2018, at 9:03 AM, Andy Bierman = <andy@yumaworks.com> wrote:

Hi,

All = of these suggested solutions seem OK if one were looking for the most = disruptive
way to solve the problem.  Tossing = iana-if-types and starting over would achieve that result.

First, this is a server = capabilities problem, so it is related to the implementation, not the = schema.

Second, = the if-types that are allowed at any given moment can be specific to the = implementation
and the interface name.

I think this is the 3rd = time I have suggested an RPC to solve the actual probem:

  rpc = get-allowed-if-types {
    = description
      "Retrieve the = interface types allowed by the server.";
  =   input {
      leaf name = {
         type = if:interface-ref;
        =  description
        =     "If present, the server will return allowed interface = types for this interface name only.
    =          If not present, then the server will = return all supported interface types.";
  =      }
    =  }
     output {
         leaf-list type {
            type identityref = {
              =  base interface-type;
      =       }
        =     description
      =         "Specifies a supported interface = type";
        }
    }
 }


Andy


On Fri, = Apr 6, 2018 at 6:55 AM, Robert Wilton <rwilton@cisco.com> wrote:
At the moment, I would = say that the vast majority of the definitions in IANA.yang are just = noise because they refer to definitions that are obsolete.  Our OS = seems to use only 10% of the 287+ defined IANA types, and that 10% = includes technologies such as frame relay, serial, atm, that very much = seem to be on their way out.

Using hierarchical identities and interface properties seems like a = reasonable solution to me (e.g. as described in = draft-wilton-netmod-interface-properties-00).  E.g. = so rather than having configuration with a direct when statement on a = specific list of interface types, instead the when statement can depend = on the appropriate interface properties.

I also like Lada's suggestion of trying to spread out the IANA = definitions to the modules that are defining the technology.  So, = if a device implements support for PPP configuration/operational state = then it would also naturally define any PPP related interface identities = at the same time.

If a vendor wants to define their own flavour of Ethernet interface then = they can do so in their vendor specific module without requiring all = tooling to become aware of it, and allowing the existing Ethernet = configuration to work as normal.



On 06/04/2018 13:01, Ladislav Lhotka wrote:
On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = writes:

If we would have a mechanism to deviate an identityref to a subset of
identity values supported by an implementation, we would have solved = a
more generic problem. Yes, the IANA list could be 'nicer' but it will
never be 'nice'.
Three mechanisms can be used for this:

- splitting the identities into separate modules
Whatever module organization you come up with, it won't work for all
implementations.
Yes, getting the root of this structure right is perhaps somewhat = tricky, but I don't think that it needs to be all encompassing, or = perfect.

- using features
Making every identity a feature will turn the feature system upside
down. This is similar to making every leaf a feature.

- using deviations (even though vendors frown on them)
If my implementation only supports A and B and C, then a deviation = may
state exactly that and the problem is solved. Hoping that my specific
In fact, deviations cannot delete identity values because they aren't = schema
nodes, so they are of no use.

combination of A and B and C matches a set of modules or some set of
features is in my view an illusion.
An implementation that supports, say, a given type of tunnel interface = will
implement the module that covers this tunnel type. If the identity for = this
tunnel interface type is defined in the same module, then all is good. I = don't
get why this should be an illusion. On the contrary, I think it is the = cleanest
available solution to this conformance specification problem.

Vendors not shipping proper deviations are essentially telling their
customers that they have not yet understood model driven management.
We need to change the mindset here instead of polluting our data
models with hundreds or thousands of fine grained 'features'.
I agree that zillions of features aren't nice but it seems to be the = only
solution that we currently have for modules of the iana-if-type = style.

Having an bulky set of identity values, most of which are of no = interest, is IMO
much worse and could also be a security issue if implementors aren't = careful
enough.
I'm not sure there is a security concern here, but a long list where = most of the values are cruft doesn't really seem to help anyone.  = It also makes it harder to know which is the right type to use.  = E.g. will everyone know that they should use "ethernetCsmacd" rather = than "gigabitEthernet" for an optical GE interface that doesn't actually = use CSMA/CD ...

Thanks,
Rob



Lada

/js


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod = mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_D49327CC-5C60-41D1-BEAD-E7F6AEC961E6-- From nobody Fri Apr 6 09:39:55 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D49112025C for ; Fri, 6 Apr 2018 09:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZehLhLDVIPn for ; Fri, 6 Apr 2018 09:39:51 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004F51200C5 for ; Fri, 6 Apr 2018 09:39:50 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id z143-v6so1400383lff.3 for ; Fri, 06 Apr 2018 09:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xar6v1YlV5qur1KT01UH8MW+SLcp0tHceLlChcuDhMc=; b=RGa63z8Ai4uLs2+ddd4Mt06hmWfVY8QpjOPgFI6VQIk+UkGwrrBujrYOisIHM60wWD W912Uz9VyKhcSYiJ29bXt6nUP7xNIJ6xp1kj0zOLf6X93zN+2VnzKIxjcGLpMZwWnAad P55nYPP7c91DIs+Mm11O7qg4B5sW3uoF9LJvfPwr5ARbvBt9aGHwm0HMRNZC2JwIqOK4 Uv0PYM4j9ZV3eY4TPph5JGIOGOdTwvfZ/Zp9aDacJukAdiDem8Q/gDfFVngH+YHqer8F NBn7Os3yEAj8G6l4Qu1/QK9BoQywH2h4K4kKIyMv3VWcoyfOsWONY0MRgzdJtiDevntj dxfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xar6v1YlV5qur1KT01UH8MW+SLcp0tHceLlChcuDhMc=; b=JaRSAena7jumaBfRh4tRr8yHEkli42ks+so9rhXKhk+zM9D7utl+FfWhI8d8LEAURa Ct+W3qgWVAiQBc6ErEH2xn0b1dA8gMH6y4EnYZpsYF11XYUS1eLrzRE+uTsKDgY2WlZt EtGzXW93Y0x7vma3XvIoIby++tMVGKuQ/ocO3AMxnay7xBiXeGVQiyQ0+ql5oeM/3bKl hblEleClN0P8dXyIiNw0YE4kbw1tS31Aq5ZxUtUlSBOZZMJRWQr/3F5ddEkwE1fchd2q h3zR0NyKnB+jGwa+P6/Ncp5EXjR1Ws9VZ/nm64uRCPGoC/AOLUIsjxvHIdGFPulTuOlV u1Aw== X-Gm-Message-State: ALQs6tD+ji1S2C2tBo4ZI+PK9+7e/QwSMwZ2EhDPzeyeo1cR3oYpoVuk ROjnFNeZrRXpgSvJ+o3vv+uA937ZE/x6iRGkpylhVQ== X-Google-Smtp-Source: AIpwx4/K/pEt2Xyc0byu1G9HhEJgg859gZazybTKN4rtQSQIR896aNB9yMX++ZZ8RM/5keFANXtCiF2FUJOP5ri2Jfc= X-Received: by 10.46.29.140 with SMTP id w12mr16939810lje.108.1523032789229; Fri, 06 Apr 2018 09:39:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:5149:0:0:0:0:0 with HTTP; Fri, 6 Apr 2018 09:39:48 -0700 (PDT) In-Reply-To: References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> <4c3be475-0b9c-5837-5d08-115201b43305@cisco.com> From: Andy Bierman Date: Fri, 6 Apr 2018 09:39:48 -0700 Message-ID: To: Mahesh Jethanandani Cc: Robert Wilton , NetMod WG Content-Type: multipart/alternative; boundary="94eb2c1a6636623932056930b452" Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 16:39:54 -0000 --94eb2c1a6636623932056930b452 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 6, 2018 at 9:24 AM, Mahesh Jethanandani wrote: > Chassis based systems have line cards that support particular interface > types. What happens to the output when a line card is plugged in or out of > the system? In other words, is this a static or a dynamic list? > > An RPC is inherently dynamic. The output is based on the current state when the RPC is invoked. There are lots of ways (e.g., proprietary trunk modes) that the interface types allowed can change dynamically. BTW, the interface-ref in the input needs to be 'require-instance false' to allow for interfaces that are not yet configured. Andy On Apr 6, 2018, at 9:03 AM, Andy Bierman wrote: > > Hi, > > All of these suggested solutions seem OK if one were looking for the most > disruptive > way to solve the problem. Tossing iana-if-types and starting over would > achieve that result. > > First, this is a server capabilities problem, so it is related to the > implementation, not the schema. > > Second, the if-types that are allowed at any given moment can be specific > to the implementation > and the interface name. > > I think this is the 3rd time I have suggested an RPC to solve the actual > probem: > > rpc get-allowed-if-types { > description > "Retrieve the interface types allowed by the server."; > input { > leaf name { > type if:interface-ref; > description > "If present, the server will return allowed interface types > for this interface name only. > If not present, then the server will return all supported > interface types."; > } > } > output { > leaf-list type { > type identityref { > base interface-type; > } > description > "Specifies a supported interface type"; > } > } > } > > > Andy > > > On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton wrote: > >> At the moment, I would say that the vast majority of the definitions in >> IANA.yang are just noise because they refer to definitions that are >> obsolete. Our OS seems to use only 10% of the 287+ defined IANA types, and >> that 10% includes technologies such as frame relay, serial, atm, that very >> much seem to be on their way out. >> >> Using hierarchical identities and interface properties seems like a >> reasonable solution to me (e.g. as described in >> draft-wilton-netmod-interface-properties-00). E.g. so rather than >> having configuration with a direct when statement on a specific list of >> interface types, instead the when statement can depend on the appropriate >> interface properties. >> >> I also like Lada's suggestion of trying to spread out the IANA >> definitions to the modules that are defining the technology. So, if a >> device implements support for PPP configuration/operational state then it >> would also naturally define any PPP related interface identities at the >> same time. >> >> If a vendor wants to define their own flavour of Ethernet interface then >> they can do so in their vendor specific module without requiring all >> tooling to become aware of it, and allowing the existing Ethernet >> configuration to work as normal. >> >> >> >> On 06/04/2018 13:01, Ladislav Lhotka wrote: >> >>> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote: >>> >>>> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: >>>> >>>>> Juergen Schoenwaelder writes: >>>>> >>>>> If we would have a mechanism to deviate an identityref to a subset of >>>>>> identity values supported by an implementation, we would have solved a >>>>>> more generic problem. Yes, the IANA list could be 'nicer' but it will >>>>>> never be 'nice'. >>>>>> >>>>> Three mechanisms can be used for this: >>>>> >>>>> - splitting the identities into separate modules >>>>> >>>> Whatever module organization you come up with, it won't work for all >>>> implementations. >>>> >>> Yes, getting the root of this structure right is perhaps somewhat >> tricky, but I don't think that it needs to be all encompassing, or perfect. >> >> - using features >>>>> >>>> Making every identity a feature will turn the feature system upside >>>> down. This is similar to making every leaf a feature. >>>> >>>> - using deviations (even though vendors frown on them) >>>>> >>>> If my implementation only supports A and B and C, then a deviation may >>>> state exactly that and the problem is solved. Hoping that my specific >>>> >>> In fact, deviations cannot delete identity values because they aren't >>> schema >>> nodes, so they are of no use. >>> >>> combination of A and B and C matches a set of modules or some set of >>>> features is in my view an illusion. >>>> >>> An implementation that supports, say, a given type of tunnel interface >>> will >>> implement the module that covers this tunnel type. If the identity for >>> this >>> tunnel interface type is defined in the same module, then all is good. I >>> don't >>> get why this should be an illusion. On the contrary, I think it is the >>> cleanest >>> available solution to this conformance specification problem. >>> >>> Vendors not shipping proper deviations are essentially telling their >>>> customers that they have not yet understood model driven management. >>>> We need to change the mindset here instead of polluting our data >>>> models with hundreds or thousands of fine grained 'features'. >>>> >>> I agree that zillions of features aren't nice but it seems to be the only >>> solution that we currently have for modules of the iana-if-type style. >>> >>> Having an bulky set of identity values, most of which are of no >>> interest, is IMO >>> much worse and could also be a security issue if implementors aren't >>> careful >>> enough. >>> >> I'm not sure there is a security concern here, but a long list where most >> of the values are cruft doesn't really seem to help anyone. It also makes >> it harder to know which is the right type to use. E.g. will everyone know >> that they should use "ethernetCsmacd" rather than "gigabitEthernet" for an >> optical GE interface that doesn't actually use CSMA/CD ... >> >> Thanks, >> Rob >> >> >> >>> Lada >>> >>> /js >>>> >>>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > Mahesh Jethanandani > mjethanandani@gmail.com > > --94eb2c1a6636623932056930b452 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 6, 2018 at 9:24 AM, Mahesh Jethanandani &= lt;mjethananda= ni@gmail.com> wrote:
Chassis based sy= stems have line cards that support particular interface types. What happens= to the output when a line card is plugged in or out of the system? In othe= r words, is this a static or a dynamic list?


An RPC is inherently dynamic.
The outp= ut is based on the current state when the RPC is invoked.
There a= re lots of ways (e.g., proprietary trunk modes) that the interface types
allowed can change dynamically.

BTW, the i= nterface-ref in the input needs to be 'require-instance false'
to allow for interfaces that are not yet configured.

=C2=A0
Andy

On Apr 6, 2018, at 9:03 AM, Andy Bierman &= lt;andy@yumaworks.c= om> wrote:

Hi,

All of these suggeste= d solutions seem OK if one were looking for the most disruptive
w= ay to solve the problem.=C2=A0 Tossing iana-if-types and starting over woul= d achieve that result.

First, this is a server cap= abilities problem, so it is related to the implementation, not the schema.<= /div>

Second, the if-types that are allowed at any given= moment can be specific to the implementation
and the interface n= ame.

I think this is the 3rd time I have suggested= an RPC to solve the actual probem:

=C2=A0 rpc get= -allowed-if-types {
=C2=A0 =C2=A0 description
=C2=A0 = =C2=A0 =C2=A0 "Retrieve the interface types allowed by the server.&quo= t;;
=C2=A0 =C2=A0 input {
=C2=A0 =C2=A0 =C2=A0 leaf nam= e {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type if:interface-ref;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 "If present, the server will return allow= ed interface types for this interface name only.
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If not present, then the server will retu= rn all supported interface types.";
=C2=A0 =C2=A0 =C2=A0 =C2= =A0}
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0output {=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf-list type {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type identityref {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base interface-type;
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 "Specifies a supported interface type";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2= =A0}


Andy


On Fri, Apr 6, 2= 018 at 6:55 AM, Robert Wilton <rwilton@cisco.com> wrote:
=
At the moment, I would say that the vast maj= ority of the definitions in IANA.yang are just noise because they refer to = definitions that are obsolete.=C2=A0 Our OS seems to use only 10% of the 28= 7+ defined IANA types, and that 10% includes technologies such as frame rel= ay, serial, atm, that very much seem to be on their way out.

Using hierarchical identities and interface properties seems like a reasona= ble solution to me (e.g. as described in draft-wilton-netmod-interface-properties-00).=C2=A0 E.g. so rather than having configuration with a dire= ct when statement on a specific list of interface types, instead the when s= tatement can depend on the appropriate interface properties.

I also like Lada's suggestion of trying to spread out the IANA definiti= ons to the modules that are defining the technology.=C2=A0 So, if a device = implements support for PPP configuration/operational state then it would al= so naturally define any PPP related interface identities at the same time.<= br>
If a vendor wants to define their own flavour of Ethernet interface then th= ey can do so in their vendor specific module without requiring all tooling = to become aware of it, and allowing the existing Ethernet configuration to = work as normal.



On 06/04/2018 13:01, Ladislav Lhotka wrote:
On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = writes:

If we would have a mechanism to deviate an identityref to a subset of
identity values supported by an implementation, we would have solved a
more generic problem. Yes, the IANA list could be 'nicer' but it wi= ll
never be 'nice'.
Three mechanisms can be used for this:

- splitting the identities into separate modules
Whatever module organization you come up with, it won't work for all implementations.
Yes, getting the root of this structure right is perhaps somewhat tricky, b= ut I don't think that it needs to be all encompassing, or perfect.

- using features
Making every identity a feature will turn the feature system upside
down. This is similar to making every leaf a feature.

- using deviations (even though vendors frown on them)
If my implementation only supports A and B and C, then a deviation may
state exactly that and the problem is solved. Hoping that my specific
In fact, deviations cannot delete identity values because they aren't s= chema
nodes, so they are of no use.

combination of A and B and C matches a set of modules or some set of
features is in my view an illusion.
An implementation that supports, say, a given type of tunnel interface will=
implement the module that covers this tunnel type. If the identity for this=
tunnel interface type is defined in the same module, then all is good. I do= n't
get why this should be an illusion. On the contrary, I think it is the clea= nest
available solution to this conformance specification problem.

Vendors not shipping proper deviations are essentially telling their
customers that they have not yet understood model driven management.
We need to change the mindset here instead of polluting our data
models with hundreds or thousands of fine grained 'features'.
I agree that zillions of features aren't nice but it seems to be the on= ly
solution that we currently have for modules of the iana-if-type style.

Having an bulky set of identity values, most of which are of no interest, i= s IMO
much worse and could also be a security issue if implementors aren't ca= reful
enough.
I'm not sure there is a security concern here, but a long list where mo= st of the values are cruft doesn't really seem to help anyone.=C2=A0 It= also makes it harder to know which is the right type to use.=C2=A0 E.g. wi= ll everyone know that they should use "ethernetCsmacd" rather tha= n "gigabitEthernet" for an optical GE interface that doesn't = actually use CSMA/CD ...

Thanks,
Rob



Lada

/js


_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list=
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani


--94eb2c1a6636623932056930b452-- From nobody Sun Apr 8 07:36:47 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E771270A3 for ; Sun, 8 Apr 2018 07:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5n_u2n_FpAy for ; Sun, 8 Apr 2018 07:36:44 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53FC12025C for ; Sun, 8 Apr 2018 07:36:44 -0700 (PDT) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 31CE01ABF32 for ; Sun, 8 Apr 2018 08:36:44 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id Xqcg1x00L2SSUrH01qcj7T; Sun, 08 Apr 2018 08:36:44 -0600 X-Authority-Analysis: v=2.2 cv=M5g9E24s c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Kd1tUaAdevIA:10 a=48vgC7mUAAAA:8 a=PunyLC4vDLbWjYNOM2wA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=GiGXcxnkOEKuCL7xiUJ45+oW/RHrW4i+iWqES3wKbwQ=; b=IXc2Pd8s3G0H/N7AhcWAkMBQ1d ofW7akgrWzZnwxfHYJ/fN+zXGzyTBF4AzvHFLEo9UM+T+D29YDr3BEZrBk3ttdroOAKgkMGZT/jx5 hSxJC8O4FvCR0tziu0Axtgv12; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:51212 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1f5BQu-002xKb-7S; Sun, 08 Apr 2018 08:36:40 -0600 To: NetMod WG , NetMod WG Chairs From: Lou Berger Message-ID: Date: Sun, 8 Apr 2018 10:36:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1f5BQu-002xKb-7S X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:51212 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [netmod] Updated minutes available in etherpad -- please review and correct X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 14:36:46 -0000 Hi,     Thanks to Michael, we have updated minutes available for review at https://etherpad.tools.ietf.org/p/notes-ietf-101-netmod  There are still some missing names, so if you made comments, please review and ensure that both your names and comments are properly recorded. Final minutes are due this week, so please review in the next few days (Wednesday if possible -- any TZ) Thank you, Lou (and co-chairs) From nobody Mon Apr 9 03:45:20 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF87E126DCA for ; Mon, 9 Apr 2018 03:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI7ubShnAuR5 for ; Mon, 9 Apr 2018 03:45:15 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AEC2E126BF6 for ; Mon, 9 Apr 2018 03:45:14 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 7C4D11820071; Mon, 9 Apr 2018 12:43:50 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 380BC1820051; Mon, 9 Apr 2018 12:43:48 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Robert Wilton Cc: NetMod WG In-Reply-To: References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> <4c3be475-0b9c-5837-5d08-115201b43305@cisco.com> Mail-Followup-To: Andy Bierman , Robert Wilton , NetMod WG Date: Mon, 09 Apr 2018 12:45:10 +0200 Message-ID: <87in90odzd.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 10:45:18 -0000 Andy Bierman writes: > Hi, > > All of these suggested solutions seem OK if one were looking for the most > disruptive > way to solve the problem. Tossing iana-if-types and starting over would > achieve that result. I think nobody is suggesting to dump iana-if-types, just create an alternative hierarchy of identities. So it's not disruptive at all. > > First, this is a server capabilities problem, so it is related to the > implementation, not the schema. I disagree, it is also a data modelling problem. What's needed is to be able to define parameters that are common to e.g. Ethernet interfaces in one place and let them be inherited by all Ethernet-like interfaces. The flat list of identities - even if the contents was much better than it currently is - allows to do it only in a way that's clumsy and non-scalable. > > Second, the if-types that are allowed at any given moment can be specific > to the implementation > and the interface name. > > I think this is the 3rd time I have suggested an RPC to solve the actual > probem: > > rpc get-allowed-if-types { But this is an ad hoc solution that works only for this particular registry. Lada > description > "Retrieve the interface types allowed by the server."; > input { > leaf name { > type if:interface-ref; > description > "If present, the server will return allowed interface types for > this interface name only. > If not present, then the server will return all supported > interface types."; > } > } > output { > leaf-list type { > type identityref { > base interface-type; > } > description > "Specifies a supported interface type"; > } > } > } > > > Andy > > > On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton wrote: > >> At the moment, I would say that the vast majority of the definitions in >> IANA.yang are just noise because they refer to definitions that are >> obsolete. Our OS seems to use only 10% of the 287+ defined IANA types, and >> that 10% includes technologies such as frame relay, serial, atm, that very >> much seem to be on their way out. >> >> Using hierarchical identities and interface properties seems like a >> reasonable solution to me (e.g. as described in >> draft-wilton-netmod-interface-properties-00). E.g. so rather than having >> configuration with a direct when statement on a specific list of interface >> types, instead the when statement can depend on the appropriate interface >> properties. >> >> I also like Lada's suggestion of trying to spread out the IANA definitions >> to the modules that are defining the technology. So, if a device >> implements support for PPP configuration/operational state then it would >> also naturally define any PPP related interface identities at the same time. >> >> If a vendor wants to define their own flavour of Ethernet interface then >> they can do so in their vendor specific module without requiring all >> tooling to become aware of it, and allowing the existing Ethernet >> configuration to work as normal. >> >> >> >> On 06/04/2018 13:01, Ladislav Lhotka wrote: >> >>> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote: >>> >>>> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: >>>> >>>>> Juergen Schoenwaelder writes: >>>>> >>>>> If we would have a mechanism to deviate an identityref to a subset of >>>>>> identity values supported by an implementation, we would have solved a >>>>>> more generic problem. Yes, the IANA list could be 'nicer' but it will >>>>>> never be 'nice'. >>>>>> >>>>> Three mechanisms can be used for this: >>>>> >>>>> - splitting the identities into separate modules >>>>> >>>> Whatever module organization you come up with, it won't work for all >>>> implementations. >>>> >>> Yes, getting the root of this structure right is perhaps somewhat tricky, >> but I don't think that it needs to be all encompassing, or perfect. >> >> - using features >>>>> >>>> Making every identity a feature will turn the feature system upside >>>> down. This is similar to making every leaf a feature. >>>> >>>> - using deviations (even though vendors frown on them) >>>>> >>>> If my implementation only supports A and B and C, then a deviation may >>>> state exactly that and the problem is solved. Hoping that my specific >>>> >>> In fact, deviations cannot delete identity values because they aren't >>> schema >>> nodes, so they are of no use. >>> >>> combination of A and B and C matches a set of modules or some set of >>>> features is in my view an illusion. >>>> >>> An implementation that supports, say, a given type of tunnel interface >>> will >>> implement the module that covers this tunnel type. If the identity for >>> this >>> tunnel interface type is defined in the same module, then all is good. I >>> don't >>> get why this should be an illusion. On the contrary, I think it is the >>> cleanest >>> available solution to this conformance specification problem. >>> >>> Vendors not shipping proper deviations are essentially telling their >>>> customers that they have not yet understood model driven management. >>>> We need to change the mindset here instead of polluting our data >>>> models with hundreds or thousands of fine grained 'features'. >>>> >>> I agree that zillions of features aren't nice but it seems to be the only >>> solution that we currently have for modules of the iana-if-type style. >>> >>> Having an bulky set of identity values, most of which are of no interest, >>> is IMO >>> much worse and could also be a security issue if implementors aren't >>> careful >>> enough. >>> >> I'm not sure there is a security concern here, but a long list where most >> of the values are cruft doesn't really seem to help anyone. It also makes >> it harder to know which is the right type to use. E.g. will everyone know >> that they should use "ethernetCsmacd" rather than "gigabitEthernet" for an >> optical GE interface that doesn't actually use CSMA/CD ... >> >> Thanks, >> Rob >> >> >> >>> Lada >>> >>> /js >>>> >>>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Apr 9 10:48:12 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFF412D777 for ; Mon, 9 Apr 2018 10:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LY8BkH8PaKjk for ; Mon, 9 Apr 2018 10:48:07 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4387B1200FC for ; Mon, 9 Apr 2018 10:48:07 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id c78-v6so7804498lfh.1 for ; Mon, 09 Apr 2018 10:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=+9wZ9NE6VK1W1iTDbjzIqe/MbYSkNI1Kmc/ya06/6gk=; b=yD80IBgZd2rrldvVqAUTq/AbTD7i/f6Y/oKdyF4UKkEPKI7GmImE2JzePUAxIzv9Ji 5AWprSW50PA1UQdQn9bK+fmBv4zz4RedGzjfG5xm3McnEBYlKqKlP36N6T7F0ScBMDrV L6MrK4nJRgi8zKD7yKPTiByGN0DWPjoudWh1PxSZrdGiZsnRSmdg0d36ywY+7yM8gRGk Zq3tzyxpCTDcfPgWAlRJAgDtl8ITQLb0H2SFmGpkSBRyzxQ7ftlADgCXD9RyVQNynxt3 Mv4CyCwc6i9VUj6cWjfqxUba8zWb6Ta8Q6I8zjUotlEZ527Q+7peEI73fYxJ0chce3tZ utvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=+9wZ9NE6VK1W1iTDbjzIqe/MbYSkNI1Kmc/ya06/6gk=; b=JZ3jyYLBwUpTNokxZAkTGfula/x9++cCegmlz4W7+6qSUKjwkpOdAdT83RZQN5cyke JqFSJ7YRRGRWpVlSjJ1DDgjWPGEGtxkVnFv+LxzMk0rEuUNzKAZ8lbsOEMjEZ4UBuDF2 h2c34tRqhNikCdEc8wVo2Nyd2YmOYjTqduS4TdGn92xrJa2AY23rQ/oFxxUnDWz5Qf2j GVtlWtgm5Kj3w8o4L3g4yuyN1QL39TXT4xp30xSv+xJPC/jgPALWrkcIvgz6AzwdaE1Z zHLd7+/SCxnhKw46af3Yc/w2A+RtEbPGP1ds9pr2P6eXBtooFEFTQRsVb3X+X+RSi48J MJvQ== X-Gm-Message-State: ALQs6tCAVyAPq5vphnDShsqu5P5wk6iq4hHzQBKhYcC6biZ5rO01gct7 VsvIMWONInVLlLH7Avq4HVKIleY+0KwBKfgVkSyykA== X-Google-Smtp-Source: AIpwx4/s+esdosqC4Nhrh4MB1VN2qdyg4hEVTH/D3LO4D2bGyapLYj+9f6+fjOy8FwB1/XAit3SuYAR+G3D9pYqKQMA= X-Received: by 2002:a19:101a:: with SMTP id f26-v6mr23383232lfi.42.1523296085386; Mon, 09 Apr 2018 10:48:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:5149:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 10:48:04 -0700 (PDT) In-Reply-To: <87in90odzd.fsf@nic.cz> References: <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> <4c3be475-0b9c-5837-5d08-115201b43305@cisco.com> <87in90odzd.fsf@nic.cz> From: Andy Bierman Date: Mon, 9 Apr 2018 10:48:04 -0700 Message-ID: To: Andy Bierman , Robert Wilton , NetMod WG Content-Type: multipart/alternative; boundary="0000000000000ec27c05696e02f5" Archived-At: Subject: Re: [netmod] An abundant amount of IANA if types... X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 17:48:11 -0000 --0000000000000ec27c05696e02f5 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 9, 2018 at 3:45 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > Hi, > > > > All of these suggested solutions seem OK if one were looking for the most > > disruptive > > way to solve the problem. Tossing iana-if-types and starting over would > > achieve that result. > > I think nobody is suggesting to dump iana-if-types, just create an > alternative hierarchy of identities. So it's not disruptive at all. > > I guess we really disagree on the nature of the problem that needs to be solved. Since the "type" leaf and existing identities cannot be changed, then it seems you are suggesting an entire new set of identities. So servers will need to handle the old identities and the new ones. Not disruptive, but not helpful either. At the end of all of this work, the client will still be unable to answer the question "What identities are allowed for interface X on server Y, right now?" I don't see how rearranging the identities lets the client know what identities a server will accept to create or modify a particular interface. Andy > > > First, this is a server capabilities problem, so it is related to the > > implementation, not the schema. > > I disagree, it is also a data modelling problem. What's needed is to be > able to define parameters that are common to e.g. Ethernet interfaces in > one place and let them be inherited by all Ethernet-like interfaces. The > flat list of identities - even if the contents was much better than it > currently is - allows to do it only in a way that's clumsy and > non-scalable. > > > > > Second, the if-types that are allowed at any given moment can be specific > > to the implementation > > and the interface name. > > > > I think this is the 3rd time I have suggested an RPC to solve the actual > > probem: > > > > rpc get-allowed-if-types { > > But this is an ad hoc solution that works only for this particular > registry. > > Lada > > > description > > "Retrieve the interface types allowed by the server."; > > input { > > leaf name { > > type if:interface-ref; > > description > > "If present, the server will return allowed interface types > for > > this interface name only. > > If not present, then the server will return all supported > > interface types."; > > } > > } > > output { > > leaf-list type { > > type identityref { > > base interface-type; > > } > > description > > "Specifies a supported interface type"; > > } > > } > > } > > > > > > Andy > > > > > > On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton wrote: > > > >> At the moment, I would say that the vast majority of the definitions in > >> IANA.yang are just noise because they refer to definitions that are > >> obsolete. Our OS seems to use only 10% of the 287+ defined IANA types, > and > >> that 10% includes technologies such as frame relay, serial, atm, that > very > >> much seem to be on their way out. > >> > >> Using hierarchical identities and interface properties seems like a > >> reasonable solution to me (e.g. as described in > >> draft-wilton-netmod-interface-properties-00). E.g. so rather than > having > >> configuration with a direct when statement on a specific list of > interface > >> types, instead the when statement can depend on the appropriate > interface > >> properties. > >> > >> I also like Lada's suggestion of trying to spread out the IANA > definitions > >> to the modules that are defining the technology. So, if a device > >> implements support for PPP configuration/operational state then it would > >> also naturally define any PPP related interface identities at the same > time. > >> > >> If a vendor wants to define their own flavour of Ethernet interface then > >> they can do so in their vendor specific module without requiring all > >> tooling to become aware of it, and allowing the existing Ethernet > >> configuration to work as normal. > >> > >> > >> > >> On 06/04/2018 13:01, Ladislav Lhotka wrote: > >> > >>> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote: > >>> > >>>> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: > >>>> > >>>>> Juergen Schoenwaelder writes: > >>>>> > >>>>> If we would have a mechanism to deviate an identityref to a subset of > >>>>>> identity values supported by an implementation, we would have > solved a > >>>>>> more generic problem. Yes, the IANA list could be 'nicer' but it > will > >>>>>> never be 'nice'. > >>>>>> > >>>>> Three mechanisms can be used for this: > >>>>> > >>>>> - splitting the identities into separate modules > >>>>> > >>>> Whatever module organization you come up with, it won't work for all > >>>> implementations. > >>>> > >>> Yes, getting the root of this structure right is perhaps somewhat > tricky, > >> but I don't think that it needs to be all encompassing, or perfect. > >> > >> - using features > >>>>> > >>>> Making every identity a feature will turn the feature system upside > >>>> down. This is similar to making every leaf a feature. > >>>> > >>>> - using deviations (even though vendors frown on them) > >>>>> > >>>> If my implementation only supports A and B and C, then a deviation may > >>>> state exactly that and the problem is solved. Hoping that my specific > >>>> > >>> In fact, deviations cannot delete identity values because they aren't > >>> schema > >>> nodes, so they are of no use. > >>> > >>> combination of A and B and C matches a set of modules or some set of > >>>> features is in my view an illusion. > >>>> > >>> An implementation that supports, say, a given type of tunnel interface > >>> will > >>> implement the module that covers this tunnel type. If the identity for > >>> this > >>> tunnel interface type is defined in the same module, then all is good. > I > >>> don't > >>> get why this should be an illusion. On the contrary, I think it is the > >>> cleanest > >>> available solution to this conformance specification problem. > >>> > >>> Vendors not shipping proper deviations are essentially telling their > >>>> customers that they have not yet understood model driven management. > >>>> We need to change the mindset here instead of polluting our data > >>>> models with hundreds or thousands of fine grained 'features'. > >>>> > >>> I agree that zillions of features aren't nice but it seems to be the > only > >>> solution that we currently have for modules of the iana-if-type style. > >>> > >>> Having an bulky set of identity values, most of which are of no > interest, > >>> is IMO > >>> much worse and could also be a security issue if implementors aren't > >>> careful > >>> enough. > >>> > >> I'm not sure there is a security concern here, but a long list where > most > >> of the values are cruft doesn't really seem to help anyone. It also > makes > >> it harder to know which is the right type to use. E.g. will everyone > know > >> that they should use "ethernetCsmacd" rather than "gigabitEthernet" for > an > >> optical GE interface that doesn't actually use CSMA/CD ... > >> > >> Thanks, > >> Rob > >> > >> > >> > >>> Lada > >>> > >>> /js > >>>> > >>>> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > --0000000000000ec27c05696e02f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 9, 2018 at 3:45 AM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> Hi,
>
> All of these suggested solutions seem OK if one were looking for the m= ost
> disruptive
> way to solve the problem.=C2=A0 Tossing iana-if-types and starting ove= r would
> achieve that result.

I think nobody is suggesting to dump iana-if-types, just create an
alternative hierarchy of identities. So it's not disruptive at all.



I guess we really disag= ree on the nature of the problem that needs to be solved.
Since t= he "type" leaf and existing identities cannot be changed,
then it seems you are suggesting an entire new set of identities.
<= div>So servers will need to handle the old identities and the new ones.
Not disruptive, but not helpful either.

At = the end of all of this work, the client will
still be unable to a= nswer the question "What identities are allowed
for interfac= e X on server Y, right now?"

I don't see = how rearranging the identities lets the client know
what identiti= es a server will accept to create or modify a particular interface.


Andy


>
> First, this is a server capabilities problem, so it is related to the<= br> > implementation, not the schema.

I disagree, it is also a data modelling problem. What's needed is to be=
able to define parameters that are common to e.g. Ethernet interfaces in one place and let them be inherited by all Ethernet-like interfaces. The flat list of identities - even if the contents was much better than it
currently is - allows to do it only in a way that's clumsy and
non-scalable.

>
> Second, the if-types that are allowed at any given moment can be speci= fic
> to the implementation
> and the interface name.
>
> I think this is the 3rd time I have suggested an RPC to solve the actu= al
> probem:
>
>=C2=A0 =C2=A0rpc get-allowed-if-types {

But this is an ad hoc solution that works only for this particular
registry.

Lada

>=C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"Retrieve the interface types allowed b= y the server.";
>=C2=A0 =C2=A0 =C2=A0input {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf name {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type if:interface-ref;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"If present, the s= erver will return allowed interface types for
> this interface name only.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If not present, then t= he server will return all supported
> interface types.";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 output {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf-list type {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type identityref {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 base interface-= type;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Specifies = a supported interface type";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 }
>
>
> Andy
>
>
> On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton <rwilton@cisco.com> wrote:
>
>> At the moment, I would say that the vast majority of the definitio= ns in
>> IANA.yang are just noise because they refer to definitions that ar= e
>> obsolete.=C2=A0 Our OS seems to use only 10% of the 287+ defined I= ANA types, and
>> that 10% includes technologies such as frame relay, serial, atm, t= hat very
>> much seem to be on their way out.
>>
>> Using hierarchical identities and interface properties seems like = a
>> reasonable solution to me (e.g. as described in
>> draft-wilton-netmod-interface-properties-00).=C2=A0 E.g. so r= ather than having
>> configuration with a direct when statement on a specific list of i= nterface
>> types, instead the when statement can depend on the appropriate in= terface
>> properties.
>>
>> I also like Lada's suggestion of trying to spread out the IANA= definitions
>> to the modules that are defining the technology.=C2=A0 So, if a de= vice
>> implements support for PPP configuration/operational state then it= would
>> also naturally define any PPP related interface identities at the = same time.
>>
>> If a vendor wants to define their own flavour of Ethernet interfac= e then
>> they can do so in their vendor specific module without requiring a= ll
>> tooling to become aware of it, and allowing the existing Ethernet<= br> >> configuration to work as normal.
>>
>>
>>
>> On 06/04/2018 13:01, Ladislav Lhotka wrote:
>>
>>> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote= :
>>>
>>>> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka = wrote:
>>>>
>>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&g= t; writes:
>>>>>
>>>>> If we would have a mechanism to deviate an identityref= to a subset of
>>>>>> identity values supported by an implementation, we= would have solved a
>>>>>> more generic problem. Yes, the IANA list could be = 'nicer' but it will
>>>>>> never be 'nice'.
>>>>>>
>>>>> Three mechanisms can be used for this:
>>>>>
>>>>> - splitting the identities into separate modules
>>>>>
>>>> Whatever module organization you come up with, it won'= t work for all
>>>> implementations.
>>>>
>>> Yes, getting the root of this structure right is perhaps somew= hat tricky,
>> but I don't think that it needs to be all encompassing, or per= fect.
>>
>> - using features
>>>>>
>>>> Making every identity a feature will turn the feature syst= em upside
>>>> down. This is similar to making every leaf a feature.
>>>>
>>>> - using deviations (even though vendors frown on them)
>>>>>
>>>> If my implementation only supports A and B and C, then a d= eviation may
>>>> state exactly that and the problem is solved. Hoping that = my specific
>>>>
>>> In fact, deviations cannot delete identity values because they= aren't
>>> schema
>>> nodes, so they are of no use.
>>>
>>> combination of A and B and C matches a set of modules or some = set of
>>>> features is in my view an illusion.
>>>>
>>> An implementation that supports, say, a given type of tunnel i= nterface
>>> will
>>> implement the module that covers this tunnel type. If the iden= tity for
>>> this
>>> tunnel interface type is defined in the same module, then all = is good. I
>>> don't
>>> get why this should be an illusion. On the contrary, I think i= t is the
>>> cleanest
>>> available solution to this conformance specification problem.<= br> >>>
>>> Vendors not shipping proper deviations are essentially telling= their
>>>> customers that they have not yet understood model driven m= anagement.
>>>> We need to change the mindset here instead of polluting ou= r data
>>>> models with hundreds or thousands of fine grained 'fea= tures'.
>>>>
>>> I agree that zillions of features aren't nice but it seems= to be the only
>>> solution that we currently have for modules of the iana-if-typ= e style.
>>>
>>> Having an bulky set of identity values, most of which are of n= o interest,
>>> is IMO
>>> much worse and could also be a security issue if implementors = aren't
>>> careful
>>> enough.
>>>
>> I'm not sure there is a security concern here, but a long list= where most
>> of the values are cruft doesn't really seem to help anyone.=C2= =A0 It also makes
>> it harder to know which is the right type to use.=C2=A0 E.g. will = everyone know
>> that they should use "ethernetCsmacd" rather than "= gigabitEthernet" for an
>> optical GE interface that doesn't actually use CSMA/CD ...
>>
>> Thanks,
>> Rob
>>
>>
>>
>>> Lada
>>>
>>> /js
>>>>
>>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netm= od
>>

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

--0000000000000ec27c05696e02f5-- From nobody Tue Apr 10 01:30:50 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AF31200C5 for ; Tue, 10 Apr 2018 01:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGDC4iz1cURl for ; Tue, 10 Apr 2018 01:30:44 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344371200A0 for ; Tue, 10 Apr 2018 01:30:44 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id ADCD72EF03530 for ; Tue, 10 Apr 2018 09:30:40 +0100 (IST) Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 10 Apr 2018 09:30:41 +0100 Received: from DGGEML507-MBS.china.huawei.com ([169.254.1.253]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0361.001; Tue, 10 Apr 2018 16:30:33 +0800 From: Jiangyuanlong To: "netmod@ietf.org" Thread-Topic: Using augment to overwrite an existing definition? Thread-Index: AdPQpjB2E1tfx0O3TOmjVHxd8wcniA== Date: Tue, 10 Apr 2018 08:30:33 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBE12@dggeml507-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.202.215] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBE12dggeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] Using augment to overwrite an existing definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 08:30:49 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBE12dggeml507mbschi_ Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: quoted-printable Folks, We are developing a YANG module for IEEE 1588, which is already a WG draft,= please see https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-07. The base module defines a leaf node +IBg-two-step-flag+IBk- and tags it as = read-write, but some applications may want to remodel it as read-only. The following is the codes I tried: module ptp-augment +AHs- namespace +ACI-urn:example:ptp-augment+ACIAOw- prefix ptp-ag+ADs- import ietf-ptp +AHs- prefix ptp+ADs- +AH0- augment /ptp:ptp/ptp:instance-list/ptp:default-ds +AHs- leaf two-step-flag +AHs- config false+ADs- type boolean+ADs- description +ACI-When set, the clock is a two-step clock+ADs- otherwise, the clock is a one-step clock.+ACIAOw- +AH0- +AH0- +AH0- The codes are validated to be right by http://www.yangvalidator.com/validat= or. My question is: By using +IBg-augment+IBk-, two leaf nodes are defined succ= essfully with the same YANG identifier but with different behaviors (also a= pplicable to different types), does the new definition take the precedence = and overwrite its old definition? If the answer is yes, I will be glad to use this YANG feature, but perhaps = it makes sense that a YANG compiler emits a warning that a new definition o= verrides an existing one. Or, are two leaf nodes defined exactly? How do we distinguish them? I also tried to use +IBg-deviation+IBk- instead, the following is the codes= : module ptp-deviations +AHs- namespace +ACI-urn:example:ptp-deviations+ACIAOw- prefix ptpd+ADs- import ietf-ptp +AHs- prefix ptp+ADs- +AH0- deviation /ptp:ptp/ptp:instance-list/ptp:default-ds/ptp:two-step-fla= g +AHs- deviate replace +AHs- config false+ADs- +AH0- +AH0- +AH0- The codes are also validated to be right by http://www.yangvalidator.com/va= lidator. My concern is, it cannot add new leaf nodes, so inevitably, another augment= will always be used. Any thoughts? Thanks, Yuanlong --_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBE12dggeml507mbschi_ Content-Type: text/html; charset="utf-7" Content-Transfer-Encoding: quoted-printable +ADw-html xmlns:v+AD0AIg-urn:schemas-microsoft-com:vml+ACI- xmlns:o+AD0AIg-= urn:schemas-microsoft-com:office:office+ACI- xmlns:w+AD0AIg-urn:schemas-mic= rosoft-com:office:word+ACI- xmlns:m+AD0AIg-http://schemas.microsoft.com/off= ice/2004/12/omml+ACI- xmlns+AD0AIg-http://www.w3.org/TR/REC-html40+ACIAPg- +ADw-head+AD4- +ADw-meta name+AD0AIg-Generator+ACI- content+AD0AIg-Microsoft Word 12 (filt= ered medium)+ACIAPg- +ADw-style+AD4- +ADwAIQ--- /+ACo- Font Definitions +ACo-/ +AEA-font-face +AHs-font-family:+W4tPUwA7- panose-1:2 1 6 0 3 1 1 1 1 1+ADsAfQ- +AEA-font-face +AHs-font-family:+ACI-Cambria Math+ACIAOw- panose-1:2 4 5 3 5 4 6 3 2 4+ADsAfQ- +AEA-font-face +AHs-font-family:Calibri+ADs- panose-1:2 15 5 2 2 2 4 3 2 4+ADsAfQ- +AEA-font-face +AHs-font-family:+ACIAXABAW4tPUwAiADs- panose-1:2 1 6 0 3 1 1 1 1 1+ADsAfQ- /+ACo- Style Definitions +ACo-/ p.MsoNormal, li.MsoNormal, div.MsoNormal +AHs-margin:0cm+ADs- margin-bottom:.0001pt+ADs- font-size:12.0pt+ADs- font-family:+ACI-Times New Roman+ACI-,+ACI-serif+ACIAOwB9- a:link, span.MsoHyperlink +AHs-mso-style-priority:99+ADs- color:blue+ADs- text-decoration:underline+ADsAfQ- a:visited, span.MsoHyperlinkFollowed +AHs-mso-style-priority:99+ADs- color:purple+ADs- text-decoration:underline+ADsAfQ- span.EmailStyle17 +AHs-mso-style-type:personal-compose+ADs- font-family:+ACI-Calibri+ACI-,+ACI-sans-serif+ACIAOw- color:windowtext+ADsAfQ- .MsoChpDefault +AHs-mso-style-type:export-only+ADsAfQ- /+ACo- Page Definitions +ACo-/ +AEA-page WordSection1 +AHs-size:612.0pt 792.0pt+ADs- margin:72.0pt 90.0pt 72.0pt 90.0pt+ADsAfQ- div.WordSection1 +AHs-page:WordSection1+ADsAfQ- --+AD4- +ADw-/style+AD4APAAh---+AFs-if gte mso 9+AF0APgA8-xml+AD4- +ADw-o:shapedefaults v:ext+AD0AIg-edit+ACI- spidmax+AD0AIg-1026+ACI- /+AD4= - +ADw-/xml+AD4APAAhAFs-endif+AF0---+AD4APAAh---+AFs-if gte mso 9+AF0APgA8-xm= l+AD4- +ADw-o:shapelayout v:ext+AD0AIg-edit+ACIAPg- +ADw-o:idmap v:ext+AD0AIg-edit+ACI- data+AD0AIg-1+ACI- /+AD4- +ADw-/o:shapelayout+AD4APA-/xml+AD4APAAhAFs-endif+AF0---+AD4- +ADw-/head+AD4- +ADw-body lang+AD0AIg-ZH-CN+ACI- link+AD0AIg-blue+ACI- vlink+AD0AIg-purple+= ACI- style+AD0AIg-text-justify-trim:punctuation+ACIAPg- +ADw-div class+AD0AIg-WordSection1+ACIAPg- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-Folks,+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+= AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-We are developing a YANG module for IEEE 1588, whi= ch is already a WG draft, please see +ADw-a href+AD0AIg-https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yan= g-07+ACIAPg-https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-07+AD= w-/a+AD4-.+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-The base module defines a leaf node +IBg-two-step-= flag+IBk- and tags it as read-write, but some applications may want to remo= del it as read-only.+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-The following is the codes I tried: +ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPg-module ptp-augment +AHsAPA-o:p+AD4APA-/o:p+AD4AP= A-/span+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- namespace +A= CY-quot+ADs-urn:example:ptp-augment+ACY-quot+ADsAOwA8-o:p+AD4APA-/o:p+AD4AP= A-/span+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- prefix ptp-a= g+ADsAPA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4AP= A-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- import ietf-= ptp +AHsAPA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- prefix ptp+ADsAPA-o:p+AD4APA-/o:p+AD4AP= A-/span+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +AH0APA-o:p+= AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4AP= A-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- augment /ptp= :ptp/ptp:instance-list/ptp:default-ds +AHsAPA-o:p+AD4APA-/o:p+AD4APA-/span+= AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- lea= f two-step-flag +AHsAPA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4APA-/p+AD= 4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-n= bsp+ADsAJg-nbsp+ADs- config false+ADsAPA-o:p+AD4APA-/o:p+AD4APA-/span+AD4AP= A-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-n= bsp+ADsAJg-nbsp+ADs- type boolean+ADsAPA-o:p+AD4APA-/o:p+AD4APA-/span+AD4AP= A-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-n= bsp+ADsAJg-nbsp+ADs- description+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i= +AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-n= bsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +ACY-quot+ADs-When set, the cl= ock is a two-step clock+ADs- otherwise,+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD= 4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-n= bsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- the clock is a one= -step clock.+ACY-quot+ADsAOwA8-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4AP= A-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +AH= 0APA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4AP= A-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACI- style+AD0AIg-text-indent:21.0pt+ACIAPgA8= -i+AD4APA-span lang+AD0AIg-EN-US+ACI- style+AD0AIg-font-size:10.5pt+ADs-fon= t-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-q= uot+ADsAOw-color:+ACM-1F497D+ACIAPgB9ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4AP= A-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgB9ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4A= PA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-The codes are validated to be right by +ADw-a href+AD0AIg-http://www.yangvalidator.com/validator+ACIAPg-http://www= .yangvalidator.com/validator+ADw-/a+AD4-.+ADw-o:p+AD4APA-/o:p+AD4APA-/span+= AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-My question is: By using +IBg-augment+IBk-, two le= af nodes are defined successfully with the same YANG identifier but with di= fferent behaviors (also applicable to different types), does the new definition take the precedenc= e and overwrite its old definition? +ACY-nbsp+ADsAPA-o:p+AD4APA-/o:p+AD4APA= -/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-If the answer is yes, I will be glad to use this Y= ANG feature, but perhaps it makes sense that a YANG compiler emits a warnin= g that a new definition overrides an existing one.+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-Or, are two leaf nodes defined exactly? How do we = distinguish them?+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-I also tried to use +IBg-deviation+IBk- instead, t= he following is the codes:+ADw-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4APA-= /p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- = module ptp-deviations +AHsAPA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4APA= -/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADs- namespace +ACY-quot+ADs-urn:example:ptp-deviations+= ACY-quot+ADsAOwA8-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADs- prefix ptpd+ADsAPA-o:p+AD4APA-/o:p+AD4APA-/span+AD4= APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4AP= A-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADs- import ietf-ptp +AHsAPA-o:p+AD4APA-/o:p+AD4APA-/spa= n+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- prefix ptp+ADsAPA-o:p+AD4AP= A-/o:p+AD4APA-/span+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADs- +AH0APA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4A= PA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4AP= A-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADs- deviation /ptp:ptp/ptp:instance-list/ptp:default-ds= /ptp:two-step-flag +AHsAPA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4APA-/p= +AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- dev= iate replace +AHsAPA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-n= bsp+ADsAJg-nbsp+ADs- config false+ADsAPA-o:p+AD4APA-/o:p+AD4APA-/span+AD4AP= A-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- +AH= 0APA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADs- +AH0APA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4A= PA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgA8-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD4APA-/span+AD4AP= A-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-i+AD4APA-span lang+AD0AIg-EN-US+ACI-= style+AD0AIg-font-size:10.5pt+ADs-font-family: +ACY-quot+ADs-Calibri+ACY-quot+ADs-,+ACY-quot+ADs-sans-serif+ACY-quot+ADsAO= w-color:+ACM-1F497D+ACIAPgAm-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- = +AH0APA-o:p+AD4APA-/o:p+AD4APA-/span+AD4APA-/i+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-The codes are also validated to be right by +ADw-a href+AD0AIg-http://www.yangvalidator.com/validator+ACIAPg-http://www= .yangvalidator.com/validator+ADw-/a+AD4-.+ADw-o:p+AD4APA-/o:p+AD4APA-/span+= AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAOw- color:+ACM-1F497D+ACIAPg-My concern is, it cannot add new leaf nodes, so in= evitably, another augment will always be used.+ADw-o:p+AD4APA-/o:p+AD4APA-/= span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAIgA+ADw-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD= 4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAIgA+-Any thoughts?+ADw-o:p+AD4APA-/o:p= +AD4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAIgA+ADw-o:p+AD4AJg-nbsp+ADsAPA-/o:p+AD= 4APA-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAIgA+-Thanks,+ADw-o:p+AD4APA-/o:p+AD4AP= A-/span+AD4APA-/p+AD4- +ADw-p class+AD0AIg-MsoNormal+ACIAPgA8-span lang+AD0AIg-EN-US+ACI- style+AD= 0AIg-font-size:10.5pt+ADs-font-family:+ACY-quot+ADs-Calibri+ACY-quot+ADs-,+= ACY-quot+ADs-sans-serif+ACY-quot+ADsAIgA+-Yuanlong+ADw-o:p+AD4APA-/o:p+AD4A= PA-/span+AD4APA-/p+AD4- +ADw-/div+AD4- +ADw-/body+AD4- +ADw-/html+AD4- --_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBE12dggeml507mbschi_-- From nobody Tue Apr 10 01:58:01 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC2F1273E2 for ; Tue, 10 Apr 2018 01:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E1jPVwq7ZPc for ; Tue, 10 Apr 2018 01:57:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E81F512420B for ; Tue, 10 Apr 2018 01:57:56 -0700 (PDT) Received: from [10.147.40.111] (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id 2B65A1AE00A0; Tue, 10 Apr 2018 10:57:55 +0200 (CEST) From: Jan Lindblad Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AAA4D06C-CCF5-4992-8613-0D6876603576" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 10 Apr 2018 10:57:53 +0200 In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBE12@dggeml507-mbs.china.huawei.com> Cc: "netmod@ietf.org" To: Jiangyuanlong References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBE12@dggeml507-mbs.china.huawei.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] Using augment to overwrite an existing definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 08:58:00 -0000 --Apple-Mail=_AAA4D06C-CCF5-4992-8613-0D6876603576 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yuanlong, Both approaches you describe are technically valid, but I don't like = either of them much. When you augment another "leaf two-step-flag" (from a different module) = into the same parent you will end up with *both* leafs. They will have = the same local-name, but different namespaces. For the average user, = this will likely be highly confusing. I also don't like when standards bodies are playing with deviations. = They are meant to be a last resort for implementors that are unable to = follow a standard. If a standard requires the use of deviations, the = value of the standard is diluted. And if an implementor would want to = deviate from the standard, how would he deviate from the deviation? Instead, I'd propose that you model this as two leafs with different = names, one config false and one config true. The config true leaf may = depend on a feature. Btw, the current definition of the leaf two-step-flag defines no default = value and does not declare the leaf mandatory. This opens up for an = undefined case. If the two-step-flag is true, it's a two-step clock. If = false, one-step. But what if an implementation doesn't return the = two-step-leaf at all? There is no requirement per the YANG to return = this leaf, and no language as to what that would mean. /jan > We are developing a YANG module for IEEE 1588, which is already a WG = draft, please see = https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-07 = . > The base module defines a leaf node =E2=80=98two-step-flag=E2=80=99 = and tags it as read-write, but some applications may want to remodel it = as read-only. > The following is the codes I tried: > module ptp-augment { > namespace "urn:example:ptp-augment"; > prefix ptp-ag; > =20 > import ietf-ptp { > prefix ptp; > } > =20 > augment /ptp:ptp/ptp:instance-list/ptp:default-ds { > leaf two-step-flag { > config false; > type boolean; > description > "When set, the clock is a two-step clock; otherwise, > the clock is a one-step clock."; > } > =20 > } > } > The codes are validated to be right by = http://www..yangvalidator.com/validator = . > My question is: By using =E2=80=98augment=E2=80=99, two leaf nodes are = defined successfully with the same YANG identifier but with different = behaviors (also applicable to different types), does the new definition = take the precedence and overwrite its old definition? =20 > If the answer is yes, I will be glad to use this YANG feature, but = perhaps it makes sense that a YANG compiler emits a warning that a new = definition overrides an existing one. > Or, are two leaf nodes defined exactly? How do we distinguish them? > =20 > I also tried to use =E2=80=98deviation=E2=80=99 instead, the following = is the codes: > =20 > module ptp-deviations { > namespace "urn:example:ptp-deviations"; > prefix ptpd; > =20 > import ietf-ptp { > prefix ptp; > } > =20 > deviation = /ptp:ptp/ptp:instance-list/ptp:default-ds/ptp:two-step-flag { > deviate replace { > config false; > } > } > =20 > } > The codes are also validated to be right by = http://www..yangvalidator.com/validator = . > My concern is, it cannot add new leaf nodes, so inevitably, another = augment will always be used. > =20 > Any thoughts? > =20 > Thanks, > Yuanlong > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_AAA4D06C-CCF5-4992-8613-0D6876603576 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yuanlong,

Both approaches you describe are technically valid, but I = don't like either of them much.

When you augment another "leaf = two-step-flag" (from a different module) into the same parent you will = end up with *both* leafs. They will have the same local-name, but = different namespaces. For the average user, this will likely be highly = confusing.

I = also don't like when standards bodies are playing with deviations. They = are meant to be a last resort for implementors that are unable to follow = a standard. If a standard requires the use of deviations, the value of = the standard is diluted. And if an implementor would want to deviate = from the standard, how would he deviate from the deviation?

Instead, I'd propose = that you model this as two leafs with different names, one config false = and one config true. The config true leaf may depend on a = feature.

Btw, = the current definition of the leaf two-step-flag defines no default = value and does not declare the leaf mandatory. This opens up for an = undefined case. If the two-step-flag is true, it's a two-step clock. If = false, one-step. But what if an implementation doesn't return the = two-step-leaf at all? There is no requirement per the YANG to return = this leaf, and no language as to what that would mean.

/jan



We are = developing a YANG module for IEEE 1588, which is already a WG draft, = please see https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-07.
The= base module defines a leaf node =E2=80=98two-step-flag=E2=80=99 and = tags it as read-write, but some applications may want to remodel it as = read-only.
The= following is the codes I tried:
module ptp-augment = {
    namespace "urn:example:ptp-augment";
    prefix ptp-ag;
 
    = import ietf-ptp {
        prefix ptp;
    }
 
    augment = /ptp:ptp/ptp:instance-list/ptp:default-ds {
           = leaf two-step-flag {
          &nb= sp;  config false;
          &nb= sp;  type boolean;
          &nb= sp;  description
          &nb= sp;    "When set, the clock is a two-step clock; = otherwise,
          &nb= sp;     the clock is a one-step clock.";
           = }
 
}
}
The codes are validated to be right by http://www..yangvalidator.com/validator.
My question = is: By using =E2=80=98augment=E2=80=99, two leaf nodes are defined = successfully with the same YANG identifier but with different behaviors = (also applicable to different types), does the new definition take the = precedence and overwrite its old definition?  
If the answer = is yes, I will be glad to use this YANG feature, but perhaps it makes = sense that a YANG compiler emits a warning that a new definition = overrides an existing one.
Or, are two leaf nodes defined exactly? = How do we distinguish them?
 
I = also tried to use =E2=80=98deviation=E2=80=99 instead, the following is = the codes:
 
     module = ptp-deviations {
       namespace = "urn:example:ptp-deviations";
       prefix ptpd;
 
       import ietf-ptp {
         prefix = ptp;
       }
 
       deviation = /ptp:ptp/ptp:instance-list/ptp:default-ds/ptp:two-step-flag {
           = deviate replace {
          &nb= sp;  config false;
           = }
       }
 
     = }
The= codes are also validated to be right by http://www..yangvalidator.com/validator.
My concern is, = it cannot add new leaf nodes, so inevitably, another augment will always = be used.
 
Any thoughts?
 
Thanks,
Yuanlong
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_AAA4D06C-CCF5-4992-8613-0D6876603576-- From nobody Tue Apr 10 02:45:22 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BFA127369 for ; Tue, 10 Apr 2018 02:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk8FIHV4sweP for ; Tue, 10 Apr 2018 02:45:17 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D18124B18 for ; Tue, 10 Apr 2018 02:45:17 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 57F0889283752 for ; Tue, 10 Apr 2018 10:45:13 +0100 (IST) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 10 Apr 2018 10:45:14 +0100 Received: from DGGEML507-MBS.china.huawei.com ([169.254.1.253]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0361.001; Tue, 10 Apr 2018 17:45:03 +0800 From: Jiangyuanlong To: Jan Lindblad CC: "netmod@ietf.org" Thread-Topic: [netmod] Using augment to overwrite an existing definition? Thread-Index: AdPQpjB2E1tfx0O3TOmjVHxd8wcniP//gYeA//93BPA= Date: Tue, 10 Apr 2018 09:45:02 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBEB0@dggeml507-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBE12@dggeml507-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.202.215] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBEB0dggeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Using augment to overwrite an existing definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 09:45:21 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBEB0dggeml507mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFuLA0KDQpUaGFuayBhIGxvdCBmb3IgeW91ciBwcm9tcHQgZmVlZGJhY2suIFBsZWFzZSBzZWUg bXkgY29tbWVudHMgaW5saW5lLg0KDQpDaGVlcnMsDQpZdWFubG9uZw0KDQpGcm9tOiBKYW4gTGlu ZGJsYWQgW21haWx0bzpqYW5sQHRhaWwtZi5jb21dDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxMCwg MjAxOCA0OjU4IFBNDQpUbzogSmlhbmd5dWFubG9uZw0KQ2M6IG5ldG1vZEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtuZXRtb2RdIFVzaW5nIGF1Z21lbnQgdG8gb3ZlcndyaXRlIGFuIGV4aXN0aW5n IGRlZmluaXRpb24/DQoNCll1YW5sb25nLA0KDQpCb3RoIGFwcHJvYWNoZXMgeW91IGRlc2NyaWJl IGFyZSB0ZWNobmljYWxseSB2YWxpZCwgYnV0IEkgZG9uJ3QgbGlrZSBlaXRoZXIgb2YgdGhlbSBt dWNoLg0KDQpXaGVuIHlvdSBhdWdtZW50IGFub3RoZXIgImxlYWYgdHdvLXN0ZXAtZmxhZyIgKGZy b20gYSBkaWZmZXJlbnQgbW9kdWxlKSBpbnRvIHRoZSBzYW1lIHBhcmVudCB5b3Ugd2lsbCBlbmQg dXAgd2l0aCAqYm90aCogbGVhZnMuIFRoZXkgd2lsbCBoYXZlIHRoZSBzYW1lIGxvY2FsLW5hbWUs IGJ1dCBkaWZmZXJlbnQgbmFtZXNwYWNlcy4gRm9yIHRoZSBhdmVyYWdlIHVzZXIsIHRoaXMgd2ls bCBsaWtlbHkgYmUgaGlnaGx5IGNvbmZ1c2luZy4NCltZdWFubG9uZ10gQWdyZWVkLiBNeSBmaXJz dCBndWVzcyB3YXMgYWxzbyB0byB1c2UgbmFtZXNwYWNlcy4NCg0KSSBhbHNvIGRvbid0IGxpa2Ug d2hlbiBzdGFuZGFyZHMgYm9kaWVzIGFyZSBwbGF5aW5nIHdpdGggZGV2aWF0aW9ucy4gVGhleSBh cmUgbWVhbnQgdG8gYmUgYSBsYXN0IHJlc29ydCBmb3IgaW1wbGVtZW50b3JzIHRoYXQgYXJlIHVu YWJsZSB0byBmb2xsb3cgYSBzdGFuZGFyZC4gSWYgYSBzdGFuZGFyZCByZXF1aXJlcyB0aGUgdXNl IG9mIGRldmlhdGlvbnMsIHRoZSB2YWx1ZSBvZiB0aGUgc3RhbmRhcmQgaXMgZGlsdXRlZC4gQW5k IGlmIGFuIGltcGxlbWVudG9yIHdvdWxkIHdhbnQgdG8gZGV2aWF0ZSBmcm9tIHRoZSBzdGFuZGFy ZCwgaG93IHdvdWxkIGhlIGRldmlhdGUgZnJvbSB0aGUgZGV2aWF0aW9uPw0KW1l1YW5sb25nXSB3 ZSBhcmUgbm90IHRhcmdldGluZyB0byB1c2UgdGhlc2UgY29kZXMgaW4gb3VyIHN0YW5kYXJkcywg YnV0IHRyeWluZyB0byBzaW11bGF0ZSBzb21lIHBvc3NpYmxlIGRlcml2ZWQgaW1wbGVtZW50YXRp b25zLiBJbiB0aGUgcGFzdCwgdGhlcmUgd2FzIG5vIHVuaWZpZWQgTUlCIHN0YW5kYXJkcyBmb3Ig SUVFRSAxNTg4LCB0aGlzIHJlc3VsdGVkIGluIHZlcnkgZGl2ZXJzaWZpZWQgIHByYWN0aWNlcyBp biBpdHMgbWFuYWdlbWVudC4NCg0KSW5zdGVhZCwgSSdkIHByb3Bvc2UgdGhhdCB5b3UgbW9kZWwg dGhpcyBhcyB0d28gbGVhZnMgd2l0aCBkaWZmZXJlbnQgbmFtZXMsIG9uZSBjb25maWcgZmFsc2Ug YW5kIG9uZSBjb25maWcgdHJ1ZS4gVGhlIGNvbmZpZyB0cnVlIGxlYWYgbWF5IGRlcGVuZCBvbiBh IGZlYXR1cmUuDQpbWXVhbmxvbmddIHdlIHdpbGwgY29uc2lkZXIgdGhpcyBvcHRpb24gdG9nZXRo ZXIgd2l0aCB0aGUgbmVjZXNzYXJ5IGFsaWdubWVudCB3aXRoIElFRUUgMTU4OCBpbmZvcm1hdGlv biBtb2RlbC4NCg0KQnR3LCB0aGUgY3VycmVudCBkZWZpbml0aW9uIG9mIHRoZSBsZWFmIHR3by1z dGVwLWZsYWcgZGVmaW5lcyBubyBkZWZhdWx0IHZhbHVlIGFuZCBkb2VzIG5vdCBkZWNsYXJlIHRo ZSBsZWFmIG1hbmRhdG9yeS4gVGhpcyBvcGVucyB1cCBmb3IgYW4gdW5kZWZpbmVkIGNhc2UuIElm IHRoZSB0d28tc3RlcC1mbGFnIGlzIHRydWUsIGl0J3MgYSB0d28tc3RlcCBjbG9jay4gSWYgZmFs c2UsIG9uZS1zdGVwLiBCdXQgd2hhdCBpZiBhbiBpbXBsZW1lbnRhdGlvbiBkb2Vzbid0IHJldHVy biB0aGUgdHdvLXN0ZXAtbGVhZiBhdCBhbGw/IFRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IHBlciB0 aGUgWUFORyB0byByZXR1cm4gdGhpcyBsZWFmLCBhbmQgbm8gbGFuZ3VhZ2UgYXMgdG8gd2hhdCB0 aGF0IHdvdWxkIG1lYW4uDQpbWXVhbmxvbmddIE15IHVuZGVyc3RhbmRpbmcgaXMgMTU4OCBpbXBs ZW1lbnRhdGlvbiB3aWxsIGluaXRpYWxpemUgdGhpcyB2YWx1ZSBpdHNlbGYsIG5vdCByZXNvcnQg dG8gY29uZmlndXJhdGlvbiAoZnJvbSBJRUVFIDE1ODgtMjAwOCkuIEJ1dCB0aGF04oCZcyBleGFj dGx5IHdoeSB0aGUgZXhpc3RpbmcgMTU4OCBpbXBsZW1lbnRhdGlvbnMgbWF5IG5vdCBpbnRlcm5l dHdvcmsgd2l0aCBlYWNoIG90aGVyLiBXZSB3aWxsIGNvbnNpZGVyIHRoaXMgdG9vLg0KDQovamFu DQoNCg0KDQpXZSBhcmUgZGV2ZWxvcGluZyBhIFlBTkcgbW9kdWxlIGZvciBJRUVFIDE1ODgsIHdo aWNoIGlzIGFscmVhZHkgYSBXRyBkcmFmdCwgcGxlYXNlIHNlZSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDcuDQpUaGUgYmFzZSBtb2R1 bGUgZGVmaW5lcyBhIGxlYWYgbm9kZSDigJh0d28tc3RlcC1mbGFn4oCZIGFuZCB0YWdzIGl0IGFz IHJlYWQtd3JpdGUsIGJ1dCBzb21lIGFwcGxpY2F0aW9ucyBtYXkgd2FudCB0byByZW1vZGVsIGl0 IGFzIHJlYWQtb25seS4NClRoZSBmb2xsb3dpbmcgaXMgdGhlIGNvZGVzIEkgdHJpZWQ6DQptb2R1 bGUgcHRwLWF1Z21lbnQgew0KICAgIG5hbWVzcGFjZSAidXJuOmV4YW1wbGU6cHRwLWF1Z21lbnQi Ow0KICAgIHByZWZpeCBwdHAtYWc7DQoNCiAgICBpbXBvcnQgaWV0Zi1wdHAgew0KICAgICAgICBw cmVmaXggcHRwOw0KICAgIH0NCg0KICAgIGF1Z21lbnQgL3B0cDpwdHAvcHRwOmluc3RhbmNlLWxp c3QvcHRwOmRlZmF1bHQtZHMgew0KICAgICAgICAgICBsZWFmIHR3by1zdGVwLWZsYWcgew0KICAg ICAgICAgICAgIGNvbmZpZyBmYWxzZTsNCiAgICAgICAgICAgICB0eXBlIGJvb2xlYW47DQogICAg ICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICJXaGVuIHNldCwgdGhlIGNsb2Nr IGlzIGEgdHdvLXN0ZXAgY2xvY2s7IG90aGVyd2lzZSwNCiAgICAgICAgICAgICAgICB0aGUgY2xv Y2sgaXMgYSBvbmUtc3RlcCBjbG9jay4iOw0KICAgICAgICAgICB9DQoNCn0NCn0NClRoZSBjb2Rl cyBhcmUgdmFsaWRhdGVkIHRvIGJlIHJpZ2h0IGJ5IGh0dHA6Ly93d3cuLnlhbmd2YWxpZGF0b3Iu Y29tL3ZhbGlkYXRvcjxodHRwOi8vd3d3Lnlhbmd2YWxpZGF0b3IuY29tL3ZhbGlkYXRvcj4uDQpN eSBxdWVzdGlvbiBpczogQnkgdXNpbmcg4oCYYXVnbWVudOKAmSwgdHdvIGxlYWYgbm9kZXMgYXJl IGRlZmluZWQgc3VjY2Vzc2Z1bGx5IHdpdGggdGhlIHNhbWUgWUFORyBpZGVudGlmaWVyIGJ1dCB3 aXRoIGRpZmZlcmVudCBiZWhhdmlvcnMgKGFsc28gYXBwbGljYWJsZSB0byBkaWZmZXJlbnQgdHlw ZXMpLCBkb2VzIHRoZSBuZXcgZGVmaW5pdGlvbiB0YWtlIHRoZSBwcmVjZWRlbmNlIGFuZCBvdmVy d3JpdGUgaXRzIG9sZCBkZWZpbml0aW9uPw0KSWYgdGhlIGFuc3dlciBpcyB5ZXMsIEkgd2lsbCBi ZSBnbGFkIHRvIHVzZSB0aGlzIFlBTkcgZmVhdHVyZSwgYnV0IHBlcmhhcHMgaXQgbWFrZXMgc2Vu c2UgdGhhdCBhIFlBTkcgY29tcGlsZXIgZW1pdHMgYSB3YXJuaW5nIHRoYXQgYSBuZXcgZGVmaW5p dGlvbiBvdmVycmlkZXMgYW4gZXhpc3Rpbmcgb25lLg0KT3IsIGFyZSB0d28gbGVhZiBub2RlcyBk ZWZpbmVkIGV4YWN0bHk/IEhvdyBkbyB3ZSBkaXN0aW5ndWlzaCB0aGVtPw0KDQpJIGFsc28gdHJp ZWQgdG8gdXNlIOKAmGRldmlhdGlvbuKAmSBpbnN0ZWFkLCB0aGUgZm9sbG93aW5nIGlzIHRoZSBj b2RlczoNCg0KICAgICBtb2R1bGUgcHRwLWRldmlhdGlvbnMgew0KICAgICAgIG5hbWVzcGFjZSAi dXJuOmV4YW1wbGU6cHRwLWRldmlhdGlvbnMiOw0KICAgICAgIHByZWZpeCBwdHBkOw0KDQogICAg ICAgaW1wb3J0IGlldGYtcHRwIHsNCiAgICAgICAgIHByZWZpeCBwdHA7DQogICAgICAgfQ0KDQog ICAgICAgZGV2aWF0aW9uIC9wdHA6cHRwL3B0cDppbnN0YW5jZS1saXN0L3B0cDpkZWZhdWx0LWRz L3B0cDp0d28tc3RlcC1mbGFnIHsNCiAgICAgICAgICAgZGV2aWF0ZSByZXBsYWNlIHsNCiAgICAg ICAgICAgICBjb25maWcgZmFsc2U7DQogICAgICAgICAgIH0NCiAgICAgICB9DQoNCiAgICAgfQ0K VGhlIGNvZGVzIGFyZSBhbHNvIHZhbGlkYXRlZCB0byBiZSByaWdodCBieSBodHRwOi8vd3d3Li55 YW5ndmFsaWRhdG9yLmNvbS92YWxpZGF0b3I8aHR0cDovL3d3dy55YW5ndmFsaWRhdG9yLmNvbS92 YWxpZGF0b3I+Lg0KTXkgY29uY2VybiBpcywgaXQgY2Fubm90IGFkZCBuZXcgbGVhZiBub2Rlcywg c28gaW5ldml0YWJseSwgYW5vdGhlciBhdWdtZW50IHdpbGwgYWx3YXlzIGJlIHVzZWQuDQoNCkFu eSB0aG91Z2h0cz8NCg0KVGhhbmtzLA0KWXVhbmxvbmcNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0 Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kDQoNCg== --_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBEB0dggeml507mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRpbWVzTmV3Um9tYW5QU01UOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAg MCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNv LXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4w cHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFuLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayBhIGxvdCBmb3IgeW91ciBwcm9t cHQgZmVlZGJhY2suIFBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5ZdWFubG9uZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEphbiBMaW5kYmxhZCBbbWFpbHRvOmphbmxAdGFp bC1mLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAxMCwgMjAxOCA0OjU4 IFBNPGJyPg0KPGI+VG86PC9iPiBKaWFuZ3l1YW5sb25nPGJyPg0KPGI+Q2M6PC9iPiBuZXRtb2RA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIFVzaW5nIGF1Z21lbnQg dG8gb3ZlcndyaXRlIGFuIGV4aXN0aW5nIGRlZmluaXRpb24/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+WXVhbmxvbmcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Qm90aCBhcHByb2FjaGVzIHlvdSBkZXNjcmliZSBhcmUgdGVjaG5pY2FsbHkgdmFs aWQsIGJ1dCBJIGRvbid0IGxpa2UgZWl0aGVyIG9mIHRoZW0gbXVjaC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoZW4geW91IGF1Z21lbnQgYW5vdGhl ciAmcXVvdDtsZWFmIHR3by1zdGVwLWZsYWcmcXVvdDsgKGZyb20gYSBkaWZmZXJlbnQgbW9kdWxl KSBpbnRvIHRoZSBzYW1lIHBhcmVudCB5b3Ugd2lsbCBlbmQgdXAgd2l0aCAqYm90aCogbGVhZnMu IFRoZXkgd2lsbCBoYXZlIHRoZSBzYW1lIGxvY2FsLW5hbWUsIGJ1dCBkaWZmZXJlbnQgbmFtZXNw YWNlcy4gRm9yIHRoZSBhdmVyYWdlIHVzZXIsIHRoaXMNCiB3aWxsIGxpa2VseSBiZSBoaWdobHkg Y29uZnVzaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1l1 YW5sb25nXSBBZ3JlZWQuIE15IGZpcnN0IGd1ZXNzIHdhcyBhbHNvIHRvIHVzZSBuYW1lc3BhY2Vz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBhbHNv IGRvbid0IGxpa2Ugd2hlbiBzdGFuZGFyZHMgYm9kaWVzIGFyZSBwbGF5aW5nIHdpdGggZGV2aWF0 aW9ucy4gVGhleSBhcmUgbWVhbnQgdG8gYmUgYSBsYXN0IHJlc29ydCBmb3IgaW1wbGVtZW50b3Jz IHRoYXQgYXJlIHVuYWJsZSB0byBmb2xsb3cgYSBzdGFuZGFyZC4gSWYgYSBzdGFuZGFyZCByZXF1 aXJlcyB0aGUgdXNlIG9mIGRldmlhdGlvbnMsIHRoZSB2YWx1ZSBvZg0KIHRoZSBzdGFuZGFyZCBp cyBkaWx1dGVkLiBBbmQgaWYgYW4gaW1wbGVtZW50b3Igd291bGQgd2FudCB0byBkZXZpYXRlIGZy b20gdGhlIHN0YW5kYXJkLCBob3cgd291bGQgaGUgZGV2aWF0ZSBmcm9tIHRoZSBkZXZpYXRpb24/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bWXVhbmxvbmddIHdl IGFyZSBub3QgdGFyZ2V0aW5nIHRvIHVzZSB0aGVzZSBjb2RlcyBpbiBvdXIgc3RhbmRhcmRzLCBi dXQgdHJ5aW5nIHRvIHNpbXVsYXRlIHNvbWUgcG9zc2libGUgZGVyaXZlZCBpbXBsZW1lbnRhdGlv bnMuIEluIHRoZSBwYXN0LA0KIHRoZXJlIHdhcyBubyB1bmlmaWVkIE1JQiBzdGFuZGFyZHMgZm9y IElFRUUgMTU4OCwgdGhpcyByZXN1bHRlZCBpbiB2ZXJ5IGRpdmVyc2lmaWVkICZuYnNwO3ByYWN0 aWNlcyBpbiBpdHMgbWFuYWdlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkluc3RlYWQsIEknZCBwcm9wb3NlIHRoYXQgeW91IG1vZGVsIHRoaXMg YXMgdHdvIGxlYWZzIHdpdGggZGlmZmVyZW50IG5hbWVzLCBvbmUgY29uZmlnIGZhbHNlIGFuZCBv bmUgY29uZmlnIHRydWUuIFRoZSBjb25maWcgdHJ1ZSBsZWFmIG1heSBkZXBlbmQgb24gYSBmZWF0 dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1l1YW5sb25n XSB3ZSB3aWxsIGNvbnNpZGVyIHRoaXMgb3B0aW9uIHRvZ2V0aGVyIHdpdGggdGhlIG5lY2Vzc2Fy eSBhbGlnbm1lbnQgd2l0aCBJRUVFIDE1ODggaW5mb3JtYXRpb24gbW9kZWwuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CdHcsIHRoZSBjdXJyZW50IGRl ZmluaXRpb24gb2YgdGhlIGxlYWYgdHdvLXN0ZXAtZmxhZyBkZWZpbmVzIG5vIGRlZmF1bHQgdmFs dWUgYW5kIGRvZXMgbm90IGRlY2xhcmUgdGhlIGxlYWYgbWFuZGF0b3J5LiBUaGlzIG9wZW5zIHVw IGZvciBhbiB1bmRlZmluZWQgY2FzZS4gSWYgdGhlIHR3by1zdGVwLWZsYWcgaXMgdHJ1ZSwgaXQn cyBhIHR3by1zdGVwIGNsb2NrLiBJZiBmYWxzZSwNCiBvbmUtc3RlcC4gQnV0IHdoYXQgaWYgYW4g aW1wbGVtZW50YXRpb24gZG9lc24ndCByZXR1cm4gdGhlIHR3by1zdGVwLWxlYWYgYXQgYWxsPyBU aGVyZSBpcyBubyByZXF1aXJlbWVudCBwZXIgdGhlIFlBTkcgdG8gcmV0dXJuIHRoaXMgbGVhZiwg YW5kIG5vIGxhbmd1YWdlIGFzIHRvIHdoYXQgdGhhdCB3b3VsZCBtZWFuLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1l1YW5sb25nXSBN eSB1bmRlcnN0YW5kaW5nIGlzIDE1ODggaW1wbGVtZW50YXRpb24gd2lsbCBpbml0aWFsaXplIHRo aXMgdmFsdWUgaXRzZWxmLCBub3QgcmVzb3J0IHRvIGNvbmZpZ3VyYXRpb24gKGZyb20gSUVFRSAx NTg4LTIwMDgpLiBCdXQgdGhhdOKAmXMNCiBleGFjdGx5IHdoeSB0aGUgZXhpc3RpbmcgMTU4OCBp bXBsZW1lbnRhdGlvbnMgbWF5IG5vdCBpbnRlcm5ldHdvcmsgd2l0aCBlYWNoIG90aGVyLiBXZSB3 aWxsIGNvbnNpZGVyIHRoaXMgdG9vLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi9qYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGFyZSBkZXZlbG9waW5nIGEgWUFORyBtb2R1bGUgZm9yIElF RUUgMTU4OCwgd2hpY2ggaXMgYWxyZWFkeSBhIFdHIGRyYWZ0LCBwbGVhc2Ugc2VlPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFuZy0wNyI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLTA3PC9zcGFuPjwvYT4uPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBiYXNlIG1vZHVsZSBkZWZpbmVzIGEgbGVhZiBub2RlIOKA mHR3by1zdGVwLWZsYWfigJkgYW5kIHRhZ3MgaXQgYXMgcmVhZC13cml0ZSwgYnV0IHNvbWUgYXBw bGljYXRpb25zIG1heSB3YW50IHRvIHJlbW9kZWwgaXQgYXMgcmVhZC1vbmx5Ljwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgZm9sbG93aW5nIGlzIHRoZSBjb2RlcyBJIHRy aWVkOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5tb2R1bGUgcHRwLWF1 Z21lbnQgezwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG5hbWVzcGFjZSAmcXVvdDt1cm46ZXhhbXBsZTpwdHAtYXVnbWVudCZxdW90 Ozs8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyBwcmVmaXggcHRwLWFnOzwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsgaW1wb3J0IGlldGYtcHRwIHs8L3NwYW4+PC9pPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBwcmVmaXggcHRwOzwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF1Z21lbnQgL3B0cDpwdHAvcHRwOmluc3RhbmNl LWxpc3QvcHRwOmRlZmF1bHQtZHMgezwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGxlYWYgdHdvLXN0ZXAtZmxhZyB7PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uZmlnIGZhbHNlOzwvc3Bhbj48 L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUg Ym9vbGVhbjs8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBkZXNjcmlwdGlvbjwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O1doZW4gc2V0LCB0aGUg Y2xvY2sgaXMgYSB0d28tc3RlcCBjbG9jazsgb3RoZXJ3aXNlLDwvc3Bhbj48L2k+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHRoZSBjbG9jayBpcyBhIG9uZS1zdGVwIGNsb2NrLiZxdW90Ozs8L3NwYW4+PC9pPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6MjEuMHB0Ij48aT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPn08L3NwYW4+PC9pPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPn08L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoZSBjb2RlcyBhcmUgdmFsaWRhdGVkIHRvIGJlIHJpZ2h0IGJ5PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93 d3cueWFuZ3ZhbGlkYXRvci5jb20vdmFsaWRhdG9yIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwOi8vd3d3Li55YW5ndmFsaWRhdG9yLmNvbS92YWxpZGF0b3I8L3NwYW4+PC9hPi48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgcXVlc3Rpb24gaXM6IEJ5IHVzaW5n IOKAmGF1Z21lbnTigJksIHR3byBsZWFmIG5vZGVzIGFyZSBkZWZpbmVkIHN1Y2Nlc3NmdWxseSB3 aXRoIHRoZSBzYW1lIFlBTkcgaWRlbnRpZmllciBidXQgd2l0aCBkaWZmZXJlbnQgYmVoYXZpb3Jz IChhbHNvIGFwcGxpY2FibGUNCiB0byBkaWZmZXJlbnQgdHlwZXMpLCBkb2VzIHRoZSBuZXcgZGVm aW5pdGlvbiB0YWtlIHRoZSBwcmVjZWRlbmNlIGFuZCBvdmVyd3JpdGUgaXRzIG9sZCBkZWZpbml0 aW9uPyAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhlIGFu c3dlciBpcyB5ZXMsIEkgd2lsbCBiZSBnbGFkIHRvIHVzZSB0aGlzIFlBTkcgZmVhdHVyZSwgYnV0 IHBlcmhhcHMgaXQgbWFrZXMgc2Vuc2UgdGhhdCBhIFlBTkcgY29tcGlsZXIgZW1pdHMgYSB3YXJu aW5nIHRoYXQgYSBuZXcgZGVmaW5pdGlvbg0KIG92ZXJyaWRlcyBhbiBleGlzdGluZyBvbmUuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9yLCBhcmUgdHdvIGxlYWYgbm9kZXMg ZGVmaW5lZCBleGFjdGx5PyBIb3cgZG8gd2UgZGlzdGluZ3Vpc2ggdGhlbT88L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkkgYWxzbyB0cmllZCB0byB1c2Ug4oCYZGV2aWF0aW9u4oCZIGluc3RlYWQsIHRo ZSBmb2xsb3dpbmcgaXMgdGhlIGNvZGVzOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1vZHVsZSBwdHAtZGV2aWF0aW9ucyB7PC9zcGFuPjwvaT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbmFtZXNwYWNlICZxdW90O3VybjpleGFtcGxlOnB0cC1kZXZpYXRpb25zJnF1b3Q7 Ozwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByZWZpeCBwdHBkOzwvc3Bhbj48L2k+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW1w b3J0IGlldGYtcHRwIHs8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcmVmaXgg cHRwOzwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRldmlhdGlvbiAv cHRwOnB0cC9wdHA6aW5zdGFuY2UtbGlzdC9wdHA6ZGVmYXVsdC1kcy9wdHA6dHdvLXN0ZXAtZmxh ZyB7PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGV2aWF0 ZSByZXBsYWNlIHs8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBjb25maWcgZmFsc2U7PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PC9pPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+ PC9pPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBjb2RlcyBhcmUgYWxzbyB2YWxp ZGF0ZWQgdG8gYmUgcmlnaHQgYnk8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy55YW5ndmFsaWRhdG9yLmNvbS92YWxpZGF0 b3IiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly93d3cuLnlhbmd2YWxpZGF0b3Iu Y29tL3ZhbGlkYXRvcjwvc3Bhbj48L2E+Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5NeSBjb25jZXJuIGlzLCBpdCBjYW5ub3QgYWRkIG5ldyBsZWFmIG5vZGVzLCBzbyBpbmV2 aXRhYmx5LCBhbm90aGVyIGF1Z21lbnQgd2lsbCBhbHdheXMgYmUgdXNlZC48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QW55IHRob3VnaHRzPzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3MsPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5ZdWFubG9uZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXNOZXdSb21hblBTTVQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxp bmcgbGlzdDxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOm5l dG1vZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXNOZXdSb21hblBTTVQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6cHVy cGxlIj5uZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXNOZXdSb21hblBT TVQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Qi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzTmV3 Um9tYW5QU01UJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBEB0dggeml507mbschi_-- From nobody Tue Apr 10 02:53:40 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D11124B18 for ; Tue, 10 Apr 2018 02:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6DZV3xUV8SJ for ; Tue, 10 Apr 2018 02:53:35 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E045412D88A for ; Tue, 10 Apr 2018 02:53:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1451BE7F; Tue, 10 Apr 2018 11:53:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id TBLoiPRRuc-S; Tue, 10 Apr 2018 11:53:26 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 10 Apr 2018 11:53:27 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4CDE20035; Tue, 10 Apr 2018 11:53:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SIV3c5cTvp56; Tue, 10 Apr 2018 11:53:27 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A10220031; Tue, 10 Apr 2018 11:53:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AC41042AE39D; Tue, 10 Apr 2018 11:53:26 +0200 (CEST) Date: Tue, 10 Apr 2018 11:53:26 +0200 From: Juergen Schoenwaelder To: Jiangyuanlong Cc: Jan Lindblad , "netmod@ietf.org" Message-ID: <20180410095326.qp4d3zyjusimnx7d@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Jiangyuanlong , Jan Lindblad , "netmod@ietf.org" References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBE12@dggeml507-mbs.china.huawei.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBEB0@dggeml507-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB6CBEB0@dggeml507-mbs.china.huawei.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Using augment to overwrite an existing definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 09:53:39 -0000 On Tue, Apr 10, 2018 at 09:45:02AM +0000, Jiangyuanlong wrote: > I also don't like when standards bodies are playing with deviations. They are meant to be a last resort for implementors that are unable to follow a standard. If a standard requires the use of deviations, the value of the standard is diluted. And if an implementor would want to deviate from the standard, how would he deviate from the deviation? > [Yuanlong] we are not targeting to use these codes in our standards, but trying to simulate some possible derived implementations. In the past, there was no unified MIB standards for IEEE 1588, this resulted in very diversified practices in its management. Then it seems a deviation is a proper way to declare that this leaf is not configurable in a given implementation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 10 05:46:49 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB6F1241F5 for ; Tue, 10 Apr 2018 05:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDJNAgdv66CZ for ; Tue, 10 Apr 2018 05:46:46 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463B81270A7 for ; Tue, 10 Apr 2018 05:46:46 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 17DADDCF; Tue, 10 Apr 2018 14:46:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ewRo9vaVKWoL; Tue, 10 Apr 2018 14:46:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 10 Apr 2018 14:46:44 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E62F220035; Tue, 10 Apr 2018 14:46:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hDIPGMjcpIsT; Tue, 10 Apr 2018 14:46:44 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38AE220031; Tue, 10 Apr 2018 14:46:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 19D8842AE702; Tue, 10 Apr 2018 14:46:44 +0200 (CEST) Date: Tue, 10 Apr 2018 14:46:43 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: netmod@ietf.org Message-ID: <20180410124643.mnywxuxrnyaahttv@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20180329090305.eqshcqvqo33r5bsf@elstar.local> <20180405.143340.1930670144610383537.mbj@tail-f.com> <20180406122406.wdba43mr3bxsnyce@elstar.local> <20180406.152710.818971844955208858.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180406.152710.818971844955208858.mbj@tail-f.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] js review of draft-ietf-netmod-schema-mount-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 12:46:48 -0000 On Fri, Apr 06, 2018 at 03:27:10PM +0200, Martin Bjorklund wrote: > > Ok. I tweaked it to: > > This document defines a mechanism to add the schema trees defined > by a set of YANG modules onto a mount point defined in the schema > tree in some YANG module. > Works for me. > > OK. It seems that for a client capable to support a 'shared schema', > > the 'inline' schema really is just a special case without parent > > references. (I wonder whether anything should be said to YANG library > > version numbers, whether they are always scoped by the mount point > > or have meaning across mount points; if two YANG library instances > > in mounted schemas have the same version number, does this imply > > that these YANG library instances are identical or is this just a > > version number clash? But then this probably goes across the spirit > > of not talking about YANG library too much.) > > When you say "version number" do you mean the YANG library checksum? > I don't think the YL document guarantees that there can never be > clashes. Yes, the checksum (which I think is actually a version identifier). Anyway, the question is whether a client can draw any conclusions from seeing YANG library instances with the same checksum and whether a client must simpy treat this as a clash. If multiple mounted schemas have the same YANG library, then reading one of them would be sufficient. The question is whether the checksum is a tool for deciding whether a YANG library is similar to an already known one or whether a client must not make this assumption, i.e., a checksum is always scoped to the YANG library instance and you have to read them all. > > This helps. Can I also mount NACM into a mount point? If yes, what if > > both are present? > > Yes you can mount NACM. To keep things simple, I think the inner NACM > should not affect the access control done in the parent. Consider the > use cases for this. In a NI situation, it doesn't make much sense to > mount NACM. In an LNE (or in a "peer mount") situation, it may make > sense to mount NACM if the LNE (or device) supports it. In this case, > if I try to access any mounted data in the parent, access is > controlled by the parent. If I have access, the parent may send a > request over to the mounted device to read/write the data. That > device will use its local copy of NACM to control access, or some > other mechanism. In this scenarios, if the parent NACM grants access but the inner NACM does not grant access, I assume I will not have access, right? So how does this line up with "the inner NACM should not affect the access control done in the parent"? Frankly, this is all a bit hypothetical since we have no standards for doing peer mounts - and clearly not for writable peer mounts. So probably the truth is that it is undefined whether the inner NACM applies or not. Hm. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 10 07:15:52 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C439129C5D for ; Tue, 10 Apr 2018 07:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p11_mQLdLmc for ; Tue, 10 Apr 2018 07:15:49 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 28514129C51 for ; Tue, 10 Apr 2018 07:15:49 -0700 (PDT) Received: from localhost (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id 98E461AE00A0; Tue, 10 Apr 2018 16:15:47 +0200 (CEST) Date: Tue, 10 Apr 2018 16:15:46 +0200 (CEST) Message-Id: <20180410.161546.1818555188781690245.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180410124643.mnywxuxrnyaahttv@elstar.local> References: <20180406122406.wdba43mr3bxsnyce@elstar.local> <20180406.152710.818971844955208858.mbj@tail-f.com> <20180410124643.mnywxuxrnyaahttv@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] js review of draft-ietf-netmod-schema-mount-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 14:15:51 -0000 Juergen Schoenwaelder wrote: > On Fri, Apr 06, 2018 at 03:27:10PM +0200, Martin Bjorklund wrote: > > > > Ok. I tweaked it to: > > > > This document defines a mechanism to add the schema trees defined > > by a set of YANG modules onto a mount point defined in the schema > > tree in some YANG module. > > > > Works for me. > > > > OK. It seems that for a client capable to support a 'shared schema', > > > the 'inline' schema really is just a special case without parent > > > references. (I wonder whether anything should be said to YANG library > > > version numbers, whether they are always scoped by the mount point > > > or have meaning across mount points; if two YANG library instances > > > in mounted schemas have the same version number, does this imply > > > that these YANG library instances are identical or is this just a > > > version number clash? But then this probably goes across the spirit > > > of not talking about YANG library too much.) > > > > When you say "version number" do you mean the YANG library checksum? > > I don't think the YL document guarantees that there can never be > > clashes. > > Yes, the checksum (which I think is actually a version identifier). > Anyway, the question is whether a client can draw any conclusions from > seeing YANG library instances with the same checksum and whether a > client must simpy treat this as a clash. If multiple mounted schemas > have the same YANG library, then reading one of them would be > sufficient. The question is whether the checksum is a tool for > deciding whether a YANG library is similar to an already known one or > whether a client must not make this assumption, i.e., a checksum is > always scoped to the YANG library instance and you have to read them > all. Options: 1. Be silent about the YL checksum in this document. 2. State that the server MUST ensure that if two mounted YL instances have the same checksum, then the YL contents MUST be the same. 3. State that just b/c the YL checksum is the same in two mounted instances, it does not mean that the YL contents is the same. 4. State that for use-schema, the YL contents and YL checksum MUST be the samem but for inline, equal YL checksum is no guarantee for equal YL contents. >From a client perspective, 2 is preferrable. It is probably not difficult to implement on a server either; except in the peer mount case where the data is just read from some device. > > > This helps. Can I also mount NACM into a mount point? If yes, what if > > > both are present? > > > > Yes you can mount NACM. To keep things simple, I think the inner NACM > > should not affect the access control done in the parent. Consider the > > use cases for this. In a NI situation, it doesn't make much sense to > > mount NACM. In an LNE (or in a "peer mount") situation, it may make > > sense to mount NACM if the LNE (or device) supports it. In this case, > > if I try to access any mounted data in the parent, access is > > controlled by the parent. If I have access, the parent may send a > > request over to the mounted device to read/write the data. That > > device will use its local copy of NACM to control access, or some > > other mechanism. > > In this scenarios, if the parent NACM grants access but the inner NACM > does not grant access, I assume I will not have access, right? So how > does this line up with "the inner NACM should not affect the access > control done in the parent"? Frankly, this is all a bit hypothetical > since we have no standards for doing peer mounts - and clearly not for > writable peer mounts. So probably the truth is that it is undefined > whether the inner NACM applies or not. Hm. But maybe this is something that needs to be handled when we define peer mount? The question is if we need to add any text to this document? /martin From nobody Tue Apr 10 07:34:24 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ADC12D7EA for ; Tue, 10 Apr 2018 07:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLtE_4988Mn9 for ; Tue, 10 Apr 2018 07:34:19 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD6E129C5D for ; Tue, 10 Apr 2018 07:34:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0CE26E78; Tue, 10 Apr 2018 16:34:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id wSQlRuK6m1gu; Tue, 10 Apr 2018 16:34:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 10 Apr 2018 16:34:17 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A818520035; Tue, 10 Apr 2018 16:34:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WDVf1gE69yzB; Tue, 10 Apr 2018 16:34:17 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15FC120031; Tue, 10 Apr 2018 16:34:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C724E42AE9D0; Tue, 10 Apr 2018 16:34:16 +0200 (CEST) Date: Tue, 10 Apr 2018 16:34:16 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: netmod@ietf.org Message-ID: <20180410143416.4y5wofkhr67wxxo4@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20180406122406.wdba43mr3bxsnyce@elstar.local> <20180406.152710.818971844955208858.mbj@tail-f.com> <20180410124643.mnywxuxrnyaahttv@elstar.local> <20180410.161546.1818555188781690245.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180410.161546.1818555188781690245.mbj@tail-f.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] js review of draft-ietf-netmod-schema-mount-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 14:34:22 -0000 On Tue, Apr 10, 2018 at 04:15:46PM +0200, Martin Bjorklund wrote: > > > > Yes, the checksum (which I think is actually a version identifier). > > Anyway, the question is whether a client can draw any conclusions from > > seeing YANG library instances with the same checksum and whether a > > client must simpy treat this as a clash. If multiple mounted schemas > > have the same YANG library, then reading one of them would be > > sufficient. The question is whether the checksum is a tool for > > deciding whether a YANG library is similar to an already known one or > > whether a client must not make this assumption, i.e., a checksum is > > always scoped to the YANG library instance and you have to read them > > all. > > Options: > > 1. Be silent about the YL checksum in this document. > > 2. State that the server MUST ensure that if two mounted YL > instances have the same checksum, then the YL contents MUST be > the same. > > 3. State that just b/c the YL checksum is the same in two mounted > instances, it does not mean that the YL contents is the same. > > 4. State that for use-schema, the YL contents and YL checksum MUST be > the samem but for inline, equal YL checksum is no guarantee for > equal YL contents. > > From a client perspective, 2 is preferrable. It is probably not > difficult to implement on a server either; except in the peer mount > case where the data is just read from some device. The more I think about it, it seems option 4. is the right thing to do. > > > Yes you can mount NACM. To keep things simple, I think the inner NACM > > > should not affect the access control done in the parent. Consider the > > > use cases for this. In a NI situation, it doesn't make much sense to > > > mount NACM. In an LNE (or in a "peer mount") situation, it may make > > > sense to mount NACM if the LNE (or device) supports it. In this case, > > > if I try to access any mounted data in the parent, access is > > > controlled by the parent. If I have access, the parent may send a > > > request over to the mounted device to read/write the data. That > > > device will use its local copy of NACM to control access, or some > > > other mechanism. > > > > In this scenarios, if the parent NACM grants access but the inner NACM > > does not grant access, I assume I will not have access, right? So how > > does this line up with "the inner NACM should not affect the access > > control done in the parent"? Frankly, this is all a bit hypothetical > > since we have no standards for doing peer mounts - and clearly not for > > writable peer mounts. So probably the truth is that it is undefined > > whether the inner NACM applies or not. Hm. > > But maybe this is something that needs to be handled when we define > peer mount? The question is if we need to add any text to this > document? > I think it is sufficient to say that the server's NACM rules apply to mounted data. (In the peer mount case, it should not matter whether the peer's NACM is mounted or not, the peer's NACM applies anyway when the peer is accessed - but it may be accessed a username identity that is different from the username identity used to access the mounted data.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 10 13:58:05 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99F512D77D for ; Tue, 10 Apr 2018 13:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEtXV_y79zDe for ; Tue, 10 Apr 2018 13:58:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DD7501272E1 for ; Tue, 10 Apr 2018 13:58:01 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 7BBC31AE00A0; Tue, 10 Apr 2018 22:58:00 +0200 (CEST) Date: Tue, 10 Apr 2018 22:58:00 +0200 (CEST) Message-Id: <20180410.225800.2211357338649569621.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180410143416.4y5wofkhr67wxxo4@elstar.local> References: <20180410124643.mnywxuxrnyaahttv@elstar.local> <20180410.161546.1818555188781690245.mbj@tail-f.com> <20180410143416.4y5wofkhr67wxxo4@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] js review of draft-ietf-netmod-schema-mount-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 20:58:04 -0000 Juergen Schoenwaelder wrote: > On Tue, Apr 10, 2018 at 04:15:46PM +0200, Martin Bjorklund wrote: > > > > > > Yes, the checksum (which I think is actually a version identifier). > > > Anyway, the question is whether a client can draw any conclusions from > > > seeing YANG library instances with the same checksum and whether a > > > client must simpy treat this as a clash. If multiple mounted schemas > > > have the same YANG library, then reading one of them would be > > > sufficient. The question is whether the checksum is a tool for > > > deciding whether a YANG library is similar to an already known one or > > > whether a client must not make this assumption, i.e., a checksum is > > > always scoped to the YANG library instance and you have to read them > > > all. > > > > Options: > > > > 1. Be silent about the YL checksum in this document. > > > > 2. State that the server MUST ensure that if two mounted YL > > instances have the same checksum, then the YL contents MUST be > > the same. > > > > 3. State that just b/c the YL checksum is the same in two mounted > > instances, it does not mean that the YL contents is the same. > > > > 4. State that for use-schema, the YL contents and YL checksum MUST be > > the samem but for inline, equal YL checksum is no guarantee for > > equal YL contents. > > > > From a client perspective, 2 is preferrable. It is probably not > > difficult to implement on a server either; except in the peer mount > > case where the data is just read from some device. > > The more I think about it, it seems option 4. is the right thing to > do. Ok. How about adding two sentences at the end of the last paragraph in section 3.3, giving: The mounted schema is determined at run time: every instance of the mount point that exists in the operational state MUST contain a copy of YANG library data that defines the mounted schema exactly as for a top-level schema. A client is expected to retrieve this data from the instance tree, possibly after creating the mount point. In the "inline" case, instances of the same mount point MAY use different mounted schemas, whereas in the "shared-schema" case, all instances MUST use the same mounted schema. In the "inline" case, if two instances have the same YANG library checksum it is not guaranteed that the YANG library contents are equal for these instances. > > > > Yes you can mount NACM. To keep things simple, I think the inner NACM > > > > should not affect the access control done in the parent. Consider the > > > > use cases for this. In a NI situation, it doesn't make much sense to > > > > mount NACM. In an LNE (or in a "peer mount") situation, it may make > > > > sense to mount NACM if the LNE (or device) supports it. In this case, > > > > if I try to access any mounted data in the parent, access is > > > > controlled by the parent. If I have access, the parent may send a > > > > request over to the mounted device to read/write the data. That > > > > device will use its local copy of NACM to control access, or some > > > > other mechanism. > > > > > > In this scenarios, if the parent NACM grants access but the inner NACM > > > does not grant access, I assume I will not have access, right? So how > > > does this line up with "the inner NACM should not affect the access > > > control done in the parent"? Frankly, this is all a bit hypothetical > > > since we have no standards for doing peer mounts - and clearly not for > > > writable peer mounts. So probably the truth is that it is undefined > > > whether the inner NACM applies or not. Hm. > > > > But maybe this is something that needs to be handled when we define > > peer mount? The question is if we need to add any text to this > > document? > > > > I think it is sufficient to say that the server's NACM rules apply to > mounted data. Ok. > (In the peer mount case, it should not matter whether > the peer's NACM is mounted or not, the peer's NACM applies anyway when > the peer is accessed - but it may be accessed a username identity that > is different from the username identity used to access the mounted > data.) Yes, this is a good point. /martin From nobody Tue Apr 10 23:20:28 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7EB126B6E for ; Tue, 10 Apr 2018 23:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs7D5eGKyqhS for ; Tue, 10 Apr 2018 23:20:24 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D5E1241FC for ; Tue, 10 Apr 2018 23:20:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B6288EA9; Wed, 11 Apr 2018 08:20:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id rApSET1mftFi; Wed, 11 Apr 2018 08:20:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 11 Apr 2018 08:20:22 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F4E720035; Wed, 11 Apr 2018 08:20:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7c18PhgkgP5a; Wed, 11 Apr 2018 08:20:21 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F48620031; Wed, 11 Apr 2018 08:20:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 621F942AF3E0; Wed, 11 Apr 2018 08:20:21 +0200 (CEST) Date: Wed, 11 Apr 2018 08:20:21 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: netmod@ietf.org Message-ID: <20180411062021.i6h2c3z3kf4otae7@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20180410124643.mnywxuxrnyaahttv@elstar.local> <20180410.161546.1818555188781690245.mbj@tail-f.com> <20180410143416.4y5wofkhr67wxxo4@elstar.local> <20180410.225800.2211357338649569621.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180410.225800.2211357338649569621.mbj@tail-f.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] js review of draft-ietf-netmod-schema-mount-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 06:20:27 -0000 On Tue, Apr 10, 2018 at 10:58:00PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Apr 10, 2018 at 04:15:46PM +0200, Martin Bjorklund wrote: > > > > > > > > Yes, the checksum (which I think is actually a version identifier). > > > > Anyway, the question is whether a client can draw any conclusions from > > > > seeing YANG library instances with the same checksum and whether a > > > > client must simpy treat this as a clash. If multiple mounted schemas > > > > have the same YANG library, then reading one of them would be > > > > sufficient. The question is whether the checksum is a tool for > > > > deciding whether a YANG library is similar to an already known one or > > > > whether a client must not make this assumption, i.e., a checksum is > > > > always scoped to the YANG library instance and you have to read them > > > > all. > > > > > > Options: > > > > > > 1. Be silent about the YL checksum in this document. > > > > > > 2. State that the server MUST ensure that if two mounted YL > > > instances have the same checksum, then the YL contents MUST be > > > the same. > > > > > > 3. State that just b/c the YL checksum is the same in two mounted > > > instances, it does not mean that the YL contents is the same. > > > > > > 4. State that for use-schema, the YL contents and YL checksum MUST be > > > the samem but for inline, equal YL checksum is no guarantee for > > > equal YL contents. > > > > > > From a client perspective, 2 is preferrable. It is probably not > > > difficult to implement on a server either; except in the peer mount > > > case where the data is just read from some device. > > > > The more I think about it, it seems option 4. is the right thing to > > do. > > Ok. How about adding two sentences at the end of the last paragraph > in section 3.3, giving: > > The mounted schema is determined at run time: every instance of the > mount point that exists in the operational state MUST contain a copy > of YANG library data that defines the mounted schema exactly as for > a top-level schema. A client is expected to retrieve this data from > the instance tree, possibly after creating the mount point. In the > "inline" case, instances of the same mount point MAY use different > mounted schemas, whereas in the "shared-schema" case, all instances > MUST use the same mounted schema. In the "inline" case, if two > instances have the same YANG library checksum it is not guaranteed > that the YANG library contents are equal for these instances. This text says "A client is expected to retrieve this data from the instance tree, possibly after creating the mount point.", which seems a bit odd. How does a client create a mount point? First, a mount point is created by defining it in a YANG module, so this is specification time not runtime. Perhaps you mean 'instantiated' rather than 'created' but even then it is somewhat unclear how a client does that in general. Perhaps simple drop ', possibly after creating the mount point'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 10 23:46:48 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396E9126C3D for ; Tue, 10 Apr 2018 23:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMrcGfIAyN6Z for ; Tue, 10 Apr 2018 23:46:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3F313126DEE for ; Tue, 10 Apr 2018 23:46:44 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 9DAFF1AE043F; Wed, 11 Apr 2018 08:46:42 +0200 (CEST) Date: Wed, 11 Apr 2018 08:46:42 +0200 (CEST) Message-Id: <20180411.084642.1344446330417036664.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180411062021.i6h2c3z3kf4otae7@elstar.local> References: <20180410143416.4y5wofkhr67wxxo4@elstar.local> <20180410.225800.2211357338649569621.mbj@tail-f.com> <20180411062021.i6h2c3z3kf4otae7@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] js review of draft-ietf-netmod-schema-mount-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 06:46:47 -0000 Juergen Schoenwaelder wrote: > On Tue, Apr 10, 2018 at 10:58:00PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Tue, Apr 10, 2018 at 04:15:46PM +0200, Martin Bjorklund wrote: > > > > > > > > > > Yes, the checksum (which I think is actually a version identifier). > > > > > Anyway, the question is whether a client can draw any conclusions from > > > > > seeing YANG library instances with the same checksum and whether a > > > > > client must simpy treat this as a clash. If multiple mounted schemas > > > > > have the same YANG library, then reading one of them would be > > > > > sufficient. The question is whether the checksum is a tool for > > > > > deciding whether a YANG library is similar to an already known one or > > > > > whether a client must not make this assumption, i.e., a checksum is > > > > > always scoped to the YANG library instance and you have to read them > > > > > all. > > > > > > > > Options: > > > > > > > > 1. Be silent about the YL checksum in this document. > > > > > > > > 2. State that the server MUST ensure that if two mounted YL > > > > instances have the same checksum, then the YL contents MUST be > > > > the same. > > > > > > > > 3. State that just b/c the YL checksum is the same in two mounted > > > > instances, it does not mean that the YL contents is the same. > > > > > > > > 4. State that for use-schema, the YL contents and YL checksum MUST be > > > > the samem but for inline, equal YL checksum is no guarantee for > > > > equal YL contents. > > > > > > > > From a client perspective, 2 is preferrable. It is probably not > > > > difficult to implement on a server either; except in the peer mount > > > > case where the data is just read from some device. > > > > > > The more I think about it, it seems option 4. is the right thing to > > > do. > > > > Ok. How about adding two sentences at the end of the last paragraph > > in section 3.3, giving: > > > > The mounted schema is determined at run time: every instance of the > > mount point that exists in the operational state MUST contain a copy > > of YANG library data that defines the mounted schema exactly as for > > a top-level schema. A client is expected to retrieve this data from > > the instance tree, possibly after creating the mount point. In the > > "inline" case, instances of the same mount point MAY use different > > mounted schemas, whereas in the "shared-schema" case, all instances > > MUST use the same mounted schema. In the "inline" case, if two > > instances have the same YANG library checksum it is not guaranteed > > that the YANG library contents are equal for these instances. > > This text says "A client is expected to retrieve this data from the > instance tree, possibly after creating the mount point.", which seems > a bit odd. How does a client create a mount point? First, a mount > point is created by defining it in a YANG module, so this is > specification time not runtime. Perhaps you mean 'instantiated' rather > than 'created' but even then it is somewhat unclear how a client does > that in general. Perhaps simple drop ', possibly after creating the > mount point'. Ok, I will do that. /martin From nobody Wed Apr 11 08:00:13 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E9F127419 for ; Wed, 11 Apr 2018 08:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVzzUydfFtxb for ; Wed, 11 Apr 2018 08:00:05 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC4D120725 for ; Wed, 11 Apr 2018 08:00:05 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id E60941ED1DB for ; Wed, 11 Apr 2018 08:45:14 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id Z2lB1x00G2SSUrH012lEd1; Wed, 11 Apr 2018 08:45:14 -0600 X-Authority-Analysis: v=2.2 cv=cY2iljLM c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=Kd1tUaAdevIA:10 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=NTp5IrceRaw5W7r2xfQA:9 a=pILNOxqGKmIA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:Subject:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YoXavlhXCTaMPgByT801Z47Io4AkIgthpejjFxALv28=; b=PNdhIZ6bYMhgjGIenylvcWQUKY KAf/xOzHsf8HY+6TNzgD+qBM0SzRvOXRKGqTkUGgqj9LOe93gFWgZ9UbpJnJVldlUVGDQZj4CYLQ1 oss/aLBhmRpxtNosEk5QUlMFU; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:35176 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1f6Gzn-004NI7-2w; Wed, 11 Apr 2018 08:45:11 -0600 From: Lou Berger To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org References: <20180410143416.4y5wofkhr67wxxo4@elstar.local> <20180410.225800.2211357338649569621.mbj@tail-f.com> <20180411062021.i6h2c3z3kf4otae7@elstar.local> <20180411.084642.1344446330417036664.mbj@tail-f.com> Message-ID: <73dff261-9e2f-fe57-c895-b1922212ee29@labn.net> Date: Wed, 11 Apr 2018 10:45:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180411.084642.1344446330417036664.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1f6Gzn-004NI7-2w X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:35176 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] js review of draft-ietf-netmod-schema-mount-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 15:00:12 -0000 Hi, I have a suggested minor clarification below. ---------- On April 11, 2018 2:47:24 AM Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Tue, Apr 10, 2018 at 10:58:00PM +0200, Martin Bjorklund wrote: >> > Juergen Schoenwaelder wrote: >> > > On Tue, Apr 10, 2018 at 04:15:46PM +0200, Martin Bjorklund wrote: ... >> > Ok. How about adding two sentences at the end of the last paragraph >> > in section 3.3, giving: >> > >> > The mounted schema is determined at run time: every instance of the >> > mount point that exists in the operational state MUST contain a copy >> > of YANG library data that defines the mounted schema exactly as for >> > a top-level schema. A client is expected to retrieve this data from >> > the instance tree, possibly after creating the mount point. In the >> > "inline" case, instances of the same mount point MAY use different >> > mounted schemas, whereas in the "shared-schema" case, all instances >> > MUST use the same mounted schema. In the "inline" case, if two >> > instances have the same YANG library checksum it is not guaranteed >> > that the YANG library contents are equal for these instances. >> >> This text says "A client is expected to retrieve this data from the >> instance tree, possibly after creating the mount point.", which seems >> a bit odd. How does a client create a mount point? First, a mount >> point is created by defining it in a YANG module, so this is >> specification time not runtime. Perhaps you mean 'instantiated' rather >> than 'created' but even then it is somewhat unclear how a client does >> that in general. Perhaps simple drop ', possibly after creating the >> mount point'. > > Ok, I will do that. > I suggest adding to text to make it unambiguous that the MUST applies to the same mount point nodes in a schema, perhaps: OLD all instances MUST NEW all instances of the same mount point MUST Lou > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Apr 11 23:48:47 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BE81241FC; Wed, 11 Apr 2018 23:48:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152351572281.9446.8536181428221919805@ietfa.amsl.com> Date: Wed, 11 Apr 2018 23:48:42 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-schema-mount-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 06:48:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Schema Mount Authors : Martin Bjorklund Ladislav Lhotka Filename : draft-ietf-netmod-schema-mount-10.txt Pages : 28 Date : 2018-04-11 Abstract: This document defines a mechanism to add the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in some YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-10 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 11 23:52:20 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA54E126C2F for ; Wed, 11 Apr 2018 23:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_OFag1VzXeY for ; Wed, 11 Apr 2018 23:52:17 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BB2341241FC for ; Wed, 11 Apr 2018 23:52:17 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id AB16A1AE0312 for ; Thu, 12 Apr 2018 08:52:16 +0200 (CEST) Date: Thu, 12 Apr 2018 08:52:15 +0200 (CEST) Message-Id: <20180412.085215.2079947419499145589.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <152351572281.9446.8536181428221919805@ietfa.amsl.com> References: <152351572281.9446.8536181428221919805@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 06:52:20 -0000 Hi, This version addresses all WGLC comments on -09. /martin internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Modeling WG of the IETF. > > Title : YANG Schema Mount > Authors : Martin Bjorklund > Ladislav Lhotka > Filename : draft-ietf-netmod-schema-mount-10.txt > Pages : 28 > Date : 2018-04-11 > > Abstract: > This document defines a mechanism to add the schema trees defined by > a set of YANG modules onto a mount point defined in the schema tree > in some YANG module. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-10 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Apr 13 04:51:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CE7126C25; Fri, 13 Apr 2018 04:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5qpp-7W_DBp; Fri, 13 Apr 2018 04:51:49 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5A3E1242F7; Fri, 13 Apr 2018 04:51:48 -0700 (PDT) Received: from pckrejci.nat9.vcit.vutbr.net (unknown [IPv6:2001:67c:1220:80c:d0:552c:73a5:18da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 0CCAD40005D; Fri, 13 Apr 2018 13:51:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1523620306; bh=314jx+AL0VHMstP/RO9+0vnerVqPXn0MAkN1CPIp2aI=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=OGpv8Vz6NZYEPiKuLVmaL0qc/2clKbEP6JYWAu+Z1UklsdLxGaxGYX/YtZHe4jvsH nxJC3vVxwlN3ovkcMf+tkN/UIvFv4AuFhcsnQuucKKKOb/MAbXNjPTVpoXvVKdIq9w pkXCyZE+qtEgGyHZe8NOzZ1VFKHs0DWyjRdZRWcU= To: Martin Bjorklund Cc: netmod@ietf.org, YANG Doctors , FRANK RIMPLER References: <20160225.161659.2204602310947308417.mbj@tail-f.com> <20160225.163105.511576225570588684.mbj@tail-f.com> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Openpgp: preference=signencrypt Message-ID: Date: Fri, 13 Apr 2018 13:51:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20160225.163105.511576225570588684.mbj@tail-f.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 11:51:52 -0000 Hi, I'm refreshing an old thread to clarify specific use case, see below... Dne 25.2.2016 v 16:31 Martin Bjorklund napsal(a): > William Ivory wrote: >> >> -----Original Message----- >> From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 >> Sent: 25 February 2016 15:17 >> To: William Ivory >> Cc: netmod@ietf.org >> Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context >> >> William Ivory wrote: >>> Hi, >>> >>> I'm looking for clarification on the meaning of the following=20 >>> paragraph in section 6.4.1 (XPATH context) in RFC6020bis: >>> >>> 'If a node that exists in the accessible tree has a non-presence >>> container as a child, then the non-presence container also exists = in >>> the tree.' >>> >>> It's unclear to me what this is trying to say, and why - for example,= =20 >>> does this mean that I need to validate any 'must' and 'when' >>> statements on the child container even when nothing within that child= =20 >>> container is configured? >> must expressions are always evaluated if the node where the must >> expression is defined exists, regardless of the number of children >> this node has. >> >> [wivory] So in my example where the child container (non-presence) has= >> NO children, then it doesn't exist, and any must statement on it >> should not be run. Only when a non-presence container has a non-zero >> number of children should any 'must' statements on that container be >> run. >> >> [wivory] If that's the case, then would it be correct to say that the >> intention of this paragraph is as a reminder that one must evaluate >> 'must' statements on nodes that have no inherent meaning and exist >> only because they contain child nodes? > No; section 7.5.3 says: > > When a datastore is validated, all "must" constraints are > conceptually evaluated once for each node in the accessible tree (se= e > Section 6.4.1). > > And the quoted paragraph of 6.4.1 says that the NP-container > (conceptually) exists if its parent exists - regardless of number of > children. > > So if the parent exists, any must expressions in the NP-container are > evaluated. > what about top-level NP-container with must constraint? Is a root node so= mething which is always present in accessible tree (even in an empty tree= )? Intuitively, I believe that it is, so even constraints on top-level NP= -containers are supposed to be evaluated, but I cannot find something abo= ut it in RFC. Regards, Radek From nobody Fri Apr 13 08:00:59 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3CB126CC7; Fri, 13 Apr 2018 08:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy3KinkGOBax; Fri, 13 Apr 2018 08:00:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFC1124BE8; Fri, 13 Apr 2018 08:00:49 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:2ca5:7aff:fe82:b795]) by mail.nic.cz (Postfix) with ESMTPSA id 8EF486239C; Fri, 13 Apr 2018 17:00:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1523631647; bh=gCcI1ln/CrekLu8r96tV8Bqkiu942srz2pEKoRYDTjU=; h=From:To:Date; b=ViFQRTWeybwamlVX3/gaAG3Y3BGKdLAXkZgXe8eqaVegepP85J29jfQXP+Ex4J4wW f5DRVj1uu46uhrK+91ibJ/Qoh/Wdl5h8A9e1yvx7KblfwGKSPN1p7FtD5DacL7bgsY bAAb76iuVq9v3SVtpYnL5fHylRspCQ0oV8ADQ30k= Message-ID: <8ebc8e37878820424f70043045fe32c460fa39da.camel@nic.cz> From: Ladislav Lhotka To: Radek =?UTF-8?Q?Krej=C4=8D=C3=AD?= , Martin Bjorklund Cc: FRANK RIMPLER , YANG Doctors , netmod@ietf.org Date: Fri, 13 Apr 2018 17:00:47 +0200 In-Reply-To: References: <20160225.161659.2204602310947308417.mbj@tail-f.com> <20160225.163105.511576225570588684.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] [yang-doctors] Clarification needed for YANG 1.1 XPATH context X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 15:00:53 -0000 On Fri, 2018-04-13 at 13:51 +0200, Radek Krejčí wrote: > Hi, > I'm refreshing an old thread to clarify specific use case, see below... > > Dne 25.2.2016 v 16:31 Martin Bjorklund napsal(a): > > William Ivory wrote: > > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: 25 February 2016 15:17 > > > To: William Ivory > > > Cc: netmod@ietf.org > > > Subject: Re: [netmod] Clarification needed for YANG 1.1 XPATH context > > > > > > William Ivory wrote: > > > > Hi, > > > > > > > > I'm looking for clarification on the meaning of the following > > > > paragraph in section 6.4.1 (XPATH context) in RFC6020bis: > > > > > > > > 'If a node that exists in the accessible tree has a non-presence > > > > container as a child, then the non-presence container also exists in > > > > the tree.' > > > > > > > > It's unclear to me what this is trying to say, and why - for example, > > > > does this mean that I need to validate any 'must' and 'when' > > > > statements on the child container even when nothing within that child > > > > container is configured? > > > > > > must expressions are always evaluated if the node where the must > > > expression is defined exists, regardless of the number of children > > > this node has. > > > > > > [wivory] So in my example where the child container (non-presence) has > > > NO children, then it doesn't exist, and any must statement on it > > > should not be run. Only when a non-presence container has a non-zero > > > number of children should any 'must' statements on that container be > > > run. > > > > > > [wivory] If that's the case, then would it be correct to say that the > > > intention of this paragraph is as a reminder that one must evaluate > > > 'must' statements on nodes that have no inherent meaning and exist > > > only because they contain child nodes? > > > > No; section 7.5.3 says: > > > > When a datastore is validated, all "must" constraints are > > conceptually evaluated once for each node in the accessible tree (see > > Section 6.4.1). > > > > And the quoted paragraph of 6.4.1 says that the NP-container > > (conceptually) exists if its parent exists - regardless of number of > > children. > > > > So if the parent exists, any must expressions in the NP-container are > > evaluated. > > > > what about top-level NP-container with must constraint? Is a root node > something which is always present in accessible tree (even in an empty tree)? > Intuitively, I believe that it is, so even constraints on top-level NP- > containers are supposed to be evaluated, but I cannot find something about it > in RFC. Yes, this follows already from XPath 1.0 spec, section 5. Lada > > Regards, > Radek > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 13 08:49:06 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC36126DD9 for ; Fri, 13 Apr 2018 08:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTZVA81qhtgv for ; Fri, 13 Apr 2018 08:49:04 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DDC1243F3 for ; Fri, 13 Apr 2018 08:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23; q=dns/txt; s=iport; t=1523634543; x=1524844143; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=BXNUh2LQj+ICKxIUhUaIFwSIRsV1f+OychdpFH5lec4=; b=dzk4OWnD3DTiRDqtfdS6jiggIXcYLcYJOg9CH/S+c5bGo5vYmLqXwnrx OqYrMBS3/1sOAOW1jQvlEM7rqIUCRZcTmGhPGTA6C5tQDSGUr+EvDPg9s 0MdQ1CKmGbeBhc/vMC8tYT3urCvmtUjrXzFnPWPR0fqGBdMRAlWmGEAwQ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHBACu0NBa/xbLJq1cHAEBAQQBAQo?= =?us-ascii?q?BAYUdhAyIYI4HgTCLM4kfEQuEegGCWDcVAQIBAQEBAQECbCiFQgqBCwImAl8?= =?us-ascii?q?NCAEBhQmoY4IciEWCL4EJiQ6BMgyKT4JUApdeCI40BoElAYYfhQKQF4ElMiK?= =?us-ascii?q?BUjMaCBsVgn+QTz2PKAEB?= X-IronPort-AV: E=Sophos;i="5.48,446,1517875200"; d="scan'208";a="3178188" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2018 15:49:00 +0000 Received: from [10.61.83.172] (ams3-vpn-dhcp5037.cisco.com [10.61.83.172]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w3DFmxdA027901 for ; Fri, 13 Apr 2018 15:48:59 GMT To: netmod WG From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF Message-ID: <954c4999-6401-eb2d-c7a3-1cd930a5b7ed@cisco.com> Date: Fri, 13 Apr 2018 17:48:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [netmod] draft-ietf-netmod-acl-model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 15:49:05 -0000 status on this draft? From nobody Mon Apr 16 05:56:25 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7C912D941 for ; Mon, 16 Apr 2018 05:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChFo17FHKHPY for ; Mon, 16 Apr 2018 05:56:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C340C120227 for ; Mon, 16 Apr 2018 05:56:22 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 6158C1AE00A0 for ; Mon, 16 Apr 2018 14:56:21 +0200 (CEST) Date: Mon, 16 Apr 2018 14:56:17 +0200 (CEST) Message-Id: <20180416.145617.1262098657698751846.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 12:56:24 -0000 Hi, While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that it is not clear what, if any, restrictions should be enforced for yang-data structures. Even among the authors we have different ideas for how this should work. Background: In 8040, the original yang-data extension had a restriction that said that a yang-data structure MUST have exactly one container, since it wouldn't be possible to have a yang-data structure in an XML instance document otherwise. Since people want to use yang-data structures in other places, this restriction was lifted in the new draft: There is no longer an assumption that a yang data structure can only be used as a top-level abstraction, instead of nested within some other data structure. With this in mind, here's a use case that I think we ought to support: rpc my-first-rpc { description "Bla bla... If an error occurs, will contain an instance of the yang-data structure 'my-first-rpc-error-info'."; ... } yang-data my-first-rpc-error-info { leaf reason { ... } container user-info { ... } } rpc my-second-rpc { description "Bla bla... If an error occurs, will contain an instance of the yang-data structure 'my-second-rpc-error-info'."; ... } yang-data my-second-rpc-error-info { leaf reason { ... } leaf important-url { ... } } (maybe in the future we could even have a YANG extension statement to formalize the description: rpc my-first-rpc { ... opx:error-info-structure my-first-rpc-error-info; } but this is not point now.) In the example above, note that the leaf "reason" is present in both structures. IMO this is not a problem, since these structures are used in different contexts. My point is that I think we should impose as few restrictions as possible to the yang-data extension. It should be up to the user of yang-data to ensure that the structure is defined in such a way so that it can be used properly. For example, a structure that is supposed to describe an XML instance document cannot define two leafs at the top level. If the WG agrees with what I wrote above, we need to change the augment-yang-data extension so that you would write for example: yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { ... } Comments? /martin From nobody Mon Apr 16 06:34:29 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6FE12D864 for ; Mon, 16 Apr 2018 06:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKKtSXvL_cLr for ; Mon, 16 Apr 2018 06:34:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4968B126FDC for ; Mon, 16 Apr 2018 06:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3139; q=dns/txt; s=iport; t=1523885666; x=1525095266; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=HEECFSiYGrUA5ih2IXrg0+EkS7VzYHcUBVgJaCMVGvs=; b=RiyBhlXwPxmwc4t9pIDtdRCbRQRhYFdJOcjaPAoEq9a8mKVx0xHK7o8O iKHQwoFKmUOkWBJwb8m8k+Cu9knXz2Kx9mdQBt8AhAbD8P1q/NMrhAfDN 2fq+VjyCnQlmRal+mMiW3LQNyxEB+krJswZ0g76Bo+Lre6Dg6W5To0Vcw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClBADDpdRa/4ENJK1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYNCgVuED5UTgUspgQ+SaIF7C4UDAoJDITYWAQIBAQEBAQECbCi?= =?us-ascii?q?FIwEFIw8BVgsOCgICJgICVwYBDAgBAYUJpU+CHIg8gi+BCYZ9gVQ/gQ8jgmi?= =?us-ascii?q?Hc4JUApdkCI41BodHhQSQH4ElIgExgVJNIxWCf4IfF44zI45oAQE?= X-IronPort-AV: E=Sophos;i="5.48,459,1517875200"; d="scan'208";a="382055691" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2018 13:33:24 +0000 Received: from [10.82.174.138] ([10.82.174.138]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w3GDXOOc007765; Mon, 16 Apr 2018 13:33:24 GMT To: Martin Bjorklund , netmod@ietf.org References: <20180416.145617.1262098657698751846.mbj@tail-f.com> From: Joe Clarke Openpgp: preference=signencrypt Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDyDmj4RBADa/Icz5Xl+cJUGNxC/tWgXWqcA9VA8GN+PeqKhXS0BnVHntdsQxbpFUUKK 4ld0Zex/Rec1jgC/ikExJHHIee8ZVcHqP+tsWexi83/ZvEdzI95diBp2Is5fYp8P8hdIBNQS Ooc1jVYrTJUaZgJK2uBzbkh/WbipwsQbueRzXqPORwCgsPNrStLzqOpjrA7FdUz/JVQf5+8D /1SiKAOFiW4TxY+fS09lqiLs3mbXjvw23iQwLxje4vBd4+b9iAUWOsSretSKv6OE9ZlD4FYe a8HmMgEkuKfXGc8GvTq4J1uHZ0gcVbrBGmxAUBPPaAENYEJfJf7dcysKVAl14ZQVIvzAGJAZ HGuegD7uekGKnOEA61R3ze4aM2zNA/96I77l0qiMc6J7gXmiD5uxC7FsSCFj5sqTYMgBqzIY EZjU/tTUbth84xcRi4X0WNkaILqq1mOcBfmzQMvzG1n1CydmJU6iF1ewle6cIui9TQYg5CES rJF7xid4vVXRz+xi6hc1+0bSaoJa3sfpNrSSr0lKGdWHZozWdQjOvTMCXc1CSm9lIE1hcmN1 cyBDbGFya2UgKEZyZWVCU0QgY29tbWl0dGVyIGFkZHJlc3MpIDxtYXJjdXNARnJlZUJTRC5v cmc+wl8EExECABcFAjyuLU0FCwcKAwQDFQMCAxYCAQIXgAASCRBvaI+K/hTPhwdlR1BHAAEB 7U0AoICIVoBe9B8bo1lrvHh+UF7GY/WaAJ9C2mCThFrmqxCr2bCtR12UoPCPqs7ATQQ8g5pA EAQAqk1J4LBDLeWs6ZOkPDYYcKCSAu0qlzEf5YP/TcSeZcjJyXILgesFXcayoy1v7ILPQSXj 4p5uzRyn0fuGqiTvajjxMZz1aSkvgGyS+gc+PDmi4SJ2N/tX2isrul8MK+NGeUsLuZaM1JKh gKpq9yuu3D3ELG7ESga7xsOs1V/sSd8AAwUD/20XByIlsUUC/65KG/DQ1WfX2gNuy5If9tSP Q6h1Lno5Hv3ow3ktybIoQSxbcBo28nA/Gzg5NFGVkkqfOkH2xtS6V0K/WjzsrloBHCPFiKp2 yHpXfKubxl8yefQPTMj8hLwlBKrNiN1fz5/629TIkEwDwrUwHxQreE7FAzPMqHORwkYEGBEC AAYFAjyDmkAACgkQb2iPiv4Uz4cnuQCfX1zNrahRTWz/HRpF7ms8qZqzdOIAn1uuu6Jst43p DzanBHUOBzUP6ymA Organization: Cisco Message-ID: Date: Mon, 16 Apr 2018 09:33:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180416.145617.1262098657698751846.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 13:34:28 -0000 On 4/16/18 08:56, Martin Bjorklund wrote: > Hi, > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > it is not clear what, if any, restrictions should be enforced for > yang-data structures. Even among the authors we have different ideas > for how this should work. > > Background: > > In 8040, the original yang-data extension had a restriction that said > that a yang-data structure MUST have exactly one container, since it > wouldn't be possible to have a yang-data structure in an XML instance > document otherwise. > > Since people want to use yang-data structures in other places, this > restriction was lifted in the new draft: > > There is no longer an assumption that a yang data structure can > only be used as a top-level abstraction, instead of nested within > some other data structure. > > > With this in mind, here's a use case that I think we ought to support: > > rpc my-first-rpc { > description > "Bla bla... > If an error occurs, will contain an instance of > the yang-data structure 'my-first-rpc-error-info'."; > ... > } > > yang-data my-first-rpc-error-info { > leaf reason { ... } > container user-info { ... } > } > > rpc my-second-rpc { > description > "Bla bla... > If an error occurs, will contain an instance of > the yang-data structure 'my-second-rpc-error-info'."; > ... > } > > yang-data my-second-rpc-error-info { > leaf reason { ... } > leaf important-url { ... } > } > > (maybe in the future we could even have a YANG extension statement to > formalize the description: > > rpc my-first-rpc { > ... > opx:error-info-structure my-first-rpc-error-info; > } > > but this is not point now.) > > In the example above, note that the leaf "reason" is present in both > structures. IMO this is not a problem, since these structures are > used in different contexts. > > My point is that I think we should impose as few restrictions as > possible to the yang-data extension. It should be up to the user of > yang-data to ensure that the structure is defined in such a way so > that it can be used properly. For example, a structure that is > supposed to describe an XML instance document cannot define two leafs > at the top level. > > If the WG agrees with what I wrote above, we need to change the > augment-yang-data extension so that you would write for example: > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > ... > } > > Comments? I found the "single container only" policy to be too restricting. I was modeling data that would [typically] be serialized to something other than XML, and this just made me jump through more hoops than I wanted to use rc:yang-data. I agree with your laissez-faire proposal here. I think there should be some text to the same effect about how it is up to the author of the yd:yang-data elements to make sure the modeled data can be encoded as they require. Joe From nobody Mon Apr 16 07:36:24 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BBC12DA1A for ; Mon, 16 Apr 2018 07:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaeXRbx-FUH3 for ; Mon, 16 Apr 2018 07:36:20 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABA41200C5 for ; Mon, 16 Apr 2018 07:36:20 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id p142-v6so22439104lfd.6 for ; Mon, 16 Apr 2018 07:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fg6iiBL9cilfTY9sjsq0V44VUl7EVofMLENtiTzKciU=; b=I+9TdsRUqTeheaO9F29F6/l6tNSS2+4N9cxehhDfNHJSS+Nw+kbs51xKWrZPFroYfG diWTfBR6Dt+v8Xfu+xJTlnXObe4jRarpNubFEgyQNOzkdIgskxzvi2A6ZvqilKOzOPSF RzxMsGFN3Lu/wgVMgsmHm3gRVV/Sz7ytAOieFLJeKexHnJZpUOB559WBXg8iuPogStlQ wegmiSnhBPJucb4WBY2bnuil5gXR6LFfgAUViqJGzeSrlTqPZPMvZTM/GkKpfB8WPqsa /OmNrbHgHPpuSnfOZnmKKzM24MNA1Rpx6Tt3acajgSA9VRB4F3NV26RfAt24dZmXW8xE L3NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fg6iiBL9cilfTY9sjsq0V44VUl7EVofMLENtiTzKciU=; b=qqcsMjQVJknsRHpzGAat7gKGBNXLv9MeVdQ3Dry7GZp3r0l3XmcEGYWyv9+SKzWVMh LeXSvF3qG/wVunOTFVS3TkSehDA7wzwsmzbnqOLKAHG8ffNadrwzkJJHiGFxybq03fde zNaOpxZHd/4kCZMedIXjeCCFIzSBayhXNoLx43sA9q7aVm+P4UBum3n2C3fhkobLeeVZ 0O9iXOIr3kQtmX6N7jpCxKX0HFoNCL3a3PaU6ACeYEP1J0H7N1zLP3AWLE8bacIyxErq B7HYkETfMTgvnVl92XZ8l2IOAxt/ZRhuli5Aj3A3mfAEEpZ8ko9jXdGbLAvoNxOQYCoG wr9Q== X-Gm-Message-State: ALQs6tBRi5HI5eB+AD4pCcRXtZ5iQ9ycB8eoS1z2piW46oKjRGTMDA/P 3oh0lpazyeu0AWxt3rvb4LmAHO2k0Bx5UYIY9/6xtw== X-Google-Smtp-Source: AIpwx4/kPCDchjyz6vHL83su7wD7g/ESf+ZyeDcgqewLjVq4MjRwK2ZVhHTOMJfyiSu9kqtOnHdxLsila8H+C/8it/E= X-Received: by 2002:a19:d720:: with SMTP id o32-v6mr14377413lfg.89.1523889378221; Mon, 16 Apr 2018 07:36:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 16 Apr 2018 07:36:16 -0700 (PDT) In-Reply-To: <20180416.145617.1262098657698751846.mbj@tail-f.com> References: <20180416.145617.1262098657698751846.mbj@tail-f.com> From: Andy Bierman Date: Mon, 16 Apr 2018 07:36:16 -0700 Message-ID: To: Martin Bjorklund Cc: NetMod WG Content-Type: multipart/alternative; boundary="00000000000011030b0569f8252f" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 14:36:23 -0000 --00000000000011030b0569f8252f Content-Type: text/plain; charset="UTF-8" Hi, I am strongly opposed to this change because it breaks the rule in YANG 1.1 that there cannot be 2 sibling nodes defined in the same module namespace. IMO since any yang-data nodes are ALLOWED to be used at the top-level, then these top-level nodes cannot have conflicting names. It is very important when parsing an instance document that the instance data can be associated with the correct schema. This is not possible if the same top-level node has multiple yang-data nodes defined. If one needs to define data that is not top-level, (1) use augment-yang-data or (2) use a different module. Andy On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund wrote: > Hi, > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > it is not clear what, if any, restrictions should be enforced for > yang-data structures. Even among the authors we have different ideas > for how this should work. > > Background: > > In 8040, the original yang-data extension had a restriction that said > that a yang-data structure MUST have exactly one container, since it > wouldn't be possible to have a yang-data structure in an XML instance > document otherwise. > > Since people want to use yang-data structures in other places, this > restriction was lifted in the new draft: > > There is no longer an assumption that a yang data structure can > only be used as a top-level abstraction, instead of nested within > some other data structure. > > > With this in mind, here's a use case that I think we ought to support: > > rpc my-first-rpc { > description > "Bla bla... > If an error occurs, will contain an instance of > the yang-data structure 'my-first-rpc-error-info'."; > ... > } > > yang-data my-first-rpc-error-info { > leaf reason { ... } > container user-info { ... } > } > > rpc my-second-rpc { > description > "Bla bla... > If an error occurs, will contain an instance of > the yang-data structure 'my-second-rpc-error-info'."; > ... > } > > yang-data my-second-rpc-error-info { > leaf reason { ... } > leaf important-url { ... } > } > > (maybe in the future we could even have a YANG extension statement to > formalize the description: > > rpc my-first-rpc { > ... > opx:error-info-structure my-first-rpc-error-info; > } > > but this is not point now.) > > In the example above, note that the leaf "reason" is present in both > structures. IMO this is not a problem, since these structures are > used in different contexts. > > My point is that I think we should impose as few restrictions as > possible to the yang-data extension. It should be up to the user of > yang-data to ensure that the structure is defined in such a way so > that it can be used properly. For example, a structure that is > supposed to describe an XML instance document cannot define two leafs > at the top level. > > If the WG agrees with what I wrote above, we need to change the > augment-yang-data extension so that you would write for example: > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > ... > } > > Comments? > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000011030b0569f8252f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am strongly opposed to this chang= e because it breaks the rule in YANG 1.1
that there cannot be 2 s= ibling nodes defined in the same module namespace.

IMO since any yang-data nodes are ALLOWED to be used at the top-level,
then these top-level nodes cannot have conflicting names.
=
It is very important when parsing an instance document that = the instance data
can be associated with the correct schema.=C2= =A0 This is not possible if the
same top-level node has multiple = yang-data nodes defined.

If one needs to define da= ta that is not top-level, (1) use augment-yang-data
or (2) use a = different module.


Andy


On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund <mbj@tail-f.com<= /a>> wrote:
Hi,

While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that=
it is not clear what, if any, restrictions should be enforced for
yang-data structures.=C2=A0 Even among the authors we have different ideas<= br> for how this should work.

Background:

In 8040, the original yang-data extension had a restriction that said
that a yang-data structure MUST have exactly one container, since it
wouldn't be possible to have a yang-data structure in an XML instance document otherwise.

Since people want to use yang-data structures in other places, this
restriction was lifted in the new draft:

=C2=A0 =C2=A0There is no longer an assumption that a yang data structure ca= n
=C2=A0 =C2=A0only be used as a top-level abstraction, instead of nested wit= hin
=C2=A0 =C2=A0some other data structure.


With this in mind, here's a use case that I think we ought to support:<= br>
=C2=A0 rpc my-first-rpc {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "Bla bla...
=C2=A0 =C2=A0 =C2=A0 =C2=A0If an error occurs, <error-info> will cont= ain an instance of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the yang-data structure 'my-first-rpc-error-= info'.";
=C2=A0 =C2=A0 ...
=C2=A0 }

=C2=A0 yang-data my-first-rpc-error-info {
=C2=A0 =C2=A0 leaf reason { ... }
=C2=A0 =C2=A0 container user-info { ... }
=C2=A0 }

=C2=A0 rpc my-second-rpc {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "Bla bla...
=C2=A0 =C2=A0 =C2=A0 =C2=A0If an error occurs, <error-info> will cont= ain an instance of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the yang-data structure 'my-second-rpc-error= -info'.";
=C2=A0 =C2=A0 ...
=C2=A0 }

=C2=A0 yang-data my-second-rpc-error-info {
=C2=A0 =C2=A0 leaf reason { ... }
=C2=A0 =C2=A0 leaf important-url { ... }
=C2=A0 }

(maybe in the future we could even have a YANG extension statement to
formalize the description:

=C2=A0 =C2=A0rpc my-first-rpc {
=C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0opx:error-info-structure my-first-rpc-error-info;
=C2=A0 =C2=A0}

but this is not point now.)

In the example above, note that the leaf "reason" is present in b= oth
structures.=C2=A0 IMO this is not a problem, since these structures are
used in different contexts.

My point is that I think we should impose as few restrictions as
possible to the yang-data extension.=C2=A0 It should be up to the user of yang-data to ensure that the structure is defined in such a way so
that it can be used properly.=C2=A0 For example, a structure that is
supposed to describe an XML instance document cannot define two leafs
at the top level.

If the WG agrees with what I wrote above, we need to change the
augment-yang-data extension so that you would write for example:

=C2=A0 yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {=
=C2=A0 =C2=A0 ...
=C2=A0 }

Comments?



/martin

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--00000000000011030b0569f8252f-- From nobody Mon Apr 16 07:53:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B57126B6E for ; Mon, 16 Apr 2018 07:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV9ngpDjNUQE for ; Mon, 16 Apr 2018 07:52:55 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E8C8012DA0D for ; Mon, 16 Apr 2018 07:52:54 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 3FE841AE00A0; Mon, 16 Apr 2018 16:52:53 +0200 (CEST) Date: Mon, 16 Apr 2018 16:52:52 +0200 (CEST) Message-Id: <20180416.165252.1949100412452419279.mbj@tail-f.com> To: andy@yumaworks.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180416.145617.1262098657698751846.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 14:52:59 -0000 Hi, Andy Bierman wrote: > Hi, > > I am strongly opposed to this change because it breaks the rule in YANG 1.1 > that there cannot be 2 sibling nodes defined in the same module namespace. > > IMO since any yang-data nodes are ALLOWED to be used at the top-level, > then these top-level nodes cannot have conflicting names. What do you mean with "used at the top-level"? Do you mean that they are allowed to be used e.g. in an XML instance document? If so, we should not allow more than one container either. > It is very important when parsing an instance document that the instance > data > can be associated with the correct schema. This is not possible if the > same top-level node has multiple yang-data nodes defined. Correct. And a structure with more than one node is also not possible to use in an instance document, but we still allow it. There is no requirement that a yang-data structure MUST be used as a single instance document. My point is that it should be up to the designer that define a yang-data structure to ensure the structure can be used properly. In some cases it means that the designer uses a single container, in some cases it means that two different strcutures have unique nodes, and in other cases it might mean that all lists have keys. We should ensure that all these use cases are supported. /martin > If one needs to define data that is not top-level, (1) use augment-yang-data > or (2) use a different module. > > > Andy > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund wrote: > > > Hi, > > > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > > it is not clear what, if any, restrictions should be enforced for > > yang-data structures. Even among the authors we have different ideas > > for how this should work. > > > > Background: > > > > In 8040, the original yang-data extension had a restriction that said > > that a yang-data structure MUST have exactly one container, since it > > wouldn't be possible to have a yang-data structure in an XML instance > > document otherwise. > > > > Since people want to use yang-data structures in other places, this > > restriction was lifted in the new draft: > > > > There is no longer an assumption that a yang data structure can > > only be used as a top-level abstraction, instead of nested within > > some other data structure. > > > > > > With this in mind, here's a use case that I think we ought to support: > > > > rpc my-first-rpc { > > description > > "Bla bla... > > If an error occurs, will contain an instance of > > the yang-data structure 'my-first-rpc-error-info'."; > > ... > > } > > > > yang-data my-first-rpc-error-info { > > leaf reason { ... } > > container user-info { ... } > > } > > > > rpc my-second-rpc { > > description > > "Bla bla... > > If an error occurs, will contain an instance of > > the yang-data structure 'my-second-rpc-error-info'."; > > ... > > } > > > > yang-data my-second-rpc-error-info { > > leaf reason { ... } > > leaf important-url { ... } > > } > > > > (maybe in the future we could even have a YANG extension statement to > > formalize the description: > > > > rpc my-first-rpc { > > ... > > opx:error-info-structure my-first-rpc-error-info; > > } > > > > but this is not point now.) > > > > In the example above, note that the leaf "reason" is present in both > > structures. IMO this is not a problem, since these structures are > > used in different contexts. > > > > My point is that I think we should impose as few restrictions as > > possible to the yang-data extension. It should be up to the user of > > yang-data to ensure that the structure is defined in such a way so > > that it can be used properly. For example, a structure that is > > supposed to describe an XML instance document cannot define two leafs > > at the top level. > > > > If the WG agrees with what I wrote above, we need to change the > > augment-yang-data extension so that you would write for example: > > > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > > ... > > } > > > > Comments? > > > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Mon Apr 16 07:55:11 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B9F126B6E for ; Mon, 16 Apr 2018 07:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psY_n1uMpK_y for ; Mon, 16 Apr 2018 07:55:07 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FFC124319 for ; Mon, 16 Apr 2018 07:55:06 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id g203-v6so22518077lfg.11 for ; Mon, 16 Apr 2018 07:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nSS/A06gQoOiZ4RiW6z1VmWmIqMAR6nRhVHZrHP5c/8=; b=HkSsKJqz0j7c5R3CWRiSTMHhlOidYDknAc3vOw6AffFgwLqWyLGd32nYIpsoxO2xq/ SUyEdXS5LDI5SFhQhArzw9nxwgvlvpYnwlzvFJyaGr+GBSPnVkeJypCZClo+Qk4Oz4W+ X2+XflkAxIQSRTMuvL08b54oWzWTF6ctwPGhdNTnFRx+S0HBx6AU8Vb1vcr5HWbFUtY/ KMs3kQ6mLuc/WJG17jqYGnzQH0lVVrudGFJ3IXacBbQt32wekbIvGplFyKNv+B9Gk9uy 8gLBsEYjXm46xvkektJWRX+PNqGaCKHCDIz7nMMAErM0g3pLr+QhQnJKyUIdTmcZcplJ 6uSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nSS/A06gQoOiZ4RiW6z1VmWmIqMAR6nRhVHZrHP5c/8=; b=lSPUgHCw6kPcYlZ1iAOmE3tzXTuf90BTWOQosAxSOC1XockxUH0JZJ6IU+ix3kd+TC jm7poLSpMkVbTAykgywCIjdVRX6nBPL0prw9Of3v1KNLFOOjviQjmhIl/ssZrcs9tWOG Zjm0EXZgo1CWmfEL/60bkcDFjO61FiKo1r2dMNEHUMyEjnwLryF8xWTDNX0f5y7GPu1U qT1nxv0Sisdw5NlpyFjORgAIpN7SqU7bLPEmg56wYbb8M5PoItg0uHIyR1EjX2H1YgAd nDoF9HgN48P0UFeJl1L+Idio1zjwphFCk+DVbfuIGR/PDUSWdyYsVvZbldDgQOm8LwyY 5BuA== X-Gm-Message-State: ALQs6tBChVqevkwJH9PCsam59uOwVreJyuEy5bXFpV7GOGmG4jccvClJ QJ4oxA0fu5i7mYpPANcMLJ4F/zKol/hVrSBfbty6JQ== X-Google-Smtp-Source: AIpwx4+cHEPWLwc8oQAHBF0tIUijKQB7ORjsZQHJgR1wNp6X0gWHDv9v9E0qnF5FDTa7lDj6b9URzV5DLlxXcK/+8FQ= X-Received: by 2002:a19:a087:: with SMTP id j129-v6mr1011921lfe.101.1523890504719; Mon, 16 Apr 2018 07:55:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 16 Apr 2018 07:55:03 -0700 (PDT) In-Reply-To: References: <20180416.145617.1262098657698751846.mbj@tail-f.com> From: Andy Bierman Date: Mon, 16 Apr 2018 07:55:03 -0700 Message-ID: To: Joe Clarke Cc: Martin Bjorklund , NetMod WG Content-Type: multipart/alternative; boundary="0000000000003616470569f86861" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 14:55:09 -0000 --0000000000003616470569f86861 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 16, 2018 at 6:33 AM, Joe Clarke wrote: > On 4/16/18 08:56, Martin Bjorklund wrote: > > Hi, > > > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > > it is not clear what, if any, restrictions should be enforced for > > yang-data structures. Even among the authors we have different ideas > > for how this should work. > > > > Background: > > > > In 8040, the original yang-data extension had a restriction that said > > that a yang-data structure MUST have exactly one container, since it > > wouldn't be possible to have a yang-data structure in an XML instance > > document otherwise. > > > > Since people want to use yang-data structures in other places, this > > restriction was lifted in the new draft: > > > > There is no longer an assumption that a yang data structure can > > only be used as a top-level abstraction, instead of nested within > > some other data structure. > > > > > > With this in mind, here's a use case that I think we ought to support: > > > > rpc my-first-rpc { > > description > > "Bla bla... > > If an error occurs, will contain an instance of > > the yang-data structure 'my-first-rpc-error-info'."; > > ... > > } > > > > yang-data my-first-rpc-error-info { > > leaf reason { ... } > > container user-info { ... } > > } > > > > rpc my-second-rpc { > > description > > "Bla bla... > > If an error occurs, will contain an instance of > > the yang-data structure 'my-second-rpc-error-info'."; > > ... > > } > > > > yang-data my-second-rpc-error-info { > > leaf reason { ... } > > leaf important-url { ... } > > } > > > > (maybe in the future we could even have a YANG extension statement to > > formalize the description: > > > > rpc my-first-rpc { > > ... > > opx:error-info-structure my-first-rpc-error-info; > > } > > > > but this is not point now.) > > > > In the example above, note that the leaf "reason" is present in both > > structures. IMO this is not a problem, since these structures are > > used in different contexts. > > > > My point is that I think we should impose as few restrictions as > > possible to the yang-data extension. It should be up to the user of > > yang-data to ensure that the structure is defined in such a way so > > that it can be used properly. For example, a structure that is > > supposed to describe an XML instance document cannot define two leafs > > at the top level. > > > > If the WG agrees with what I wrote above, we need to change the > > augment-yang-data extension so that you would write for example: > > > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > > ... > > } > > > > Comments? > > I found the "single container only" policy to be too restricting. I was > modeling data that would [typically] be serialized to something other > than XML, and this just made me jump through more hoops than I wanted to > use rc:yang-data. > > I agree with your laissez-faire proposal here. I think there should be > some text to the same effect about how it is up to the author of the > yd:yang-data elements to make sure the modeled data can be encoded as > they require. > > How will your tool handle this? module foo { x:yang-data fake-namespace1 { container top { ... } } x:yang-data fake-namespace2 { container top { ... } } container top { ... } } You parse an artifact file: ... Current YANG says that the node can only be defined once. This makes it possible for a parser to pick the correct schema. If 2 or or more yang-data definitions have this name (foo:top) then how does your tool pick the right one.? This existing restriction in YANG serves a useful purpose. Removing it would be unwise. There is no restriction to limit the yang-data to a container. This has already been removed. My counter-proposal is to remove the argument for yang-data since it servers no purpose: x:yang-data { container top { ... } } x:yang-data { list bar { ... } } Joe > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0000000000003616470569f86861 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 16, 2018 at 6:33 AM, Joe Clarke <jclarke@cisco.com>= wrote:
On 4/16= /18 08:56, Martin Bjorklund wrote:
> Hi,
>
> While preparing draft-ietf-netmod-yang-data-ext-02, it turned out= that
> it is not clear what, if any, restrictions should be enforced for
> yang-data structures.=C2=A0 Even among the authors we have different i= deas
> for how this should work.
>
> Background:
>
> In 8040, the original yang-data extension had a restriction that said<= br> > that a yang-data structure MUST have exactly one container, since it > wouldn't be possible to have a yang-data structure in an XML insta= nce
> document otherwise.
>
> Since people want to use yang-data structures in other places, this > restriction was lifted in the new draft:
>
>=C2=A0 =C2=A0 There is no longer an assumption that a yang data structu= re can
>=C2=A0 =C2=A0 only be used as a top-level abstraction, instead of neste= d within
>=C2=A0 =C2=A0 some other data structure.
>
>
> With this in mind, here's a use case that I think we ought to supp= ort:
>
>=C2=A0 =C2=A0rpc my-first-rpc {
>=C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"Bla bla...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 If an error occurs, <error-info> will= contain an instance of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the yang-data structure 'my-first-rpc-e= rror-info'.";
>=C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0yang-data my-first-rpc-error-info {
>=C2=A0 =C2=A0 =C2=A0leaf reason { ... }
>=C2=A0 =C2=A0 =C2=A0container user-info { ... }
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0rpc my-second-rpc {
>=C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"Bla bla...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 If an error occurs, <error-info> will= contain an instance of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the yang-data structure 'my-second-rpc-= error-info'.";
>=C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0yang-data my-second-rpc-error-info {
>=C2=A0 =C2=A0 =C2=A0leaf reason { ... }
>=C2=A0 =C2=A0 =C2=A0leaf important-url { ... }
>=C2=A0 =C2=A0}
>
> (maybe in the future we could even have a YANG extension statement to<= br> > formalize the description:
>
>=C2=A0 =C2=A0 rpc my-first-rpc {
>=C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 opx:error-info-structure my-first-rpc-error-info;<= br> >=C2=A0 =C2=A0 }
>
> but this is not point now.)
>
> In the example above, note that the leaf "reason" is present= in both
> structures.=C2=A0 IMO this is not a problem, since these structures ar= e
> used in different contexts.
>
> My point is that I think we should impose as few restrictions as
> possible to the yang-data extension.=C2=A0 It should be up to the user= of
> yang-data to ensure that the structure is defined in such a way so
> that it can be used properly.=C2=A0 For example, a structure that is > supposed to describe an XML instance document cannot define two leafs<= br> > at the top level.
>
> If the WG agrees with what I wrote above, we need to change the
> augment-yang-data extension so that you would write for example:
>
>=C2=A0 =C2=A0yx:augment-yang-data /ex:my-first-rpc-error-info/ex:u= ser-info {
>=C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0}
>
> Comments?

I found the "single container only" policy to be too restricting.= =C2=A0 I was
modeling data that would [typically] be serialized to something other
than XML, and this just made me jump through more hoops than I wanted to use rc:yang-data.

I agree with your laissez-faire proposal here.=C2=A0 I think there should b= e
some text to the same effect about how it is up to the author of the
yd:yang-data elements to make sure the modeled data can be encoded as
they require.



How will your tool hand= le this?


module foo {
=C2= =A0 =C2=A0x:yang-data fake-namespace1 {
=C2=A0 =C2=A0 =C2=A0 cont= ainer top { ... }
=C2=A0 =C2=A0}

= =C2=A0 =C2=A0x:yang-data fake-namespace2 {
=C2=A0 =C2=A0 =C2=A0 c= ontainer top { ... }
=C2=A0 =C2=A0}

=C2=A0 =C2=A0container top { ... }

}
<= br>

You parse an artifact file:

<top =C2=A0xmlns=3D"module-foo-namespace">
=C2=A0 =C2=A0<next> ... </next>
</top>

Current YANG says that the <toip> node can only be = defined once.
This makes it possible for a parser to pick the cor= rect schema.
If 2 or or more yang-data definitions have this name= (foo:top)
then how does your tool pick the right one.?

This existing restriction in YANG serves a useful purpose.<= /div>
Removing it would be unwise.

There is no= restriction to limit the yang-data to a container.
This has alre= ady been removed.


My counter-propos= al is to remove the argument for yang-data
since it servers no pu= rpose:


=C2=A0 x:yang-data =C2=A0{
=C2=A0 =C2=A0 =C2=A0conta= iner top { ... }
=C2=A0 }

= =C2=A0 x:yang-data {
=C2=A0 =C2=A0 =C2=A0 list bar { ... }
=C2=A0 =C2=A0}

Joe



Andy

=C2=A0
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--0000000000003616470569f86861-- From nobody Mon Apr 16 08:02:27 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095D312DA24 for ; Mon, 16 Apr 2018 08:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQEivOXO2dPN for ; Mon, 16 Apr 2018 08:02:22 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A8C51124319 for ; Mon, 16 Apr 2018 08:02:22 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id C61351AE00A0; Mon, 16 Apr 2018 17:02:21 +0200 (CEST) Date: Mon, 16 Apr 2018 17:02:21 +0200 (CEST) Message-Id: <20180416.170221.1581228820475809080.mbj@tail-f.com> To: andy@yumaworks.com Cc: jclarke@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180416.145617.1262098657698751846.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 15:02:26 -0000 Hi, Andy Bierman wrote: > On Mon, Apr 16, 2018 at 6:33 AM, Joe Clarke wrote: > > > On 4/16/18 08:56, Martin Bjorklund wrote: > > > Hi, > > > > > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > > > it is not clear what, if any, restrictions should be enforced for > > > yang-data structures. Even among the authors we have different ideas > > > for how this should work. > > > > > > Background: > > > > > > In 8040, the original yang-data extension had a restriction that said > > > that a yang-data structure MUST have exactly one container, since it > > > wouldn't be possible to have a yang-data structure in an XML instance > > > document otherwise. > > > > > > Since people want to use yang-data structures in other places, this > > > restriction was lifted in the new draft: > > > > > > There is no longer an assumption that a yang data structure can > > > only be used as a top-level abstraction, instead of nested within > > > some other data structure. > > > > > > > > > With this in mind, here's a use case that I think we ought to support: > > > > > > rpc my-first-rpc { > > > description > > > "Bla bla... > > > If an error occurs, will contain an instance of > > > the yang-data structure 'my-first-rpc-error-info'."; > > > ... > > > } > > > > > > yang-data my-first-rpc-error-info { > > > leaf reason { ... } > > > container user-info { ... } > > > } > > > > > > rpc my-second-rpc { > > > description > > > "Bla bla... > > > If an error occurs, will contain an instance of > > > the yang-data structure 'my-second-rpc-error-info'."; > > > ... > > > } > > > > > > yang-data my-second-rpc-error-info { > > > leaf reason { ... } > > > leaf important-url { ... } > > > } > > > > > > (maybe in the future we could even have a YANG extension statement to > > > formalize the description: > > > > > > rpc my-first-rpc { > > > ... > > > opx:error-info-structure my-first-rpc-error-info; > > > } > > > > > > but this is not point now.) > > > > > > In the example above, note that the leaf "reason" is present in both > > > structures. IMO this is not a problem, since these structures are > > > used in different contexts. > > > > > > My point is that I think we should impose as few restrictions as > > > possible to the yang-data extension. It should be up to the user of > > > yang-data to ensure that the structure is defined in such a way so > > > that it can be used properly. For example, a structure that is > > > supposed to describe an XML instance document cannot define two leafs > > > at the top level. > > > > > > If the WG agrees with what I wrote above, we need to change the > > > augment-yang-data extension so that you would write for example: > > > > > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > > > ... > > > } > > > > > > Comments? > > > > I found the "single container only" policy to be too restricting. I was > > modeling data that would [typically] be serialized to something other > > than XML, and this just made me jump through more hoops than I wanted to > > use rc:yang-data. > > > > I agree with your laissez-faire proposal here. I think there should be > > some text to the same effect about how it is up to the author of the > > yd:yang-data elements to make sure the modeled data can be encoded as > > they require. > > > > > > How will your tool handle this? > > > module foo { > x:yang-data fake-namespace1 { > container top { ... } > } > > x:yang-data fake-namespace2 { > container top { ... } > } > > container top { ... } > > } > > > You parse an artifact file: > > > ... > If the yang-data structures are supposed be used in instance documents w/ no additional context information, then the designer should not use two nodes with the same name in different strcuctures, just like he wouldn't use two top-level containers. But as my original email demonstrated, there are cases where the context provides the information which structure to use.n > Current YANG says that the node can only be defined once. > This makes it possible for a parser to pick the correct schema. > If 2 or or more yang-data definitions have this name (foo:top) > then how does your tool pick the right one.? > > This existing restriction in YANG serves a useful purpose. > Removing it would be unwise. > > There is no restriction to limit the yang-data to a container. > This has already been removed. > > > My counter-proposal is to remove the argument for yang-data > since it servers no purpose: > > > x:yang-data { > container top { ... } > } > > x:yang-data { > list bar { ... } > } I think this would be a mistake. It wouldn't even be possible to talk about the different structures in a module. For example, the subscribed notification draft has this: These are the following three yang-data structures for failed event stream subscriptions: 1. "establish-subscription-stream-error-info": This MUST be returned ... And it would be impossible to add an extension like: opx:error-info-structure my-first-rpc-error-info; (see my original email for details) /martin > > Joe > > > > > > Andy > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Mon Apr 16 08:44:35 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1A312706D for ; Mon, 16 Apr 2018 08:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ebF9V6AqGFp for ; Mon, 16 Apr 2018 08:44:30 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14D5126DEE for ; Mon, 16 Apr 2018 08:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15338; q=dns/txt; s=iport; t=1523893470; x=1525103070; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=1T6tv+Abr+GgPvqUtoUX5N/UUq8bky/3SNZwCvIu0ks=; b=EoGez2qyf+8qGarcvTgHcHVJFOn9rcwvTccfDLIKY3v4XomzXw0WbWgg KoM9ZO30kHxUyTwhmkzPcuF5/wIztkMDUWhQiKAKZnFsx6HxRM8X+XrLk RR5lgYDiIPNG/+ivMc8pcW8pj6G6p4HDhdpMHsyMAaJdAnkIgpb7R7qdF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AxAgCaxNRa/xbLJq0ZAUIZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgk1GgRAXYyiDZ4gCXo1/CCGBD41+hGqBewsYAQqEFUs?= =?us-ascii?q?CgmU0GAECAQEBAQEBAmwcDIUjAQEBAwEBIUsbCQIYJwMCAicfEQYBDAYCAQE?= =?us-ascii?q?XhHIPiRZum0CCHB+EOINmgioFiVo/gQ8jDIJcgxEBAYRgglQCjASLYAiONQa?= =?us-ascii?q?HR4UEin+FIIElHDgmgSwzGggbFTuCQ4FwMBeIWYU/PjCOOAEB?= X-IronPort-AV: E=Sophos;i="5.48,459,1517875200"; d="scan'208,217";a="3175051" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2018 15:44:09 +0000 Received: from [10.63.23.73] (dhcp-ensft1-uk-vla370-10-63-23-73.cisco.com [10.63.23.73]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w3GFi9op023348; Mon, 16 Apr 2018 15:44:09 GMT To: Andy Bierman , Martin Bjorklund , NetMod WG References: <20180416.145617.1262098657698751846.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Mon, 16 Apr 2018 16:44:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F3AD200D7A5971CBE5583381" Content-Language: en-US Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 15:44:33 -0000 This is a multi-part message in MIME format. --------------F3AD200D7A5971CBE5583381 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Don't groupings have a somewhat similar concern?  E.g. if two groupings define the same data node name and are used at the same point then you would get a namespace clash, but YANG does not disallow the groupings: grouping foo_widget { leaf name { type string; description "Name of my foo widget";  } } grouping bar_widget { leaf name { type string; description "Name of my bar widget";  } } container all_widgets { uses foo_widget; uses bar_widget;   } The principal difference here, is that the compiler can easily check and reject the conflict at the uses statements. Hence I think that it would be good if we could find a solution for yang-data-ext that doesn't not require all root yang-data nodes to be unique, since that feels somewhat clunky.  I.e. my preference is to keep them less restrictive, as Martin has proposed, if this is feasible. Thanks, Rob On 16/04/2018 15:36, Andy Bierman wrote: > Hi, > > I am strongly opposed to this change because it breaks the rule in > YANG 1.1 > that there cannot be 2 sibling nodes defined in the same module namespace. > > IMO since any yang-data nodes are ALLOWED to be used at the top-level, > then these top-level nodes cannot have conflicting names. > > It is very important when parsing an instance document that the > instance data > can be associated with the correct schema.  This is not possible if the > same top-level node has multiple yang-data nodes defined. > > If one needs to define data that is not top-level, (1) use > augment-yang-data > or (2) use a different module. > > > Andy > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund > wrote: > > Hi, > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > it is not clear what, if any, restrictions should be enforced for > yang-data structures.  Even among the authors we have different ideas > for how this should work. > > Background: > > In 8040, the original yang-data extension had a restriction that said > that a yang-data structure MUST have exactly one container, since it > wouldn't be possible to have a yang-data structure in an XML instance > document otherwise. > > Since people want to use yang-data structures in other places, this > restriction was lifted in the new draft: > >    There is no longer an assumption that a yang data structure can >    only be used as a top-level abstraction, instead of nested within >    some other data structure. > > > With this in mind, here's a use case that I think we ought to support: > >   rpc my-first-rpc { >     description >       "Bla bla... >        If an error occurs, will contain an instance of >        the yang-data structure 'my-first-rpc-error-info'."; >     ... >   } > >   yang-data my-first-rpc-error-info { >     leaf reason { ... } >     container user-info { ... } >   } > >   rpc my-second-rpc { >     description >       "Bla bla... >        If an error occurs, will contain an instance of >        the yang-data structure 'my-second-rpc-error-info'."; >     ... >   } > >   yang-data my-second-rpc-error-info { >     leaf reason { ... } >     leaf important-url { ... } >   } > > (maybe in the future we could even have a YANG extension statement to > formalize the description: > >    rpc my-first-rpc { >      ... >      opx:error-info-structure my-first-rpc-error-info; >    } > > but this is not point now.) > > In the example above, note that the leaf "reason" is present in both > structures.  IMO this is not a problem, since these structures are > used in different contexts. > > My point is that I think we should impose as few restrictions as > possible to the yang-data extension.  It should be up to the user of > yang-data to ensure that the structure is defined in such a way so > that it can be used properly.  For example, a structure that is > supposed to describe an XML instance document cannot define two leafs > at the top level. > > If the WG agrees with what I wrote above, we need to change the > augment-yang-data extension so that you would write for example: > >   yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { >     ... >   } > > Comments? > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------F3AD200D7A5971CBE5583381 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Don't groupings have a somewhat similar concern?

 E.g. if two groupings define the same data node name and are used at the same point then you would get a namespace clash, but YANG does not disallow the groupings:

     grouping foo_widget {
       leaf name {
         type string;
         description "Name of my foo widget";
       }
     }

     grouping bar_widget {
       leaf name {
         type string;
         description "Name of my bar widget";
       }
     }


     container all_widgets {
       uses foo_widget;
       uses bar_widget;
     }

The principal difference here, is that the compiler can easily check and reject the conflict at the uses statements.

Hence I think that it would be good if we could find a solution for yang-data-ext that doesn't not require all root yang-data nodes to be unique, since that feels somewhat clunky.  I.e. my preference is to keep them less restrictive, as Martin has proposed, if this is feasible.

Thanks,
Rob


On 16/04/2018 15:36, Andy Bierman wrote:
Hi,

I am strongly opposed to this change because it breaks the rule in YANG 1.1
that there cannot be 2 sibling nodes defined in the same module namespace.

IMO since any yang-data nodes are ALLOWED to be used at the top-level,
then these top-level nodes cannot have conflicting names.

It is very important when parsing an instance document that the instance data
can be associated with the correct schema.  This is not possible if the
same top-level node has multiple yang-data nodes defined.

If one needs to define data that is not top-level, (1) use augment-yang-data
or (2) use a different module.


Andy



On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
it is not clear what, if any, restrictions should be enforced for
yang-data structures.  Even among the authors we have different ideas
for how this should work.

Background:

In 8040, the original yang-data extension had a restriction that said
that a yang-data structure MUST have exactly one container, since it
wouldn't be possible to have a yang-data structure in an XML instance
document otherwise.

Since people want to use yang-data structures in other places, this
restriction was lifted in the new draft:

   There is no longer an assumption that a yang data structure can
   only be used as a top-level abstraction, instead of nested within
   some other data structure.


With this in mind, here's a use case that I think we ought to support:

  rpc my-first-rpc {
    description
      "Bla bla...
       If an error occurs, <error-info> will contain an instance of
       the yang-data structure 'my-first-rpc-error-info'.";
    ...
  }

  yang-data my-first-rpc-error-info {
    leaf reason { ... }
    container user-info { ... }
  }

  rpc my-second-rpc {
    description
      "Bla bla...
       If an error occurs, <error-info> will contain an instance of
       the yang-data structure 'my-second-rpc-error-info'.";
    ...
  }

  yang-data my-second-rpc-error-info {
    leaf reason { ... }
    leaf important-url { ... }
  }

(maybe in the future we could even have a YANG extension statement to
formalize the description:

   rpc my-first-rpc {
     ...
     opx:error-info-structure my-first-rpc-error-info;
   }

but this is not point now.)

In the example above, note that the leaf "reason" is present in both
structures.  IMO this is not a problem, since these structures are
used in different contexts.

My point is that I think we should impose as few restrictions as
possible to the yang-data extension.  It should be up to the user of
yang-data to ensure that the structure is defined in such a way so
that it can be used properly.  For example, a structure that is
supposed to describe an XML instance document cannot define two leafs
at the top level.

If the WG agrees with what I wrote above, we need to change the
augment-yang-data extension so that you would write for example:

  yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
    ...
  }

Comments?



/martin

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--------------F3AD200D7A5971CBE5583381-- From nobody Mon Apr 16 09:07:11 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E724A12E8C7 for ; Mon, 16 Apr 2018 09:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hx2fc0PzKvSv for ; Mon, 16 Apr 2018 09:07:07 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEABA12E8C3 for ; Mon, 16 Apr 2018 09:07:06 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id g203-v6so22885549lfg.11 for ; Mon, 16 Apr 2018 09:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1UK8zmfGh51nRaNdjb00Jd1rqAicHCGwQVB/iLIRHYo=; b=mkahOZLTdcwUbz/atzRYAPG4d88rd9tM7SCWBZC3wNBVBVzA4fWsAwSbeNLDQnWJYo d7k/WCc5dcMgwNQjW+kUR6ab1lhaNIB2QT4mrilJMb+pXmad2T757hztAhCcevuudSkM MQ1PCgjhW1/3kVeKP0U+sYT17QbE74HiRYXD9O3MvZqHUFNsVTWdmPdxUxkbh8gU2T5I 7/2/4Bt9R2yLQJrAy8/Peq+vXfNNOXimt+U3GYB7mg5Ns8XJdZByGX0n3huCh3iVV6F4 WykuTswgD83jHF7kU1lmb0EvF3P81QAx6sgAfARla8KAgU2DdkX9f4SK/PYecbR+60j+ Qzqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1UK8zmfGh51nRaNdjb00Jd1rqAicHCGwQVB/iLIRHYo=; b=ZNE59+IBPjTREl9AkZzh318lMLuMKMLrVItGf4dgVrteTqU8pL1JUQNnpggt0VTpB2 AVcyS9v6NoUnFX058lgwNId+FT0LZcl+z/eAUgc0IM97TykNJZToLeAqMKuYKm0/z3k3 IAfuLHuGRZgYeG9OTRfSPqiFIsCRChDFPAlpo2LoIzqfmScZwTfsQbqN1d3WHg0kDRec Xb6qSS3/oOwrHQmIjZkTL6rxJVY0vkGr7z3p2RY4/oESMvBYm8c8R2vGyrI/8YFbrC/d EW0i5QXaBaM1+Cq5DCEey649TT73FhJwViWgtAJT3XnMwYCYRd5VAVXItXmWfObKXR4j +BOQ== X-Gm-Message-State: ALQs6tAu6Q9DcgkcUoTwTlQlqmXqc1R5jLXKo+mRpGYUuyUNsfp4uRK7 Vr66KtwoWXRZ0Vi0CUNxGg0WD+eZDsu80hFveuRAdw== X-Google-Smtp-Source: AIpwx49XiuO7g4XKlvhJDmYwiynSlZtAwzcXdWO4/9YRnFNGTRWIu5oHGljQZFQaEjUTeyvKoxiUulU/RqyCzC5m0qM= X-Received: by 2002:a19:4c46:: with SMTP id z67-v6mr4151149lfa.141.1523894825185; Mon, 16 Apr 2018 09:07:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 16 Apr 2018 09:07:04 -0700 (PDT) In-Reply-To: References: <20180416.145617.1262098657698751846.mbj@tail-f.com> From: Andy Bierman Date: Mon, 16 Apr 2018 09:07:04 -0700 Message-ID: To: Robert Wilton Cc: Martin Bjorklund , NetMod WG Content-Type: multipart/alternative; boundary="000000000000bb0d7e0569f96936" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 16:07:10 -0000 --000000000000bb0d7e0569f96936 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton wrote: > Don't groupings have a somewhat similar concern? > > E.g. if two groupings define the same data node name and are used at the > same point then you would get a namespace clash, but YANG does not disallow > the groupings: > > grouping foo_widget { > leaf name { > type string; > description "Name of my foo widget"; > } > } > > grouping bar_widget { > leaf name { > type string; > description "Name of my bar widget"; > } > } > > > container all_widgets { > uses foo_widget; > uses bar_widget; > } > > > The principal difference here, is that the compiler can easily check and > reject the conflict at the uses statements. > > Hence I think that it would be good if we could find a solution for > yang-data-ext that doesn't not require all root yang-data nodes to be > unique, since that feels somewhat clunky. I.e. my preference is to keep > them less restrictive, as Martin has proposed, if this is feasible. > > It is not clunky that 2 top-level YANG data nodes in the same module have unique names. This is simple and deterministic. This restriction has not been a problem so far. The yang-data statement has to define the context or new abstract namespace, or whatever this hack is called. Every tool that implements yang-data has to be able to interpret a yang-data statement exactly the same way. If you want to reinvent XSD substitutionGroup, then do it right. > Thanks, > Rob > > Andy > > On 16/04/2018 15:36, Andy Bierman wrote: > > Hi, > > I am strongly opposed to this change because it breaks the rule in YANG 1.1 > that there cannot be 2 sibling nodes defined in the same module namespace. > > IMO since any yang-data nodes are ALLOWED to be used at the top-level, > then these top-level nodes cannot have conflicting names. > > It is very important when parsing an instance document that the instance > data > can be associated with the correct schema. This is not possible if the > same top-level node has multiple yang-data nodes defined. > > If one needs to define data that is not top-level, (1) use > augment-yang-data > or (2) use a different module. > > > Andy > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund wrote: > >> Hi, >> >> While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that >> it is not clear what, if any, restrictions should be enforced for >> yang-data structures. Even among the authors we have different ideas >> for how this should work. >> >> Background: >> >> In 8040, the original yang-data extension had a restriction that said >> that a yang-data structure MUST have exactly one container, since it >> wouldn't be possible to have a yang-data structure in an XML instance >> document otherwise. >> >> Since people want to use yang-data structures in other places, this >> restriction was lifted in the new draft: >> >> There is no longer an assumption that a yang data structure can >> only be used as a top-level abstraction, instead of nested within >> some other data structure. >> >> >> With this in mind, here's a use case that I think we ought to support: >> >> rpc my-first-rpc { >> description >> "Bla bla... >> If an error occurs, will contain an instance of >> the yang-data structure 'my-first-rpc-error-info'."; >> ... >> } >> >> yang-data my-first-rpc-error-info { >> leaf reason { ... } >> container user-info { ... } >> } >> >> rpc my-second-rpc { >> description >> "Bla bla... >> If an error occurs, will contain an instance of >> the yang-data structure 'my-second-rpc-error-info'."; >> ... >> } >> >> yang-data my-second-rpc-error-info { >> leaf reason { ... } >> leaf important-url { ... } >> } >> >> (maybe in the future we could even have a YANG extension statement to >> formalize the description: >> >> rpc my-first-rpc { >> ... >> opx:error-info-structure my-first-rpc-error-info; >> } >> >> but this is not point now.) >> > I see no reason to reinvent the grouping-stmt. You could easily say opx:error-info-structure argument is a grouping name as it is a yang-data name. > >> In the example above, note that the leaf "reason" is present in both >> structures. IMO this is not a problem, since these structures are >> used in different contexts. >> >> My point is that I think we should impose as few restrictions as >> possible to the yang-data extension. It should be up to the user of >> yang-data to ensure that the structure is defined in such a way so >> that it can be used properly. For example, a structure that is >> supposed to describe an XML instance document cannot define two leafs >> at the top level. >> >> If the WG agrees with what I wrote above, we need to change the >> augment-yang-data extension so that you would write for example: >> >> yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { >> ... >> } >> >> Comments? >> >> >> >> /martin >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > --000000000000bb0d7e0569f96936 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20
Don't groupings have a somewhat similar concern?

=C2=A0E.g. if two groupings define the same data node name and are used at the same point then you would get a namespace clash, but YANG does not disallow the groupings:

     grouping foo_widget {
       leaf name {
         type string;
         description "Name of my foo widget";
      =C2=A0}
     }

     grouping bar_widget {
       leaf name {
         type string;
         description "Name of my bar widget";
      =C2=A0}
     }


     container all_widgets {
       uses foo_widget;
       uses bar_widget;
=C2=A0    }

The principal difference here, is that the compiler can easily check and reject the conflict at the uses statements.

Hence I think that it would be good if we could find a solution for yang-data-ext that doesn't not require all root yang-data nodes to be unique, since that feels somewhat clunky.=C2=A0 I.e. my preference i= s to keep them less restrictive, as Martin has proposed, if this is feasible.




It is not clunky that 2 top-level YANG data nodes in the same module
have unique names. This is simple and deterministic.
This r= estriction has not been a problem so far.


The yang-data statement has to define the context or new abstract na= mespace,
or whatever this hack is called.=C2=A0 Every tool that i= mplements yang-data has to be able
to interpret a yang-data state= ment exactly the same way.

If you want to reinvent= XSD substitutionGroup, then do it right.


=C2=A0
Thanks,
Rob



Andy
=C2=A0

On 16/04/2018 15:3= 6, Andy Bierman wrote:
=20
Hi,

I am strongly opposed to this change because it breaks the rule in YANG 1.1
that there cannot be 2 sibling nodes defined in the same module namespace.

IMO since any yang-data nodes are ALLOWED to be used at the top-level,
then these top-level nodes cannot have conflicting names.

It is very important when parsing an instance document that the instance data
can be associated with the correct schema.=C2=A0 This is not possible if the
same top-level node has multiple yang-data nodes defined.

If one needs to define data that is not top-level, (1) use augment-yang-data
or (2) use a different module.


Andy



On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
it is not clear what, if any, restrictions should be enforced for
yang-data structures.=C2=A0 Even among the authors we have different ideas
for how this should work.

Background:

In 8040, the original yang-data extension had a restriction that said
that a yang-data structure MUST have exactly one container, since it
wouldn't be possible to have a yang-data structure in a= n XML instance
document otherwise.

Since people want to use yang-data structures in other places, this
restriction was lifted in the new draft:

=C2=A0 =C2=A0There is no longer an assumption that a yang d= ata structure can
=C2=A0 =C2=A0only be used as a top-level abstraction, inste= ad of nested within
=C2=A0 =C2=A0some other data structure.


With this in mind, here's a use case that I think we ought to support:

=C2=A0 rpc my-first-rpc {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "Bla bla...
=C2=A0 =C2=A0 =C2=A0 =C2=A0If an error occurs, <error-in= fo> will contain an instance of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the yang-data structure 'my-first-rpc-error-info'.";
=C2=A0 =C2=A0 ...
=C2=A0 }

=C2=A0 yang-data my-first-rpc-error-info {
=C2=A0 =C2=A0 leaf reason { ... }
=C2=A0 =C2=A0 container user-info { ... }
=C2=A0 }

=C2=A0 rpc my-second-rpc {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "Bla bla...
=C2=A0 =C2=A0 =C2=A0 =C2=A0If an error occurs, <error-in= fo> will contain an instance of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the yang-data structure 'my-second-rpc-error-info'.";
=C2=A0 =C2=A0 ...
=C2=A0 }

=C2=A0 yang-data my-second-rpc-error-info {
=C2=A0 =C2=A0 leaf reason { ... }
=C2=A0 =C2=A0 leaf important-url { ... }
=C2=A0 }

(maybe in the future we could even have a YANG extension statement to
formalize the description:

=C2=A0 =C2=A0rpc my-first-rpc {
=C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0opx:error-info-structure my-first-rpc-e= rror-info;
=C2=A0 =C2=A0}

but this is not point now.)



I see no reason to reinvent the grouping-stmt.
Yo= u could easily say opx:error-info-structure argument is a grouping name
as it is a yang-data name.

=C2=A0

In the example above, note that the leaf "reason"= is present in both
structures.=C2=A0 IMO this is not a problem, since these structures are
used in different contexts.

My point is that I think we should impose as few restrictions as
possible to the yang-data extension.=C2=A0 It should be up = to the user of
yang-data to ensure that the structure is defined in such a way so
that it can be used properly.=C2=A0 For example, a structur= e that is
supposed to describe an XML instance document cannot define two leafs
at the top level.

If the WG agrees with what I wrote above, we need to change the
augment-yang-data extension so that you would write for example:

=C2=A0 yx:augment-yang-data /ex:my-first-rpc-error-info/ex<= wbr>:user-info {
=C2=A0 =C2=A0 ...
=C2=A0 }

Comments?



/martin

_______________________________________________
netmod mailing list
netmod= @ietf.org
https://www.ietf.org/mailman/listin= fo/netmod



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/=
mailman/listinfo/netmod


--000000000000bb0d7e0569f96936-- From nobody Mon Apr 16 09:29:31 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F40312EA94 for ; Mon, 16 Apr 2018 09:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xH9aE90xzhq9 for ; Mon, 16 Apr 2018 09:29:28 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C53EF12EA59 for ; Mon, 16 Apr 2018 09:29:27 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id A50C01AE00A0; Mon, 16 Apr 2018 18:29:26 +0200 (CEST) Date: Mon, 16 Apr 2018 18:29:26 +0200 (CEST) Message-Id: <20180416.182926.637163540708856373.mbj@tail-f.com> To: andy@yumaworks.com Cc: rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 16:29:30 -0000 Andy Bierman wrote: > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton wrote: > > > Don't groupings have a somewhat similar concern? > > > > E.g. if two groupings define the same data node name and are used at the > > same point then you would get a namespace clash, but YANG does not disallow > > the groupings: > > > > grouping foo_widget { > > leaf name { > > type string; > > description "Name of my foo widget"; > > } > > } > > > > grouping bar_widget { > > leaf name { > > type string; > > description "Name of my bar widget"; > > } > > } > > > > > > container all_widgets { > > uses foo_widget; > > uses bar_widget; > > } > > > > > > The principal difference here, is that the compiler can easily check and > > reject the conflict at the uses statements. > > > > Hence I think that it would be good if we could find a solution for > > yang-data-ext that doesn't not require all root yang-data nodes to be > > unique, since that feels somewhat clunky. I.e. my preference is to keep > > them less restrictive, as Martin has proposed, if this is feasible. > > > > > > > It is not clunky that 2 top-level YANG data nodes in the same module > have unique names. If the yang-data structure is used nested within some other node, it does not define a top-level node. In this case it doesn't have to have uniquely named nodes, and it doesn't have to define a single container. > This is simple and deterministic. > This restriction has not been a problem so far. yang-data is a new construct. A more restrictive version was defined in RFC 8040, and these restrictions *were* problematic. I don't want to make the same mistake again. > The yang-data statement has to define the context or new abstract namespace, Yes, agreed. Regardless of the outcome of this thread, the yang-data statement has to define where the structure being defined is supposed to be used. > or whatever this hack is called. Every tool that implements yang-data has > to be able > to interpret a yang-data statement exactly the same way. > > If you want to reinvent XSD substitutionGroup, then do it right. This is not a new substitutionGroup. /martin > > > > > > Thanks, > > Rob > > > > > > Andy > > > > > > On 16/04/2018 15:36, Andy Bierman wrote: > > > > Hi, > > > > I am strongly opposed to this change because it breaks the rule in YANG 1.1 > > that there cannot be 2 sibling nodes defined in the same module namespace. > > > > IMO since any yang-data nodes are ALLOWED to be used at the top-level, > > then these top-level nodes cannot have conflicting names. > > > > It is very important when parsing an instance document that the instance > > data > > can be associated with the correct schema. This is not possible if the > > same top-level node has multiple yang-data nodes defined. > > > > If one needs to define data that is not top-level, (1) use > > augment-yang-data > > or (2) use a different module. > > > > > > Andy > > > > > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund wrote: > > > >> Hi, > >> > >> While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > >> it is not clear what, if any, restrictions should be enforced for > >> yang-data structures. Even among the authors we have different ideas > >> for how this should work. > >> > >> Background: > >> > >> In 8040, the original yang-data extension had a restriction that said > >> that a yang-data structure MUST have exactly one container, since it > >> wouldn't be possible to have a yang-data structure in an XML instance > >> document otherwise. > >> > >> Since people want to use yang-data structures in other places, this > >> restriction was lifted in the new draft: > >> > >> There is no longer an assumption that a yang data structure can > >> only be used as a top-level abstraction, instead of nested within > >> some other data structure. > >> > >> > >> With this in mind, here's a use case that I think we ought to support: > >> > >> rpc my-first-rpc { > >> description > >> "Bla bla... > >> If an error occurs, will contain an instance of > >> the yang-data structure 'my-first-rpc-error-info'."; > >> ... > >> } > >> > >> yang-data my-first-rpc-error-info { > >> leaf reason { ... } > >> container user-info { ... } > >> } > >> > >> rpc my-second-rpc { > >> description > >> "Bla bla... > >> If an error occurs, will contain an instance of > >> the yang-data structure 'my-second-rpc-error-info'."; > >> ... > >> } > >> > >> yang-data my-second-rpc-error-info { > >> leaf reason { ... } > >> leaf important-url { ... } > >> } > >> > >> (maybe in the future we could even have a YANG extension statement to > >> formalize the description: > >> > >> rpc my-first-rpc { > >> ... > >> opx:error-info-structure my-first-rpc-error-info; > >> } > >> > >> but this is not point now.) > >> > > > > > I see no reason to reinvent the grouping-stmt. > You could easily say opx:error-info-structure argument is a grouping name > as it is a yang-data name. > > > > > > >> In the example above, note that the leaf "reason" is present in both > >> structures. IMO this is not a problem, since these structures are > >> used in different contexts. > >> > >> My point is that I think we should impose as few restrictions as > >> possible to the yang-data extension. It should be up to the user of > >> yang-data to ensure that the structure is defined in such a way so > >> that it can be used properly. For example, a structure that is > >> supposed to describe an XML instance document cannot define two leafs > >> at the top level. > >> > >> If the WG agrees with what I wrote above, we need to change the > >> augment-yang-data extension so that you would write for example: > >> > >> yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > >> ... > >> } > >> > >> Comments? > >> > >> > >> > >> /martin > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > > > > > > > _______________________________________________ > > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > > > > From nobody Mon Apr 16 09:46:48 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DD6124207 for ; Mon, 16 Apr 2018 09:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQZrP4G786SF for ; Mon, 16 Apr 2018 09:46:43 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A492C12DA13 for ; Mon, 16 Apr 2018 09:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26836; q=dns/txt; s=iport; t=1523897198; x=1525106798; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=5eSrWwtcIiDpCdhopKxU5bfDC7zveVyq2sd0VFjHnrA=; b=YzVptbEF/+0nJrobwuqd71sw3ybS9Yo1X220Jyws7NpJEs6I1hWtl996 fTBxTK24LYVBFH6NNhlwZQ0/yrYVOIXVRTMa2rhA7nD3UIPhoCm6Vdi2U evvqQA53JYAzbF+txbNLhQmeHXIxYqsIxw1HPzphNE0o7xGi49CtftkIo Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAgB80tRa/xbLJq0ZAUIZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgk1GgRAXYyiDZ4hgjgApgQ+SaIF7CxgBCoQVSwKCZTY?= =?us-ascii?q?WAQIBAQEBAQECbBwMhSIBAQEBAgEBASFLCxAJAhggBwMCAicfEQYBDAYCAQE?= =?us-ascii?q?XhGoID4kqdptAghwfhDiDZ4IqBYlaP4EPI4JogxEBAYRgglQCjASLYAiONQa?= =?us-ascii?q?BM4YUIoRiin+FIIElIwIvJoEsMxoIGxU7gkOBcDAXiFmFPz4wjjABAQ?= X-IronPort-AV: E=Sophos;i="5.48,459,1517875200"; d="scan'208,217";a="3175877" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2018 16:46:36 +0000 Received: from [10.63.23.73] (dhcp-ensft1-uk-vla370-10-63-23-73.cisco.com [10.63.23.73]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w3GGkZq3012803; Mon, 16 Apr 2018 16:46:36 GMT To: Andy Bierman , Martin Bjorklund Cc: NetMod WG References: <20180416.145617.1262098657698751846.mbj@tail-f.com> From: Robert Wilton Message-ID: <6e111dfc-efc7-109f-40f5-8cdba72021fc@cisco.com> Date: Mon, 16 Apr 2018 17:46:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8AFB57621A336577238CB503" Content-Language: en-US Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 16:46:46 -0000 This is a multi-part message in MIME format. --------------8AFB57621A336577238CB503 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 16/04/2018 17:07, Andy Bierman wrote: > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton > wrote: > > Don't groupings have a somewhat similar concern? > >  E.g. if two groupings define the same data node name and are used > at the same point then you would get a namespace clash, but YANG > does not disallow the groupings: > > grouping foo_widget { > leaf name { > type string; > description "Name of my foo widget"; >  } > } > > grouping bar_widget { > leaf name { > type string; > description "Name of my bar widget"; >  } > } > > container all_widgets { > uses foo_widget; > uses bar_widget; >   } > > > The principal difference here, is that the compiler can easily > check and reject the conflict at the uses statements. > > Hence I think that it would be good if we could find a solution > for yang-data-ext that doesn't not require all root yang-data > nodes to be unique, since that feels somewhat clunky.  I.e. my > preference is to keep them less restrictive, as Martin has > proposed, if this is feasible. > > > > > It is not clunky that 2 top-level YANG data nodes in the same module > have unique names. This is simple and deterministic. > This restriction has not been a problem so far. I agree with the statements above. But it is not clear to me that yang-data-ext is really defining new top level data nodes that are part of the same tree/namespace as the configuration/state nodes.  In Martin's examples they were used within RPCs, and it the forcing the names to be unique in that context that I think would be clunky.  E.g. in Martin's example forcing different names for "reason" and "user-info" doesn't seem to be helpful. > > > The yang-data statement has to define the context or new abstract > namespace, > or whatever this hack is called. Perhaps.  I think that this depends on how they are used. Could a fix for this be something along the lines of:  - yang-data names must be unique amongst other top level data nodes within the module.  - if yang-data extensions are used at the top level then their name must be used as a single top level container.  - if a yang-data extension is used within another structure then the yang-data name is excluded, and the top level nodes defined in the yang-data definition are used .... >   Every tool that implements yang-data has to be able > to interpret a yang-data statement exactly the same way. > > If you want to reinvent XSD substitutionGroup, then do it right. I'm not familiar with them.  From a quick read, I don't see how they are related to the problem that we are trying to solve here. Thanks, Rob > > > Thanks, > Rob > > > > Andy > > > On 16/04/2018 15:36, Andy Bierman wrote: >> Hi, >> >> I am strongly opposed to this change because it breaks the rule >> in YANG 1.1 >> that there cannot be 2 sibling nodes defined in the same module >> namespace. >> >> IMO since any yang-data nodes are ALLOWED to be used at the >> top-level, >> then these top-level nodes cannot have conflicting names. >> >> It is very important when parsing an instance document that the >> instance data >> can be associated with the correct schema. This is not possible >> if the >> same top-level node has multiple yang-data nodes defined. >> >> If one needs to define data that is not top-level, (1) use >> augment-yang-data >> or (2) use a different module. >> >> >> Andy >> >> >> >> On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund > > wrote: >> >> Hi, >> >> While preparing draft-ietf-netmod-yang-data-ext-02, it turned >> out that >> it is not clear what, if any, restrictions should be enforced for >> yang-data structures.  Even among the authors we have >> different ideas >> for how this should work. >> >> Background: >> >> In 8040, the original yang-data extension had a restriction >> that said >> that a yang-data structure MUST have exactly one container, >> since it >> wouldn't be possible to have a yang-data structure in an XML >> instance >> document otherwise. >> >> Since people want to use yang-data structures in other >> places, this >> restriction was lifted in the new draft: >> >>    There is no longer an assumption that a yang data >> structure can >>    only be used as a top-level abstraction, instead of nested >> within >>    some other data structure. >> >> >> With this in mind, here's a use case that I think we ought to >> support: >> >>   rpc my-first-rpc { >>     description >>       "Bla bla... >>        If an error occurs, will contain an >> instance of >>        the yang-data structure 'my-first-rpc-error-info'."; >>     ... >>   } >> >>   yang-data my-first-rpc-error-info { >>     leaf reason { ... } >>     container user-info { ... } >>   } >> >>   rpc my-second-rpc { >>     description >>       "Bla bla... >>        If an error occurs, will contain an >> instance of >>        the yang-data structure 'my-second-rpc-error-info'."; >>     ... >>   } >> >>   yang-data my-second-rpc-error-info { >>     leaf reason { ... } >>     leaf important-url { ... } >>   } >> >> (maybe in the future we could even have a YANG extension >> statement to >> formalize the description: >> >>    rpc my-first-rpc { >>      ... >>      opx:error-info-structure my-first-rpc-error-info; >>    } >> >> but this is not point now.) >> > > > > I see no reason to reinvent the grouping-stmt. > You could easily say opx:error-info-structure argument is a grouping name > as it is a yang-data name. > >> >> In the example above, note that the leaf "reason" is present >> in both >> structures.  IMO this is not a problem, since these >> structures are >> used in different contexts. >> >> My point is that I think we should impose as few restrictions as >> possible to the yang-data extension.  It should be up to the >> user of >> yang-data to ensure that the structure is defined in such a >> way so >> that it can be used properly.  For example, a structure that is >> supposed to describe an XML instance document cannot define >> two leafs >> at the top level. >> >> If the WG agrees with what I wrote above, we need to change the >> augment-yang-data extension so that you would write for example: >> >>   yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { >>     ... >>   } >> >> Comments? >> >> >> >> /martin >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > --------------8AFB57621A336577238CB503 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 16/04/2018 17:07, Andy Bierman wrote:


On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton <rwilton@cisco.com> wrote:
Don't groupings have a somewhat similar concern?

 E.g. if two groupings define the same data node name and are used at the same point then you would get a namespace clash, but YANG does not disallow the groupings:

     grouping foo_widget {
       leaf name {
         type string;
         description "Name of my foo widget";
       }
     }

     grouping bar_widget {
       leaf name {
         type string;
         description "Name of my bar widget";
       }
     }


     container all_widgets {
       uses foo_widget;
       uses bar_widget;
     }

The principal difference here, is that the compiler can easily check and reject the conflict at the uses statements.

Hence I think that it would be good if we could find a solution for yang-data-ext that doesn't not require all root yang-data nodes to be unique, since that feels somewhat clunky.  I.e. my preference is to keep them less restrictive, as Martin has proposed, if this is feasible.




It is not clunky that 2 top-level YANG data nodes in the same module
have unique names. This is simple and deterministic.
This restriction has not been a problem so far.
I agree with the statements above.

But it is not clear to me that yang-data-ext is really defining new top level data nodes that are part of the same tree/namespace as the configuration/state nodes.  In Martin's examples they were used within RPCs, and it the forcing the names to be unique in that context that I think would be clunky.  E.g. in Martin's example forcing different names for "reason" and "user-info" doesn't seem to be helpful.



The yang-data statement has to define the context or new abstract namespace,
or whatever this hack is called.
Perhaps.  I think that this depends on how they are used.

Could a fix for this be something along the lines of:
 - yang-data names must be unique amongst other top level data nodes within the module.
 - if yang-data extensions are used at the top level then their name must be used as a single top level container.
 - if a yang-data extension is used within another structure then the yang-data name is excluded, and the top level nodes defined in the yang-data definition are used ....

  Every tool that implements yang-data has to be able
to interpret a yang-data statement exactly the same way.

If you want to reinvent XSD substitutionGroup, then do it right.
I'm not familiar with them.  From a quick read, I don't see how they are related to the problem that we are trying to solve here.

Thanks,
Rob




 
Thanks,
Rob



Andy
 

On 16/04/2018 15:36, Andy Bierman wrote:
Hi,

I am strongly opposed to this change because it breaks the rule in YANG 1.1
that there cannot be 2 sibling nodes defined in the same module namespace.

IMO since any yang-data nodes are ALLOWED to be used at the top-level,
then these top-level nodes cannot have conflicting names.

It is very important when parsing an instance document that the instance data
can be associated with the correct schema.  This is not possible if the
same top-level node has multiple yang-data nodes defined.

If one needs to define data that is not top-level, (1) use augment-yang-data
or (2) use a different module.


Andy



On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
it is not clear what, if any, restrictions should be enforced for
yang-data structures.  Even among the authors we have different ideas
for how this should work.

Background:

In 8040, the original yang-data extension had a restriction that said
that a yang-data structure MUST have exactly one container, since it
wouldn't be possible to have a yang-data structure in an XML instance
document otherwise.

Since people want to use yang-data structures in other places, this
restriction was lifted in the new draft:

   There is no longer an assumption that a yang data structure can
   only be used as a top-level abstraction, instead of nested within
   some other data structure.


With this in mind, here's a use case that I think we ought to support:

  rpc my-first-rpc {
    description
      "Bla bla...
       If an error occurs, <error-info> will contain an instance of
       the yang-data structure 'my-first-rpc-error-info'.";
    ...
  }

  yang-data my-first-rpc-error-info {
    leaf reason { ... }
    container user-info { ... }
  }

  rpc my-second-rpc {
    description
      "Bla bla...
       If an error occurs, <error-info> will contain an instance of
       the yang-data structure 'my-second-rpc-error-info'.";
    ...
  }

  yang-data my-second-rpc-error-info {
    leaf reason { ... }
    leaf important-url { ... }
  }

(maybe in the future we could even have a YANG extension statement to
formalize the description:

   rpc my-first-rpc {
     ...
     opx:error-info-structure my-first-rpc-error-info;
   }

but this is not point now.)



I see no reason to reinvent the grouping-stmt.
You could easily say opx:error-info-structure argument is a grouping name
as it is a yang-data name.

 

In the example above, note that the leaf "reason" is present in both
structures.  IMO this is not a problem, since these structures are
used in different contexts.

My point is that I think we should impose as few restrictions as
possible to the yang-data extension.  It should be up to the user of
yang-data to ensure that the structure is defined in such a way so
that it can be used properly.  For example, a structure that is
supposed to describe an XML instance document cannot define two leafs
at the top level.

If the WG agrees with what I wrote above, we need to change the
augment-yang-data extension so that you would write for example:

  yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
    ...
  }

Comments?



/martin

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



--------------8AFB57621A336577238CB503-- From nobody Mon Apr 16 10:05:24 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411C0127869 for ; Mon, 16 Apr 2018 10:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O797olC-cT78 for ; Mon, 16 Apr 2018 10:05:19 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E141E120721 for ; Mon, 16 Apr 2018 10:05:18 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id r125-v6so6447340lfe.2 for ; Mon, 16 Apr 2018 10:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bXKpIDYR80v9LEswqLMGWWbDRT54WjbinAHYePfeRko=; b=HdrMEqTwYfPrJDLM5yFFmsrJ5QBrq4fFOkF5GrzTEegoPvu24jmX6tkmq6gPSYDP9a HTpxTHrzoGx5X3YsUtyXoOueKGdBhEDu1voryNlBC2Br+bYDc1Slh7CaegZNcRpQ+xIl nC4EhMOS1Yhvv0x7+usg+7zV9elhQpektzGhKsRdnjGvfcr5zTBewreJzeX+WacVuthH JzhSTHXoxYzHl3R1BPL4GJJAeKXu6w1zP0VKh+yAio1dD5lN+E3efSt9HzGFzUXpmAi9 w4cxBgWL590fTdRMBR9OfEhAMNjXZBLspAc1dnq2GpYu/MaBYFWRFNBd6X1UuPI17mPu LiTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bXKpIDYR80v9LEswqLMGWWbDRT54WjbinAHYePfeRko=; b=Tpz7rwkqhR3X+ssAzFqWCYFYhKUaWJGOEK7KkBDd6y4G9IzsL7XsAuEWiWLYrcPuoI 6s5PDa6rhw/YBo4vxU6VtS3mxKPQbXY15ndZbsPX835jsYbysijd0pzRapBl1fFKQvs8 VK7IoMp+GtpHnKj/qLewruorzQgzAqy9HqD2+Di1LdyLPbhV1TsbVVrpOf3HcPbogaxB NwZ5SmLaDEIb+XrwALHgNZpjC9gRplinpdic67/EXCqH1atVOb+xciz+r83TVCPSZ8La 0BH3xnB/N2v04cOAxrMJ293fNi5csswpiRHfyfwubD+OP820hu/yzcsuF4CBiULkf9Ha fybw== X-Gm-Message-State: ALQs6tCS06i6ykuxzI2G+P2A+1sHUGGiLmaKiXce9tqBmfKQclUHETeK kDodYjJ9zzZllo9eN+6G9tP3hf+brxZ/bHc1jvvyiw== X-Google-Smtp-Source: AIpwx4+c0mK2JZpGGVVFh7l0AruvZp4UGKIJJuEFhnjfxJ1BYjF/jng2lL938QphYO8VQC/Cz52ixUJU5LFuYk79T1o= X-Received: by 10.46.127.10 with SMTP id a10mr1967657ljd.78.1523898317083; Mon, 16 Apr 2018 10:05:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 16 Apr 2018 10:05:15 -0700 (PDT) In-Reply-To: <6e111dfc-efc7-109f-40f5-8cdba72021fc@cisco.com> References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <6e111dfc-efc7-109f-40f5-8cdba72021fc@cisco.com> From: Andy Bierman Date: Mon, 16 Apr 2018 10:05:15 -0700 Message-ID: To: Robert Wilton Cc: Martin Bjorklund , NetMod WG Content-Type: multipart/alternative; boundary="089e082b3ee8dd394c0569fa394c" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 17:05:22 -0000 --089e082b3ee8dd394c0569fa394c Content-Type: text/plain; charset="UTF-8" On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton wrote: > > > On 16/04/2018 17:07, Andy Bierman wrote: > > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton wrote: > >> Don't groupings have a somewhat similar concern? >> >> E.g. if two groupings define the same data node name and are used at the >> same point then you would get a namespace clash, but YANG does not disallow >> the groupings: >> >> grouping foo_widget { >> leaf name { >> type string; >> description "Name of my foo widget"; >> } >> } >> >> grouping bar_widget { >> leaf name { >> type string; >> description "Name of my bar widget"; >> } >> } >> >> >> container all_widgets { >> uses foo_widget; >> uses bar_widget; >> } >> >> >> The principal difference here, is that the compiler can easily check and >> reject the conflict at the uses statements. >> >> Hence I think that it would be good if we could find a solution for >> yang-data-ext that doesn't not require all root yang-data nodes to be >> unique, since that feels somewhat clunky. I.e. my preference is to keep >> them less restrictive, as Martin has proposed, if this is feasible. >> >> > > > It is not clunky that 2 top-level YANG data nodes in the same module > have unique names. This is simple and deterministic. > This restriction has not been a problem so far. > > I agree with the statements above. > > But it is not clear to me that yang-data-ext is really defining new top > level data nodes that are part of the same tree/namespace as the > configuration/state nodes. In Martin's examples they were used within > RPCs, and it the forcing the names to be unique in that context that I > think would be clunky. E.g. in Martin's example forcing different names > for "reason" and "user-info" doesn't seem to be helpful. > > > > The yang-data statement has to define the context or new abstract > namespace, > or whatever this hack is called. > > Perhaps. I think that this depends on how they are used. > The yang-data statement has to specify the expansion point, or at least specify that it is or is not the top-level. yang-data top/name1 { container mydata; } where context is something like "top" or "error-info", etc. It is trivial to use groupings if the same set of nodes needs to be used in different contexts: yang-data error-info/name1 { container mydata; } Only the context named "top" is restricted to a resulting single-container and cannot have duplicate names. This is OK: x:yang-data error-info/my-error1 { leaf reason {} } x:yang-data error-info/my-error2 { leaf reason {} } > Could a fix for this be something along the lines of: > - yang-data names must be unique amongst other top level data nodes > within the module. > - if yang-data extensions are used at the top level then their name must > be used as a single top level container. > - if a yang-data extension is used within another structure then the > yang-data name is excluded, and the top level nodes defined in the > yang-data definition are used .... > > Every tool that implements yang-data has to be able > to interpret a yang-data statement exactly the same way. > > If you want to reinvent XSD substitutionGroup, then do it right. > > I'm not familiar with them. From a quick read, I don't see how they are > related to the problem that we are trying to solve here. > > A substitutionGroup allows a point int the schema to be identified by name. Different elements can be defined that match this name, which then can be used (like a YANG choice) at the specified schema point. (e.g. error-info above is like a substitutionGroup) > Thanks, > Rob > Andy > > > > > > >> Thanks, >> Rob >> >> > > Andy > > >> >> On 16/04/2018 15:36, Andy Bierman wrote: >> >> Hi, >> >> I am strongly opposed to this change because it breaks the rule in YANG >> 1.1 >> that there cannot be 2 sibling nodes defined in the same module namespace. >> >> IMO since any yang-data nodes are ALLOWED to be used at the top-level, >> then these top-level nodes cannot have conflicting names. >> >> It is very important when parsing an instance document that the instance >> data >> can be associated with the correct schema. This is not possible if the >> same top-level node has multiple yang-data nodes defined. >> >> If one needs to define data that is not top-level, (1) use >> augment-yang-data >> or (2) use a different module. >> >> >> Andy >> >> >> >> On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund wrote: >> >>> Hi, >>> >>> While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that >>> it is not clear what, if any, restrictions should be enforced for >>> yang-data structures. Even among the authors we have different ideas >>> for how this should work. >>> >>> Background: >>> >>> In 8040, the original yang-data extension had a restriction that said >>> that a yang-data structure MUST have exactly one container, since it >>> wouldn't be possible to have a yang-data structure in an XML instance >>> document otherwise. >>> >>> Since people want to use yang-data structures in other places, this >>> restriction was lifted in the new draft: >>> >>> There is no longer an assumption that a yang data structure can >>> only be used as a top-level abstraction, instead of nested within >>> some other data structure. >>> >>> >>> With this in mind, here's a use case that I think we ought to support: >>> >>> rpc my-first-rpc { >>> description >>> "Bla bla... >>> If an error occurs, will contain an instance of >>> the yang-data structure 'my-first-rpc-error-info'."; >>> ... >>> } >>> >>> yang-data my-first-rpc-error-info { >>> leaf reason { ... } >>> container user-info { ... } >>> } >>> >>> rpc my-second-rpc { >>> description >>> "Bla bla... >>> If an error occurs, will contain an instance of >>> the yang-data structure 'my-second-rpc-error-info'."; >>> ... >>> } >>> >>> yang-data my-second-rpc-error-info { >>> leaf reason { ... } >>> leaf important-url { ... } >>> } >>> >>> (maybe in the future we could even have a YANG extension statement to >>> formalize the description: >>> >>> rpc my-first-rpc { >>> ... >>> opx:error-info-structure my-first-rpc-error-info; >>> } >>> >>> but this is not point now.) >>> >> > > > I see no reason to reinvent the grouping-stmt. > You could easily say opx:error-info-structure argument is a grouping name > as it is a yang-data name. > > > >> >>> In the example above, note that the leaf "reason" is present in both >>> structures. IMO this is not a problem, since these structures are >>> used in different contexts. >>> >>> My point is that I think we should impose as few restrictions as >>> possible to the yang-data extension. It should be up to the user of >>> yang-data to ensure that the structure is defined in such a way so >>> that it can be used properly. For example, a structure that is >>> supposed to describe an XML instance document cannot define two leafs >>> at the top level. >>> >>> If the WG agrees with what I wrote above, we need to change the >>> augment-yang-data extension so that you would write for example: >>> >>> yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { >>> ... >>> } >>> >>> Comments? >>> >>> >>> >>> /martin >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> >> >> _______________________________________________ >> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >> >> >> > > --089e082b3ee8dd394c0569fa394c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20



On 16/04/2018= 17:07, Andy Bierman wrote:
=20


On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton <rwilton@cisco.com> wrote:
Don't groupings have a somewhat similar concern?

=C2=A0E.g. if two groupings define the same data node name and are used at the same point then you would get a namespace clash, but YANG does not disallow the groupings:

     gro=
uping foo_widget {
       leaf name {
         type string;
         description "Name of my foo widget";
      =C2=A0}
     }

     grouping bar_widget {
       leaf name {
         type string;
         description "Name of my bar widget";
      =C2=A0}
     }


     con=
tainer all_widgets {
       uses foo_widget;
       uses bar_widget;
=C2=A0    }

The principal difference here, is that the compiler can easily check and reject the conflict at the uses statements.

Hence I think that it would be good if we could find a solution for yang-data-ext that doesn't not require all root yang-data nodes to be unique, since that feels somewhat clunky.=C2=A0 I.e. my preference is to keep them less restrictive, as Martin has proposed, if this is feasible.




It is not clunky that 2 top-level YANG data nodes in the same module
have unique names. This is simple and deterministic.
This restriction has not been a problem so far.
I agree with the statements above.

But it is not clear to me that yang-data-ext is really defining new top level data nodes that are part of the same tree/namespace as the configuration/state nodes.=C2=A0 In Martin's examples they were use= d within RPCs, and it the forcing the names to be unique in that context that I think would be clunky.=C2=A0 E.g. in Martin's exampl= e forcing different names for "reason" and "user-info"= ; doesn't seem to be helpful.



The yang-data statement has to define the context or new abstract namespace,
or whatever this hack is called.
Perhaps.=C2=A0 I think that this depends on how they are used.


The yang-data statement ha= s to specify the expansion point, or
at least specify that it is = or is not the top-level.

=C2=A0 yang-data top/name= 1 {
=C2=A0 =C2=A0 =C2=A0 container mydata;
=C2=A0 }

where context is something like "top" or &q= uot;error-info", etc.

It is trivial to use gr= oupings if the same set of nodes needs to be used in different contexts:


= =C2=A0 yang-data error-info/name1 {
=C2=A0 =C2=A0 =C2=A0 containe= r mydata;
=C2=A0 }

Only the contex= t named "top" is restricted to a resulting single-container
=
and cannot have duplicate names.

This is OK:<= /div>

=C2=A0 x:yang-data error-info/my-error1 {
=C2=A0 =C2=A0 =C2=A0 leaf reason {}
=C2=A0 }


=C2=A0 x:yang-dat= a error-info/my-error2 {
=C2=A0 =C2=A0 =C2=A0 leaf reason {}
=C2=A0 }




Could a fix for this be something along the lines of:
=C2=A0- yang-data names must be unique amongst other top level data nod= es within the module.
=C2=A0- if yang-data extensions are used at the top level then their na= me must be used as a single top level container.
=C2=A0- if a yang-data extension is used within another structure then the yang-data name is excluded, and the top level nodes defined in the yang-data definition are used ....

=C2=A0 Every tool that implements yang-data has to be able=
to interpret a yang-data statement exactly the same way.

If you want to reinvent XSD substitutionGroup, then do it right.
I'm not familiar with them.=C2=A0 From a quick read, I don't se= e how they are related to the problem that we are trying to solve here.



A substitutio= nGroup allows a point int the schema to be identified by name.
Di= fferent elements can be defined that match this name, which then can be
used (like a YANG choice) at the specified schema point.
(= e.g. error-info above is like a substitutionGroup)


=C2=A0
Thanks,
Rob

Andy
=C2=A0




=C2=A0
Thanks,
Rob



Andy
=C2=A0

On 16/04/2018 15:36, Andy Bierman wrote:
Hi,

I am strongly opposed to this change because it breaks the rule in YANG 1.1
that there cannot be 2 sibling nodes defined in the same module namespace.

IMO since any yang-data nodes are ALLOWED to be used at the top-level,
then these top-level nodes cannot have conflicting names.

It is very important when parsing an instance document that the instance data
can be associated with the correct schema.=C2=A0 This is not possible if the
same top-level node has multiple yang-data nodes defined.

If one needs to define data that is not top-level, (1) use augment-yang-data
or (2) use a different module.


Andy



On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund <<= a href=3D"mailto:mbj@tail-f.com" target=3D"_blank">mbj@tail-f.com> wrote:
Hi,

While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
it is not clear what, if any, restrictions should be enforced for
yang-data structures.=C2=A0 Even among the authors we have different ideas
for how this should work.

Background:

In 8040, the original yang-data extension had a restriction that said
that a yang-data structure MUST have exactly one container, since it
wouldn't be possible to have a yang-data structure in an XML instance
document otherwise.

Since people want to use yang-data structures in other places, this
restriction was lifted in the new draft:

=C2=A0 =C2=A0There is no longer an assumption t= hat a yang data structure can
=C2=A0 =C2=A0only be used as a top-level abstra= ction, instead of nested within
=C2=A0 =C2=A0some other data structure.


With this in mind, here's a use case that I think we ought to support:

=C2=A0 rpc my-first-rpc {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "Bla bla...
=C2=A0 =C2=A0 =C2=A0 =C2=A0If an error occurs, <error-info> will contain an instance of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the yang-data struct= ure 'my-first-rpc-error-info'.";
=C2=A0 =C2=A0 ...
=C2=A0 }

=C2=A0 yang-data my-first-rpc-error-info {
=C2=A0 =C2=A0 leaf reason { ... }
=C2=A0 =C2=A0 container user-info { ... }
=C2=A0 }

=C2=A0 rpc my-second-rpc {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "Bla bla...
=C2=A0 =C2=A0 =C2=A0 =C2=A0If an error occurs, <error-info> will contain an instance of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the yang-data struct= ure 'my-second-rpc-error-info'.";
=C2=A0 =C2=A0 ...
=C2=A0 }

=C2=A0 yang-data my-second-rpc-error-info {
=C2=A0 =C2=A0 leaf reason { ... }
=C2=A0 =C2=A0 leaf important-url { ... }
=C2=A0 }

(maybe in the future we could even have a YANG extension statement to
formalize the description:

=C2=A0 =C2=A0rpc my-first-rpc {
=C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0opx:error-info-structure my-first-rpc-error-info;
=C2=A0 =C2=A0}

but this is not point now.)



I see no reason to reinvent the grouping-stmt.
You could easily say opx:error-info-structure argument is a grouping name
as it is a yang-data name.

=C2=A0

In the example above, note that the leaf "reason" is present in both
structures.=C2=A0 IMO this is not a problem, since these structures are
used in different contexts.

My point is that I think we should impose as few restrictions as
possible to the yang-data extension.=C2=A0 It should be up to the user of
yang-data to ensure that the structure is defined in such a way so
that it can be used properly.=C2=A0 For example= , a structure that is
supposed to describe an XML instance document cannot define two leafs
at the top level.

If the WG agrees with what I wrote above, we need to change the
augment-yang-data extension so that you would write for example:

=C2=A0 yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
=C2=A0 =C2=A0 ...
=C2=A0 }

Comments?



/martin

__________________________________________= _____
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman= /listinfo/netmod



_______________________________________________
netmod mailing list
netmod@ietf.o=
rg
https://www.ietf.org/mailman/listinfo/netmod




--089e082b3ee8dd394c0569fa394c-- From nobody Mon Apr 16 13:20:33 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9144F12704A for ; Mon, 16 Apr 2018 13:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGFqOK_gLOqj for ; Mon, 16 Apr 2018 13:20:29 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17CD126CE8 for ; Mon, 16 Apr 2018 13:20:29 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3GK9eUl012530; Mon, 16 Apr 2018 13:20:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=xHWtLqvfOZX4fvEWUbmJTMwOfk6ygLh4JVXQagYT70w=; b=DEI3McBkPmklJwPJQZCEb9w1dmun3EjKhmauBoA2DFylJ1fDyG3BZ+6CfONk97FlTnQ7 iVnOcELyNVZueLOfTkH4ZEiYT3NkBGyCE+UyeKbGQvW0a7EyyWXuLOP0wstL5ln9Bq+t r6CjZzrto10q7wcBkYrWRfcvf1NS5qKflTbSVlwPMLND/NkUScEPN4AEsCecpk0+EgVD LuDhCD+gO5G7cvom8FuRyukC+cKI77BXhDXhV0qjNQ6AIjI5Qqan4+IOJhHC0kTKoc/y ymekZw6VZ691EFkBC/mKQolCEm2Mq7hSra+9Vv6qpzHDCXUHR9W7+P67O9aPPZJpVEBc KQ== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0050.outbound.protection.outlook.com [216.32.180.50]) by mx0a-00273201.pphosted.com with ESMTP id 2hd10yr6rx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 16 Apr 2018 13:20:28 -0700 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.8; Mon, 16 Apr 2018 20:20:27 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965%4]) with mapi id 15.20.0696.011; Mon, 16 Apr 2018 20:20:27 +0000 From: Kent Watsen To: Eliot Lear , NetMod WG Thread-Topic: [netmod] draft-ietf-netmod-acl-model Thread-Index: AQHT0z73qbFgAKxWEECeyyn4JZjNbaQDlzgA Date: Mon, 16 Apr 2018 20:20:27 +0000 Message-ID: <1DE823C2-79C5-4508-971C-2A4EEC4DE42D@juniper.net> References: <954c4999-6401-eb2d-c7a3-1cd930a5b7ed@cisco.com> In-Reply-To: <954c4999-6401-eb2d-c7a3-1cd930a5b7ed@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3484; 7:1Ga6lcSE995nZ5tlB5cRN5GPmMdkgP7E+/nOSJSDgHCwUcNK3UmhbBFCEeHeN/1UsRb9MNPrx+ySF5R/VqQo6iP/Gc3G+sgD7hqqxRZRs2bt/JGxcubvTtWoP2bGrAH8ZLCPntM5jUdYoL1OZM4t4sRzN2alEaXbOk/de4mBt15CcuBD6DAjjnEoK1XltJPfMXHbmTcypq3m2MeXoqK0EnLuIABBj9ZyOnPTOPYixDs58nFfG3zcx/9+DVHNHbuD x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DM5PR05MB3484; x-ms-traffictypediagnostic: DM5PR05MB3484: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231232)(944501347)(52105095)(10201501046)(3002001)(6055026)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR05MB3484; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3484; x-forefront-prvs: 0644578634 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39860400002)(39380400002)(366004)(199004)(189003)(186003)(106356001)(26005)(102836004)(6436002)(25786009)(68736007)(2900100001)(6506007)(6486002)(5250100002)(3660700001)(3846002)(3280700002)(6116002)(6512007)(97736004)(966005)(66066001)(229853002)(6306002)(478600001)(36756003)(8676002)(81166006)(81156014)(53936002)(476003)(2616005)(446003)(7736002)(11346002)(6246003)(76176011)(2906002)(305945005)(8936002)(486006)(5660300001)(83716003)(99286004)(14454004)(33656002)(575784001)(86362001)(110136005)(82746002)(105586002)(58126008)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3484; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: FrLvmhk/HvGknECCRGEG2spBC0Z/u5K0bNlumGcJ2HEeXhz2sAAuN3srrdEm/9AgHbdecrbgetbGsrzNJN3w3mP+TgqtiYHEDl3WN1HG4AiVy3NzbqrlDOzU0SOycX7hBjMumVHKRP4fG4yRsytGJGtDQq05VDgCrgWGRovVeeg+14K97779J9ubeTh9f6aw spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5F9A7AA92F74FE46870BE663DE1A2479@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 955d62d4-cc9b-4b55-9043-08d5a3d77e1f X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 955d62d4-cc9b-4b55-9043-08d5a3d77e1f X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2018 20:20:27.1618 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3484 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-16_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804160171 Archived-At: Subject: Re: [netmod] draft-ietf-netmod-acl-model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 20:20:31 -0000 W2p1c3QgYmFjayBmcm9tIFBUT10NCg0KSSdsbCBiZSBkb2luZyB0aGUgc2hlcGhlcmQgd3JpdGUt dXAgc2hvcnRseS4NCg0KS2VudCAvLyBzaGVwaGVyZA0KDQoNCg0KPT09PT0gb3JpZ2luYWwgbWVz c2FnZSA9PT09PQ0KDQpzdGF0dXMgb24gdGhpcyBkcmFmdD8NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1v ZEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1I QWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpH SjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWVOYjhjUVBQNlVLWlJreHdpaGlOLXoy SXhBWDhOZU44RVdfeng3OWJaTk0mcz1oc0daMkNzcUJoVkRtX2lleW9nQ3h4VjZiQzd3UkVzbzRR Nzh4d0ROSWNnJmU9DQoNCg0K From nobody Mon Apr 16 13:26:11 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FA812704A for ; Mon, 16 Apr 2018 13:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeUCGCGlUWAv for ; Mon, 16 Apr 2018 13:26:07 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D93C126CE8 for ; Mon, 16 Apr 2018 13:26:07 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id v207-v6so24020051lfa.10 for ; Mon, 16 Apr 2018 13:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=MccExldum3VAGNPEJMXkAkoHn7cGRhTUy8YrJIe4tZ8=; b=yCNToPLY1deNTh27q3L2Mm8BIiOmy5GijxSozuMHFOZTQ7+558SA/ZSP/O9CBbDqyh yQ3lTGNTj8FfxaZyx5nZtj5o9/4TVETvMOgwG18ysNRGt9DILf3zmmMZyloVGByP84tT MkHagfCCLPtreJ0+92h/B1h9r3asWrOgCwwROScQlgqj4OPQXNSLgXMDg49bFEb2ZiY9 QuyMR/mr1RNLvgZC2ia6xv+GnbWfK4NkhQczg4fn8/HCfR9I8qdPxCLv5abrQPBFBhxM wlLGvZro1CmqSYej9gvl6rTJ5DGDwIf2r1VimKRJeBn5wOoZZcVsxSjKY0LixiYgrgm/ kB4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MccExldum3VAGNPEJMXkAkoHn7cGRhTUy8YrJIe4tZ8=; b=gzdeXfXI0kbIhKk+2yW3ttlwgc61KxKry06kZRSQdWnzlJI5NOuMXfmBDLvHxo67SC 2wGqHoDFPlddTGjlZ9kd+fwpv2LECTQmw3/1pmvCfyGO3/fiRR5pdfYiCcfGbacsnPMv 0ejr4PRAK/CjWMO63Bw50NZXnLqhB8zzcogovikLi2J0pgQtgZ7sgol4wbu6fACAAbEh 7RvlVgTrvO+omGYmjbSIgxOnMsWAm1s4ZE8pMIjTR0A/9naD3dxLFq9sI01ERXSGfgyH 66Cc6h4br4njkwo4B17FgCl8re92BVJpBjuHcrHCx7re1zz97CqpNV7W5Gxzj0K6OWjz mzGg== X-Gm-Message-State: ALQs6tBDu0jarjLw6UzB7VjPj2d3lE9z1vvSp3tCcGtdVBDyr5eOfJAA S+zkqXQfD4pebR+A0wGDSgE+8UtyydxN8U8uy11qSUWw X-Google-Smtp-Source: AIpwx4+WE1WBW+73OyX3aZ5YxpE2Gm0H7ho9998W6c46AtRngWUc6iDTAC9yE98ZSqMS1QuDY0fQP3At4H/qirCPB9Y= X-Received: by 10.46.127.10 with SMTP id a10mr2334884ljd.78.1523910364704; Mon, 16 Apr 2018 13:26:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 16 Apr 2018 13:26:03 -0700 (PDT) From: Andy Bierman Date: Mon, 16 Apr 2018 13:26:03 -0700 Message-ID: To: NetMod WG Content-Type: multipart/alternative; boundary="089e082b3ee8f551030569fd0742" Archived-At: Subject: [netmod] comments on draft-ietf-netmod-module-tags-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 20:26:10 -0000 --089e082b3ee8f551030569fd0742 Content-Type: text/plain; charset="UTF-8" Hi, Here are my comments for this draft. I hope it can be completely quickly. * sec 3.2: Vendor Tags however, it is recommended that the vendor consider including extra identification in the tag name to avoid collisions (e.g., vendor:super-duper-company:...). - Suggest standard text about choosing names with a low probability of collision, like RFC 7950, 5.1: Developers of module tags are RECOMMENDED to choose names for their module tags that will have a low probability of colliding with other vendor tags, e.g., by using the enterprise or organization name as the second field name. e.g., vendor:example.com:system-management. * sec. 4.1 Module Definition Association A module definition SHOULD indicate a set of tags to be automatically added by the module implementer. These tags MUST be standard tags (Section 3.1). This does imply that new modules may also drive the addition of new standard tags to the IANA registry. - Why can't a vendor specify its own tags. - IMO, remove the sentence about MUST be standard tags. * sec. 5.2 Tags Module - a top-level list node is usually avoided, and a top-level container is used instead. - [major] there is no way for the client to retrieve the module-tags list for the installed tags. A read-only version of the module-tags list is needed (name, tag) - how does a client know what tags the server will accept? - how does a client know what values to put in the masked-tag field? ** leaf-list tag (type string) - a named type called "module-tag" would be better than an inline type It will likely be reused. - a minimum length of 1 would be better. (according to the normative sections, the minimum length would be 5 for 'ietf:') - a maximum length is likely to be enforced by an implementation. It is useful for the client to know what a server must support at a minimum (like 64 char names for YANG identifiers) - a pattern specifying the exact allows chars and formats would be better than a plain string * sec 7.1 Define Standard Tags - I do not agree that conformance requirements should be specified for module tags. The underlying definitions already have conformance specifications (e.g., if-feature, deviation). - How are standard tags going to be decided? Is this done by a design team, a WG, the IETF? What level of consensus is required to create a new standard tag. - I oppose using the description-stmt text to define module tags. Machine-readable text should be identified as such. YANG has an extension statement for this purpose: extension module-tag { description "Specifies a module-tag associated with the module. This statement is ignored unless it appears at the top level of the YANG module. The argument 'label' specifies the module tag value."; argument label { yin-element true; } } Usage: module example-module { x:module-tag ietf:some-required-tag:foo; x:module-tag ietf:some-recommended-tag:bar; x:module-tag ietf:some-optional-tag:baz; description "[Text describing the module...] RFC TAGS: The following tags MUST be included by an implementation: - ietf:some-required-tag:foo - ... The following tags SHOULD be included by an implementation: - ietf:some-recommended-tag:bar - ... The following tags MAY be included by an implementation: - ietf:some-optional-tag:baz - ... "; ... } Andy --089e082b3ee8f551030569fd0742 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Here are my comments for= this draft.
I hope it can be completely quickly.

<= /div>

* sec 3.2: Vendor Tags

= =C2=A0 =C2=A0however, it is recommended that the vendor consider
= =C2=A0 =C2=A0including extra identification in the tag name to avoid collis= ions
=C2=A0 =C2=A0(e.g., vendor:super-duper-company:...).

=C2=A0 - Suggest standard text about choosing names with = a low probability
=C2=A0 =C2=A0 of collision, like RFC 7950, 5.1:=

=C2=A0 =C2=A0Developers of module tags are RECOMM= ENDED to choose
=C2=A0 =C2=A0names for their module tags that wil= l have a low probability of colliding
=C2=A0 =C2=A0with other ven= dor tags, e.g., by using the
=C2=A0 =C2=A0enterprise or organizat= ion name as the second field name.
=C2=A0 =C2=A0e.g., vendor:exam= ple.com:system-management.

* sec. 4.1 Module Defin= ition Association

=C2=A0 =C2=A0A module definition= SHOULD indicate a set of tags to be automatically
=C2=A0 =C2=A0a= dded by the module implementer.=C2=A0 These tags MUST be standard tags
=C2=A0 =C2=A0(Section 3.1).=C2=A0 This does imply that new modules ma= y also drive the
=C2=A0 =C2=A0addition of new standard tags to th= e IANA registry.

=C2=A0 - Why can't a vendor s= pecify its own tags.
=C2=A0 - IMO, remove the sentence about MUST= be standard tags.

* sec. 5.2 Tags Module

=C2=A0 - a top-level list node is usually avoided, and a t= op-level container
=C2=A0 =C2=A0 is used instead.

<= /div>
=C2=A0- [major] there is no way for the client to retrieve the mo= dule-tags
=C2=A0 =C2=A0list for the installed tags.=C2=A0 A read-= only version of the module-tags
=C2=A0 =C2=A0list is needed (name= , tag)

=C2=A0 =C2=A0 =C2=A0- how does a client kno= w what tags the server will accept?
=C2=A0 =C2=A0 =C2=A0- how doe= s a client know what values to put in the masked-tag
=C2=A0 =C2= =A0 =C2=A0 =C2=A0field?

=C2=A0** leaf-list tag (ty= pe string)

=C2=A0 =C2=A0 - a named type called &qu= ot;module-tag" would be better than an inline type
=C2=A0 = =C2=A0 =C2=A0 It will likely be reused.

=C2=A0 =C2= =A0 - a minimum length of 1 would be better. =C2=A0(according to the
<= div>=C2=A0 =C2=A0 =C2=A0 normative sections, the minimum length would be 5 = for 'ietf:')

=C2=A0 =C2=A0 - a maximum len= gth is likely to be enforced by an implementation.
=C2=A0 =C2=A0 = =C2=A0 It is useful for the client to know what a server must
=C2= =A0 =C2=A0 =C2=A0 support at a minimum (like 64 char names for YANG identif= iers)

=C2=A0 =C2=A0 - a pattern specifying the exa= ct allows chars and formats would
=C2=A0 =C2=A0 =C2=A0 be better = than a plain string

* sec 7.1 Define Standard Tags=

=C2=A0 - I do not agree that conformance requirem= ents should be specified
=C2=A0 =C2=A0 for module tags.=C2=A0 The= underlying definitions already have conformance
=C2=A0 =C2=A0 sp= ecifications (e.g., if-feature, deviation).

=C2=A0= - How are standard tags going to be decided?
=C2=A0 =C2=A0 Is th= is done by a design team, a WG, the IETF?
=C2=A0 =C2=A0 What leve= l of consensus is required to create a new standard tag.

=C2=A0 - I oppose using the description-stmt text to define module t= ags.
=C2=A0 =C2=A0 Machine-readable text should be identified as = such.
=C2=A0 =C2=A0 YANG has an extension statement for this purp= ose:

=C2=A0 =C2=A0 =C2=A0extension module-tag {
=C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0"Specifies a module-tag associated with the module.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This statement is ignored unles= s it appears at the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 top level = of the YANG module.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 The argument 'label' specifies the module tag value.";<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0argument label {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0yin-element true;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0}
=C2=A0 =C2=A0 =C2=A0}


=
Usage:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0modu= le example-module {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0x:module-tag ietf:some-required-tag:foo;
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0x:module-tag ietf:some-recommended-tag:bar;<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0x:module-tag ietf:some-o= ptional-tag:baz;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"[Text describing the module...]

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC<this document> TAGS:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The following tags = MUST be included by an implementation:
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - ietf:some-required-tag:foo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The following tags S= HOULD be included by an implementation:
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - ietf:some-recommended-tag:bar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - ...<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The following tag= s MAY be included by an implementation:
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - ietf:some-optional-tag:baz
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0";
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0}


Andy

--089e082b3ee8f551030569fd0742-- From nobody Mon Apr 16 22:35:50 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909EB12EAB9 for ; Mon, 16 Apr 2018 22:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvIgvEM4Bs2a for ; Mon, 16 Apr 2018 22:35:47 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A64DB12D892 for ; Mon, 16 Apr 2018 22:35:45 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 35C4E1820157; Tue, 17 Apr 2018 07:33:32 +0200 (CEST) Received: from localhost (unknown [89.24.57.237]) by trail.lhotka.name (Postfix) with ESMTPSA id 8CB2A1820051; Tue, 17 Apr 2018 07:33:29 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20180416.145617.1262098657698751846.mbj@tail-f.com> References: <20180416.145617.1262098657698751846.mbj@tail-f.com> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org Date: Tue, 17 Apr 2018 07:35:37 +0200 Message-ID: <87h8oal7iu.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 05:35:50 -0000 Hi, this is a slippery slope. If we want to turn YANG into a general-purpose schema language, it should IMO be done the other way around: design a general-purpose schema language with a sound architecture, and then use it for defining schemas of datastores, protocol messages or whatever. YANG extensions make changes to the original YANG architecture way too easy, but the result may be a bastard with no architecture at all. Lada Martin Bjorklund writes: > Hi, > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > it is not clear what, if any, restrictions should be enforced for > yang-data structures. Even among the authors we have different ideas > for how this should work. > > Background: > > In 8040, the original yang-data extension had a restriction that said > that a yang-data structure MUST have exactly one container, since it > wouldn't be possible to have a yang-data structure in an XML instance > document otherwise. > > Since people want to use yang-data structures in other places, this > restriction was lifted in the new draft: > > There is no longer an assumption that a yang data structure can > only be used as a top-level abstraction, instead of nested within > some other data structure. > > > With this in mind, here's a use case that I think we ought to support: > > rpc my-first-rpc { > description > "Bla bla... > If an error occurs, will contain an instance of > the yang-data structure 'my-first-rpc-error-info'."; > ... > } > > yang-data my-first-rpc-error-info { > leaf reason { ... } > container user-info { ... } > } > > rpc my-second-rpc { > description > "Bla bla... > If an error occurs, will contain an instance of > the yang-data structure 'my-second-rpc-error-info'."; > ... > } > > yang-data my-second-rpc-error-info { > leaf reason { ... } > leaf important-url { ... } > } > > (maybe in the future we could even have a YANG extension statement to > formalize the description: > > rpc my-first-rpc { > ... > opx:error-info-structure my-first-rpc-error-info; > } > > but this is not point now.) > > In the example above, note that the leaf "reason" is present in both > structures. IMO this is not a problem, since these structures are > used in different contexts. > > My point is that I think we should impose as few restrictions as > possible to the yang-data extension. It should be up to the user of > yang-data to ensure that the structure is defined in such a way so > that it can be used properly. For example, a structure that is > supposed to describe an XML instance document cannot define two leafs > at the top level. > > If the WG agrees with what I wrote above, we need to change the > augment-yang-data extension so that you would write for example: > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > ... > } > > Comments? > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Apr 16 23:36:26 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F63B1270AE; Mon, 16 Apr 2018 23:36:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Jaeggli To: X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Cc: netmod-chairs@ietf.org, netmod@ietf.org, joelja@gmail.com, Kent Watsen , iesg-secretary@ietf.org, Lou Berger , Joel Jaeggli Message-ID: <152394698344.26114.5410872852100077671.idtracker@ietfa.amsl.com> Date: Mon, 16 Apr 2018 23:36:23 -0700 Archived-At: Subject: [netmod] Publication has been requested for draft-ietf-netmod-schema-mount-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 06:36:23 -0000 Joel Jaeggli has requested publication of draft-ietf-netmod-schema-mount-10 as Proposed Standard on behalf of the NETMOD working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ From nobody Wed Apr 18 10:27:03 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2ED412D881 for ; Wed, 18 Apr 2018 10:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqiVHbjS7e7d for ; Wed, 18 Apr 2018 10:26:58 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD951126D85 for ; Wed, 18 Apr 2018 10:26:57 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3IHKFdW029338; Wed, 18 Apr 2018 10:26:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=Zj4XSzCvW/DN27okVtpIXZyfICqv+U7oPRbhmd9dvf4=; b=ElnhiXo1AEjHBNGhWnKn4oBaMLrxGNTjeYOWlznW18eVTZsF7GYsHOqHTocd+RjyftNX xRyr2jLX7sig+EBFsWxSa6enwTMnjcnAO4s52N4dDoDofzMQDrstCJQcWesLlD6zvPzV uWenKZVtfJTcBb8m6QAyuDE9VntlrwRHALzXGo+2oOb3+W1OtYH5W3R97L3TaHX/6U1a rwUFMLqrB9WdCsoGSsfKOULGHEWlNPXunzzqLUEaCxqfcAXXqWTTcbak7jFhDKDFEM/x ElUQWduWjnwMV0zFS9NYMaDurVJvAq0jHZQYcCSY47qQX1oacOOiJXv3gbaNhBEv/t5v /A== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0056.outbound.protection.outlook.com [216.32.180.56]) by mx0b-00273201.pphosted.com with ESMTP id 2he9gj84ty-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Apr 2018 10:26:56 -0700 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3065.namprd05.prod.outlook.com (10.173.218.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.5; Wed, 18 Apr 2018 17:26:53 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965%4]) with mapi id 15.20.0696.011; Wed, 18 Apr 2018 17:26:53 +0000 From: Kent Watsen To: Andy Bierman , Robert Wilton CC: NetMod WG Thread-Topic: [netmod] yang-data-ext issues Thread-Index: AQHT1YJYRSnZmZlnhU6JIK4LoPfNTqQDdYgAgAAS9YCAAAZpAIAACwoAgAAFOICAAuemAA== Date: Wed, 18 Apr 2018 17:26:53 +0000 Message-ID: References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <6e111dfc-efc7-109f-40f5-8cdba72021fc@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3065; 7:k+tPdQF6vaKGLlfn017rXuP7ITsopjuU36a3LVuLi7lcClHons3QrEhzBr8vWkLDtns6S8rNABi0w/rj1xRV402cuGs1QHwPObXS/t+arqthxp9CTjVi6u6UKFc8yg/epU1UM3ziIJ6PM40vmklUy5d2iv1cdvSMt2uJYRCC1YVXqBMrdEof4+FYlHk1wsaPDoH7iDTiObmllNOKpMcvIz/e2Sk3j1OgLpncCYTkKp/LX26O2YZkKLJISzjZ1bF8 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DM5PR05MB3065; x-ms-traffictypediagnostic: DM5PR05MB3065: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(131327999870524)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231232)(944501327)(52105095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB3065; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3065; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(366004)(39860400002)(376002)(99286004)(316002)(11346002)(966005)(3660700001)(3280700002)(7736002)(8676002)(2616005)(446003)(110136005)(476003)(81166006)(14454004)(93886005)(8936002)(229853002)(2906002)(82746002)(26005)(4326008)(186003)(53936002)(36756003)(33656002)(54896002)(6306002)(86362001)(6512007)(66066001)(561944003)(606006)(6486002)(25786009)(53546011)(6506007)(236005)(5250100002)(478600001)(3846002)(6246003)(76176011)(83716003)(6436002)(59450400001)(6116002)(102836004)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3065; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: XiHM0opgO+fz99BkQ/J3FyTFvxrJHbQLGWcgRjt/Gru5j/+y6piKFMSmyT4QNjNMTVREBxQksAOnsXkNoiM67qcousZ6NhyNVMEw3rhoW+lrpnkAFWEoBlUPBEZf5XYOzWYcIZw/X6qVXZ5EQQeYVuX91aMYSfoFaTR4EU0Kb9LjFqec/UPJbDEx3+9eeAu+ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AD15A3E271BC4134AAFDBA249ABDEEB1junipernet_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: d24806b4-e120-40a1-0eee-08d5a55193e9 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: d24806b4-e120-40a1-0eee-08d5a55193e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2018 17:26:53.4782 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3065 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804180156 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 17:27:02 -0000 --_000_AD15A3E271BC4134AAFDBA249ABDEEB1junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBsaWtlIEFuZHkncyBwcm9wb3NhbCBiZWxvdywgZm9yIHRoZSBhcmd1bWVudCBvZiB0aGUgJ3lh bmctZGF0YScgc3RhdGVtZW50IHRvIGVuY29kZSBzb21lIG1ldGEtaW5mb3JtYXRpb24gcmVnYXJk aW5nIHRoZSBjb250ZXh0L25hbWVzcGFjZSBpbiB3aGljaCBpdCdzIHVzZWQsIGJ1dCBJIHdvbmRl ciBob3cgaXQgcmVhbGx5IHdvcmtzLiAgRm9yIGluc3RhbmNlLCB3b3VsZCAidG9wIiBhbmQgImVy cm9yLWluZm8iIGJlIHRoZSBvbmx5IGFsbG93ZWQgYmFzZS1wYXRoIHZhbHVlcyBmb3IgdGhlIGFy Z3VtZW50PyBhbmQgd2hhdCBpcyB0aGUgdmFsdWUgb2YgdGhlIHJlbWFpbmRlciBvZiB0aGUgcGF0 aD8gIGFyZSB3ZSBleHBlY3RpbmcgZm9yIHRoZXJlIHRvIGJlIHNvbWUga2luZCB1cyAndXNlcycg c3RhdGVtZW50IHRoYXQgY2FuIHJlZmVyIHRvIGp1c3QgdGhlIGJhc2UtcGF0aCBjb21wb25lbnQg dG8gaW1wbGVtZW50IHN1YnN0aXR1dGlvbi1ncm91cCBsaWtlIGJlaGF2aW9yPw0KDQpLZW50IC8v IGNvbnRyaWJ1dG9yDQoNCg0KT24gNC8xNi8xOCwgMTowNSBQTSwgIm5ldG1vZCBvbiBiZWhhbGYg b2YgQW5keSBCaWVybWFuIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1i b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgYW5keUB5dW1hd29ya3MuY29tPG1haWx0bzph bmR5QHl1bWF3b3Jrcy5jb20+PiB3cm90ZToNCg0KDQoNCk9uIE1vbiwgQXByIDE2LCAyMDE4IGF0 IDk6NDYgQU0sIFJvYmVydCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9u QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCg0KT24gMTYvMDQvMjAxOCAxNzowNywgQW5keSBCaWVy bWFuIHdyb3RlOg0KDQoNCk9uIE1vbiwgQXByIDE2LCAyMDE4IGF0IDg6NDQgQU0sIFJvYmVydCBX aWx0b24gPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+IHdyb3Rl Og0KDQpEb24ndCBncm91cGluZ3MgaGF2ZSBhIHNvbWV3aGF0IHNpbWlsYXIgY29uY2Vybj8NCg0K IEUuZy4gaWYgdHdvIGdyb3VwaW5ncyBkZWZpbmUgdGhlIHNhbWUgZGF0YSBub2RlIG5hbWUgYW5k IGFyZSB1c2VkIGF0IHRoZSBzYW1lIHBvaW50IHRoZW4geW91IHdvdWxkIGdldCBhIG5hbWVzcGFj ZSBjbGFzaCwgYnV0IFlBTkcgZG9lcyBub3QgZGlzYWxsb3cgdGhlIGdyb3VwaW5nczoNCg0KDQoN CiAgICAgZ3JvdXBpbmcgZm9vX3dpZGdldCB7DQoNCiAgICAgICBsZWFmIG5hbWUgew0KDQogICAg ICAgICB0eXBlIHN0cmluZzsNCg0KICAgICAgICAgZGVzY3JpcHRpb24gIk5hbWUgb2YgbXkgZm9v IHdpZGdldCI7DQoNCiAgICAgICB9DQoNCiAgICAgfQ0KDQoNCg0KICAgICBncm91cGluZyBiYXJf d2lkZ2V0IHsNCg0KICAgICAgIGxlYWYgbmFtZSB7DQoNCiAgICAgICAgIHR5cGUgc3RyaW5nOw0K DQogICAgICAgICBkZXNjcmlwdGlvbiAiTmFtZSBvZiBteSBiYXIgd2lkZ2V0IjsNCg0KICAgICAg IH0NCg0KICAgICB9DQoNCg0KDQogICAgIGNvbnRhaW5lciBhbGxfd2lkZ2V0cyB7DQoNCiAgICAg ICB1c2VzIGZvb193aWRnZXQ7DQoNCiAgICAgICB1c2VzIGJhcl93aWRnZXQ7DQoNCiAgICAgfQ0K DQpUaGUgcHJpbmNpcGFsIGRpZmZlcmVuY2UgaGVyZSwgaXMgdGhhdCB0aGUgY29tcGlsZXIgY2Fu IGVhc2lseSBjaGVjayBhbmQgcmVqZWN0IHRoZSBjb25mbGljdCBhdCB0aGUgdXNlcyBzdGF0ZW1l bnRzLg0KDQpIZW5jZSBJIHRoaW5rIHRoYXQgaXQgd291bGQgYmUgZ29vZCBpZiB3ZSBjb3VsZCBm aW5kIGEgc29sdXRpb24gZm9yIHlhbmctZGF0YS1leHQgdGhhdCBkb2Vzbid0IG5vdCByZXF1aXJl IGFsbCByb290IHlhbmctZGF0YSBub2RlcyB0byBiZSB1bmlxdWUsIHNpbmNlIHRoYXQgZmVlbHMg c29tZXdoYXQgY2x1bmt5LiAgSS5lLiBteSBwcmVmZXJlbmNlIGlzIHRvIGtlZXAgdGhlbSBsZXNz IHJlc3RyaWN0aXZlLCBhcyBNYXJ0aW4gaGFzIHByb3Bvc2VkLCBpZiB0aGlzIGlzIGZlYXNpYmxl Lg0KDQoNCg0KSXQgaXMgbm90IGNsdW5reSB0aGF0IDIgdG9wLWxldmVsIFlBTkcgZGF0YSBub2Rl cyBpbiB0aGUgc2FtZSBtb2R1bGUNCmhhdmUgdW5pcXVlIG5hbWVzLiBUaGlzIGlzIHNpbXBsZSBh bmQgZGV0ZXJtaW5pc3RpYy4NClRoaXMgcmVzdHJpY3Rpb24gaGFzIG5vdCBiZWVuIGEgcHJvYmxl bSBzbyBmYXIuDQpJIGFncmVlIHdpdGggdGhlIHN0YXRlbWVudHMgYWJvdmUuDQoNCkJ1dCBpdCBp cyBub3QgY2xlYXIgdG8gbWUgdGhhdCB5YW5nLWRhdGEtZXh0IGlzIHJlYWxseSBkZWZpbmluZyBu ZXcgdG9wIGxldmVsIGRhdGEgbm9kZXMgdGhhdCBhcmUgcGFydCBvZiB0aGUgc2FtZSB0cmVlL25h bWVzcGFjZSBhcyB0aGUgY29uZmlndXJhdGlvbi9zdGF0ZSBub2Rlcy4gIEluIE1hcnRpbidzIGV4 YW1wbGVzIHRoZXkgd2VyZSB1c2VkIHdpdGhpbiBSUENzLCBhbmQgaXQgdGhlIGZvcmNpbmcgdGhl IG5hbWVzIHRvIGJlIHVuaXF1ZSBpbiB0aGF0IGNvbnRleHQgdGhhdCBJIHRoaW5rIHdvdWxkIGJl IGNsdW5reS4gIEUuZy4gaW4gTWFydGluJ3MgZXhhbXBsZSBmb3JjaW5nIGRpZmZlcmVudCBuYW1l cyBmb3IgInJlYXNvbiIgYW5kICJ1c2VyLWluZm8iIGRvZXNuJ3Qgc2VlbSB0byBiZSBoZWxwZnVs Lg0KDQoNCg0KDQpUaGUgeWFuZy1kYXRhIHN0YXRlbWVudCBoYXMgdG8gZGVmaW5lIHRoZSBjb250 ZXh0IG9yIG5ldyBhYnN0cmFjdCBuYW1lc3BhY2UsDQpvciB3aGF0ZXZlciB0aGlzIGhhY2sgaXMg Y2FsbGVkLg0KUGVyaGFwcy4gIEkgdGhpbmsgdGhhdCB0aGlzIGRlcGVuZHMgb24gaG93IHRoZXkg YXJlIHVzZWQuDQoNCg0KVGhlIHlhbmctZGF0YSBzdGF0ZW1lbnQgaGFzIHRvIHNwZWNpZnkgdGhl IGV4cGFuc2lvbiBwb2ludCwgb3INCmF0IGxlYXN0IHNwZWNpZnkgdGhhdCBpdCBpcyBvciBpcyBu b3QgdGhlIHRvcC1sZXZlbC4NCg0KICB5YW5nLWRhdGEgdG9wL25hbWUxIHsNCiAgICAgIGNvbnRh aW5lciBteWRhdGE7DQogIH0NCg0Kd2hlcmUgY29udGV4dCBpcyBzb21ldGhpbmcgbGlrZSAidG9w IiBvciAiZXJyb3ItaW5mbyIsIGV0Yy4NCg0KSXQgaXMgdHJpdmlhbCB0byB1c2UgZ3JvdXBpbmdz IGlmIHRoZSBzYW1lIHNldCBvZiBub2RlcyBuZWVkcyB0byBiZSB1c2VkIGluIGRpZmZlcmVudCBj b250ZXh0czoNCg0KDQogIHlhbmctZGF0YSBlcnJvci1pbmZvL25hbWUxIHsNCiAgICAgIGNvbnRh aW5lciBteWRhdGE7DQogIH0NCg0KT25seSB0aGUgY29udGV4dCBuYW1lZCAidG9wIiBpcyByZXN0 cmljdGVkIHRvIGEgcmVzdWx0aW5nIHNpbmdsZS1jb250YWluZXINCmFuZCBjYW5ub3QgaGF2ZSBk dXBsaWNhdGUgbmFtZXMuDQoNClRoaXMgaXMgT0s6DQoNCiAgeDp5YW5nLWRhdGEgZXJyb3ItaW5m by9teS1lcnJvcjEgew0KICAgICAgbGVhZiByZWFzb24ge30NCiAgfQ0KDQoNCiAgeDp5YW5nLWRh dGEgZXJyb3ItaW5mby9teS1lcnJvcjIgew0KICAgICAgbGVhZiByZWFzb24ge30NCiAgfQ0KDQoN Cg0KDQpDb3VsZCBhIGZpeCBmb3IgdGhpcyBiZSBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9m Og0KIC0geWFuZy1kYXRhIG5hbWVzIG11c3QgYmUgdW5pcXVlIGFtb25nc3Qgb3RoZXIgdG9wIGxl dmVsIGRhdGEgbm9kZXMgd2l0aGluIHRoZSBtb2R1bGUuDQogLSBpZiB5YW5nLWRhdGEgZXh0ZW5z aW9ucyBhcmUgdXNlZCBhdCB0aGUgdG9wIGxldmVsIHRoZW4gdGhlaXIgbmFtZSBtdXN0IGJlIHVz ZWQgYXMgYSBzaW5nbGUgdG9wIGxldmVsIGNvbnRhaW5lci4NCiAtIGlmIGEgeWFuZy1kYXRhIGV4 dGVuc2lvbiBpcyB1c2VkIHdpdGhpbiBhbm90aGVyIHN0cnVjdHVyZSB0aGVuIHRoZSB5YW5nLWRh dGEgbmFtZSBpcyBleGNsdWRlZCwgYW5kIHRoZSB0b3AgbGV2ZWwgbm9kZXMgZGVmaW5lZCBpbiB0 aGUgeWFuZy1kYXRhIGRlZmluaXRpb24gYXJlIHVzZWQgLi4uLg0KDQoNCiAgRXZlcnkgdG9vbCB0 aGF0IGltcGxlbWVudHMgeWFuZy1kYXRhIGhhcyB0byBiZSBhYmxlDQp0byBpbnRlcnByZXQgYSB5 YW5nLWRhdGEgc3RhdGVtZW50IGV4YWN0bHkgdGhlIHNhbWUgd2F5Lg0KDQpJZiB5b3Ugd2FudCB0 byByZWludmVudCBYU0Qgc3Vic3RpdHV0aW9uR3JvdXAsIHRoZW4gZG8gaXQgcmlnaHQuDQpJJ20g bm90IGZhbWlsaWFyIHdpdGggdGhlbS4gIEZyb20gYSBxdWljayByZWFkLCBJIGRvbid0IHNlZSBo b3cgdGhleSBhcmUgcmVsYXRlZCB0byB0aGUgcHJvYmxlbSB0aGF0IHdlIGFyZSB0cnlpbmcgdG8g c29sdmUgaGVyZS4NCg0KDQpBIHN1YnN0aXR1dGlvbkdyb3VwIGFsbG93cyBhIHBvaW50IGludCB0 aGUgc2NoZW1hIHRvIGJlIGlkZW50aWZpZWQgYnkgbmFtZS4NCkRpZmZlcmVudCBlbGVtZW50cyBj YW4gYmUgZGVmaW5lZCB0aGF0IG1hdGNoIHRoaXMgbmFtZSwgd2hpY2ggdGhlbiBjYW4gYmUNCnVz ZWQgKGxpa2UgYSBZQU5HIGNob2ljZSkgYXQgdGhlIHNwZWNpZmllZCBzY2hlbWEgcG9pbnQuDQoo ZS5nLiBlcnJvci1pbmZvIGFib3ZlIGlzIGxpa2UgYSBzdWJzdGl0dXRpb25Hcm91cCkNCg0KDQoN ClRoYW5rcywNClJvYg0KDQpBbmR5DQoNCg0KDQoNCg0KDQoNClRoYW5rcywNClJvYg0KDQoNCkFu ZHkNCg0KDQpPbiAxNi8wNC8yMDE4IDE1OjM2LCBBbmR5IEJpZXJtYW4gd3JvdGU6DQpIaSwNCg0K SSBhbSBzdHJvbmdseSBvcHBvc2VkIHRvIHRoaXMgY2hhbmdlIGJlY2F1c2UgaXQgYnJlYWtzIHRo ZSBydWxlIGluIFlBTkcgMS4xDQp0aGF0IHRoZXJlIGNhbm5vdCBiZSAyIHNpYmxpbmcgbm9kZXMg ZGVmaW5lZCBpbiB0aGUgc2FtZSBtb2R1bGUgbmFtZXNwYWNlLg0KDQpJTU8gc2luY2UgYW55IHlh bmctZGF0YSBub2RlcyBhcmUgQUxMT1dFRCB0byBiZSB1c2VkIGF0IHRoZSB0b3AtbGV2ZWwsDQp0 aGVuIHRoZXNlIHRvcC1sZXZlbCBub2RlcyBjYW5ub3QgaGF2ZSBjb25mbGljdGluZyBuYW1lcy4N Cg0KSXQgaXMgdmVyeSBpbXBvcnRhbnQgd2hlbiBwYXJzaW5nIGFuIGluc3RhbmNlIGRvY3VtZW50 IHRoYXQgdGhlIGluc3RhbmNlIGRhdGENCmNhbiBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNvcnJl Y3Qgc2NoZW1hLiAgVGhpcyBpcyBub3QgcG9zc2libGUgaWYgdGhlDQpzYW1lIHRvcC1sZXZlbCBu b2RlIGhhcyBtdWx0aXBsZSB5YW5nLWRhdGEgbm9kZXMgZGVmaW5lZC4NCg0KSWYgb25lIG5lZWRz IHRvIGRlZmluZSBkYXRhIHRoYXQgaXMgbm90IHRvcC1sZXZlbCwgKDEpIHVzZSBhdWdtZW50LXlh bmctZGF0YQ0Kb3IgKDIpIHVzZSBhIGRpZmZlcmVudCBtb2R1bGUuDQoNCg0KQW5keQ0KDQoNCg0K T24gTW9uLCBBcHIgMTYsIDIwMTggYXQgNTo1NiBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRh aWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4gd3JvdGU6DQpIaSwNCg0KV2hpbGUgcHJl cGFyaW5nIGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctZGF0YS1leHQtMDIsIGl0IHR1cm5lZCBvdXQg dGhhdA0KaXQgaXMgbm90IGNsZWFyIHdoYXQsIGlmIGFueSwgcmVzdHJpY3Rpb25zIHNob3VsZCBi ZSBlbmZvcmNlZCBmb3INCnlhbmctZGF0YSBzdHJ1Y3R1cmVzLiAgRXZlbiBhbW9uZyB0aGUgYXV0 aG9ycyB3ZSBoYXZlIGRpZmZlcmVudCBpZGVhcw0KZm9yIGhvdyB0aGlzIHNob3VsZCB3b3JrLg0K DQpCYWNrZ3JvdW5kOg0KDQpJbiA4MDQwLCB0aGUgb3JpZ2luYWwgeWFuZy1kYXRhIGV4dGVuc2lv biBoYWQgYSByZXN0cmljdGlvbiB0aGF0IHNhaWQNCnRoYXQgYSB5YW5nLWRhdGEgc3RydWN0dXJl IE1VU1QgaGF2ZSBleGFjdGx5IG9uZSBjb250YWluZXIsIHNpbmNlIGl0DQp3b3VsZG4ndCBiZSBw b3NzaWJsZSB0byBoYXZlIGEgeWFuZy1kYXRhIHN0cnVjdHVyZSBpbiBhbiBYTUwgaW5zdGFuY2UN CmRvY3VtZW50IG90aGVyd2lzZS4NCg0KU2luY2UgcGVvcGxlIHdhbnQgdG8gdXNlIHlhbmctZGF0 YSBzdHJ1Y3R1cmVzIGluIG90aGVyIHBsYWNlcywgdGhpcw0KcmVzdHJpY3Rpb24gd2FzIGxpZnRl ZCBpbiB0aGUgbmV3IGRyYWZ0Og0KDQogICBUaGVyZSBpcyBubyBsb25nZXIgYW4gYXNzdW1wdGlv biB0aGF0IGEgeWFuZyBkYXRhIHN0cnVjdHVyZSBjYW4NCiAgIG9ubHkgYmUgdXNlZCBhcyBhIHRv cC1sZXZlbCBhYnN0cmFjdGlvbiwgaW5zdGVhZCBvZiBuZXN0ZWQgd2l0aGluDQogICBzb21lIG90 aGVyIGRhdGEgc3RydWN0dXJlLg0KDQoNCldpdGggdGhpcyBpbiBtaW5kLCBoZXJlJ3MgYSB1c2Ug Y2FzZSB0aGF0IEkgdGhpbmsgd2Ugb3VnaHQgdG8gc3VwcG9ydDoNCg0KICBycGMgbXktZmlyc3Qt cnBjIHsNCiAgICBkZXNjcmlwdGlvbg0KICAgICAgIkJsYSBibGEuLi4NCiAgICAgICBJZiBhbiBl cnJvciBvY2N1cnMsIDxlcnJvci1pbmZvPiB3aWxsIGNvbnRhaW4gYW4gaW5zdGFuY2Ugb2YNCiAg ICAgICB0aGUgeWFuZy1kYXRhIHN0cnVjdHVyZSAnbXktZmlyc3QtcnBjLWVycm9yLWluZm8nLiI7 DQogICAgLi4uDQogIH0NCg0KICB5YW5nLWRhdGEgbXktZmlyc3QtcnBjLWVycm9yLWluZm8gew0K ICAgIGxlYWYgcmVhc29uIHsgLi4uIH0NCiAgICBjb250YWluZXIgdXNlci1pbmZvIHsgLi4uIH0N CiAgfQ0KDQogIHJwYyBteS1zZWNvbmQtcnBjIHsNCiAgICBkZXNjcmlwdGlvbg0KICAgICAgIkJs YSBibGEuLi4NCiAgICAgICBJZiBhbiBlcnJvciBvY2N1cnMsIDxlcnJvci1pbmZvPiB3aWxsIGNv bnRhaW4gYW4gaW5zdGFuY2Ugb2YNCiAgICAgICB0aGUgeWFuZy1kYXRhIHN0cnVjdHVyZSAnbXkt c2Vjb25kLXJwYy1lcnJvci1pbmZvJy4iOw0KICAgIC4uLg0KICB9DQoNCiAgeWFuZy1kYXRhIG15 LXNlY29uZC1ycGMtZXJyb3ItaW5mbyB7DQogICAgbGVhZiByZWFzb24geyAuLi4gfQ0KICAgIGxl YWYgaW1wb3J0YW50LXVybCB7IC4uLiB9DQogIH0NCg0KKG1heWJlIGluIHRoZSBmdXR1cmUgd2Ug Y291bGQgZXZlbiBoYXZlIGEgWUFORyBleHRlbnNpb24gc3RhdGVtZW50IHRvDQpmb3JtYWxpemUg dGhlIGRlc2NyaXB0aW9uOg0KDQogICBycGMgbXktZmlyc3QtcnBjIHsNCiAgICAgLi4uDQogICAg IG9weDplcnJvci1pbmZvLXN0cnVjdHVyZSBteS1maXJzdC1ycGMtZXJyb3ItaW5mbzsNCiAgIH0N Cg0KYnV0IHRoaXMgaXMgbm90IHBvaW50IG5vdy4pDQoNCg0KDQpJIHNlZSBubyByZWFzb24gdG8g cmVpbnZlbnQgdGhlIGdyb3VwaW5nLXN0bXQuDQpZb3UgY291bGQgZWFzaWx5IHNheSBvcHg6ZXJy b3ItaW5mby1zdHJ1Y3R1cmUgYXJndW1lbnQgaXMgYSBncm91cGluZyBuYW1lDQphcyBpdCBpcyBh IHlhbmctZGF0YSBuYW1lLg0KDQoNCg0KSW4gdGhlIGV4YW1wbGUgYWJvdmUsIG5vdGUgdGhhdCB0 aGUgbGVhZiAicmVhc29uIiBpcyBwcmVzZW50IGluIGJvdGgNCnN0cnVjdHVyZXMuICBJTU8gdGhp cyBpcyBub3QgYSBwcm9ibGVtLCBzaW5jZSB0aGVzZSBzdHJ1Y3R1cmVzIGFyZQ0KdXNlZCBpbiBk aWZmZXJlbnQgY29udGV4dHMuDQoNCk15IHBvaW50IGlzIHRoYXQgSSB0aGluayB3ZSBzaG91bGQg aW1wb3NlIGFzIGZldyByZXN0cmljdGlvbnMgYXMNCnBvc3NpYmxlIHRvIHRoZSB5YW5nLWRhdGEg ZXh0ZW5zaW9uLiAgSXQgc2hvdWxkIGJlIHVwIHRvIHRoZSB1c2VyIG9mDQp5YW5nLWRhdGEgdG8g ZW5zdXJlIHRoYXQgdGhlIHN0cnVjdHVyZSBpcyBkZWZpbmVkIGluIHN1Y2ggYSB3YXkgc28NCnRo YXQgaXQgY2FuIGJlIHVzZWQgcHJvcGVybHkuICBGb3IgZXhhbXBsZSwgYSBzdHJ1Y3R1cmUgdGhh dCBpcw0Kc3VwcG9zZWQgdG8gZGVzY3JpYmUgYW4gWE1MIGluc3RhbmNlIGRvY3VtZW50IGNhbm5v dCBkZWZpbmUgdHdvIGxlYWZzDQphdCB0aGUgdG9wIGxldmVsLg0KDQpJZiB0aGUgV0cgYWdyZWVz IHdpdGggd2hhdCBJIHdyb3RlIGFib3ZlLCB3ZSBuZWVkIHRvIGNoYW5nZSB0aGUNCmF1Z21lbnQt eWFuZy1kYXRhIGV4dGVuc2lvbiBzbyB0aGF0IHlvdSB3b3VsZCB3cml0ZSBmb3IgZXhhbXBsZToN Cg0KICB5eDphdWdtZW50LXlhbmctZGF0YSAvZXg6bXktZmlyc3QtcnBjLWVycm9yLWluZm8vZXg6 dXNlci1pbmZvIHsNCiAgICAuLi4NCiAgfQ0KDQpDb21tZW50cz8NCg0KDQoNCi9tYXJ0aW4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBt YWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8aHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1h bl9saXN0aW5mb19uZXRtb2QmZD1Ed01GYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUst bmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK ZGNabyZtPXE2SV95S2JYVm9haHY5aDVJMXdaaVFNVWVITFo1WFd1TW9oRVl0eXBtenMmcz1qRUNa TWh5cHc5THR1eHp1bnRrRk5NLThsbTd4cHp0WXdERExPeENNXzhrJmU9Pg0KDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpuZXRtb2QgbWFp bGluZyBsaXN0DQoNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3TUZhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVN Sy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNs YUpkY1pvJm09cTZJX3lLYlhWb2FodjloNUkxd1ppUU1VZUhMWjVYV3VNb2hFWXR5cG16cyZzPWpF Q1pNaHlwdzlMdHV4enVudGtGTk0tOGxtN3hwenRZd0RETE94Q01fOGsmZT0+DQoNCg0KDQoNCg== --_000_AD15A3E271BC4134AAFDBA249ABDEEB1junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb3Vy aWVyO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50 Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29y YXRpb246bm9uZSBub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4ubXNvSW5z DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+SSBs aWtlIEFuZHkncyBwcm9wb3NhbCBiZWxvdywgZm9yIHRoZSBhcmd1bWVudCBvZiB0aGUgJ3lhbmct ZGF0YScgc3RhdGVtZW50IHRvIGVuY29kZSBzb21lIG1ldGEtaW5mb3JtYXRpb24gcmVnYXJkaW5n IHRoZSBjb250ZXh0L25hbWVzcGFjZSBpbiB3aGljaCBpdCdzIHVzZWQsIGJ1dCBJIHdvbmRlciBo b3cgaXQgcmVhbGx5IHdvcmtzLiZuYnNwOyBGb3IgaW5zdGFuY2UsDQogd291bGQgJnF1b3Q7dG9w JnF1b3Q7IGFuZCAmcXVvdDtlcnJvci1pbmZvJnF1b3Q7IGJlIHRoZSBvbmx5IGFsbG93ZWQgYmFz ZS1wYXRoIHZhbHVlcyBmb3IgdGhlIGFyZ3VtZW50PyBhbmQgd2hhdCBpcyB0aGUgdmFsdWUgb2Yg dGhlIHJlbWFpbmRlciBvZiB0aGUgcGF0aD8gJm5ic3A7YXJlIHdlIGV4cGVjdGluZyBmb3IgdGhl cmUgdG8gYmUgc29tZSBraW5kIHVzICd1c2VzJyBzdGF0ZW1lbnQgdGhhdCBjYW4gcmVmZXIgdG8g anVzdCB0aGUgYmFzZS1wYXRoIGNvbXBvbmVudCB0byBpbXBsZW1lbnQNCiBzdWJzdGl0dXRpb24t Z3JvdXAgbGlrZSBiZWhhdmlvcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmkiPktlbnQgLy8gY29udHJpYnV0b3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNC8xNi8xOCwgMTowNSBQTSwgJnF1 b3Q7bmV0bW9kIG9uIGJlaGFsZiBvZiBBbmR5IEJpZXJtYW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5 dW1hd29ya3MuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBcHIgMTYsIDIwMTggYXQgOTo0NiBBTSwgUm9i ZXJ0IFdpbHRvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiAxNi8wNC8yMDE4IDE3OjA3LCBBbmR5IEJpZXJtYW4gd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXByIDE2LCAyMDE4IGF0IDg6 NDQgQU0sIFJvYmVydCBXaWx0b24gJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RG9uJ3QgZ3JvdXBpbmdzIGhhdmUgYSBzb21ld2hhdCBzaW1pbGFyIGNvbmNlcm4/ PGJyPg0KPGJyPg0KJm5ic3A7RS5nLiBpZiB0d28gZ3JvdXBpbmdzIGRlZmluZSB0aGUgc2FtZSBk YXRhIG5vZGUgbmFtZSBhbmQgYXJlIHVzZWQgYXQgdGhlIHNhbWUgcG9pbnQgdGhlbiB5b3Ugd291 bGQgZ2V0IGEgbmFtZXNwYWNlIGNsYXNoLCBidXQgWUFORyBkb2VzIG5vdCBkaXNhbGxvdyB0aGUg Z3JvdXBpbmdzOjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBncm91cGluZyBmb29f d2lkZ2V0IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBuYW1lIHs8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBzdHJp bmc7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2Ny aXB0aW9uICZxdW90O05hbWUgb2YgbXkgZm9vIHdpZGdldCZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7fTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdyb3VwaW5nIGJhcl93aWRnZXQgezxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIG5hbWUgezxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIHN0cmluZzs8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7TmFtZSBvZiBt eSBiYXIgd2lkZ2V0JnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDt9 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9y bWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2lu ZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNvbnRhaW5lciBhbGxfd2lkZ2V0cyB7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHVzZXMgZm9vX3dpZGdldDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dXNlcyBiYXJfd2lkZ2V0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NClRoZSBwcmluY2lwYWwgZGlmZmVyZW5jZSBoZXJlLCBpcyB0aGF0IHRoZSBjb21w aWxlciBjYW4gZWFzaWx5IGNoZWNrIGFuZCByZWplY3QgdGhlIGNvbmZsaWN0IGF0IHRoZSB1c2Vz IHN0YXRlbWVudHMuPGJyPg0KPGJyPg0KSGVuY2UgSSB0aGluayB0aGF0IGl0IHdvdWxkIGJlIGdv b2QgaWYgd2UgY291bGQgZmluZCBhIHNvbHV0aW9uIGZvciB5YW5nLWRhdGEtZXh0IHRoYXQgZG9l c24ndCBub3QgcmVxdWlyZSBhbGwgcm9vdCB5YW5nLWRhdGEgbm9kZXMgdG8gYmUgdW5pcXVlLCBz aW5jZSB0aGF0IGZlZWxzIHNvbWV3aGF0IGNsdW5reS4mbmJzcDsgSS5lLiBteSBwcmVmZXJlbmNl IGlzIHRvIGtlZXAgdGhlbSBsZXNzIHJlc3RyaWN0aXZlLCBhcyBNYXJ0aW4gaGFzIHByb3Bvc2Vk LA0KIGlmIHRoaXMgaXMgZmVhc2libGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBub3QgY2x1bmt5 IHRoYXQgMiB0b3AtbGV2ZWwgWUFORyBkYXRhIG5vZGVzIGluIHRoZSBzYW1lIG1vZHVsZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aGF2ZSB1bmlx dWUgbmFtZXMuIFRoaXMgaXMgc2ltcGxlIGFuZCBkZXRlcm1pbmlzdGljLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyByZXN0cmljdGlvbiBo YXMgbm90IGJlZW4gYSBwcm9ibGVtIHNvIGZhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBhZ3JlZSB3aXRoIHRoZSBzdGF0ZW1lbnRzIGFib3ZlLjxicj4NCjxicj4NCkJ1dCBpdCBpcyBu b3QgY2xlYXIgdG8gbWUgdGhhdCB5YW5nLWRhdGEtZXh0IGlzIHJlYWxseSBkZWZpbmluZyBuZXcg dG9wIGxldmVsIGRhdGEgbm9kZXMgdGhhdCBhcmUgcGFydCBvZiB0aGUgc2FtZSB0cmVlL25hbWVz cGFjZSBhcyB0aGUgY29uZmlndXJhdGlvbi9zdGF0ZSBub2Rlcy4mbmJzcDsgSW4gTWFydGluJ3Mg ZXhhbXBsZXMgdGhleSB3ZXJlIHVzZWQgd2l0aGluIFJQQ3MsIGFuZCBpdCB0aGUgZm9yY2luZyB0 aGUgbmFtZXMgdG8gYmUgdW5pcXVlIGluDQogdGhhdCBjb250ZXh0IHRoYXQgSSB0aGluayB3b3Vs ZCBiZSBjbHVua3kuJm5ic3A7IEUuZy4gaW4gTWFydGluJ3MgZXhhbXBsZSBmb3JjaW5nIGRpZmZl cmVudCBuYW1lcyBmb3IgJnF1b3Q7cmVhc29uJnF1b3Q7IGFuZCAmcXVvdDt1c2VyLWluZm8mcXVv dDsgZG9lc24ndCBzZWVtIHRvIGJlIGhlbHBmdWwuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIHlhbmctZGF0YSBzdGF0ZW1lbnQgaGFzIHRvIGRlZmluZSB0aGUgY29udGV4dCBv ciBuZXcgYWJzdHJhY3QgbmFtZXNwYWNlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+b3Igd2hhdGV2ZXIgdGhpcyBoYWNrIGlzIGNhbGxlZC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyaGFwcy4mbmJzcDsgSSB0aGluayB0aGF0IHRoaXMg ZGVwZW5kcyBvbiBob3cgdGhleSBhcmUgdXNlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgeWFuZy1kYXRh IHN0YXRlbWVudCBoYXMgdG8gc3BlY2lmeSB0aGUgZXhwYW5zaW9uIHBvaW50LCBvcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXQgbGVhc3Qgc3Bl Y2lmeSB0aGF0IGl0IGlzIG9yIGlzIG5vdCB0aGUgdG9wLWxldmVsLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgeWFuZy1kYXRhIHRv cC9uYW1lMSB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBjb250YWluZXIgbXlkYXRhOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IH08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hlcmUgY29udGV4 dCBpcyBzb21ldGhpbmcgbGlrZSAmcXVvdDt0b3AmcXVvdDsgb3IgJnF1b3Q7ZXJyb3ItaW5mbyZx dW90OywgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JdCBpcyB0cml2aWFsIHRvIHVzZSBncm91cGluZ3MgaWYgdGhlIHNhbWUgc2V0IG9m IG5vZGVzIG5lZWRzIHRvIGJlIHVzZWQgaW4gZGlmZmVyZW50IGNvbnRleHRzOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K Jm5ic3A7IHlhbmctZGF0YSBlcnJvci1pbmZvL25hbWUxIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnRh aW5lciBteWRhdGE7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9ubHkgdGhlIGNvbnRleHQgbmFtZWQgJnF1b3Q7dG9wJnF1 b3Q7IGlzIHJlc3RyaWN0ZWQgdG8gYSByZXN1bHRpbmcgc2luZ2xlLWNvbnRhaW5lcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIGNhbm5vdCBo YXZlIGR1cGxpY2F0ZSBuYW1lcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBPSzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IHg6eWFuZy1kYXRhIGVycm9yLWluZm8v bXktZXJyb3IxIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGxlYWYgcmVhc29uIHt9PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgfTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K Jm5ic3A7IHg6eWFuZy1kYXRhIGVycm9yLWluZm8vbXktZXJyb3IyIHs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 IGxlYWYgcmVhc29uIHt9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQ291bGQgYSBm aXggZm9yIHRoaXMgYmUgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZjo8YnI+DQombmJzcDst IHlhbmctZGF0YSBuYW1lcyBtdXN0IGJlIHVuaXF1ZSBhbW9uZ3N0IG90aGVyIHRvcCBsZXZlbCBk YXRhIG5vZGVzIHdpdGhpbiB0aGUgbW9kdWxlLjxicj4NCiZuYnNwOy0gaWYgeWFuZy1kYXRhIGV4 dGVuc2lvbnMgYXJlIHVzZWQgYXQgdGhlIHRvcCBsZXZlbCB0aGVuIHRoZWlyIG5hbWUgbXVzdCBi ZSB1c2VkIGFzIGEgc2luZ2xlIHRvcCBsZXZlbCBjb250YWluZXIuPGJyPg0KJm5ic3A7LSBpZiBh IHlhbmctZGF0YSBleHRlbnNpb24gaXMgdXNlZCB3aXRoaW4gYW5vdGhlciBzdHJ1Y3R1cmUgdGhl biB0aGUgeWFuZy1kYXRhIG5hbWUgaXMgZXhjbHVkZWQsIGFuZCB0aGUgdG9wIGxldmVsIG5vZGVz IGRlZmluZWQgaW4gdGhlIHlhbmctZGF0YSBkZWZpbml0aW9uIGFyZSB1c2VkIC4uLi48YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBFdmVyeSB0b29sIHRoYXQgaW1wbGVtZW50cyB5 YW5nLWRhdGEgaGFzIHRvIGJlIGFibGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnRvIGludGVycHJldCBhIHlhbmctZGF0YSBzdGF0ZW1lbnQgZXhh Y3RseSB0aGUgc2FtZSB3YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPklmIHlvdSB3YW50IHRvIHJlaW52ZW50IFhTRCBzdWJzdGl0dXRpb25H cm91cCwgdGhlbiBkbyBpdCByaWdodC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JJ20gbm90IGZhbWlsaWFyIHdpdGggdGhlbS4mbmJzcDsg RnJvbSBhIHF1aWNrIHJlYWQsIEkgZG9uJ3Qgc2VlIGhvdyB0aGV5IGFyZSByZWxhdGVkIHRvIHRo ZSBwcm9ibGVtIHRoYXQgd2UgYXJlIHRyeWluZyB0byBzb2x2ZSBoZXJlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkEgc3Vic3RpdHV0aW9uR3JvdXAgYWxsb3dzIGEgcG9pbnQgaW50IHRoZSBzY2hlbWEgdG8gYmUg aWRlbnRpZmllZCBieSBuYW1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RGlmZmVyZW50IGVsZW1lbnRzIGNhbiBiZSBkZWZpbmVkIHRoYXQgbWF0 Y2ggdGhpcyBuYW1lLCB3aGljaCB0aGVuIGNhbiBiZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dXNlZCAobGlrZSBhIFlBTkcgY2hvaWNlKSBhdCB0 aGUgc3BlY2lmaWVkIHNjaGVtYSBwb2ludC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPihlLmcuIGVycm9yLWluZm8gYWJvdmUgaXMgbGlrZSBhIHN1 YnN0aXR1dGlvbkdyb3VwKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbjowLi44ZXgiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhh bmtzLDxicj4NClJvYjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdDttYXJnaW46MC4uOGV4Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAx Ni8wNC8yMDE4IDE1OjM2LCBBbmR5IEJpZXJtYW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCA8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gc3Ryb25nbHkgb3Bwb3NlZCB0byB0aGlz IGNoYW5nZSBiZWNhdXNlIGl0IGJyZWFrcyB0aGUgcnVsZSBpbiBZQU5HIDEuMTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhdCB0aGVyZSBjYW5u b3QgYmUgMiBzaWJsaW5nIG5vZGVzIGRlZmluZWQgaW4gdGhlIHNhbWUgbW9kdWxlIG5hbWVzcGFj ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SU1PIHNpbmNlIGFueSB5YW5nLWRhdGEgbm9kZXMgYXJlIEFMTE9XRUQgdG8gYmUgdXNlZCBhdCB0 aGUgdG9wLWxldmVsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+dGhlbiB0aGVzZSB0b3AtbGV2ZWwgbm9kZXMgY2Fubm90IGhhdmUgY29uZmxpY3Rp bmcgbmFtZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkl0IGlzIHZlcnkgaW1wb3J0YW50IHdoZW4gcGFyc2luZyBhbiBpbnN0YW5jZSBkb2N1 bWVudCB0aGF0IHRoZSBpbnN0YW5jZSBkYXRhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jYW4gYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBjb3JyZWN0 IHNjaGVtYS4mbmJzcDsgVGhpcyBpcyBub3QgcG9zc2libGUgaWYgdGhlPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zYW1lIHRvcC1sZXZlbCBub2Rl IGhhcyBtdWx0aXBsZSB5YW5nLWRhdGEgbm9kZXMgZGVmaW5lZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgb25lIG5lZWRzIHRvIGRlZmlu ZSBkYXRhIHRoYXQgaXMgbm90IHRvcC1sZXZlbCwgKDEpIHVzZSBhdWdtZW50LXlhbmctZGF0YTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b3IgKDIp IHVzZSBhIGRpZmZlcmVudCBtb2R1bGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEFwciAxNiwgMjAxOCBhdCA1OjU2 IEFNLCBNYXJ0aW4gQmpvcmtsdW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20i IHRhcmdldD0iX2JsYW5rIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxicj4NCjxicj4NCldo aWxlIHByZXBhcmluZyBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLWRhdGEtZXh0LTAyLCBpdCB0dXJu ZWQgb3V0IHRoYXQ8YnI+DQppdCBpcyBub3QgY2xlYXIgd2hhdCwgaWYgYW55LCByZXN0cmljdGlv bnMgc2hvdWxkIGJlIGVuZm9yY2VkIGZvcjxicj4NCnlhbmctZGF0YSBzdHJ1Y3R1cmVzLiZuYnNw OyBFdmVuIGFtb25nIHRoZSBhdXRob3JzIHdlIGhhdmUgZGlmZmVyZW50IGlkZWFzPGJyPg0KZm9y IGhvdyB0aGlzIHNob3VsZCB3b3JrLjxicj4NCjxicj4NCkJhY2tncm91bmQ6PGJyPg0KPGJyPg0K SW4gODA0MCwgdGhlIG9yaWdpbmFsIHlhbmctZGF0YSBleHRlbnNpb24gaGFkIGEgcmVzdHJpY3Rp b24gdGhhdCBzYWlkPGJyPg0KdGhhdCBhIHlhbmctZGF0YSBzdHJ1Y3R1cmUgTVVTVCBoYXZlIGV4 YWN0bHkgb25lIGNvbnRhaW5lciwgc2luY2UgaXQ8YnI+DQp3b3VsZG4ndCBiZSBwb3NzaWJsZSB0 byBoYXZlIGEgeWFuZy1kYXRhIHN0cnVjdHVyZSBpbiBhbiBYTUwgaW5zdGFuY2U8YnI+DQpkb2N1 bWVudCBvdGhlcndpc2UuPGJyPg0KPGJyPg0KU2luY2UgcGVvcGxlIHdhbnQgdG8gdXNlIHlhbmct ZGF0YSBzdHJ1Y3R1cmVzIGluIG90aGVyIHBsYWNlcywgdGhpczxicj4NCnJlc3RyaWN0aW9uIHdh cyBsaWZ0ZWQgaW4gdGhlIG5ldyBkcmFmdDo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhlcmUg aXMgbm8gbG9uZ2VyIGFuIGFzc3VtcHRpb24gdGhhdCBhIHlhbmcgZGF0YSBzdHJ1Y3R1cmUgY2Fu PGJyPg0KJm5ic3A7ICZuYnNwO29ubHkgYmUgdXNlZCBhcyBhIHRvcC1sZXZlbCBhYnN0cmFjdGlv biwgaW5zdGVhZCBvZiBuZXN0ZWQgd2l0aGluPGJyPg0KJm5ic3A7ICZuYnNwO3NvbWUgb3RoZXIg ZGF0YSBzdHJ1Y3R1cmUuPGJyPg0KPGJyPg0KPGJyPg0KV2l0aCB0aGlzIGluIG1pbmQsIGhlcmUn cyBhIHVzZSBjYXNlIHRoYXQgSSB0aGluayB3ZSBvdWdodCB0byBzdXBwb3J0Ojxicj4NCjxicj4N CiZuYnNwOyBycGMgbXktZmlyc3QtcnBjIHs8YnI+DQombmJzcDsgJm5ic3A7IGRlc2NyaXB0aW9u PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7QmxhIGJsYS4uLjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0lmIGFuIGVycm9yIG9jY3VycywgJmx0O2Vycm9yLWluZm8mZ3Q7 IHdpbGwgY29udGFpbiBhbiBpbnN0YW5jZSBvZjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3RoZSB5YW5nLWRhdGEgc3RydWN0dXJlICdteS1maXJzdC1ycGMtZXJyb3ItaW5mbycuJnF1 b3Q7Ozxicj4NCiZuYnNwOyAmbmJzcDsgLi4uPGJyPg0KJm5ic3A7IH08YnI+DQo8YnI+DQombmJz cDsgeWFuZy1kYXRhIG15LWZpcnN0LXJwYy1lcnJvci1pbmZvIHs8YnI+DQombmJzcDsgJm5ic3A7 IGxlYWYgcmVhc29uIHsgLi4uIH08YnI+DQombmJzcDsgJm5ic3A7IGNvbnRhaW5lciB1c2VyLWlu Zm8geyAuLi4gfTxicj4NCiZuYnNwOyB9PGJyPg0KPGJyPg0KJm5ic3A7IHJwYyBteS1zZWNvbmQt cnBjIHs8YnI+DQombmJzcDsgJm5ic3A7IGRlc2NyaXB0aW9uPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJnF1b3Q7QmxhIGJsYS4uLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lm IGFuIGVycm9yIG9jY3VycywgJmx0O2Vycm9yLWluZm8mZ3Q7IHdpbGwgY29udGFpbiBhbiBpbnN0 YW5jZSBvZjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSB5YW5nLWRhdGEgc3Ry dWN0dXJlICdteS1zZWNvbmQtcnBjLWVycm9yLWluZm8nLiZxdW90Ozs8YnI+DQombmJzcDsgJm5i c3A7IC4uLjxicj4NCiZuYnNwOyB9PGJyPg0KPGJyPg0KJm5ic3A7IHlhbmctZGF0YSBteS1zZWNv bmQtcnBjLWVycm9yLWluZm8gezxicj4NCiZuYnNwOyAmbmJzcDsgbGVhZiByZWFzb24geyAuLi4g fTxicj4NCiZuYnNwOyAmbmJzcDsgbGVhZiBpbXBvcnRhbnQtdXJsIHsgLi4uIH08YnI+DQombmJz cDsgfTxicj4NCjxicj4NCihtYXliZSBpbiB0aGUgZnV0dXJlIHdlIGNvdWxkIGV2ZW4gaGF2ZSBh IFlBTkcgZXh0ZW5zaW9uIHN0YXRlbWVudCB0bzxicj4NCmZvcm1hbGl6ZSB0aGUgZGVzY3JpcHRp b246PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO3JwYyBteS1maXJzdC1ycGMgezxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7Li4uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtvcHg6ZXJyb3ItaW5m by1zdHJ1Y3R1cmUgbXktZmlyc3QtcnBjLWVycm9yLWluZm87PGJyPg0KJm5ic3A7ICZuYnNwO308 YnI+DQo8YnI+DQpidXQgdGhpcyBpcyBub3QgcG9pbnQgbm93Lik8bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBzZWUgbm8gcmVhc29uIHRvIHJlaW52ZW50IHRoZSBncm91cGluZy1zdG10LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGNvdWxkIGVh c2lseSBzYXkgb3B4OmVycm9yLWluZm8tc3RydWN0dXJlIGFyZ3VtZW50IGlzIGEgZ3JvdXBpbmcg bmFtZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ YXMgaXQgaXMgYSB5YW5nLWRhdGEgbmFtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0O21hcmdpbjowLi44ZXgiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJbiB0aGUgZXhh bXBsZSBhYm92ZSwgbm90ZSB0aGF0IHRoZSBsZWFmICZxdW90O3JlYXNvbiZxdW90OyBpcyBwcmVz ZW50IGluIGJvdGg8YnI+DQpzdHJ1Y3R1cmVzLiZuYnNwOyBJTU8gdGhpcyBpcyBub3QgYSBwcm9i bGVtLCBzaW5jZSB0aGVzZSBzdHJ1Y3R1cmVzIGFyZTxicj4NCnVzZWQgaW4gZGlmZmVyZW50IGNv bnRleHRzLjxicj4NCjxicj4NCk15IHBvaW50IGlzIHRoYXQgSSB0aGluayB3ZSBzaG91bGQgaW1w b3NlIGFzIGZldyByZXN0cmljdGlvbnMgYXM8YnI+DQpwb3NzaWJsZSB0byB0aGUgeWFuZy1kYXRh IGV4dGVuc2lvbi4mbmJzcDsgSXQgc2hvdWxkIGJlIHVwIHRvIHRoZSB1c2VyIG9mPGJyPg0KeWFu Zy1kYXRhIHRvIGVuc3VyZSB0aGF0IHRoZSBzdHJ1Y3R1cmUgaXMgZGVmaW5lZCBpbiBzdWNoIGEg d2F5IHNvPGJyPg0KdGhhdCBpdCBjYW4gYmUgdXNlZCBwcm9wZXJseS4mbmJzcDsgRm9yIGV4YW1w bGUsIGEgc3RydWN0dXJlIHRoYXQgaXM8YnI+DQpzdXBwb3NlZCB0byBkZXNjcmliZSBhbiBYTUwg aW5zdGFuY2UgZG9jdW1lbnQgY2Fubm90IGRlZmluZSB0d28gbGVhZnM8YnI+DQphdCB0aGUgdG9w IGxldmVsLjxicj4NCjxicj4NCklmIHRoZSBXRyBhZ3JlZXMgd2l0aCB3aGF0IEkgd3JvdGUgYWJv dmUsIHdlIG5lZWQgdG8gY2hhbmdlIHRoZTxicj4NCmF1Z21lbnQteWFuZy1kYXRhIGV4dGVuc2lv biBzbyB0aGF0IHlvdSB3b3VsZCB3cml0ZSBmb3IgZXhhbXBsZTo8YnI+DQo8YnI+DQombmJzcDsg eXg6YXVnbWVudC15YW5nLWRhdGEgL2V4Om15LWZpcnN0LXJwYy1lcnJvci1pbmZvL2V4OnVzZXIt aW5mbyB7PGJyPg0KJm5ic3A7ICZuYnNwOyAuLi48YnI+DQombmJzcDsgfTxicj4NCjxicj4NCkNv bW1lbnRzPzxicj4NCjxicj4NCjxicj4NCjxicj4NCi9tYXJ0aW48YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f bGlzdGluZm9fbmV0bW9kJmFtcDtkPUR3TUZhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVq QlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZ YUdUdmpJU2xhSmRjWm8mYW1wO209cTZJX3lLYlhWb2FodjloNUkxd1ppUU1VZUhMWjVYV3VNb2hF WXR5cG16cyZhbXA7cz1qRUNaTWh5cHc5THR1eHp1bnRrRk5NLThsbTd4cHp0WXdERExPeENNXzhr JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPm5ldG1vZCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bmV0bW9kQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmFtcDtkPUR3TUZhUSZhbXA7Yz1IQWtZdWg2M3Jz dWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBv T0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209cTZJX3lLYlhWb2FodjloNUkxd1ppUU1V ZUhMWjVYV3VNb2hFWXR5cG16cyZhbXA7cz1qRUNaTWh5cHc5THR1eHp1bnRrRk5NLThsbTd4cHp0 WXdERExPeENNXzhrJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AD15A3E271BC4134AAFDBA249ABDEEB1junipernet_-- From nobody Wed Apr 18 10:43:42 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDFD127599 for ; Wed, 18 Apr 2018 10:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FVptI5socf1 for ; Wed, 18 Apr 2018 10:43:37 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 74D4E1270A3 for ; Wed, 18 Apr 2018 10:43:37 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id EB7EC1AE030D; Wed, 18 Apr 2018 19:43:35 +0200 (CEST) Date: Wed, 18 Apr 2018 19:43:35 +0200 (CEST) Message-Id: <20180418.194335.1059747539864098574.mbj@tail-f.com> To: kwatsen@juniper.net Cc: andy@yumaworks.com, rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <6e111dfc-efc7-109f-40f5-8cdba72021fc@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 17:43:40 -0000 Hi, [Kent, your email program has messed up the quoting in this thread. It becomes quite difficult to follow. And no, please don't invent a new quoting style in every email thread...] Kent Watsen wrote: > I like Andy's proposal below, for the argument of the 'yang-data' > statement to encode some meta-information regarding the > context/namespace in which it's used, but I wonder how it really > works. I *think* that what Andy proposes is a way to formally specify the context in which the yang-data structure will be used. My proposal was to simply define the context in plain text. A formal way of defining the context would of course be useful -- if we can find agreement on how that would work. I don't think we should hard-code a few contexts in this draft; the mechanism must be extensible. An alternative syntax could be to introduce a new substatement: yd:yang-data foo { yd:context ...; description "..."; } /martin > For instance, would "top" and "error-info" be the only allowed > base-path values for the argument? and what is the value of the > remainder of the path? are we expecting for there to be some kind us > 'uses' statement that can refer to just the base-path component to > implement substitution-group like behavior? > > Kent // contributor > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" > on behalf of > andy@yumaworks.com> wrote: > > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton > > wrote: > > > > On 16/04/2018 17:07, Andy Bierman wrote: > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton > > wrote: > > Don't groupings have a somewhat similar concern? > > E.g. if two groupings define the same data node name and are used at > the same point then you would get a namespace clash, but YANG does not > disallow the groupings: > > > > grouping foo_widget { > > leaf name { > > type string; > > description "Name of my foo widget"; > > } > > } > > > > grouping bar_widget { > > leaf name { > > type string; > > description "Name of my bar widget"; > > } > > } > > > > container all_widgets { > > uses foo_widget; > > uses bar_widget; > > } > > The principal difference here, is that the compiler can easily check > and reject the conflict at the uses statements. > > Hence I think that it would be good if we could find a solution for > yang-data-ext that doesn't not require all root yang-data nodes to be > unique, since that feels somewhat clunky. I.e. my preference is to > keep them less restrictive, as Martin has proposed, if this is > feasible. > > > > It is not clunky that 2 top-level YANG data nodes in the same module > have unique names. This is simple and deterministic. > This restriction has not been a problem so far. > I agree with the statements above. > > But it is not clear to me that yang-data-ext is really defining new > top level data nodes that are part of the same tree/namespace as the > configuration/state nodes. In Martin's examples they were used within > RPCs, and it the forcing the names to be unique in that context that I > think would be clunky. E.g. in Martin's example forcing different > names for "reason" and "user-info" doesn't seem to be helpful. > > > > > The yang-data statement has to define the context or new abstract > namespace, > or whatever this hack is called. > Perhaps. I think that this depends on how they are used. > > > The yang-data statement has to specify the expansion point, or > at least specify that it is or is not the top-level. > > yang-data top/name1 { > container mydata; > } > > where context is something like "top" or "error-info", etc. > > It is trivial to use groupings if the same set of nodes needs to be > used in different contexts: > > > yang-data error-info/name1 { > container mydata; > } > > Only the context named "top" is restricted to a resulting > single-container > and cannot have duplicate names. > > This is OK: > > x:yang-data error-info/my-error1 { > leaf reason {} > } > > > x:yang-data error-info/my-error2 { > leaf reason {} > } > > > > > Could a fix for this be something along the lines of: > - yang-data names must be unique amongst other top level data nodes > - within the module. > - if yang-data extensions are used at the top level then their name must > - be used as a single top level container. > - if a yang-data extension is used within another structure then the > - yang-data name is excluded, and the top level nodes defined in the > - yang-data definition are used .... > > > Every tool that implements yang-data has to be able > to interpret a yang-data statement exactly the same way. > > If you want to reinvent XSD substitutionGroup, then do it right. > I'm not familiar with them. From a quick read, I don't see how they > are related to the problem that we are trying to solve here. > > > A substitutionGroup allows a point int the schema to be identified by > name. > Different elements can be defined that match this name, which then can > be > used (like a YANG choice) at the specified schema point. > (e.g. error-info above is like a substitutionGroup) > > > > Thanks, > Rob > > Andy > > > > > > > > Thanks, > Rob > > > Andy > > > On 16/04/2018 15:36, Andy Bierman wrote: > Hi, > > I am strongly opposed to this change because it breaks the rule in > YANG 1.1 > that there cannot be 2 sibling nodes defined in the same module > namespace. > > IMO since any yang-data nodes are ALLOWED to be used at the top-level, > then these top-level nodes cannot have conflicting names. > > It is very important when parsing an instance document that the > instance data > can be associated with the correct schema. This is not possible if > the > same top-level node has multiple yang-data nodes defined. > > If one needs to define data that is not top-level, (1) use > augment-yang-data > or (2) use a different module. > > > Andy > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund > > wrote: > Hi, > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > it is not clear what, if any, restrictions should be enforced for > yang-data structures. Even among the authors we have different ideas > for how this should work. > > Background: > > In 8040, the original yang-data extension had a restriction that said > that a yang-data structure MUST have exactly one container, since it > wouldn't be possible to have a yang-data structure in an XML instance > document otherwise. > > Since people want to use yang-data structures in other places, this > restriction was lifted in the new draft: > > There is no longer an assumption that a yang data structure can > only be used as a top-level abstraction, instead of nested within > some other data structure. > > > With this in mind, here's a use case that I think we ought to support: > > rpc my-first-rpc { > description > "Bla bla... > If an error occurs, will contain an instance of > the yang-data structure 'my-first-rpc-error-info'."; > ... > } > > yang-data my-first-rpc-error-info { > leaf reason { ... } > container user-info { ... } > } > > rpc my-second-rpc { > description > "Bla bla... > If an error occurs, will contain an instance of > the yang-data structure 'my-second-rpc-error-info'."; > ... > } > > yang-data my-second-rpc-error-info { > leaf reason { ... } > leaf important-url { ... } > } > > (maybe in the future we could even have a YANG extension statement to > formalize the description: > > rpc my-first-rpc { > ... > opx:error-info-structure my-first-rpc-error-info; > } > > but this is not point now.) > > > > I see no reason to reinvent the grouping-stmt. > You could easily say opx:error-info-structure argument is a grouping > name > as it is a yang-data name. > > > > In the example above, note that the leaf "reason" is present in both > structures. IMO this is not a problem, since these structures are > used in different contexts. > > My point is that I think we should impose as few restrictions as > possible to the yang-data extension. It should be up to the user of > yang-data to ensure that the structure is defined in such a way so > that it can be used properly. For example, a structure that is > supposed to describe an XML instance document cannot define two leafs > at the top level. > > If the WG agrees with what I wrote above, we need to change the > augment-yang-data extension so that you would write for example: > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > ... > } > > Comments? > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > From nobody Wed Apr 18 10:44:01 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C021270A3 for ; Wed, 18 Apr 2018 10:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soJCAyHf7UIn for ; Wed, 18 Apr 2018 10:43:45 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1045C12D883 for ; Wed, 18 Apr 2018 10:43:45 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id g203-v6so3862915lfg.11 for ; Wed, 18 Apr 2018 10:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3ZQJKhsJ3vsL87KFn0cwl2CSBnbl+IqG3EV559FooGE=; b=PF3+BQy6+mJP555oOK9+e771aKlfZnzb1BtP5uHH9dl9pNswDPicDxS/9DpagYGgJj bDtakztCLSbKjoywkhpQD240YOn3XuC+XI91fohPilLMWmPv7GX3tPTvjlUt+amrm4lg oLEMtg+A2rbNXCf0QUmmMwZP5XDZmsdEx9huT8Ek3jC1oJ4Hxa+ludj9re0M/rgN0GOM OFkcckMSBlvpGYqVIX8byNB8SLneGZplYgA6JNmnebKEzgTHEn9jgL5kqJiEAv9q0hqI 2yWVlFQK/KIsp9t49IhFxzppP0VoWe3AgZs9p3MUT/D31NWMR2kfXlyj3/6UOIT9HOSE AGSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3ZQJKhsJ3vsL87KFn0cwl2CSBnbl+IqG3EV559FooGE=; b=nxZxW72QX3xFwPRNlk8IAte30Nk37oqaFHYzOJYrfOEWpnAgZVtPxbJ/RormzolELi M9TWiMoB2apF1NMVLuYdKZCultvVOIJ09a1RSE5CQ5KLTHDXNMrVb8MoA/gapFlqEv74 yMYX04YdTwaaPz7xfeSXyQL3F4GTvS0VGv6hzpuSirofoySze8nLmUnHy2xLwQfgATUs V2CF5e+ESiquZyyhQ/ZG8CgZbNHE6SQwFDpVBVdG8Wl2ZnRu+wH0cF5jPiq5L6LAqGWP kv2nCRagKME8wk8/kCxOoxSfR2FFtMgOQ1EZPNTYJdgvsQHgfXRux1DFvjGqom3abNmD fuhw== X-Gm-Message-State: ALQs6tBqQfOsbaBFi1Snj5gdKKSTBtHnXZo0bmfr4X5aV9dgD0OnPQ44 hEaSRirD2OQcFZ8aYnPRykezyPkLH1lPDot0JZJh4g== X-Google-Smtp-Source: AIpwx489rTIlG4PVh1jd0VjLRK+uguQ/1DWCIjjcrkJZFNtlZPeay0o/U8BEtam9MNxSw2Qu3HHfu6GQsbax5ssPLdo= X-Received: by 10.46.62.12 with SMTP id l12mr2005459lja.66.1524073423076; Wed, 18 Apr 2018 10:43:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Wed, 18 Apr 2018 10:43:42 -0700 (PDT) In-Reply-To: References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <6e111dfc-efc7-109f-40f5-8cdba72021fc@cisco.com> From: Andy Bierman Date: Wed, 18 Apr 2018 10:43:42 -0700 Message-ID: To: Kent Watsen Cc: Robert Wilton , NetMod WG Content-Type: multipart/alternative; boundary="f4f5e8075c40fe915c056a22fe47" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 17:43:52 -0000 --f4f5e8075c40fe915c056a22fe47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen wrote: > I like Andy's proposal below, for the argument of the 'yang-data' > statement to encode some meta-information regarding the context/namespace > in which it's used, but I wonder how it really works. For instance, woul= d > "top" and "error-info" be the only allowed base-path values for the > argument? and what is the value of the remainder of the path? are we > expecting for there to be some kind us 'uses' statement that can refer to > just the base-path component to implement substitution-group like behavio= r? > > > If we want to avoid defining these contexts, then we could just define root vs. nonroot. e,g: x:yang-data /mydef1 { container foo; } x:yang-data mydef2 { leaf x; leaf y; container z; } Only an argument starting with '/' would be treated as a top-level data node. All other yang-data definitions are not allowed to appear as a root node. The context where this yang-data is used is completely proprietary. The mechanism used to expand this yang-data as if it was a grouping is completely proprietary. The augment-yang-data extension only applies to top-level yang-data definitions. However, my preference is to only standardize top-level yang-data. I do not see any need for the other form since all functionality can be achieved with a grouping and a proprietary YANG extension. Kent // contributor > Andy > > > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" < > netmod-bounces@ietf.org on behalf of andy@yumaworks.com> wrote: > > > > > > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton wrote: > > > > > > On 16/04/2018 17:07, Andy Bierman wrote: > > > > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton wrote: > > Don't groupings have a somewhat similar concern? > > E.g. if two groupings define the same data node name and are used at the > same point then you would get a namespace clash, but YANG does not disall= ow > the groupings: > > > grouping foo_widget { > > leaf name { > > type string; > > description "Name of my foo widget"; > > } > > } > > > > grouping bar_widget { > > leaf name { > > type string; > > description "Name of my bar widget"; > > } > > } > > > > container all_widgets { > > uses foo_widget; > > uses bar_widget; > > } > > > The principal difference here, is that the compiler can easily check and > reject the conflict at the uses statements. > > Hence I think that it would be good if we could find a solution for > yang-data-ext that doesn't not require all root yang-data nodes to be > unique, since that feels somewhat clunky. I.e. my preference is to keep > them less restrictive, as Martin has proposed, if this is feasible. > > > > > > > > It is not clunky that 2 top-level YANG data nodes in the same module > > have unique names. This is simple and deterministic. > > This restriction has not been a problem so far. > > I agree with the statements above. > > But it is not clear to me that yang-data-ext is really defining new top > level data nodes that are part of the same tree/namespace as the > configuration/state nodes. In Martin's examples they were used within > RPCs, and it the forcing the names to be unique in that context that I > think would be clunky. E.g. in Martin's example forcing different names > for "reason" and "user-info" doesn't seem to be helpful. > > > > > > > The yang-data statement has to define the context or new abstract > namespace, > > or whatever this hack is called. > > Perhaps. I think that this depends on how they are used. > > > > > > The yang-data statement has to specify the expansion point, or > > at least specify that it is or is not the top-level. > > > > yang-data top/name1 { > > container mydata; > > } > > > > where context is something like "top" or "error-info", etc. > > > > It is trivial to use groupings if the same set of nodes needs to be used > in different contexts: > > > > > yang-data error-info/name1 { > > container mydata; > > } > > > > Only the context named "top" is restricted to a resulting single-containe= r > > and cannot have duplicate names. > > > > This is OK: > > > > x:yang-data error-info/my-error1 { > > leaf reason {} > > } > > > > > x:yang-data error-info/my-error2 { > > leaf reason {} > > } > > > > > > > > > Could a fix for this be something along the lines of: > - yang-data names must be unique amongst other top level data nodes > within the module. > - if yang-data extensions are used at the top level then their name must > be used as a single top level container. > - if a yang-data extension is used within another structure then the > yang-data name is excluded, and the top level nodes defined in the > yang-data definition are used .... > > > Every tool that implements yang-data has to be able > > to interpret a yang-data statement exactly the same way. > > > > If you want to reinvent XSD substitutionGroup, then do it right. > > I'm not familiar with them. From a quick read, I don't see how they are > related to the problem that we are trying to solve here. > > > > > > A substitutionGroup allows a point int the schema to be identified by nam= e. > > Different elements can be defined that match this name, which then can be > > used (like a YANG choice) at the specified schema point. > > (e.g. error-info above is like a substitutionGroup) > > > > > > > > Thanks, > Rob > > > > Andy > > > > > > > > > > > > > Thanks, > Rob > > > > > > Andy > > > > > > On 16/04/2018 15:36, Andy Bierman wrote: > > Hi, > > > > I am strongly opposed to this change because it breaks the rule in YANG 1= .1 > > that there cannot be 2 sibling nodes defined in the same module namespace= . > > > > IMO since any yang-data nodes are ALLOWED to be used at the top-level, > > then these top-level nodes cannot have conflicting names. > > > > It is very important when parsing an instance document that the instance > data > > can be associated with the correct schema. This is not possible if the > > same top-level node has multiple yang-data nodes defined. > > > > If one needs to define data that is not top-level, (1) use > augment-yang-data > > or (2) use a different module. > > > > > > Andy > > > > > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund wrote: > > Hi, > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > it is not clear what, if any, restrictions should be enforced for > yang-data structures. Even among the authors we have different ideas > for how this should work. > > Background: > > In 8040, the original yang-data extension had a restriction that said > that a yang-data structure MUST have exactly one container, since it > wouldn't be possible to have a yang-data structure in an XML instance > document otherwise. > > Since people want to use yang-data structures in other places, this > restriction was lifted in the new draft: > > There is no longer an assumption that a yang data structure can > only be used as a top-level abstraction, instead of nested within > some other data structure. > > > With this in mind, here's a use case that I think we ought to support: > > rpc my-first-rpc { > description > "Bla bla... > If an error occurs, will contain an instance of > the yang-data structure 'my-first-rpc-error-info'."; > ... > } > > yang-data my-first-rpc-error-info { > leaf reason { ... } > container user-info { ... } > } > > rpc my-second-rpc { > description > "Bla bla... > If an error occurs, will contain an instance of > the yang-data structure 'my-second-rpc-error-info'."; > ... > } > > yang-data my-second-rpc-error-info { > leaf reason { ... } > leaf important-url { ... } > } > > (maybe in the future we could even have a YANG extension statement to > formalize the description: > > rpc my-first-rpc { > ... > opx:error-info-structure my-first-rpc-error-info; > } > > but this is not point now.) > > > > > > > > I see no reason to reinvent the grouping-stmt. > > You could easily say opx:error-info-structure argument is a grouping name > > as it is a yang-data name. > > > > > > > In the example above, note that the leaf "reason" is present in both > structures. IMO this is not a problem, since these structures are > used in different contexts. > > My point is that I think we should impose as few restrictions as > possible to the yang-data extension. It should be up to the user of > yang-data to ensure that the structure is defined in such a way so > that it can be used properly. For example, a structure that is > supposed to describe an XML instance document cannot define two leafs > at the top level. > > If the WG agrees with what I wrote above, we need to change the > augment-yang-data extension so that you would write for example: > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > ... > } > > Comments? > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > --f4f5e8075c40fe915c056a22fe47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen <kwatsen@juniper.net> wrote:

I like Andy'= s proposal below, for the argument of the 'yang-data' statement to = encode some meta-information regarding the context/namespace in which it= 9;s used, but I wonder how it really works.=C2=A0 For instance, would "top" and "error-info" be the only allowed base-= path values for the argument? and what is the value of the remainder of the= path? =C2=A0are we expecting for there to be some kind us 'uses' s= tatement that can refer to just the base-path component to implement substitution-group like behavior?

=C2=A0



If we w= ant to avoid defining these contexts, then we could just define root vs. no= nroot.

e,g:

x:yang-data /= mydef1 {
=C2=A0 container foo;
}

x:yang-data mydef2 {
=C2=A0 leaf y;
=C2=A0 container z;
}
=C2=A0

Only an argument starting with '/' would be treated as a to= p-level data node.

All other yang-data definitions= are not allowed to appear as a root node.
The context where this= yang-data is used is completely proprietary.
The mechanism used = to expand this yang-data as if it was a grouping
is completely pr= oprietary.

The augment-yang-data extension only ap= plies to top-level yang-data definitions.

However,= my preference is to only standardize top-level yang-data.
I do n= ot see any need for the other form since all functionality can be
achieved with a grouping and a proprietary YANG extension.

<= /div>

Kent // contribu= tor


Andy
= =C2=A0

=C2=A0=

=C2=A0=

=C2=A0

=C2=A0

=C2=A0

On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton <<= a href=3D"mailto:rwilton@cisco.com" target=3D"_blank">rwilton@cisco.com= > wrote:

=C2=A0

=C2=A0

On 16/04/2018 17:07, Andy Bierman wrote:

=C2=A0

=C2=A0

On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton <<= a href=3D"mailto:rwilton@cisco.com" target=3D"_blank">rwilton@cisco.com= > wrote:

Don't groupings have a somewhat similar concern?=

=C2=A0E.g. if two groupings define the same data node name and are used at = the same point then you would get a namespace clash, but YANG does not disa= llow the groupings:


=C2=A0=C2=A0=C2=A0=C2=A0 grouping foo_widg=
et {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf =
name {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 type string;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 description "Name of my foo widget";<=
/pre>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0}<=
/u>


=C2=A0=C2=A0=C2=A0=C2=A0 }


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0 grouping bar_widg=
et {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf =
name {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 type string;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 description "Name of my bar widget";<=
/pre>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0}<=
/u>


=C2=A0=C2=A0=C2=A0=C2=A0 }


=C2=A0


=
=C2=A0=C2=A0=C2=A0=C2=A0 container all_widgets {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uses =
foo_widget;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uses =
bar_widget;


=C2=A0=C2=A0=C2=A0=C2=A0 }




The principal difference here, is that the compiler can easily check and re=
ject the conflict at the uses statements.



Hence I think that it would be good if we could find a solution for yang-da=
ta-ext that doesn't not require all root yang-data nodes to be unique, =
since that feels somewhat clunky.=C2=A0 I.e. my preference is to keep them =
less restrictive, as Martin has proposed,
 if this is feasible.

=C2=A0

=C2=A0

=C2=A0

It is not clunky that 2 top-level YANG data nodes in= the same module

have unique names. This is simple and deterministic.=

This restriction has not been a problem so far.

I agree with the statements above.

But it is not clear to me that yang-data-ext is really defining new top lev= el data nodes that are part of the same tree/namespace as the configuration= /state nodes.=C2=A0 In Martin's examples they were used within RPCs, an= d it the forcing the names to be unique in that context that I think would be clunky.=C2=A0 E.g. in Martin's exam= ple forcing different names for "reason" and "user-info"= ; doesn't seem to be helpful.


=C2=A0

=C2=A0

The yang-data statement has to define the context or= new abstract namespace,

or whatever this hack is called.

Perhaps.=C2=A0 I think that this depends on how they= are used.

=C2=A0

=C2=A0

The yang-data statement has to specify the expansion= point, or

at least specify that it is or is not the top-level.=

=C2=A0

=C2=A0 yang-data top/name1 {

=C2=A0 =C2=A0 =C2=A0 container mydata;=

=C2=A0 }

=C2=A0

where context is something like "top" or &= quot;error-info", etc.

=C2=A0

It is trivial to use groupings if the same set of no= des needs to be used in different contexts:

=C2=A0


=C2=A0 yang-data error-info/name1 {

=C2=A0 =C2=A0 =C2=A0 container mydata;=

=C2=A0 }

=C2=A0

Only the context named "top" is restricted= to a resulting single-container

and cannot have duplicate names.

=C2=A0

This is OK:

=C2=A0

=C2=A0 x:yang-data error-info/my-error1 {<= /u>

=C2=A0 =C2=A0 =C2=A0 leaf reason {}

=C2=A0 }

=C2=A0


=C2=A0 x:yang-data error-info/my-error2 {

=C2=A0 =C2=A0 =C2=A0 leaf reason {}

=C2=A0 }

=C2=A0

=C2=A0

=C2=A0


Could a fix for this be something along the lines of:
=C2=A0- yang-data names must be unique amongst other top level data nodes w= ithin the module.
=C2=A0- if yang-data extensions are used at the top level then their name m= ust be used as a single top level container.
=C2=A0- if a yang-data extension is used within another structure then the = yang-data name is excluded, and the top level nodes defined in the yang-dat= a definition are used ....


=C2=A0 Every tool that implements yang-data has to b= e able

to interpret a yang-data statement exactly the same = way.

=C2=A0

If you want to reinvent XSD substitutionGroup, then = do it right.

I'm not familiar = with them.=C2=A0 From a quick read, I don't see how they are related to= the problem that we are trying to solve here.

=C2=A0

=C2=A0

A substitutionGroup allows a point int the schema to= be identified by name.

Different elements can be defined that match this na= me, which then can be

used (like a YANG choice) at the specified schema po= int.

(e.g. error-info above is like a substitutionGroup)<= u>

=C2=A0

=C2=A0

=C2=A0

Thanks,
Rob

=C2=A0

Andy

=C2=A0




=C2=A0

=C2=A0

=C2=A0

Thanks,
Rob

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

On 16/04/2018 15:36, Andy Bierman wrote:

Hi,

=C2=A0

I am strongly opposed to this change because it brea= ks the rule in YANG 1.1

that there cannot be 2 sibling nodes defined in the = same module namespace.

=C2=A0

IMO since any yang-data nodes are ALLOWED to be used= at the top-level,

then these top-level nodes cannot have conflicting n= ames.

=C2=A0

It is very important when parsing an instance docume= nt that the instance data

can be associated with the correct schema.=C2=A0 Thi= s is not possible if the

same top-level node has multiple yang-data nodes def= ined.

=C2=A0

If one needs to define data that is not top-level, (= 1) use augment-yang-data

or (2) use a different module.

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:

Hi,

While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that=
it is not clear what, if any, restrictions should be enforced for
yang-data structures.=C2=A0 Even among the authors we have different ideas<= br> for how this should work.

Background:

In 8040, the original yang-data extension had a restriction that said
that a yang-data structure MUST have exactly one container, since it
wouldn't be possible to have a yang-data structure in an XML instance document otherwise.

Since people want to use yang-data structures in other places, this
restriction was lifted in the new draft:

=C2=A0 =C2=A0There is no longer an assumption that a yang data structure ca= n
=C2=A0 =C2=A0only be used as a top-level abstraction, instead of nested wit= hin
=C2=A0 =C2=A0some other data structure.


With this in mind, here's a use case that I think we ought to support:<= br>
=C2=A0 rpc my-first-rpc {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "Bla bla...
=C2=A0 =C2=A0 =C2=A0 =C2=A0If an error occurs, <error-info> will cont= ain an instance of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the yang-data structure 'my-first-rpc-error-= info'.";
=C2=A0 =C2=A0 ...
=C2=A0 }

=C2=A0 yang-data my-first-rpc-error-info {
=C2=A0 =C2=A0 leaf reason { ... }
=C2=A0 =C2=A0 container user-info { ... }
=C2=A0 }

=C2=A0 rpc my-second-rpc {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "Bla bla...
=C2=A0 =C2=A0 =C2=A0 =C2=A0If an error occurs, <error-info> will cont= ain an instance of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the yang-data structure 'my-second-rpc-error= -info'.";
=C2=A0 =C2=A0 ...
=C2=A0 }

=C2=A0 yang-data my-second-rpc-error-info {
=C2=A0 =C2=A0 leaf reason { ... }
=C2=A0 =C2=A0 leaf important-url { ... }
=C2=A0 }

(maybe in the future we could even have a YANG extension statement to
formalize the description:

=C2=A0 =C2=A0rpc my-first-rpc {
=C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0opx:error-info-structure my-first-rpc-error-info;
=C2=A0 =C2=A0}

but this is not point now.)

=C2=A0

=C2=A0

=C2=A0

I see no reason to reinvent the grouping-stmt.

You could easily say opx:error-info-structure argume= nt is a grouping name

as it is a yang-data name.

=C2=A0

=C2=A0


In the example above, note that the leaf "reason" is present in b= oth
structures.=C2=A0 IMO this is not a problem, since these structures are
used in different contexts.

My point is that I think we should impose as few restrictions as
possible to the yang-data extension.=C2=A0 It should be up to the user of yang-data to ensure that the structure is defined in such a way so
that it can be used properly.=C2=A0 For example, a structure that is
supposed to describe an XML instance document cannot define two leafs
at the top level.

If the WG agrees with what I wrote above, we need to change the
augment-yang-data extension so that you would write for example:

=C2=A0 yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {=
=C2=A0 =C2=A0 ...
=C2=A0 }

Comments?



/martin

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/= mailman/listinfo/netmod

=C2=A0



_______________________________________________

netmod mailing list


netmod@ietf.org


https://www.ietf=
.org/mailman/listinfo/netmod

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--f4f5e8075c40fe915c056a22fe47-- From nobody Wed Apr 18 10:47:49 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EAF12778E for ; Wed, 18 Apr 2018 10:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KocrSJtB2dNc for ; Wed, 18 Apr 2018 10:47:45 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 57C9A12778D for ; Wed, 18 Apr 2018 10:47:45 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 981731AE030D; Wed, 18 Apr 2018 19:47:44 +0200 (CEST) Date: Wed, 18 Apr 2018 19:47:44 +0200 (CEST) Message-Id: <20180418.194744.1882806546121321450.mbj@tail-f.com> To: andy@yumaworks.com Cc: kwatsen@juniper.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 17:47:48 -0000 Hi, Andy Bierman wrote: > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen wrote: > > > I like Andy's proposal below, for the argument of the 'yang-data' > > statement to encode some meta-information regarding the context/namespace > > in which it's used, but I wonder how it really works. For instance, would > > "top" and "error-info" be the only allowed base-path values for the > > argument? and what is the value of the remainder of the path? are we > > expecting for there to be some kind us 'uses' statement that can refer to > > just the base-path component to implement substitution-group like behavior? > > > > > > > > > If we want to avoid defining these contexts, then we could just define root > vs. nonroot. > > e,g: > > x:yang-data /mydef1 { > container foo; > } > > x:yang-data mydef2 { > leaf x; > leaf y; > container z; > } > > > Only an argument starting with '/' would be treated as a top-level data > node. > > All other yang-data definitions are not allowed to appear as a root node. > The context where this yang-data is used is completely proprietary. > The mechanism used to expand this yang-data as if it was a grouping > is completely proprietary. > > The augment-yang-data extension only applies to top-level yang-data > definitions. > > However, my preference is to only standardize top-level yang-data. What is "top-level" yang-data? /martin > I do not see any need for the other form since all functionality can be > achieved with a grouping and a proprietary YANG extension. > > Kent // contributor > > > > Andy > > > > > > > > > > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" < > > netmod-bounces@ietf.org on behalf of andy@yumaworks.com> wrote: > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton wrote: > > > > > > > > > > > > On 16/04/2018 17:07, Andy Bierman wrote: > > > > > > > > > > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton wrote: > > > > Don't groupings have a somewhat similar concern? > > > > E.g. if two groupings define the same data node name and are used at the > > same point then you would get a namespace clash, but YANG does not disallow > > the groupings: > > > > > > grouping foo_widget { > > > > leaf name { > > > > type string; > > > > description "Name of my foo widget"; > > > > } > > > > } > > > > > > > > grouping bar_widget { > > > > leaf name { > > > > type string; > > > > description "Name of my bar widget"; > > > > } > > > > } > > > > > > > > container all_widgets { > > > > uses foo_widget; > > > > uses bar_widget; > > > > } > > > > > > The principal difference here, is that the compiler can easily check and > > reject the conflict at the uses statements. > > > > Hence I think that it would be good if we could find a solution for > > yang-data-ext that doesn't not require all root yang-data nodes to be > > unique, since that feels somewhat clunky. I.e. my preference is to keep > > them less restrictive, as Martin has proposed, if this is feasible. > > > > > > > > > > > > > > > > It is not clunky that 2 top-level YANG data nodes in the same module > > > > have unique names. This is simple and deterministic. > > > > This restriction has not been a problem so far. > > > > I agree with the statements above. > > > > But it is not clear to me that yang-data-ext is really defining new top > > level data nodes that are part of the same tree/namespace as the > > configuration/state nodes. In Martin's examples they were used within > > RPCs, and it the forcing the names to be unique in that context that I > > think would be clunky. E.g. in Martin's example forcing different names > > for "reason" and "user-info" doesn't seem to be helpful. > > > > > > > > > > > > > > The yang-data statement has to define the context or new abstract > > namespace, > > > > or whatever this hack is called. > > > > Perhaps. I think that this depends on how they are used. > > > > > > > > > > > > The yang-data statement has to specify the expansion point, or > > > > at least specify that it is or is not the top-level. > > > > > > > > yang-data top/name1 { > > > > container mydata; > > > > } > > > > > > > > where context is something like "top" or "error-info", etc. > > > > > > > > It is trivial to use groupings if the same set of nodes needs to be used > > in different contexts: > > > > > > > > > > yang-data error-info/name1 { > > > > container mydata; > > > > } > > > > > > > > Only the context named "top" is restricted to a resulting single-container > > > > and cannot have duplicate names. > > > > > > > > This is OK: > > > > > > > > x:yang-data error-info/my-error1 { > > > > leaf reason {} > > > > } > > > > > > > > > > x:yang-data error-info/my-error2 { > > > > leaf reason {} > > > > } > > > > > > > > > > > > > > > > > > Could a fix for this be something along the lines of: > > - yang-data names must be unique amongst other top level data nodes > > within the module. > > - if yang-data extensions are used at the top level then their name must > > be used as a single top level container. > > - if a yang-data extension is used within another structure then the > > yang-data name is excluded, and the top level nodes defined in the > > yang-data definition are used .... > > > > > > Every tool that implements yang-data has to be able > > > > to interpret a yang-data statement exactly the same way. > > > > > > > > If you want to reinvent XSD substitutionGroup, then do it right. > > > > I'm not familiar with them. From a quick read, I don't see how they are > > related to the problem that we are trying to solve here. > > > > > > > > > > > > A substitutionGroup allows a point int the schema to be identified by name. > > > > Different elements can be defined that match this name, which then can be > > > > used (like a YANG choice) at the specified schema point. > > > > (e.g. error-info above is like a substitutionGroup) > > > > > > > > > > > > > > > > Thanks, > > Rob > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > Rob > > > > > > > > > > > > Andy > > > > > > > > > > > > On 16/04/2018 15:36, Andy Bierman wrote: > > > > Hi, > > > > > > > > I am strongly opposed to this change because it breaks the rule in YANG 1..1 > > > > that there cannot be 2 sibling nodes defined in the same module namespace.. > > > > > > > > IMO since any yang-data nodes are ALLOWED to be used at the top-level, > > > > then these top-level nodes cannot have conflicting names. > > > > > > > > It is very important when parsing an instance document that the instance > > data > > > > can be associated with the correct schema. This is not possible if the > > > > same top-level node has multiple yang-data nodes defined. > > > > > > > > If one needs to define data that is not top-level, (1) use > > augment-yang-data > > > > or (2) use a different module. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund wrote: > > > > Hi, > > > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > > it is not clear what, if any, restrictions should be enforced for > > yang-data structures. Even among the authors we have different ideas > > for how this should work. > > > > Background: > > > > In 8040, the original yang-data extension had a restriction that said > > that a yang-data structure MUST have exactly one container, since it > > wouldn't be possible to have a yang-data structure in an XML instance > > document otherwise. > > > > Since people want to use yang-data structures in other places, this > > restriction was lifted in the new draft: > > > > There is no longer an assumption that a yang data structure can > > only be used as a top-level abstraction, instead of nested within > > some other data structure. > > > > > > With this in mind, here's a use case that I think we ought to support: > > > > rpc my-first-rpc { > > description > > "Bla bla... > > If an error occurs, will contain an instance of > > the yang-data structure 'my-first-rpc-error-info'."; > > ... > > } > > > > yang-data my-first-rpc-error-info { > > leaf reason { ... } > > container user-info { ... } > > } > > > > rpc my-second-rpc { > > description > > "Bla bla... > > If an error occurs, will contain an instance of > > the yang-data structure 'my-second-rpc-error-info'."; > > ... > > } > > > > yang-data my-second-rpc-error-info { > > leaf reason { ... } > > leaf important-url { ... } > > } > > > > (maybe in the future we could even have a YANG extension statement to > > formalize the description: > > > > rpc my-first-rpc { > > ... > > opx:error-info-structure my-first-rpc-error-info; > > } > > > > but this is not point now.) > > > > > > > > > > > > > > > > I see no reason to reinvent the grouping-stmt. > > > > You could easily say opx:error-info-structure argument is a grouping name > > > > as it is a yang-data name. > > > > > > > > > > > > > > In the example above, note that the leaf "reason" is present in both > > structures. IMO this is not a problem, since these structures are > > used in different contexts. > > > > My point is that I think we should impose as few restrictions as > > possible to the yang-data extension. It should be up to the user of > > yang-data to ensure that the structure is defined in such a way so > > that it can be used properly. For example, a structure that is > > supposed to describe an XML instance document cannot define two leafs > > at the top level. > > > > If the WG agrees with what I wrote above, we need to change the > > augment-yang-data extension so that you would write for example: > > > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > > ... > > } > > > > Comments? > > > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > > > > From nobody Wed Apr 18 10:52:08 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD5E12778D for ; Wed, 18 Apr 2018 10:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdsSVMdDNpWL for ; Wed, 18 Apr 2018 10:52:03 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C453124207 for ; Wed, 18 Apr 2018 10:52:02 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id r7-v6so3934480lfr.1 for ; Wed, 18 Apr 2018 10:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HjO6jJ7pqsd+43iqPXUru5P0kEaXM5YKMdlG9Ye6Z/Q=; b=FDBErsuRwNO2J7EAAxbVDqm+Yi8NHweWUl2cXgkz6dv+AZ04Xs1YpbcpM2SjA69Csm YDyQShDm4opWLh5Gh23BOlPh8I+D+wGmWDd7YeCIj04KTSTdj2tHVeHLaT/31HzHmBjA xFunpTEFEpo3yph1YMFnpmWv8nLgUfRcANTFE9ZI8Ph29NokX53kJGoPMSr5BT4kp7qF j1AaUQ0yXan3BL3eGiuniD0DfJKgartEtm66/dngaLSq6XXko+12VYApSxN0XPHtq2ui 3Dae7iEMp1GSyB1fG8qfpNQLPAzCr5VQBKAKVIfSNsw9k1VWsXOKMy32aIa/SWRerWjU D/fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HjO6jJ7pqsd+43iqPXUru5P0kEaXM5YKMdlG9Ye6Z/Q=; b=Z08HWWTZhh4xcJaHJmnWSoucMdOdK0QVFoP8M6ktDTgFg1QJvxstqlEYbhc8tWzd+G 3+GIoZnX42v/JBfbd7/9yf4XS0YFgUXicsqtV6X9BzQEEH73Np5NG63lN0kRns4X+F6c 5+oWujbLH7etpMfyVak2ktR6cXwTpaD3+JsLlNbCpBPgWfXSr6r6h21/zazjd4pvftfj AcOwXV79pKTX4LTCHq7HyAN0WnxZphEwRSAaUoiXUlCmkY4sjg1/FV1B5TxOTijmjUeJ 4jMOBwmT4xZEtbIfx2E/qFY8vesRaj3ACQNBRoEHqdt0NE7IbiOHRLG5tU3qgSCIVMz8 yqZw== X-Gm-Message-State: ALQs6tA62DOOdLlha/Z7p+z4lx9RP0U2bhXyWk5lWJOxE6vZY4LLCUOD DsEVk1cEa19uGDNf4ey4ZFfc+xZDE9IJcBGC4mSlAQ== X-Google-Smtp-Source: AIpwx4+AGv/LZoSnQmxR3CB6taMHZYMp4MW6C/aKyav24EcNt3fsCS+eiYDJiXFAF/Sz4ZkNLHeNW0EQep6Evsu65GE= X-Received: by 10.46.127.10 with SMTP id a10mr2043912ljd.78.1524073920435; Wed, 18 Apr 2018 10:52:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Wed, 18 Apr 2018 10:51:59 -0700 (PDT) In-Reply-To: <20180418.194744.1882806546121321450.mbj@tail-f.com> References: <20180418.194744.1882806546121321450.mbj@tail-f.com> From: Andy Bierman Date: Wed, 18 Apr 2018 10:51:59 -0700 Message-ID: To: Martin Bjorklund Cc: Kent Watsen , NetMod WG Content-Type: multipart/alternative; boundary="089e082b3ee8a3ab87056a231cb1" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 17:52:07 -0000 --089e082b3ee8a3ab87056a231cb1 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen > wrote: > > > > > I like Andy's proposal below, for the argument of the 'yang-data' > > > statement to encode some meta-information regarding the > context/namespace > > > in which it's used, but I wonder how it really works. For instance, > would > > > "top" and "error-info" be the only allowed base-path values for the > > > argument? and what is the value of the remainder of the path? are we > > > expecting for there to be some kind us 'uses' statement that can refer > to > > > just the base-path component to implement substitution-group like > behavior? > > > > > > > > > > > > > > > If we want to avoid defining these contexts, then we could just define > root > > vs. nonroot. > > > > e,g: > > > > x:yang-data /mydef1 { > > container foo; > > } > > > > x:yang-data mydef2 { > > leaf x; > > leaf y; > > container z; > > } > > > > > > Only an argument starting with '/' would be treated as a top-level data > > node. > > > > All other yang-data definitions are not allowed to appear as a root node. > > The context where this yang-data is used is completely proprietary. > > The mechanism used to expand this yang-data as if it was a grouping > > is completely proprietary. > > > > The augment-yang-data extension only applies to top-level yang-data > > definitions. > > > > However, my preference is to only standardize top-level yang-data. > > What is "top-level" yang-data? > > > It is a data structure that represents an instance document. Since this is the ONLY definition of yang-data we have in the standard, what is a yang-data definition that represents some unspecified usage, other than an instance document? Why is this any different than a YANG grouping? > /martin > > > Andy > > I do not see any need for the other form since all functionality can be > > achieved with a grouping and a proprietary YANG extension. > > > > Kent // contributor > > > > > > > Andy > > > > > > > > > > > > > > > > > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" < > > > netmod-bounces@ietf.org on behalf of andy@yumaworks.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton > wrote: > > > > > > > > > > > > > > > > > > On 16/04/2018 17:07, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton > wrote: > > > > > > Don't groupings have a somewhat similar concern? > > > > > > E.g. if two groupings define the same data node name and are used at > the > > > same point then you would get a namespace clash, but YANG does not > disallow > > > the groupings: > > > > > > > > > grouping foo_widget { > > > > > > leaf name { > > > > > > type string; > > > > > > description "Name of my foo widget"; > > > > > > } > > > > > > } > > > > > > > > > > > > grouping bar_widget { > > > > > > leaf name { > > > > > > type string; > > > > > > description "Name of my bar widget"; > > > > > > } > > > > > > } > > > > > > > > > > > > container all_widgets { > > > > > > uses foo_widget; > > > > > > uses bar_widget; > > > > > > } > > > > > > > > > The principal difference here, is that the compiler can easily check > and > > > reject the conflict at the uses statements. > > > > > > Hence I think that it would be good if we could find a solution for > > > yang-data-ext that doesn't not require all root yang-data nodes to be > > > unique, since that feels somewhat clunky. I.e. my preference is to > keep > > > them less restrictive, as Martin has proposed, if this is feasible. > > > > > > > > > > > > > > > > > > > > > > > > It is not clunky that 2 top-level YANG data nodes in the same module > > > > > > have unique names. This is simple and deterministic. > > > > > > This restriction has not been a problem so far. > > > > > > I agree with the statements above. > > > > > > But it is not clear to me that yang-data-ext is really defining new top > > > level data nodes that are part of the same tree/namespace as the > > > configuration/state nodes. In Martin's examples they were used within > > > RPCs, and it the forcing the names to be unique in that context that I > > > think would be clunky. E.g. in Martin's example forcing different > names > > > for "reason" and "user-info" doesn't seem to be helpful. > > > > > > > > > > > > > > > > > > > > > The yang-data statement has to define the context or new abstract > > > namespace, > > > > > > or whatever this hack is called. > > > > > > Perhaps. I think that this depends on how they are used. > > > > > > > > > > > > > > > > > > The yang-data statement has to specify the expansion point, or > > > > > > at least specify that it is or is not the top-level. > > > > > > > > > > > > yang-data top/name1 { > > > > > > container mydata; > > > > > > } > > > > > > > > > > > > where context is something like "top" or "error-info", etc. > > > > > > > > > > > > It is trivial to use groupings if the same set of nodes needs to be > used > > > in different contexts: > > > > > > > > > > > > > > > yang-data error-info/name1 { > > > > > > container mydata; > > > > > > } > > > > > > > > > > > > Only the context named "top" is restricted to a resulting > single-container > > > > > > and cannot have duplicate names. > > > > > > > > > > > > This is OK: > > > > > > > > > > > > x:yang-data error-info/my-error1 { > > > > > > leaf reason {} > > > > > > } > > > > > > > > > > > > > > > x:yang-data error-info/my-error2 { > > > > > > leaf reason {} > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > Could a fix for this be something along the lines of: > > > - yang-data names must be unique amongst other top level data nodes > > > within the module. > > > - if yang-data extensions are used at the top level then their name > must > > > be used as a single top level container. > > > - if a yang-data extension is used within another structure then the > > > yang-data name is excluded, and the top level nodes defined in the > > > yang-data definition are used .... > > > > > > > > > Every tool that implements yang-data has to be able > > > > > > to interpret a yang-data statement exactly the same way. > > > > > > > > > > > > If you want to reinvent XSD substitutionGroup, then do it right. > > > > > > I'm not familiar with them. From a quick read, I don't see how they > are > > > related to the problem that we are trying to solve here. > > > > > > > > > > > > > > > > > > A substitutionGroup allows a point int the schema to be identified by > name. > > > > > > Different elements can be defined that match this name, which then can > be > > > > > > used (like a YANG choice) at the specified schema point. > > > > > > (e.g. error-info above is like a substitutionGroup) > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > Rob > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > Rob > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On 16/04/2018 15:36, Andy Bierman wrote: > > > > > > Hi, > > > > > > > > > > > > I am strongly opposed to this change because it breaks the rule in > YANG 1..1 > > > > > > that there cannot be 2 sibling nodes defined in the same module > namespace.. > > > > > > > > > > > > IMO since any yang-data nodes are ALLOWED to be used at the top-level, > > > > > > then these top-level nodes cannot have conflicting names. > > > > > > > > > > > > It is very important when parsing an instance document that the > instance > > > data > > > > > > can be associated with the correct schema. This is not possible if the > > > > > > same top-level node has multiple yang-data nodes defined. > > > > > > > > > > > > If one needs to define data that is not top-level, (1) use > > > augment-yang-data > > > > > > or (2) use a different module. > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund > wrote: > > > > > > Hi, > > > > > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > > > it is not clear what, if any, restrictions should be enforced for > > > yang-data structures. Even among the authors we have different ideas > > > for how this should work. > > > > > > Background: > > > > > > In 8040, the original yang-data extension had a restriction that said > > > that a yang-data structure MUST have exactly one container, since it > > > wouldn't be possible to have a yang-data structure in an XML instance > > > document otherwise. > > > > > > Since people want to use yang-data structures in other places, this > > > restriction was lifted in the new draft: > > > > > > There is no longer an assumption that a yang data structure can > > > only be used as a top-level abstraction, instead of nested within > > > some other data structure. > > > > > > > > > With this in mind, here's a use case that I think we ought to support: > > > > > > rpc my-first-rpc { > > > description > > > "Bla bla... > > > If an error occurs, will contain an instance of > > > the yang-data structure 'my-first-rpc-error-info'."; > > > ... > > > } > > > > > > yang-data my-first-rpc-error-info { > > > leaf reason { ... } > > > container user-info { ... } > > > } > > > > > > rpc my-second-rpc { > > > description > > > "Bla bla... > > > If an error occurs, will contain an instance of > > > the yang-data structure 'my-second-rpc-error-info'."; > > > ... > > > } > > > > > > yang-data my-second-rpc-error-info { > > > leaf reason { ... } > > > leaf important-url { ... } > > > } > > > > > > (maybe in the future we could even have a YANG extension statement to > > > formalize the description: > > > > > > rpc my-first-rpc { > > > ... > > > opx:error-info-structure my-first-rpc-error-info; > > > } > > > > > > but this is not point now.) > > > > > > > > > > > > > > > > > > > > > > > > I see no reason to reinvent the grouping-stmt. > > > > > > You could easily say opx:error-info-structure argument is a grouping > name > > > > > > as it is a yang-data name. > > > > > > > > > > > > > > > > > > > > > In the example above, note that the leaf "reason" is present in both > > > structures. IMO this is not a problem, since these structures are > > > used in different contexts. > > > > > > My point is that I think we should impose as few restrictions as > > > possible to the yang-data extension. It should be up to the user of > > > yang-data to ensure that the structure is defined in such a way so > > > that it can be used properly. For example, a structure that is > > > supposed to describe an XML instance document cannot define two leafs > > > at the top level. > > > > > > If the WG agrees with what I wrote above, we need to change the > > > augment-yang-data extension so that you would write for example: > > > > > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > > > ... > > > } > > > > > > Comments? > > > > > > > > > > > > /martin > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c= > HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r= > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_ > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM- > 8lm7xpztYwDDLOxCM_8k&e=> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netmod proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ > listinfo_netmod&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r= > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_ > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM- > 8lm7xpztYwDDLOxCM_8k&e=> > > > > > > > > > > > > > > > > > > > > > > > > > > > > --089e082b3ee8a3ab87056a231cb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Hi,

Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen <kwatsen@juniper.net> wrote:
>
> > I like Andy's proposal below, for the argument of the 'ya= ng-data'
> > statement to encode some meta-information regarding the context/n= amespace
> > in which it's used, but I wonder how it really works.=C2=A0 F= or instance, would
> > "top" and "error-info" be the only allowed ba= se-path values for the
> > argument? and what is the value of the remainder of the path?=C2= =A0 are we
> > expecting for there to be some kind us 'uses' statement t= hat can refer to
> > just the base-path component to implement substitution-group like= behavior?
> >
> >
> >
>
>
> If we want to avoid defining these contexts, then we could just define= root
> vs. nonroot.
>
> e,g:
>
> x:yang-data /mydef1 {
>=C2=A0 =C2=A0container foo;
> }
>
> x:yang-data mydef2 {
>=C2=A0 =C2=A0leaf x;
>=C2=A0 =C2=A0leaf y;
>=C2=A0 =C2=A0container z;
> }
>
>
> Only an argument starting with '/' would be treated as a top-l= evel data
> node.
>
> All other yang-data definitions are not allowed to appear as a root no= de.
> The context where this yang-data is used is completely proprietary. > The mechanism used to expand this yang-data as if it was a grouping > is completely proprietary.
>
> The augment-yang-data extension only applies to top-level yang-data > definitions.
>
> However, my preference is to only standardize top-level yang-data.

What is "top-level" yang-data?



It is a data structure that represents= an instance document.

Since this is the ONLY defi= nition of yang-data we have in the standard,
what is a yang-data = definition that represents some unspecified usage,
other than an = instance document?

Why is this any different than = a YANG grouping?

=C2=A0
/martin



Andy

=C2=A0
> I do not see any need for the other form since all functionality can b= e
> achieved with a grouping and a proprietary YANG extension.
>
> Kent // contributor
> >
>
> Andy
>
>
> >
> >
> >
> >
> > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman"= <
> > netmod-bounces@ietf.or= g on behalf of andy@yumaworks.com= > wrote:
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton <rwilton@cisco.com> wrote:
> >
> >
> >
> >
> >
> > On 16/04/2018 17:07, Andy Bierman wrote:
> >
> >
> >
> >
> >
> > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton <rwilton@cisco.com> wrote:
> >
> > Don't groupings have a somewhat similar concern?
> >
> >=C2=A0 E.g. if two groupings define the same data node name and ar= e used at the
> > same point then you would get a namespace clash, but YANG does no= t disallow
> > the groupings:
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 grouping foo_widget {
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name {
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "Name of my fo= o widget";
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >
> >=C2=A0 =C2=A0 =C2=A0 }
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 grouping bar_widget {
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name {
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "Name of my ba= r widget";
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >
> >=C2=A0 =C2=A0 =C2=A0 }
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 container all_widgets {
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses foo_widget;
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses bar_widget;
> >
> >=C2=A0 =C2=A0 =C2=A0 }
> >
> >
> > The principal difference here, is that the compiler can easily ch= eck and
> > reject the conflict at the uses statements.
> >
> > Hence I think that it would be good if we could find a solution f= or
> > yang-data-ext that doesn't not require all root yang-data nod= es to be
> > unique, since that feels somewhat clunky.=C2=A0 I.e. my preferenc= e is to keep
> > them less restrictive, as Martin has proposed, if this is feasibl= e.
> >
> >
> >
> >
> >
> >
> >
> > It is not clunky that 2 top-level YANG data nodes in the same mod= ule
> >
> > have unique names. This is simple and deterministic.
> >
> > This restriction has not been a problem so far.
> >
> > I agree with the statements above.
> >
> > But it is not clear to me that yang-data-ext is really defining n= ew top
> > level data nodes that are part of the same tree/namespace as the<= br> > > configuration/state nodes.=C2=A0 In Martin's examples they we= re used within
> > RPCs, and it the forcing the names to be unique in that context t= hat I
> > think would be clunky.=C2=A0 E.g. in Martin's example forcing= different names
> > for "reason" and "user-info" doesn't seem= to be helpful.
> >
> >
> >
> >
> >
> >
> > The yang-data statement has to define the context or new abstract=
> > namespace,
> >
> > or whatever this hack is called.
> >
> > Perhaps.=C2=A0 I think that this depends on how they are used. > >
> >
> >
> >
> >
> > The yang-data statement has to specify the expansion point, or > >
> > at least specify that it is or is not the top-level.
> >
> >
> >
> >=C2=A0 =C2=A0yang-data top/name1 {
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0container mydata;
> >
> >=C2=A0 =C2=A0}
> >
> >
> >
> > where context is something like "top" or "error-in= fo", etc.
> >
> >
> >
> > It is trivial to use groupings if the same set of nodes needs to = be used
> > in different contexts:
> >
> >
> >
> >
> >=C2=A0 =C2=A0yang-data error-info/name1 {
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0container mydata;
> >
> >=C2=A0 =C2=A0}
> >
> >
> >
> > Only the context named "top" is restricted to a resulti= ng single-container
> >
> > and cannot have duplicate names.
> >
> >
> >
> > This is OK:
> >
> >
> >
> >=C2=A0 =C2=A0x:yang-data error-info/my-error1 {
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf reason {}
> >
> >=C2=A0 =C2=A0}
> >
> >
> >
> >
> >=C2=A0 =C2=A0x:yang-data error-info/my-error2 {
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf reason {}
> >
> >=C2=A0 =C2=A0}
> >
> >
> >
> >
> >
> >
> >
> >
> > Could a fix for this be something along the lines of:
> >=C2=A0 - yang-data names must be unique amongst other top level da= ta nodes
> > within the module.
> >=C2=A0 - if yang-data extensions are used at the top level then th= eir name must
> > be used as a single top level container.
> >=C2=A0 - if a yang-data extension is used within another structure= then the
> > yang-data name is excluded, and the top level nodes defined in th= e
> > yang-data definition are used ....
> >
> >
> >=C2=A0 =C2=A0Every tool that implements yang-data has to be able > >
> > to interpret a yang-data statement exactly the same way.
> >
> >
> >
> > If you want to reinvent XSD substitutionGroup, then do it right.<= br> > >
> > I'm not familiar with them.=C2=A0 From a quick read, I don= 9;t see how they are
> > related to the problem that we are trying to solve here.
> >
> >
> >
> >
> >
> > A substitutionGroup allows a point int the schema to be identifie= d by name.
> >
> > Different elements can be defined that match this name, which the= n can be
> >
> > used (like a YANG choice) at the specified schema point.
> >
> > (e.g. error-info above is like a substitutionGroup)
> >
> >
> >
> >
> >
> >
> >
> > Thanks,
> > Rob
> >
> >
> >
> > Andy
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Thanks,
> > Rob
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> >
> > On 16/04/2018 15:36, Andy Bierman wrote:
> >
> > Hi,
> >
> >
> >
> > I am strongly opposed to this change because it breaks the rule i= n YANG 1..1
> >
> > that there cannot be 2 sibling nodes defined in the same module n= amespace..
> >
> >
> >
> > IMO since any yang-data nodes are ALLOWED to be used at the top-l= evel,
> >
> > then these top-level nodes cannot have conflicting names.
> >
> >
> >
> > It is very important when parsing an instance document that the i= nstance
> > data
> >
> > can be associated with the correct schema.=C2=A0 This is not poss= ible if the
> >
> > same top-level node has multiple yang-data nodes defined.
> >
> >
> >
> > If one needs to define data that is not top-level, (1) use
> > augment-yang-data
> >
> > or (2) use a different module.
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> >
> > Hi,
> >
> > While preparing draft-ietf-netmod-yang-data-ext-02, it turne= d out that
> > it is not clear what, if any, restrictions should be enforced for=
> > yang-data structures.=C2=A0 Even among the authors we have differ= ent ideas
> > for how this should work.
> >
> > Background:
> >
> > In 8040, the original yang-data extension had a restriction that = said
> > that a yang-data structure MUST have exactly one container, since= it
> > wouldn't be possible to have a yang-data structure in an XML = instance
> > document otherwise.
> >
> > Since people want to use yang-data structures in other places, th= is
> > restriction was lifted in the new draft:
> >
> >=C2=A0 =C2=A0 There is no longer an assumption that a yang data st= ructure can
> >=C2=A0 =C2=A0 only be used as a top-level abstraction, instead of = nested within
> >=C2=A0 =C2=A0 some other data structure.
> >
> >
> > With this in mind, here's a use case that I think we ought to= support:
> >
> >=C2=A0 =C2=A0rpc my-first-rpc {
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Bla bla...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 If an error occurs, <error-info>= will contain an instance of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the yang-data structure 'my-first-= rpc-error-info'.";
> >=C2=A0 =C2=A0 =C2=A0...
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0yang-data my-first-rpc-error-info {
> >=C2=A0 =C2=A0 =C2=A0leaf reason { ... }
> >=C2=A0 =C2=A0 =C2=A0container user-info { ... }
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0rpc my-second-rpc {
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Bla bla...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 If an error occurs, <error-info>= will contain an instance of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the yang-data structure 'my-second= -rpc-error-info'.";
> >=C2=A0 =C2=A0 =C2=A0...
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0yang-data my-second-rpc-error-info {
> >=C2=A0 =C2=A0 =C2=A0leaf reason { ... }
> >=C2=A0 =C2=A0 =C2=A0leaf important-url { ... }
> >=C2=A0 =C2=A0}
> >
> > (maybe in the future we could even have a YANG extension statemen= t to
> > formalize the description:
> >
> >=C2=A0 =C2=A0 rpc my-first-rpc {
> >=C2=A0 =C2=A0 =C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 opx:error-info-structure my-first-rpc-error-i= nfo;
> >=C2=A0 =C2=A0 }
> >
> > but this is not point now.)
> >
> >
> >
> >
> >
> >
> >
> > I see no reason to reinvent the grouping-stmt.
> >
> > You could easily say opx:error-info-structure argument is a group= ing name
> >
> > as it is a yang-data name.
> >
> >
> >
> >
> >
> >
> > In the example above, note that the leaf "reason" is pr= esent in both
> > structures.=C2=A0 IMO this is not a problem, since these structur= es are
> > used in different contexts.
> >
> > My point is that I think we should impose as few restrictions as<= br> > > possible to the yang-data extension.=C2=A0 It should be up to the= user of
> > yang-data to ensure that the structure is defined in such a way s= o
> > that it can be used properly.=C2=A0 For example, a structure that= is
> > supposed to describe an XML instance document cannot define two l= eafs
> > at the top level.
> >
> > If the WG agrees with what I wrote above, we need to change the > > augment-yang-data extension so that you would write for example:<= br> > >
> >=C2=A0 =C2=A0yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
> >=C2=A0 =C2=A0 =C2=A0...
> >=C2=A0 =C2=A0}
> >
> > Comments?
> >
> >
> >
> > /martin
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/net= mod
> > <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A= __www.ietf.org_mailman_listinfo_netmod&d=3DDwMFaQ&c=3DHAk= Yuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EP= oOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3Dq6I_yKbXVoahv9h5I1wZiQMUeHLZ5= XWuMohEYtypmzs&s=3DjECZMhypw9LtuxzuntkFNM-8lm7xpztYwDDLO= xCM_8k&e=3D>
> >
> >
> >
> >
> >
> > _______________________________________________
> >
> > netmod mailing list
> >
> > netmod@ietf.org
> >
> > https://www.ietf.org/mailman/listinfo/net= mod <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A= __www.ietf.org_mailman_listinfo_netmod&d=3DDwMFaQ&c=3DHAk= Yuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EP= oOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3Dq6I_yKbXVoahv9h5I1wZiQMUeHLZ5= XWuMohEYtypmzs&s=3DjECZMhypw9LtuxzuntkFNM-8lm7xpztYwDDLO= xCM_8k&e=3D>
> >
> >
> >
> >
> >
> >
> >
> >
> >

--089e082b3ee8a3ab87056a231cb1-- From nobody Wed Apr 18 12:02:20 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAB0126C26 for ; Wed, 18 Apr 2018 12:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCkX9DQoG-zK for ; Wed, 18 Apr 2018 12:02:17 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B111252BA for ; Wed, 18 Apr 2018 12:02:17 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3IJ09VA031342; Wed, 18 Apr 2018 12:02:17 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=EXFcMdFr1Q1auKFVwIloVoX/dP1AqgDZ0Pkv/jeMX+s=; b=GiIXsCBYN9TJvhPVSpjA65TBcq8p3ib92iIEbZBjvk/YVmU+jXBluyNVTmQSQ0XL4YWN vDEhqrxlVaMWtGrigJJozIpt4dFCBlz7qrhtckDAJW13bfnl/l/8UMRLgCN79hrmNSFq YDIbxfTkMfDlIMqubmFG6G3c1+Qtdg+XoxLp1e2aG7NwEO+fbGsT523sQ+NggiA+3qCV dz9Y1Q72aBZcoOVo22HWvEFZ+MarPOsFtUGtUGiR0+pQXceFe5CexbIozzTIwW4pOM3D 9jIQaE3ZyAIslW86SBvOFhWAmfZgqvCKk7kORrn488uGhD29hJ0RzycTKIaUivvfwqIj iw== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0180.outbound.protection.outlook.com [216.32.181.180]) by mx0a-00273201.pphosted.com with ESMTP id 2heau9g483-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Apr 2018 12:02:16 -0700 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB2810.namprd05.prod.outlook.com (10.168.175.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.8; Wed, 18 Apr 2018 19:02:15 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965%4]) with mapi id 15.20.0696.011; Wed, 18 Apr 2018 19:02:15 +0000 From: Kent Watsen To: Andy Bierman , Martin Bjorklund CC: NetMod WG Thread-Topic: [netmod] yang-data-ext issues Thread-Index: AQHT1YJYRSnZmZlnhU6JIK4LoPfNTqQDdYgAgAAS9YCAAAZpAIAACwoAgAAFOICAAuemAIAAR8IAgAABIACAAAEwgP//0JSA Date: Wed, 18 Apr 2018 19:02:15 +0000 Message-ID: References: <20180418.194744.1882806546121321450.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB2810; 7:6e8ZLVUhbh8ac4i9Ac8laJbcXN4xZZYPuPFzWO8yhgjmcjPUjMe2lYGI3D4Ef1+ADjPvclE6WWElZZFZn8SMKxq/6FKQihPfaQDm0rPxc329KvEaA5ALi50/hOmEOeIbHrJCWnZcaxtshsTBVt/Ahvg2tcA/uLdyted/0jienWNJgAtW/6OdXOgXXS1X+kSAyptE8LyZrjj2f7Z0J6traZT2zRJZWL0fBEoVwR5CH/Gs88zbAyjDfJ84hGpTaJ/B x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7153060)(7193020); SRVR:DM5PR05MB2810; x-ms-traffictypediagnostic: DM5PR05MB2810: authentication-results: outbound.protection.outlook.com; spf=skipped (originating message); dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=juniper.net; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231232)(944501368)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB2810; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2810; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39380400002)(39860400002)(376002)(36756003)(82746002)(6246003)(3660700001)(6512007)(53936002)(6306002)(6486002)(54896002)(229853002)(8676002)(99286004)(5660300001)(478600001)(102836004)(93886005)(4326008)(33656002)(66066001)(6436002)(110136005)(6506007)(14454004)(476003)(446003)(3280700002)(6116002)(26005)(11346002)(3846002)(86362001)(7736002)(8936002)(5250100002)(83716003)(81166006)(2906002)(316002)(186003)(76176011)(25786009)(2616005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2810; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: aQ9nsNWVkccCDCinGiQffnBfTtkl0dZSUraXxgYmikskwn78SbAHdYnnjrcGY4smQSKEpbwQ/7mNnZOKt1NPLBqXKe9Mu0+WjxFeydYu4MpzDRfqqNuyAJ1BJ1MUMkF3ZzfMxJKmzjSVpXlrdblNJk9g6dJp6X+y38uE6Bv8lJviUkFr+lV2Y/JNeYMBRXQc spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B8FCE29D02B549FCB2FC5DE327BCFBE8junipernet_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: e5d982e5-8257-4cfd-09cc-08d5a55ee693 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: e5d982e5-8257-4cfd-09cc-08d5a55ee693 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2018 19:02:15.6229 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2810 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=912 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804180171 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 19:02:19 -0000 --_000_B8FCE29D02B549FCB2FC5DE327BCFBE8junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpBbm90aGVyIGFuZCBzb21ld2hhdCByYWRpY2FsIGlkZWEgaXMgdG8gdGhpbmsgb2YgJ3lhbmct ZGF0YScgYXMgZGVmaW5pbmcgYSBkYXRhIG5vZGUsIGxpa2UgYSAnY29udGFpbmVyJywgYnV0IG5v dCBhIGNvbmZpZyBvciBvcHN0YXRlIG5vZGUuICBZZXMsIHRoaXMgaXMgZGlmZmVyZW50IGZyb20g cmM6eWFuZy1kYXRhLCB3aGljaCBkZWZpbmVzIGEgdHJhbnNwYXJlbnQgbm9kZSwgbGlrZSAnY2hv aWNlJywgYnV0IG1heWJlIGl0J3Mgb2theSBpZiB3ZSBjYW4gZ2V0IHRoZSBzdWJzdGl0dXRpb24g Z3JvdXBzIHBhcnQgd29ya2luZy4gIEZvciBpbnN0YW5jZToNCg0KRnJvbSBkcmFmdC1pZXRmLWFu aW1hLXZvdWNoZXI6DQogICAgT0xEOg0KICAgICAgIHJjOnlhbmctZGF0YSB2b3VjaGVyLWFydGlm YWN0IHsNCiAgICAgICAgICBjb250YWluZXIgdm91Y2hlciB74oCmfQ0KICAgICAgICB9DQogICAg TkVXOg0KICAgICAgIHlkOnlhbmctZGF0YSB2b3VjaGVyIHsNCiAgICAgICAgICDigKYNCiAgICAg ICAgfQ0KDQpGcm9tIGRyYWZ0LWlldGYtbmV0Y29uZi16ZXJvdG91Y2g6DQogICAgT0xEDQogICAg ICAgICByYzp5YW5nLWRhdGEgInplcm90b3VjaC1pbmZvcm1hdGlvbiIgew0KICAgICAgICAgICBj aG9pY2UgaW5mb3JtYXRpb24tdHlwZSB7DQogICAgICAgICAgICAgY29udGFpbmVyIHJlZGlyZWN0 LWluZm9ybWF0aW9uIHvigKZ9DQogICAgICAgICAgICAgY29udGFpbmVyIG9uYm9hcmRpbmctaW5m b3JtYXRpb24ge+KApn0NCiAgICAgICAgICAgfQ0KICAgICAgICAgfQ0KICAgIE5FVw0KICAgICAg ICAgeWQ6eWFuZy1kYXRhICJyZWRpcmVjdC1pbmZvcm1hdGlvbiIgew0KICAgICAgICAgICAgIHlk OnN1YnN0aXR1dGlvbi1ncm91cCB6ZXJvdG91Y2gtaW5mb3JtYXRpb247DQogICAgICAgICAgICAg 4oCmDQogICAgICAgICB9DQogICAgICAgICB5ZDp5YW5nLWRhdGEgIm9uYm9hcmRpbmctaW5mb3Jt YXRpb24iIHsNCiAgICAgICAgICAgICB5ZDpzdWJzdGl0dXRpb24tZ3JvdXAgemVyb3RvdWNoLWlu Zm9ybWF0aW9uOw0KICAgICAgICAgICAgIOKApg0KICAgICAgICAgfQ0KDQpBbmQgZm9yIHRoZSBl cnJvci1pbmZvIHVzZS1jYXNlOg0KDQogICAgeWQ6eWFuZy1kYXRhICJlcnJvci1pbmZvIiB7DQog ICAgICAgIGNob2ljZSBlcnJvci10eXBlIHsNCiAgICAgICAgICAgIGxlYWYgbXktZXJyb3IxIHvi gKZ9DQogICAgICAgICAgICBsZWFmIG15LWVycm9yMiB74oCmfQ0KICAgICAgICB9DQogICB9DQoN Cg0KVGhvdWdodHM/DQoNCktlbnQNCg0KDQo= --_000_B8FCE29D02B549FCB2FC5DE327BCFBE8junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <323EC0021DA3B94C8D1E58F54EDD5E94@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpIj5Bbm90aGVyIGFuZCBzb21ld2hhdCByYWRpY2FsIGlkZWEgaXMg dG8gdGhpbmsgb2YgJ3lhbmctZGF0YScgYXMgZGVmaW5pbmcgYSBkYXRhIG5vZGUsIGxpa2UgYSAn Y29udGFpbmVyJywgYnV0IG5vdCBhIGNvbmZpZyBvciBvcHN0YXRlIG5vZGUuJm5ic3A7IFllcywg dGhpcyBpcyBkaWZmZXJlbnQgZnJvbSByYzp5YW5nLWRhdGEsIHdoaWNoIGRlZmluZXMgYSB0cmFu c3BhcmVudA0KIG5vZGUsIGxpa2UgJ2Nob2ljZScsIGJ1dCBtYXliZSBpdCdzIG9rYXkgaWYgd2Ug Y2FuIGdldCB0aGUgc3Vic3RpdHV0aW9uIGdyb3VwcyBwYXJ0IHdvcmtpbmcuJm5ic3A7IEZvciBp bnN0YW5jZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki PkZyb20gZHJhZnQtaWV0Zi1hbmltYS12b3VjaGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJz cDsmbmJzcDsmbmJzcDsgT0xEOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyYzp5YW5nLWRhdGEgdm91Y2hlci1hcnRpZmFjdCB7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtjb250YWluZXIgdm91Y2hlciB74oCmfTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpIj4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsgTkVXOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt5ZDp5YW5nLWRh dGEgdm91Y2hlciB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO+KApjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpIj4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+RnJvbSBkcmFmdC1pZXRm LW5ldGNvbmYtemVyb3RvdWNoOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJz cDsgT0xEPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtyYzp5YW5nLWRhdGEgJnF1b3Q7emVyb3RvdWNoLWluZm9ybWF0 aW9uJnF1b3Q7IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Nob2ljZSBpbmZvcm1hdGlvbi10 eXBlIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NvbnRhaW5lciByZWRp cmVjdC1pbmZvcm1hdGlvbiB74oCmfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Y29udGFpbmVyIG9uYm9hcmRpbmctaW5mb3JtYXRpb24ge+KApn08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IE5FVzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7eWQ6eWFuZy1kYXRhICZxdW90O3JlZGlyZWN0LWlu Zm9ybWF0aW9uJnF1b3Q7IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO3lk OnN1YnN0aXR1dGlvbi1ncm91cCB6ZXJvdG91Y2gtaW5mb3JtYXRpb247PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3lk OnlhbmctZGF0YSAmcXVvdDtvbmJvYXJkaW5nLWluZm9ybWF0aW9uJnF1b3Q7IHs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO3lkOnN1YnN0aXR1dGlvbi1ncm91cCB6ZXJvdG91 Y2gtaW5mb3JtYXRpb247PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigKY8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmkiPkFuZCBmb3IgdGhlIGVycm9yLWluZm8gdXNlLWNhc2U6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsgeWQ6eWFu Zy1kYXRhICZxdW90O2Vycm9yLWluZm8mcXVvdDsgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2hvaWNlIGVycm9yLXR5cGUg ezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bGVhZiBteS1lcnJvcjEge+KApn08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2xlYWYgbXktZXJyb3IyIHvigKZ9PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwO308bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpIj5UaG91Z2h0cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmkiPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8FCE29D02B549FCB2FC5DE327BCFBE8junipernet_-- From nobody Fri Apr 20 08:14:50 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932C612D7E8 for ; Fri, 20 Apr 2018 08:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViSCWX0jN1Ds for ; Fri, 20 Apr 2018 08:14:45 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB8C124F57 for ; Fri, 20 Apr 2018 08:14:45 -0700 (PDT) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id DBF7217672A for ; Fri, 20 Apr 2018 09:14:44 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id cfEh1x0022SSUrH01fEk8e; Fri, 20 Apr 2018 09:14:44 -0600 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=Kd1tUaAdevIA:10 a=48vgC7mUAAAA:8 a=Pre3Gn1L7ksxRNMeSkYA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7axvharKI8mhojZM3TYGPJWPFOe72bfk4wLkPcc96SY=; b=vwMeGO0EjLxomv4eSgz+oNwvIr GQMn7eP0udCE5cgT9lhlvips0m7xtE/aTE1oDyOVKY5s3TFg0+XU0cF9qBRNmevv1KTubQBOF5+Jo Be5dkpfBtbHeDd6BlrM+WBfqi; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:33418 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1f9XkG-000gTr-TY; Fri, 20 Apr 2018 09:14:40 -0600 To: NETMOD Working Group Cc: NetMod Chairs , Robert Wilton From: Lou Berger Openpgp: preference=signencrypt Autocrypt: addr=lberger@labn.net; prefer-encrypt=mutual; keydata= xsBNBERW5dYBCAC1Bjgr/mVovBhi1rbqkowJShVtvLitNEGOTd6RtmwO7FPebg61J9+kRFTz 1wt869yiAjtQO1EtQs26QFTH5ZDZJU/LDAOzxTi12mpBic+AWI8W0yrB1C+KOZ0gw2p7Vnfj EKc3ohwkCICHTnZ3blO8Mslb4qHGxDm7Uy3luRjvH1ZDifuZvfFHcHVw2dJyGwLg2MhXCqpo OyUqFN0tlGqz1TOCAy3/IMG6OdNK27DGF5+vJyIqek/2xkIVDOLgzVCek3dARLqPP37W1Lx2 uXJUsgcJ7t7om5AEV2LTFrafvAvJbKLT9RZ0fgF4LXeRTIVlFXKkvYJFgygW+r4JCTvHABEB AAHNHUxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+wsDHBBABAgBxBQJEVuXyMBSAAAAA ACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQcLCQgHAwIKAhkB GRhsZGFwOi8va2V5c2VydmVyLnBncC5jb20FGwMAAAADFgIBBR4BAAAABBUICQoACgkQgbLN W8HBX9eB9QgAl8/lFnNh43at51P//sRX8cDg33C/biok8st8Fff0Y/6p+6HkYKQcxiuZuOLr HHtBFxTdMGfFrlJIFob/N6m92CwVwoTRZu8QIe68DLewd+72PIEzvlSy/iTq3e91XqfGWCE7 oqw7H/weJJlB7yzPWXra/BwgPD+WkTxUiKeG2F2HzBTQfBQ6VpHiMqW6AL0jcCh/Drya93ZA aAdWfW2ywVPqIKETZIk04SBsZCw9WESB2If/NqeZu/DNwBg4FsXCrfp3WfMSTkYmfT3zcU11 MpKcv20YUpG8Jf9lyMY1DgMHHdpUHdjo/fuLz4aVSQvt8EygRSzCxGWOWb89bUosAc7ATQRE VuXXAQgApBEy7m0+xMm4SEcQtFi/UQQqjVOllc2227M1ypbcEMRa46Tq6p0P5QBM9C9pxjAl tyI2m3hzvBxBJNnjknXTp875DGyj/yDwj9VeA18Tj9q6PRsJIxAnGKBgWO0yGdZLpsp0AN5n kMamxdVFGYojzUiwkPBayST6sEUp33o4xHsx99TA2bFxZRj6k0igWgdrPVq4qeEgD1l7Cl3f pj96owzm+7wecswAts2b545gfR4/V/Vx3VUebETR/LwMDecXokP5fiDAIRHhEUi/+FXcwg6w 6jtPilFcJ64HJP6P81OUdfeMDUxvSmbeRqXaZrbRN+hF6XfWODTKepsqPaX8TQARAQABwsBi BBgBAgAMBQJEVuXXBRsMAAAAAAoJEIGyzVvBwV/XUcMH/2eB6dvsP52su9KgaDHqsgPbxF21 AQL9oDCheN+AJKD3Eouj/d/MbQdsp/M/pjgTAqB3G4/rtoyJw+BDjnvZwdUe4HQ656IPZOub e10sOgq1taJQZtQIl+mWKURMGlIihScYeuGfi/1RzMqXeCcFW63n5POVG55FzU8B7DBwQ2oJ Zy7NL0YVbT0ROXGson6WHLhzGnVP8CjHq5TN5co/FH/2BntaQIdSaOmTqN+vy38KkRsYa3cx k9eTbP99ypebZclmw6kxlOZGl9DBp4qNkTn/7LgQ7iZNVyESs9rSE7hQXnmfM+C+TCpeZo62 8AwC5SYEqa5YlkpgsP0NIEMAIoU= Message-ID: Date: Fri, 20 Apr 2018 11:14:39 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1f9XkG-000gTr-TY X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:33418 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [netmod] YANG Model Versioning Design Team X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 15:14:49 -0000 Hi, As discussed at the NETMOD WG session in IETF 101, London, we would like to set up a design team for YANG versioning. The proposed charter for the design team is as follows: The YANG Model Versioning Design Team is chartered to propose a revised approach to supporting YANG module updates. The existing approach is described in [1], and related issues have been discussed at IETF 100 [2], IETF 101 [3] and in [4]. The Design Team will document the current problem, related requirements and objections, and lead the WG related discussion to ensure consensus. The result of this effort is expected to be an individual draft which may be adopted by the WG per normal process. The goal of the design team is to have this draft published prior to IETF 102. The Design Team is also expected to explore the possible solution space and propose a single solution to the WG in the form of an individual document. The goal of the design team is to have an initial version of this draft available prior to IETF 103, and to help with the effort of achieving WG adoption of the draft. The Design Team is expected to close once there is WG draft providing a revised solution to supporting YANG module updates. We have asked Rob Wilton to lead the DT and would like to ask that those who are interested in joining the design team please contact the chairs and Rob Wilton. Note if you have already sent mail to the chairs regarding volunteering, there is no need to send an additional e-mail. If you volunteer and are not asked to join, please know that you will have ample opportunity to provide input as any documents produced by the DT will follow normal WG process, starting with a normal WG adoption call. Thank you, NETMOD WG Chairs [1] https://tools.ietf.org/html/rfc7950#section-11 [2] https://datatracker.ietf.org/meeting/100/session/netmod [3] https://datatracker.ietf.org/meeting/101/session/netmod [4] https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update From nobody Fri Apr 20 18:16:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC5F127909 for ; Fri, 20 Apr 2018 18:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKfo3TlilZdL for ; Fri, 20 Apr 2018 18:16:14 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6A9126DED for ; Fri, 20 Apr 2018 18:16:14 -0700 (PDT) Received: from nitebug.localdomain (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 7B7BE2427D9; Sat, 21 Apr 2018 03:16:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1524273371; bh=a5TpPj9BmSCr64avo7qZ8A5p+UwlxdOT75qkd8lqXS8=; h=Subject:To:References:From:Date:In-Reply-To; b=mOGrGcDfzkdpPKXW1tkZOyu6vZ0ulr468YWOXsQ6wQSnF/+OxnwTzu7VkHuYKXHSe C5yL34Ldi0zhPK3xwG0xR2AB9xyASSQwgzbiCWnkvvbHHeZAcv2FX9Zydyw/4lBlCZ cPFUUkAtb06NVAzosGcpgV77Q7VJ3L/M9w+nQXVY= To: Martin Bjorklund , netmod@ietf.org References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> From: Robert Varga Message-ID: Date: Sat, 21 Apr 2018 03:16:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <87h8oal7iu.fsf@nic.cz> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gt8gVFaMZhw7k0Dv07gkTlSELOcuuMAO7" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 01:16:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gt8gVFaMZhw7k0Dv07gkTlSELOcuuMAO7 Content-Type: multipart/mixed; boundary="pT9s8d2qAWcHyEXr2rr2NUBwe1VDTob38"; protected-headers="v1" From: Robert Varga To: Martin Bjorklund , netmod@ietf.org Message-ID: Subject: Re: [netmod] yang-data-ext issues References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> In-Reply-To: <87h8oal7iu.fsf@nic.cz> --pT9s8d2qAWcHyEXr2rr2NUBwe1VDTob38 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 17/04/18 07:35, Ladislav Lhotka wrote: > Hi, >=20 > this is a slippery slope. If we want to turn YANG into a general-purpos= e > schema language, it should IMO be done the other way around: design a > general-purpose schema language with a sound architecture, and then use= > it for defining schemas of datastores, protocol messages or whatever. >=20 > YANG extensions make changes to the original YANG architecture way too > easy, but the result may be a bastard with no architecture at all. +1 in general, although I am not convinced we need to start from scratch.= The problem is that the metamodel behind YANG is not formally defined, which means every implementer has to reverse-engineer it from RFC6020/7960 (and 6241, and others). Since there is no metamodel spec, it is very hard to reason about how an extension affects it, especially in edge cases -- which can (and most probably will) lead to bastardizatio= n. One example: YANG 1.1 was supposed to be a backwards-compatible, yet it introduced multiple-inheritence to a language which was previously strictly single-inheritence. That sort of change is a major revision of the metamodel and certainly does not qualify as backwards-compatible at that level of abstraction. It may not be important for run-of-the-mill NETCONF operations, but becomes pivotal when you are mapping YANG to other languages. Regards, Robert --pT9s8d2qAWcHyEXr2rr2NUBwe1VDTob38-- --gt8gVFaMZhw7k0Dv07gkTlSELOcuuMAO7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlrakNULHG5pdGVAaHEu c2sACgkQJKB0S2uuNdsoig/+OCyqVzr2cyF5aTZoJGkgnr2tZOClgzgkrZAB/J5O l6sGT70TvUvmEtQhrxBfVT1VzesLpAckmJrVIyZTZZBBy4ji9eEBzohJdY6i9T/L A7boHzKBCZ/ErtRlyzfoTkucjiDKBLIOVDxFLbi5hgmVNgSRwAN17esfCKwGA3b4 lKBZOybusz9QAOrYSE7LlcsM99QgIMD2ugESifFGrJq3s6QTeESv/whD9BzbAJTO zjNYUxWXjOl/KbIlVbmVOaJqNwTS2qsPVtqGrlkJZqIc+wcvb0NzvFDBcBu+wg8z s99K/zTAfUrl7WbinpY3iXCkXQx6DXJZsUuDeaS05wSmU3M5qQIN4XhIcoujiDzo aGEarZZWlAtuJI6MUbLOS0xgoEYn4jGCE94qwumABxcMgX/56FMxhkhD/BpRPWzc izObC/FGiuCqFZHcvGgxUyFpf1Nidy0Oypd44JidLz3+SC/wsj+xppX7ui1Khy7s GrKE9kIes/IByB919RfWZrax3qBz/zfqDDy0i8+ts5k2YZBW93Q3E4VJi2+WRnov PXZ73SCUpJ9I8BjPRS0ffKOjY+l6memlajL8fEDLHM61e2/MZGbFKse+z8FbHui8 0BJf6dYOqHKZ8QZ5zVyBm86kJhXY6IvJj8BgHMCFhAGBQ/sLiICtr07J70/Gk1vv 7Co= =rF9E -----END PGP SIGNATURE----- --gt8gVFaMZhw7k0Dv07gkTlSELOcuuMAO7-- From nobody Sun Apr 22 05:56:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3506F1204DA for ; Sun, 22 Apr 2018 05:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwThS0ELt4GB for ; Sun, 22 Apr 2018 05:56:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1B11200C5 for ; Sun, 22 Apr 2018 05:56:51 -0700 (PDT) Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 43EF762BEE for ; Sun, 22 Apr 2018 14:56:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1524401809; bh=md2rtvpD6W7/XeRmEGZHchEfLYPN6t/Sj+uY/8dRKKk=; h=From:To:Date; b=wgIPxf1hiqaeSBxTSm4qBXH4qrFfD1mDbfvB8BpC850ENSufmeJpvS/VTbPerJEV4 SXNth8jl+M6t1u0ckfclzDNojkMlfvUcGfuC3JtC3cvXSsABerXM5kfkvmIPIYMSy4 gKcLe7D+2x99hblaHinNu61Rb6gE2aC7mrtNHEYs= Message-ID: <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Sun, 22 Apr 2018 14:56:51 +0200 In-Reply-To: References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 12:56:55 -0000 On Sat, 2018-04-21 at 03:16 +0200, Robert Varga wrote: > On 17/04/18 07:35, Ladislav Lhotka wrote: > > Hi, > > > > this is a slippery slope. If we want to turn YANG into a general-purpose > > schema language, it should IMO be done the other way around: design a > > general-purpose schema language with a sound architecture, and then use > > it for defining schemas of datastores, protocol messages or whatever. > > > > YANG extensions make changes to the original YANG architecture way too > > easy, but the result may be a bastard with no architecture at all. > > +1 in general, although I am not convinced we need to start from scratch. I didn't mean to start from scratch, but the thing is that YANG spec contains many references to the specific NM context that don't make sense in other contexts, so these would need to be removed. To begin with, it is the config true/false dichotomy. > > The problem is that the metamodel behind YANG is not formally defined, > which means every implementer has to reverse-engineer it from > RFC6020/7960 (and 6241, and others). Since there is no metamodel spec, > it is very hard to reason about how an extension affects it, especially > in edge cases -- which can (and most probably will) lead to bastardization. In fact, for the major XML schema languages the metamodel stems from a specific formal validation algorithm. This article is quite instructive: http://pike.psu.edu/publications/toit05.pdf A useful side effect of the YANG-to-DSDL mapping was the evidence that YANG 1.0 was still pretty close to the mainstream of XML schema languages. > > One example: YANG 1.1 was supposed to be a backwards-compatible, yet it > introduced multiple-inheritence to a language which was previously > strictly single-inheritence. That sort of change is a major revision of > the metamodel and certainly does not qualify as backwards-compatible at > that level of abstraction. I'd defend YANG 1.1 here, I think it was a well managed and conservative update. The meaning of backward compatibility was defined in the charter: YANG 1.0 modules should continue to work in 1.1. Apart from fixing evident bugs, I believe this goal was achieved. I am much more concerned with some of the post-1.1 features, also because YANG is now being updated in several directions without a clear vision. And another big problem is that YANG extensions are used for these changes, so we will probably end up with several different versions of YANG, although formally everything will be 1.1. Regarding your example: from my own experience, implementing validation of identityref values with multiple inheritance is not terribly complicated in comparison to single inheritance. I have other favorites for the most peculiar feature in YANG. > > It may not be important for run-of-the-mill NETCONF operations, but > becomes pivotal when you are mapping YANG to other languages. You are right, if such a mapping is what you need. I have myself given up updating the DSDL mapping. Lada > > Regards, > Robert > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Sun Apr 22 23:52:29 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35887126D05 for ; Sun, 22 Apr 2018 23:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkMZ_OPvDMYb for ; Sun, 22 Apr 2018 23:52:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEA51243FE for ; Sun, 22 Apr 2018 23:52:24 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 3E1FD1AE018C; Mon, 23 Apr 2018 08:52:22 +0200 (CEST) Date: Mon, 23 Apr 2018 08:52:22 +0200 (CEST) Message-Id: <20180423.085222.753779000097456009.mbj@tail-f.com> To: andy@yumaworks.com Cc: kwatsen@juniper.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180418.194744.1882806546121321450.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 06:52:27 -0000 Andy Bierman wrote: > On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund wrote: > > > Hi, > > > > Andy Bierman wrote: > > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen > > wrote: > > > > > > > I like Andy's proposal below, for the argument of the 'yang-data' > > > > statement to encode some meta-information regarding the > > context/namespace > > > > in which it's used, but I wonder how it really works. For instance, > > would > > > > "top" and "error-info" be the only allowed base-path values for the > > > > argument? and what is the value of the remainder of the path? are we > > > > expecting for there to be some kind us 'uses' statement that can refer > > to > > > > just the base-path component to implement substitution-group like > > behavior? > > > > > > > > > > > > > > > > > > > > > If we want to avoid defining these contexts, then we could just define > > root > > > vs. nonroot. > > > > > > e,g: > > > > > > x:yang-data /mydef1 { > > > container foo; > > > } > > > > > > x:yang-data mydef2 { > > > leaf x; > > > leaf y; > > > container z; > > > } > > > > > > > > > Only an argument starting with '/' would be treated as a top-level data > > > node. > > > > > > All other yang-data definitions are not allowed to appear as a root node. > > > The context where this yang-data is used is completely proprietary. > > > The mechanism used to expand this yang-data as if it was a grouping > > > is completely proprietary. > > > > > > The augment-yang-data extension only applies to top-level yang-data > > > definitions. > > > > > > However, my preference is to only standardize top-level yang-data. > > > > What is "top-level" yang-data? > > > > > > > It is a data structure that represents an instance document. So then I assume that you also want to change the current draft -01 behavior so that a yang-data structure MUST have a single container as the child? Just like in rc:yang-data. > Since this is the ONLY definition of yang-data we have in the standard, > what is a yang-data definition that represents some unspecified usage, > other than an instance document? We want to create a flexible solution for creating structures that can be used in other places than just self-contained instance document. One example is the error-info data (see subscribed-notifications). > Why is this any different than a YANG grouping? ? We don't have these CLRs for groupings; the following is legal: grouping foo { leaf a { ... } leaf b { ... } } grouping bar { leaf b { ... } } It is up to the user of the grouping to ensure it is used in a way so that the result is legal. I think yang-data should work the same way. /martin > > > > > /martin > > > > > > > Andy > > > > > > I do not see any need for the other form since all functionality can be > > > achieved with a grouping and a proprietary YANG extension. > > > > > > Kent // contributor > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" < > > > > netmod-bounces@ietf.org on behalf of andy@yumaworks.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 16/04/2018 17:07, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton > > wrote: > > > > > > > > Don't groupings have a somewhat similar concern? > > > > > > > > E.g. if two groupings define the same data node name and are used at > > the > > > > same point then you would get a namespace clash, but YANG does not > > disallow > > > > the groupings: > > > > > > > > > > > > grouping foo_widget { > > > > > > > > leaf name { > > > > > > > > type string; > > > > > > > > description "Name of my foo widget"; > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > grouping bar_widget { > > > > > > > > leaf name { > > > > > > > > type string; > > > > > > > > description "Name of my bar widget"; > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > container all_widgets { > > > > > > > > uses foo_widget; > > > > > > > > uses bar_widget; > > > > > > > > } > > > > > > > > > > > > The principal difference here, is that the compiler can easily check > > and > > > > reject the conflict at the uses statements. > > > > > > > > Hence I think that it would be good if we could find a solution for > > > > yang-data-ext that doesn't not require all root yang-data nodes to be > > > > unique, since that feels somewhat clunky. I.e. my preference is to > > keep > > > > them less restrictive, as Martin has proposed, if this is feasible. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is not clunky that 2 top-level YANG data nodes in the same module > > > > > > > > have unique names. This is simple and deterministic. > > > > > > > > This restriction has not been a problem so far. > > > > > > > > I agree with the statements above. > > > > > > > > But it is not clear to me that yang-data-ext is really defining new top > > > > level data nodes that are part of the same tree/namespace as the > > > > configuration/state nodes. In Martin's examples they were used within > > > > RPCs, and it the forcing the names to be unique in that context that I > > > > think would be clunky. E.g. in Martin's example forcing different > > names > > > > for "reason" and "user-info" doesn't seem to be helpful. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The yang-data statement has to define the context or new abstract > > > > namespace, > > > > > > > > or whatever this hack is called. > > > > > > > > Perhaps. I think that this depends on how they are used. > > > > > > > > > > > > > > > > > > > > > > > > The yang-data statement has to specify the expansion point, or > > > > > > > > at least specify that it is or is not the top-level. > > > > > > > > > > > > > > > > yang-data top/name1 { > > > > > > > > container mydata; > > > > > > > > } > > > > > > > > > > > > > > > > where context is something like "top" or "error-info", etc. > > > > > > > > > > > > > > > > It is trivial to use groupings if the same set of nodes needs to be > > used > > > > in different contexts: > > > > > > > > > > > > > > > > > > > > yang-data error-info/name1 { > > > > > > > > container mydata; > > > > > > > > } > > > > > > > > > > > > > > > > Only the context named "top" is restricted to a resulting > > single-container > > > > > > > > and cannot have duplicate names. > > > > > > > > > > > > > > > > This is OK: > > > > > > > > > > > > > > > > x:yang-data error-info/my-error1 { > > > > > > > > leaf reason {} > > > > > > > > } > > > > > > > > > > > > > > > > > > > > x:yang-data error-info/my-error2 { > > > > > > > > leaf reason {} > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could a fix for this be something along the lines of: > > > > - yang-data names must be unique amongst other top level data nodes > > > > within the module. > > > > - if yang-data extensions are used at the top level then their name > > must > > > > be used as a single top level container. > > > > - if a yang-data extension is used within another structure then the > > > > yang-data name is excluded, and the top level nodes defined in the > > > > yang-data definition are used .... > > > > > > > > > > > > Every tool that implements yang-data has to be able > > > > > > > > to interpret a yang-data statement exactly the same way. > > > > > > > > > > > > > > > > If you want to reinvent XSD substitutionGroup, then do it right. > > > > > > > > I'm not familiar with them. From a quick read, I don't see how they > > are > > > > related to the problem that we are trying to solve here. > > > > > > > > > > > > > > > > > > > > > > > > A substitutionGroup allows a point int the schema to be identified by > > name. > > > > > > > > Different elements can be defined that match this name, which then can > > be > > > > > > > > used (like a YANG choice) at the specified schema point. > > > > > > > > (e.g. error-info above is like a substitutionGroup) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On 16/04/2018 15:36, Andy Bierman wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I am strongly opposed to this change because it breaks the rule in > > YANG 1..1 > > > > > > > > that there cannot be 2 sibling nodes defined in the same module > > namespace.. > > > > > > > > > > > > > > > > IMO since any yang-data nodes are ALLOWED to be used at the top-level, > > > > > > > > then these top-level nodes cannot have conflicting names. > > > > > > > > > > > > > > > > It is very important when parsing an instance document that the > > instance > > > > data > > > > > > > > can be associated with the correct schema. This is not possible if the > > > > > > > > same top-level node has multiple yang-data nodes defined. > > > > > > > > > > > > > > > > If one needs to define data that is not top-level, (1) use > > > > augment-yang-data > > > > > > > > or (2) use a different module. > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund > > wrote: > > > > > > > > Hi, > > > > > > > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that > > > > it is not clear what, if any, restrictions should be enforced for > > > > yang-data structures. Even among the authors we have different ideas > > > > for how this should work. > > > > > > > > Background: > > > > > > > > In 8040, the original yang-data extension had a restriction that said > > > > that a yang-data structure MUST have exactly one container, since it > > > > wouldn't be possible to have a yang-data structure in an XML instance > > > > document otherwise. > > > > > > > > Since people want to use yang-data structures in other places, this > > > > restriction was lifted in the new draft: > > > > > > > > There is no longer an assumption that a yang data structure can > > > > only be used as a top-level abstraction, instead of nested within > > > > some other data structure. > > > > > > > > > > > > With this in mind, here's a use case that I think we ought to support: > > > > > > > > rpc my-first-rpc { > > > > description > > > > "Bla bla... > > > > If an error occurs, will contain an instance of > > > > the yang-data structure 'my-first-rpc-error-info'."; > > > > ... > > > > } > > > > > > > > yang-data my-first-rpc-error-info { > > > > leaf reason { ... } > > > > container user-info { ... } > > > > } > > > > > > > > rpc my-second-rpc { > > > > description > > > > "Bla bla... > > > > If an error occurs, will contain an instance of > > > > the yang-data structure 'my-second-rpc-error-info'."; > > > > ... > > > > } > > > > > > > > yang-data my-second-rpc-error-info { > > > > leaf reason { ... } > > > > leaf important-url { ... } > > > > } > > > > > > > > (maybe in the future we could even have a YANG extension statement to > > > > formalize the description: > > > > > > > > rpc my-first-rpc { > > > > ... > > > > opx:error-info-structure my-first-rpc-error-info; > > > > } > > > > > > > > but this is not point now.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I see no reason to reinvent the grouping-stmt. > > > > > > > > You could easily say opx:error-info-structure argument is a grouping > > name > > > > > > > > as it is a yang-data name. > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the example above, note that the leaf "reason" is present in both > > > > structures. IMO this is not a problem, since these structures are > > > > used in different contexts. > > > > > > > > My point is that I think we should impose as few restrictions as > > > > possible to the yang-data extension. It should be up to the user of > > > > yang-data to ensure that the structure is defined in such a way so > > > > that it can be used properly. For example, a structure that is > > > > supposed to describe an XML instance document cannot define two leafs > > > > at the top level. > > > > > > > > If the WG agrees with what I wrote above, we need to change the > > > > augment-yang-data extension so that you would write for example: > > > > > > > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > > > > ... > > > > } > > > > > > > > Comments? > > > > > > > > > > > > > > > > /martin > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c= > > HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r= > > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_ > > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM- > > 8lm7xpztYwDDLOxCM_8k&e=> > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > netmod mailing list > > > > > > > > netmod@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ > > listinfo_netmod&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r= > > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_ > > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM- > > 8lm7xpztYwDDLOxCM_8k&e=> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From nobody Mon Apr 23 04:10:51 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48628127873 for ; Mon, 23 Apr 2018 04:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfed5soj452I for ; Mon, 23 Apr 2018 04:10:45 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B9B12783A for ; Mon, 23 Apr 2018 04:10:44 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id o123-v6so11730292lfe.8 for ; Mon, 23 Apr 2018 04:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nnMQ+QmkHX83XR9Jdcmh4NAMURQAo6B4U2jzMt+Zr98=; b=iJ2D9ZnispALAZCs4hmqBr0AsZIaoYWtF6CM3qd0bsEZedOHEeK+wWiunPYJlEqYie LLAo0tlZRmB77QvyXJlMaksGBgoCNm7FlQzCfLg8tK5DRctnKlUkH6jCEJxNHD2PXa+w vUrp+BFk52WAN1KdN26xNYuwqyS8QOpW9Yq08bIfm3Zc+LOfU/ifB81y4uQqihV/oJAa 1he1fDekTwhNbah6rALQVp75JUlxAQGr0m8o7bftwzmjCBNK1XdFYDHE/Liz/mw2+8D7 DtCWmWWOHguQHWbH7GwDYrfHBOv1N6AHkEbYVH2D5Q29KlyDJVEQGS+GOsLviKCeoBOm 59hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nnMQ+QmkHX83XR9Jdcmh4NAMURQAo6B4U2jzMt+Zr98=; b=q7toUbPtygNLY/OhxzdgzoKp0DnWAdjvpOAb3JxJS03VtKSNJVXQyMF6mS74F0BRGb wevdSgmkNR1CKdZwFrN14n/qve0swG9QaCQ0enPzOgKDHifEy7QCljMZWVQdIBtqRvDt c4H9cj465VpwVj+UR0IcOkVz4v10wDnuUbAgDJaHhSxYqVsbVluhay4A86elXTOSDfZg KNrqb6aUSJzHpaLGR5wsQ32WhvBNVxx+PsQ6xzFYuNjNFk5RFuVxXEN9H0l7w3HRsNGd BL80RR+B98Jg8E+19sJfd+jcDr9xREJrqvVnsngh+scvBIGEe8IGSZ3V/cTDDTseg9RK xsbw== X-Gm-Message-State: ALQs6tBr5WxgR3xo/MRvzbwFlp+9JNOADRVxuTM9QStGSLEsEHcusDSa ke4bMgSd8e77NHsoNBpbfDA/uLyrI9qnE3vkggWxgQ== X-Google-Smtp-Source: AIpwx49MCVuM4yO3rf3HFdZ9XI7Z4mPvqAtIFoZ+MebZvzQq22eooi8jglSOKuSTL9JkesLiVj4R0nmWZi0vYrkfLkM= X-Received: by 10.46.9.148 with SMTP id 142mr13959358ljj.129.1524481842874; Mon, 23 Apr 2018 04:10:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 04:10:41 -0700 (PDT) In-Reply-To: <20180423.085222.753779000097456009.mbj@tail-f.com> References: <20180418.194744.1882806546121321450.mbj@tail-f.com> <20180423.085222.753779000097456009.mbj@tail-f.com> From: Andy Bierman Date: Mon, 23 Apr 2018 04:10:41 -0700 Message-ID: To: Martin Bjorklund Cc: Kent Watsen , NetMod WG Content-Type: multipart/alternative; boundary="001a114b1384b621b2056a8216df" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 11:10:49 -0000 --001a114b1384b621b2056a8216df Content-Type: text/plain; charset="UTF-8" On Sun, Apr 22, 2018 at 11:52 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund > wrote: > > > > > Hi, > > > > > > Andy Bierman wrote: > > > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen > > > wrote: > > > > > > > > > I like Andy's proposal below, for the argument of the 'yang-data' > > > > > statement to encode some meta-information regarding the > > > context/namespace > > > > > in which it's used, but I wonder how it really works. For > instance, > > > would > > > > > "top" and "error-info" be the only allowed base-path values for the > > > > > argument? and what is the value of the remainder of the path? are > we > > > > > expecting for there to be some kind us 'uses' statement that can > refer > > > to > > > > > just the base-path component to implement substitution-group like > > > behavior? > > > > > > > > > > > > > > > > > > > > > > > > > > > If we want to avoid defining these contexts, then we could just > define > > > root > > > > vs. nonroot. > > > > > > > > e,g: > > > > > > > > x:yang-data /mydef1 { > > > > container foo; > > > > } > > > > > > > > x:yang-data mydef2 { > > > > leaf x; > > > > leaf y; > > > > container z; > > > > } > > > > > > > > > > > > Only an argument starting with '/' would be treated as a top-level > data > > > > node. > > > > > > > > All other yang-data definitions are not allowed to appear as a root > node. > > > > The context where this yang-data is used is completely proprietary. > > > > The mechanism used to expand this yang-data as if it was a grouping > > > > is completely proprietary. > > > > > > > > The augment-yang-data extension only applies to top-level yang-data > > > > definitions. > > > > > > > > However, my preference is to only standardize top-level yang-data. > > > > > > What is "top-level" yang-data? > > > > > > > > > > > It is a data structure that represents an instance document. > > So then I assume that you also want to change the current draft -01 > behavior so that a yang-data structure MUST have a single container as > the child? Just like in rc:yang-data. > > A yang-data structure representing an instance document needs to result in a container. > > > Since this is the ONLY definition of yang-data we have in the standard, > > what is a yang-data definition that represents some unspecified usage, > > other than an instance document? > > We want to create a flexible solution for creating structures that can > be used in other places than just self-contained instance document. > One example is the error-info data (see subscribed-notifications). > > > Why is this any different than a YANG grouping? > > ? We don't have these CLRs for groupings; the following is legal: > > grouping foo { > leaf a { ... } > leaf b { ... } > } > > grouping bar { > leaf b { ... } > } > > > It is up to the user of the grouping to ensure it is used in a way so > that the result is legal. I think yang-data should work the same > way. > > > We don't need yang-data to be another way to define a grouping, because we already have grouping-stmt. We don't need to re-invent another collection of data-def-stmts that are not instantiated as data nodes automatically. Any place you could use yang-data for this purpose, you could use a grouping instead. > /martin > > > Andy > > > > > > > > > > /martin > > > > > > > > > > > Andy > > > > > > > > > > I do not see any need for the other form since all functionality can > be > > > > achieved with a grouping and a proprietary YANG extension. > > > > > > > > Kent // contributor > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" < > > > > > netmod-bounces@ietf.org on behalf of andy@yumaworks.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 16/04/2018 17:07, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton > > > wrote: > > > > > > > > > > Don't groupings have a somewhat similar concern? > > > > > > > > > > E.g. if two groupings define the same data node name and are used > at > > > the > > > > > same point then you would get a namespace clash, but YANG does not > > > disallow > > > > > the groupings: > > > > > > > > > > > > > > > grouping foo_widget { > > > > > > > > > > leaf name { > > > > > > > > > > type string; > > > > > > > > > > description "Name of my foo widget"; > > > > > > > > > > } > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > grouping bar_widget { > > > > > > > > > > leaf name { > > > > > > > > > > type string; > > > > > > > > > > description "Name of my bar widget"; > > > > > > > > > > } > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > container all_widgets { > > > > > > > > > > uses foo_widget; > > > > > > > > > > uses bar_widget; > > > > > > > > > > } > > > > > > > > > > > > > > > The principal difference here, is that the compiler can easily > check > > > and > > > > > reject the conflict at the uses statements. > > > > > > > > > > Hence I think that it would be good if we could find a solution for > > > > > yang-data-ext that doesn't not require all root yang-data nodes to > be > > > > > unique, since that feels somewhat clunky. I.e. my preference is to > > > keep > > > > > them less restrictive, as Martin has proposed, if this is feasible. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is not clunky that 2 top-level YANG data nodes in the same > module > > > > > > > > > > have unique names. This is simple and deterministic. > > > > > > > > > > This restriction has not been a problem so far. > > > > > > > > > > I agree with the statements above. > > > > > > > > > > But it is not clear to me that yang-data-ext is really defining > new top > > > > > level data nodes that are part of the same tree/namespace as the > > > > > configuration/state nodes. In Martin's examples they were used > within > > > > > RPCs, and it the forcing the names to be unique in that context > that I > > > > > think would be clunky. E.g. in Martin's example forcing different > > > names > > > > > for "reason" and "user-info" doesn't seem to be helpful. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The yang-data statement has to define the context or new abstract > > > > > namespace, > > > > > > > > > > or whatever this hack is called. > > > > > > > > > > Perhaps. I think that this depends on how they are used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The yang-data statement has to specify the expansion point, or > > > > > > > > > > at least specify that it is or is not the top-level. > > > > > > > > > > > > > > > > > > > > yang-data top/name1 { > > > > > > > > > > container mydata; > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > where context is something like "top" or "error-info", etc. > > > > > > > > > > > > > > > > > > > > It is trivial to use groupings if the same set of nodes needs to be > > > used > > > > > in different contexts: > > > > > > > > > > > > > > > > > > > > > > > > > yang-data error-info/name1 { > > > > > > > > > > container mydata; > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > Only the context named "top" is restricted to a resulting > > > single-container > > > > > > > > > > and cannot have duplicate names. > > > > > > > > > > > > > > > > > > > > This is OK: > > > > > > > > > > > > > > > > > > > > x:yang-data error-info/my-error1 { > > > > > > > > > > leaf reason {} > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > x:yang-data error-info/my-error2 { > > > > > > > > > > leaf reason {} > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could a fix for this be something along the lines of: > > > > > - yang-data names must be unique amongst other top level data > nodes > > > > > within the module. > > > > > - if yang-data extensions are used at the top level then their > name > > > must > > > > > be used as a single top level container. > > > > > - if a yang-data extension is used within another structure then > the > > > > > yang-data name is excluded, and the top level nodes defined in the > > > > > yang-data definition are used .... > > > > > > > > > > > > > > > Every tool that implements yang-data has to be able > > > > > > > > > > to interpret a yang-data statement exactly the same way. > > > > > > > > > > > > > > > > > > > > If you want to reinvent XSD substitutionGroup, then do it right. > > > > > > > > > > I'm not familiar with them. From a quick read, I don't see how > they > > > are > > > > > related to the problem that we are trying to solve here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A substitutionGroup allows a point int the schema to be identified > by > > > name. > > > > > > > > > > Different elements can be defined that match this name, which then > can > > > be > > > > > > > > > > used (like a YANG choice) at the specified schema point. > > > > > > > > > > (e.g. error-info above is like a substitutionGroup) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > Rob > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 16/04/2018 15:36, Andy Bierman wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I am strongly opposed to this change because it breaks the rule in > > > YANG 1..1 > > > > > > > > > > that there cannot be 2 sibling nodes defined in the same module > > > namespace.. > > > > > > > > > > > > > > > > > > > > IMO since any yang-data nodes are ALLOWED to be used at the > top-level, > > > > > > > > > > then these top-level nodes cannot have conflicting names. > > > > > > > > > > > > > > > > > > > > It is very important when parsing an instance document that the > > > instance > > > > > data > > > > > > > > > > can be associated with the correct schema. This is not possible > if the > > > > > > > > > > same top-level node has multiple yang-data nodes defined. > > > > > > > > > > > > > > > > > > > > If one needs to define data that is not top-level, (1) use > > > > > augment-yang-data > > > > > > > > > > or (2) use a different module. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out > that > > > > > it is not clear what, if any, restrictions should be enforced for > > > > > yang-data structures. Even among the authors we have different > ideas > > > > > for how this should work. > > > > > > > > > > Background: > > > > > > > > > > In 8040, the original yang-data extension had a restriction that > said > > > > > that a yang-data structure MUST have exactly one container, since > it > > > > > wouldn't be possible to have a yang-data structure in an XML > instance > > > > > document otherwise. > > > > > > > > > > Since people want to use yang-data structures in other places, this > > > > > restriction was lifted in the new draft: > > > > > > > > > > There is no longer an assumption that a yang data structure can > > > > > only be used as a top-level abstraction, instead of nested > within > > > > > some other data structure. > > > > > > > > > > > > > > > With this in mind, here's a use case that I think we ought to > support: > > > > > > > > > > rpc my-first-rpc { > > > > > description > > > > > "Bla bla... > > > > > If an error occurs, will contain an instance of > > > > > the yang-data structure 'my-first-rpc-error-info'."; > > > > > ... > > > > > } > > > > > > > > > > yang-data my-first-rpc-error-info { > > > > > leaf reason { ... } > > > > > container user-info { ... } > > > > > } > > > > > > > > > > rpc my-second-rpc { > > > > > description > > > > > "Bla bla... > > > > > If an error occurs, will contain an instance of > > > > > the yang-data structure 'my-second-rpc-error-info'."; > > > > > ... > > > > > } > > > > > > > > > > yang-data my-second-rpc-error-info { > > > > > leaf reason { ... } > > > > > leaf important-url { ... } > > > > > } > > > > > > > > > > (maybe in the future we could even have a YANG extension statement > to > > > > > formalize the description: > > > > > > > > > > rpc my-first-rpc { > > > > > ... > > > > > opx:error-info-structure my-first-rpc-error-info; > > > > > } > > > > > > > > > > but this is not point now.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I see no reason to reinvent the grouping-stmt. > > > > > > > > > > You could easily say opx:error-info-structure argument is a > grouping > > > name > > > > > > > > > > as it is a yang-data name. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the example above, note that the leaf "reason" is present in > both > > > > > structures. IMO this is not a problem, since these structures are > > > > > used in different contexts. > > > > > > > > > > My point is that I think we should impose as few restrictions as > > > > > possible to the yang-data extension. It should be up to the user > of > > > > > yang-data to ensure that the structure is defined in such a way so > > > > > that it can be used properly. For example, a structure that is > > > > > supposed to describe an XML instance document cannot define two > leafs > > > > > at the top level. > > > > > > > > > > If the WG agrees with what I wrote above, we need to change the > > > > > augment-yang-data extension so that you would write for example: > > > > > > > > > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > > > > > ... > > > > > } > > > > > > > > > > Comments? > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c= > > > HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r= > > > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_ > > > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM- > > > 8lm7xpztYwDDLOxCM_8k&e=> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > netmod mailing list > > > > > > > > > > netmod@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ > > > listinfo_netmod&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r= > > > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_ > > > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM- > > > 8lm7xpztYwDDLOxCM_8k&e=> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --001a114b1384b621b2056a8216df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Apr 22, 2018 at 11:52 PM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Hi,
> >
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen <kwatsen@juniper.net>
> > wrote:
> > >
> > > > I like Andy's proposal below, for the argument of t= he 'yang-data'
> > > > statement to encode some meta-information regarding the=
> > context/namespace
> > > > in which it's used, but I wonder how it really work= s.=C2=A0 For instance,
> > would
> > > > "top" and "error-info" be the only = allowed base-path values for the
> > > > argument? and what is the value of the remainder of the= path?=C2=A0 are we
> > > > expecting for there to be some kind us 'uses' s= tatement that can refer
> > to
> > > > just the base-path component to implement substitution-= group like
> > behavior?
> > > >
> > > >
> > > >
> > >
> > >
> > > If we want to avoid defining these contexts, then we could j= ust define
> > root
> > > vs. nonroot.
> > >
> > > e,g:
> > >
> > > x:yang-data /mydef1 {
> > >=C2=A0 =C2=A0container foo;
> > > }
> > >
> > > x:yang-data mydef2 {
> > >=C2=A0 =C2=A0leaf x;
> > >=C2=A0 =C2=A0leaf y;
> > >=C2=A0 =C2=A0container z;
> > > }
> > >
> > >
> > > Only an argument starting with '/' would be treated = as a top-level data
> > > node.
> > >
> > > All other yang-data definitions are not allowed to appear as= a root node.
> > > The context where this yang-data is used is completely propr= ietary.
> > > The mechanism used to expand this yang-data as if it was a g= rouping
> > > is completely proprietary.
> > >
> > > The augment-yang-data extension only applies to top-level ya= ng-data
> > > definitions.
> > >
> > > However, my preference is to only standardize top-level yang= -data.
> >
> > What is "top-level" yang-data?
> >
> >
> >
> It is a data structure that represents an instance document.

So then I assume that you also want to change the current draft -01
behavior so that a yang-data structure MUST have a single container as
the child?=C2=A0 Just like in rc:yang-data.



A yang-data structure r= epresenting an instance document needs to result in
a container.<= /div>


=C2=A0

> Since this is the ONLY definition of yang-data we have in the standard= ,
> what is a yang-data definition that represents some unspecified usage,=
> other than an instance document?

We want to create a flexible solution for creating structures that can
be used in other places than just self-contained instance document.
One example is the error-info data (see subscribed-notifications).

> Why is this any different than a YANG grouping?

?=C2=A0 We don't have these CLRs for groupings; the following is legal:=

=C2=A0 grouping foo {
=C2=A0 =C2=A0 leaf a { ... }
=C2=A0 =C2=A0 leaf b { ... }
=C2=A0 }

=C2=A0 grouping bar {
=C2=A0 =C2=A0 leaf b { ... }
=C2=A0 }


It is up to the user of the grouping to ensure it is used in a way so
that the result is legal.=C2=A0 I think yang-data should work the same
way.




We don't need yang-= data to be another way to define a grouping, because
we already h= ave grouping-stmt.

We don't need to re-invent = another collection of data-def-stmts that are not
instantiated as= data nodes automatically. Any place you could use yang-data
for = this purpose, you could use a grouping instead.

= =C2=A0
/martin




Andy

=C2=A0

>
>
>
> > /martin
> >
> >
> >
> Andy
>
>
>
> > > I do not see any need for the other form since all functiona= lity can be
> > > achieved with a grouping and a proprietary YANG extension. > > >
> > > Kent // contributor
> > > >
> > >
> > > Andy
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bie= rman" <
> > > > netmod-bounc= es@ietf.org on behalf of andy@yum= aworks.com> wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton <rwilton@cisco.com>
> > wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 16/04/2018 17:07, Andy Bierman wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton <rwilton@cisco.com>
> > wrote:
> > > >
> > > > Don't groupings have a somewhat similar concern? > > > >
> > > >=C2=A0 E.g. if two groupings define the same data node n= ame and are used at
> > the
> > > > same point then you would get a namespace clash, but YA= NG does not
> > disallow
> > > > the groupings:
> > > >
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 grouping foo_widget {
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name {
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "Nam= e of my foo widget";
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 }
> > > >
> > > >
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 grouping bar_widget {
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name {
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "Nam= e of my bar widget";
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 }
> > > >
> > > >
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 container all_widgets {
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses foo_widget;
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses bar_widget;
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 }
> > > >
> > > >
> > > > The principal difference here, is that the compiler can= easily check
> > and
> > > > reject the conflict at the uses statements.
> > > >
> > > > Hence I think that it would be good if we could find a = solution for
> > > > yang-data-ext that doesn't not require all root yan= g-data nodes to be
> > > > unique, since that feels somewhat clunky.=C2=A0 I.e. my= preference is to
> > keep
> > > > them less restrictive, as Martin has proposed, if this = is feasible.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > It is not clunky that 2 top-level YANG data nodes in th= e same module
> > > >
> > > > have unique names. This is simple and deterministic. > > > >
> > > > This restriction has not been a problem so far.
> > > >
> > > > I agree with the statements above.
> > > >
> > > > But it is not clear to me that yang-data-ext is really = defining new top
> > > > level data nodes that are part of the same tree/namespa= ce as the
> > > > configuration/state nodes.=C2=A0 In Martin's exampl= es they were used within
> > > > RPCs, and it the forcing the names to be unique in that= context that I
> > > > think would be clunky.=C2=A0 E.g. in Martin's examp= le forcing different
> > names
> > > > for "reason" and "user-info" doesn&= #39;t seem to be helpful.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > The yang-data statement has to define the context or ne= w abstract
> > > > namespace,
> > > >
> > > > or whatever this hack is called.
> > > >
> > > > Perhaps.=C2=A0 I think that this depends on how they ar= e used.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > The yang-data statement has to specify the expansion po= int, or
> > > >
> > > > at least specify that it is or is not the top-level. > > > >
> > > >
> > > >
> > > >=C2=A0 =C2=A0yang-data top/name1 {
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0container mydata;
> > > >
> > > >=C2=A0 =C2=A0}
> > > >
> > > >
> > > >
> > > > where context is something like "top" or &quo= t;error-info", etc.
> > > >
> > > >
> > > >
> > > > It is trivial to use groupings if the same set of nodes= needs to be
> > used
> > > > in different contexts:
> > > >
> > > >
> > > >
> > > >
> > > >=C2=A0 =C2=A0yang-data error-info/name1 {
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0container mydata;
> > > >
> > > >=C2=A0 =C2=A0}
> > > >
> > > >
> > > >
> > > > Only the context named "top" is restricted to= a resulting
> > single-container
> > > >
> > > > and cannot have duplicate names.
> > > >
> > > >
> > > >
> > > > This is OK:
> > > >
> > > >
> > > >
> > > >=C2=A0 =C2=A0x:yang-data error-info/my-error1 {
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf reason {}
> > > >
> > > >=C2=A0 =C2=A0}
> > > >
> > > >
> > > >
> > > >
> > > >=C2=A0 =C2=A0x:yang-data error-info/my-error2 {
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf reason {}
> > > >
> > > >=C2=A0 =C2=A0}
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Could a fix for this be something along the lines of: > > > >=C2=A0 - yang-data names must be unique amongst other to= p level data nodes
> > > > within the module.
> > > >=C2=A0 - if yang-data extensions are used at the top lev= el then their name
> > must
> > > > be used as a single top level container.
> > > >=C2=A0 - if a yang-data extension is used within another= structure then the
> > > > yang-data name is excluded, and the top level nodes def= ined in the
> > > > yang-data definition are used ....
> > > >
> > > >
> > > >=C2=A0 =C2=A0Every tool that implements yang-data has to= be able
> > > >
> > > > to interpret a yang-data statement exactly the same way= .
> > > >
> > > >
> > > >
> > > > If you want to reinvent XSD substitutionGroup, then do = it right.
> > > >
> > > > I'm not familiar with them.=C2=A0 From a quick read= , I don't see how they
> > are
> > > > related to the problem that we are trying to solve here= .
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > A substitutionGroup allows a point int the schema to be= identified by
> > name.
> > > >
> > > > Different elements can be defined that match this name,= which then can
> > be
> > > >
> > > > used (like a YANG choice) at the specified schema point= .
> > > >
> > > > (e.g. error-info above is like a substitutionGroup)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 16/04/2018 15:36, Andy Bierman wrote:
> > > >
> > > > Hi,
> > > >
> > > >
> > > >
> > > > I am strongly opposed to this change because it breaks = the rule in
> > YANG 1..1
> > > >
> > > > that there cannot be 2 sibling nodes defined in the sam= e module
> > namespace..
> > > >
> > > >
> > > >
> > > > IMO since any yang-data nodes are ALLOWED to be used at= the top-level,
> > > >
> > > > then these top-level nodes cannot have conflicting name= s.
> > > >
> > > >
> > > >
> > > > It is very important when parsing an instance document = that the
> > instance
> > > > data
> > > >
> > > > can be associated with the correct schema.=C2=A0 This i= s not possible if the
> > > >
> > > > same top-level node has multiple yang-data nodes define= d.
> > > >
> > > >
> > > >
> > > > If one needs to define data that is not top-level, (1) = use
> > > > augment-yang-data
> > > >
> > > > or (2) use a different module.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund <<= a href=3D"mailto:mbj@tail-f.com">mbj@tail-f.com>
> > wrote:
> > > >
> > > > Hi,
> > > >
> > > > While preparing draft-ietf-netmod-yang-data-ext-02= , it turned out that
> > > > it is not clear what, if any, restrictions should be en= forced for
> > > > yang-data structures.=C2=A0 Even among the authors we h= ave different ideas
> > > > for how this should work.
> > > >
> > > > Background:
> > > >
> > > > In 8040, the original yang-data extension had a restric= tion that said
> > > > that a yang-data structure MUST have exactly one contai= ner, since it
> > > > wouldn't be possible to have a yang-data structure = in an XML instance
> > > > document otherwise.
> > > >
> > > > Since people want to use yang-data structures in other = places, this
> > > > restriction was lifted in the new draft:
> > > >
> > > >=C2=A0 =C2=A0 There is no longer an assumption that a ya= ng data structure can
> > > >=C2=A0 =C2=A0 only be used as a top-level abstraction, i= nstead of nested within
> > > >=C2=A0 =C2=A0 some other data structure.
> > > >
> > > >
> > > > With this in mind, here's a use case that I think w= e ought to support:
> > > >
> > > >=C2=A0 =C2=A0rpc my-first-rpc {
> > > >=C2=A0 =C2=A0 =C2=A0description
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Bla bla...
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 If an error occurs, <erro= r-info> will contain an instance of
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the yang-data structure '= ;my-first-rpc-error-info'.";
> > > >=C2=A0 =C2=A0 =C2=A0...
> > > >=C2=A0 =C2=A0}
> > > >
> > > >=C2=A0 =C2=A0yang-data my-first-rpc-error-info {
> > > >=C2=A0 =C2=A0 =C2=A0leaf reason { ... }
> > > >=C2=A0 =C2=A0 =C2=A0container user-info { ... }
> > > >=C2=A0 =C2=A0}
> > > >
> > > >=C2=A0 =C2=A0rpc my-second-rpc {
> > > >=C2=A0 =C2=A0 =C2=A0description
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Bla bla...
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 If an error occurs, <erro= r-info> will contain an instance of
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the yang-data structure '= ;my-second-rpc-error-info'.";
> > > >=C2=A0 =C2=A0 =C2=A0...
> > > >=C2=A0 =C2=A0}
> > > >
> > > >=C2=A0 =C2=A0yang-data my-second-rpc-error-info {
> > > >=C2=A0 =C2=A0 =C2=A0leaf reason { ... }
> > > >=C2=A0 =C2=A0 =C2=A0leaf important-url { ... }
> > > >=C2=A0 =C2=A0}
> > > >
> > > > (maybe in the future we could even have a YANG extensio= n statement to
> > > > formalize the description:
> > > >
> > > >=C2=A0 =C2=A0 rpc my-first-rpc {
> > > >=C2=A0 =C2=A0 =C2=A0 ...
> > > >=C2=A0 =C2=A0 =C2=A0 opx:error-info-structure my-first-r= pc-error-info;
> > > >=C2=A0 =C2=A0 }
> > > >
> > > > but this is not point now.)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I see no reason to reinvent the grouping-stmt.
> > > >
> > > > You could easily say opx:error-info-structure argument = is a grouping
> > name
> > > >
> > > > as it is a yang-data name.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > In the example above, note that the leaf "reason&q= uot; is present in both
> > > > structures.=C2=A0 IMO this is not a problem, since thes= e structures are
> > > > used in different contexts.
> > > >
> > > > My point is that I think we should impose as few restri= ctions as
> > > > possible to the yang-data extension.=C2=A0 It should be= up to the user of
> > > > yang-data to ensure that the structure is defined in su= ch a way so
> > > > that it can be used properly.=C2=A0 For example, a stru= cture that is
> > > > supposed to describe an XML instance document cannot de= fine two leafs
> > > > at the top level.
> > > >
> > > > If the WG agrees with what I wrote above, we need to ch= ange the
> > > > augment-yang-data extension so that you would write for= example:
> > > >
> > > >=C2=A0 =C2=A0yx:augment-yang-data /ex:my-first-rpc-error= -info/ex:user-info {
> > > >=C2=A0 =C2=A0 =C2=A0...
> > > >=C2=A0 =C2=A0}
> > > >
> > > > Comments?
> > > >
> > > >
> > > >
> > > > /martin
> > > >
> > > > _______________________________________________ > > > > netmod mailing list
> > > > netmod@ietf.org<= br> > > > > https://www.ietf.org/mailman/li= stinfo/netmod
> > > > <https://urldefense.p= roofpoint.com/v2/url?u=3Dhttps-
> > 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwMFaQ&= c=3D
> > HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D
> > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3Dq6I_
> > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=3DjECZMhy= pw9LtuxzuntkFNM-
> > 8lm7xpztYwDDLOxCM_8k&e=3D>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________ > > > >
> > > > netmod mailing list
> > > >
> > > > netmod@ietf.org<= br> > > > >
> > > > https://www.ietf.org/mailman/li= stinfo/netmod <https://urldefense.
> > proofpoint.com/v2/url?u=3D= https-3A__www.ietf.org_mailman_
> > listinfo_netmod&d=3DDwMFaQ&c=3DHAkYuh63rsuhr6Scbfh0U= jBXeMK-ndb3voDTXcWzoCI&r=3D
> > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3Dq6I_
> > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=3DjECZMhy= pw9LtuxzuntkFNM-
> > 8lm7xpztYwDDLOxCM_8k&e=3D>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >

--001a114b1384b621b2056a8216df-- From nobody Mon Apr 23 04:28:37 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABF0127871 for ; Mon, 23 Apr 2018 04:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62b8d3NpuNNH for ; Mon, 23 Apr 2018 04:28:32 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 898EE124D6C for ; Mon, 23 Apr 2018 04:28:32 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id E37431AE018C; Mon, 23 Apr 2018 13:28:30 +0200 (CEST) Date: Mon, 23 Apr 2018 13:28:30 +0200 (CEST) Message-Id: <20180423.132830.1432860273167614403.mbj@tail-f.com> To: andy@yumaworks.com Cc: kwatsen@juniper.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180423.085222.753779000097456009.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 11:28:36 -0000 Andy Bierman wrote: > On Sun, Apr 22, 2018 at 11:52 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund > > wrote: > > > > > > > Hi, > > > > > > > > Andy Bierman wrote: > > > > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen > > > > wrote: > > > > > > > > > > > I like Andy's proposal below, for the argument of the 'yang-data' > > > > > > statement to encode some meta-information regarding the > > > > context/namespace > > > > > > in which it's used, but I wonder how it really works. For > > instance, > > > > would > > > > > > "top" and "error-info" be the only allowed base-path values for the > > > > > > argument? and what is the value of the remainder of the path? are > > we > > > > > > expecting for there to be some kind us 'uses' statement that can > > refer > > > > to > > > > > > just the base-path component to implement substitution-group like > > > > behavior? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If we want to avoid defining these contexts, then we could just > > define > > > > root > > > > > vs. nonroot. > > > > > > > > > > e,g: > > > > > > > > > > x:yang-data /mydef1 { > > > > > container foo; > > > > > } > > > > > > > > > > x:yang-data mydef2 { > > > > > leaf x; > > > > > leaf y; > > > > > container z; > > > > > } > > > > > > > > > > > > > > > Only an argument starting with '/' would be treated as a top-level > > data > > > > > node. > > > > > > > > > > All other yang-data definitions are not allowed to appear as a root > > node. > > > > > The context where this yang-data is used is completely proprietary. > > > > > The mechanism used to expand this yang-data as if it was a grouping > > > > > is completely proprietary. > > > > > > > > > > The augment-yang-data extension only applies to top-level yang-data > > > > > definitions. > > > > > > > > > > However, my preference is to only standardize top-level yang-data. > > > > > > > > What is "top-level" yang-data? > > > > > > > > > > > > > > > It is a data structure that represents an instance document. > > > > So then I assume that you also want to change the current draft -01 > > behavior so that a yang-data structure MUST have a single container as > > the child? Just like in rc:yang-data. > > > > > > A yang-data structure representing an instance document needs to result in > a container. Right, and since you wrote: my preference is to only standardize top-level yang-data. I assume that you want to re-add the CLR about a single container in yang-ext? > > > Since this is the ONLY definition of yang-data we have in the standard, > > > what is a yang-data definition that represents some unspecified usage, > > > other than an instance document? > > > > We want to create a flexible solution for creating structures that can > > be used in other places than just self-contained instance document. > > One example is the error-info data (see subscribed-notifications). > > > > > Why is this any different than a YANG grouping? > > > > ? We don't have these CLRs for groupings; the following is legal: > > > > grouping foo { > > leaf a { ... } > > leaf b { ... } > > } > > > > grouping bar { > > leaf b { ... } > > } > > > > > > It is up to the user of the grouping to ensure it is used in a way so > > that the result is legal. I think yang-data should work the same > > way. > > > > > > > > We don't need yang-data to be another way to define a grouping, because > we already have grouping-stmt. I agree. At some point someone suggested "uses-yang-data", I think we both agreed that this was a bad idea. > We don't need to re-invent another collection of data-def-stmts that are not > instantiated as data nodes automatically. Any place you could use yang-data > for this purpose, you could use a grouping instead. I'm not sure what you are trying to say. Are you suggesting that we don't need yang-data at all? /martin > > > > > /martin > > > > > > > > Andy > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > I do not see any need for the other form since all functionality can > > be > > > > > achieved with a grouping and a proprietary YANG extension. > > > > > > > > > > Kent // contributor > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" < > > > > > > netmod-bounces@ietf.org on behalf of andy@yumaworks.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 16/04/2018 17:07, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton > > > > wrote: > > > > > > > > > > > > Don't groupings have a somewhat similar concern? > > > > > > > > > > > > E.g. if two groupings define the same data node name and are used > > at > > > > the > > > > > > same point then you would get a namespace clash, but YANG does not > > > > disallow > > > > > > the groupings: > > > > > > > > > > > > > > > > > > grouping foo_widget { > > > > > > > > > > > > leaf name { > > > > > > > > > > > > type string; > > > > > > > > > > > > description "Name of my foo widget"; > > > > > > > > > > > > } > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > grouping bar_widget { > > > > > > > > > > > > leaf name { > > > > > > > > > > > > type string; > > > > > > > > > > > > description "Name of my bar widget"; > > > > > > > > > > > > } > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > container all_widgets { > > > > > > > > > > > > uses foo_widget; > > > > > > > > > > > > uses bar_widget; > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > The principal difference here, is that the compiler can easily > > check > > > > and > > > > > > reject the conflict at the uses statements. > > > > > > > > > > > > Hence I think that it would be good if we could find a solution for > > > > > > yang-data-ext that doesn't not require all root yang-data nodes to > > be > > > > > > unique, since that feels somewhat clunky. I.e. my preference is to > > > > keep > > > > > > them less restrictive, as Martin has proposed, if this is feasible. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is not clunky that 2 top-level YANG data nodes in the same > > module > > > > > > > > > > > > have unique names. This is simple and deterministic. > > > > > > > > > > > > This restriction has not been a problem so far. > > > > > > > > > > > > I agree with the statements above. > > > > > > > > > > > > But it is not clear to me that yang-data-ext is really defining > > new top > > > > > > level data nodes that are part of the same tree/namespace as the > > > > > > configuration/state nodes. In Martin's examples they were used > > within > > > > > > RPCs, and it the forcing the names to be unique in that context > > that I > > > > > > think would be clunky. E.g. in Martin's example forcing different > > > > names > > > > > > for "reason" and "user-info" doesn't seem to be helpful. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The yang-data statement has to define the context or new abstract > > > > > > namespace, > > > > > > > > > > > > or whatever this hack is called. > > > > > > > > > > > > Perhaps. I think that this depends on how they are used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The yang-data statement has to specify the expansion point, or > > > > > > > > > > > > at least specify that it is or is not the top-level. > > > > > > > > > > > > > > > > > > > > > > > > yang-data top/name1 { > > > > > > > > > > > > container mydata; > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > where context is something like "top" or "error-info", etc. > > > > > > > > > > > > > > > > > > > > > > > > It is trivial to use groupings if the same set of nodes needs to be > > > > used > > > > > > in different contexts: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yang-data error-info/name1 { > > > > > > > > > > > > container mydata; > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > Only the context named "top" is restricted to a resulting > > > > single-container > > > > > > > > > > > > and cannot have duplicate names. > > > > > > > > > > > > > > > > > > > > > > > > This is OK: > > > > > > > > > > > > > > > > > > > > > > > > x:yang-data error-info/my-error1 { > > > > > > > > > > > > leaf reason {} > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > x:yang-data error-info/my-error2 { > > > > > > > > > > > > leaf reason {} > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could a fix for this be something along the lines of: > > > > > > - yang-data names must be unique amongst other top level data > > nodes > > > > > > within the module. > > > > > > - if yang-data extensions are used at the top level then their > > name > > > > must > > > > > > be used as a single top level container. > > > > > > - if a yang-data extension is used within another structure then > > the > > > > > > yang-data name is excluded, and the top level nodes defined in the > > > > > > yang-data definition are used .... > > > > > > > > > > > > > > > > > > Every tool that implements yang-data has to be able > > > > > > > > > > > > to interpret a yang-data statement exactly the same way. > > > > > > > > > > > > > > > > > > > > > > > > If you want to reinvent XSD substitutionGroup, then do it right. > > > > > > > > > > > > I'm not familiar with them. From a quick read, I don't see how > > they > > > > are > > > > > > related to the problem that we are trying to solve here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A substitutionGroup allows a point int the schema to be identified > > by > > > > name. > > > > > > > > > > > > Different elements can be defined that match this name, which then > > can > > > > be > > > > > > > > > > > > used (like a YANG choice) at the specified schema point. > > > > > > > > > > > > (e.g. error-info above is like a substitutionGroup) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 16/04/2018 15:36, Andy Bierman wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > I am strongly opposed to this change because it breaks the rule in > > > > YANG 1..1 > > > > > > > > > > > > that there cannot be 2 sibling nodes defined in the same module > > > > namespace.. > > > > > > > > > > > > > > > > > > > > > > > > IMO since any yang-data nodes are ALLOWED to be used at the > > top-level, > > > > > > > > > > > > then these top-level nodes cannot have conflicting names. > > > > > > > > > > > > > > > > > > > > > > > > It is very important when parsing an instance document that the > > > > instance > > > > > > data > > > > > > > > > > > > can be associated with the correct schema. This is not possible > > if the > > > > > > > > > > > > same top-level node has multiple yang-data nodes defined. > > > > > > > > > > > > > > > > > > > > > > > > If one needs to define data that is not top-level, (1) use > > > > > > augment-yang-data > > > > > > > > > > > > or (2) use a different module. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out > > that > > > > > > it is not clear what, if any, restrictions should be enforced for > > > > > > yang-data structures. Even among the authors we have different > > ideas > > > > > > for how this should work. > > > > > > > > > > > > Background: > > > > > > > > > > > > In 8040, the original yang-data extension had a restriction that > > said > > > > > > that a yang-data structure MUST have exactly one container, since > > it > > > > > > wouldn't be possible to have a yang-data structure in an XML > > instance > > > > > > document otherwise. > > > > > > > > > > > > Since people want to use yang-data structures in other places, this > > > > > > restriction was lifted in the new draft: > > > > > > > > > > > > There is no longer an assumption that a yang data structure can > > > > > > only be used as a top-level abstraction, instead of nested > > within > > > > > > some other data structure. > > > > > > > > > > > > > > > > > > With this in mind, here's a use case that I think we ought to > > support: > > > > > > > > > > > > rpc my-first-rpc { > > > > > > description > > > > > > "Bla bla... > > > > > > If an error occurs, will contain an instance of > > > > > > the yang-data structure 'my-first-rpc-error-info'."; > > > > > > ... > > > > > > } > > > > > > > > > > > > yang-data my-first-rpc-error-info { > > > > > > leaf reason { ... } > > > > > > container user-info { ... } > > > > > > } > > > > > > > > > > > > rpc my-second-rpc { > > > > > > description > > > > > > "Bla bla... > > > > > > If an error occurs, will contain an instance of > > > > > > the yang-data structure 'my-second-rpc-error-info'."; > > > > > > ... > > > > > > } > > > > > > > > > > > > yang-data my-second-rpc-error-info { > > > > > > leaf reason { ... } > > > > > > leaf important-url { ... } > > > > > > } > > > > > > > > > > > > (maybe in the future we could even have a YANG extension statement > > to > > > > > > formalize the description: > > > > > > > > > > > > rpc my-first-rpc { > > > > > > ... > > > > > > opx:error-info-structure my-first-rpc-error-info; > > > > > > } > > > > > > > > > > > > but this is not point now.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I see no reason to reinvent the grouping-stmt. > > > > > > > > > > > > You could easily say opx:error-info-structure argument is a > > grouping > > > > name > > > > > > > > > > > > as it is a yang-data name. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the example above, note that the leaf "reason" is present in > > both > > > > > > structures. IMO this is not a problem, since these structures are > > > > > > used in different contexts. > > > > > > > > > > > > My point is that I think we should impose as few restrictions as > > > > > > possible to the yang-data extension. It should be up to the user > > of > > > > > > yang-data to ensure that the structure is defined in such a way so > > > > > > that it can be used properly. For example, a structure that is > > > > > > supposed to describe an XML instance document cannot define two > > leafs > > > > > > at the top level. > > > > > > > > > > > > If the WG agrees with what I wrote above, we need to change the > > > > > > augment-yang-data extension so that you would write for example: > > > > > > > > > > > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info { > > > > > > ... > > > > > > } > > > > > > > > > > > > Comments? > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c= > > > > HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r= > > > > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_ > > > > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM- > > > > 8lm7xpztYwDDLOxCM_8k&e=> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > netmod mailing list > > > > > > > > > > > > netmod@ietf.org > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ > > > > listinfo_netmod&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > > ndb3voDTXcWzoCI&r= > > > > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_ > > > > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM- > > > > 8lm7xpztYwDDLOxCM_8k&e=> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From nobody Mon Apr 23 08:59:47 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752F912D7E2 for ; Mon, 23 Apr 2018 08:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSl6-zu-zG1W for ; Mon, 23 Apr 2018 08:59:41 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A0912D77E for ; Mon, 23 Apr 2018 08:59:41 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id y15-v6so7643671lfj.0 for ; Mon, 23 Apr 2018 08:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m6eQhpMKKJPRgpKa7BjGrGgHTC4fzLZKdwVm9GmuoH4=; b=w4BArkA56sncpagC6YCoswtNMHyKNWiON7I6rRy71E4TRRjodL7BlWrR/+81263wP+ IXVFWIhZw370M17jYjwj1YlNbVSenKE4MTYFk9zT046xEqcgmq3Rd/saey4EtpzrXm7W ngEyXDpZ8APYcR2VR73GSMIt7UszpaDP0uACRrbmVJp22igkOlA2P+d+OMzsoSUdtL2w 1g7zo4G1vx5EB3eIzhRYVOLEAPp4r3e2BcM3nyHDNcf4gFBPP1tTYi9DM+NS8QvnLsEm mTWs0UOx+WNQbqzh2RSgMonGUlVGNjiCgIdPff56ZIImPc5wepxf7S87uMMAFXZAma2w v64w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m6eQhpMKKJPRgpKa7BjGrGgHTC4fzLZKdwVm9GmuoH4=; b=nOmsJw306YI1zppJvONaB77xTd700CcnAML/7kMO5E6SwKaswZcrJakFpChzHDUMQ4 KJtlGPjQsLLtIzGMBrRQ7oNg+LNFdzLF65R5FjMCEOaLNXSXwVSNhWDGH+o349c1H0b4 nazw1hn7Ti9MqXQoBHibhDMqQMjXO89fcEZhgK6AA4MW6nTE6XsckrM/a4P2hbGrieNf OfC0sx4lPydesM+j5/5hvWCthgnqIOG/tAlY7tGQCW40z8jTJzOaQtxKdFcbGq1AlSyG YrpW2Jwdj3is8w3a1xROUNKOyj77AAxDAEVaBx24EQJfjv3fIA7j735RdqnEzzRNHtoF w9BQ== X-Gm-Message-State: ALQs6tAusc9gRom7NOBUJwUa4xY1WTNBp/U0eL12ziliboNywzUqH3KX 9HQ4MVlhkh404gzeNLbEKfq81XwoidxuWIhzu2SkNw== X-Google-Smtp-Source: AB8JxZpMvD5F+WBzXyuMXA+Fb2tMwYjUPr4v/WJuh1QUfwul20gUvE9CdPZLFnWR69WHeT7a2N0M3Zk+c8AdulbD3Bc= X-Received: by 2002:a19:93ce:: with SMTP id w75-v6mr9621321lfk.38.1524499179164; Mon, 23 Apr 2018 08:59:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 08:59:38 -0700 (PDT) In-Reply-To: <20180423.132830.1432860273167614403.mbj@tail-f.com> References: <20180423.085222.753779000097456009.mbj@tail-f.com> <20180423.132830.1432860273167614403.mbj@tail-f.com> From: Andy Bierman Date: Mon, 23 Apr 2018 08:59:38 -0700 Message-ID: To: Martin Bjorklund Cc: Kent Watsen , NetMod WG Content-Type: multipart/alternative; boundary="00000000000008f53c056a8620ef" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 15:59:46 -0000 --00000000000008f53c056a8620ef Content-Type: text/plain; charset="UTF-8" On Mon, Apr 23, 2018 at 4:28 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Sun, Apr 22, 2018 at 11:52 PM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > Andy Bierman wrote: > > > > > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen < > kwatsen@juniper.net> > > > > > wrote: > > > > > > > > > > > > > I like Andy's proposal below, for the argument of the > 'yang-data' > > > > > > > statement to encode some meta-information regarding the > > > > > context/namespace > > > > > > > in which it's used, but I wonder how it really works. For > > > instance, > > > > > would > > > > > > > "top" and "error-info" be the only allowed base-path values > for the > > > > > > > argument? and what is the value of the remainder of the path? > are > > > we > > > > > > > expecting for there to be some kind us 'uses' statement that > can > > > refer > > > > > to > > > > > > > just the base-path component to implement substitution-group > like > > > > > behavior? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If we want to avoid defining these contexts, then we could just > > > define > > > > > root > > > > > > vs. nonroot. > > > > > > > > > > > > e,g: > > > > > > > > > > > > x:yang-data /mydef1 { > > > > > > container foo; > > > > > > } > > > > > > > > > > > > x:yang-data mydef2 { > > > > > > leaf x; > > > > > > leaf y; > > > > > > container z; > > > > > > } > > > > > > > > > > > > > > > > > > Only an argument starting with '/' would be treated as a > top-level > > > data > > > > > > node. > > > > > > > > > > > > All other yang-data definitions are not allowed to appear as a > root > > > node. > > > > > > The context where this yang-data is used is completely > proprietary. > > > > > > The mechanism used to expand this yang-data as if it was a > grouping > > > > > > is completely proprietary. > > > > > > > > > > > > The augment-yang-data extension only applies to top-level > yang-data > > > > > > definitions. > > > > > > > > > > > > However, my preference is to only standardize top-level > yang-data. > > > > > > > > > > What is "top-level" yang-data? > > > > > > > > > > > > > > > > > > > It is a data structure that represents an instance document. > > > > > > So then I assume that you also want to change the current draft -01 > > > behavior so that a yang-data structure MUST have a single container as > > > the child? Just like in rc:yang-data. > > > > > > > > > > A yang-data structure representing an instance document needs to result > in > > a container. > > Right, and since you wrote: > > my preference is to only standardize top-level yang-data. > > I assume that you want to re-add the CLR about a single container in > yang-ext? > > > > > Since this is the ONLY definition of yang-data we have in the > standard, > > > > what is a yang-data definition that represents some unspecified > usage, > > > > other than an instance document? > > > > > > We want to create a flexible solution for creating structures that can > > > be used in other places than just self-contained instance document. > > > One example is the error-info data (see subscribed-notifications). > > > > > > > Why is this any different than a YANG grouping? > > > > > > ? We don't have these CLRs for groupings; the following is legal: > > > > > > grouping foo { > > > leaf a { ... } > > > leaf b { ... } > > > } > > > > > > grouping bar { > > > leaf b { ... } > > > } > > > > > > > > > It is up to the user of the grouping to ensure it is used in a way so > > > that the result is legal. I think yang-data should work the same > > > way. > > > > > > > > > > > > > We don't need yang-data to be another way to define a grouping, because > > we already have grouping-stmt. > > I agree. At some point someone suggested "uses-yang-data", I think we > both agreed that this was a bad idea. > > > We don't need to re-invent another collection of data-def-stmts that are > not > > instantiated as data nodes automatically. Any place you could use > yang-data > > for this purpose, you could use a grouping instead. > > I'm not sure what you are trying to say. Are you suggesting that we > don't need yang-data at all? > > I do not understand the need for a yang-data structure that represents data that can be instantiated anywhere and everywhere. I do not want to break existing tools that expect sibling data nodes in the same module namespace to be unique local-names. I would rather stick with the yang-data in RFC 8040 than introduce a new extension with no restrictions. Standard YANG extensions should be interoperable and have a clear purpose. If we do not need to define what a YANG extension does in a way that can be observed somehow, then it does not need to be a standard. > /martin > Andy > > > > > > > > > > > /martin > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > I do not see any need for the other form since all functionality > can > > > be > > > > > > achieved with a grouping and a proprietary YANG extension. > > > > > > > > > > > > Kent // contributor > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" < > > > > > > > netmod-bounces@ietf.org on behalf of andy@yumaworks.com> > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton < > rwilton@cisco.com> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 16/04/2018 17:07, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton < > rwilton@cisco.com> > > > > > wrote: > > > > > > > > > > > > > > Don't groupings have a somewhat similar concern? > > > > > > > > > > > > > > E.g. if two groupings define the same data node name and are > used > > > at > > > > > the > > > > > > > same point then you would get a namespace clash, but YANG does > not > > > > > disallow > > > > > > > the groupings: > > > > > > > > > > > > > > > > > > > > > grouping foo_widget { > > > > > > > > > > > > > > leaf name { > > > > > > > > > > > > > > type string; > > > > > > > > > > > > > > description "Name of my foo widget"; > > > > > > > > > > > > > > } > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > grouping bar_widget { > > > > > > > > > > > > > > leaf name { > > > > > > > > > > > > > > type string; > > > > > > > > > > > > > > description "Name of my bar widget"; > > > > > > > > > > > > > > } > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > container all_widgets { > > > > > > > > > > > > > > uses foo_widget; > > > > > > > > > > > > > > uses bar_widget; > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > The principal difference here, is that the compiler can easily > > > check > > > > > and > > > > > > > reject the conflict at the uses statements. > > > > > > > > > > > > > > Hence I think that it would be good if we could find a > solution for > > > > > > > yang-data-ext that doesn't not require all root yang-data > nodes to > > > be > > > > > > > unique, since that feels somewhat clunky. I.e. my preference > is to > > > > > keep > > > > > > > them less restrictive, as Martin has proposed, if this is > feasible. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is not clunky that 2 top-level YANG data nodes in the same > > > module > > > > > > > > > > > > > > have unique names. This is simple and deterministic. > > > > > > > > > > > > > > This restriction has not been a problem so far. > > > > > > > > > > > > > > I agree with the statements above. > > > > > > > > > > > > > > But it is not clear to me that yang-data-ext is really defining > > > new top > > > > > > > level data nodes that are part of the same tree/namespace as > the > > > > > > > configuration/state nodes. In Martin's examples they were used > > > within > > > > > > > RPCs, and it the forcing the names to be unique in that context > > > that I > > > > > > > think would be clunky. E.g. in Martin's example forcing > different > > > > > names > > > > > > > for "reason" and "user-info" doesn't seem to be helpful. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The yang-data statement has to define the context or new > abstract > > > > > > > namespace, > > > > > > > > > > > > > > or whatever this hack is called. > > > > > > > > > > > > > > Perhaps. I think that this depends on how they are used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The yang-data statement has to specify the expansion point, or > > > > > > > > > > > > > > at least specify that it is or is not the top-level. > > > > > > > > > > > > > > > > > > > > > > > > > > > > yang-data top/name1 { > > > > > > > > > > > > > > container mydata; > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > where context is something like "top" or "error-info", etc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is trivial to use groupings if the same set of nodes needs > to be > > > > > used > > > > > > > in different contexts: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yang-data error-info/name1 { > > > > > > > > > > > > > > container mydata; > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > Only the context named "top" is restricted to a resulting > > > > > single-container > > > > > > > > > > > > > > and cannot have duplicate names. > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is OK: > > > > > > > > > > > > > > > > > > > > > > > > > > > > x:yang-data error-info/my-error1 { > > > > > > > > > > > > > > leaf reason {} > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > x:yang-data error-info/my-error2 { > > > > > > > > > > > > > > leaf reason {} > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could a fix for this be something along the lines of: > > > > > > > - yang-data names must be unique amongst other top level data > > > nodes > > > > > > > within the module. > > > > > > > - if yang-data extensions are used at the top level then their > > > name > > > > > must > > > > > > > be used as a single top level container. > > > > > > > - if a yang-data extension is used within another structure > then > > > the > > > > > > > yang-data name is excluded, and the top level nodes defined in > the > > > > > > > yang-data definition are used .... > > > > > > > > > > > > > > > > > > > > > Every tool that implements yang-data has to be able > > > > > > > > > > > > > > to interpret a yang-data statement exactly the same way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you want to reinvent XSD substitutionGroup, then do it > right. > > > > > > > > > > > > > > I'm not familiar with them. From a quick read, I don't see how > > > they > > > > > are > > > > > > > related to the problem that we are trying to solve here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A substitutionGroup allows a point int the schema to be > identified > > > by > > > > > name. > > > > > > > > > > > > > > Different elements can be defined that match this name, which > then > > > can > > > > > be > > > > > > > > > > > > > > used (like a YANG choice) at the specified schema point. > > > > > > > > > > > > > > (e.g. error-info above is like a substitutionGroup) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 16/04/2018 15:36, Andy Bierman wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am strongly opposed to this change because it breaks the > rule in > > > > > YANG 1..1 > > > > > > > > > > > > > > that there cannot be 2 sibling nodes defined in the same module > > > > > namespace.. > > > > > > > > > > > > > > > > > > > > > > > > > > > > IMO since any yang-data nodes are ALLOWED to be used at the > > > top-level, > > > > > > > > > > > > > > then these top-level nodes cannot have conflicting names. > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is very important when parsing an instance document that the > > > > > instance > > > > > > > data > > > > > > > > > > > > > > can be associated with the correct schema. This is not > possible > > > if the > > > > > > > > > > > > > > same top-level node has multiple yang-data nodes defined. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If one needs to define data that is not top-level, (1) use > > > > > > > augment-yang-data > > > > > > > > > > > > > > or (2) use a different module. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund < > mbj@tail-f.com> > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned > out > > > that > > > > > > > it is not clear what, if any, restrictions should be enforced > for > > > > > > > yang-data structures. Even among the authors we have different > > > ideas > > > > > > > for how this should work. > > > > > > > > > > > > > > Background: > > > > > > > > > > > > > > In 8040, the original yang-data extension had a restriction > that > > > said > > > > > > > that a yang-data structure MUST have exactly one container, > since > > > it > > > > > > > wouldn't be possible to have a yang-data structure in an XML > > > instance > > > > > > > document otherwise. > > > > > > > > > > > > > > Since people want to use yang-data structures in other places, > this > > > > > > > restriction was lifted in the new draft: > > > > > > > > > > > > > > There is no longer an assumption that a yang data structure > can > > > > > > > only be used as a top-level abstraction, instead of nested > > > within > > > > > > > some other data structure. > > > > > > > > > > > > > > > > > > > > > With this in mind, here's a use case that I think we ought to > > > support: > > > > > > > > > > > > > > rpc my-first-rpc { > > > > > > > description > > > > > > > "Bla bla... > > > > > > > If an error occurs, will contain an > instance of > > > > > > > the yang-data structure 'my-first-rpc-error-info'."; > > > > > > > ... > > > > > > > } > > > > > > > > > > > > > > yang-data my-first-rpc-error-info { > > > > > > > leaf reason { ... } > > > > > > > container user-info { ... } > > > > > > > } > > > > > > > > > > > > > > rpc my-second-rpc { > > > > > > > description > > > > > > > "Bla bla... > > > > > > > If an error occurs, will contain an > instance of > > > > > > > the yang-data structure 'my-second-rpc-error-info'."; > > > > > > > ... > > > > > > > } > > > > > > > > > > > > > > yang-data my-second-rpc-error-info { > > > > > > > leaf reason { ... } > > > > > > > leaf important-url { ... } > > > > > > > } > > > > > > > > > > > > > > (maybe in the future we could even have a YANG extension > statement > > > to > > > > > > > formalize the description: > > > > > > > > > > > > > > rpc my-first-rpc { > > > > > > > ... > > > > > > > opx:error-info-structure my-first-rpc-error-info; > > > > > > > } > > > > > > > > > > > > > > but this is not point now.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I see no reason to reinvent the grouping-stmt. > > > > > > > > > > > > > > You could easily say opx:error-info-structure argument is a > > > grouping > > > > > name > > > > > > > > > > > > > > as it is a yang-data name. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the example above, note that the leaf "reason" is present in > > > both > > > > > > > structures. IMO this is not a problem, since these structures > are > > > > > > > used in different contexts. > > > > > > > > > > > > > > My point is that I think we should impose as few restrictions > as > > > > > > > possible to the yang-data extension. It should be up to the > user > > > of > > > > > > > yang-data to ensure that the structure is defined in such a > way so > > > > > > > that it can be used properly. For example, a structure that is > > > > > > > supposed to describe an XML instance document cannot define two > > > leafs > > > > > > > at the top level. > > > > > > > > > > > > > > If the WG agrees with what I wrote above, we need to change the > > > > > > > augment-yang-data extension so that you would write for > example: > > > > > > > > > > > > > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info > { > > > > > > > ... > > > > > > > } > > > > > > > > > > > > > > Comments? > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > _______________________________________________ > > > > > > > netmod mailing list > > > > > > > netmod@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c= > > > > > HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r= > > > > > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_ > > > > > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM- > > > > > 8lm7xpztYwDDLOxCM_8k&e=> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > netmod mailing list > > > > > > > > > > > > > > netmod@ietf.org > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod < > https://urldefense. > > > > > proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ > > > > > listinfo_netmod&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > > > ndb3voDTXcWzoCI&r= > > > > > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_ > > > > > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM- > > > > > 8lm7xpztYwDDLOxCM_8k&e=> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --00000000000008f53c056a8620ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 23, 2018 at 4:28 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Sun, Apr 22, 2018 at 11:52 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > Andy Bierman <= andy@yumaworks.com> wrote:
> > > > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen <= kwatsen@juniper.net>
> > > > wrote:
> > > > >
> > > > > > I like Andy's proposal below, for the arg= ument of the 'yang-data'
> > > > > > statement to encode some meta-information reg= arding the
> > > > context/namespace
> > > > > > in which it's used, but I wonder how it r= eally works.=C2=A0 For
> > instance,
> > > > would
> > > > > > "top" and "error-info" be= the only allowed base-path values for the
> > > > > > argument? and what is the value of the remain= der of the path?=C2=A0 are
> > we
> > > > > > expecting for there to be some kind us 'u= ses' statement that can
> > refer
> > > > to
> > > > > > just the base-path component to implement sub= stitution-group like
> > > > behavior?
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > If we want to avoid defining these contexts, then = we could just
> > define
> > > > root
> > > > > vs. nonroot.
> > > > >
> > > > > e,g:
> > > > >
> > > > > x:yang-data /mydef1 {
> > > > >=C2=A0 =C2=A0container foo;
> > > > > }
> > > > >
> > > > > x:yang-data mydef2 {
> > > > >=C2=A0 =C2=A0leaf x;
> > > > >=C2=A0 =C2=A0leaf y;
> > > > >=C2=A0 =C2=A0container z;
> > > > > }
> > > > >
> > > > >
> > > > > Only an argument starting with '/' would b= e treated as a top-level
> > data
> > > > > node.
> > > > >
> > > > > All other yang-data definitions are not allowed to= appear as a root
> > node.
> > > > > The context where this yang-data is used is comple= tely proprietary.
> > > > > The mechanism used to expand this yang-data as if = it was a grouping
> > > > > is completely proprietary.
> > > > >
> > > > > The augment-yang-data extension only applies to to= p-level yang-data
> > > > > definitions.
> > > > >
> > > > > However, my preference is to only standardize top-= level yang-data.
> > > >
> > > > What is "top-level" yang-data?
> > > >
> > > >
> > > >
> > > It is a data structure that represents an instance document.=
> >
> > So then I assume that you also want to change the current draft -= 01
> > behavior so that a yang-data structure MUST have a single contain= er as
> > the child?=C2=A0 Just like in rc:yang-data.
> >
> >
>
> A yang-data structure representing an instance document needs to resul= t in
> a container.

Right, and since you wrote:

=C2=A0 =C2=A0 my preference is to only standardize top-level yang-data.

I assume that you want to re-add the CLR about a single container in
yang-ext?

> > > Since this is the ONLY definition of yang-data we have in th= e standard,
> > > what is a yang-data definition that represents some unspecif= ied usage,
> > > other than an instance document?
> >
> > We want to create a flexible solution for creating structures tha= t can
> > be used in other places than just self-contained instance documen= t.
> > One example is the error-info data (see subscribed-notifications)= .
> >
> > > Why is this any different than a YANG grouping?
> >
> > ?=C2=A0 We don't have these CLRs for groupings; the following= is legal:
> >
> >=C2=A0 =C2=A0grouping foo {
> >=C2=A0 =C2=A0 =C2=A0leaf a { ... }
> >=C2=A0 =C2=A0 =C2=A0leaf b { ... }
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping bar {
> >=C2=A0 =C2=A0 =C2=A0leaf b { ... }
> >=C2=A0 =C2=A0}
> >
> >
> > It is up to the user of the grouping to ensure it is used in a wa= y so
> > that the result is legal.=C2=A0 I think yang-data should work the= same
> > way.
> >
> >
> >
>
> We don't need yang-data to be another way to define a grouping, be= cause
> we already have grouping-stmt.

I agree.=C2=A0 At some point someone suggested "uses-yang-data", = I think we
both agreed that this was a bad idea.

> We don't need to re-invent another collection of data-def-stmts th= at are not
> instantiated as data nodes automatically. Any place you could use yang= -data
> for this purpose, you could use a grouping instead.

I'm not sure what you are trying to say.=C2=A0 Are you suggesting that = we
don't need yang-data at all?



I do not understand the= need for a yang-data structure that represents data
that can be = instantiated anywhere and everywhere.=C2=A0 I do not want to break
existing tools that expect sibling data nodes in the same module namespac= e to
be unique local-names.

I would rath= er stick with the yang-data in RFC 8040 than introduce a new extension
with no restrictions.=C2=A0 Standard YANG extensions should be intero= perable and have
a clear purpose. If we do not need to define wha= t a YANG extension does in
a way that can be observed somehow, th= en it does not need to be a standard.



/martin


Andy
= =C2=A0


>
>
>
> > /martin
> >
> >
> >
>
> Andy
>
>
>
> >
> > >
> > >
> > >
> > > > /martin
> > > >
> > > >
> > > >
> > > Andy
> > >
> > >
> > >
> > > > > I do not see any need for the other form since all= functionality can
> > be
> > > > > achieved with a grouping and a proprietary YANG ex= tension.
> > > > >
> > > > > Kent // contributor
> > > > > >
> > > > >
> > > > > Andy
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 4/16/18, 1:05 PM, "netmod on behalf o= f Andy Bierman" <
> > > > > > ne= tmod-bounces@ietf.org on behalf of andy@yumaworks.com> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilto= n <rwilton@cisco.com>
> > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 16/04/2018 17:07, Andy Bierman wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilto= n <rwilton@cisco.com>
> > > > wrote:
> > > > > >
> > > > > > Don't groupings have a somewhat similar c= oncern?
> > > > > >
> > > > > >=C2=A0 E.g. if two groupings define the same d= ata node name and are used
> > at
> > > > the
> > > > > > same point then you would get a namespace cla= sh, but YANG does not
> > > > disallow
> > > > > > the groupings:
> > > > > >
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 grouping foo_widget {
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name {
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string= ;
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description= "Name of my foo widget";
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 }
> > > > > >
> > > > > >
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 grouping bar_widget {
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name {
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string= ;
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description= "Name of my bar widget";
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 }
> > > > > >
> > > > > >
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 container all_widgets { > > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses foo_widget; > > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses bar_widget; > > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 }
> > > > > >
> > > > > >
> > > > > > The principal difference here, is that the co= mpiler can easily
> > check
> > > > and
> > > > > > reject the conflict at the uses statements. > > > > > >
> > > > > > Hence I think that it would be good if we cou= ld find a solution for
> > > > > > yang-data-ext that doesn't not require al= l root yang-data nodes to
> > be
> > > > > > unique, since that feels somewhat clunky.=C2= =A0 I.e. my preference is to
> > > > keep
> > > > > > them less restrictive, as Martin has proposed= , if this is feasible.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > It is not clunky that 2 top-level YANG data n= odes in the same
> > module
> > > > > >
> > > > > > have unique names. This is simple and determi= nistic.
> > > > > >
> > > > > > This restriction has not been a problem so fa= r.
> > > > > >
> > > > > > I agree with the statements above.
> > > > > >
> > > > > > But it is not clear to me that yang-data-ext = is really defining
> > new top
> > > > > > level data nodes that are part of the same tr= ee/namespace as the
> > > > > > configuration/state nodes.=C2=A0 In Martin= 9;s examples they were used
> > within
> > > > > > RPCs, and it the forcing the names to be uniq= ue in that context
> > that I
> > > > > > think would be clunky.=C2=A0 E.g. in Martin&#= 39;s example forcing different
> > > > names
> > > > > > for "reason" and "user-info&qu= ot; doesn't seem to be helpful.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > The yang-data statement has to define the con= text or new abstract
> > > > > > namespace,
> > > > > >
> > > > > > or whatever this hack is called.
> > > > > >
> > > > > > Perhaps.=C2=A0 I think that this depends on h= ow they are used.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > The yang-data statement has to specify the ex= pansion point, or
> > > > > >
> > > > > > at least specify that it is or is not the top= -level.
> > > > > >
> > > > > >
> > > > > >
> > > > > >=C2=A0 =C2=A0yang-data top/name1 {
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0container mydata; > > > > > >
> > > > > >=C2=A0 =C2=A0}
> > > > > >
> > > > > >
> > > > > >
> > > > > > where context is something like "top&quo= t; or "error-info", etc.
> > > > > >
> > > > > >
> > > > > >
> > > > > > It is trivial to use groupings if the same se= t of nodes needs to be
> > > > used
> > > > > > in different contexts:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >=C2=A0 =C2=A0yang-data error-info/name1 {
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0container mydata; > > > > > >
> > > > > >=C2=A0 =C2=A0}
> > > > > >
> > > > > >
> > > > > >
> > > > > > Only the context named "top" is res= tricted to a resulting
> > > > single-container
> > > > > >
> > > > > > and cannot have duplicate names.
> > > > > >
> > > > > >
> > > > > >
> > > > > > This is OK:
> > > > > >
> > > > > >
> > > > > >
> > > > > >=C2=A0 =C2=A0x:yang-data error-info/my-error1 = {
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf reason {}
> > > > > >
> > > > > >=C2=A0 =C2=A0}
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >=C2=A0 =C2=A0x:yang-data error-info/my-error2 = {
> > > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf reason {}
> > > > > >
> > > > > >=C2=A0 =C2=A0}
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Could a fix for this be something along the l= ines of:
> > > > > >=C2=A0 - yang-data names must be unique amongs= t other top level data
> > nodes
> > > > > > within the module.
> > > > > >=C2=A0 - if yang-data extensions are used at t= he top level then their
> > name
> > > > must
> > > > > > be used as a single top level container.
> > > > > >=C2=A0 - if a yang-data extension is used with= in another structure then
> > the
> > > > > > yang-data name is excluded, and the top level= nodes defined in the
> > > > > > yang-data definition are used ....
> > > > > >
> > > > > >
> > > > > >=C2=A0 =C2=A0Every tool that implements yang-d= ata has to be able
> > > > > >
> > > > > > to interpret a yang-data statement exactly th= e same way.
> > > > > >
> > > > > >
> > > > > >
> > > > > > If you want to reinvent XSD substitutionGroup= , then do it right.
> > > > > >
> > > > > > I'm not familiar with them.=C2=A0 From a = quick read, I don't see how
> > they
> > > > are
> > > > > > related to the problem that we are trying to = solve here.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > A substitutionGroup allows a point int the sc= hema to be identified
> > by
> > > > name.
> > > > > >
> > > > > > Different elements can be defined that match = this name, which then
> > can
> > > > be
> > > > > >
> > > > > > used (like a YANG choice) at the specified sc= hema point.
> > > > > >
> > > > > > (e.g. error-info above is like a substitution= Group)
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Rob
> > > > > >
> > > > > >
> > > > > >
> > > > > > Andy
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Rob
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Andy
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 16/04/2018 15:36, Andy Bierman wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > >
> > > > > >
> > > > > > I am strongly opposed to this change because = it breaks the rule in
> > > > YANG 1..1
> > > > > >
> > > > > > that there cannot be 2 sibling nodes defined = in the same module
> > > > namespace..
> > > > > >
> > > > > >
> > > > > >
> > > > > > IMO since any yang-data nodes are ALLOWED to = be used at the
> > top-level,
> > > > > >
> > > > > > then these top-level nodes cannot have confli= cting names.
> > > > > >
> > > > > >
> > > > > >
> > > > > > It is very important when parsing an instance= document that the
> > > > instance
> > > > > > data
> > > > > >
> > > > > > can be associated with the correct schema.=C2= =A0 This is not possible
> > if the
> > > > > >
> > > > > > same top-level node has multiple yang-data no= des defined.
> > > > > >
> > > > > >
> > > > > >
> > > > > > If one needs to define data that is not top-l= evel, (1) use
> > > > > > augment-yang-data
> > > > > >
> > > > > > or (2) use a different module.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Andy
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjork= lund <mbj@tail-f.com>
> > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > While preparing draft-ietf-netmod-yang-data-<= wbr>ext-02, it turned out
> > that
> > > > > > it is not clear what, if any, restrictions sh= ould be enforced for
> > > > > > yang-data structures.=C2=A0 Even among the au= thors we have different
> > ideas
> > > > > > for how this should work.
> > > > > >
> > > > > > Background:
> > > > > >
> > > > > > In 8040, the original yang-data extension had= a restriction that
> > said
> > > > > > that a yang-data structure MUST have exactly = one container, since
> > it
> > > > > > wouldn't be possible to have a yang-data = structure in an XML
> > instance
> > > > > > document otherwise.
> > > > > >
> > > > > > Since people want to use yang-data structures= in other places, this
> > > > > > restriction was lifted in the new draft:
> > > > > >
> > > > > >=C2=A0 =C2=A0 There is no longer an assumption= that a yang data structure can
> > > > > >=C2=A0 =C2=A0 only be used as a top-level abst= raction, instead of nested
> > within
> > > > > >=C2=A0 =C2=A0 some other data structure.
> > > > > >
> > > > > >
> > > > > > With this in mind, here's a use case that= I think we ought to
> > support:
> > > > > >
> > > > > >=C2=A0 =C2=A0rpc my-first-rpc {
> > > > > >=C2=A0 =C2=A0 =C2=A0description
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Bla bla... > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 If an error occurs= , <error-info> will contain an instance of
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the yang-data stru= cture 'my-first-rpc-error-info'.";
> > > > > >=C2=A0 =C2=A0 =C2=A0...
> > > > > >=C2=A0 =C2=A0}
> > > > > >
> > > > > >=C2=A0 =C2=A0yang-data my-first-rpc-error-info= {
> > > > > >=C2=A0 =C2=A0 =C2=A0leaf reason { ... }
> > > > > >=C2=A0 =C2=A0 =C2=A0container user-info { ... = }
> > > > > >=C2=A0 =C2=A0}
> > > > > >
> > > > > >=C2=A0 =C2=A0rpc my-second-rpc {
> > > > > >=C2=A0 =C2=A0 =C2=A0description
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Bla bla... > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 If an error occurs= , <error-info> will contain an instance of
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the yang-data stru= cture 'my-second-rpc-error-info'.";
> > > > > >=C2=A0 =C2=A0 =C2=A0...
> > > > > >=C2=A0 =C2=A0}
> > > > > >
> > > > > >=C2=A0 =C2=A0yang-data my-second-rpc-error-inf= o {
> > > > > >=C2=A0 =C2=A0 =C2=A0leaf reason { ... }
> > > > > >=C2=A0 =C2=A0 =C2=A0leaf important-url { ... }=
> > > > > >=C2=A0 =C2=A0}
> > > > > >
> > > > > > (maybe in the future we could even have a YAN= G extension statement
> > to
> > > > > > formalize the description:
> > > > > >
> > > > > >=C2=A0 =C2=A0 rpc my-first-rpc {
> > > > > >=C2=A0 =C2=A0 =C2=A0 ...
> > > > > >=C2=A0 =C2=A0 =C2=A0 opx:error-info-structure = my-first-rpc-error-info;
> > > > > >=C2=A0 =C2=A0 }
> > > > > >
> > > > > > but this is not point now.)
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I see no reason to reinvent the grouping-stmt= .
> > > > > >
> > > > > > You could easily say opx:error-info-structure= argument is a
> > grouping
> > > > name
> > > > > >
> > > > > > as it is a yang-data name.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > In the example above, note that the leaf &quo= t;reason" is present in
> > both
> > > > > > structures.=C2=A0 IMO this is not a problem, = since these structures are
> > > > > > used in different contexts.
> > > > > >
> > > > > > My point is that I think we should impose as = few restrictions as
> > > > > > possible to the yang-data extension.=C2=A0 It= should be up to the user
> > of
> > > > > > yang-data to ensure that the structure is def= ined in such a way so
> > > > > > that it can be used properly.=C2=A0 For examp= le, a structure that is
> > > > > > supposed to describe an XML instance document= cannot define two
> > leafs
> > > > > > at the top level.
> > > > > >
> > > > > > If the WG agrees with what I wrote above, we = need to change the
> > > > > > augment-yang-data extension so that you would= write for example:
> > > > > >
> > > > > >=C2=A0 =C2=A0yx:augment-yang-data /ex:my-first= -rpc-error-info/ex:user-info {
> > > > > >=C2=A0 =C2=A0 =C2=A0...
> > > > > >=C2=A0 =C2=A0}
> > > > > >
> > > > > > Comments?
> > > > > >
> > > > > >
> > > > > >
> > > > > > /martin
> > > > > >
> > > > > > ________________________________________= _______
> > > > > > netmod mailing list
> > > > > > netmod@iet= f.org
> > > > > > https://www.ietf.org/mailm= an/listinfo/netmod
> > > > > > <https://urldefe= nse.proofpoint.com/v2/url?u=3Dhttps-
> > > > 3A__www.ietf.org_mailman_listinfo_netmod&d=3DD= wMFaQ&c=3D
> > > > HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r= =3D
> > > > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m= =3Dq6I_
> > > > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=3DjECZMhypw9LtuxzuntkFNM-
> > > > 8lm7xpztYwDDLOxCM_8k&e=3D>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________________= _______
> > > > > >
> > > > > > netmod mailing list
> > > > > >
> > > > > > netmod@iet= f.org
> > > > > >
> > > > > > https://www.ietf.org/mailm= an/listinfo/netmod <https://urldefense.
> > > > proofpoint.com/v= 2/url?u=3Dhttps-3A__www.ietf.org_mailman_
> > > > listinfo_netmod&d=3DDwMFaQ&c=3DHAkYuh63rsu= hr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=3D
> > > > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m= =3Dq6I_
> > > > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=3DjECZMhypw9LtuxzuntkFNM-
> > > > 8lm7xpztYwDDLOxCM_8k&e=3D>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> >

--00000000000008f53c056a8620ef-- From nobody Mon Apr 23 09:48:50 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDA212D881 for ; Mon, 23 Apr 2018 09:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YirbyhXPNmS for ; Mon, 23 Apr 2018 09:48:43 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68FB12E887 for ; Mon, 23 Apr 2018 09:48:37 -0700 (PDT) Received: from nitebug.localdomain (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id E9EC9242EC0; Mon, 23 Apr 2018 18:48:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1524502115; bh=xjbIaDmUumd7CW3WA6KWPDN9Jzje5+LyuuqBT9cwjWs=; h=Subject:To:References:From:Date:In-Reply-To; b=J5vGlgwGhzoEP66hhKcVwJSjrJVQiX43HWX+EVOS46fEP7BLy3gDsDMGukLIw0x9W VsB7WKNjtqCz+J0nzcRDd4E/nlNcS1TmWOwwVz8aANZSfcOtSvbm4tezQY319U9DUL Xz5Jb3WpnaBFncsMOjFMgML2TO7AxFCaTScbjI7U= To: Ladislav Lhotka , netmod@ietf.org References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> From: Robert Varga Message-ID: <9e9c4b0e-f7f0-b730-de13-52886d9b3399@hq.sk> Date: Mon, 23 Apr 2018 18:48:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TEtu9BWMHa5gnQmBQ64bQV43a2x8P7D8R" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 16:48:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TEtu9BWMHa5gnQmBQ64bQV43a2x8P7D8R Content-Type: multipart/mixed; boundary="qs0152nxPmLADbrLvzizi8x06swAvqWqm"; protected-headers="v1" From: Robert Varga To: Ladislav Lhotka , netmod@ietf.org Message-ID: <9e9c4b0e-f7f0-b730-de13-52886d9b3399@hq.sk> Subject: Re: [netmod] yang-data-ext issues References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> In-Reply-To: <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> --qs0152nxPmLADbrLvzizi8x06swAvqWqm Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 22/04/18 14:56, Ladislav Lhotka wrote: >> One example: YANG 1.1 was supposed to be a backwards-compatible, yet i= t >> introduced multiple-inheritence to a language which was previously >> strictly single-inheritence. That sort of change is a major revision o= f >> the metamodel and certainly does not qualify as backwards-compatible a= t >> that level of abstraction. > I'd defend YANG 1.1 here, I think it was a well managed and conservativ= e update. > The meaning of backward compatibility was defined in the charter: YANG = 1.0 > modules should continue to work in 1.1. Apart from fixing evident bugs,= I > believe this goal was achieved. I agree and the upgrade process was very smooth, all things considered. > I am much more concerned with some of the post-1.1 features, also becau= se YANG > is now being updated in several directions without a clear vision. And = another > big problem is that YANG extensions are used for these changes, so we w= ill > probably end up with several different versions of YANG, although forma= lly > everything will be 1.1. =20 Agree, and it's especially the interactions between extensions which are critical to manage the outcome. > Regarding your example: from my own experience, implementing validation= of > identityref values with multiple inheritance is not terribly complicate= d in > comparison to single inheritance. I have other favorites for the most p= eculiar > feature in YANG. It's not, but it forced us to incompatibly change our Java binding specifications -- where we used to use abstract classes we have to use interfaces. Luckily there is no state involved :) Regards, Robert --qs0152nxPmLADbrLvzizi8x06swAvqWqm-- --TEtu9BWMHa5gnQmBQ64bQV43a2x8P7D8R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlreDlsLHG5pdGVAaHEu c2sACgkQJKB0S2uuNdujtBAArbzOgLRGFO/N1aXSAIU91ji4AHvMn81MCXubvo+p c0U4NpWPCYTGrAjE9N/ZBOtyN46poWz9KlkES19mq98qOG49aBq92lb5DArvjvIq AHq4KUhSvcqFhac/8szThp9190NA6KzQ9uCwtKzSpLCiznQzFM6x01OAEf7oSjk2 WWLgKxh+6WWZUOAiHHy/jbD15fYzN8IK7MKNWvXCTWQL+fIsNFp5tg+LicAtRW9X RNV6bT0WAuc5nsquB+Lri2jLY/oP3jF2qsFr9XYQ6uH+R/916P6gQoUiYnTp2qU1 JseDN/rGQux1hJzGwJdnkr5u3UV55Pxd5gCnkBrGT4MbSQWQIzU6UgelG1fhDMd6 H/4iUwys+LLEZPy9biNC0YOwQsaIzPM/OczV7Wiu1uRcg4qLmX4auHMSE/41+VcI qlEYap2WJ1O2nThAOcvf6echCxQ/7V9ju4RKGmxRzMspwt7zUZM/gEyu8egba85o hScBFsKmoaX89XQcPjV8zDOkKuOrqkWk1Zo9yQn8tfCDu/OZdsfAegOlvq0TJbJf 4VyK+yLat9TkWOPXkNUbyToDw3TVn60RAp8M7DZ454k8Q4L3Z7xXIi8nUYEBc7Ss VwawEE/FnUDDAmtmMW7ZS0A50qr0uh10PEdv7AcGW4pV/mx8GvN7ox1QkffS4CA0 1ag= =5Jnd -----END PGP SIGNATURE----- --TEtu9BWMHa5gnQmBQ64bQV43a2x8P7D8R-- From nobody Mon Apr 23 09:51:23 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1565E12DA23 for ; Mon, 23 Apr 2018 09:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl7Rhva6Vzt0 for ; Mon, 23 Apr 2018 09:51:07 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265AA12DA1A for ; Mon, 23 Apr 2018 09:51:07 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 51F19CFF; Mon, 23 Apr 2018 18:51:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id iR2E7QSAvCFL; Mon, 23 Apr 2018 18:51:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 23 Apr 2018 18:51:05 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34ACB20031; Mon, 23 Apr 2018 18:51:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id P3rBXNgFO-AO; Mon, 23 Apr 2018 18:51:04 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBE0820035; Mon, 23 Apr 2018 18:51:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 948F942BD5D4; Mon, 23 Apr 2018 18:51:04 +0200 (CEST) Date: Mon, 23 Apr 2018 18:51:04 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: netmod@ietf.org Message-ID: <20180423165104.zi7g75tifhekmezh@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 16:51:22 -0000 On Sun, Apr 22, 2018 at 02:56:51PM +0200, Ladislav Lhotka wrote: > I am much more concerned with some of the post-1.1 features, also > because YANG is now being updated in several directions without a > clear vision. And another big problem is that YANG extensions are > used for these changes, so we will probably end up with several > different versions of YANG, although formally everything will be > 1.1. I tend to agree. Ideally, we would carefully remove things from YANG that did not meet the cost/benefit target (e.g., submodules), reorganize definitions whenever possible (some NETCONF specific stuff in the YANG specification should not be there, XML encoding may be factored out) and incorporate new features (like yang-data) after we have sufficient _experience_ to know that such new features will be useful (which seems to be the case for yang-data). Yes, such iterations likely take 2 years at IETF speed but this kind of maintenance cost/effort is likely the price to be paied for something that is being used at a larger scale. Some people will say that the cost of a new language version is high. (Well, when we did 1.1, some people said it will never be deployed.) Anyway, not bumping the YANG version number but having instead several (optional) language extensions is just hiding the version number change under the carpet. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Apr 23 10:18:43 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A86E126C22 for ; Mon, 23 Apr 2018 10:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjQ-ofJJkixv for ; Mon, 23 Apr 2018 10:18:40 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE3712D886 for ; Mon, 23 Apr 2018 10:18:40 -0700 (PDT) Received: from nitebug.localdomain (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id A7050242EC0; Mon, 23 Apr 2018 19:18:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1524503918; bh=+Mh0UphtMYsH9tdGIpKyl99q2DIxSOet9wv1oE6Fuw0=; h=Subject:To:References:From:Date:In-Reply-To; b=MbrQz30AqZlxJgo4EuiPEOVvancBK06tZkmkOAzuMxLlzZfH8L1YV3+vJknzZZL0+ hMViLQW9I0T3pS0mTPobOBgtASzFlpN65sO/OZhEasMHu2F1El48Skqtt5EufA8k3R KYnPjgIl+l26axkciabtceDcuwpFI29g+72JIuVc= To: Ladislav Lhotka , netmod@ietf.org References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> <20180423165104.zi7g75tifhekmezh@elstar.local> From: Robert Varga Message-ID: Date: Mon, 23 Apr 2018 19:18:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180423165104.zi7g75tifhekmezh@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nBkGyXcEzWUW1bToNKcJY91Ih944ggYeu" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 17:18:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nBkGyXcEzWUW1bToNKcJY91Ih944ggYeu Content-Type: multipart/mixed; boundary="GqYqx4a0SGb5ubBFzhlD2nGv47Rc0d7jh"; protected-headers="v1" From: Robert Varga To: Ladislav Lhotka , netmod@ietf.org Message-ID: Subject: Re: [netmod] yang-data-ext issues References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> <20180423165104.zi7g75tifhekmezh@elstar.local> In-Reply-To: <20180423165104.zi7g75tifhekmezh@elstar.local> --GqYqx4a0SGb5ubBFzhlD2nGv47Rc0d7jh Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 23/04/18 18:51, Juergen Schoenwaelder wrote: > Some people will say that the cost of a new language version is high. > (Well, when we did 1.1, some people said it will never be deployed.) > Anyway, not bumping the YANG version number but having instead several > (optional) language extensions is just hiding the version number > change under the carpet. Not quite, as extensions allow for modular/incremental evolution, as an implementer I do not have to go through a long development cycle where I need to rewire language aspects just to get the features my users need for their models... Regards, Robert --GqYqx4a0SGb5ubBFzhlD2nGv47Rc0d7jh-- --nBkGyXcEzWUW1bToNKcJY91Ih944ggYeu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlreFW4LHG5pdGVAaHEu c2sACgkQJKB0S2uuNdv3XQ//WmtlBi/2fd8rZlH4jPlKNsX7kTowYmixCRQZzqOS jm27g/T1L/Semo+y9hk3L1VoUkMuHq2EIa9WFJKkSa3CRxWl3gOIdRKMdWaIMMLr YEQnun0IAoMh+MwTabkJl0kPKrj3WUezr0qVpWcDcAMkGx1cq1T57Fsv53b28Ypx r/U9lI2TzM+CEWBqmgOeuo9Go5GefpdGMrM41Sx0mJ0sjkTI6xIAVwUAf86LevAt x00A7iTg2BAduHDlUofCk4j3B2UhbKJu+IxGoNxzrwUf97w5yBJnbPchtJcIE6n0 6gKeXSIGEh19VFUPGdgChTv1LYANrMKEuXTJTVIC4fQGVuLB7n0bl2UwTC0HPKGo l04NE+3KpQ3VykF0hRqU77OZojBZhBUnRnABOIccVQyENJKBxLN2bjwN47qI/rk6 XCnPnWRtr/fj7QFKDxTm3y7RiysOAem3vVC37N5ovY03v2KTECnI7fE3ZRj6qkmL IB51RjtkvbjeR5uvewhwrPA9cobSbfs4xAylyi5QmvL50O0YRbL3feqNDyzanPF2 O8jKSbx1Pw9thikb0Jn+bYHYEcZRMdM8IIrtQgmpbnvHOkq56Nhawug3daJMhARH CBBOxKh/v3gOaQeuOxjWhJzFGTVvEwqrd4aIFTqaEu4KM9CyqczGMne0XWutiVgp ILU= =Jgd6 -----END PGP SIGNATURE----- --nBkGyXcEzWUW1bToNKcJY91Ih944ggYeu-- From nobody Mon Apr 23 10:36:42 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CFF124F57 for ; Mon, 23 Apr 2018 10:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3s8ZW7LEPsc for ; Mon, 23 Apr 2018 10:36:39 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD0F1242F7 for ; Mon, 23 Apr 2018 10:36:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id ABF41D00; Mon, 23 Apr 2018 19:36:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id UMLvO7V2LSDD; Mon, 23 Apr 2018 19:36:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 23 Apr 2018 19:36:37 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66D7420035; Mon, 23 Apr 2018 19:36:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OPVLyndmCWtZ; Mon, 23 Apr 2018 19:36:37 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 078CB20031; Mon, 23 Apr 2018 19:36:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D8F0242BD9BC; Mon, 23 Apr 2018 19:36:36 +0200 (CEST) Date: Mon, 23 Apr 2018 19:36:36 +0200 From: Juergen Schoenwaelder To: Robert Varga Cc: Ladislav Lhotka , netmod@ietf.org Message-ID: <20180423173636.fx63befibcc4vhmh@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Varga , Ladislav Lhotka , netmod@ietf.org References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> <20180423165104.zi7g75tifhekmezh@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 17:36:40 -0000 On Mon, Apr 23, 2018 at 07:18:38PM +0200, Robert Varga wrote: > On 23/04/18 18:51, Juergen Schoenwaelder wrote: > > Some people will say that the cost of a new language version is high. > > (Well, when we did 1.1, some people said it will never be deployed.) > > Anyway, not bumping the YANG version number but having instead several > > (optional) language extensions is just hiding the version number > > change under the carpet. > > Not quite, as extensions allow for modular/incremental evolution, as an > implementer I do not have to go through a long development cycle where I > need to rewire language aspects just to get the features my users need > for their models... Once we standardize extensions (and this is what I am talking about), we better make sure that the whole stays consistent. Otherwise, we will end up with patchwork where all the patches may work in isolation but sooner or later they will fall apart when you look at all the possible combinations. I am in favour of managing a clean definition of the core of the YANG language instead of creating patchwork. It is great if people create and prototype new extensions but once such extensions are considered to be ready for general use, we should roll them into the core (and remove any cruft from the core at the same time). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Apr 23 12:49:30 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E0612D7E4 for ; Mon, 23 Apr 2018 12:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyjYH9Idl-jh for ; Mon, 23 Apr 2018 12:49:26 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E6B63126B6E for ; Mon, 23 Apr 2018 12:49:25 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id F19741AE018C; Mon, 23 Apr 2018 21:49:23 +0200 (CEST) Date: Mon, 23 Apr 2018 21:49:23 +0200 (CEST) Message-Id: <20180423.214923.1209533731960312602.mbj@tail-f.com> To: andy@yumaworks.com Cc: kwatsen@juniper.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180423.132830.1432860273167614403.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 19:49:30 -0000 Andy Bierman wrote: > On Mon, Apr 23, 2018 at 4:28 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Sun, Apr 22, 2018 at 11:52 PM, Martin Bjorklund > > wrote: > > > > > > > Andy Bierman wrote: > > > > > On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > Andy Bierman wrote: > > > > > > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen < > > kwatsen@juniper.net> > > > > > > wrote: > > > > > > > > > > > > > > > I like Andy's proposal below, for the argument of the > > 'yang-data' > > > > > > > > statement to encode some meta-information regarding the > > > > > > context/namespace > > > > > > > > in which it's used, but I wonder how it really works. For > > > > instance, > > > > > > would > > > > > > > > "top" and "error-info" be the only allowed base-path values > > for the > > > > > > > > argument? and what is the value of the remainder of the path? > > are > > > > we > > > > > > > > expecting for there to be some kind us 'uses' statement that > > can > > > > refer > > > > > > to > > > > > > > > just the base-path component to implement substitution-group > > like > > > > > > behavior? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If we want to avoid defining these contexts, then we could just > > > > define > > > > > > root > > > > > > > vs. nonroot. > > > > > > > > > > > > > > e,g: > > > > > > > > > > > > > > x:yang-data /mydef1 { > > > > > > > container foo; > > > > > > > } > > > > > > > > > > > > > > x:yang-data mydef2 { > > > > > > > leaf x; > > > > > > > leaf y; > > > > > > > container z; > > > > > > > } > > > > > > > > > > > > > > > > > > > > > Only an argument starting with '/' would be treated as a > > top-level > > > > data > > > > > > > node. > > > > > > > > > > > > > > All other yang-data definitions are not allowed to appear as a > > root > > > > node. > > > > > > > The context where this yang-data is used is completely > > proprietary. > > > > > > > The mechanism used to expand this yang-data as if it was a > > grouping > > > > > > > is completely proprietary. > > > > > > > > > > > > > > The augment-yang-data extension only applies to top-level > > yang-data > > > > > > > definitions. > > > > > > > > > > > > > > However, my preference is to only standardize top-level > > yang-data. > > > > > > > > > > > > What is "top-level" yang-data? > > > > > > > > > > > > > > > > > > > > > > > It is a data structure that represents an instance document. > > > > > > > > So then I assume that you also want to change the current draft -01 > > > > behavior so that a yang-data structure MUST have a single container as > > > > the child? Just like in rc:yang-data. > > > > > > > > > > > > > > A yang-data structure representing an instance document needs to result > > in > > > a container. > > > > Right, and since you wrote: > > > > my preference is to only standardize top-level yang-data. > > > > I assume that you want to re-add the CLR about a single container in > > yang-ext? > > > > > > > Since this is the ONLY definition of yang-data we have in the > > standard, > > > > > what is a yang-data definition that represents some unspecified > > usage, > > > > > other than an instance document? > > > > > > > > We want to create a flexible solution for creating structures that can > > > > be used in other places than just self-contained instance document. > > > > One example is the error-info data (see subscribed-notifications). > > > > > > > > > Why is this any different than a YANG grouping? > > > > > > > > ? We don't have these CLRs for groupings; the following is legal: > > > > > > > > grouping foo { > > > > leaf a { ... } > > > > leaf b { ... } > > > > } > > > > > > > > grouping bar { > > > > leaf b { ... } > > > > } > > > > > > > > > > > > It is up to the user of the grouping to ensure it is used in a way so > > > > that the result is legal. I think yang-data should work the same > > > > way. > > > > > > > > > > > > > > > > > > We don't need yang-data to be another way to define a grouping, because > > > we already have grouping-stmt. > > > > I agree. At some point someone suggested "uses-yang-data", I think we > > both agreed that this was a bad idea. > > > > > We don't need to re-invent another collection of data-def-stmts that are > > not > > > instantiated as data nodes automatically. Any place you could use > > yang-data > > > for this purpose, you could use a grouping instead. > > > > I'm not sure what you are trying to say. Are you suggesting that we > > don't need yang-data at all? > > > > > > I do not understand the need for a yang-data structure that represents data > that can be instantiated anywhere and everywhere. AFAIK noone is proposing that. > I do not want to break > existing tools that expect sibling data nodes in the same module namespace > to > be unique local-names. > > I would rather stick with the yang-data in RFC 8040 than introduce a new > extension > with no restrictions. Standard YANG extensions should be interoperable and > have > a clear purpose. Of course. > If we do not need to define what a YANG extension does in > a way that can be observed somehow, then it does not need to be a standard. Agreed. Not sure how any of this helps with the original issue though. /martin > > > > > /martin > > > > > Andy > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > I do not see any need for the other form since all functionality > > can > > > > be > > > > > > > achieved with a grouping and a proprietary YANG extension. > > > > > > > > > > > > > > Kent // contributor > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" < > > > > > > > > netmod-bounces@ietf.org on behalf of andy@yumaworks.com> > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton < > > rwilton@cisco.com> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 16/04/2018 17:07, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton < > > rwilton@cisco.com> > > > > > > wrote: > > > > > > > > > > > > > > > > Don't groupings have a somewhat similar concern? > > > > > > > > > > > > > > > > E.g. if two groupings define the same data node name and are > > used > > > > at > > > > > > the > > > > > > > > same point then you would get a namespace clash, but YANG does > > not > > > > > > disallow > > > > > > > > the groupings: > > > > > > > > > > > > > > > > > > > > > > > > grouping foo_widget { > > > > > > > > > > > > > > > > leaf name { > > > > > > > > > > > > > > > > type string; > > > > > > > > > > > > > > > > description "Name of my foo widget"; > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > grouping bar_widget { > > > > > > > > > > > > > > > > leaf name { > > > > > > > > > > > > > > > > type string; > > > > > > > > > > > > > > > > description "Name of my bar widget"; > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > container all_widgets { > > > > > > > > > > > > > > > > uses foo_widget; > > > > > > > > > > > > > > > > uses bar_widget; > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > The principal difference here, is that the compiler can easily > > > > check > > > > > > and > > > > > > > > reject the conflict at the uses statements. > > > > > > > > > > > > > > > > Hence I think that it would be good if we could find a > > solution for > > > > > > > > yang-data-ext that doesn't not require all root yang-data > > nodes to > > > > be > > > > > > > > unique, since that feels somewhat clunky. I.e. my preference > > is to > > > > > > keep > > > > > > > > them less restrictive, as Martin has proposed, if this is > > feasible. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is not clunky that 2 top-level YANG data nodes in the same > > > > module > > > > > > > > > > > > > > > > have unique names. This is simple and deterministic. > > > > > > > > > > > > > > > > This restriction has not been a problem so far. > > > > > > > > > > > > > > > > I agree with the statements above. > > > > > > > > > > > > > > > > But it is not clear to me that yang-data-ext is really defining > > > > new top > > > > > > > > level data nodes that are part of the same tree/namespace as > > the > > > > > > > > configuration/state nodes. In Martin's examples they were used > > > > within > > > > > > > > RPCs, and it the forcing the names to be unique in that context > > > > that I > > > > > > > > think would be clunky. E.g. in Martin's example forcing > > different > > > > > > names > > > > > > > > for "reason" and "user-info" doesn't seem to be helpful. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The yang-data statement has to define the context or new > > abstract > > > > > > > > namespace, > > > > > > > > > > > > > > > > or whatever this hack is called. > > > > > > > > > > > > > > > > Perhaps. I think that this depends on how they are used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The yang-data statement has to specify the expansion point, or > > > > > > > > > > > > > > > > at least specify that it is or is not the top-level. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yang-data top/name1 { > > > > > > > > > > > > > > > > container mydata; > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > where context is something like "top" or "error-info", etc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is trivial to use groupings if the same set of nodes needs > > to be > > > > > > used > > > > > > > > in different contexts: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > yang-data error-info/name1 { > > > > > > > > > > > > > > > > container mydata; > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Only the context named "top" is restricted to a resulting > > > > > > single-container > > > > > > > > > > > > > > > > and cannot have duplicate names. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is OK: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > x:yang-data error-info/my-error1 { > > > > > > > > > > > > > > > > leaf reason {} > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > x:yang-data error-info/my-error2 { > > > > > > > > > > > > > > > > leaf reason {} > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could a fix for this be something along the lines of: > > > > > > > > - yang-data names must be unique amongst other top level data > > > > nodes > > > > > > > > within the module. > > > > > > > > - if yang-data extensions are used at the top level then their > > > > name > > > > > > must > > > > > > > > be used as a single top level container. > > > > > > > > - if a yang-data extension is used within another structure > > then > > > > the > > > > > > > > yang-data name is excluded, and the top level nodes defined in > > the > > > > > > > > yang-data definition are used .... > > > > > > > > > > > > > > > > > > > > > > > > Every tool that implements yang-data has to be able > > > > > > > > > > > > > > > > to interpret a yang-data statement exactly the same way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you want to reinvent XSD substitutionGroup, then do it > > right. > > > > > > > > > > > > > > > > I'm not familiar with them. From a quick read, I don't see how > > > > they > > > > > > are > > > > > > > > related to the problem that we are trying to solve here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A substitutionGroup allows a point int the schema to be > > identified > > > > by > > > > > > name. > > > > > > > > > > > > > > > > Different elements can be defined that match this name, which > > then > > > > can > > > > > > be > > > > > > > > > > > > > > > > used (like a YANG choice) at the specified schema point. > > > > > > > > > > > > > > > > (e.g. error-info above is like a substitutionGroup) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 16/04/2018 15:36, Andy Bierman wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am strongly opposed to this change because it breaks the > > rule in > > > > > > YANG 1..1 > > > > > > > > > > > > > > > > that there cannot be 2 sibling nodes defined in the same module > > > > > > namespace.. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IMO since any yang-data nodes are ALLOWED to be used at the > > > > top-level, > > > > > > > > > > > > > > > > then these top-level nodes cannot have conflicting names. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is very important when parsing an instance document that the > > > > > > instance > > > > > > > > data > > > > > > > > > > > > > > > > can be associated with the correct schema. This is not > > possible > > > > if the > > > > > > > > > > > > > > > > same top-level node has multiple yang-data nodes defined. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If one needs to define data that is not top-level, (1) use > > > > > > > > augment-yang-data > > > > > > > > > > > > > > > > or (2) use a different module. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund < > > mbj@tail-f.com> > > > > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned > > out > > > > that > > > > > > > > it is not clear what, if any, restrictions should be enforced > > for > > > > > > > > yang-data structures. Even among the authors we have different > > > > ideas > > > > > > > > for how this should work. > > > > > > > > > > > > > > > > Background: > > > > > > > > > > > > > > > > In 8040, the original yang-data extension had a restriction > > that > > > > said > > > > > > > > that a yang-data structure MUST have exactly one container, > > since > > > > it > > > > > > > > wouldn't be possible to have a yang-data structure in an XML > > > > instance > > > > > > > > document otherwise. > > > > > > > > > > > > > > > > Since people want to use yang-data structures in other places, > > this > > > > > > > > restriction was lifted in the new draft: > > > > > > > > > > > > > > > > There is no longer an assumption that a yang data structure > > can > > > > > > > > only be used as a top-level abstraction, instead of nested > > > > within > > > > > > > > some other data structure. > > > > > > > > > > > > > > > > > > > > > > > > With this in mind, here's a use case that I think we ought to > > > > support: > > > > > > > > > > > > > > > > rpc my-first-rpc { > > > > > > > > description > > > > > > > > "Bla bla... > > > > > > > > If an error occurs, will contain an > > instance of > > > > > > > > the yang-data structure 'my-first-rpc-error-info'."; > > > > > > > > ... > > > > > > > > } > > > > > > > > > > > > > > > > yang-data my-first-rpc-error-info { > > > > > > > > leaf reason { ... } > > > > > > > > container user-info { ... } > > > > > > > > } > > > > > > > > > > > > > > > > rpc my-second-rpc { > > > > > > > > description > > > > > > > > "Bla bla... > > > > > > > > If an error occurs, will contain an > > instance of > > > > > > > > the yang-data structure 'my-second-rpc-error-info'."; > > > > > > > > ... > > > > > > > > } > > > > > > > > > > > > > > > > yang-data my-second-rpc-error-info { > > > > > > > > leaf reason { ... } > > > > > > > > leaf important-url { ... } > > > > > > > > } > > > > > > > > > > > > > > > > (maybe in the future we could even have a YANG extension > > statement > > > > to > > > > > > > > formalize the description: > > > > > > > > > > > > > > > > rpc my-first-rpc { > > > > > > > > ... > > > > > > > > opx:error-info-structure my-first-rpc-error-info; > > > > > > > > } > > > > > > > > > > > > > > > > but this is not point now.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I see no reason to reinvent the grouping-stmt. > > > > > > > > > > > > > > > > You could easily say opx:error-info-structure argument is a > > > > grouping > > > > > > name > > > > > > > > > > > > > > > > as it is a yang-data name. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the example above, note that the leaf "reason" is present in > > > > both > > > > > > > > structures. IMO this is not a problem, since these structures > > are > > > > > > > > used in different contexts. > > > > > > > > > > > > > > > > My point is that I think we should impose as few restrictions > > as > > > > > > > > possible to the yang-data extension. It should be up to the > > user > > > > of > > > > > > > > yang-data to ensure that the structure is defined in such a > > way so > > > > > > > > that it can be used properly. For example, a structure that is > > > > > > > > supposed to describe an XML instance document cannot define two > > > > leafs > > > > > > > > at the top level. > > > > > > > > > > > > > > > > If the WG agrees with what I wrote above, we need to change the > > > > > > > > augment-yang-data extension so that you would write for > > example: > > > > > > > > > > > > > > > > yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info > > { > > > > > > > > ... > > > > > > > > } > > > > > > > > > > > > > > > > Comments? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > netmod mailing list > > > > > > > > netmod@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c= > > > > > > HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r= > > > > > > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_ > > > > > > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM- > > > > > > 8lm7xpztYwDDLOxCM_8k&e=> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > netmod mailing list > > > > > > > > > > > > > > > > netmod@ietf.org > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod < > > https://urldefense. > > > > > > proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ > > > > > > listinfo_netmod&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > > > > ndb3voDTXcWzoCI&r= > > > > > > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_ > > > > > > yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM- > > > > > > 8lm7xpztYwDDLOxCM_8k&e=> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From nobody Mon Apr 23 12:51:14 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CAA12D93F for ; Mon, 23 Apr 2018 12:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AheHx1mSFDAt for ; Mon, 23 Apr 2018 12:51:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEB212D7E4 for ; Mon, 23 Apr 2018 12:51:11 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 4EB211AE018C; Mon, 23 Apr 2018 21:51:10 +0200 (CEST) Date: Mon, 23 Apr 2018 21:51:10 +0200 (CEST) Message-Id: <20180423.215110.441857992070858100.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180423165104.zi7g75tifhekmezh@elstar.local> References: <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> <20180423165104.zi7g75tifhekmezh@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 19:51:13 -0000 Hi, I am not sure what this statement tells us re. the issue in this email thread. /martin Juergen Schoenwaelder wrote: > On Sun, Apr 22, 2018 at 02:56:51PM +0200, Ladislav Lhotka wrote: > > > I am much more concerned with some of the post-1.1 features, also > > because YANG is now being updated in several directions without a > > clear vision. And another big problem is that YANG extensions are > > used for these changes, so we will probably end up with several > > different versions of YANG, although formally everything will be > > 1.1. > > I tend to agree. Ideally, we would carefully remove things from YANG > that did not meet the cost/benefit target (e.g., submodules), > reorganize definitions whenever possible (some NETCONF specific stuff > in the YANG specification should not be there, XML encoding may be > factored out) and incorporate new features (like yang-data) after we > have sufficient _experience_ to know that such new features will be > useful (which seems to be the case for yang-data). > > Yes, such iterations likely take 2 years at IETF speed but this kind > of maintenance cost/effort is likely the price to be paied for > something that is being used at a larger scale. > > Some people will say that the cost of a new language version is high. > (Well, when we did 1.1, some people said it will never be deployed.) > Anyway, not bumping the YANG version number but having instead several > (optional) language extensions is just hiding the version number > change under the carpet. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Apr 23 12:58:11 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04E012D7E4 for ; Mon, 23 Apr 2018 12:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMWe22t8Hjud for ; Mon, 23 Apr 2018 12:58:06 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64682126B6E for ; Mon, 23 Apr 2018 12:58:06 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id y15-v6so8685255lfj.0 for ; Mon, 23 Apr 2018 12:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4H43MuOENaF8QMThU9AyxcZw6jywt1FSgGjAelml4dk=; b=bn8ia2yiAf4MRGx2WjR+JPPS7QxXPXliraX/qkj4FKCNmHEHI9q7o7/TYWwRM4v8BN 5tCkTz2VESJOfT60w1F46v+x//jphLffQZdL/sbNuG1h2tTiqiKV1Aa9kSn2p4eYts5p Nz42Q8RxBBAmDY0SnBNm+rpNYXTjaGGlE9mpt8VeyW3vMiLHWTYlRBe578aeJwgVnv/A 8LYXxWxVtS5gjF2mTVm5UTalAJjRDX4IMYeguwUMWt/42OndQnxQUIeCm5KTf53/A1B9 OT5V9uHtl5jr4XhS1CXPvUMe+LDV6rlI56THqm5FrFOe5PTAjNn5CmOU4GrzzcuoYPru zh6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4H43MuOENaF8QMThU9AyxcZw6jywt1FSgGjAelml4dk=; b=scZo3RhR7TWEPtLngSd9sInVVukYi6Ac8PXoN111VXn7zxvha7R25PLEFgNBAaBQRM GrUMDi1wHwlVyeBDi05yS6Cq9Oe9pjY0ep9PjqYK88nDc+rHLpNS7VMFyeCxfOzrpgx1 JbFbwBWI5IjJNHQQmcK8SHGznqZfkJqCtNM5/QiS2IazOQPEZtgNAmKAsQNt5BPL1o14 kRpUTBk1ub62Awcx/Rc3eaURKnj/f7b4rjE165VblrJU8SlFFt/zTT1X9hjgHIHBOgc0 Cm/Ibqn8VtxCoxGg1pcQDuiMJam/Men7fzeaNPVJ4Tcc7mACYeUnVqcM7vpcR9fjl72a 12hQ== X-Gm-Message-State: ALQs6tBOxuQ6sY7BoGzw3W9pr9EZ6abGOwVLhyaU5GTQvvHYxhh0ekD6 znCAvhN2AK1h+ir86GcXkefWlCRCMzd9Maeb3aBMkw== X-Google-Smtp-Source: AIpwx4+3qLpMZFIp09V9loIpeI1I7GG9R1NNN1FtJRFrBwrKHcWC//Ir2xCWydLsK93qWf2E8mwsjkui0RNYG8JLfms= X-Received: by 10.46.151.206 with SMTP id m14mr15400780ljj.102.1524513484591; Mon, 23 Apr 2018 12:58:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 12:58:03 -0700 (PDT) In-Reply-To: <20180423.214923.1209533731960312602.mbj@tail-f.com> References: <20180423.132830.1432860273167614403.mbj@tail-f.com> <20180423.214923.1209533731960312602.mbj@tail-f.com> From: Andy Bierman Date: Mon, 23 Apr 2018 12:58:03 -0700 Message-ID: To: Martin Bjorklund Cc: Kent Watsen , NetMod WG Content-Type: multipart/alternative; boundary="883d24f22e14b463b3056a89747e" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 19:58:09 -0000 --883d24f22e14b463b3056a89747e Content-Type: text/plain; charset="UTF-8" > .... > > > > I do not understand the need for a yang-data structure that represents > data > > that can be instantiated anywhere and everywhere. > > AFAIK noone is proposing that. > > > I do not want to break > > existing tools that expect sibling data nodes in the same module > namespace > > to > > be unique local-names. > > > > I would rather stick with the yang-data in RFC 8040 than introduce a new > > extension > > with no restrictions. Standard YANG extensions should be interoperable > and > > have > > a clear purpose. > > Of course. > > > If we do not need to define what a YANG extension does in > > a way that can be observed somehow, then it does not need to be a > standard. > > Agreed. > > Not sure how any of this helps with the original issue though. > > You proposed that duplicate nodes were OK: module X { prefix x; x:yang-data A { list foo { ... } } x:yang-data B { container foo { ... } } } I do not want to allow any duplicates. There are no encoding and parsing rules for instance data that support this sort of duplicate. yang-data definitions define conceptual data nodes (e.g, /x:foo) Only one data-def-stmt (in yang-data or otherwise) can define a data node /x:foo. The descriptive names for the yang-data (A or B) do not define namespaces. > /martin > > Andy --883d24f22e14b463b3056a89747e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=
....
>
> I do not understand the need for a yang-data structure that represents= data
> that can be instantiated anywhere and everywhere.

AFAIK noone is proposing that.

> I do not want to break
> existing tools that expect sibling data nodes in the same module names= pace
> to
> be unique local-names.
>
> I would rather stick with the yang-data in RFC 8040 than introduce a n= ew
> extension
> with no restrictions.=C2=A0 Standard YANG extensions should be interop= erable and
> have
> a clear purpose.

Of course.

> If we do not need to define what a YANG extension does in
> a way that can be observed somehow, then it does not need to be a stan= dard.

Agreed.

Not sure how any of this helps with the original issue though.



You proposed that dupli= cate nodes were OK:

module X {
prefix x;=

x:yang-data A {
=C2=A0 =C2=A0list foo {= ... }
}

x:yang-data B {
=C2= =A0 container foo { ... }
}

}
=

I do not want to allow any duplicates.
<= div>There are no encoding and parsing rules for instance data
tha= t support this sort of duplicate.

yang-data defini= tions define conceptual data nodes (e.g, /x:foo)
Only one data-de= f-stmt (in yang-data or otherwise) can define a data node /x:foo.
The descriptive names for the yang-data (A or B) do not define namespaces.=



/martin

=C2=A0
Andy

=
--883d24f22e14b463b3056a89747e-- From nobody Mon Apr 23 13:08:20 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918F712D810 for ; Mon, 23 Apr 2018 13:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jioAVy6qBdVx for ; Mon, 23 Apr 2018 13:08:17 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D226512D945 for ; Mon, 23 Apr 2018 13:08:16 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 2078C1AE018C; Mon, 23 Apr 2018 22:08:16 +0200 (CEST) Date: Mon, 23 Apr 2018 22:08:15 +0200 (CEST) Message-Id: <20180423.220815.526647366558506966.mbj@tail-f.com> To: andy@yumaworks.com Cc: kwatsen@juniper.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180423.214923.1209533731960312602.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 20:08:18 -0000 Andy Bierman wrote: > > .... > > > > > > I do not understand the need for a yang-data structure that represents > > data > > > that can be instantiated anywhere and everywhere. > > > > AFAIK noone is proposing that. > > > > > I do not want to break > > > existing tools that expect sibling data nodes in the same module > > namespace > > > to > > > be unique local-names. > > > > > > I would rather stick with the yang-data in RFC 8040 than introduce a new > > > extension > > > with no restrictions. Standard YANG extensions should be interoperable > > and > > > have > > > a clear purpose. > > > > Of course. > > > > > If we do not need to define what a YANG extension does in > > > a way that can be observed somehow, then it does not need to be a > > standard. > > > > Agreed. > > > > Not sure how any of this helps with the original issue though. > > > > > > You proposed that duplicate nodes were OK: > > module X { > prefix x; > > x:yang-data A { > list foo { ... } > } > > x:yang-data B { > container foo { ... } > } > > } > > > I do not want to allow any duplicates. Yes, I got that. > There are no encoding and parsing rules for instance data > that support this sort of duplicate. This is not correct, as I have demonstrated earlier, and I think you also accepted; if different structures are defined for different rpcs' error-infos, then these structures can have the same child node names. I think that we have to agree on the basics before disussing solutions: 1) Should we do anything at all? (i.e., keep using yang-data in RFC 8040) 2) Should we define structures that only can be used in standalone instance documents? (i.e., *more* restrictive than yang-data in RFC 8040) 3) Should we define structures that can be used in standalone instance documents, error-info contents, and other places that we might not know right now? (i.e., *less* restrictive than yang-data in RFC 8040) Since the current draft says: The "yang-data" extension statement from RFC 8040 [RFC8040] is defined for this purpose, however it is limited in its functionality. The intended use of the "yang-data" extension is to model all or part of a protocol message, such as the "errors" definition in ietf- restconf.yang [RFC8040], or the contents of a file. However, protocols are often layered such that the header or payload portions of the message can be extended by external documents. The YANG statements that model a protocol need to support this extensibility that is already found in that protocol. I thought we are doing (3). /martin > yang-data definitions define conceptual data nodes (e.g, /x:foo) > Only one data-def-stmt (in yang-data or otherwise) can define a data node > /x:foo. > The descriptive names for the yang-data (A or B) do not define namespaces. > > > > > /martin > > > > > Andy From nobody Mon Apr 23 13:58:57 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461E612D95A for ; Mon, 23 Apr 2018 13:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAafNQliBs_7 for ; Mon, 23 Apr 2018 13:58:53 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FCF12D957 for ; Mon, 23 Apr 2018 13:58:53 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id j68-v6so16994288lfg.13 for ; Mon, 23 Apr 2018 13:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=OTTJhRyRbYRg3iVDidQovehUQ3ZR1QhBdDnYQAZ7kiM=; b=1C0U9s1LIYoKCBer6544G+XYcVf9U8EEFjFSZnqwpmXdYTrY1tK+n8Z14iZcBiFktz wuPxwupl2ONDBxGU7zHlk+n+1fxHp14rsVyeQI+LgPCV0A/yiTrVGh69FAPfN5GeFA15 u9bQY1wxj7tB17H08NNl/1+vVXepiaAox7OFI33gG3apn9zdhFDVDFDfb/a67Ua3aPpx AcB4/PvdvXOGfLYxBoI2EaD23OPoo6LdtXOqOQv8nZLfX90AuD7CihL/6Vb/a0EGPArt nihLR4Iv7n/xbunuX7mBRY4tnEpj+Bo4GlgpePwBz0yn0H1ANfSmeyNu9P1xfXvFt23U KhzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=OTTJhRyRbYRg3iVDidQovehUQ3ZR1QhBdDnYQAZ7kiM=; b=ILA41uy8tPQ5899kCiPYmhwE4JmiMX2qQHZI2yUDQuDiTIywSKQBHucwEIzmzpYS1e HMu8F/n1sScFlOhm/PzZCm+jc+2CUPs74ofLvI6HWpiCIRrSnYbHiWmjUOV0y481J+GG a3eDSkSR08Az0CUNj7LfkGcjtMKTWp74cXAiiyFcatYxnz1p9tAYOWIuUJvOV75DLCOO lP9Dq4tCzbVSutbUmapT/CYB9WMxECmRNWsM33esrTiTcbJlQJLAEJD5wUVW+pjIM18X XZvv73a86coFboHiad7C3UOpdrWfPykt6KQTWjyQcI/5ZaHtiSjgAeUhwucHyzrCXl6C 7L0g== X-Gm-Message-State: ALQs6tAmQD5EurvVJfSKWOhUsWgaW4yMO2IiGy8lcR53OcIW2BgQxFAO 3Qt+mLyCL6SsO0D+pLkfa4xUqRRByarCNYG/2ddeOA== X-Google-Smtp-Source: AB8JxZp0DnN+iR59v67x0Pwfy/B0NAk8jnpuCqmhetZENJdOwM9fxGhHj9EJ45Od2D5FiyXD9oxicUYFjGeLcjjLPw0= X-Received: by 2002:a19:a087:: with SMTP id j129-v6mr9595562lfe.101.1524517131364; Mon, 23 Apr 2018 13:58:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 13:58:50 -0700 (PDT) In-Reply-To: <20180423173636.fx63befibcc4vhmh@elstar.local> References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423173636.fx63befibcc4vhmh@elstar.local> From: Andy Bierman Date: Mon, 23 Apr 2018 13:58:50 -0700 Message-ID: To: Juergen Schoenwaelder , Robert Varga , Ladislav Lhotka , NetMod WG Content-Type: multipart/alternative; boundary="00000000000011c1ff056a8a4e07" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 20:58:56 -0000 --00000000000011c1ff056a8a4e07 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 23, 2018 at 10:36 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Apr 23, 2018 at 07:18:38PM +0200, Robert Varga wrote: > > On 23/04/18 18:51, Juergen Schoenwaelder wrote: > > > Some people will say that the cost of a new language version is high. > > > (Well, when we did 1.1, some people said it will never be deployed.) > > > Anyway, not bumping the YANG version number but having instead several > > > (optional) language extensions is just hiding the version number > > > change under the carpet. > > > > Not quite, as extensions allow for modular/incremental evolution, as an > > implementer I do not have to go through a long development cycle where I > > need to rewire language aspects just to get the features my users need > > for their models... > > Once we standardize extensions (and this is what I am talking about), > we better make sure that the whole stays consistent. Otherwise, we > will end up with patchwork where all the patches may work in isolation > but sooner or later they will fall apart when you look at all the > possible combinations. > > I am in favour of managing a clean definition of the core of the YANG > language instead of creating patchwork. It is great if people create > and prototype new extensions but once such extensions are considered > to be ready for general use, we should roll them into the core (and > remove any cruft from the core at the same time). > > I agree with your concerns. If the intent is that a YANG extension is optional, then its semantics have to be well-scoped so that tools really can skip over the extension without any problems. If we create standard extensions that standard YANG 1.1 modules use, then this can become an unofficial add-on to YANG 1.1. (e.g. annotation could already be considered as such) /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000011c1ff056a8a4e07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 23, 2018 at 10:36 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Apr 23, 2018 at 07:18:38PM +0200, Robert Va= rga wrote:
> On 23/04/18 18:51, Juergen Schoenwaelder wrote:
> > Some people will say that the cost of a new language version is h= igh.
> > (Well, when we did 1.1, some people said it will never be deploye= d.)
> > Anyway, not bumping the YANG version number but having instead se= veral
> > (optional) language extensions is just hiding the version number<= br> > > change under the carpet.
>
> Not quite, as extensions allow for modular/incremental evolution, as a= n
> implementer I do not have to go through a long development cycle where= I
> need to rewire language aspects just to get the features my users need=
> for their models...

Once we standardize extensions (and this is what I am talking about),
we better make sure that the whole stays consistent. Otherwise, we
will end up with patchwork where all the patches may work in isolation
but sooner or later they will fall apart when you look at all the
possible combinations.

I am in favour of managing a clean definition of the core of the YANG
language instead of creating patchwork. It is great if people create
and prototype new extensions but once such extensions are considered
to be ready for general use, we should roll them into the core (and
remove any cruft from the core at the same time).


I agree with your concerns.
If the intent = is that a YANG extension is optional, then its semantics have
to = be well-scoped so that tools really can skip over the extension without any= problems.
If we create standard extensions that standard YANG 1.= 1 modules use, then this can
become an unofficial add-on to YANG = 1.1. (e.g. annotation could already be considered as such)



/js


Andy
=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--00000000000011c1ff056a8a4e07-- From nobody Mon Apr 23 16:04:11 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66053126FDC; Mon, 23 Apr 2018 16:04:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: netmod-chairs@ietf.org, ibagdona@gmail.com, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152452464936.28891.13863536832256595509.idtracker@ietfa.amsl.com> Date: Mon, 23 Apr 2018 16:04:09 -0700 Archived-At: Subject: [netmod] netmod - New Meeting Session Request for IETF 102 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 23:04:09 -0000 A new meeting session request has just been submitted by Lou Berger, a Chair of the netmod working group. --------------------------------------------------------- Working Group Name: Network Modeling Area Name: Operations and Management Area Session Requester: Lou Berger Number of Sessions: 2 Length of Session(s): 1.5 Hours, 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: netconf Second Priority: teas i2rs anima rtgwg Third Priority: saag People who must be present: Lou Berger Joel Jaeggli Benoit Claise Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Apr 24 01:30:25 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC611270AC for ; Tue, 24 Apr 2018 01:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK1bG20134Vu for ; Tue, 24 Apr 2018 01:30:22 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF46B126DEE for ; Tue, 24 Apr 2018 01:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11491; q=dns/txt; s=iport; t=1524558622; x=1525768222; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=J5eCz4iY0PlIzPO3brKqro7ZpvcRxG5Ch6pimwosHMU=; b=bqZI2IsvtkiC8JM84zoBkOJl4x7GU1FY1pQHo4nksKF9PgMzyTNJ4H/R smsmUAk6ZnjgGW89OaGXJ4021ztvfjxZaT6Y7bYN9iZr5nnRzrimfR0J5 6kVViKxpznqPt+iStTyyzXULjvw1rfFdw+MTd+4t3rViA9If5uRXQwXkI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAQAB6t5a/xbLJq1ZAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDFASBDBdjKINqiGCNZSmBD44UhG6BeAsYAQqDEXFGAoM?= =?us-ascii?q?RNhYBAgEBAQEBAQJsHAyFIwEBAQMBASFLGQIJEggnAwICGwwfEQYBDAYCAQG?= =?us-ascii?q?FCw+KY5tBghwfg1oBXoNygjQFBYlbP4EygWlRgz8BAYIBJoI5glQCh1OJGIc?= =?us-ascii?q?MCIE1jQUGAodIhQSLDYUhgSUjCCmBUjMaCBsVO4JDgXAwF3oBCYJ0hGGFCAE?= =?us-ascii?q?2PjCQQgEB?= X-IronPort-AV: E=Sophos;i="5.49,321,1520899200"; d="scan'208,217";a="3373615" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2018 08:30:20 +0000 Received: from [10.63.23.54] (dhcp-ensft1-uk-vla370-10-63-23-54.cisco.com [10.63.23.54]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w3O8UHsF012939; Tue, 24 Apr 2018 08:30:19 GMT To: Andy Bierman , Juergen Schoenwaelder , Robert Varga , Ladislav Lhotka , NetMod WG References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423173636.fx63befibcc4vhmh@elstar.local> From: Robert Wilton Message-ID: <30689299-e689-0942-8841-8533e1847c4a@cisco.com> Date: Tue, 24 Apr 2018 09:30:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B7AD1125BABAB1BD9FB69DCB" Content-Language: en-US Archived-At: Subject: [netmod] Extensions vs new YANG versions [was Re: yang-data-ext issues] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 08:30:24 -0000 This is a multi-part message in MIME format. --------------B7AD1125BABAB1BD9FB69DCB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit [Renaming the thread because this doesn't seem to be directly applicable to the yang-data extension.] I think that extensions are great in the sense that they allow YANG to evolve more quickly without requiring a fork lift version upgrade that may take a long time to produce. I agree that all standard defined extensions should cleanly inter-operate with each other. I also think that it is useful to periodically define new versions of YANG that fold back in all the extensions that have been successfully and are widely deployed.  And also to deprecate/obsolete stuff that hasn't worked well. For me, the interesting question is about namespaces when those extensions are incorporated back into a new version of YANG: - Does it just keep the extension prefix that the extension module was originally defined in? - Or does the extension get folded into core of the YANG language and no extension prefix is used any more? - Or does the extension get supported both with/without the extension namespace prefix? Thanks, Rob On 23/04/2018 21:58, Andy Bierman wrote: > > > On Mon, Apr 23, 2018 at 10:36 AM, Juergen Schoenwaelder > > wrote: > > On Mon, Apr 23, 2018 at 07:18:38PM +0200, Robert Varga wrote: > > On 23/04/18 18:51, Juergen Schoenwaelder wrote: > > > Some people will say that the cost of a new language version > is high. > > > (Well, when we did 1.1, some people said it will never be > deployed.) > > > Anyway, not bumping the YANG version number but having instead > several > > > (optional) language extensions is just hiding the version number > > > change under the carpet. > > > > Not quite, as extensions allow for modular/incremental > evolution, as an > > implementer I do not have to go through a long development cycle > where I > > need to rewire language aspects just to get the features my > users need > > for their models... > > Once we standardize extensions (and this is what I am talking about), > we better make sure that the whole stays consistent. Otherwise, we > will end up with patchwork where all the patches may work in isolation > but sooner or later they will fall apart when you look at all the > possible combinations. > > I am in favour of managing a clean definition of the core of the YANG > language instead of creating patchwork. It is great if people create > and prototype new extensions but once such extensions are considered > to be ready for general use, we should roll them into the core (and > remove any cruft from the core at the same time). > > > I agree with your concerns. > If the intent is that a YANG extension is optional, then its semantics > have > to be well-scoped so that tools really can skip over the extension > without any problems. > If we create standard extensions that standard YANG 1.1 modules use, > then this can > become an unofficial add-on to YANG 1.1. (e.g. annotation could > already be considered as such) > > > > /js > > > Andy > > -- > Juergen Schoenwaelder           Jacobs University Bremen gGmbH > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany > Fax:   +49 421 200 3103          > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------B7AD1125BABAB1BD9FB69DCB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

[Renaming the thread because this doesn't seem to be directly applicable to the yang-data extension.]

I think that extensions are great in the sense that they allow YANG to evolve more quickly without requiring a fork lift version upgrade that may take a long time to produce.

I agree that all standard defined extensions should cleanly inter-operate with each other.

I also think that it is useful to periodically define new versions of YANG that fold back in all the extensions that have been successfully and are widely deployed.  And also to deprecate/obsolete stuff that hasn't worked well.

For me, the interesting question is about namespaces when those extensions are incorporated back into a new version of YANG:
- Does it just keep the extension prefix that the extension module was originally defined in?
- Or does the extension get folded into core of the YANG language and no extension prefix is used any more?
- Or does the extension get supported both with/without the extension namespace prefix?

Thanks,
Rob


On 23/04/2018 21:58, Andy Bierman wrote:


On Mon, Apr 23, 2018 at 10:36 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Apr 23, 2018 at 07:18:38PM +0200, Robert Varga wrote:
> On 23/04/18 18:51, Juergen Schoenwaelder wrote:
> > Some people will say that the cost of a new language version is high.
> > (Well, when we did 1.1, some people said it will never be deployed.)
> > Anyway, not bumping the YANG version number but having instead several
> > (optional) language extensions is just hiding the version number
> > change under the carpet.
>
> Not quite, as extensions allow for modular/incremental evolution, as an
> implementer I do not have to go through a long development cycle where I
> need to rewire language aspects just to get the features my users need
> for their models...

Once we standardize extensions (and this is what I am talking about),
we better make sure that the whole stays consistent. Otherwise, we
will end up with patchwork where all the patches may work in isolation
but sooner or later they will fall apart when you look at all the
possible combinations.

I am in favour of managing a clean definition of the core of the YANG
language instead of creating patchwork. It is great if people create
and prototype new extensions but once such extensions are considered
to be ready for general use, we should roll them into the core (and
remove any cruft from the core at the same time).


I agree with your concerns.
If the intent is that a YANG extension is optional, then its semantics have
to be well-scoped so that tools really can skip over the extension without any problems.
If we create standard extensions that standard YANG 1.1 modules use, then this can
become an unofficial add-on to YANG 1.1. (e.g. annotation could already be considered as such)



/js


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

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--------------B7AD1125BABAB1BD9FB69DCB-- From nobody Tue Apr 24 02:02:00 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D461D124BFA for ; Tue, 24 Apr 2018 02:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grSTleYKnA4w for ; Tue, 24 Apr 2018 02:01:57 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CE712025C for ; Tue, 24 Apr 2018 02:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4155; q=dns/txt; s=iport; t=1524560517; x=1525770117; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=zTdTEEhTDKlkfBiwkDPjZXDLIpjqLzAvxEg/IVuPK4E=; b=mI7WvAuppG4xVvao4Ng/tsEo6lyu891/vTsRRUJuxhR/HN++gqFz9LHq Yj2MUYLLvcoTCS9C30j+0+hlz4+Sfp1w9/Lod8A8hdOXGm3N4Rn1bPepJ L/iesNFS9lhHA5roOtrwZ9ZH1tgKiPy1YU6ilyq2ttmfr/DBrCuS9NmHh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAAAA8t5a/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQkeiiDaogCXo1lCCGBD5MCgXgLGAuEAkYCgxE0GAECAQE?= =?us-ascii?q?BAQEBAmwcDIUiAQEBAQIBAQEhDwEFNgsQCw4KAgImAgInMAYBDAYCAQEXhGw?= =?us-ascii?q?ID6YdghyEWINygjQFgQmIVz+BMgyCXIMRAQGBOYMnglQCl3cIjjoGh0qFBIs?= =?us-ascii?q?NhSGBJRw4gVIzGggbFTuCQ4sQhT8+MI18gkYBAQ?= X-IronPort-AV: E=Sophos;i="5.49,322,1520899200"; d="scan'208";a="3374186" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2018 09:01:54 +0000 Received: from [10.63.23.54] (dhcp-ensft1-uk-vla370-10-63-23-54.cisco.com [10.63.23.54]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w3O91seg019241; Tue, 24 Apr 2018 09:01:54 GMT To: Martin Bjorklund , andy@yumaworks.com Cc: netmod@ietf.org References: <20180423.214923.1209533731960312602.mbj@tail-f.com> <20180423.220815.526647366558506966.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Tue, 24 Apr 2018 10:01:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180423.220815.526647366558506966.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 09:01:59 -0000 On 23/04/2018 21:08, Martin Bjorklund wrote: > Andy Bierman wrote: >>> .... >>>> I do not understand the need for a yang-data structure that represents >>> data >>>> that can be instantiated anywhere and everywhere. >>> AFAIK noone is proposing that. >>> >>>> I do not want to break >>>> existing tools that expect sibling data nodes in the same module >>> namespace >>>> to >>>> be unique local-names. >>>> >>>> I would rather stick with the yang-data in RFC 8040 than introduce a new >>>> extension >>>> with no restrictions. Standard YANG extensions should be interoperable >>> and >>>> have >>>> a clear purpose. >>> Of course. >>> >>>> If we do not need to define what a YANG extension does in >>>> a way that can be observed somehow, then it does not need to be a >>> standard. >>> >>> Agreed. >>> >>> Not sure how any of this helps with the original issue though. >>> >>> >> You proposed that duplicate nodes were OK: >> >> module X { >> prefix x; >> >> x:yang-data A { >> list foo { ... } >> } >> >> x:yang-data B { >> container foo { ... } >> } >> >> } >> >> >> I do not want to allow any duplicates. > Yes, I got that. > >> There are no encoding and parsing rules for instance data >> that support this sort of duplicate. > This is not correct, as I have demonstrated earlier, and I think you > also accepted; if different structures are defined for different rpcs' > error-infos, then these structures can have the same child node names. > > I think that we have to agree on the basics before disussing > solutions: > > 1) Should we do anything at all? > > (i.e., keep using yang-data in RFC 8040) There is also an option 1(b) which is to move the current yang-data definition on RFC 8040 into it's own document, just to fix the references issue. > > 2) Should we define structures that only can be used in > standalone instance documents? > > (i.e., *more* restrictive than yang-data in RFC 8040) I don't think that we should define something more restrictive that yang-data in RFC 8040. > > 3) Should we define structures that can be used in standalone > instance documents, error-info contents, and other places that > we might not know right now? > > (i.e., *less* restrictive than yang-data in RFC 8040) I don't know about this one because I'm not sure that I understand the problem space well enough. For some of the categories above would a choice statement + groupings works just as well as a yang-data extension? A different thought, one that has probably been considered before:  - Could all yang data definitions be defined using groupings instead.  I.e. a grouping without any associated uses statements.  - Perhaps an extra statement under the grouping could be used to indicate whether the grouping represents a yang data definition. Thanks, Rob > > > Since the current draft says: > > The "yang-data" extension statement from RFC > 8040 [RFC8040] is defined for this purpose, however it is limited in > its functionality. > > The intended use of the "yang-data" extension is to model all or part > of a protocol message, such as the "errors" definition in ietf- > restconf.yang [RFC8040], or the contents of a file. However, > protocols are often layered such that the header or payload portions > of the message can be extended by external documents. The YANG > statements that model a protocol need to support this extensibility > that is already found in that protocol. > > > I thought we are doing (3). > > > > /martin > > > >> yang-data definitions define conceptual data nodes (e.g, /x:foo) >> Only one data-def-stmt (in yang-data or otherwise) can define a data node >> /x:foo. >> The descriptive names for the yang-data (A or B) do not define namespaces. >> >> >> >>> /martin >>> >>> >> Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Apr 24 06:09:24 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF33127AD4 for ; Tue, 24 Apr 2018 06:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cyWJwMG_zPB for ; Tue, 24 Apr 2018 06:09:21 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A03E126C19 for ; Tue, 24 Apr 2018 06:09:21 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A08E44C7BD6D1 for ; Tue, 24 Apr 2018 14:09:16 +0100 (IST) Received: from DGGEMA404-HUB.china.huawei.com (10.3.20.45) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 24 Apr 2018 14:09:18 +0100 Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.62]) by DGGEMA404-HUB.china.huawei.com ([10.3.20.45]) with mapi id 14.03.0361.001; Tue, 24 Apr 2018 21:09:08 +0800 From: Rohit R Ranade To: "netmod@ietf.org" Thread-Topic: [netmod] Comments on draft-ietf-netconf-nmda-netconf-05 Thread-Index: AdPbx8ZmmFXO/JW6Snea5zZ5ApuR+g== Date: Tue, 24 Apr 2018 13:09:07 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B1E8D96@DGGEMA502-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.150.121] Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6B1E8D96DGGEMA502MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] Comments on draft-ietf-netconf-nmda-netconf-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 13:09:23 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A6B1E8D96DGGEMA502MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Please find some comments for the draft. 1. If "config-filter" leaf is not given for whether we can= add explicit text that both config=3Dtrue and config=3Dfalse nodes will be= selected. 2. In the YANG module description for "config-filter" , also it is no= t clear about what happens if the leaf is not given in filter. I feel bette= r we keep the style like RESTCONF RFC 8040 Section 4.8.1 , with "content" h= aving config/nonconfig/all 3. Regarding the "max-depth" parameter, I feel we should take the tex= t about how "depth" is calculated for each node from RESTCONF RFC from Sect= ion 4.8.2 and add it to this draft. What will be depth of parent keys which= are auto-selected when selecting on child nodes. Maybe some example regard= ing using of "max-depth" will be helpful. 4. For the filter mechanism, since there are 4 filters (fi= lter-spec and config-filter and max-depth and with-defaults), whether we ca= n mention that all these filters are AND'ed. Also whether there is a sugges= ted order to apply filter ? I think "max-depth" filter has to be applied la= st. Others maybe any order is OK. 5. negated-origin-filter : Regarding this I feel we can add a sentenc= e as to when user should use "negated-origin-filter" , as "origin-filter" a= lso can be used for this purpose. With Regards, Rohit R Ranade --_000_991B70D8B4112A4699D5C00DDBBF878A6B1E8D96DGGEMA502MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Please find some comments for t= he draft.  

 

1= .   &= nbsp;   If “config-filter” leaf is not= given for <get-data> whether we can add explicit text that both config=3Dtrue and config=3Dfalse nodes will be selected.

2= .   &= nbsp;   In the YANG module desc= ription for “config-filter” , also it is not clear about what h= appens if the leaf is not given in filter. I feel better we keep the style = like RESTCONF RFC 8040 Section 4.8.1 , wi= th “content” having  config/nonconfig/all

3= .   &= nbsp;   Regarding the “ma= x-depth” parameter, I feel we should take the text about how “d= epth” is calculated for each node from RESTCONF RFC from Section 4.8.= 2 and add it to this draft. What will be depth of parent keys which are auto-selected when selecting on child nodes. Maybe some example = regarding using of “max-depth” will be helpful.

4= .   &= nbsp;   For the <get-data>= ; filter mechanism, since there are 4 filters (filter-spec and config-filte= r and max-depth and with-defaults), whether we can mention that all these f= ilters are AND’ed. Also whether there is a suggested order to apply filter ? I think “max-depth” filter= has to be applied last. Others maybe any order is OK.

5= .   &= nbsp;   negated-origin-filter := Regarding this I feel we can add a sentence as to when user should use = 220;negated-origin-filter” , as “origin-filter” also can = be used for this purpose.

 

With Regards,=

Rohit R Ranade

 

 

--_000_991B70D8B4112A4699D5C00DDBBF878A6B1E8D96DGGEMA502MBXchi_-- From nobody Tue Apr 24 07:07:45 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D55C12D7F9 for ; Tue, 24 Apr 2018 07:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxJ-LWE7luFL for ; Tue, 24 Apr 2018 07:07:40 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5972512EA93 for ; Tue, 24 Apr 2018 07:07:33 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 433D31820159; Tue, 24 Apr 2018 16:13:14 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 2FD6A1820055; Tue, 24 Apr 2018 16:13:10 +0200 (CEST) From: Ladislav Lhotka To: Robert Wilton , Andy Bierman , Juergen Schoenwaelder , Robert Varga , NetMod WG In-Reply-To: <30689299-e689-0942-8841-8533e1847c4a@cisco.com> References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423173636.fx63befibcc4vhmh@elstar.local> <30689299-e689-0942-8841-8533e1847c4a@cisco.com> Mail-Followup-To: Robert Wilton , Andy Bierman , Juergen Schoenwaelder , Robert Varga , NetMod WG Date: Tue, 24 Apr 2018 16:07:30 +0200 Message-ID: <8736zksnod.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Extensions vs new YANG versions [was Re: yang-data-ext issues] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 14:07:44 -0000 Robert Wilton writes: > [Renaming the thread because this doesn't seem to be directly applicable= =20 > to the yang-data extension.] > > I think that extensions are great in the sense that they allow YANG to=20 > evolve more quickly without requiring a fork lift version upgrade that=20 > may take a long time to produce. This is of course a double-edged sword. In my view, extensions must not influence the resulting data model, and I thought the last paragraph in sec. 6.3.1 of RFC 6020 had been intended to mean exactly this. I would prefer to indicate experimental versions of YANG in the version string (e.g. as a topical branch), and use YANG extensions only for stuff that's outside the realm of data modelling. For example, the extension in NACM is perfectly OK because it is a hint for protocol operation and doesn't affect the schema in any way. > > I agree that all standard defined extensions should cleanly=20 > inter-operate with each other. > > I also think that it is useful to periodically define new versions of=20 > YANG that fold back in all the extensions that have been successfully=20 > and are widely deployed.=C2=A0 And also to deprecate/obsolete stuff that= =20 > hasn't worked well. Without a metamodel, it is difficult to avoid YANG becoming a kitchen sink. And what about extensions that won't make it into the new official version? For example, imagine that "openconfig:pattern" won't be accepted - would it really matter? The forked versions will continue to exist but they could still claim adherence to the IETF standard (which is what marketing departments love). Lada > > For me, the interesting question is about namespaces when those=20 > extensions are incorporated back into a new version of YANG: > - Does it just keep the extension prefix that the extension module was=20 > originally defined in? > - Or does the extension get folded into core of the YANG language and no= =20 > extension prefix is used any more? > - Or does the extension get supported both with/without the extension=20 > namespace prefix? > > Thanks, > Rob > > > On 23/04/2018 21:58, Andy Bierman wrote: >> >> >> On Mon, Apr 23, 2018 at 10:36 AM, Juergen Schoenwaelder=20 >> > > wrote: >> >> On Mon, Apr 23, 2018 at 07:18:38PM +0200, Robert Varga wrote: >> > On 23/04/18 18:51, Juergen Schoenwaelder wrote: >> > > Some people will say that the cost of a new language version >> is high. >> > > (Well, when we did 1.1, some people said it will never be >> deployed.) >> > > Anyway, not bumping the YANG version number but having instead >> several >> > > (optional) language extensions is just hiding the version number >> > > change under the carpet. >> > >> > Not quite, as extensions allow for modular/incremental >> evolution, as an >> > implementer I do not have to go through a long development cycle >> where I >> > need to rewire language aspects just to get the features my >> users need >> > for their models... >> >> Once we standardize extensions (and this is what I am talking about), >> we better make sure that the whole stays consistent. Otherwise, we >> will end up with patchwork where all the patches may work in isolati= on >> but sooner or later they will fall apart when you look at all the >> possible combinations. >> >> I am in favour of managing a clean definition of the core of the YANG >> language instead of creating patchwork. It is great if people create >> and prototype new extensions but once such extensions are considered >> to be ready for general use, we should roll them into the core (and >> remove any cruft from the core at the same time). >> >> >> I agree with your concerns. >> If the intent is that a YANG extension is optional, then its semantics=20 >> have >> to be well-scoped so that tools really can skip over the extension=20 >> without any problems. >> If we create standard extensions that standard YANG 1.1 modules use,=20 >> then this can >> become an unofficial add-on to YANG 1.1. (e.g. annotation could=20 >> already be considered as such) >> >> >> >> /js >> >> >> Andy >> >> --=20 >> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs= University Bremen gGmbH >> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring= 1 | 28759 Bremen | Germany >> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= https://www.jacobs-university.de/ >> > >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Apr 24 07:25:59 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F288012895E for ; Tue, 24 Apr 2018 07:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Uxkt62Nq4X2 for ; Tue, 24 Apr 2018 07:25:55 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9059C128954 for ; Tue, 24 Apr 2018 07:25:55 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id BA8581820157; Tue, 24 Apr 2018 16:31:36 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id B2C9E1820055; Tue, 24 Apr 2018 16:31:35 +0200 (CEST) From: Ladislav Lhotka To: Robert Varga , netmod@ietf.org In-Reply-To: References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <87h8oal7iu.fsf@nic.cz> <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> <20180423165104.zi7g75tifhekmezh@elstar.local> Mail-Followup-To: Robert Varga , netmod@ietf.org Date: Tue, 24 Apr 2018 16:25:57 +0200 Message-ID: <87zi1sr896.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 14:25:57 -0000 Robert Varga writes: > On 23/04/18 18:51, Juergen Schoenwaelder wrote: >> Some people will say that the cost of a new language version is high. >> (Well, when we did 1.1, some people said it will never be deployed.) >> Anyway, not bumping the YANG version number but having instead several >> (optional) language extensions is just hiding the version number >> change under the carpet. > > Not quite, as extensions allow for modular/incremental evolution, as an > implementer I do not have to go through a long development cycle where I > need to rewire language aspects just to get the features my users need > for their models... But what prevents you from forking YANG, indicating it in the "yang-version" string and implementing your new statements as built-ins? It is tempting to think about extensions as a magic for adding modular extensions but it breaks down as soon as such extensions interfere with the YANG core (with and each other, or both). Lada > > Regards, > Robert > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Apr 24 07:31:46 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA62C128954 for ; Tue, 24 Apr 2018 07:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nZuT55EL8Uu for ; Tue, 24 Apr 2018 07:30:09 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 352BA124205 for ; Tue, 24 Apr 2018 07:30:09 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 5E6921820157; Tue, 24 Apr 2018 16:35:50 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 1D9531820055; Tue, 24 Apr 2018 16:35:47 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org In-Reply-To: <20180423.215110.441857992070858100.mbj@tail-f.com> References: <6d5cd4e4257822e4a5c478dc934c5433428aff38.camel@nic.cz> <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423.215110.441857992070858100.mbj@tail-f.com> Mail-Followup-To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de, netmod@ietf.org Date: Tue, 24 Apr 2018 16:30:09 +0200 Message-ID: <87wowwr826.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 14:30:24 -0000 Martin Bjorklund writes: > Hi, > > I am not sure what this statement tells us re. the issue in this email > thread. It tells us that, in my view, the approach taken in this document is a bad idea. Lada > > > /martin > > > Juergen Schoenwaelder wrote: >> On Sun, Apr 22, 2018 at 02:56:51PM +0200, Ladislav Lhotka wrote: >> >> > I am much more concerned with some of the post-1.1 features, also >> > because YANG is now being updated in several directions without a >> > clear vision. And another big problem is that YANG extensions are >> > used for these changes, so we will probably end up with several >> > different versions of YANG, although formally everything will be >> > 1.1. >> >> I tend to agree. Ideally, we would carefully remove things from YANG >> that did not meet the cost/benefit target (e.g., submodules), >> reorganize definitions whenever possible (some NETCONF specific stuff >> in the YANG specification should not be there, XML encoding may be >> factored out) and incorporate new features (like yang-data) after we >> have sufficient _experience_ to know that such new features will be >> useful (which seems to be the case for yang-data). >> >> Yes, such iterations likely take 2 years at IETF speed but this kind >> of maintenance cost/effort is likely the price to be paied for >> something that is being used at a larger scale. >> >> Some people will say that the cost of a new language version is high. >> (Well, when we did 1.1, some people said it will never be deployed.) >> Anyway, not bumping the YANG version number but having instead several >> (optional) language extensions is just hiding the version number >> change under the carpet. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Apr 24 07:36:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E42512D874 for ; Tue, 24 Apr 2018 07:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3NJvkkto3qU for ; Tue, 24 Apr 2018 07:36:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 567AE12EA56 for ; Tue, 24 Apr 2018 07:36:04 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id BFC901AE0471; Tue, 24 Apr 2018 16:36:01 +0200 (CEST) Date: Tue, 24 Apr 2018 16:36:01 +0200 (CEST) Message-Id: <20180424.163601.648085760139600532.mbj@tail-f.com> To: lhotka@nic.cz Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <87wowwr826.fsf@nic.cz> References: <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423.215110.441857992070858100.mbj@tail-f.com> <87wowwr826.fsf@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 14:36:08 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Hi, > > > > I am not sure what this statement tells us re. the issue in this email > > thread. > > It tells us that, in my view, the approach taken in this document is a > bad idea. Do you mean that the WG shoud drop this document? And people that need yang-data should continue to use the version in 8040? Or that people that need yang-data do not have a valid use case and they should do something else? /martin > > Lada > > > > > > > /martin > > > > > > Juergen Schoenwaelder wrote: > >> On Sun, Apr 22, 2018 at 02:56:51PM +0200, Ladislav Lhotka wrote: > >> > >> > I am much more concerned with some of the post-1.1 features, also > >> > because YANG is now being updated in several directions without a > >> > clear vision. And another big problem is that YANG extensions are > >> > used for these changes, so we will probably end up with several > >> > different versions of YANG, although formally everything will be > >> > 1.1. > >> > >> I tend to agree. Ideally, we would carefully remove things from YANG > >> that did not meet the cost/benefit target (e.g., submodules), > >> reorganize definitions whenever possible (some NETCONF specific stuff > >> in the YANG specification should not be there, XML encoding may be > >> factored out) and incorporate new features (like yang-data) after we > >> have sufficient _experience_ to know that such new features will be > >> useful (which seems to be the case for yang-data). > >> > >> Yes, such iterations likely take 2 years at IETF speed but this kind > >> of maintenance cost/effort is likely the price to be paied for > >> something that is being used at a larger scale. > >> > >> Some people will say that the cost of a new language version is high. > >> (Well, when we did 1.1, some people said it will never be deployed.) > >> Anyway, not bumping the YANG version number but having instead several > >> (optional) language extensions is just hiding the version number > >> change under the carpet. > >> > >> /js > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > From nobody Tue Apr 24 07:43:27 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DE81289B0 for ; Tue, 24 Apr 2018 07:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci2klMDB6GOW for ; Tue, 24 Apr 2018 07:43:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2B67F127333 for ; Tue, 24 Apr 2018 07:43:25 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id CE7991AE0471; Tue, 24 Apr 2018 16:43:23 +0200 (CEST) Date: Tue, 24 Apr 2018 16:43:23 +0200 (CEST) Message-Id: <20180424.164323.134787755202916169.mbj@tail-f.com> To: lhotka@nic.cz Cc: nite@hq.sk, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <87zi1sr896.fsf@nic.cz> References: <20180423165104.zi7g75tifhekmezh@elstar.local> <87zi1sr896.fsf@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 14:43:27 -0000 Ladislav Lhotka wrote: > Robert Varga writes: > > > On 23/04/18 18:51, Juergen Schoenwaelder wrote: > >> Some people will say that the cost of a new language version is high. > >> (Well, when we did 1.1, some people said it will never be deployed.) > >> Anyway, not bumping the YANG version number but having instead several > >> (optional) language extensions is just hiding the version number > >> change under the carpet. > > > > Not quite, as extensions allow for modular/incremental evolution, as an > > implementer I do not have to go through a long development cycle where I > > need to rewire language aspects just to get the features my users need > > for their models... > > But what prevents you from forking YANG, indicating it in the > "yang-version" string and implementing your new statements as built-ins? > > It is tempting to think about extensions as a magic for adding modular > extensions but it breaks down as soon as such extensions interfere with > the YANG core (with and each other, or both). Sure, nothing new here. This is how the extension mechanism is designed. Do you feel that there are so many standard extensions that interfere with each other that we actually have a problem? I strongly agree that we need to be careful with standard extensions, and I strongly encourage vendors to not define extensions that interfere with YANG core (been there, done that, bad idea). In the case of yang-data, the fact is that it *is* used in standard models (in ways not originally anticipated), and vendors have similar proprietary extensions (we have a tailf:structure, and I think others have reported similar things). /martin From nobody Tue Apr 24 07:51:15 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A63128954 for ; Tue, 24 Apr 2018 07:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZQO_qukOa46 for ; Tue, 24 Apr 2018 07:51:06 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C2AED129C5D for ; Tue, 24 Apr 2018 07:51:05 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id CA3F31AE0471; Tue, 24 Apr 2018 16:51:04 +0200 (CEST) Date: Tue, 24 Apr 2018 16:51:04 +0200 (CEST) Message-Id: <20180424.165104.314256714668452461.mbj@tail-f.com> To: rwilton@cisco.com Cc: andy@yumaworks.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180423.220815.526647366558506966.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 14:51:14 -0000 Robert Wilton wrote: > = > = > On 23/04/2018 21:08, Martin Bjorklund wrote: > > Andy Bierman wrote: > >>> .... > >>>> I do not understand the need for a yang-data structure that repr= esents > >>> data > >>>> that can be instantiated anywhere and everywhere. > >>> AFAIK noone is proposing that. > >>> > >>>> I do not want to break > >>>> existing tools that expect sibling data nodes in the same module= > >>> namespace > >>>> to > >>>> be unique local-names. > >>>> > >>>> I would rather stick with the yang-data in RFC 8040 than introdu= ce a > >>>> new > >>>> extension > >>>> with no restrictions. Standard YANG extensions should be > >>>> interoperable > >>> and > >>>> have > >>>> a clear purpose. > >>> Of course. > >>> > >>>> If we do not need to define what a YANG extension does in > >>>> a way that can be observed somehow, then it does not need to be = a > >>> standard. > >>> > >>> Agreed. > >>> > >>> Not sure how any of this helps with the original issue though. > >>> > >>> > >> You proposed that duplicate nodes were OK: > >> > >> module X { > >> prefix x; > >> > >> x:yang-data A { > >> list foo { ... } > >> } > >> > >> x:yang-data B { > >> container foo { ... } > >> } > >> > >> } > >> > >> > >> I do not want to allow any duplicates. > > Yes, I got that. > > > >> There are no encoding and parsing rules for instance data > >> that support this sort of duplicate. > > This is not correct, as I have demonstrated earlier, and I think yo= u > > also accepted; if different structures are defined for different rp= cs' > > error-infos, then these structures can have the same child node nam= es. > > > > I think that we have to agree on the basics before disussing > > solutions: > > > > 1) Should we do anything at all? > > > > (i.e., keep using yang-data in RFC 8040) > There is also an option 1(b) which is to move the current yang-data > definition on RFC 8040 into it's own document, just to fix the > references issue. Sure, but I don't think it is worth the effort. > > 2) Should we define structures that only can be used in > > standalone instance documents? > > > > (i.e., *more* restrictive than yang-data in RFC 8040) > I don't think that we should define something more restrictive that > yang-data in RFC 8040. I agree. > > 3) Should we define structures that can be used in standalone > > instance documents, error-info contents, and other places th= at > > we might not know right now? > > > > (i.e., *less* restrictive than yang-data in RFC 8040) > I don't know about this one because I'm not sure that I understand th= e > problem space well enough. > = > For some of the categories above would a choice statement + groupings= > works just as well as a yang-data extension? Not sure what you mean, but before we had yang-data in 8040, people used something like this: module my-module { .... container foo { description "This is not really a real data node that is supposed to be instantiated in any datastore. Instead it is supposed to be the top-level node in an instance document that describes..."; } } By this is really a mis-use of YANG statements. Wrapping it in an extension solves that problem. = > A different thought, one that has probably been considered before: > =A0- Could all yang data definitions be defined using groupings > instead.=A0 I.e. a grouping without any associated uses statements. > =A0- Perhaps an extra statement under the grouping could be used to > indicate whether the grouping represents a yang data definition. Nodes in a grouping do not belong to any namespace. Forcing such a namespace binding with a substatement to "grouping" feels worse than having a YANG extension with the nodes defined (which of course can be done with "uses"). /martin > = > Thanks, > Rob > = > = > > > > > > Since the current draft says: > > > > The "yang-data" extension statement from RFC > > 8040 [RFC8040] is defined for this purpose, however it is limit= ed in > > its functionality. > > > > The intended use of the "yang-data" extension is to model all o= r part > > of a protocol message, such as the "errors" definition in ietf-= > > restconf.yang [RFC8040], or the contents of a file. However, > > protocols are often layered such that the header or payload por= tions > > of the message can be extended by external documents. The YANG= > > statements that model a protocol need to support this extensibi= lity > > that is already found in that protocol. > > > > > > I thought we are doing (3). > > > > > > > > /martin > > > > > > > >> yang-data definitions define conceptual data nodes (e.g, /x:foo) > >> Only one data-def-stmt (in yang-data or otherwise) can define a da= ta > >> node > >> /x:foo. > >> The descriptive names for the yang-data (A or B) do not define > >> namespaces. > >> > >> > >> > >>> /martin > >>> > >>> > >> Andy > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > = From nobody Tue Apr 24 08:23:08 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8006512D96C for ; Tue, 24 Apr 2018 08:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKZ4nEgqfoCI for ; Tue, 24 Apr 2018 08:23:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A9712D943 for ; Tue, 24 Apr 2018 08:23:02 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:d066:6fff:fe74:312a]) by mail.nic.cz (Postfix) with ESMTPSA id EFA6C62D9B; Tue, 24 Apr 2018 17:22:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1524583380; bh=Jk9lFIYPi5gecsmFOQcnbypm3nYElV0aKVeWs2SDjjw=; h=From:To:Date; b=wsUyaedJFiWuMhRUOcfiFUxF58z3KevHvSMoy17g2jnd/OAtsdJeCe0ZBMGMisFDx egbBz36eo2skWu7VWNINmijW7n/tSPcmOugQjFT0kgJ5CBGQUIGFOLcE6KMIvpb+Yj UvWyiDDlLeDhq6LjtDKtngfheNlJ9SxHb1ukj9tk= Message-ID: From: Ladislav Lhotka To: Martin Bjorklund Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org Date: Tue, 24 Apr 2018 17:23:03 +0200 In-Reply-To: <20180424.163601.648085760139600532.mbj@tail-f.com> References: <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423.215110.441857992070858100.mbj@tail-f.com> <87wowwr826.fsf@nic.cz> <20180424.163601.648085760139600532.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 15:23:06 -0000 On Tue, 2018-04-24 at 16:36 +0200, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > > > Hi, > > > > > > I am not sure what this statement tells us re. the issue in this email > > > thread. > > > > It tells us that, in my view, the approach taken in this document is a > > bad idea. > > Do you mean that the WG shoud drop this document? And people that Yes. Doing it properly would amount to rewriting many parts of RFC 7950 for use inside "yang-data". > need yang-data should continue to use the version in 8040? Or that Preferably not. > people that need yang-data do not have a valid use case and they > should do something else? They may have a valid use case but YANG (in the current form) is not suitable for it. Lada > > > /martin > > > > > > > Lada > > > > > > > > > > > /martin > > > > > > > > > Juergen Schoenwaelder wrote: > > >> On Sun, Apr 22, 2018 at 02:56:51PM +0200, Ladislav Lhotka wrote: > > >> > > >> > I am much more concerned with some of the post-1.1 features, also > > >> > because YANG is now being updated in several directions without a > > >> > clear vision. And another big problem is that YANG extensions are > > >> > used for these changes, so we will probably end up with several > > >> > different versions of YANG, although formally everything will be > > >> > 1.1. > > >> > > >> I tend to agree. Ideally, we would carefully remove things from YANG > > >> that did not meet the cost/benefit target (e.g., submodules), > > >> reorganize definitions whenever possible (some NETCONF specific stuff > > >> in the YANG specification should not be there, XML encoding may be > > >> factored out) and incorporate new features (like yang-data) after we > > >> have sufficient _experience_ to know that such new features will be > > >> useful (which seems to be the case for yang-data). > > >> > > >> Yes, such iterations likely take 2 years at IETF speed but this kind > > >> of maintenance cost/effort is likely the price to be paied for > > >> something that is being used at a larger scale. > > >> > > >> Some people will say that the cost of a new language version is high. > > >> (Well, when we did 1.1, some people said it will never be deployed.) > > >> Anyway, not bumping the YANG version number but having instead several > > >> (optional) language extensions is just hiding the version number > > >> change under the carpet. > > >> > > >> /js > > >> > > >> -- > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > >> Fax: +49 421 200 3103 > > >> > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > >> > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Apr 24 12:18:51 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7E412D7EC for ; Tue, 24 Apr 2018 12:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CCn-T-wqsRI for ; Tue, 24 Apr 2018 12:18:47 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFF3124F57 for ; Tue, 24 Apr 2018 12:18:46 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id u21-v6so20362964lfu.9 for ; Tue, 24 Apr 2018 12:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o8Mm5H7E3H1Za4s5FJ/2MFH6tRXNiR5tSq46sAyVjW0=; b=TKKRwYHz6ZGt6k0CDE5uv5OP7fr6DUQgBYGQKg07niGYEcAw9v3UynnJEZURpSsPtn SzjoMHlRHbEICpcb5B/YHn2LQ2voH6m1uHQV5NQ/bX7Bs78aAcq2OQ7VBpId8/rcRlPL /Ib5WajASjZVCUe8iVSH1PnYXXpCqSFD4KsNiDdBpyPrIq5SPNTFQVwzXvNU9wr23GZZ 5OWGYeAPO5Z1pYuTyW2KuTMFuhnr96tKvx9sBXjY2t7FFtnj9TTpxTSNXmR83OO8JuFp d2WnvRhyxmz885uHeY9LWH/Qcruhxqno/IkTUDj/OWpEB42BmtWQguJS/dT5zq4fu8OF cCig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o8Mm5H7E3H1Za4s5FJ/2MFH6tRXNiR5tSq46sAyVjW0=; b=UMViWI5ll1KG/kk+dXV8XkTdRYFRPqf4yLQOPkGhp+1tMtJt3Urm5UOvJUvcxBBZWY p2ie864UEozOhczWKOfKae4DQ0OaGH8W/DhtqlA4QJL1YzqPjuAYyGOKYegm0N2L0vkl ZhqzedUjYgvIBxfjlai3D49atEcgCI3atQZIdzYoT9Q02X2u6ACBJ+jOoq4egvzKPhM8 +/GV+TFi1b/Oaia6CVs2Y7dtK6QHjKvMsHkcdpv5G+fYLWjGMvXu8JEhDx4oj7y0gyAd pqbDsD8mlXYdSECGSmTd2YKuMCUWcMAgbA8+q0F/0s3ZnX9zjmx5lwRf4VZ2ixKKVMP1 E5Yw== X-Gm-Message-State: ALQs6tBLnl5Nc843rMddaoYyLMPUDWxv2kmBEb/VksWkI/nbf1QvZD5N W+BCP9EVPuxA9LlcjO2GLxnYvTx4l19Pl4sVwrzm7A== X-Google-Smtp-Source: AIpwx49HFb/BaGeewsuRhLgFOqD+MWTCYXAxtfpFBNZTvxeQqxR5/tCzUEbru7NoXcLt1zDmueMPL0GpQDsmH+++naI= X-Received: by 10.46.151.206 with SMTP id m14mr18345875ljj.102.1524597524861; Tue, 24 Apr 2018 12:18:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Tue, 24 Apr 2018 12:18:43 -0700 (PDT) In-Reply-To: <20180423.220815.526647366558506966.mbj@tail-f.com> References: <20180423.214923.1209533731960312602.mbj@tail-f.com> <20180423.220815.526647366558506966.mbj@tail-f.com> From: Andy Bierman Date: Tue, 24 Apr 2018 12:18:43 -0700 Message-ID: To: Martin Bjorklund Cc: Kent Watsen , NetMod WG Content-Type: multipart/alternative; boundary="883d24f22e14e53490056a9d0538" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 19:18:50 -0000 --883d24f22e14e53490056a9d0538 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 23, 2018 at 1:08 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > > .... > > > > > > > > I do not understand the need for a yang-data structure that > represents > > > data > > > > that can be instantiated anywhere and everywhere. > > > > > > AFAIK noone is proposing that. > > > > > > > I do not want to break > > > > existing tools that expect sibling data nodes in the same module > > > namespace > > > > to > > > > be unique local-names. > > > > > > > > I would rather stick with the yang-data in RFC 8040 than introduce a > new > > > > extension > > > > with no restrictions. Standard YANG extensions should be > interoperable > > > and > > > > have > > > > a clear purpose. > > > > > > Of course. > > > > > > > If we do not need to define what a YANG extension does in > > > > a way that can be observed somehow, then it does not need to be a > > > standard. > > > > > > Agreed. > > > > > > Not sure how any of this helps with the original issue though. > > > > > > > > > > You proposed that duplicate nodes were OK: > > > > module X { > > prefix x; > > > > x:yang-data A { > > list foo { ... } > > } > > > > x:yang-data B { > > container foo { ... } > > } > > > > } > > > > > > I do not want to allow any duplicates. > > Yes, I got that. > > > There are no encoding and parsing rules for instance data > > that support this sort of duplicate. > > This is not correct, as I have demonstrated earlier, and I think you > also accepted; if different structures are defined for different rpcs' > error-infos, then these structures can have the same child node names. > > I think that we have to agree on the basics before disussing > solutions: > > 1) Should we do anything at all? > > (i.e., keep using yang-data in RFC 8040) > > 2) Should we define structures that only can be used in > standalone instance documents? > > (i.e., *more* restrictive than yang-data in RFC 8040) > > 3) Should we define structures that can be used in standalone > instance documents, error-info contents, and other places that > we might not know right now? > > (i.e., *less* restrictive than yang-data in RFC 8040) > > > Since the current draft says: > > The "yang-data" extension statement from RFC > 8040 [RFC8040] is defined for this purpose, however it is limited in > its functionality. > > The intended use of the "yang-data" extension is to model all or part > of a protocol message, such as the "errors" definition in ietf- > restconf.yang [RFC8040], or the contents of a file. However, > protocols are often layered such that the header or payload portions > of the message can be extended by external documents. The YANG > statements that model a protocol need to support this extensibility > that is already found in that protocol. > > > I thought we are doing (3). > > > The use-case that has come up several times is (1). People want to use YANG to define the schema for an XML or JSON representation of a stand-alone document. Item (3) needs to be machine-readable and deterministic for it to be even remotely feasible as a standard. There is no way a tool should have to match to the correct schema, based on the description-stmt inside some yang-data-stmt. The only data needed must be module + local-name. The example you gave of different definitions of the leaf is a really bad idea. We should never try to define different schema for the same instance data, where the module-name and local-name are the same, but the contents are different. Defining an extension that maps error-info data for a specific RPC might be something worth standardizing. It should not be done with yang-data, but rather a different extension just for this purpose. > /martin > Andy > > > > > yang-data definitions define conceptual data nodes (e.g, /x:foo) > > Only one data-def-stmt (in yang-data or otherwise) can define a data node > > /x:foo. > > The descriptive names for the yang-data (A or B) do not define > namespaces. > > > > > > > > > /martin > > > > > > > > Andy > --883d24f22e14e53490056a9d0538 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 23, 2018 at 1:08 PM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> > ....
> > >
> > > I do not understand the need for a yang-data structure that = represents
> > data
> > > that can be instantiated anywhere and everywhere.
> >
> > AFAIK noone is proposing that.
> >
> > > I do not want to break
> > > existing tools that expect sibling data nodes in the same mo= dule
> > namespace
> > > to
> > > be unique local-names.
> > >
> > > I would rather stick with the yang-data in RFC 8040 than int= roduce a new
> > > extension
> > > with no restrictions.=C2=A0 Standard YANG extensions should = be interoperable
> > and
> > > have
> > > a clear purpose.
> >
> > Of course.
> >
> > > If we do not need to define what a YANG extension does in > > > a way that can be observed somehow, then it does not need to= be a
> > standard.
> >
> > Agreed.
> >
> > Not sure how any of this helps with the original issue though. > >
> >
>
> You proposed that duplicate nodes were OK:
>
> module X {
> prefix x;
>
> x:yang-data A {
>=C2=A0 =C2=A0 list foo { ... }
> }
>
> x:yang-data B {
>=C2=A0 =C2=A0container foo { ... }
> }
>
> }
>
>
> I do not want to allow any duplicates.

Yes, I got that.

> There are no encoding and parsing rules for instance data
> that support this sort of duplicate.

This is not correct, as I have demonstrated earlier, and I think you
also accepted; if different structures are defined for different rpcs'<= br> error-infos, then these structures can have the same child node names.

I think that we have to agree on the basics before disussing
solutions:

=C2=A0 1)=C2=A0 Should we do anything at all?

=C2=A0 =C2=A0 =C2=A0 (i.e., keep using yang-data in RFC 8040)

=C2=A0 2)=C2=A0 Should we define structures that only can be used in
=C2=A0 =C2=A0 =C2=A0 standalone instance documents?

=C2=A0 =C2=A0 =C2=A0 (i.e., *more* restrictive than yang-data in RFC 8040)<= br>
=C2=A0 3)=C2=A0 Should we define structures that can be used in standalone<= br> =C2=A0 =C2=A0 =C2=A0 instance documents, error-info contents, and other pla= ces that
=C2=A0 =C2=A0 =C2=A0 we might not know right now?

=C2=A0 =C2=A0 =C2=A0 (i.e., *less* restrictive than yang-data in RFC 8040)<= br>

Since the current draft says:

=C2=A0 =C2=A0The "yang-data" extension statement from RFC
=C2=A0 =C2=A08040 [RFC8040] is defined for this purpose, however it is limi= ted in
=C2=A0 =C2=A0its functionality.

=C2=A0 =C2=A0The intended use of the "yang-data" extension is to = model all or part
=C2=A0 =C2=A0of a protocol message, such as the "errors" definiti= on in ietf-
=C2=A0 =C2=A0restconf.yang [RFC8040], or the contents of a file.=C2=A0 Howe= ver,
=C2=A0 =C2=A0protocols are often layered such that the header or payload po= rtions
=C2=A0 =C2=A0of the message can be extended by external documents.=C2=A0 Th= e YANG
=C2=A0 =C2=A0statements that model a protocol need to support this extensib= ility
=C2=A0 =C2=A0that is already found in that protocol.


I thought we are doing (3).



The use-case that has come up several = times is (1).
People want to use YANG to define the schema for an= XML or JSON
representation of a stand-alone document.
=
Item (3) needs to be machine-readable and deterministic for = it to be even remotely
feasible as a standard. There is no way a = tool should have to match <x:foo> to
the correct schema, ba= sed on the description-stmt inside some yang-data-stmt.
The only = data needed must be module + local-name.

The examp= le you gave of different definitions of the <reason> leaf is a really= bad idea.
We should never try to define different schema for the= same instance data,
where the module-name and local-name are the= same, but the contents are different.

Defining an= extension that maps error-info data for a specific RPC might be
= something worth standardizing.=C2=A0 It should not be done with yang-data,<= /div>
but rather a different extension just for this purpose.



/martin

Andy
=C2=A0



> yang-data definitions define conceptual data nodes (e.g, /x:foo)
> Only one data-def-stmt (in yang-data or otherwise) can define a data n= ode
> /x:foo.
> The descriptive names for the yang-data (A or B) do not define namespa= ces.
>
>
>
> > /martin
> >
> >
> Andy

--883d24f22e14e53490056a9d0538-- From nobody Tue Apr 24 14:13:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA57F12DA4F for ; Tue, 24 Apr 2018 14:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCRYooIB-_Oe for ; Tue, 24 Apr 2018 14:13:15 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3EFF12DA11 for ; Tue, 24 Apr 2018 14:13:14 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3OL9FqH030651; Tue, 24 Apr 2018 14:13:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=MEljIUEcKVOQTf8FQxbNuZlJyijNzluJS47kL7pPV60=; b=MeTx1QJV9K8RkQXAXQFDB1i/82qTjlukD1+4n4SHexznPGmAifDC5khfOtmCwV3BMmoy wzenlhcFPe2DIJimLKGYu8FmEPpet9fbWGtWQjP3pMFXkcRoImrsQ0CbxdQcZO2YHItF +y9bBs8AL4Z8rN1bY79DQ0kGSxvyUJQob/d4p6tmqtXx3oJwu9H+D22X60gkOZiLPAf/ B5T8VWjLeknRjEl8SGB6JYUt4omj+IicZCojIB3iE/adRPw9spVIPHauScEwgB1/YQ62 c6Fgwu5YWF31u2c8SUScPY8/OZuoXQnqXtlfce4wY8AUQ0sVYaAYVjtp9wDWGslqmToK xw== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0015.outbound.protection.outlook.com [207.46.163.15]) by mx0a-00273201.pphosted.com with ESMTP id 2hj8tpgdnx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Apr 2018 14:13:14 -0700 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3419.namprd05.prod.outlook.com (10.174.240.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.715.7; Tue, 24 Apr 2018 21:13:13 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965%6]) with mapi id 15.20.0715.015; Tue, 24 Apr 2018 21:13:13 +0000 From: Kent Watsen To: Andy Bierman , Martin Bjorklund CC: NetMod WG Thread-Topic: [netmod] yang-data-ext issues Thread-Index: AQHT1YJYRSnZmZlnhU6JIK4LoPfNTqQDdYgAgAAS9YCAAAZpAIAACwoAgAAFOICAAuemAIAAR8IAgAABIACAAAEwgIAHI10AgABILICAAAT7AIAAS8EAgABAMYCAAAJrgIAAAtqAgAGEfoD//9zuAA== Date: Tue, 24 Apr 2018 21:13:12 +0000 Message-ID: <403C417C-4546-48FA-AEA5-6ABA3D5A3845@juniper.net> References: <20180423.214923.1209533731960312602.mbj@tail-f.com> <20180423.220815.526647366558506966.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3419; 7:jk/shhD5JY2lsdUj0b0CXesS+09CjjPabRQPbxu++zrbv+K/f75LJs7hAkjK+hw0i4nYI8oL/Kl/jw8lXDIUKvvZQIsirkF9dk4BJ3syrhGXOWZ9pxAB3LTEAcTC1la27nQutFYP6sgs2Six5UR6bOhPnRaTX7s7D22C89Sw8o9GBpdinu0j0Z3tVHoRDycMslG5oBDJCDOIbK4A5n6emgEB6H/JBEPRtIIj1aziKS97a0v7Z6DnLqiwjZ+yGau1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM5PR05MB3419; x-ms-traffictypediagnostic: DM5PR05MB3419: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231232)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041310)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR05MB3419; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3419; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(366004)(346002)(376002)(396003)(199004)(189003)(2616005)(11346002)(446003)(3846002)(82746002)(476003)(486006)(6116002)(6436002)(6512007)(53936002)(6246003)(5250100002)(7736002)(83716003)(3660700001)(3280700002)(14454004)(97736004)(26005)(86362001)(186003)(105586002)(25786009)(36756003)(2906002)(6306002)(106356001)(76176011)(6486002)(478600001)(8936002)(58126008)(102836004)(110136005)(54896002)(316002)(68736007)(4326008)(33656002)(2900100001)(81156014)(66066001)(59450400001)(81166006)(93886005)(229853002)(99286004)(6506007)(8676002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3419; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: ndimI8RBUyH+FzVIUvwaxGt7XPSaErAgim9RHp1bdisInSBnNfYG2vHMZCGkxe6i+Uil1dAMwkhyWbxizzcjij06ANavHBwmPMET9e0Nf3E/6xb/DL2463ReC90eftvYqAmqEBxeDZLixvrR/2xHJt++wf4L20svGGI1TocZ2Rg6o5jnpidyysX2ptT23Gk6 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_403C417C454648FAAEA56ABA3D5A3845junipernet_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 447638e7-085a-4008-75df-08d5aa283067 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 447638e7-085a-4008-75df-08d5aa283067 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2018 21:13:12.9092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3419 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-24_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804240200 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 21:13:18 -0000 --_000_403C417C454648FAAEA56ABA3D5A3845junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+IFBlb3BsZSB3YW50IHRvIHVzZSBZQU5HIHRvIGRlZmluZSB0aGUgc2NoZW1hIGZvciBhbiBY TUwgb3IgSlNPTg0KPiByZXByZXNlbnRhdGlvbiBvZiBhIHN0YW5kLWFsb25lIGRvY3VtZW50Lg0K DQpBZ3JlZWQNCg0KDQo+IFRoZSBvbmx5IGRhdGEgbmVlZGVkIG11c3QgYmUgbW9kdWxlICsgbG9j YWwtbmFtZS4NCg0KT3IgbWF5YmU6IG1vZHVsZSArIGxvY2FsLW5hbWUgKyBjb250ZXh0LCB3aGVy ZSBjb250ZXh0IGlzIG9uZSBvZjoNCg0KICAtIGRhdGEgbm9kZXMNCiAgLSBSUEMvYWN0aW9ucw0K ICAtIG5vdGlmaWNhdGlvbnMNCiAgLSBzdGFuZGFsb25lIGFydGlmYWN0cyAoZmlsZXMpDQoNCkF0 IGxlYXN0LCBpdCBzZWVtcyB0aGF0IHRoZXNlIGFyZSBkaWZmZXJlbnQgdGhpbmdzLg0KDQpbTm90 ZTogUkVTVENPTkYgcGxhY2VzIHNvbWUgb2YgdGhlIGNvbnRleHQgaW50byB0aGUgVVJMOyB0d28g ZGlmZmVyZW50IGRhdGEgbm9kZSByZXNvdXJjZXMgY2FuIGhhdmUgaWRlbnRpY2FsIG1vZHVsZSAr IGxvY2FsLW5hbWUuXQ0KDQpJdCB3b3VsZCBiZSBiYWQgaWYgdHdvIHN0YW5kLWFsb25lIGFydGlm YWN0cyBoYWQgdGhlIHNhbWUgbW9kdWxlK2xvY2FsLW5hbWUgKGZvbzpiYXIpLiAgIEhvd2V2ZXIs IGl0J3Mgb2theSB0byBoYXZlIGEgbWF0Y2hpbmcgdG9wLWxldmVsIGRhdGEgbm9kZSBjYWxsZWQg ImZvbzpiYXIiLCBzaW5jZSBpdCBpcyB1c2VkIGluIGEgZGlmZmVyZW50IGNvbnRleHQuICBKdXN0 IGxpa2UgeWFuZy1kYXRhIGNhbm5vdCBiZSBhY2Nlc3NlZCBhcyBkYXRhIHZpYSBhIHByb3RvY29s IGxpa2UgTkMgb3IgUkMsIHNvIGl0IGlzIHRoYXQgdHJhZGl0aW9uYWxseS1kZWZpbmVkIGRhdGEg bm9kZXMgY2Fubm90IGJlIGFjY2Vzc2VkIGFzIGEgc3RhbmQtYWxvbmUgYXJ0aWZhY3QgKHVubGVz cyB5b3XigJlyZSBhIGRyYWZ0LWF1dGhvciBhbmQgbmVlZCBhbiBpbnN0YW5jZSBkb2N1bWVudCBm b3IgYW4gZXhhbXBsZSkuDQoNCg0KPiBEZWZpbmluZyBhbiBleHRlbnNpb24gdGhhdCBtYXBzIGVy cm9yLWluZm8gZGF0YSBmb3IgYSBzcGVjaWZpYyBSUEMgbWlnaHQgYmUNCj4gc29tZXRoaW5nIHdv cnRoIHN0YW5kYXJkaXppbmcuICBJdCBzaG91bGQgbm90IGJlIGRvbmUgd2l0aCB5YW5nLWRhdGEs DQo+IGJ1dCByYXRoZXIgYSBkaWZmZXJlbnQgZXh0ZW5zaW9uIGp1c3QgZm9yIHRoaXMgcHVycG9z ZS4NCg0KTWFydGluIHdyb3RlIGJlZm9yZToNCg0KICAgICAgICAgICAgKG1heWJlIGluIHRoZSBm dXR1cmUgd2UgY291bGQgZXZlbiBoYXZlIGEgWUFORyBleHRlbnNpb24gc3RhdGVtZW50IHRvDQog ICAgICAgICAgICBmb3JtYWxpemUgdGhlIGRlc2NyaXB0aW9uOg0KDQogICAgICAgICAgICAgICBy cGMgbXktZmlyc3QtcnBjIHsNCiAgICAgICAgICAgICAgICAgLi4uDQogICAgICAgICAgICAgICAg IG9weDplcnJvci1pbmZvLXN0cnVjdHVyZSBteS1maXJzdC1ycGMtZXJyb3ItaW5mbzsNCiAgICAg ICAgICAgICAgIH0NCg0KICAgICAgICAgICAgYnV0IHRoaXMgaXMgbm90IHBvaW50IG5vdy4pDQoN CkkgaW1hZ2luZWQgdGhhdCBoZSB3YXMgaG9waW5nIHRvIGxpbWl0IHdoYXQncyBuZWVkZWQgdG8g Z2V0IGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMgb3V0IHRoZSBkb29y IG5vdywgYnV0IEkgdGhpbmsgYW5vdGhlciBJLUQgc2hvdWxkIGJlIHByb3Bvc2VkIHRvIGF1Z21l bnQgdGhlICdycGMnIGFuZCAnYWN0aW9uJyBzdGF0ZW1lbnRzIHdpdGggYW4gYW55ZGF0YSBjYWxs ZWQgImVycm9yLWluZm8tc3RydWN0dXJlIiBzbyB0aGUgWUFORyB3b3VsZCBiZSBtb3JlIGxpa2Ug dGhpczoNCg0KICAgICAgICAgICAgICAgcnBjIG15LWZpcnN0LXJwYyB7DQogICAgICAgICAgICAg ICAgIC4uLg0KICAgICAgICAgICAgICAgICBvcHg6ZXJyb3ItaW5mby1zdHJ1Y3R1cmUgbXktZmly c3QtcnBjLWVycm9yLWluZm8gew0KICAgICAgICAgICAgICAgICAgICAg4oCmDQogICAgICAgICAg ICAgICAgICAgfQ0KICAgICAgICAgICAgICAgfQ0KDQpUaGF0IGlzLCB0byB5b3VyIHBvaW50LCB3 aXRoIG5vIHJlZmVyZW5jZSB0byBhIHlhbmctZGF0YSBkYXRhIHN0cnVjdHVyZS4NCg0KDQo+IEFu ZHkNCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQo= --_000_403C417C454648FAAEA56ABA3D5A3845junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <8D581DCED069D84EBEB0D6FB6F529DB9@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3Rl eHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0K CXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IFBlb3BsZSB3YW50IHRvIHVzZSBZQU5HIHRvIGRlZmluZSB0aGUgc2NoZW1hIGZvciBhbiBYTUwg b3IgSlNPTjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyByZXByZXNlbnRhdGlvbiBvZiBhIHN0YW5kLWFsb25lIGRvY3VtZW50LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZWQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7IFRoZSBvbmx5IGRhdGEgbmVlZGVkIG11c3QgYmUgbW9kdWxlICYjNDM7IGxv Y2FsLW5hbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9yIG1heWJl OiBtb2R1bGUgJiM0MzsgbG9jYWwtbmFtZSAmIzQzOyBjb250ZXh0LCB3aGVyZSBjb250ZXh0IGlz IG9uZSBvZjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0gZGF0YSBub2RlczxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0gUlBDL2FjdGlvbnM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAtIG5vdGlmaWNhdGlvbnM8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAtIHN0YW5kYWxvbmUg YXJ0aWZhY3RzIChmaWxlcyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgbGVhc3QsIGl0IHNl ZW1zIHRoYXQgdGhlc2UgYXJlIGRpZmZlcmVudCB0aGluZ3MuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPltOb3RlOiBSRVNUQ09ORiBwbGFjZXMgc29tZSBvZiB0aGUgY29udGV4dCBpbnRvIHRoZSBV Ukw7IHR3byBkaWZmZXJlbnQgZGF0YSBub2RlIHJlc291cmNlcyBjYW4gaGF2ZSBpZGVudGljYWwg bW9kdWxlICYjNDM7IGxvY2FsLW5hbWUuXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3Vs ZCBiZSBiYWQgaWYgdHdvIHN0YW5kLWFsb25lIGFydGlmYWN0cyBoYWQgdGhlIHNhbWUgbW9kdWxl JiM0Mztsb2NhbC1uYW1lIChmb286YmFyKS4mbmJzcDsmbmJzcDsgSG93ZXZlciwgaXQncyBva2F5 IHRvIGhhdmUgYSBtYXRjaGluZyB0b3AtbGV2ZWwgZGF0YSBub2RlIGNhbGxlZCAmcXVvdDtmb286 YmFyJnF1b3Q7LCBzaW5jZSBpdCBpcyB1c2VkIGluIGEgZGlmZmVyZW50IGNvbnRleHQuJm5ic3A7 IEp1c3QgbGlrZSB5YW5nLWRhdGEgY2Fubm90IGJlDQogYWNjZXNzZWQgYXMgZGF0YSB2aWEgYSBw cm90b2NvbCBsaWtlIE5DIG9yIFJDLCBzbyBpdCBpcyB0aGF0IHRyYWRpdGlvbmFsbHktZGVmaW5l ZCBkYXRhIG5vZGVzIGNhbm5vdCBiZSBhY2Nlc3NlZCBhcyBhIHN0YW5kLWFsb25lIGFydGlmYWN0 ICh1bmxlc3MgeW914oCZcmUgYSBkcmFmdC1hdXRob3IgYW5kIG5lZWQgYW4gaW5zdGFuY2UgZG9j dW1lbnQgZm9yIGFuIGV4YW1wbGUpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsgRGVmaW5pbmcgYW4gZXh0ZW5zaW9uIHRoYXQgbWFwcyBlcnJvci1pbmZvIGRh dGEgZm9yIGEgc3BlY2lmaWMgUlBDIG1pZ2h0IGJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IHNvbWV0aGluZyB3b3J0aCBzdGFuZGFyZGl6 aW5nLiZuYnNwOyBJdCBzaG91bGQgbm90IGJlIGRvbmUgd2l0aCB5YW5nLWRhdGEsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IGJ1dCByYXRo ZXIgYSBkaWZmZXJlbnQgZXh0ZW5zaW9uIGp1c3QgZm9yIHRoaXMgcHVycG9zZS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TWFydGluIHdyb3RlIGJlZm9yZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IChtYXliZSBpbiB0aGUgZnV0dXJlIHdlIGNvdWxkIGV2ZW4gaGF2ZSBhIFlB TkcgZXh0ZW5zaW9uIHN0YXRlbWVudCB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGZvcm1hbGl6ZSB0aGUgZGVzY3JpcHRpb246PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgcnBjIG15LWZpcnN0LXJwYyB7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvcHg6ZXJyb3ItaW5mby1zdHJ1Y3R1cmUgbXkt Zmlyc3QtcnBjLWVycm9yLWluZm87PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGJ1dCB0aGlzIGlzIG5vdCBwb2ludCBub3cuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGltYWdpbmVkIHRoYXQgaGUgd2FzIGhvcGluZyB0byBsaW1pdCB3aGF0J3MgbmVlZGVkIHRvIGdl dCBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzIG91dCB0aGUgZG9vciBu b3csIGJ1dCBJIHRoaW5rIGFub3RoZXIgSS1EIHNob3VsZCBiZSBwcm9wb3NlZCB0byBhdWdtZW50 IHRoZSAncnBjJyBhbmQgJ2FjdGlvbicgc3RhdGVtZW50cyB3aXRoIGFuIGFueWRhdGEgY2FsbGVk ICZxdW90O2Vycm9yLWluZm8tc3RydWN0dXJlJnF1b3Q7DQogc28gdGhlIFlBTkcgd291bGQgYmUg bW9yZSBsaWtlIHRoaXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsgcnBjIG15LWZpcnN0LXJwYyB7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBvcHg6ZXJyb3ItaW5mby1zdHJ1Y3R1cmUgbXktZmlyc3QtcnBjLWVycm9yLWluZm8gezxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKApjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO308bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGlz LCB0byB5b3VyIHBvaW50LCB3aXRoIG5vIHJlZmVyZW5jZSB0byBhIHlhbmctZGF0YSBkYXRhIHN0 cnVjdHVyZS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgQW5keTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktlbnQgLy8gY29udHJp YnV0b3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_403C417C454648FAAEA56ABA3D5A3845junipernet_-- From nobody Tue Apr 24 21:22:48 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C2C126CF6; Tue, 24 Apr 2018 21:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCFChLVAFuI7; Tue, 24 Apr 2018 21:22:39 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169861205F0; Tue, 24 Apr 2018 21:22:39 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D8B461B1EF079; Wed, 25 Apr 2018 05:22:34 +0100 (IST) Received: from DGGEMA421-HUB.china.huawei.com (10.1.198.154) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 25 Apr 2018 05:22:35 +0100 Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.62]) by dggema421-hub.china.huawei.com ([10.1.198.154]) with mapi id 14.03.0361.001; Wed, 25 Apr 2018 12:22:24 +0800 From: Rohit R Ranade To: "netconf@ietf.org" , "netmod@ietf.org" Thread-Topic: [netconf] Comments on draft-ietf-netconf-nmda-netconf-05 Thread-Index: AdPcSwf++bO2gXLeQQmOiZdPyJhH8w== Date: Wed, 25 Apr 2018 04:22:24 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B1E92F6@DGGEMA502-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.150.121] Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6B1E92F6DGGEMA502MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 04:22:42 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A6B1E92F6DGGEMA502MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I plan to implement this draft and hence had some implementation related cl= arifications. 1. I feel that there should be more text added about "origin" filteri= ng mechanism. I am not clear about some aspects of origin filtering. RFC 8342 : NMDA RFC provides the below example lo0 loopback 127.0.0.1 ::1 If user provides as "system" ONLY, then he will NOT get thi= s record in output. Because the keys have originated from "intended" . Righ= t ? So, If user wants to get the system originated data, he MUST give all the o= rigins in the where the keys of the system data have origin= ated from. Can you please confirm whether this is OK. Another example given in RFC 8342 is as below: lo0 127.0.0.1 ::1 ? Here keys are originated from "system", but it is under container of "in= tended". So if user gives "system" for "origin-filter", the output will sti= ll NOT have this instance output ? ? Also the container is not defined as "presence" in C.3. Interface Examp= le, but still it has origin whether that is Ok ? With Regards, Rohit R Ranade From: Rohit R Ranade Sent: 24 April 2018 18:39 To: 'netmod@ietf.org' Subject: [netmod] Comments on draft-ietf-netconf-nmda-netconf-05 Hi All, Please find some comments for the draft. 1. If "config-filter" leaf is not given for whether we can= add explicit text that both config=3Dtrue and config=3Dfalse nodes will be= selected. 2. In the YANG module description for "config-filter" , also it is no= t clear about what happens if the leaf is not given in filter. I feel bette= r we keep the style like RESTCONF RFC 8040 Section 4.8.1 , with "content" h= aving config/nonconfig/all 3. Regarding the "max-depth" parameter, I feel we should take the tex= t about how "depth" is calculated for each node from RESTCONF RFC from Sect= ion 4.8.2 and add it to this draft. What will be depth of parent keys which= are auto-selected when selecting on child nodes. Maybe some example regard= ing using of "max-depth" will be helpful. 4. For the filter mechanism, since there are 4 filters (fi= lter-spec and config-filter and max-depth and with-defaults), whether we ca= n mention that all these filters are AND'ed. Also whether there is a sugges= ted order to apply filter ? I think "max-depth" filter has to be applied la= st. Others maybe any order is OK. 5. negated-origin-filter : Regarding this I feel we can add a sentenc= e as to when user should use "negated-origin-filter" , as "origin-filter" a= lso can be used for this purpose. With Regards, Rohit R Ranade --_000_991B70D8B4112A4699D5C00DDBBF878A6B1E92F6DGGEMA502MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,=

&n= bsp;

I plan = to implement this draft and hence had some implementation related clarifica= tions.

&n= bsp;

1.       I feel that there should be more text added about “origin” fil= tering mechanism. I am not clear about some aspects of origin filtering.

&n= bsp;

RFC 834= 2 : NMDA RFC provides the below example

&n= bsp;

<interfaces xmlns:or=3D"urn:ietf:params:xml:ns= :yang:ietf-origin"

 &= nbsp;           &nbs= p;   or:origin=3D"or:intended">

 &= nbsp;     <interface>

 &= nbsp;       <name>lo0</name>=

 &= nbsp;       <description>loopback</d= escription>

 &= nbsp;       <ip-address or:origin=3D"= or:system">127.0.0.1</ip-address>

 &= nbsp;       <ip-address>::1</ip-addr= ess>

 &= nbsp;     </interface>

 &= nbsp;   </interfaces>

If user= provides <origin-filter> as “system” ONLY, then he will = NOT get this record in output. Because the keys have originated from “= ;intended” . Right ?

So, If = user wants to get the system originated data, he MUST give all the origins = in the <origin-filter> where the keys of the system data have origina= ted from. Can you please confirm whether this is OK.

&n= bsp;

&n= bsp;

Another= example given in RFC 8342 is as below:

     <interfaces xmlns= :or=3D"urn:ietf:params:xml:ns:yang:ietf-origin"=

       &nb= sp;         or:origin=3D"or:in= tended">

       <inte= rface or:origin=3D"or:system">

       &nb= sp; <name>lo0</name>

       &nb= sp; <ip-address>127.0.0.1</ip-address>

       &nb= sp; <ip-address>::1</ip-address>

       </int= erface>

     </interfaces>

ð  Here keys are originated from “system”, but it is under contai= ner of “intended”. So if user gives “system” for &#= 8220;origin-filter”, the output will still NOT have this instance out= put ?

ð  Also the container is not defined as “presence” in C.3.  Interface Example, but still it has origin whether that i= s Ok ?

&n= bsp;

With Re= gards,

Rohit R= Ranade

&n= bsp;

From: Rohit R Ranade
Sent: 24 April 2018 18:39
To: 'netmod@ietf.org' <netmod@ietf.org>
Subject: [netmod] Comments on draft-ietf-netconf-nmda-netconf-05

 

Hi All,

 

Please find some comments for t= he draft.  

 

1= .   &= nbsp;   If “config-filter” leaf is not= given for <get-data> whether we can add explicit text that both config=3Dtrue and config=3Dfalse nodes will be selected.

2= .   &= nbsp;   In the YANG module desc= ription for “config-filter” , also it is not clear about what h= appens if the leaf is not given in filter. I feel better we keep the style = like RESTCONF RFC 8040 Section 4.8.1 , wi= th “content” having  config/nonconfig/all

3= .   &= nbsp;   Regarding the “ma= x-depth” parameter, I feel we should take the text about how “d= epth” is calculated for each node from RESTCONF RFC from Section 4.8.= 2 and add it to this draft. What will be depth of parent keys which are auto-selected when selecting on child nodes. Maybe some example = regarding using of “max-depth” will be helpful.

4= .   &= nbsp;   For the <get-data>= ; filter mechanism, since there are 4 filters (filter-spec and config-filte= r and max-depth and with-defaults), whether we can mention that all these f= ilters are AND’ed. Also whether there is a suggested order to apply filter ? I think “max-depth” filter= has to be applied last. Others maybe any order is OK.

5= .   &= nbsp;   negated-origin-filter := Regarding this I feel we can add a sentence as to when user should use = 220;negated-origin-filter” , as “origin-filter” also can = be used for this purpose.

 

With Regards,=

Rohit R Ranade

 

 

--_000_991B70D8B4112A4699D5C00DDBBF878A6B1E92F6DGGEMA502MBXchi_-- From nobody Tue Apr 24 23:57:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A8D127076 for ; Tue, 24 Apr 2018 23:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIIABljQpC0B for ; Tue, 24 Apr 2018 23:57:53 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3C35612706D for ; Tue, 24 Apr 2018 23:57:53 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 81F911AE02A7; Wed, 25 Apr 2018 08:57:51 +0200 (CEST) Date: Wed, 25 Apr 2018 08:57:51 +0200 (CEST) Message-Id: <20180425.085751.1552281751468645335.mbj@tail-f.com> To: kwatsen@juniper.net Cc: andy@yumaworks.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <403C417C-4546-48FA-AEA5-6ABA3D5A3845@juniper.net> References: <20180423.220815.526647366558506966.mbj@tail-f.com> <403C417C-4546-48FA-AEA5-6ABA3D5A3845@juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 06:57:55 -0000 S2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiANCj4gPiBQZW9wbGUg d2FudCB0byB1c2UgWUFORyB0byBkZWZpbmUgdGhlIHNjaGVtYSBmb3IgYW4gWE1MIG9yIEpTT04N Cj4gPiByZXByZXNlbnRhdGlvbiBvZiBhIHN0YW5kLWFsb25lIGRvY3VtZW50Lg0KPiANCj4gQWdy ZWVkDQo+IA0KPiANCj4gPiBUaGUgb25seSBkYXRhIG5lZWRlZCBtdXN0IGJlIG1vZHVsZSArIGxv Y2FsLW5hbWUuDQo+IA0KPiBPciBtYXliZTogbW9kdWxlICsgbG9jYWwtbmFtZSArIGNvbnRleHQs IHdoZXJlIGNvbnRleHQgaXMgb25lIG9mOg0KPiANCj4gICAtIGRhdGEgbm9kZXMNCj4gICAtIFJQ Qy9hY3Rpb25zDQo+ICAgLSBub3RpZmljYXRpb25zDQo+ICAgLSBzdGFuZGFsb25lIGFydGlmYWN0 cyAoZmlsZXMpDQoNCkkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHVzZSB5YW5nLWRhdGEgdG8gbW9k ZWwgbm90aWZpY2F0aW9ucy4NClByZXN1bWFibHkgeW91IG1lYW50IGVycm9yLWluZm8gZnJvbSBy cGMgb3IgYWN0aW9uLg0KDQpBbmQgbXkgcG9pbnQgaXQgaXMgdGhhdCBJIHRoaW5rIHRoYXQgd2Ug c2hvdWxkIG1ha2UgeWFuZy1kYXRhDQpmbGV4aWJsZSBlbm9vdWdoIGluIGl0c2VsZiwgYW5kIG5v dCBjb25zdHJhaW4gaXQgdG8gdGhlIG9uZSBvciB0d28gdXNlDQpjYXNlcyB3ZSBrbm93IG5vdy4N Cg0KPiBBdCBsZWFzdCwgaXQgc2VlbXMgdGhhdCB0aGVzZSBhcmUgZGlmZmVyZW50IHRoaW5ncy4N Cj4gDQo+IFtOb3RlOiBSRVNUQ09ORiBwbGFjZXMgc29tZSBvZiB0aGUgY29udGV4dCBpbnRvIHRo ZSBVUkw7IHR3byBkaWZmZXJlbnQNCj4gZGF0YSBub2RlIHJlc291cmNlcyBjYW4gaGF2ZSBpZGVu dGljYWwgbW9kdWxlICsgbG9jYWwtbmFtZS5dDQo+IA0KPiBJdCB3b3VsZCBiZSBiYWQgaWYgdHdv IHN0YW5kLWFsb25lIGFydGlmYWN0cyBoYWQgdGhlIHNhbWUNCj4gbW9kdWxlK2xvY2FsLW5hbWUg KGZvbzpiYXIpLiAgSG93ZXZlciwgaXQncyBva2F5IHRvIGhhdmUgYSBtYXRjaGluZw0KPiB0b3At bGV2ZWwgZGF0YSBub2RlIGNhbGxlZCAiZm9vOmJhciIsIHNpbmNlIGl0IGlzIHVzZWQgaW4gYSBk aWZmZXJlbnQNCj4gY29udGV4dC4gIEp1c3QgbGlrZSB5YW5nLWRhdGEgY2Fubm90IGJlIGFjY2Vz c2VkIGFzIGRhdGEgdmlhIGENCj4gcHJvdG9jb2wgbGlrZSBOQyBvciBSQywgc28gaXQgaXMgdGhh dCB0cmFkaXRpb25hbGx5LWRlZmluZWQgZGF0YSBub2Rlcw0KPiBjYW5ub3QgYmUgYWNjZXNzZWQg YXMgYSBzdGFuZC1hbG9uZSBhcnRpZmFjdCAodW5sZXNzIHlvdeKAmXJlIGENCj4gZHJhZnQtYXV0 aG9yIGFuZCBuZWVkIGFuIGluc3RhbmNlIGRvY3VtZW50IGZvciBhbiBleGFtcGxlKS4NCj4gDQo+ IA0KPiA+IERlZmluaW5nIGFuIGV4dGVuc2lvbiB0aGF0IG1hcHMgZXJyb3ItaW5mbyBkYXRhIGZv ciBhIHNwZWNpZmljIFJQQw0KPiA+IG1pZ2h0IGJlDQo+ID4gc29tZXRoaW5nIHdvcnRoIHN0YW5k YXJkaXppbmcuICBJdCBzaG91bGQgbm90IGJlIGRvbmUgd2l0aCB5YW5nLWRhdGEsDQo+ID4gYnV0 IHJhdGhlciBhIGRpZmZlcmVudCBleHRlbnNpb24ganVzdCBmb3IgdGhpcyBwdXJwb3NlLg0KPiAN Cj4gTWFydGluIHdyb3RlIGJlZm9yZToNCj4gDQo+ICAgICAgICAgICAgIChtYXliZSBpbiB0aGUg ZnV0dXJlIHdlIGNvdWxkIGV2ZW4gaGF2ZSBhIFlBTkcgZXh0ZW5zaW9uIHN0YXRlbWVudA0KPiAg ICAgICAgICAgICB0bw0KPiAgICAgICAgICAgICBmb3JtYWxpemUgdGhlIGRlc2NyaXB0aW9uOg0K PiANCj4gICAgICAgICAgICAgICAgcnBjIG15LWZpcnN0LXJwYyB7DQo+ICAgICAgICAgICAgICAg ICAgLi4uDQo+ICAgICAgICAgICAgICAgICAgb3B4OmVycm9yLWluZm8tc3RydWN0dXJlIG15LWZp cnN0LXJwYy1lcnJvci1pbmZvOw0KPiAgICAgICAgICAgICAgICB9DQo+IA0KPiAgICAgICAgICAg ICBidXQgdGhpcyBpcyBub3QgcG9pbnQgbm93LikNCj4gDQo+IEkgaW1hZ2luZWQgdGhhdCBoZSB3 YXMgaG9waW5nIHRvIGxpbWl0IHdoYXQncyBuZWVkZWQgdG8gZ2V0DQo+IGRyYWZ0LWlldGYtbmV0 Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMgb3V0IHRoZSBkb29yIG5vdywgYnV0IEkgdGhpbmsN Cj4gYW5vdGhlciBJLUQgc2hvdWxkIGJlIHByb3Bvc2VkIHRvIGF1Z21lbnQgdGhlICdycGMnIGFu ZCAnYWN0aW9uJw0KPiBzdGF0ZW1lbnRzIHdpdGggYW4gYW55ZGF0YSBjYWxsZWQgImVycm9yLWlu Zm8tc3RydWN0dXJlIiBzbyB0aGUgWUFORw0KPiB3b3VsZCBiZSBtb3JlIGxpa2UgdGhpczoNCj4g DQo+ICAgICAgICAgICAgICAgIHJwYyBteS1maXJzdC1ycGMgew0KPiAgICAgICAgICAgICAgICAg IC4uLg0KPiAgICAgICAgICAgICAgICAgIG9weDplcnJvci1pbmZvLXN0cnVjdHVyZSBteS1maXJz dC1ycGMtZXJyb3ItaW5mbyB7DQo+ICAgICAgICAgICAgICAgICAgICAgIOKApg0KPiAgICAgICAg ICAgICAgICAgICAgfQ0KPiAgICAgICAgICAgICAgICB9DQoNCk5vIEkgd2FzIHRoaW5raW5nIGFs b25nIHRoZSBsaW5lcyBvZjoNCg0KICB5ZHg6eWFuZy1kYXRhIG15LWZpcnN0LXJwYy1lcnJvci1p bmZvIHsNCiAgICAuLi4NCiAgfQ0KDQogIHJwYyBteS1maXJzdC1ycGMgew0KICAgIC4uLg0KICAg IG9weDplcnJvci1pbmZvLXN0cnVjdHVyZSBteS1maXJzdC1ycGMtZXJyb3ItaW5mbzsNCiAgfQ0K DQpJLmUuLCB1c2UgeWFuZy1kYXRhIHRvIGRlZmluZSBhIHN0cnVjdHVyZSwgYW5kIHVzZSBhbm90 aGVyIHN0YXRlbWVudA0KdG8gdGllIHRoZW0gdG9nZXRoZXIuDQoNCklmIHdlIGRlZmluZSBzcGVj aWFsIHN0YXRlbWVudHMgd2l0aCBpbmxpbmUgc3RydWN0dXJlcywgd2UgcHJvYmFibHkNCmFsc28g bmVlZCBzcGVjaWFsIGF1Z21lbnQgc3RhdGVtZW50czsgd2l0aCB5b3VyIGV4YW1wbGU6DQoNCg0K ICBycGMgbXktZmlyc3QtcnBjIHsNCiAgICAuLi4NCiAgICBvcHg6ZXJyb3ItaW5mby1zdHJ1Y3R1 cmUgbXktZmlyc3QtcnBjLWVycm9yLWluZm8gew0KICAgICAgLi4uDQogICAgfQ0KICB9DQoNCg0K ICBvcHg6YXVnbWVudC1lcnJvci1pbmZvLXN0cnVjdHVyZSAnL206bXktZmlyc3QtcnBjJw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKyAnL206bXktZmlyc3QtcnBjLWVycm9yLWlu Zm8gew0KICAgIC4uLg0KICB9DQogIA0KDQovbWFydGluDQoNCg0KDQoNCj4gVGhhdCBpcywgdG8g eW91ciBwb2ludCwgd2l0aCBubyByZWZlcmVuY2UgdG8gYSB5YW5nLWRhdGEgZGF0YQ0KPiBzdHJ1 Y3R1cmUuDQo+IA0KPiANCj4gPiBBbmR5DQo+IA0KPiBLZW50IC8vIGNvbnRyaWJ1dG9yDQo+IA0K From nobody Wed Apr 25 00:03:51 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1984E127077 for ; Wed, 25 Apr 2018 00:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDB23i67x28l for ; Wed, 25 Apr 2018 00:03:48 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0F212706D for ; Wed, 25 Apr 2018 00:03:48 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 634991AE02A7; Wed, 25 Apr 2018 09:03:47 +0200 (CEST) Date: Wed, 25 Apr 2018 09:03:47 +0200 (CEST) Message-Id: <20180425.090347.389055708996810830.mbj@tail-f.com> To: andy@yumaworks.com Cc: kwatsen@juniper.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180423.220815.526647366558506966.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 07:03:50 -0000 Andy Bierman wrote: > On Mon, Apr 23, 2018 at 1:08 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > > .... > > > > > > > > > > I do not understand the need for a yang-data structure that > > represents > > > > data > > > > > that can be instantiated anywhere and everywhere. > > > > > > > > AFAIK noone is proposing that. > > > > > > > > > I do not want to break > > > > > existing tools that expect sibling data nodes in the same module > > > > namespace > > > > > to > > > > > be unique local-names. > > > > > > > > > > I would rather stick with the yang-data in RFC 8040 than introduce a > > new > > > > > extension > > > > > with no restrictions. Standard YANG extensions should be > > interoperable > > > > and > > > > > have > > > > > a clear purpose. > > > > > > > > Of course. > > > > > > > > > If we do not need to define what a YANG extension does in > > > > > a way that can be observed somehow, then it does not need to be a > > > > standard. > > > > > > > > Agreed. > > > > > > > > Not sure how any of this helps with the original issue though. > > > > > > > > > > > > > > You proposed that duplicate nodes were OK: > > > > > > module X { > > > prefix x; > > > > > > x:yang-data A { > > > list foo { ... } > > > } > > > > > > x:yang-data B { > > > container foo { ... } > > > } > > > > > > } > > > > > > > > > I do not want to allow any duplicates. > > > > Yes, I got that. > > > > > There are no encoding and parsing rules for instance data > > > that support this sort of duplicate. > > > > This is not correct, as I have demonstrated earlier, and I think you > > also accepted; if different structures are defined for different rpcs' > > error-infos, then these structures can have the same child node names. > > > > I think that we have to agree on the basics before disussing > > solutions: > > > > 1) Should we do anything at all? > > > > (i.e., keep using yang-data in RFC 8040) > > > > 2) Should we define structures that only can be used in > > standalone instance documents? > > > > (i.e., *more* restrictive than yang-data in RFC 8040) > > > > 3) Should we define structures that can be used in standalone > > instance documents, error-info contents, and other places that > > we might not know right now? > > > > (i.e., *less* restrictive than yang-data in RFC 8040) > > > > > > Since the current draft says: > > > > The "yang-data" extension statement from RFC > > 8040 [RFC8040] is defined for this purpose, however it is limited in > > its functionality. > > > > The intended use of the "yang-data" extension is to model all or part > > of a protocol message, such as the "errors" definition in ietf- > > restconf.yang [RFC8040], or the contents of a file. However, > > protocols are often layered such that the header or payload portions > > of the message can be extended by external documents. The YANG > > statements that model a protocol need to support this extensibility > > that is already found in that protocol. > > > > > > I thought we are doing (3). > > > > > > > The use-case that has come up several times is (1). > People want to use YANG to define the schema for an XML or JSON > representation of a stand-alone document. > > Item (3) needs to be machine-readable and deterministic for it to be even > remotely > feasible as a standard. There is no way a tool should have to match > to > the correct schema, based on the description-stmt inside some > yang-data-stmt. > The only data needed must be module + local-name. > > The example you gave of different definitions of the leaf is a > really bad idea. > We should never try to define different schema for the same instance data, > where the module-name and local-name are the same, but the contents are > different. When the context is different this is not a problem. Compare w/ augment: augment "/if:interfaces/if:interface" { container ipv4 { ... } } augment "/if:interfaces/if:interface-state" { container ipv4 { ... } } These augements define the node "ipv4" in the the "ietf-ip" namespace, but b/c the context is different, there is no risk for confusion. > Defining an extension that maps error-info data for a specific RPC might be > something worth standardizing. It should not be done with yang-data, > but rather a different extension just for this purpose. See my email to Kent. I don't understand why this can't be done with yang-data. This said, if we were to do a new version of YANG and address this problem, we would define a new core keyword for this. /martin > > > > > /martin > > > > Andy > > > > > > > > > > > yang-data definitions define conceptual data nodes (e.g, /x:foo) > > > Only one data-def-stmt (in yang-data or otherwise) can define a data node > > > /x:foo. > > > The descriptive names for the yang-data (A or B) do not define > > namespaces. > > > > > > > > > > > > > /martin > > > > > > > > > > > Andy > > From nobody Wed Apr 25 03:10:03 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1909712DA13 for ; Wed, 25 Apr 2018 03:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmwFSHU0FxlJ for ; Wed, 25 Apr 2018 03:09:48 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D34212DA1D for ; Wed, 25 Apr 2018 03:09:47 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id r125-v6so24621186lfe.2 for ; Wed, 25 Apr 2018 03:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=By8rIUcyvFGeIVr8FvIhqbsvOB4ygxxHgSdR3q8VUGw=; b=kEPy4myswUCha06M6sUh1dUmYoBFpGdmXMqkCMIVwgw7ySggzzHmd5z7cqZ0NqcHE9 hCkfk3RLvdQn8T4p8PV9aZPFbUiYSlZ6BUjkpq1a8aJP+sQhDgMKYai0JU5SSHyHq0Zd 2C7Ob3idHVnFafr9hCYXL6ui/xzn8HUR446oEUUcC0kvHctbVjE4RWxEID8S3toGqKUB 9wcUr5QmUbdF1ux00uykvgLCc1pMNgB8VjXrB1NN3AusQw4WqkSnuVzuo0Gbuqapg8Q4 w1f81akE9+HfRJY80z8PUZXeWZEO31R7/jszpLubOA8DsJ4F8ncslNKeMEmS97F0hRNR TJiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=By8rIUcyvFGeIVr8FvIhqbsvOB4ygxxHgSdR3q8VUGw=; b=GtxYCtdO8oPg8pxR5rN8BE3ABP1A47QeXHXBdgySSE0p+HgiPTLSGhjat56E8xKsk0 7LLGJIWM43GaL1MazzvlglLAAmLY1F474cylIgQdWb2o0KzwcdClEVT8P+P6NwrEoWpp ll9/PfJokL/M5XxCwGtnrtKQDNAtPHsVp+G39srP6Arw/2p3CL7Gq8FC503zY2zDSbhj qqWC4yd3Zn8ukVccLvJeiKCVZEWcxK3qc/44Je7DAwh55iIF8h0tYRbLqvHaR9OvTjji 6m6c2hFhGfB/Za2ofz8KSXbyAdYjWyKs3Hu7fNmWIcxr3WKlDTc4+N2geSGT2jcARdN6 e5SQ== X-Gm-Message-State: ALQs6tBARUWNrWV61XfIv9ROFKd5oeI768uUmaLWi6fbiaxvdcMOhgPN uXwiTwzHbrxeFTsZu1LcI51qXbJa76jmY9eIJ3GgK2Ny X-Google-Smtp-Source: AB8JxZpkwo0Pe1Qnf5YrcQYN0/KMIqr93US4WbT7lp8uPii5k6HvQNo9N8iGz6zyWxMvB775x27+3hjBCYjpXEsGd8U= X-Received: by 2002:a19:93ce:: with SMTP id w75-v6mr14209624lfk.38.1524650985312; Wed, 25 Apr 2018 03:09:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Wed, 25 Apr 2018 03:09:44 -0700 (PDT) In-Reply-To: <20180425.085751.1552281751468645335.mbj@tail-f.com> References: <20180423.220815.526647366558506966.mbj@tail-f.com> <403C417C-4546-48FA-AEA5-6ABA3D5A3845@juniper.net> <20180425.085751.1552281751468645335.mbj@tail-f.com> From: Andy Bierman Date: Wed, 25 Apr 2018 03:09:44 -0700 Message-ID: To: Martin Bjorklund Cc: Kent Watsen , NetMod WG Content-Type: multipart/alternative; boundary="00000000000062eab6056aa97871" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 10:10:02 -0000 --00000000000062eab6056aa97871 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 24, 2018 at 11:57 PM, Martin Bjorklund wrote: > Kent Watsen wrote: > > > > > People want to use YANG to define the schema for an XML or JSON > > > representation of a stand-alone document. > > > > Agreed > > > > > > > The only data needed must be module + local-name. > > > > Or maybe: module + local-name + context, where context is one of: > > > > - data nodes > > - RPC/actions > > - notifications > > - standalone artifacts (files) > > I don't think we should use yang-data to model notifications. > Presumably you meant error-info from rpc or action. > > And my point it is that I think that we should make yang-data > flexible enoough in itself, and not constrain it to the one or two use > cases we know now. > > > At least, it seems that these are different things. > > > > [Note: RESTCONF places some of the context into the URL; two different > > data node resources can have identical module + local-name.] > > > > It would be bad if two stand-alone artifacts had the same > > module+local-name (foo:bar). However, it's okay to have a matching > > top-level data node called "foo:bar", since it is used in a different > > context. Just like yang-data cannot be accessed as data via a > > protocol like NC or RC, so it is that traditionally-defined data nodes > > cannot be accessed as a stand-alone artifact (unless you=E2=80=99re a > > draft-author and need an instance document for an example). > > > > > > > Defining an extension that maps error-info data for a specific RPC > > > might be > > > something worth standardizing. It should not be done with yang-data, > > > but rather a different extension just for this purpose. > > > > Martin wrote before: > > > > (maybe in the future we could even have a YANG extension > statement > > to > > formalize the description: > > > > rpc my-first-rpc { > > ... > > opx:error-info-structure my-first-rpc-error-info; > > } > > > > but this is not point now.) > > > > I imagined that he was hoping to limit what's needed to get > > draft-ietf-netconf-notification-messages out the door now, but I think > > another I-D should be proposed to augment the 'rpc' and 'action' > > statements with an anydata called "error-info-structure" so the YANG > > would be more like this: > > > > rpc my-first-rpc { > > ... > > opx:error-info-structure my-first-rpc-error-info { > > =E2=80=A6 > > } > > } > > No I was thinking along the lines of: > > ydx:yang-data my-first-rpc-error-info { > ... > } > > rpc my-first-rpc { > ... > opx:error-info-structure my-first-rpc-error-info; > } > > I.e., use yang-data to define a structure, and use another statement > to tie them together. > > If we define special statements with inline structures, we probably > also need special augment statements; with your example: > > > rpc my-first-rpc { > ... > opx:error-info-structure my-first-rpc-error-info { > ... > } > } > > > opx:augment-error-info-structure '/m:my-first-rpc' > + '/m:my-first-rpc-error-info { > ... > } > > This could easily be defined to use groupings instead: grouping my-first-rpc-error-info { ... } rpc my-first-rpc { ... opx:error-info-structure my-first-rpc-error-info; } There is no need to reinvent the grouping. > /martin > > Andy > > > > > That is, to your point, with no reference to a yang-data data > > structure. > > > > > > > Andy > > > > Kent // contributor > > > --00000000000062eab6056aa97871 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 24, 2018 at 11:57 PM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Kent W= atsen <kwatsen@juniper.net>= ; wrote:
>
> > People want to use YANG to define the schema for an XML or JSON > > representation of a stand-alone document.
>
> Agreed
>
>
> > The only data needed must be module + local-name.
>
> Or maybe: module + local-name + context, where context is one of:
>
>=C2=A0 =C2=A0- data nodes
>=C2=A0 =C2=A0- RPC/actions
>=C2=A0 =C2=A0- notifications
>=C2=A0 =C2=A0- standalone artifacts (files)

I don't think we should use yang-data to model notifications.
Presumably you meant error-info from rpc or action.

And my point it is that I think that we should make yang-data
flexible enoough in itself, and not constrain it to the one or two use
cases we know now.

> At least, it seems that these are different things.
>
> [Note: RESTCONF places some of the context into the URL; two different=
> data node resources can have identical module + local-name.]
>
> It would be bad if two stand-alone artifacts had the same
> module+local-name (foo:bar).=C2=A0 However, it's okay to have a ma= tching
> top-level data node called "foo:bar", since it is used in a = different
> context.=C2=A0 Just like yang-data cannot be accessed as data via a > protocol like NC or RC, so it is that traditionally-defined data nodes=
> cannot be accessed as a stand-alone artifact (unless you=E2=80=99re a<= br> > draft-author and need an instance document for an example).
>
>
> > Defining an extension that maps error-info data for a specific RP= C
> > might be
> > something worth standardizing.=C2=A0 It should not be done with y= ang-data,
> > but rather a different extension just for this purpose.
>
> Martin wrote before:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(maybe in the future we= could even have a YANG extension statement
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0formalize the descripti= on:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rpc my-first-rp= c {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opx:erro= r-info-structure my-first-rpc-error-info;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but this is not point n= ow.)
>
> I imagined that he was hoping to limit what's needed to get
> draft-ietf-netconf-notification-messages out the door now, but I = think
> another I-D should be proposed to augment the 'rpc' and 'a= ction'
> statements with an anydata called "error-info-structure" so = the YANG
> would be more like this:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rpc my-first-rp= c {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opx:erro= r-info-structure my-first-rpc-error-info {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =E2=80=A6
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

No I was thinking along the lines of:

=C2=A0 ydx:yang-data my-first-rpc-error-info {
=C2=A0 =C2=A0 ...
=C2=A0 }

=C2=A0 rpc my-first-rpc {
=C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 opx:error-info-structure my-first-rpc-error-info;
=C2=A0 }

I.e., use yang-data to define a structure, and use another statement
to tie them together.

If we define special statements with inline structures, we probably
also need special augment statements; with your example:


=C2=A0 rpc my-first-rpc {
=C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 opx:error-info-structure my-first-rpc-error-info {
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 }
=C2=A0 }


=C2=A0 opx:augment-error-info-structure '/m:my-first-rpc'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ '/m:my-first-rpc-error-i= nfo {
=C2=A0 =C2=A0 ...
=C2=A0 }




This cou= ld easily be defined to use groupings instead:


=C2=A0 grouping my-first-rpc-error-info {
=C2=A0 =C2=A0 = ...
=C2=A0 }

=C2=A0 rpc my-first-rpc {
=C2=A0 =C2=A0 ...
= =C2=A0 =C2=A0 opx:error-info-structure my-first-rpc-error-info;
=C2=A0 }=


=C2=A0There is no need to rein= vent the grouping.



/martin



Andy

=C2=A0



> That is, to your point, with no reference to a yang-data data
> structure.
>
>
> > Andy
>
> Kent // contributor
>

--00000000000062eab6056aa97871-- From nobody Wed Apr 25 03:13:42 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2366412DA1D for ; Wed, 25 Apr 2018 03:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9YKVrVvgDBf for ; Wed, 25 Apr 2018 03:13:36 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB6912DA13 for ; Wed, 25 Apr 2018 03:13:36 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id b23-v6so24660110lfg.4 for ; Wed, 25 Apr 2018 03:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ENeac4W2MfojulEsoxHaD2oTwMmNUzZOCUw0UV9bAIs=; b=Qh7E8Qcfg3nu8OG85W4oDVbdS0OZR8IKDry5T67lbgfR8KSPnCH55DSbbO2V4Uk24B sBrEvMtCUHA665oW7+KUlCbkPuA+yIObKIxa/Jj1sUDPg3qma6+C8KxB8upd1IvVFwjP cAtlqY4TnN/g5SK6+mvLAa47aZ3s8s9sIfZnYe2FSnBpriFzbirheekL/D3If34CioNa ZVO4IAvRtsm6neXzdleGqznBzsQ/AbArTz6nxZ+LhHBX0frdnJZpaQdzdM3Kauv0Or3c 8Ibb9BmQqAkYHel8fOZaC/dp8uL1zfnzVWf7xcvNe+EpSAiFG/MegRt1sVAV8qR8bR+L jqQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ENeac4W2MfojulEsoxHaD2oTwMmNUzZOCUw0UV9bAIs=; b=o4eCMikFA8ILWW2AfUF4Ry/XqJHl8Pf4BD+gDCeMmuRAwrx83qXlZzX8bDZ+bor7nN lu+Qh9E/0F4jhv40YReR7X5xfM8zP/M1SpQ6FzSb1RgaqSJhuFYyG1/OGjbcp4+5EM0N eG1kjlI0xFeG2n6AsbJlS7cajpUd1RJD3JH7xI01F7I9dGlnY3oQS8BnPwaoGuLvL8cR PHvPOjc8l68NOoErtbKSZQ/ie/Y3DZPOZQMZe5/QxAx2tEF312vYnW9Ero722iN0absD zscxfsZY/VpiMUpEgTv5SQzp7i5tTUw64eqIbpAF9UFRzKQsvrVejYrAE3ldDhaozvSV FAFA== X-Gm-Message-State: ALQs6tB8K26l+XoQGs0ITdzEvIcO3ZB6i8kKS3WHPIRoSGWOCOng13A9 hDRkTfBQur03yv0Fgi4t8XMDL4cB75GIUXdO7n+LGhHU X-Google-Smtp-Source: AIpwx4/V/w7ZVO9bWeqSLJ9dibv5613TGkJNrrX/VgYwM+6ccIz4OLtGVa1gjyhc329YrMpbklCrrEfOmbI3TMsgUkc= X-Received: by 10.46.127.10 with SMTP id a10mr13586626ljd.78.1524651214348; Wed, 25 Apr 2018 03:13:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Wed, 25 Apr 2018 03:13:33 -0700 (PDT) In-Reply-To: <20180425.090347.389055708996810830.mbj@tail-f.com> References: <20180423.220815.526647366558506966.mbj@tail-f.com> <20180425.090347.389055708996810830.mbj@tail-f.com> From: Andy Bierman Date: Wed, 25 Apr 2018 03:13:33 -0700 Message-ID: To: Martin Bjorklund Cc: Kent Watsen , NetMod WG Content-Type: multipart/alternative; boundary="089e082b3ee809b584056aa9869c" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 10:13:40 -0000 --089e082b3ee809b584056aa9869c Content-Type: text/plain; charset="UTF-8" On Wed, Apr 25, 2018 at 12:03 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Apr 23, 2018 at 1:08 PM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > > .... > > > > > > > > > > > > I do not understand the need for a yang-data structure that > > > represents > > > > > data > > > > > > that can be instantiated anywhere and everywhere. > > > > > > > > > > AFAIK noone is proposing that. > > > > > > > > > > > I do not want to break > > > > > > existing tools that expect sibling data nodes in the same module > > > > > namespace > > > > > > to > > > > > > be unique local-names. > > > > > > > > > > > > I would rather stick with the yang-data in RFC 8040 than > introduce a > > > new > > > > > > extension > > > > > > with no restrictions. Standard YANG extensions should be > > > interoperable > > > > > and > > > > > > have > > > > > > a clear purpose. > > > > > > > > > > Of course. > > > > > > > > > > > If we do not need to define what a YANG extension does in > > > > > > a way that can be observed somehow, then it does not need to be a > > > > > standard. > > > > > > > > > > Agreed. > > > > > > > > > > Not sure how any of this helps with the original issue though. > > > > > > > > > > > > > > > > > > You proposed that duplicate nodes were OK: > > > > > > > > module X { > > > > prefix x; > > > > > > > > x:yang-data A { > > > > list foo { ... } > > > > } > > > > > > > > x:yang-data B { > > > > container foo { ... } > > > > } > > > > > > > > } > > > > > > > > > > > > I do not want to allow any duplicates. > > > > > > Yes, I got that. > > > > > > > There are no encoding and parsing rules for instance data > > > > that support this sort of duplicate. > > > > > > This is not correct, as I have demonstrated earlier, and I think you > > > also accepted; if different structures are defined for different rpcs' > > > error-infos, then these structures can have the same child node names. > > > > > > I think that we have to agree on the basics before disussing > > > solutions: > > > > > > 1) Should we do anything at all? > > > > > > (i.e., keep using yang-data in RFC 8040) > > > > > > 2) Should we define structures that only can be used in > > > standalone instance documents? > > > > > > (i.e., *more* restrictive than yang-data in RFC 8040) > > > > > > 3) Should we define structures that can be used in standalone > > > instance documents, error-info contents, and other places that > > > we might not know right now? > > > > > > (i.e., *less* restrictive than yang-data in RFC 8040) > > > > > > > > > Since the current draft says: > > > > > > The "yang-data" extension statement from RFC > > > 8040 [RFC8040] is defined for this purpose, however it is limited in > > > its functionality. > > > > > > The intended use of the "yang-data" extension is to model all or > part > > > of a protocol message, such as the "errors" definition in ietf- > > > restconf.yang [RFC8040], or the contents of a file. However, > > > protocols are often layered such that the header or payload portions > > > of the message can be extended by external documents. The YANG > > > statements that model a protocol need to support this extensibility > > > that is already found in that protocol. > > > > > > > > > I thought we are doing (3). > > > > > > > > > > > The use-case that has come up several times is (1). > > People want to use YANG to define the schema for an XML or JSON > > representation of a stand-alone document. > > > > Item (3) needs to be machine-readable and deterministic for it to be even > > remotely > > feasible as a standard. There is no way a tool should have to match > > > to > > the correct schema, based on the description-stmt inside some > > yang-data-stmt. > > The only data needed must be module + local-name. > > > > The example you gave of different definitions of the leaf is a > > really bad idea. > > We should never try to define different schema for the same instance > data, > > where the module-name and local-name are the same, but the contents are > > different. > > When the context is different this is not a problem. Compare w/ > augment: > > augment "/if:interfaces/if:interface" { > container ipv4 { ... } > } > > augment "/if:interfaces/if:interface-state" { > container ipv4 { ... } > } > > But you are proposing that the target location not be specified, or specified inside a description-stmt. No matter what context you pick, DOUBLE augment is not allowed: augment "/if:interfaces/if:interface" { container ipv4 { ... } } augment "/if:interfaces/if:interface" { container ipv4 { ... } } So yang-data cannot define the same node in multiple contexts. Leaving the context unspecified is not an option. > These augements define the node "ipv4" in the the "ietf-ip" namespace, > but b/c the context is different, there is no risk for confusion. > > > Defining an extension that maps error-info data for a specific RPC might > be > > something worth standardizing. It should not be done with yang-data, > > but rather a different extension just for this purpose. > > See my email to Kent. I don't understand why this can't be done with > yang-data. This said, if we were to do a new version of YANG and > address this problem, we would define a new core keyword for this. > > > /martin > > > Andy > > > > > > > > > > > /martin > > > > > > > Andy > > > > > > > > > > > > > > > > > yang-data definitions define conceptual data nodes (e.g, /x:foo) > > > > Only one data-def-stmt (in yang-data or otherwise) can define a data > node > > > > /x:foo. > > > > The descriptive names for the yang-data (A or B) do not define > > > namespaces. > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > Andy > > > > --089e082b3ee809b584056aa9869c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 25, 2018 at 12:03 AM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Andy B= ierman <andy@yumaworks.com>= wrote:
> On Mon, Apr 23, 2018 at 1:08 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > > ....
> > > > >
> > > > > I do not understand the need for a yang-data struc= ture that
> > represents
> > > > data
> > > > > that can be instantiated anywhere and everywhere.<= br> > > > >
> > > > AFAIK noone is proposing that.
> > > >
> > > > > I do not want to break
> > > > > existing tools that expect sibling data nodes in t= he same module
> > > > namespace
> > > > > to
> > > > > be unique local-names.
> > > > >
> > > > > I would rather stick with the yang-data in RFC 804= 0 than introduce a
> > new
> > > > > extension
> > > > > with no restrictions.=C2=A0 Standard YANG extensio= ns should be
> > interoperable
> > > > and
> > > > > have
> > > > > a clear purpose.
> > > >
> > > > Of course.
> > > >
> > > > > If we do not need to define what a YANG extension = does in
> > > > > a way that can be observed somehow, then it does n= ot need to be a
> > > > standard.
> > > >
> > > > Agreed.
> > > >
> > > > Not sure how any of this helps with the original issue = though.
> > > >
> > > >
> > >
> > > You proposed that duplicate nodes were OK:
> > >
> > > module X {
> > > prefix x;
> > >
> > > x:yang-data A {
> > >=C2=A0 =C2=A0 list foo { ... }
> > > }
> > >
> > > x:yang-data B {
> > >=C2=A0 =C2=A0container foo { ... }
> > > }
> > >
> > > }
> > >
> > >
> > > I do not want to allow any duplicates.
> >
> > Yes, I got that.
> >
> > > There are no encoding and parsing rules for instance data > > > that support this sort of duplicate.
> >
> > This is not correct, as I have demonstrated earlier, and I think = you
> > also accepted; if different structures are defined for different = rpcs'
> > error-infos, then these structures can have the same child node n= ames.
> >
> > I think that we have to agree on the basics before disussing
> > solutions:
> >
> >=C2=A0 =C2=A01)=C2=A0 Should we do anything at all?
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(i.e., keep using yang-data in RFC 8040= )
> >
> >=C2=A0 =C2=A02)=C2=A0 Should we define structures that only can be= used in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0standalone instance documents?
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(i.e., *more* restrictive than yang-dat= a in RFC 8040)
> >
> >=C2=A0 =C2=A03)=C2=A0 Should we define structures that can be used= in standalone
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0instance documents, error-info contents= , and other places that
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0we might not know right now?
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(i.e., *less* restrictive than yang-dat= a in RFC 8040)
> >
> >
> > Since the current draft says:
> >
> >=C2=A0 =C2=A0 The "yang-data" extension statement from R= FC
> >=C2=A0 =C2=A0 8040 [RFC8040] is defined for this purpose, however = it is limited in
> >=C2=A0 =C2=A0 its functionality.
> >
> >=C2=A0 =C2=A0 The intended use of the "yang-data" extens= ion is to model all or part
> >=C2=A0 =C2=A0 of a protocol message, such as the "errors"= ; definition in ietf-
> >=C2=A0 =C2=A0 restconf.yang [RFC8040], or the contents of a file.= =C2=A0 However,
> >=C2=A0 =C2=A0 protocols are often layered such that the header or = payload portions
> >=C2=A0 =C2=A0 of the message can be extended by external documents= .=C2=A0 The YANG
> >=C2=A0 =C2=A0 statements that model a protocol need to support thi= s extensibility
> >=C2=A0 =C2=A0 that is already found in that protocol.
> >
> >
> > I thought we are doing (3).
> >
> >
> >
> The use-case that has come up several times is (1).
> People want to use YANG to define the schema for an XML or JSON
> representation of a stand-alone document.
>
> Item (3) needs to be machine-readable and deterministic for it to be e= ven
> remotely
> feasible as a standard. There is no way a tool should have to match &l= t;x:foo>
> to
> the correct schema, based on the description-stmt inside some
> yang-data-stmt.
> The only data needed must be module + local-name.
>
> The example you gave of different definitions of the <reason> le= af is a
> really bad idea.
> We should never try to define different schema for the same instance d= ata,
> where the module-name and local-name are the same, but the contents ar= e
> different.

When the context is different this is not a problem.=C2=A0 Compare w/
augment:

=C2=A0 =C2=A0 augment "/if:interfaces/if:interface" {
=C2=A0 =C2=A0 =C2=A0 container ipv4 { ... }
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 augment "/if:interfaces/if:interface-state" {<= br> =C2=A0 =C2=A0 =C2=A0 container ipv4 { ... }
=C2=A0 =C2=A0 }



But you are proposing t= hat the target location not be specified,
or specified inside a d= escription-stmt.

No matter what context you pick, = DOUBLE augment is not allowed:


=C2=A0 =C2=A0 a= ugment "/if:interfaces/if:interface" {
=C2=A0 =C2=A0 =C2=A0 co= ntainer ipv4 { ... }
=C2=A0 =C2=A0 }


= =C2=A0 =C2=A0 augment "/if:interfaces/if:interface" {
=C2=A0 = =C2=A0 =C2=A0 container ipv4 { ... }
=C2=A0 =C2=A0 }

<= /div>

So yang-data cannot define the same node in multip= le contexts.
Leaving the context unspecified is not an option.



=C2=A0
These augements define the node "ipv4" in the the "ietf-ip&q= uot; namespace,
but b/c the context is different, there is no risk for confusion.

> Defining an extension that maps error-info data for a specific RPC mig= ht be
> something worth standardizing.=C2=A0 It should not be done with yang-d= ata,
> but rather a different extension just for this purpose.

See my email to Kent.=C2=A0 I don't understand why this can't be do= ne with
yang-data.=C2=A0 This said, if we were to do a new version of YANG and
address this problem, we would define a new core keyword for this.


/martin




Andy

=C2=A0


>
>
>
> > /martin
> >
>
> Andy
>
>
> >
> >
> >
> > > yang-data definitions define conceptual data nodes (e.g, /x:= foo)
> > > Only one data-def-stmt (in yang-data or otherwise) can defin= e a data node
> > > /x:foo.
> > > The descriptive names for the yang-data (A or B) do not defi= ne
> > namespaces.
> > >
> > >
> > >
> > > > /martin
> > > >
> > > >
> > > Andy
> >

--089e082b3ee809b584056aa9869c-- From nobody Wed Apr 25 03:42:29 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E5C12DA6F; Wed, 25 Apr 2018 03:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtSIRGwN810O; Wed, 25 Apr 2018 03:42:25 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6163712DA6E; Wed, 25 Apr 2018 03:42:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 85290CFF; Wed, 25 Apr 2018 12:42:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id nkZA4Z_Nufd9; Wed, 25 Apr 2018 12:42:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Apr 2018 12:42:23 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5CA9F20035; Wed, 25 Apr 2018 12:42:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YYfV_fcvbHbg; Wed, 25 Apr 2018 12:42:22 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D153320031; Wed, 25 Apr 2018 12:42:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 736F242C1339; Wed, 25 Apr 2018 12:42:22 +0200 (CEST) Date: Wed, 25 Apr 2018 12:42:22 +0200 From: Juergen Schoenwaelder To: Rohit R Ranade Cc: "netconf@ietf.org" , "netmod@ietf.org" Message-ID: <20180425104222.2asz5wiuierdumr4@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Rohit R Ranade , "netconf@ietf.org" , "netmod@ietf.org" References: <991B70D8B4112A4699D5C00DDBBF878A6B1E92F6@DGGEMA502-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B1E92F6@DGGEMA502-MBX.china.huawei.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] [Netconf] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 10:42:28 -0000 On Wed, Apr 25, 2018 at 04:22:24AM +0000, Rohit R Ranade wrote: > Hi All, > > I plan to implement this draft and hence had some implementation related clarifications. > > > 1. I feel that there should be more text added about "origin" filtering mechanism. I am not clear about some aspects of origin filtering. > > RFC 8342 : NMDA RFC provides the below example > > or:origin="or:intended"> > > lo0 > loopback > 127.0.0.1 > ::1 > > > If user provides as "system" ONLY, then he will NOT get this record in output. Because the keys have originated from "intended" . Right ? > So, If user wants to get the system originated data, he MUST give all the origins in the where the keys of the system data have originated from. Can you please confirm whether this is OK. I would expect that or:system would select the ip-address tagged with or:origin="or:system" and that the system would return any necessary container or list elements and the necessary key elements (since otherwise the value returned is just useless). So the result would be: lo0 127.0.0.1 > Another example given in RFC 8342 is as below: > or:origin="or:intended"> > > lo0 > 127.0.0.1 > ::1 > > > > ? Here keys are originated from "system", but it is under container of "intended". So if user gives "system" for "origin-filter", the output will still NOT have this instance output ? We allow origin values on containers or lists in order to inherit them, i.e., to achieve a more compact encoding. Anyway, if a leaf node matches, then I think any encompassing containers and list should be included in the result so that the matching leaf can be reported. So you would return lo0 127.0.0.1 ::1 instead of not returning anything at all. > ? Also the container is not defined as "presence" in C.3. Interface Example, but still it has origin whether that is Ok ? Why not? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 25 03:55:33 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C705F12421A for ; Wed, 25 Apr 2018 03:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_qPd4q3v9_t for ; Wed, 25 Apr 2018 03:55:30 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB920120721 for ; Wed, 25 Apr 2018 03:55:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 85606755; Wed, 25 Apr 2018 12:55:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id BQPYubN-DFiE; Wed, 25 Apr 2018 12:55:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Apr 2018 12:55:28 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EB6820031; Wed, 25 Apr 2018 12:55:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WGngJ7iKlgsH; Wed, 25 Apr 2018 12:55:27 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE0CE20035; Wed, 25 Apr 2018 12:55:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CDB3242C1393; Wed, 25 Apr 2018 12:55:27 +0200 (CEST) Date: Wed, 25 Apr 2018 12:55:27 +0200 From: Juergen Schoenwaelder To: Rohit R Ranade Cc: "netmod@ietf.org" Message-ID: <20180425105527.jud4k2vxnzl5j322@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Rohit R Ranade , "netmod@ietf.org" References: <991B70D8B4112A4699D5C00DDBBF878A6B1E8D96@DGGEMA502-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B1E8D96@DGGEMA502-MBX.china.huawei.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Comments on draft-ietf-netconf-nmda-netconf-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 10:55:32 -0000 On Tue, Apr 24, 2018 at 01:09:07PM +0000, Rohit R Ranade wrote: > Hi All, > > Please find some comments for the draft. > > > 1. If "config-filter" leaf is not given for whether we can add explicit text that both config=true and config=false nodes will be selected. Well, if there is no filter, you do not filter. Is this not obvious? > 2. In the YANG module description for "config-filter" , also it is not clear about what happens if the leaf is not given in filter. I feel better we keep the style like RESTCONF RFC 8040 Section 4.8.1 , with "content" having config/nonconfig/all Why? Even in RESTCONF the content query parameter can be absent. If this query parameter is not present, the default value is "all". > 3. Regarding the "max-depth" parameter, I feel we should take the text about how "depth" is calculated for each node from RESTCONF RFC from Section 4.8.2 and add it to this draft. What will be depth of parent keys which are auto-selected when selecting on child nodes. Maybe some example regarding using of "max-depth" will be helpful. I do not think the RESTCONF text talks about depths of parent keys which are auto-selected. Here is what the I-D says: "For each node selected by the filter, this parameter selects how many conceptual sub-tree levels should be returned in the reply. If the depth is 1, the reply includes just the selected nodes but no children. If the depth is 'unbounded', all descendant nodes are included."; What exactly is missing? > 4. For the filter mechanism, since there are 4 filters (filter-spec and config-filter and max-depth and with-defaults), whether we can mention that all these filters are AND'ed. Also whether there is a suggested order to apply filter ? I think "max-depth" filter has to be applied last. Others maybe any order is OK. Yes, I think the idea is that all filters apply. Do you have a concrete proposal? > 5. negated-origin-filter : Regarding this I feel we can add a sentence as to when user should use "negated-origin-filter" , as "origin-filter" also can be used for this purpose. Well, the set of origin values is not necessarily static. There are a bunch of concrete values defined in RFC 8342 but technically origin values are identities and thus extensible. Hence, if you want every config true node which is not origin intended, then you better use negated-origin-filter since trying list all origin-filter values is at least fragile. Bottom line: if I want 'all except some', I use "negated-origin-filter" and if I want 'all where' I use "origin-filter". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 25 05:38:55 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03332120454 for ; Wed, 25 Apr 2018 05:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJh-yYzKf_ZX for ; Wed, 25 Apr 2018 05:38:51 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 82E77129C6E for ; Wed, 25 Apr 2018 05:38:42 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 4625F1820158; Wed, 25 Apr 2018 14:44:17 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id C0BB21820055; Wed, 25 Apr 2018 14:44:14 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund Cc: nite@hq.sk, netmod@ietf.org In-Reply-To: <20180424.164323.134787755202916169.mbj@tail-f.com> References: <20180423165104.zi7g75tifhekmezh@elstar.local> <87zi1sr896.fsf@nic.cz> <20180424.164323.134787755202916169.mbj@tail-f.com> Mail-Followup-To: Martin Bjorklund , nite@hq.sk, netmod@ietf.org Date: Wed, 25 Apr 2018 14:38:41 +0200 Message-ID: <871sf3v4tq.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 12:38:54 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> Robert Varga writes: >> >> > On 23/04/18 18:51, Juergen Schoenwaelder wrote: >> >> Some people will say that the cost of a new language version is high. >> >> (Well, when we did 1.1, some people said it will never be deployed.) >> >> Anyway, not bumping the YANG version number but having instead several >> >> (optional) language extensions is just hiding the version number >> >> change under the carpet. >> > >> > Not quite, as extensions allow for modular/incremental evolution, as an >> > implementer I do not have to go through a long development cycle where I >> > need to rewire language aspects just to get the features my users need >> > for their models... >> >> But what prevents you from forking YANG, indicating it in the >> "yang-version" string and implementing your new statements as built-ins? >> >> It is tempting to think about extensions as a magic for adding modular >> extensions but it breaks down as soon as such extensions interfere with >> the YANG core (with and each other, or both). > > Sure, nothing new here. This is how the extension mechanism is > designed. Do you feel that there are so many standard extensions that My objections are also not new. Implementations are permitted to ignore extensions, but if an extension affects the resulting schema, then implementation A that supports the extension may end up working with another schema than implementation B that doesn't support the extension. This situation has to be avoided. > interfere with each other that we actually have a problem? I strongly Perhaps not yet, but we do have extensions (or proposals thereof) that interfere with core YANG. And my impression is that OpenConfig is going to use extensions for creating their own YANG silo. > agree that we need to be careful with standard extensions, and I > strongly encourage vendors to not define extensions that interfere > with YANG core (been there, done that, bad idea). > > In the case of yang-data, the fact is that it *is* used in standard > models (in ways not originally anticipated), and vendors have similar > proprietary extensions (we have a tailf:structure, and I think others > have reported similar things). I don't know how much effort those vendors invested into the specification of such extensions, but the text of the current draft and module descriptions leave quite a few questions unanswered. Here are just a few that come to my mind: - What is the accessible tree for XPath evaluations and leafrefs? In particular, error messages might want to refer to state data. Is it possible? - This sentence makes no sense: "The XPath document root is the extension statement itself, ..." A YANG statement cannot be an XPath node. - What is the meaning of leaf and leaf-list default values? In RFC 7950 it is defined in terms of server behaviour but there is no server for yang-data. - What does it mean if an action is defined inside yang-data? - If a module is imported without revision and its groupings/typedefs are used inside yang-data, how is the exact revision of the imported module determined? I suspect that users of such extensions accept the fact that some amount of hand-waving is necessary. But then, why all this hassle? Why cannot normal YANG be used for specifying a schema that is not intended for an NM protocol? It requires just a little bit more hand-waving. The draft doesn't explain why the extension is needed. Also, I am quite sure that YANG experts can use it carefully so that it makes sense. But as a Standard Track document it becomes an official part of YANG that seems to give unsuspecting users enough rope for hanging themselves. Lada > > > > /martin -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Apr 25 05:56:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7196312422F for ; Wed, 25 Apr 2018 05:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD7syJJMcsEJ for ; Wed, 25 Apr 2018 05:56:37 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBE71205D3 for ; Wed, 25 Apr 2018 05:56:37 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 823201AE02A7; Wed, 25 Apr 2018 14:56:36 +0200 (CEST) Date: Wed, 25 Apr 2018 14:56:36 +0200 (CEST) Message-Id: <20180425.145636.875182615279072475.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: rohitrranade@huawei.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180425105527.jud4k2vxnzl5j322@elstar.local> References: <991B70D8B4112A4699D5C00DDBBF878A6B1E8D96@DGGEMA502-MBX.china.huawei.com> <20180425105527.jud4k2vxnzl5j322@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Comments on draft-ietf-netconf-nmda-netconf-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 12:56:39 -0000 Hi, Juergen Schoenwaelder wrote: > On Tue, Apr 24, 2018 at 01:09:07PM +0000, Rohit R Ranade wrote: [...] > > 4. For the filter mechanism, since there are 4 filters > > (filter-spec and config-filter and max-depth and with-defaults), > > whether we can mention that all these filters are AND'ed. Also whether > > there is a suggested order to apply filter ? I think "max-depth" > > filter has to be applied last. Others maybe any order is OK. > > Yes, I think the idea is that all filters apply. Do you have a > concrete proposal? Note that the current document has this in the description statement of "get-data": The content returned by get-data must satisfy all filters, i.e., the filter criteria are logically ANDed. /martin From nobody Wed Apr 25 06:55:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBE6126DFF for ; Wed, 25 Apr 2018 06:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Yxm1DoFkaMi for ; Wed, 25 Apr 2018 06:55:54 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F68B126D45 for ; Wed, 25 Apr 2018 06:55:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 21560755; Wed, 25 Apr 2018 15:55:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id L6RtmxljzUsm; Wed, 25 Apr 2018 15:55:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Apr 2018 15:55:53 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0314E20035; Wed, 25 Apr 2018 15:55:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BuBa5GogsScr; Wed, 25 Apr 2018 15:55:52 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8202420031; Wed, 25 Apr 2018 15:55:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4595F42C1B0F; Wed, 25 Apr 2018 15:55:51 +0200 (CEST) Date: Wed, 25 Apr 2018 15:55:50 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: lhotka@nic.cz, netmod@ietf.org Message-ID: <20180425135550.jwwbwtpofd7vz52z@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423.215110.441857992070858100.mbj@tail-f.com> <87wowwr826.fsf@nic.cz> <20180424.163601.648085760139600532.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180424.163601.648085760139600532.mbj@tail-f.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 13:55:56 -0000 On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > > > Hi, > > > > > > I am not sure what this statement tells us re. the issue in this email > > > thread. > > > > It tells us that, in my view, the approach taken in this document is a > > bad idea. > > Do you mean that the WG shoud drop this document? And people that > need yang-data should continue to use the version in 8040? Or that > people that need yang-data do not have a valid use case and they > should do something else? One option is that people use yang-data as defined in RFC 8040 until there is a version of YANG that has a proper and complete integrated solution. (If for example yang-data is used to declare error content for RPCs, then more extensions are needed or a proper integration into YANG. Is it really good to introduce augment-yang-data (instead of making augment work with say 'data' in YANG 1.2)? And then we do uses-yang-data etc. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 25 07:05:39 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357D2120047 for ; Wed, 25 Apr 2018 07:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM3LbsVDItN5 for ; Wed, 25 Apr 2018 07:05:35 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45B1126DEE for ; Wed, 25 Apr 2018 07:05:35 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:5ce2:b9ff:fe81:cca6]) by mail.nic.cz (Postfix) with ESMTPSA id 22B0762CF2; Wed, 25 Apr 2018 16:05:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1524665134; bh=WifznDgMgezGh4DECVGO9y3mkANOfx9f1osNIrjmsyA=; h=From:To:Date; b=N5KBnBPQDIjQhFSbmF1PRO9+skBkUG3TQeWsl7e6YC3+WY6/RRwyhPc04J/m4KNR1 8hf3ArUHq/7LwbLDM4hA2CBPaG8a1eLgSqBrGKRO+eP0VJfcNW7ylmTX6uaWSbEcX5 h0sz1Url+FyIYR3bjAmPUOPZV53OhCeHwjtpoidk= Message-ID: <3f6631298f1f7e0c752d7300585962b04ddc49cc.camel@nic.cz> From: Ladislav Lhotka To: Juergen Schoenwaelder , Martin Bjorklund Cc: netmod@ietf.org Date: Wed, 25 Apr 2018 16:05:38 +0200 In-Reply-To: <20180425135550.jwwbwtpofd7vz52z@elstar.local> References: <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423.215110.441857992070858100.mbj@tail-f.com> <87wowwr826.fsf@nic.cz> <20180424.163601.648085760139600532.mbj@tail-f.com> <20180425135550.jwwbwtpofd7vz52z@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 14:05:38 -0000 On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote: > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund wrote: > > Ladislav Lhotka wrote: > > > Martin Bjorklund writes: > > > > > > > Hi, > > > > > > > > I am not sure what this statement tells us re. the issue in this email > > > > thread. > > > > > > It tells us that, in my view, the approach taken in this document is a > > > bad idea. > > > > Do you mean that the WG shoud drop this document? And people that > > need yang-data should continue to use the version in 8040? Or that > > people that need yang-data do not have a valid use case and they > > should do something else? > > One option is that people use yang-data as defined in RFC 8040 until IMO, people should use plain YANG. With the new YANG library it will be possible to confine such non-NM schemas in a special datastore so that the intention should be clear and multi-module schemas with all the additional data (versions, features, deviations) can be used. Lada > there is a version of YANG that has a proper and complete integrated > solution. (If for example yang-data is used to declare error content > for RPCs, then more extensions are needed or a proper integration into > YANG. Is it really good to introduce augment-yang-data (instead of > making augment work with say 'data' in YANG 1.2)? And then we do > uses-yang-data etc. > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Apr 25 08:04:48 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309DB124239 for ; Wed, 25 Apr 2018 08:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzkT4Eo08uPA for ; Wed, 25 Apr 2018 08:04:43 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA03127286 for ; Wed, 25 Apr 2018 08:04:42 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id q5-v6so25940635lff.12 for ; Wed, 25 Apr 2018 08:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yRzhk0MRtZDCLIXdx0zJbQWRZoIlErpFcl1TZTb0aYg=; b=Af+hPHE+BV00l8d5Mnw0EQgp7/yYn01M+P4ksEzsxPi0YNBE/qVhtpUXJyNg3iaajM wpVExF6reSZaMwSrit9SELJ3IRuPLODDT3Swe1JItkoIYpKPbTD7OVt6PowxS0PXYUw1 k9jFO73CH0JsVaYGNPm5GmwQuzYJEDqaBB2WXA73M9nbDVehOtpqzoawkwl7kz8Vop7k qlzgViUurXAlbbrACKSWS16VNw24GMGOr0LD6tEFbrXK2Jc8pdHoTvBlAB8ULCkix9E6 26O0Ae/vixc2WNL9+3sBnirijXORZwexz1RyukuG72z8uk1JMis/QO22+nomng0ieE0P 0jAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yRzhk0MRtZDCLIXdx0zJbQWRZoIlErpFcl1TZTb0aYg=; b=FFz3q8VDXAoB6a4zG2DLKamRYhbhCFx0MkCCMkVRm9QROONqNq97E4DYMeWnp8nKiq JB/8C5w95SdlbRtQo8AOi43i8DHnznUx8XAArO86ihgOr/LNXpHUzcSzKKSabXV+VvU6 ux3nHLaP9v6EweSrSgb+GCCjNHkjdIKVrvRHWkvc6Poh5Ujgn0UgorSBAwSxwJnYS2qz mtjHMG47yjIkGJn6DcqvdaYTAJp+PdV9/tQJbY9VEBxwyPgpp/Rg0XQ6PFWVaJLiAY1X CSumXACMvvifwIP/lkdM9OO6CTLnXKZdtEpz+Evgerg6C5cpyXqnlQjKMGWUwB4bUzor 6dVQ== X-Gm-Message-State: ALQs6tClHD+1n2/n4B/TAxZQnbbDRSU4KGStlpOrObDjTiEW37XoOWb1 TPOZb9D5EBOPeCVu1dsjZRKdYylOBrhnO7Kuo96xYw== X-Google-Smtp-Source: AB8JxZrpwaaMNgDyXW7b1smFGiudtm2pzmCFxhM/jNWF41fxXVEvyTbB/qWTPxuxrnVi4dgHPaaLYFiHaZPr7pJZAhg= X-Received: by 10.46.151.206 with SMTP id m14mr770456ljj.102.1524668680936; Wed, 25 Apr 2018 08:04:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Wed, 25 Apr 2018 08:04:39 -0700 (PDT) In-Reply-To: <3f6631298f1f7e0c752d7300585962b04ddc49cc.camel@nic.cz> References: <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423.215110.441857992070858100.mbj@tail-f.com> <87wowwr826.fsf@nic.cz> <20180424.163601.648085760139600532.mbj@tail-f.com> <20180425135550.jwwbwtpofd7vz52z@elstar.local> <3f6631298f1f7e0c752d7300585962b04ddc49cc.camel@nic.cz> From: Andy Bierman Date: Wed, 25 Apr 2018 08:04:39 -0700 Message-ID: To: Ladislav Lhotka Cc: Juergen Schoenwaelder , Martin Bjorklund , NetMod WG Content-Type: multipart/alternative; boundary="883d24f22e1420e4ae056aad976d" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 15:04:46 -0000 --883d24f22e1420e4ae056aad976d Content-Type: text/plain; charset="UTF-8" On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka wrote: > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote: > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > > > Martin Bjorklund writes: > > > > > > > > > Hi, > > > > > > > > > > I am not sure what this statement tells us re. the issue in this > email > > > > > thread. > > > > > > > > It tells us that, in my view, the approach taken in this document is > a > > > > bad idea. > > > > > > Do you mean that the WG shoud drop this document? And people that > > > need yang-data should continue to use the version in 8040? Or that > > > people that need yang-data do not have a valid use case and they > > > should do something else? > > > > One option is that people use yang-data as defined in RFC 8040 until > > IMO, people should use plain YANG. With the new YANG library it will be > possible > to confine such non-NM schemas in a special datastore so that the intention > should be clear and multi-module schemas with all the additional data > (versions, > features, deviations) can be used. > > I don't see how yang-data interferes with "plain YANG" at all. It is for data that is not in scope for plain YANG. A plain client can ignore yang-data and not affect and RPC, notification, or data definitions in plain YANG. > Lada > > Andy > > there is a version of YANG that has a proper and complete integrated > > solution. (If for example yang-data is used to declare error content > > for RPCs, then more extensions are needed or a proper integration into > > YANG. Is it really good to introduce augment-yang-data (instead of > > making augment work with say 'data' in YANG 1.2)? And then we do > > uses-yang-data etc. > > > > /js > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --883d24f22e1420e4ae056aad976d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
On Wed, 2018-04-25 at 15:55 += 0200, Juergen Schoenwaelder wrote:
> On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> > > Martin Bjorklund <mbj@t= ail-f.com> writes:
> > >
> > > > Hi,
> > > >
> > > > I am not sure what this statement tells us re. the issu= e in this email
> > > > thread.
> > >
> > > It tells us that, in my view, the approach taken in this doc= ument is a
> > > bad idea.
> >
> > Do you mean that the WG shoud drop this document?=C2=A0 And peopl= e that
> > need yang-data should continue to use the version in 8040?=C2=A0 = Or that
> > people that need yang-data do not have a valid use case and they<= br> > > should do something else?
>
> One option is that people use yang-data as defined in RFC 8040 until
IMO, people should use plain YANG. With the new YANG library it will be pos= sible
to confine such non-NM schemas in a special datastore so that the intention=
should be clear and multi-module schemas with all the additional data (vers= ions,
=C2=A0features, deviations) can be used.


I don't see how yang-data interfer= es with "plain YANG" at all.
It is for data that is not= in scope for plain YANG.
A plain client can ignore yang-data and= not affect and RPC, notification, or data
definitions in plain Y= ANG.

=C2=A0
Lada


Andy
=C2=A0
> there is a version of YANG that has a proper and complete integrated > solution. (If for example yang-data is used to declare error content > for RPCs, then more extensions are needed or a proper integration into=
> YANG. Is it really good to introduce augment-yang-data (instead of
> making augment work with say 'data' in YANG 1.2)? And then we = do
> uses-yang-data etc.
>
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--883d24f22e1420e4ae056aad976d-- From nobody Wed Apr 25 08:14:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B052124239 for ; Wed, 25 Apr 2018 08:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIm-k0d68xrh for ; Wed, 25 Apr 2018 08:14:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21531124205 for ; Wed, 25 Apr 2018 08:14:05 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:5ce2:b9ff:fe81:cca6]) by mail.nic.cz (Postfix) with ESMTPSA id 635A662CD8; Wed, 25 Apr 2018 17:14:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1524669243; bh=Nk97b3J/H2dAnhdLZkcLRX7A13DWRWsk+KsNNwLJ9pI=; h=From:To:Date; b=GmizkyFGaRvax9zeuLLrV9YR2ZQYHEDom2F20tRiaKRgSKxN/0oqFDSDMK/PCJJNY AFxP8ylEvMTv12gNceO0aO6oCabtNDPgxg3sgfyPgkhdJW49y7A4Ss6g0QwNfS5wDp lx0g0xi/5EiuC8IxJoMId9ZBMqJiNE3ERxtZgatg= Message-ID: <66a94c163cf41aad4def540141a38ebb19d3ba24.camel@nic.cz> From: Ladislav Lhotka To: Andy Bierman Cc: Juergen Schoenwaelder , Martin Bjorklund , NetMod WG Date: Wed, 25 Apr 2018 17:14:07 +0200 In-Reply-To: References: <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423.215110.441857992070858100.mbj@tail-f.com> <87wowwr826.fsf@nic.cz> <20180424.163601.648085760139600532.mbj@tail-f.com> <20180425135550.jwwbwtpofd7vz52z@elstar.local> <3f6631298f1f7e0c752d7300585962b04ddc49cc.camel@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 15:14:08 -0000 On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: > > > On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka wrote: > > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote: > > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > > > > > Martin Bjorklund writes: > > > > > > > > > > > Hi, > > > > > > > > > > > > I am not sure what this statement tells us re. the issue in this > > email > > > > > > thread. > > > > > > > > > > It tells us that, in my view, the approach taken in this document is a > > > > > bad idea. > > > > > > > > Do you mean that the WG shoud drop this document? And people that > > > > need yang-data should continue to use the version in 8040? Or that > > > > people that need yang-data do not have a valid use case and they > > > > should do something else? > > > > > > One option is that people use yang-data as defined in RFC 8040 until > > > > IMO, people should use plain YANG. With the new YANG library it will be > > possible > > to confine such non-NM schemas in a special datastore so that the intention > > should be clear and multi-module schemas with all the additional data > > (versions, > > features, deviations) can be used. > > > > I don't see how yang-data interferes with "plain YANG" at all. > It is for data that is not in scope for plain YANG. My question is why this extension is needed in the first place. > A plain client can ignore yang-data and not affect and RPC, notification, or > data > definitions in plain YANG. A plain (NC/RC) client should never see such data even if it is not protected by yang-data in YANG. On the other hand, tools will be able to process such schemas (generate the ascii tree, convert it to something else, generate sample instances etc.) without explicitly supporting yang-data. Lada > > > > Lada > > > > Andy > > > > there is a version of YANG that has a proper and complete integrated > > > solution. (If for example yang-data is used to declare error content > > > for RPCs, then more extensions are needed or a proper integration into > > > YANG. Is it really good to introduce augment-yang-data (instead of > > > making augment work with say 'data' in YANG 1.2)? And then we do > > > uses-yang-data etc. > > > > > > /js > > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Apr 25 16:16:49 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4223B12D88E for ; Wed, 25 Apr 2018 16:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47eoC1NuIKZ1 for ; Wed, 25 Apr 2018 16:16:44 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29A412D86E for ; Wed, 25 Apr 2018 16:16:44 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3PNF0Ag003539; Wed, 25 Apr 2018 16:16:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=MLs1G2FrlpuL+mBbgRmLZyUhsPnVsByaZYNxhQrgOTY=; b=0BlY3lNzWdqReebTqeMWzXdrsJp3bYQK+aomKfYnAy1rq8Ad3ahm4VgmdYsgyeQO4aDU QWInOd5w+CgUCVplNCLs7641oDIs2Slf2fQOdsU7xPL1zlJD3n7L7NOWqLDKrXEKZ/B3 NnvipKtqDbTybp6CYTHJXdUi1CU8mB2OQ+GkorukCp4+FtRw9vSdyud4sQtte1gxQqI1 BgwA2Ka3n8ak+SIWE7+hoKxwMlEldTJ/8Hn8vHzuaR243IV2d4PgTHAbFxBAL7D+DTFM WHXzyt8ARVyRTyyKqmuS871Nqs4H0VBaOcPUEFs3hJTl+LJy04/emSIQePBs2tq1z5zs rw== Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0178.outbound.protection.outlook.com [216.32.180.178]) by mx0b-00273201.pphosted.com with ESMTP id 2hk33eg0e6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 25 Apr 2018 16:16:41 -0700 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3642.namprd05.prod.outlook.com (10.174.243.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.715.7; Wed, 25 Apr 2018 23:16:38 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965%6]) with mapi id 15.20.0715.015; Wed, 25 Apr 2018 23:16:38 +0000 From: Kent Watsen To: "mjethanandani@gmail.com" , "lyihuang16@gmail.com" , "sagarwal12@gmail.com" , "dblair@cisco.com" CC: "netmod@ietf.org" Thread-Topic: IPR call on draft-ietf-netmod-acl-model-18 Thread-Index: AQHT3Ot2MTVWKVAlf0G2oQe4g5DO7Q== Date: Wed, 25 Apr 2018 23:16:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3642; 7:gG3zMIokKATTjUEuM3Zyq5G8TwVloNK+T18HlGFXS1HkLWJfzjfZQZYze6OO797mqmV2e4iSHHcSE0k1GjyEjb40Gav/GBKGbsW4JwnzTvVHR0T+XPt0xWHt62a/il1hMVvqe1I/f6gyupYMet32U1eQ//Lvz5gKNdua65Olk1nXw/EIu/irdFBxozKRBIMoaE2JMFzKZxd0Yxa2qpjrItF1S43ajKzP5+1pxAHBFKxCtW1c5LQj+lSl8bbKWhMs x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM5PR05MB3642; x-ms-traffictypediagnostic: DM5PR05MB3642: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231232)(944501410)(52105095)(6055026)(6041310)(20161123558120)(20161123562045)(201703131423095)(201703011903075)(201702281528075)(20161123555045)(201703061421075)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR05MB3642; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3642; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7966004)(366004)(376002)(346002)(39860400002)(396003)(39380400002)(199004)(189003)(53936002)(5660300001)(6116002)(3660700001)(5250100002)(82746002)(68736007)(36756003)(6486002)(102836004)(2616005)(99286004)(3280700002)(316002)(25786009)(4326008)(86362001)(26005)(2906002)(83716003)(39060400002)(2201001)(486006)(476003)(81156014)(305945005)(33656002)(3846002)(2900100001)(97736004)(966005)(186003)(6436002)(66066001)(508600001)(6512007)(81166006)(58126008)(110136005)(105586002)(14454004)(8936002)(8676002)(106356001)(6306002)(6506007)(2501003)(7736002)(48284002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3642; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: R/pRpjwNQpLwBZM2z1T59o/I3nufOQ0XvHR70XgaPKBcBXHmj61BxwvXn0p69nGjRZS863Z3GqH4IFBn1cq1IEoNZ32523GTlz7F53Llhmu/xl2jhNMMJUW+r9Ogau4N6fWwMyMR4Wv4XoaH8OBpLQihYJCqIs/MTiqAJKWaR4W909yZo7TTm4yhL4U8bEvM spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5E96F0F115332C439A7F4180EF49B60F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 8793a727-2f33-462c-b95d-08d5ab0298aa X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 8793a727-2f33-462c-b95d-08d5ab0298aa X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2018 23:16:38.1482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3642 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-25_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=980 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804250214 Archived-At: Subject: [netmod] IPR call on draft-ietf-netmod-acl-model-18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 23:16:47 -0000 QXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCg0KQXMgcGFydCBvZiBTaGVwaGVyZCB3cml0ZS11 cCBmb3IgdGhlIGFjbC1tb2RlbCBkcmFmdCwgd2UgbmVlZCB0byBlbnN1cmUgdGhhdCBhbGwgSVBS IGhhcyBiZWVuIGRlY2xhcmVkLiAgVGhlcmUgd2FzIGFuIElQUi1jYWxsIGJlZm9yZSwgd2hlbiB0 aGVyZSB3YXMgYSBkaWZmZXJlbnQgc2V0IG9mIGF1dGhvcnMgaW52b2x2ZWQsIGJ1dCBub3Qgc2lu Y2UsIHNvIGl0IHNlZW1zIHBydWRlbnQgdG8gZG8gYW5vdGhlciBjYWxsIG5vdy4gDQoNCkFyZSB5 b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92 ZT8NCg0KDQpQbGVhc2Ugc3RhdGUgZWl0aGVyOg0KICAgICJObywgSSdtIG5vdCBhd2FyZSBvZiBh bnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KICBvcg0KICAgICJZZXMsIEknbSBh d2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoNCg0KSWYgeWVzLCBoYXMg dGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVz DQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8g UGxlYXNlIHN0YXRlDQplaXRoZXI6DQogICAgIlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9z ZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0KICBvcg0KICAgICJObywgdGhl IElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KDQpJZiBubywgcGxlYXNlIHByb3ZpZGUgYW55 IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsgYXBwcm9wcmlhdGUuDQoNCg0KSWYgeW91IGFy ZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IsIHBsZWFzZSBhbnN3 ZXIgdGhlDQphYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3 aGV0aGVyIG9yIG5vdCB5b3UgYXJlDQphd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRv Y3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQNCnN0YWdlIHVudGlsIGEgcmVzcG9u c2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkDQpjb250cmli dXRvci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVT U0FHRSdTDQpUTyBMSU5FUy4NCg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9y IGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQNCmFzIGFuIGF1dGhvciBvciBj b250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZQ0K SUVURiBJUFIgcnVsZXMgd2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlm IHlvdSBhcmUgYXdhcmUNCm9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24s IG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nDQppbiBhbnkgY29udHJpYnV0aW9uIG9y IGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yDQptb3JlIGlu Zm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZSBhbmQNCmh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3Bl cnR5Lg0KDQpUaGFuayB5b3UsDQoNCktlbnQgLy8gZG9jdW1lbnQgc2hlcGhlcmQgYW5kIGNvLWNo YWlyDQoNCg0KUFM6IFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2Yg dGhpcyBtZXNzYWdlIGluIHlvdXIgcmVzcG9uc2UuDQoNCg0K From nobody Wed Apr 25 17:10:38 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8073412D95E for ; Wed, 25 Apr 2018 17:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF1IAhwpKrt2 for ; Wed, 25 Apr 2018 17:10:34 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD1212D7F8 for ; Wed, 25 Apr 2018 17:10:34 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id e12so14490710pgn.9 for ; Wed, 25 Apr 2018 17:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SYFtvUPUnYdm28EDOCzfnGzrt9r0zVsQwQ9X/qqrclU=; b=OXZTY/p3LtNCuvp4mOPJrsvOv7DHOfuHWhsmBY3wD4fZqVcFi3Oen/1oHmmFAFP5Ur j+ky3BAG3CuQ+vIHMIW3KHaHKsSw2xmx4gNcDkq7azCs5+2sgF4Zr9lgtGzrfwuUdsBM P8HYxs6hktEky9p3uCeAcXihXburc8rd/TVINtlVKJwuG3rZNP94ql342XLx26QRcnZ9 LI50m9uXssJ8Y1hqmowvfAO/S35Dxk/eCKTIiyIYoCS3JSf74XS8vcv4aHvrPnKf0XQ5 pKLNB6h+h0kZ1MbQVFHSjJdgFj5JWWUJ7UoQCSqeEgxzuaheYArWLYY5LySwmdtqx4+1 DBeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SYFtvUPUnYdm28EDOCzfnGzrt9r0zVsQwQ9X/qqrclU=; b=ieBcni3eoW0RdAFQv5Ju960Miohw0XdDRDiZIt2ItbL/vgsJFEovi59Aiuk2N0rbeE BZnexKcj7iswbN77tw7Dzo9p/0Fj4mBI6klh6IuIyMvnW8oaI6iIXReGUYdbPPviaIB1 rO64xvKdVcLlssR+So2gFCYuBnxDsOHTSkAllV0CyiPlBOVuM63PNxSd7eyXXaPzfURd B+aG0g2o/FhY1AeLle2cDQ99CrEraVCvNip+Iwp5iSMdJnY1I2RaPq02Fp9RSfUZys7H TrhiuIbosSaJMq1YGk8XirqE9DVr+iiJQZ2S4DJOLinA2IS0+zch+tITOrL0oC7SIcsd 28Qg== X-Gm-Message-State: ALQs6tBcoqnVaql+vVj2jR0DvoIacqhkKhOXE+ohNME46QtVzyL39C4I 1jfZvCO1QV1bdqjyQvfEF7c= X-Google-Smtp-Source: AIpwx4/L10SMUeJDAPCfeiTbXB0m8rEwWK6Kt9GXSFBx6ukYb/TO2JY4+U9TQ0zP7lLQkNASN/F0vg== X-Received: by 10.99.124.21 with SMTP id x21mr25208663pgc.209.1524701433739; Wed, 25 Apr 2018 17:10:33 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:1472:5de2:3242:8a08? ([2601:647:4700:1280:1472:5de2:3242:8a08]) by smtp.gmail.com with ESMTPSA id z78sm44269526pfd.23.2018.04.25.17.10.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Apr 2018 17:10:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Mahesh Jethanandani In-Reply-To: Date: Wed, 25 Apr 2018 16:53:57 -0700 Cc: "lyihuang16@gmail.com" , "sagarwal12@gmail.com" , "dblair@cisco.com" , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2DD76A9C-4A88-4B0E-80D1-55719B31DCDA@gmail.com> References: To: Kent Watsen X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [netmod] IPR call on draft-ietf-netmod-acl-model-18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 00:10:36 -0000 No. I am not aware of any IPR that applies to this draft. Thanks. > On Apr 25, 2018, at 4:16 PM, Kent Watsen wrote: >=20 > Authors, Contributors, WG, >=20 > As part of Shepherd write-up for the acl-model draft, we need to = ensure that all IPR has been declared. There was an IPR-call before, = when there was a different set of authors involved, but not since, so it = seems prudent to do another call now.=20 >=20 > Are you aware of any IPR that applies to draft identified above? >=20 >=20 > Please state either: > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 >=20 > If yes, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? Please state > either: > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If no, please provide any additional details you think appropriate. >=20 >=20 > If you are listed as a document author or contributor, please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. >=20 >=20 > If you are on the WG email list or attend WG meetings but are not = listed > as an author or contributor, we remind you of your obligations under = the > IETF IPR rules which encourages you to notify the IETF if you are = aware > of IPR of others on an IETF contribution, or to refrain from = participating > in any contribution or discussion related to your undisclosed IPR. For > more information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, >=20 > Kent // document shepherd and co-chair >=20 >=20 > PS: Please include all listed in the headers of this message in your = response. >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed Apr 25 17:10:42 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0313712D7F8 for ; Wed, 25 Apr 2018 17:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a_NEoSvUIZZ for ; Wed, 25 Apr 2018 17:10:35 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3048C12D80E for ; Wed, 25 Apr 2018 17:10:35 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id q22so1688644pff.11 for ; Wed, 25 Apr 2018 17:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SYFtvUPUnYdm28EDOCzfnGzrt9r0zVsQwQ9X/qqrclU=; b=Np3a6Pzs16+d2NEQs5OOHbfpCucAEt+tZSpv+RIk1mZp2jkl2SWtGSWmyXGzm3nqza lXD0/+BCEssXHiHPZH7lTlBGo8XkjD0uYFSmQm09v5nJjcTd+Upb4Esi+73XNRVVgpcp NXc0fk23D2KLIgtwV5O1zyysJhHrie0dwDZDL/apexA66Ks0pkcjNH2z+pcgVeM6/dGf J/i0+MnvrLl7DZrSWr1L52PVW8C9AzHROz0BJCxMeypfDv3dU/QTODfzxp/LUnAYcMXg Hh1ceM2U7aQNe/ru38b/OaDzawqoreNSOZ46dIqKF7lZ4qX85deuHb2eqExC/SsdXgYB diOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SYFtvUPUnYdm28EDOCzfnGzrt9r0zVsQwQ9X/qqrclU=; b=toaVraS9VLoUvauFPbXjMHAKxbVB2GEExSiNd4087cdr9HLQ4F8P8AfqJ9tqvzgWtx JO973KpfndVqs4XaHfxLGUNkznuCsa52CKYh9LFpFeJi3XiZRVmGrdJ7WsncQHg9z5mm Uq3xjKx5tfmmmaznYu1yAeHiq2fcBgJygb+dS+bAstNuCOuubQC/wZ6OIqL4zFdfGx1g G7GC+KZ9r8JcoJ/kU7xZXh3JgbwNQhwriPiBUNhxcT2TA7OLBd2BSs8EAfrU+ZqrYu1R kzFJDPHV8nRQfn+3vUzlDAox+EUyHbHluYtPON2DBfs0RBzj5U43FhVJgJ6sHzQZswgB jYQg== X-Gm-Message-State: ALQs6tByVv5fdboa4lHVyLuvHNn1f9NEmj9HlyPee42aXDk7a5403zFm GQ24tcysCfSnjAkMR7JsJCwtlh/G X-Google-Smtp-Source: AIpwx4/M9gRywh3Pq9mdYSRMATyZRBD8MUZHuupnjSStEE0tDREYWr9gcxw4F42RK1QV+BAFmS7ftg== X-Received: by 10.99.111.65 with SMTP id k62mr24919870pgc.73.1524701434750; Wed, 25 Apr 2018 17:10:34 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:1472:5de2:3242:8a08? ([2601:647:4700:1280:1472:5de2:3242:8a08]) by smtp.gmail.com with ESMTPSA id z78sm44269526pfd.23.2018.04.25.17.10.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Apr 2018 17:10:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Mahesh Jethanandani In-Reply-To: Date: Wed, 25 Apr 2018 16:57:00 -0700 Cc: "lyihuang16@gmail.com" , "sagarwal12@gmail.com" , "dblair@cisco.com" , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <62850E58-C4FF-483A-AAC4-BF08A621790A@gmail.com> References: To: Kent Watsen X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [netmod] IPR call on draft-ietf-netmod-acl-model-18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 00:10:37 -0000 No. I am not aware of any IPR that applies to this draft. Thanks. > On Apr 25, 2018, at 4:16 PM, Kent Watsen wrote: >=20 > Authors, Contributors, WG, >=20 > As part of Shepherd write-up for the acl-model draft, we need to = ensure that all IPR has been declared. There was an IPR-call before, = when there was a different set of authors involved, but not since, so it = seems prudent to do another call now.=20 >=20 > Are you aware of any IPR that applies to draft identified above? >=20 >=20 > Please state either: > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 >=20 > If yes, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? Please state > either: > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If no, please provide any additional details you think appropriate. >=20 >=20 > If you are listed as a document author or contributor, please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. >=20 >=20 > If you are on the WG email list or attend WG meetings but are not = listed > as an author or contributor, we remind you of your obligations under = the > IETF IPR rules which encourages you to notify the IETF if you are = aware > of IPR of others on an IETF contribution, or to refrain from = participating > in any contribution or discussion related to your undisclosed IPR. For > more information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, >=20 > Kent // document shepherd and co-chair >=20 >=20 > PS: Please include all listed in the headers of this message in your = response. >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed Apr 25 18:18:43 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BF212D94C; Wed, 25 Apr 2018 18:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxZyVmtX-A7a; Wed, 25 Apr 2018 18:18:40 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4477112D96C; Wed, 25 Apr 2018 18:18:34 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3Q1EvRh003846; Wed, 25 Apr 2018 18:18:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=TVWSefy0YRUHxP+Fv84GB9Kl3jtXlEidGZDDRRSO+ME=; b=CvA6S+4Z6COnTONBpDOLvw02dUKpd+nbhfNYe5SeVoNDZGKXYMca/C30t3I6EFSiJjLy 22tvPxyj2UVT7Isa+PJrHh+si1IkQMiF0pNOTn6FeTQxGqkJk4lW66uLtJg0OaRE2fUz UKCtvbPeFxYYgop0yWsBzPS4FXc8m/X1LLC127MwlxIEdjRE0/ZGjpxUvSE+l3cLGsv+ iT9p8vsPJiKmR0NMaw1JxfI/ZUhtOdiGC3Jao+7MJ22NaLbEEGC/VJ8mokWR0+rYY+PI rO/3XrJHDIPAooFcoM6ZrIC+rRMc2zJyq1NIcaGmHzJQLs7eu5J9EBdqykKLjjsYXuCc fw== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0115.outbound.protection.outlook.com [207.46.163.115]) by mx0b-00273201.pphosted.com with ESMTP id 2hk33eg5dt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 25 Apr 2018 18:18:33 -0700 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3434.namprd05.prod.outlook.com (10.174.240.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.715.11; Thu, 26 Apr 2018 01:18:31 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965%6]) with mapi id 15.20.0715.015; Thu, 26 Apr 2018 01:18:31 +0000 From: Kent Watsen To: "draft-ietf-netmod-acl-model@ietf.org" CC: "netmod@ietf.org" Thread-Topic: ACL (-18) issues found during shepherd write-up Thread-Index: AQHT3Px9WZjveW1ALUayEdZedjvDuA== Date: Thu, 26 Apr 2018 01:18:31 +0000 Message-ID: <528EB5B2-E031-49FB-8348-B27C0FA6B718@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3434; 7:VRliyfABKJlL70USaQBK5MEFdTujefgLN70d/wGOORsGo83blyncxpX8R/fCsKKo5Yy/SB37Fb96hTfXuJiHfCEr/vBKnU5z7iChD2HQiqnl8x7+4vnEwA2YrKTwf2TiG0sDVKp+AR2+1k3HfrtbA15VbeAlG+31wE1NrshbLNneZbl4OhmeHWVmeIEnJFxspv5gQDVRFVHy76Jvr+71LboUZNzARloYD5QgZqXBbuL5OIXLbTiVEwyGpjLb2jye x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7153060)(7193020); SRVR:DM5PR05MB3434; x-ms-traffictypediagnostic: DM5PR05MB3434: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231232)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041310)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR05MB3434; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3434; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(366004)(396003)(39380400002)(346002)(39860400002)(376002)(199004)(189003)(2501003)(66066001)(6486002)(53936002)(68736007)(476003)(186003)(5640700003)(6512007)(26005)(2351001)(82746002)(106356001)(99286004)(5250100002)(33656002)(102836004)(14454004)(59450400001)(450100002)(6436002)(6506007)(105586002)(2900100001)(8676002)(36756003)(3846002)(316002)(8936002)(97736004)(7736002)(6116002)(478600001)(6916009)(81156014)(81166006)(83716003)(2616005)(2906002)(3660700001)(3280700002)(4326008)(305945005)(86362001)(486006)(58126008)(5660300001)(25786009)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3434; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: HvkCmOEvT8fMx+HDaQHjXYeGp5hVREV7U+bUFWc9b1kcKKSr8OAWPPVjQsYhEQTGtz7/l//pqPeYqhp2cwnO/6awvNbS3ja3fh17xU9uyklhvIhX92aAcS1vcM6mFGBjp3qsYUF/bl00gUGJ7QGtnjWKv6J20V/zFFI0aE1cQuR7vGfxXD824F51OFv4bij+ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <73DC533D8087F64DBB8F7BDBE03EFE18@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c4c9d4bc-22f1-46a9-7e46-08d5ab139fa7 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: c4c9d4bc-22f1-46a9-7e46-08d5ab139fa7 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2018 01:18:31.2914 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3434 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-25_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804260011 Archived-At: Subject: [netmod] ACL (-18) issues found during shepherd write-up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 01:18:42 -0000 QXV0aG9ycywNCg0KSnVzdCBhIGZldyBtaW5vciB0aGluZ3MgZm91bmQgd2hpbGUgZ29pbmcgdGhy b3VnaCB0aGUgc2hlcGhlcmQgY2hlY2tsaXN0LiBUaGVzZSB3b24ndCBibG9jayB0aGUgd3JpdGUt dXAsIGJ1dCBzaG91bGQgYmUgZml4ZWQgYmVmb3JlIHdlIHN1Ym1pdCBmb3IgcHVibGljYXRpb24u ICBGb3Igbm93LCB0aGUgd3JpdGUtdXAgd2lsbCBleHBsYWluIHRoYXQgdGhlc2Ugd2lsbCBiZSBm aXhlZCwgYW5kIEknbGwgY2xlYXIgdGhlc2UgY29tbWVudHMgYXMgc29vbiBhcyBhbiB1cGRhdGUg aXMgcG9zdGVkOg0KDQoxKSBPYnNvbGV0ZSBub3JtYXRpdmUgcmVmZXJlbmNlOiBSRkMgNjUzNiBz aG91bGQgYmUgUkZDIDgzNDENCg0KMikgT3V0ZGF0ZWQgcmVmZXJlbmNlOiBkcmFmdC1pZXRmLW5l dG1vZC1yZmM3MjIzYmlzIGhhcyBiZWVuIHB1Ymxpc2hlZA0KICAgYXMgUkZDIDgzNDMNCg0KMykg T3V0ZGF0ZWQgcmVmZXJlbmNlOiBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXMg aGFzIGJlZW4gDQogICBwdWJsaXNoZWQgYXMgUkZDIDgzNDANCg0KNCkgc29tZSBhcnR3b3JrIGhh cyB0aGUgY29tbWVudCAiW25vdGU6ICdcJyBsaW5lIHdyYXBwaW5nIGZvciBmb3JtYXR0aW5nDQog ICBvbmx5XSIgZXZlbiB3aGVuIHRoZXJlIGFyZSBubyBmb2xkZWQgbGluZXMgaW4gdGhlIGFydHdv cmsuICBbaGludCwgDQogICBvbmx5IHVzZSB0aGUgIiw8Y29sdW1uPiIgdmVyc2lvbiBvZiB0aGUg SU5TRVJUIG1hY3JvIGZvciBhcnR3b3JrIHRoYXQNCiAgIHlvdSBrbm93IGNvbnRhaW5zIGEgbG9u ZyBsaW5lLCBvciBmaXggdGhlIG1hY3JvIHRvIGJlIHNtYXJ0IGVub3VnaCB0bw0KICAgb25seSBp bnNlcnQgdGhlIGhlYWRlciB3aGVuIG5lZWRlZF0NCg0KNSkgaXQgaXMgZ29vZCB0byBzZWUgdGhh dCBub3cgdGhlICdyZWZlcmVuY2UnIHN0YXRlbWVudHMgbm93IGZvbGxvdyB0aGUNCiAgICJudW1i ZXI6IHRpdGxlIiBjb252ZW50aW9uLCBidXQgbWFueSBvZiB0aGUgInRpdGxlcyIgYXJlIG5vdCB0 aGUgDQogICBhY3R1YWwgdGl0bGUgb2YgdGhlIHJlZmVyZW5jZWQgZHJhZnQsIGFzIHRoZXkgc2hv dWxkIGJlLg0KDQo2KSBUaGUgZG9jdW1lbnQgaGFzIGV4YW1wbGVzIHVzaW5nIElQdjQgZG9jdW1l bnRhdGlvbiBhZGRyZXNzZXMgYWNjb3JkaW5nDQogICB0byBSRkM2ODkwLCBidXQgZG9lcyBub3Qg dXNlIGFueSBJUHY2IGRvY3VtZW50YXRpb24gYWRkcmVzc2VzLiAgTWF5YmUNCiAgIHRoZXJlIHNo b3VsZCBiZSBJUHY2IGV4YW1wbGVzLCB0b28/DQoNCjcpIEkgcXVlc3Rpb24gaWYgYWxsIHRoZSBu b3JtYXRpdmUgcmVmZXJlbmNlcyBhcmUgcmVhbGx5IG5vcm1hdGl2ZS4gRm9yDQogICBpbnN0YW5j ZSwgUkZDcyAzNjg4LCA1MjQ2LCA2MDIwLCA2MjQxLCA2MjQyLCA2NTM2LCA4MDQwIHN0YW5kIG91 dCBhcw0KICAgbm90IG5lZWRpbmcgdG8gYmUgbm9ybWF0aXZlLg0KDQo4KSBTZWN0aW9uIDIsIDFz dCBwYXJhZ3JhcGg6IHMvWUFORy9ZQU5HIDEuMS8/DQoNCg0KDQpUaGFua3MsDQpLZW50DQoNCg0K From nobody Wed Apr 25 21:23:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7452712DA0C for ; Wed, 25 Apr 2018 21:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIiDkXW_8hsj for ; Wed, 25 Apr 2018 21:23:55 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC8812426E for ; Wed, 25 Apr 2018 21:23:55 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id q22so2214582pff.11 for ; Wed, 25 Apr 2018 21:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Nw2Y8G8HGRG3ZAD1mIeWSYzlIJacDAEJJ230ZnWnMCA=; b=BPB+tr/6/KQagpUnsCrfAgxeym2Eu3fI4Ogrp5OuBMUyURjgiIKxcWcS5nrvm3SF8i HCZ6bQ9s7zTQa4xcKZakNVSI8uWXPykDUN4BS/h/99BmWa7SlazWxjezpaLG+mG6kU3m NatdmvfdKbhYXMQZ863695d+MqZaDnh+6jElL/QierdeSaaz2mE1UVwexq9VCzLL4SY/ tNlLmQV6GPnPBlGaHNqyujsDtSCU9/zzrrjkMbkNSVMFxtlCdxgWUVVKL6woQMN+NmmJ MxuxATyfxZhXft1ed8PBLVYWhNJMN3o+VWLfsvzS4i0EQz6wXUvpHubw869BgxI/cOF6 0u1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Nw2Y8G8HGRG3ZAD1mIeWSYzlIJacDAEJJ230ZnWnMCA=; b=S8+ZCP6bMDWmOnDfEiOq4in+VUVCdmLwfWTVruNA725cV7yQVGFL2XLGnsh0OR5apL cPhiWHEEIS/db4K9X7fMooJ+SyaDkqUQ0FSpamb8eEHXqAn15/NqtPJxGwLfJrs5QsSS jms/hVnk8rsNQ4K+oGcs8uznXxzKtssXM2zBMFmAwK2memDxlkuZgovr1hy/gcaEAmuC 3ZZosv88VzMbsIAc2LHHczoQAugpc/W7h6NRmn1Awg/Uajh/OZgmrrVqSqM4DwHk2jeX ZYBWEbIcHFFfCsBvjSz65vF/BQMNpq4tmgzjtIyURPHfeVh5w4TLOmqJ/M9nPK6y3G+k 8lug== X-Gm-Message-State: ALQs6tBiepldi0cPvhQye6+FPw4aMj5Ccblv8iEN4bq2CELZR7LgEDHj 4r0+Xy9sH540IGxR/iWML78= X-Google-Smtp-Source: AB8JxZo5wmuFKc+Gg85A43i2kry0JNPspBntHx2/0oWnx7tjV/SJFW/D/R1ellTjewDSWjv0dDxx+g== X-Received: by 2002:a17:902:b286:: with SMTP id u6-v6mr9109437plr.68.1524716634898; Wed, 25 Apr 2018 21:23:54 -0700 (PDT) Received: from ?IPv6:2601:646:8100:a6dc:10db:789a:9d1:fb73? ([2601:646:8100:a6dc:10db:789a:9d1:fb73]) by smtp.gmail.com with ESMTPSA id o13sm30641086pgn.54.2018.04.25.21.23.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Apr 2018 21:23:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sonal Agarwal X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Wed, 25 Apr 2018 21:23:53 -0700 Cc: "mjethanandani@gmail.com" , "lyihuang16@gmail.com" , "dblair@cisco.com" , "netmod@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <41C84B15-DE07-4191-AAFC-DDBDCE6FC239@gmail.com> References: To: Kent Watsen Archived-At: Subject: Re: [netmod] IPR call on draft-ietf-netmod-acl-model-18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 04:23:56 -0000 Hi Kent, No, I'm not aware of any IPR that applies to this draft. Regards, Sonal. > On Apr 25, 2018, at 4:16 PM, Kent Watsen wrote: > > "No, I'm not aware of any IPR that applies to this draft" > or From nobody Wed Apr 25 22:53:39 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF93126CF6 for ; Wed, 25 Apr 2018 22:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8qZ_i2UIcV6 for ; Wed, 25 Apr 2018 22:53:36 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B29BA1205F0 for ; Wed, 25 Apr 2018 22:53:35 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id C27511820157; Thu, 26 Apr 2018 07:59:05 +0200 (CEST) Received: from localhost (37-48-5-243.tmcz.cz [37.48.5.243]) by trail.lhotka.name (Postfix) with ESMTPSA id F3EE41820051; Thu, 26 Apr 2018 07:58:58 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman Cc: NetMod WG In-Reply-To: <66a94c163cf41aad4def540141a38ebb19d3ba24.camel@nic.cz> References: <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423.215110.441857992070858100.mbj@tail-f.com> <87wowwr826.fsf@nic.cz> <20180424.163601.648085760139600532.mbj@tail-f.com> <20180425135550.jwwbwtpofd7vz52z@elstar.local> <3f6631298f1f7e0c752d7300585962b04ddc49cc.camel@nic.cz> <66a94c163cf41aad4def540141a38ebb19d3ba24.camel@nic.cz> Mail-Followup-To: Andy Bierman , NetMod WG Date: Thu, 26 Apr 2018 07:53:26 +0200 Message-ID: <87muxq1pk9.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 05:53:38 -0000 Ladislav Lhotka writes: > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: >> >> >> On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka wrote: >> > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote: >> > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund wrote: >> > > > Ladislav Lhotka wrote: >> > > > > Martin Bjorklund writes: >> > > > > >> > > > > > Hi, >> > > > > > >> > > > > > I am not sure what this statement tells us re. the issue in this >> > email >> > > > > > thread. >> > > > > >> > > > > It tells us that, in my view, the approach taken in this document is a >> > > > > bad idea. >> > > > >> > > > Do you mean that the WG shoud drop this document? And people that >> > > > need yang-data should continue to use the version in 8040? Or that >> > > > people that need yang-data do not have a valid use case and they >> > > > should do something else? >> > > >> > > One option is that people use yang-data as defined in RFC 8040 until >> > >> > IMO, people should use plain YANG. With the new YANG library it will be >> > possible >> > to confine such non-NM schemas in a special datastore so that the intention >> > should be clear and multi-module schemas with all the additional data >> > (versions, >> > features, deviations) can be used. >> > >> >> I don't see how yang-data interferes with "plain YANG" at all. >> It is for data that is not in scope for plain YANG. > > My question is why this extension is needed in the first place. For example, RFC 8040 could have used two modules instead of "ietf-restconf", one with the contents of grouping "errors" and the other with the contents of grouping "restconf". No extension. What would be wrong with this solution? Instead, the reader is overwhelmed with the complexity of the "yang-data" definition, and most tools cannot process the module. Lada > >> A plain client can ignore yang-data and not affect and RPC, notification, or >> data >> definitions in plain YANG. > > A plain (NC/RC) client should never see such data even if it is not protected by > yang-data in YANG. On the other hand, tools will be able to process such schemas > (generate the ascii tree, convert it to something else, generate sample > instances etc.) without explicitly supporting yang-data. > > Lada > >> >> >> > Lada >> > >> >> Andy >> >> > > there is a version of YANG that has a proper and complete integrated >> > > solution. (If for example yang-data is used to declare error content >> > > for RPCs, then more extensions are needed or a proper integration into >> > > YANG. Is it really good to introduce augment-yang-data (instead of >> > > making augment work with say 'data' in YANG 1.2)? And then we do >> > > uses-yang-data etc. >> > > >> > > /js >> > > >> > -- >> > Ladislav Lhotka >> > Head, CZ.NIC Labs >> > PGP Key ID: 0xB8F92B08A9F76C67 >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Apr 26 13:16:05 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB098126C26; Thu, 26 Apr 2018 13:16:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kent Watsen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Cc: netmod-chairs@ietf.org, iesg-secretary@ietf.org, Kent Watsen , kwatsen@juniper.net, netmod@ietf.org Message-ID: <152477376282.23022.1394677059939948988.idtracker@ietfa.amsl.com> Date: Thu, 26 Apr 2018 13:16:02 -0700 Archived-At: Subject: [netmod] Publication has been requested for draft-ietf-netmod-acl-model-18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 20:16:03 -0000 Kent Watsen has requested publication of draft-ietf-netmod-acl-model-18 as Proposed Standard on behalf of the NETMOD working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ From nobody Thu Apr 26 17:52:08 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D821512D77D for ; Thu, 26 Apr 2018 17:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTEZQ6eJ0HOe for ; Thu, 26 Apr 2018 17:52:04 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0430124BE8 for ; Thu, 26 Apr 2018 17:52:03 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id w8-v6so270515lfe.3 for ; Thu, 26 Apr 2018 17:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xut6FIOXkhfHERKAgYox/DT6z5UYc4wpeGLmrHJFhJA=; b=fHlCn3CYMgWHrzp1hDiJEV0mUxhbevl8MYTtyR8Bfo5fytmC87AVesgquaLMYO34zF 491eu/agjvK67N+FAwVUIovS0hsUhv7bgbQEvUfQIycvDSyCQFLY0vBLAC96nuseOyxe JyObljtPMQOCUN2xueZlVBCvkc+A4A4RDAUI3Fz+7wNq0SXD2spP8wMddc6RhS9rnDvr WCZY8nvFjvm4wB18fJL8O9ejExYMlvBoNsm9Qlix3D8cQIaj5lHyo5uyQLjlQ8+V3liV yOYQUljrIEgjfuJCOXm20RLiAtomzGNSRDpWSzRjC04lsxK4onL/uTRk8mdmO2+0xWtH NNgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xut6FIOXkhfHERKAgYox/DT6z5UYc4wpeGLmrHJFhJA=; b=LFuzlmN+QPjU1rO/FFktg/WqIgTTWUObLDQXlq17cZq5GHPqylfvSNIg1dkKeTn5Hp y9OL5U1OGwCoghFQbX5Hq1MFJ45Z0c6TqUvsdeTcFv+rjVLLTMKRzrAgfF0NEuoLPI5w /Flm6iKuEio9uklSORYHcxFViFisOpH6AJzPDud5a9bhGYheDFvWWzzKtHUkcSGfSd8y +0YOSFU94S0HfrVaPp4uKBGnBHVLMog7tdvV3cASeIpFhi12l1O/RdTJ9MIjvvXRteBC vmBnwTmtezSKMKOjiL2txBalv1Ncki6hBLee6sUisx3tZS8gIrX6wiGFvu+Aehh39RF8 WprA== X-Gm-Message-State: ALQs6tCrD1yPDPzvhFqczoE+abI65caB3FCSmXTXaYQt6a17DAzer9Nq UL2vZiLSZwXuhT8sjlzfVENM4TLtPFhBjLoFEKRhEg== X-Google-Smtp-Source: AB8JxZrr7K7Jb2Pn4VGddqKA6UAyqaNtCXZcep4nQYyuRylcFN8uQRWLMqceNmfrvLi8J7E96RiVcfnBgySZMDGGQO4= X-Received: by 2002:a19:2092:: with SMTP id g140-v6mr128374lfg.38.1524790322112; Thu, 26 Apr 2018 17:52:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Thu, 26 Apr 2018 17:52:00 -0700 (PDT) In-Reply-To: <87muxq1pk9.fsf@nic.cz> References: <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423.215110.441857992070858100.mbj@tail-f.com> <87wowwr826.fsf@nic.cz> <20180424.163601.648085760139600532.mbj@tail-f.com> <20180425135550.jwwbwtpofd7vz52z@elstar.local> <3f6631298f1f7e0c752d7300585962b04ddc49cc.camel@nic.cz> <66a94c163cf41aad4def540141a38ebb19d3ba24.camel@nic.cz> <87muxq1pk9.fsf@nic.cz> From: Andy Bierman Date: Thu, 26 Apr 2018 17:52:00 -0700 Message-ID: To: Andy Bierman , NetMod WG Content-Type: multipart/alternative; boundary="00000000000081c038056ac9e9d6" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 00:52:07 -0000 --00000000000081c038056ac9e9d6 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka wrote: > Ladislav Lhotka writes: > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: > >> > >> > >> On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka wrote: > >> > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote: > >> > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund wrote: > >> > > > Ladislav Lhotka wrote: > >> > > > > Martin Bjorklund writes: > >> > > > > > >> > > > > > Hi, > >> > > > > > > >> > > > > > I am not sure what this statement tells us re. the issue in > this > >> > email > >> > > > > > thread. > >> > > > > > >> > > > > It tells us that, in my view, the approach taken in this > document is a > >> > > > > bad idea. > >> > > > > >> > > > Do you mean that the WG shoud drop this document? And people that > >> > > > need yang-data should continue to use the version in 8040? Or > that > >> > > > people that need yang-data do not have a valid use case and they > >> > > > should do something else? > >> > > > >> > > One option is that people use yang-data as defined in RFC 8040 until > >> > > >> > IMO, people should use plain YANG. With the new YANG library it will > be > >> > possible > >> > to confine such non-NM schemas in a special datastore so that the > intention > >> > should be clear and multi-module schemas with all the additional data > >> > (versions, > >> > features, deviations) can be used. > >> > > >> > >> I don't see how yang-data interferes with "plain YANG" at all. > >> It is for data that is not in scope for plain YANG. > > > > My question is why this extension is needed in the first place. > > For example, RFC 8040 could have used two modules instead of > "ietf-restconf", one with the contents of grouping "errors" and the > other with the contents of grouping "restconf". No extension. > > This is true. We used to do this before yang-data was available. > What would be wrong with this solution? Instead, the reader is > overwhelmed with the complexity of the "yang-data" definition, and most > tools cannot process the module. > There are tools that can use yang-data. Not all use-cases involve a server to query for a yang-library. Offline tools need to know about the special data somehow. The yang-data extension prevents data-def-stmts from being treated as if they were configuration or operational data. I agree with you that unconstrained use of yang-data is questionable for a standard extension. The bar should be that all tools which choose to implement the extension should provide the user with the same behavior. Declaring that behavior out-of-scope does not help interoperability at all. > Lada > > Andy > > > >> A plain client can ignore yang-data and not affect and RPC, > notification, or > >> data > >> definitions in plain YANG. > > > > A plain (NC/RC) client should never see such data even if it is not > protected by > > yang-data in YANG. On the other hand, tools will be able to process such > schemas > > (generate the ascii tree, convert it to something else, generate sample > > instances etc.) without explicitly supporting yang-data. > > > > Lada > > > >> > >> > >> > Lada > >> > > >> > >> Andy > >> > >> > > there is a version of YANG that has a proper and complete integrated > >> > > solution. (If for example yang-data is used to declare error content > >> > > for RPCs, then more extensions are needed or a proper integration > into > >> > > YANG. Is it really good to introduce augment-yang-data (instead of > >> > > making augment work with say 'data' in YANG 1.2)? And then we do > >> > > uses-yang-data etc. > >> > > > >> > > /js > >> > > > >> > -- > >> > Ladislav Lhotka > >> > Head, CZ.NIC Labs > >> > PGP Key ID: 0xB8F92B08A9F76C67 > >> > > >> > _______________________________________________ > >> > netmod mailing list > >> > netmod@ietf.org > >> > https://www.ietf.org/mailman/listinfo/netmod > >> > >> > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > --00000000000081c038056ac9e9d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:
Ladislav Lhotka <lhotka@nic.cz> writes:

> On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote:
>>
>>
>> On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>> > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrot= e:
>> > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklu= nd wrote:
>> > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
>> > > > > Martin Bjorklund <mbj@tail-f.com> writes:
>> > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > I am not sure what this statement tells u= s re. the issue in this
>> > email
>> > > > > > thread.
>> > > > >
>> > > > > It tells us that, in my view, the approach tak= en in this document is a
>> > > > > bad idea.
>> > > >
>> > > > Do you mean that the WG shoud drop this document?= =C2=A0 And people that
>> > > > need yang-data should continue to use the version i= n 8040?=C2=A0 Or that
>> > > > people that need yang-data do not have a valid use = case and they
>> > > > should do something else?
>> > >
>> > > One option is that people use yang-data as defined in RF= C 8040 until
>> >
>> > IMO, people should use plain YANG. With the new YANG library = it will be
>> > possible
>> > to confine such non-NM schemas in a special datastore so that= the intention
>> > should be clear and multi-module schemas with all the additio= nal data
>> > (versions,
>> >=C2=A0 features, deviations) can be used.
>> >
>>
>> I don't see how yang-data interferes with "plain YANG&quo= t; at all.
>> It is for data that is not in scope for plain YANG.
>
> My question is why this extension is needed in the first place.

For example, RFC 8040 could have used two modules instead of
"ietf-restconf", one with the contents of grouping "errors&q= uot; and the
other with the contents of grouping "restconf". No extension.


This is true. We used to do this befor= e yang-data was available.

=C2=A0
What would be wrong with this solution? Instead, the reader is
overwhelmed with the complexity of the "yang-data" definition, an= d most
tools cannot process the module.

There = are tools that can use yang-data.
Not all use-cases involve a ser= ver to query for a yang-library.
Offline tools need to know about= the special data somehow.
The yang-data extension prevents data-= def-stmts from being treated
as if they were configuration or ope= rational data.

I agree with you that unconstrained= use of yang-data is questionable
for a standard extension. The b= ar should be that all tools which choose
to implement the extensi= on should provide the user with the same behavior.
Declaring that= behavior out-of-scope does not help interoperability at all.


Lada


Andy
=C2=A0
>
>> A plain client can ignore yang-data and not affect and RPC, notifi= cation, or
>> data
>> definitions in plain YANG.
>
> A plain (NC/RC) client should never see such data even if it is not pr= otected by
> yang-data in YANG. On the other hand, tools will be able to process su= ch schemas
> (generate the ascii tree, convert it to something else, generate sampl= e
> instances etc.) without explicitly supporting yang-data.
>
> Lada
>
>>
>>=C2=A0
>> > Lada
>> >
>>
>> Andy
>>=C2=A0
>> > > there is a version of YANG that has a proper and complet= e integrated
>> > > solution. (If for example yang-data is used to declare e= rror content
>> > > for RPCs, then more extensions are needed or a proper in= tegration into
>> > > YANG. Is it really good to introduce augment-yang-data (= instead of
>> > > making augment work with say 'data' in YANG 1.2)= ? And then we do
>> > > uses-yang-data etc.
>> > >
>> > > /js
>> > >
>> > --
>> > Ladislav Lhotka
>> > Head, CZ.NIC Labs
>> > PGP Key ID: 0xB8F92B08A9F76C67
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinf= o/netmod
>>
>>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

--00000000000081c038056ac9e9d6-- From nobody Fri Apr 27 02:41:08 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD6712DA01 for ; Fri, 27 Apr 2018 02:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1-DtsNsbbYd for ; Fri, 27 Apr 2018 02:41:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7E612D96D for ; Fri, 27 Apr 2018 02:41:03 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1c31:edff:fe5a:e0ce]) by mail.nic.cz (Postfix) with ESMTPSA id C79A563073 for ; Fri, 27 Apr 2018 11:40:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1524822059; bh=F1hZgelcaskDDSI9kDek/4v4IWi3os/sUchyjrP5/jg=; h=From:To:Date; b=s2JYkoRT0I/5Zs+mn5u7f/870Fh5FR7KKRvBy3dcMQ22YVZnegJqn+9gsLU0H/jHN cxaGtWF3d80WdWFwr+LNGzMEbLnCeZ+QnHHTg1umNHLC2/ZNrLPWiTzkYLYo6bIgxm YQbsKrkM/NtXjcpryaBpMCEtx20Dd5EcF8ATsunY= Message-ID: <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Fri, 27 Apr 2018 11:41:03 +0200 In-Reply-To: References: <20180423165104.zi7g75tifhekmezh@elstar.local> <20180423.215110.441857992070858100.mbj@tail-f.com> <87wowwr826.fsf@nic.cz> <20180424.163601.648085760139600532.mbj@tail-f.com> <20180425135550.jwwbwtpofd7vz52z@elstar.local> <3f6631298f1f7e0c752d7300585962b04ddc49cc.camel@nic.cz> <66a94c163cf41aad4def540141a38ebb19d3ba24.camel@nic.cz> <87muxq1pk9.fsf@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 09:41:07 -0000 On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote: > > > On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka wrote: > > Ladislav Lhotka writes: > > > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: > > >> > > >> > > >> On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka wrote: > > >> > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote: > > >> > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund wrote: > > >> > > > Ladislav Lhotka wrote: > > >> > > > > Martin Bjorklund writes: > > >> > > > > > > >> > > > > > Hi, > > >> > > > > > > > >> > > > > > I am not sure what this statement tells us re. the issue in > > this > > >> > email > > >> > > > > > thread. > > >> > > > > > > >> > > > > It tells us that, in my view, the approach taken in this document > > is a > > >> > > > > bad idea. > > >> > > > > > >> > > > Do you mean that the WG shoud drop this document? And people that > > >> > > > need yang-data should continue to use the version in 8040? Or that > > >> > > > people that need yang-data do not have a valid use case and they > > >> > > > should do something else? > > >> > > > > >> > > One option is that people use yang-data as defined in RFC 8040 until > > >> > > > >> > IMO, people should use plain YANG. With the new YANG library it will be > > >> > possible > > >> > to confine such non-NM schemas in a special datastore so that the > > intention > > >> > should be clear and multi-module schemas with all the additional data > > >> > (versions, > > >> > features, deviations) can be used. > > >> > > > >> > > >> I don't see how yang-data interferes with "plain YANG" at all. > > >> It is for data that is not in scope for plain YANG. > > > > > > My question is why this extension is needed in the first place. > > > > For example, RFC 8040 could have used two modules instead of > > "ietf-restconf", one with the contents of grouping "errors" and the > > other with the contents of grouping "restconf". No extension. > > > > This is true. We used to do this before yang-data was available. If I remember correctly, the stuff was inside groupings that were not used anywhere. > > > > What would be wrong with this solution? Instead, the reader is > > overwhelmed with the complexity of the "yang-data" definition, and most > > tools cannot process the module. > > There are tools that can use yang-data. > Not all use-cases involve a server to query for a yang-library. Sure, but it is not necessary, I meant it just as an option. Such YANG modules can be passed straight to tools. > Offline tools need to know about the special data somehow. Why? Let's say I want the ascii tree, and pyang will be able to generate it. All right, there will be "rw" labels that don't apply but it is not a big deal. > The yang-data extension prevents data-def-stmts from being treated > as if they were configuration or operational data. This would be a problem if this yang-data is mixed with standard data in the same module. IMO this can be avoided, and then for it is essentially irrelevant for tools whether it is normal data or not. > > I agree with you that unconstrained use of yang-data is questionable > for a standard extension. The bar should be that all tools which choose > to implement the extension should provide the user with the same behavior. > Declaring that behavior out-of-scope does not help interoperability at all. Yes, and so my proposal here is to silently misuse YANG somewhat where necessary rather than spend cycles on a Standard Track document that gives a false impression of a general solution. It would be great to remove NETCONF specifics from YANG and I'd be willing to contribute to this work. Lada > > > > Lada > > > > Andy > > > > > > >> A plain client can ignore yang-data and not affect and RPC, notification, > > or > > >> data > > >> definitions in plain YANG. > > > > > > A plain (NC/RC) client should never see such data even if it is not > > protected by > > > yang-data in YANG. On the other hand, tools will be able to process such > > schemas > > > (generate the ascii tree, convert it to something else, generate sample > > > instances etc.) without explicitly supporting yang-data. > > > > > > Lada > > > > > >> > > >> > > >> > Lada > > >> > > > >> > > >> Andy > > >> > > >> > > there is a version of YANG that has a proper and complete integrated > > >> > > solution. (If for example yang-data is used to declare error content > > >> > > for RPCs, then more extensions are needed or a proper integration > > into > > >> > > YANG. Is it really good to introduce augment-yang-data (instead of > > >> > > making augment work with say 'data' in YANG 1.2)? And then we do > > >> > > uses-yang-data etc. > > >> > > > > >> > > /js > > >> > > > > >> > -- > > >> > Ladislav Lhotka > > >> > Head, CZ.NIC Labs > > >> > PGP Key ID: 0xB8F92B08A9F76C67 > > >> > > > >> > _______________________________________________ > > >> > netmod mailing list > > >> > netmod@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/netmod > > >> > > >> > > > -- > > > Ladislav Lhotka > > > Head, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 27 03:03:31 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267EC12DA46 for ; Fri, 27 Apr 2018 03:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKOLBKdVSB9A for ; Fri, 27 Apr 2018 03:03:27 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD8112DA41 for ; Fri, 27 Apr 2018 03:03:27 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id BA9A61AE030D; Fri, 27 Apr 2018 12:03:25 +0200 (CEST) Date: Fri, 27 Apr 2018 12:03:25 +0200 (CEST) Message-Id: <20180427.120325.419501937185262392.mbj@tail-f.com> To: lhotka@nic.cz Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 10:03:29 -0000 Hi, Ladislav Lhotka wrote: > On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote: > > > > > > On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka wrote: > > > Ladislav Lhotka writes: > > > > > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: > > > >> > > > >> > > > >> On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka wrote: > > > >> > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote: > > > >> > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund wrote: > > > >> > > > Ladislav Lhotka wrote: > > > >> > > > > Martin Bjorklund writes: > > > >> > > > > > > > >> > > > > > Hi, > > > >> > > > > > > > > >> > > > > > I am not sure what this statement tells us re. the issue in > > > this > > > >> > email > > > >> > > > > > thread. > > > >> > > > > > > > >> > > > > It tells us that, in my view, the approach taken in this document > > > is a > > > >> > > > > bad idea. > > > >> > > > > > > >> > > > Do you mean that the WG shoud drop this document? And people that > > > >> > > > need yang-data should continue to use the version in 8040? Or that > > > >> > > > people that need yang-data do not have a valid use case and they > > > >> > > > should do something else? > > > >> > > > > > >> > > One option is that people use yang-data as defined in RFC 8040 until > > > >> > > > > >> > IMO, people should use plain YANG. With the new YANG library it will be > > > >> > possible > > > >> > to confine such non-NM schemas in a special datastore so that the > > > intention > > > >> > should be clear and multi-module schemas with all the additional data > > > >> > (versions, > > > >> > features, deviations) can be used. > > > >> > > > > >> > > > >> I don't see how yang-data interferes with "plain YANG" at all. > > > >> It is for data that is not in scope for plain YANG. > > > > > > > > My question is why this extension is needed in the first place. > > > > > > For example, RFC 8040 could have used two modules instead of > > > "ietf-restconf", one with the contents of grouping "errors" and the > > > other with the contents of grouping "restconf". No extension. > > > > > > > This is true. We used to do this before yang-data was available. > > If I remember correctly, the stuff was inside groupings that were not used > anywhere. Which doesn't quite work, since no namespace is attached to the nodes. > > > What would be wrong with this solution? Instead, the reader is > > > overwhelmed with the complexity of the "yang-data" definition, and most > > > tools cannot process the module. > > > > There are tools that can use yang-data. > > Not all use-cases involve a server to query for a yang-library. > > Sure, but it is not necessary, I meant it just as an option. Such YANG modules > can be passed straight to tools. > > > Offline tools need to know about the special data somehow. > > Why? Let's say I want the ascii tree, and pyang will be able to generate it. All > right, there will be "rw" labels that don't apply but it is not a big deal. > > > The yang-data extension prevents data-def-stmts from being treated > > as if they were configuration or operational data. > > This would be a problem if this yang-data is mixed with standard data in the > same module. IMO this can be avoided, and then for it is essentially irrelevant > for tools whether it is normal data or not. > > > > > I agree with you that unconstrained use of yang-data is questionable > > for a standard extension. The bar should be that all tools which choose > > to implement the extension should provide the user with the same behavior. > > Declaring that behavior out-of-scope does not help interoperability at all. > > Yes, and so my proposal here is to silently misuse YANG somewhat where necessary > rather than spend cycles on a Standard Track document that gives a false > impression of a general solution. I am strongly opposed to this. IMO it is much better to put such structures in an extension, which tools that don't understand it will ignore, than relying on description statements in normal data nodes, which no tool can understand without hard coding special cases. > It would be great to remove NETCONF specifics from YANG and I'd be willing to > contribute to this work. This is a different topic though. /martin > > Lada > > > > > > > > Lada > > > > > > > Andy > > > > > > > > > >> A plain client can ignore yang-data and not affect and RPC, notification, > > > or > > > >> data > > > >> definitions in plain YANG. > > > > > > > > A plain (NC/RC) client should never see such data even if it is not > > > protected by > > > > yang-data in YANG. On the other hand, tools will be able to process such > > > schemas > > > > (generate the ascii tree, convert it to something else, generate sample > > > > instances etc.) without explicitly supporting yang-data. > > > > > > > > Lada > > > > > > > >> > > > >> > > > >> > Lada > > > >> > > > > >> > > > >> Andy > > > >> > > > >> > > there is a version of YANG that has a proper and complete integrated > > > >> > > solution. (If for example yang-data is used to declare error content > > > >> > > for RPCs, then more extensions are needed or a proper integration > > > into > > > >> > > YANG. Is it really good to introduce augment-yang-data (instead of > > > >> > > making augment work with say 'data' in YANG 1.2)? And then we do > > > >> > > uses-yang-data etc. > > > >> > > > > > >> > > /js > > > >> > > > > > >> > -- > > > >> > Ladislav Lhotka > > > >> > Head, CZ.NIC Labs > > > >> > PGP Key ID: 0xB8F92B08A9F76C67 > > > >> > > > > >> > _______________________________________________ > > > >> > netmod mailing list > > > >> > netmod@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/netmod > > > >> > > > >> > > > > -- > > > > Ladislav Lhotka > > > > Head, CZ.NIC Labs > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Apr 27 03:23:50 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB161243FE for ; Fri, 27 Apr 2018 03:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnHPy3mZaOYX for ; Fri, 27 Apr 2018 03:23:45 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F731127076 for ; Fri, 27 Apr 2018 03:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7230; q=dns/txt; s=iport; t=1524824625; x=1526034225; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=nSimABvrcp7Mh0KnL1itO5NMY1FTkcJ/0CgykPGOuwA=; b=NcC4SO24pnZp/TiJxDZMyDPhjRyQly78VsXS1tUJ60XnB8WTgYpzwLCa qSRCE5/XHTwRetsyHeegWX7l2jGRMzXcd3ck3qh6otXtOaFQBbjtSFnz8 ct1CkTJh8yA2XEk7lEJ+JuEjCmPK2/W2xNN1y4o5/DzSZyK7uPKkZrQTV c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQB1+eJa/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMUgRB6KINriGCOEYEPkxQUgWQLGAuEA0YCgm42FgECAQE?= =?us-ascii?q?BAQEBAmwcDIUpAQEBAwEBIQ8BBTYLEAsOCgICJgICJzAGAQwGAgEBF4R0D6g?= =?us-ascii?q?SghyEWIN2gkAFgQmIXz+BMoFpf4MRAQGBLQESAQmDFoJUApgNCI5EBodOhQe?= =?us-ascii?q?LGIUigSUiATFhcTMaCBsVO4JDixCFPz4wjwSCNwEB?= X-IronPort-AV: E=Sophos;i="5.49,334,1520899200"; d="scan'208";a="3436306" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2018 10:23:43 +0000 Received: from [10.63.23.54] (dhcp-ensft1-uk-vla370-10-63-23-54.cisco.com [10.63.23.54]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w3RANhFj024792; Fri, 27 Apr 2018 10:23:43 GMT To: Martin Bjorklund , lhotka@nic.cz Cc: netmod@ietf.org References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> From: Robert Wilton Message-ID: <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> Date: Fri, 27 Apr 2018 11:23:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180427.120325.419501937185262392.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 10:23:48 -0000 On 27/04/2018 11:03, Martin Bjorklund wrote: > Hi, > > Ladislav Lhotka wrote: >> On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote: >>> >>> On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka wrote: >>>> Ladislav Lhotka writes: >>>> >>>>> On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: >>>>>> >>>>>> On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka wrote: >>>>>>> On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote: >>>>>>>> On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund wrote: >>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>> Martin Bjorklund writes: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I am not sure what this statement tells us re. the issue in >>>> this >>>>>>> email >>>>>>>>>>> thread. >>>>>>>>>> It tells us that, in my view, the approach taken in this document >>>> is a >>>>>>>>>> bad idea. >>>>>>>>> Do you mean that the WG shoud drop this document? And people that >>>>>>>>> need yang-data should continue to use the version in 8040? Or that >>>>>>>>> people that need yang-data do not have a valid use case and they >>>>>>>>> should do something else? >>>>>>>> One option is that people use yang-data as defined in RFC 8040 until >>>>>>> IMO, people should use plain YANG. With the new YANG library it will be >>>>>>> possible >>>>>>> to confine such non-NM schemas in a special datastore so that the >>>> intention >>>>>>> should be clear and multi-module schemas with all the additional data >>>>>>> (versions, >>>>>>> features, deviations) can be used. >>>>>>> >>>>>> I don't see how yang-data interferes with "plain YANG" at all. >>>>>> It is for data that is not in scope for plain YANG. >>>>> My question is why this extension is needed in the first place. >>>> For example, RFC 8040 could have used two modules instead of >>>> "ietf-restconf", one with the contents of grouping "errors" and the >>>> other with the contents of grouping "restconf". No extension. >>>> >>> This is true. We used to do this before yang-data was available. >> If I remember correctly, the stuff was inside groupings that were not used >> anywhere. > Which doesn't quite work, since no namespace is attached to the nodes. OK.  So, using plain groupings doesn't work. In cases where groupings are being used within a YANG defined RPC, then presumably they do work OK? Is the specific problem scenario where the data is external to YANG defined RPCs, but yet it is still desirable to use a YANG schema and one of the associated YANG encodings to describe/encode the data? > >>>> What would be wrong with this solution? Instead, the reader is >>>> overwhelmed with the complexity of the "yang-data" definition, and most >>>> tools cannot process the module. >>> There are tools that can use yang-data. >>> Not all use-cases involve a server to query for a yang-library. >> Sure, but it is not necessary, I meant it just as an option. Such YANG modules >> can be passed straight to tools. >> >>> Offline tools need to know about the special data somehow. >> Why? Let's say I want the ascii tree, and pyang will be able to generate it. All >> right, there will be "rw" labels that don't apply but it is not a big deal. >> >>> The yang-data extension prevents data-def-stmts from being treated >>> as if they were configuration or operational data. >> This would be a problem if this yang-data is mixed with standard data in the >> same module. IMO this can be avoided, and then for it is essentially irrelevant >> for tools whether it is normal data or not. >> >>> I agree with you that unconstrained use of yang-data is questionable >>> for a standard extension. The bar should be that all tools which choose >>> to implement the extension should provide the user with the same behavior. >>> Declaring that behavior out-of-scope does not help interoperability at all. >> Yes, and so my proposal here is to silently misuse YANG somewhat where necessary >> rather than spend cycles on a Standard Track document that gives a false >> impression of a general solution. > I am strongly opposed to this. IMO it is much better to put such > structures in an extension, which tools that don't understand it will > ignore, than relying on description statements in normal data nodes, > which no tool can understand without hard coding special cases. I'm also opposed to this. Stuff that looks like configuration should be configuration, and stuff that looks like state should be state.  If this data is going to be described in YANG then I think that there must be a programmatic way to indicate that the resultant schema is not configuration or operational state, but something else instead.  An extension seems to achieve this. Thanks, Rob > > >> It would be great to remove NETCONF specifics from YANG and I'd be willing to >> contribute to this work. > This is a different topic though. > > > /martin > > >> Lada >> >>> >>>> Lada >>>> >>> Andy >>> >>>>>> A plain client can ignore yang-data and not affect and RPC, notification, >>>> or >>>>>> data >>>>>> definitions in plain YANG. >>>>> A plain (NC/RC) client should never see such data even if it is not >>>> protected by >>>>> yang-data in YANG. On the other hand, tools will be able to process such >>>> schemas >>>>> (generate the ascii tree, convert it to something else, generate sample >>>>> instances etc.) without explicitly supporting yang-data. >>>>> >>>>> Lada >>>>> >>>>>> >>>>>>> Lada >>>>>>> >>>>>> Andy >>>>>> >>>>>>>> there is a version of YANG that has a proper and complete integrated >>>>>>>> solution. (If for example yang-data is used to declare error content >>>>>>>> for RPCs, then more extensions are needed or a proper integration >>>> into >>>>>>>> YANG. Is it really good to introduce augment-yang-data (instead of >>>>>>>> making augment work with say 'data' in YANG 1.2)? And then we do >>>>>>>> uses-yang-data etc. >>>>>>>> >>>>>>>> /js >>>>>>>> >>>>>>> -- >>>>>>> Ladislav Lhotka >>>>>>> Head, CZ.NIC Labs >>>>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netmod mailing list >>>>>>> netmod@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>> >>>>> -- >>>>> Ladislav Lhotka >>>>> Head, CZ.NIC Labs >>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Fri Apr 27 04:04:11 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9418C120726 for ; Fri, 27 Apr 2018 04:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JI0esHitrOOX for ; Fri, 27 Apr 2018 04:04:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1689512E044 for ; Fri, 27 Apr 2018 04:03:55 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1c31:edff:fe5a:e0ce]) by mail.nic.cz (Postfix) with ESMTPSA id 2606662505; Fri, 27 Apr 2018 13:03:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1524827033; bh=Rs1lx4n+tbD3ta5B66A+F8t0SgvArha1noJ8jMzctgM=; h=From:To:Date; b=ZyRxmrcy5YuhIs4yosSJLFr42+Nisnh8Yus0M93iqzicyZlyAyCtdtLGB+P+rhimW 3IfrwDL2vLI6Odey/RqgnALIG59ALnaHVLRSrlReKKHd+L8ERVQCOeqR3ZqnNrAAT9 RFoe9ZtU3EtxjsNZFGXosu3Ap7TbhVGC2Z52/MtY= Message-ID: <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> From: Ladislav Lhotka To: Robert Wilton , Martin Bjorklund Cc: netmod@ietf.org Date: Fri, 27 Apr 2018 13:03:58 +0200 In-Reply-To: <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 11:04:09 -0000 On Fri, 2018-04-27 at 11:23 +0100, Robert Wilton wrote: > > On 27/04/2018 11:03, Martin Bjorklund wrote: > > Hi, > > > > Ladislav Lhotka wrote: > > > On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote: > > > > > > > > On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka wrote: > > > > > Ladislav Lhotka writes: > > > > > > > > > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: > > > > > > > > > > > > > > On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka > > > > > > > wrote: > > > > > > > > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote: > > > > > > > > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund > > > > > > > > > wrote: > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > > > > > > Martin Bjorklund writes: > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > I am not sure what this statement tells us re. the issue > > > > > > > > > > > > in > > > > > > > > > > this > > > > > > > > email > > > > > > > > > > > > thread. > > > > > > > > > > > > > > > > > > > > > > It tells us that, in my view, the approach taken in this > > > > > > > > > > > document > > > > > > > > > > is a > > > > > > > > > > > bad idea. > > > > > > > > > > > > > > > > > > > > Do you mean that the WG shoud drop this document? And > > > > > > > > > > people that > > > > > > > > > > need yang-data should continue to use the version in > > > > > > > > > > 8040? Or that > > > > > > > > > > people that need yang-data do not have a valid use case and > > > > > > > > > > they > > > > > > > > > > should do something else? > > > > > > > > > > > > > > > > > > One option is that people use yang-data as defined in RFC 8040 > > > > > > > > > until > > > > > > > > > > > > > > > > IMO, people should use plain YANG. With the new YANG library it > > > > > > > > will be > > > > > > > > possible > > > > > > > > to confine such non-NM schemas in a special datastore so that > > > > > > > > the > > > > > > > > > > intention > > > > > > > > should be clear and multi-module schemas with all the additional > > > > > > > > data > > > > > > > > (versions, > > > > > > > > features, deviations) can be used. > > > > > > > > > > > > > > > > > > > > > > I don't see how yang-data interferes with "plain YANG" at all. > > > > > > > It is for data that is not in scope for plain YANG. > > > > > > > > > > > > My question is why this extension is needed in the first place. > > > > > > > > > > For example, RFC 8040 could have used two modules instead of > > > > > "ietf-restconf", one with the contents of grouping "errors" and the > > > > > other with the contents of grouping "restconf". No extension. > > > > > > > > > > > > > This is true. We used to do this before yang-data was available. > > > > > > If I remember correctly, the stuff was inside groupings that were not used > > > anywhere. > > > > Which doesn't quite work, since no namespace is attached to the nodes. Note that this is not what I was proposing. For RESTCONF errors, the module I had in mind could be like this: module ietf-restconf-errors { container errors { // same content as in RFC 8040 ... } ... } Please explain why this cannot serve the given purpose, apart from the fact that it looks like configuration which it isn't - but this can be explained in the module description. With this module, one could validate error messages using generic YANG tools etc. (I am not proposing to update RFC 8040, just using it as an example.) > > OK. So, using plain groupings doesn't work. > > In cases where groupings are being used within a YANG defined RPC, then > presumably they do work OK? > > Is the specific problem scenario where the data is external to YANG > defined RPCs, but yet it is still desirable to use a YANG schema and one > of the associated YANG encodings to describe/encode the data? > > > > > > > > > What would be wrong with this solution? Instead, the reader is > > > > > overwhelmed with the complexity of the "yang-data" definition, and > > > > > most > > > > > tools cannot process the module. > > > > > > > > There are tools that can use yang-data. > > > > Not all use-cases involve a server to query for a yang-library. > > > > > > Sure, but it is not necessary, I meant it just as an option. Such YANG > > > modules > > > can be passed straight to tools. > > > > > > > Offline tools need to know about the special data somehow. > > > > > > Why? Let's say I want the ascii tree, and pyang will be able to generate > > > it. All > > > right, there will be "rw" labels that don't apply but it is not a big > > > deal. > > > > > > > The yang-data extension prevents data-def-stmts from being treated > > > > as if they were configuration or operational data. > > > > > > This would be a problem if this yang-data is mixed with standard data in > > > the > > > same module. IMO this can be avoided, and then for it is essentially > > > irrelevant > > > for tools whether it is normal data or not. > > > > > > > I agree with you that unconstrained use of yang-data is questionable > > > > for a standard extension. The bar should be that all tools which choose > > > > to implement the extension should provide the user with the same > > > > behavior. > > > > Declaring that behavior out-of-scope does not help interoperability at > > > > all. > > > > > > Yes, and so my proposal here is to silently misuse YANG somewhat where > > > necessary > > > rather than spend cycles on a Standard Track document that gives a false > > > impression of a general solution. > > > > I am strongly opposed to this. IMO it is much better to put such > > structures in an extension, which tools that don't understand it will > > ignore, than relying on description statements in normal data nodes, > > which no tool can understand without hard coding special cases. > > I'm also opposed to this. > > Stuff that looks like configuration should be configuration, and stuff > that looks like state should be state. If this data is going to be > described in YANG then I think that there must be a programmatic way to > indicate that the resultant schema is not configuration or operational > state, but something else instead. An extension seems to achieve this. YANG spec deals exclusively with configuration and state data, and using its statements inside an extension doesn't make this basic fact go away. Specifying all necessary changes properly inside a description of an extension is simply impossible. Lada > > Thanks, > Rob > > > > > > > > > It would be great to remove NETCONF specifics from YANG and I'd be willing > > > to > > > contribute to this work. > > > > This is a different topic though. > > > > > > /martin > > > > > > > Lada > > > > > > > > > > > > Lada > > > > > > > > > > > > > Andy > > > > > > > > > > > A plain client can ignore yang-data and not affect and RPC, > > > > > > > notification, > > > > > > > > > > or > > > > > > > data > > > > > > > definitions in plain YANG. > > > > > > > > > > > > A plain (NC/RC) client should never see such data even if it is not > > > > > > > > > > protected by > > > > > > yang-data in YANG. On the other hand, tools will be able to process > > > > > > such > > > > > > > > > > schemas > > > > > > (generate the ascii tree, convert it to something else, generate > > > > > > sample > > > > > > instances etc.) without explicitly supporting yang-data. > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > there is a version of YANG that has a proper and complete > > > > > > > > > integrated > > > > > > > > > solution. (If for example yang-data is used to declare error > > > > > > > > > content > > > > > > > > > for RPCs, then more extensions are needed or a proper > > > > > > > > > integration > > > > > > > > > > into > > > > > > > > > YANG. Is it really good to introduce augment-yang-data > > > > > > > > > (instead of > > > > > > > > > making augment work with say 'data' in YANG 1.2)? And then we > > > > > > > > > do > > > > > > > > > uses-yang-data etc. > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Ladislav Lhotka > > > > > > > > Head, CZ.NIC Labs > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > netmod mailing list > > > > > > > > netmod@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > -- > > > > > > Ladislav Lhotka > > > > > > Head, CZ.NIC Labs > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > > Ladislav Lhotka > > > Head, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 27 04:19:50 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EDA124BFA for ; Fri, 27 Apr 2018 04:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxHXpp2OX2ct for ; Fri, 27 Apr 2018 04:19:45 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D06D1200F1 for ; Fri, 27 Apr 2018 04:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9515; q=dns/txt; s=iport; t=1524827985; x=1526037585; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=PKELNGYEGuyl0YS0Bzf5saQkQ0S19WyLZyWu4115tzQ=; b=WCtR2Hexh0TXF42Kewq9xlsx7mzmhfFZBgjiYR/u7eKLJ3m9gbvfQZmF rYiFHDQgjdBC91be+FpJ8g5L7wWohYiANvlB/MgUKojR/yvKc940h6Akf gLUrPS3geoSND4g41RF/ctX/DNewVpm9rXeToeEwHfbdbesqpUuNcE3FM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQB0BuNa/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQkeiiDa4hgjhGBD5MUFIFkCxgLhANGAoJuNRcBAgEBAQE?= =?us-ascii?q?BAQJsHAyFKAEBAQECAQEBIRU2CxALGAICJgICJzAGAQwGAgEBF4RsCA+oAoI?= =?us-ascii?q?chFiDdYJABYEJiF8/gTKBaX+DEQEBgS0BEgEJgxaCVAKYDQiORAaBNYNggjm?= =?us-ascii?q?FB4c9g1uFIoElHQE2YXEzGggbFTuCQ4sQhT8+MI53DRcHghkBAQ?= X-IronPort-AV: E=Sophos;i="5.49,335,1520899200"; d="scan'208";a="3390788" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2018 11:19:42 +0000 Received: from [10.63.23.54] (dhcp-ensft1-uk-vla370-10-63-23-54.cisco.com [10.63.23.54]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w3RBJfNl005975; Fri, 27 Apr 2018 11:19:41 GMT To: Ladislav Lhotka , Martin Bjorklund Cc: netmod@ietf.org References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> From: Robert Wilton Message-ID: <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> Date: Fri, 27 Apr 2018 12:19:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 11:19:48 -0000 On 27/04/2018 12:03, Ladislav Lhotka wrote: > On Fri, 2018-04-27 at 11:23 +0100, Robert Wilton wrote: >> On 27/04/2018 11:03, Martin Bjorklund wrote: >>> Hi, >>> >>> Ladislav Lhotka wrote: >>>> On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote: >>>>> On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka wrote: >>>>>> Ladislav Lhotka writes: >>>>>> >>>>>>> On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: >>>>>>>> On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka >>>>>>>> wrote: >>>>>>>>> On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote: >>>>>>>>>> On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund >>>>>>>>>> wrote: >>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>> Martin Bjorklund writes: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I am not sure what this statement tells us re. the issue >>>>>>>>>>>>> in >>>>>> this >>>>>>>>> email >>>>>>>>>>>>> thread. >>>>>>>>>>>> It tells us that, in my view, the approach taken in this >>>>>>>>>>>> document >>>>>> is a >>>>>>>>>>>> bad idea. >>>>>>>>>>> Do you mean that the WG shoud drop this document? And >>>>>>>>>>> people that >>>>>>>>>>> need yang-data should continue to use the version in >>>>>>>>>>> 8040? Or that >>>>>>>>>>> people that need yang-data do not have a valid use case and >>>>>>>>>>> they >>>>>>>>>>> should do something else? >>>>>>>>>> One option is that people use yang-data as defined in RFC 8040 >>>>>>>>>> until >>>>>>>>> IMO, people should use plain YANG. With the new YANG library it >>>>>>>>> will be >>>>>>>>> possible >>>>>>>>> to confine such non-NM schemas in a special datastore so that >>>>>>>>> the >>>>>> intention >>>>>>>>> should be clear and multi-module schemas with all the additional >>>>>>>>> data >>>>>>>>> (versions, >>>>>>>>> features, deviations) can be used. >>>>>>>>> >>>>>>>> I don't see how yang-data interferes with "plain YANG" at all. >>>>>>>> It is for data that is not in scope for plain YANG. >>>>>>> My question is why this extension is needed in the first place. >>>>>> For example, RFC 8040 could have used two modules instead of >>>>>> "ietf-restconf", one with the contents of grouping "errors" and the >>>>>> other with the contents of grouping "restconf". No extension. >>>>>> >>>>> This is true. We used to do this before yang-data was available. >>>> If I remember correctly, the stuff was inside groupings that were not used >>>> anywhere. >>> Which doesn't quite work, since no namespace is attached to the nodes. > Note that this is not what I was proposing. For RESTCONF errors, the module I > had in mind could be like this: > > module ietf-restconf-errors { > > container errors { // same content as in RFC 8040 > ... > } > > ... > > } > > Please explain why this cannot serve the given purpose, apart from the fact that > it looks like configuration which it isn't - but this can be explained in the > module description. It is the "because it looks like configuration" that I don't like. If the server supports and advertises this module then it is reasonable to expect that a client should be able to configure the errors container, since it is configuration ... At least marking it as config false would be slightly better. > > With this module, one could validate error messages using generic YANG tools > etc. > > (I am not proposing to update RFC 8040, just using it as an example.) > >> OK. So, using plain groupings doesn't work. >> >> In cases where groupings are being used within a YANG defined RPC, then >> presumably they do work OK? >> >> Is the specific problem scenario where the data is external to YANG >> defined RPCs, but yet it is still desirable to use a YANG schema and one >> of the associated YANG encodings to describe/encode the data? >> >> >>>>>> What would be wrong with this solution? Instead, the reader is >>>>>> overwhelmed with the complexity of the "yang-data" definition, and >>>>>> most >>>>>> tools cannot process the module. >>>>> There are tools that can use yang-data. >>>>> Not all use-cases involve a server to query for a yang-library. >>>> Sure, but it is not necessary, I meant it just as an option. Such YANG >>>> modules >>>> can be passed straight to tools. >>>> >>>>> Offline tools need to know about the special data somehow. >>>> Why? Let's say I want the ascii tree, and pyang will be able to generate >>>> it. All >>>> right, there will be "rw" labels that don't apply but it is not a big >>>> deal. >>>> >>>>> The yang-data extension prevents data-def-stmts from being treated >>>>> as if they were configuration or operational data. >>>> This would be a problem if this yang-data is mixed with standard data in >>>> the >>>> same module. IMO this can be avoided, and then for it is essentially >>>> irrelevant >>>> for tools whether it is normal data or not. >>>> >>>>> I agree with you that unconstrained use of yang-data is questionable >>>>> for a standard extension. The bar should be that all tools which choose >>>>> to implement the extension should provide the user with the same >>>>> behavior. >>>>> Declaring that behavior out-of-scope does not help interoperability at >>>>> all. >>>> Yes, and so my proposal here is to silently misuse YANG somewhat where >>>> necessary >>>> rather than spend cycles on a Standard Track document that gives a false >>>> impression of a general solution. >>> I am strongly opposed to this. IMO it is much better to put such >>> structures in an extension, which tools that don't understand it will >>> ignore, than relying on description statements in normal data nodes, >>> which no tool can understand without hard coding special cases. >> I'm also opposed to this. >> >> Stuff that looks like configuration should be configuration, and stuff >> that looks like state should be state. If this data is going to be >> described in YANG then I think that there must be a programmatic way to >> indicate that the resultant schema is not configuration or operational >> state, but something else instead. An extension seems to achieve this. > YANG spec deals exclusively with configuration and state data, and using its > statements inside an extension doesn't make this basic fact go away. Specifying > all necessary changes properly inside a description of an extension is simply > impossible. If an implementation needs to support generating the error messages then they can support the yang-data extension if they want (or just hard code what they expect to receive). Otherwise, devices can also ignore the yang-data extension and it doesn't seem to do any harm since its doesn't change the behaviour in any way. Thanks, Rob > > Lada > >> Thanks, >> Rob >> >> >>> >>>> It would be great to remove NETCONF specifics from YANG and I'd be willing >>>> to >>>> contribute to this work. >>> This is a different topic though. >>> >>> >>> /martin >>> >>> >>>> Lada >>>> >>>>>> Lada >>>>>> >>>>> Andy >>>>> >>>>>>>> A plain client can ignore yang-data and not affect and RPC, >>>>>>>> notification, >>>>>> or >>>>>>>> data >>>>>>>> definitions in plain YANG. >>>>>>> A plain (NC/RC) client should never see such data even if it is not >>>>>> protected by >>>>>>> yang-data in YANG. On the other hand, tools will be able to process >>>>>>> such >>>>>> schemas >>>>>>> (generate the ascii tree, convert it to something else, generate >>>>>>> sample >>>>>>> instances etc.) without explicitly supporting yang-data. >>>>>>> >>>>>>> Lada >>>>>>> >>>>>>>> >>>>>>>>> Lada >>>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>>>> there is a version of YANG that has a proper and complete >>>>>>>>>> integrated >>>>>>>>>> solution. (If for example yang-data is used to declare error >>>>>>>>>> content >>>>>>>>>> for RPCs, then more extensions are needed or a proper >>>>>>>>>> integration >>>>>> into >>>>>>>>>> YANG. Is it really good to introduce augment-yang-data >>>>>>>>>> (instead of >>>>>>>>>> making augment work with say 'data' in YANG 1.2)? And then we >>>>>>>>>> do >>>>>>>>>> uses-yang-data etc. >>>>>>>>>> >>>>>>>>>> /js >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ladislav Lhotka >>>>>>>>> Head, CZ.NIC Labs >>>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> netmod mailing list >>>>>>>>> netmod@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>> -- >>>>>>> Ladislav Lhotka >>>>>>> Head, CZ.NIC Labs >>>>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netmod mailing list >>>>>>> netmod@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> -- >>>> Ladislav Lhotka >>>> Head, CZ.NIC Labs >>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> >> From nobody Fri Apr 27 07:34:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361D5124234 for ; Fri, 27 Apr 2018 07:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVDLi3OpDiVv for ; Fri, 27 Apr 2018 07:34:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503321205D3 for ; Fri, 27 Apr 2018 07:34:35 -0700 (PDT) Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 74A8162667; Fri, 27 Apr 2018 16:34:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1524839673; bh=9xsKD+OtPnBt9XXrkhmJ4s3R+Aa+Mfbp/eHGaKVrcgQ=; h=From:To:Date; b=UThjAH4fQiAfk9JOlFufII1mZmE9YugZ+HKGPSwqw+Y1Yr/ZrzN9byHdVLRuZB3fV glFFnja6QxR9G24ReX8DoUF/hyi8TPTWEPFRrAkQamLqIjM2Sg5XRzyzzzUKnwwnhG egy4leMeYmASfjKJHhVmtP8QR8b98vwFEKC/4vyM= Message-ID: From: Ladislav Lhotka To: Robert Wilton , Martin Bjorklund Cc: netmod@ietf.org Date: Fri, 27 Apr 2018 16:34:38 +0200 In-Reply-To: <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 14:34:40 -0000 On Fri, 2018-04-27 at 12:19 +0100, Robert Wilton wrote: > > On 27/04/2018 12:03, Ladislav Lhotka wrote: > > On Fri, 2018-04-27 at 11:23 +0100, Robert Wilton wrote: > > > On 27/04/2018 11:03, Martin Bjorklund wrote: > > > > Hi, > > > > > > > > Ladislav Lhotka wrote: > > > > > On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote: > > > > > > On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka > > > > > > wrote: > > > > > > > Ladislav Lhotka writes: > > > > > > > > > > > > > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: > > > > > > > > > On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka > > > > > > > > z> > > > > > > > > > wrote: > > > > > > > > > > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder > > > > > > > > > > wrote: > > > > > > > > > > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund > > > > > > > > > > > wrote: > > > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > > > > > > > > Martin Bjorklund writes: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure what this statement tells us re. the > > > > > > > > > > > > > > issue > > > > > > > > > > > > > > in > > > > > > > > > > > > > > this > > > > > > > > > > email > > > > > > > > > > > > > > thread. > > > > > > > > > > > > > > > > > > > > > > > > > > It tells us that, in my view, the approach taken in > > > > > > > > > > > > > this > > > > > > > > > > > > > document > > > > > > > > > > > > > > is a > > > > > > > > > > > > > bad idea. > > > > > > > > > > > > > > > > > > > > > > > > Do you mean that the WG shoud drop this document? And > > > > > > > > > > > > people that > > > > > > > > > > > > need yang-data should continue to use the version in > > > > > > > > > > > > 8040? Or that > > > > > > > > > > > > people that need yang-data do not have a valid use case > > > > > > > > > > > > and > > > > > > > > > > > > they > > > > > > > > > > > > should do something else? > > > > > > > > > > > > > > > > > > > > > > One option is that people use yang-data as defined in RFC > > > > > > > > > > > 8040 > > > > > > > > > > > until > > > > > > > > > > > > > > > > > > > > IMO, people should use plain YANG. With the new YANG library > > > > > > > > > > it > > > > > > > > > > will be > > > > > > > > > > possible > > > > > > > > > > to confine such non-NM schemas in a special datastore so > > > > > > > > > > that > > > > > > > > > > the > > > > > > > > > > > > > > intention > > > > > > > > > > should be clear and multi-module schemas with all the > > > > > > > > > > additional > > > > > > > > > > data > > > > > > > > > > (versions, > > > > > > > > > > features, deviations) can be used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't see how yang-data interferes with "plain YANG" at all. > > > > > > > > > It is for data that is not in scope for plain YANG. > > > > > > > > > > > > > > > > My question is why this extension is needed in the first place. > > > > > > > > > > > > > > For example, RFC 8040 could have used two modules instead of > > > > > > > "ietf-restconf", one with the contents of grouping "errors" and > > > > > > > the > > > > > > > other with the contents of grouping "restconf". No extension. > > > > > > > > > > > > > > > > > > > This is true. We used to do this before yang-data was available. > > > > > > > > > > If I remember correctly, the stuff was inside groupings that were not > > > > > used > > > > > anywhere. > > > > > > > > Which doesn't quite work, since no namespace is attached to the nodes. > > > > Note that this is not what I was proposing. For RESTCONF errors, the module > > I > > had in mind could be like this: > > > > module ietf-restconf-errors { > > > > container errors { // same content as in RFC 8040 > > ... > > } > > > > ... > > > > } > > > > Please explain why this cannot serve the given purpose, apart from the fact > > that > > it looks like configuration which it isn't - but this can be explained in > > the > > module description. > > It is the "because it looks like configuration" that I don't like. IMO this won't change even if the same data is inside the "yang-data" extension because RFC 7950 says in sec. 7.21.1: If the top node does not specify a "config" statement, the default is "true". So even though the description of "yang-data" says that the "config" statement is ignored if present, it doesn't mean that schema nodes lose the config property. This may look like nitpicking but it illustrates the general problem: YANG was designed for a very specific context and using it elsewhere requires creative interpretation of its spec, with "yang-data" extension or without. > > If the server supports and advertises this module then it is reasonable > to expect that a client should be able to configure the errors > container, since it is configuration ... There is no point for the server to advertise it as a part of the standard datastores such as "intended". And in order to advertise it as a schema for error messages, it is IMO possible to use the trick that I suggested: define a special datastore for it, such as "error-messages". So it will be the datastore that enforces the desired semantics, and clients that support it can use it in the intended way. > > At least marking it as config false would be slightly better. > > > > > With this module, one could validate error messages using generic YANG tools > > etc. > > > > (I am not proposing to update RFC 8040, just using it as an example.) > > > > > OK. So, using plain groupings doesn't work. > > > > > > In cases where groupings are being used within a YANG defined RPC, then > > > presumably they do work OK? > > > > > > Is the specific problem scenario where the data is external to YANG > > > defined RPCs, but yet it is still desirable to use a YANG schema and one > > > of the associated YANG encodings to describe/encode the data? > > > > > > > > > > > > > What would be wrong with this solution? Instead, the reader is > > > > > > > overwhelmed with the complexity of the "yang-data" definition, and > > > > > > > most > > > > > > > tools cannot process the module. > > > > > > > > > > > > There are tools that can use yang-data. > > > > > > Not all use-cases involve a server to query for a yang-library. > > > > > > > > > > Sure, but it is not necessary, I meant it just as an option. Such YANG > > > > > modules > > > > > can be passed straight to tools. > > > > > > > > > > > Offline tools need to know about the special data somehow. > > > > > > > > > > Why? Let's say I want the ascii tree, and pyang will be able to > > > > > generate > > > > > it. All > > > > > right, there will be "rw" labels that don't apply but it is not a big > > > > > deal. > > > > > > > > > > > The yang-data extension prevents data-def-stmts from being treated > > > > > > as if they were configuration or operational data. > > > > > > > > > > This would be a problem if this yang-data is mixed with standard data > > > > > in > > > > > the > > > > > same module. IMO this can be avoided, and then for it is essentially > > > > > irrelevant > > > > > for tools whether it is normal data or not. > > > > > > > > > > > I agree with you that unconstrained use of yang-data is questionable > > > > > > for a standard extension. The bar should be that all tools which > > > > > > choose > > > > > > to implement the extension should provide the user with the same > > > > > > behavior. > > > > > > Declaring that behavior out-of-scope does not help interoperability > > > > > > at > > > > > > all. > > > > > > > > > > Yes, and so my proposal here is to silently misuse YANG somewhat where > > > > > necessary > > > > > rather than spend cycles on a Standard Track document that gives a > > > > > false > > > > > impression of a general solution. > > > > > > > > I am strongly opposed to this. IMO it is much better to put such > > > > structures in an extension, which tools that don't understand it will > > > > ignore, than relying on description statements in normal data nodes, > > > > which no tool can understand without hard coding special cases. > > > > > > I'm also opposed to this. > > > > > > Stuff that looks like configuration should be configuration, and stuff > > > that looks like state should be state. If this data is going to be > > > described in YANG then I think that there must be a programmatic way to > > > indicate that the resultant schema is not configuration or operational > > > state, but something else instead. An extension seems to achieve this. > > > > YANG spec deals exclusively with configuration and state data, and using its > > statements inside an extension doesn't make this basic fact go away. > > Specifying > > all necessary changes properly inside a description of an extension is > > simply > > impossible. > > If an implementation needs to support generating the error messages then > they can support the yang-data extension if they want (or just hard code > what they expect to receive). Or support the "error-messages" datastore, see above. Lada > > Otherwise, devices can also ignore the yang-data extension and it > doesn't seem to do any harm since its doesn't change the behaviour in > any way. > > Thanks, > Rob > > > > > > Lada > > > > > Thanks, > > > Rob > > > > > > > > > > > > > > > It would be great to remove NETCONF specifics from YANG and I'd be > > > > > willing > > > > > to > > > > > contribute to this work. > > > > > > > > This is a different topic though. > > > > > > > > > > > > /martin > > > > > > > > > > > > > Lada > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > A plain client can ignore yang-data and not affect and RPC, > > > > > > > > > notification, > > > > > > > > > > > > > > or > > > > > > > > > data > > > > > > > > > definitions in plain YANG. > > > > > > > > > > > > > > > > A plain (NC/RC) client should never see such data even if it is > > > > > > > > not > > > > > > > > > > > > > > protected by > > > > > > > > yang-data in YANG. On the other hand, tools will be able to > > > > > > > > process > > > > > > > > such > > > > > > > > > > > > > > schemas > > > > > > > > (generate the ascii tree, convert it to something else, generate > > > > > > > > sample > > > > > > > > instances etc.) without explicitly supporting yang-data. > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > there is a version of YANG that has a proper and complete > > > > > > > > > > > integrated > > > > > > > > > > > solution. (If for example yang-data is used to declare > > > > > > > > > > > error > > > > > > > > > > > content > > > > > > > > > > > for RPCs, then more extensions are needed or a proper > > > > > > > > > > > integration > > > > > > > > > > > > > > into > > > > > > > > > > > YANG. Is it really good to introduce augment-yang-data > > > > > > > > > > > (instead of > > > > > > > > > > > making augment work with say 'data' in YANG 1.2)? And then > > > > > > > > > > > we > > > > > > > > > > > do > > > > > > > > > > > uses-yang-data etc. > > > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Ladislav Lhotka > > > > > > > > > > Head, CZ.NIC Labs > > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > netmod mailing list > > > > > > > > > > netmod@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > > -- > > > > > > > > Ladislav Lhotka > > > > > > > > Head, CZ.NIC Labs > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > netmod mailing list > > > > > > > > netmod@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > _______________________________________________ > > > > > > > netmod mailing list > > > > > > > netmod@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > -- > > > > > Ladislav Lhotka > > > > > Head, CZ.NIC Labs > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > . > > > > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 27 07:47:16 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB9E1242F5 for ; Fri, 27 Apr 2018 07:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaqA5E188g-f for ; Fri, 27 Apr 2018 07:47:12 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B87F124234 for ; Fri, 27 Apr 2018 07:47:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id ADA7527; Fri, 27 Apr 2018 16:47:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id rn-nm3PaG-mM; Fri, 27 Apr 2018 16:47:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 27 Apr 2018 16:47:10 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8940D20036; Fri, 27 Apr 2018 16:47:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iqTzNXj5Phqy; Fri, 27 Apr 2018 16:47:10 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3EDF820035; Fri, 27 Apr 2018 16:47:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8BBC942C5507; Fri, 27 Apr 2018 16:47:08 +0200 (CEST) Date: Fri, 27 Apr 2018 16:47:08 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: netmod@ietf.org Message-ID: <20180427144708.6ekknrajexvz5yvf@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 14:47:15 -0000 On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote: > [...] define a special datastore for it, such as "error-messages". This seems worse than using, well, RFC 8040 yang-data. The proper clear solution for RPCs and actions would be to enable the definition of error details right in the rpc/action definition (input, output, error). But something like yang-data seems to have uses in other contexts. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 27 08:13:21 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF6E1252BA for ; Fri, 27 Apr 2018 08:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNOmw7gPfL2J for ; Fri, 27 Apr 2018 08:13:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20211242F7 for ; Fri, 27 Apr 2018 08:13:17 -0700 (PDT) Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 01F9562691; Fri, 27 Apr 2018 17:13:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1524841996; bh=dLpMu4HNSLkRqPwH0Id9xog7wf2wOkH0UuiH/EnZrNM=; h=From:To:Date; b=mQsJFGXDZbRW10zfjOveL+D0bNR2GZvoJqpOimvkFa2mBIyvWztAmNyOKiIGFtBP9 mDjIQDfIzkgVhZE+bMvPvazXZhV8jAf2Wv07BPTUk4IeyvPVvcnC74otocZ/muRLQ1 qazw+G4DY959bGEFPM9yO8eYJus8XDj3GAq7JuuE= Message-ID: <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> From: Ladislav Lhotka To: Juergen Schoenwaelder Cc: netmod@ietf.org Date: Fri, 27 Apr 2018 17:13:20 +0200 In-Reply-To: <20180427144708.6ekknrajexvz5yvf@elstar.local> References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <20180427144708.6ekknrajexvz5yvf@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 15:13:20 -0000 On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote: > On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote: > > > [...] define a special datastore for it, such as "error-messages". > > This seems worse than using, well, RFC 8040 yang-data. The proper Why it seems worse? > clear solution for RPCs and actions would be to enable the definition > of error details right in the rpc/action definition (input, output, > error). Agreed. > > But something like yang-data seems to have uses in other contexts. So other datastores may be defined. I assume that YANG library data can be used independently, not just on a NC/RC server, pretty much along the lines of draft- lengyel-netmod-yang-instance-data. Lada > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 27 08:58:39 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BF1126DEE for ; Fri, 27 Apr 2018 08:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zScYpiN7RtdR for ; Fri, 27 Apr 2018 08:58:35 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCDA126D0C for ; Fri, 27 Apr 2018 08:58:35 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id z130-v6so3409852lff.5 for ; Fri, 27 Apr 2018 08:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WP9AsK1GBJIPZ5FmVlGr/LpR9s959z3u+Ir2CDje+Io=; b=I8h5GYfVHeuQJJ3XwxZNqQJEy/biUDQ64isickPMAf6etJkvpPFCkT9TDpV//e3NOg i/ny1No8jRhQph/e/OzUg4524296dexnCKhajG+1PgtMMXA8Zvz9iYZXnEsWdsiFmfBM NvykZvrT+SvehM2/WhkWAgvaT3TVV3F+YBgHbGRfzbKigPSQ7cg9rgd7aYJ8t4MzmKi9 9614IDaCAxaMdBDUP2Prf+SsxvZqW5XzLR8UYwYicPGONP+pRvAi+U8u0YZRZQ6TWlCP b4DKbRhd/nJZsHrLfr3mlM/PAdln/GVeriLbrYMZr8FRynfHF2wrSaiUx927T1K9tiNt DJHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WP9AsK1GBJIPZ5FmVlGr/LpR9s959z3u+Ir2CDje+Io=; b=ter3CMHHqIznQSZEmzP9owPW+ZzAOVc6Uc1XmT1cUVIRVpvk2tR3+sZw215xuItVy0 OArG8XyC3mjybPtKa1xJt8EW29wPlESUYDYTVnkOf0OEySY7CjKvqol31hk3lUXn11L3 gtOULMm78pc6N1HhpZgkhw5wx6x7m+3N5yKADY13oMOE9f5EzZ4zLlPhKmS6TDjlsmoF 9HnIViVYLyVhDrmR/jwaKmV8rZzAAEVY08UAvtuaJM5XZDay2Elnxz4n2bpSBlbRRP4K GJHcaDKgHSVbNRneDSVldOCSBwokls7lqBZ5l/djfXmv79EGIlBZbD9VvOj0Zn9hpRyZ eBYg== X-Gm-Message-State: ALQs6tAhEFeXdFZEp5QGUrMb5Ra8h3bq9Reef5EsWmPE+4E1oyK3z8iQ MMrqn87+8PY0vZ7TUzizLbCkrpg8xt6tFmUZrWupDQ== X-Google-Smtp-Source: AB8JxZo+3joINE3oYgefqFdOuGOhi9u98Qe6oV3ZrjpsnHLQwmsnd60kSDOuqHsN0yN0mDd6zV7NwJXBrOGDgjCo7/8= X-Received: by 2002:a2e:90d4:: with SMTP id o20-v6mr2023863ljg.15.1524844713784; Fri, 27 Apr 2018 08:58:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Fri, 27 Apr 2018 08:58:32 -0700 (PDT) In-Reply-To: <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <20180427144708.6ekknrajexvz5yvf@elstar.local> <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> From: Andy Bierman Date: Fri, 27 Apr 2018 08:58:32 -0700 Message-ID: To: Ladislav Lhotka Cc: Juergen Schoenwaelder , NetMod WG Content-Type: multipart/alternative; boundary="00000000000080cdf4056ad693ff" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 15:58:38 -0000 --00000000000080cdf4056ad693ff Content-Type: text/plain; charset="UTF-8" On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka wrote: > On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote: > > On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote: > > > > > [...] define a special datastore for it, such as "error-messages". > > > > This seems worse than using, well, RFC 8040 yang-data. The proper > > Why it seems worse? > > Because this is not part of the NMDA. IMO, the yang-data defined in RFC 8040 has a clear purpose, and it is sufficient for that purpose, which is a YANG representation of an instance document (such as a protocol message or file). YANG is useful for defining data structures that can be represented in different formats, yet it is independent of any 1 format. I am in favor if keeping the yang-data in RFC 8040 and not creating a new version of it that is unconstrained. There does not seem to be consensus on how to do this, or even consensus that it is a good idea. > > clear solution for RPCs and actions would be to enable the definition > > of error details right in the rpc/action definition (input, output, > > error). > > Agreed. > > > > > But something like yang-data seems to have uses in other contexts. > > So other datastores may be defined. I assume that YANG library data can be > used > independently, not just on a NC/RC server, pretty much along the lines of > draft- > lengyel-netmod-yang-instance-data. > > Lada > > > > Andy > > /js > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000080cdf4056ad693ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
On Fri, 2018-04-27 at 16:47 += 0200, Juergen Schoenwaelder wrote:
> On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote:
>
> > [...] define a special datastore for it, such as "error-mess= ages".
>
> This seems worse than using, well, RFC 8040 yang-data. The proper

Why it seems worse?


Because this is not part of the NMDA.<= /div>
IMO, the yang-data defined in RFC 8040 has a clear purpose, and i= t
is sufficient for that purpose, which is a YANG representation = of
an instance document (such as a protocol message or file).

YANG is useful for defining data structures that can = be represented in
different formats, yet it is independent of any= 1 format.

I am in favor if keeping the yang-data = in RFC 8040 and not
creating a new version of it that is unconstr= ained.
There does not seem to be consensus on how to do this,
or even consensus that it is a good idea.

= =C2=A0
> clear solution for RPCs and actions would be to enable the definition<= br> > of error details right in the rpc/action definition (input, output, > error).

Agreed.

>
> But something like yang-data seems to have uses in other contexts.

So other datastores may be defined. I assume that YANG library data can be = used
independently, not just on a NC/RC server, pretty much along the lines of d= raft-
lengyel-netmod-yang-instance-data.

Lada

>

Andy

=C2= =A0
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--00000000000080cdf4056ad693ff-- From nobody Fri Apr 27 09:28:55 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8C1126B7E for ; Fri, 27 Apr 2018 09:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOckv4JgOaJJ for ; Fri, 27 Apr 2018 09:28:51 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96538126D3F for ; Fri, 27 Apr 2018 09:28:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 64C5B6B1; Fri, 27 Apr 2018 18:28:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 2AT2gzhl0g8p; Fri, 27 Apr 2018 18:28:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 27 Apr 2018 18:28:50 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16F7820035; Fri, 27 Apr 2018 18:28:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id i8Q--KflKEEU; Fri, 27 Apr 2018 18:28:49 +0200 (CEST) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB90520031; Fri, 27 Apr 2018 18:28:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BC40442C56E2; Fri, 27 Apr 2018 18:28:49 +0200 (CEST) Date: Fri, 27 Apr 2018 18:28:49 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: netmod@ietf.org Message-ID: <20180427162849.73ytpehhtfl3xpda@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <20180427144708.6ekknrajexvz5yvf@elstar.local> <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 16:28:54 -0000 On Fri, Apr 27, 2018 at 05:13:20PM +0200, Ladislav Lhotka wrote: > On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote: > > On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote: > > > > > [...] define a special datastore for it, such as "error-messages". > > > > This seems worse than using, well, RFC 8040 yang-data. The proper > > Why it seems worse? Unnecessary complexity. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 27 12:12:28 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39D012778D; Fri, 27 Apr 2018 12:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pOmC7Wt2t88; Fri, 27 Apr 2018 12:12:25 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3960126D85; Fri, 27 Apr 2018 12:12:24 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id j11so2126311pff.10; Fri, 27 Apr 2018 12:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JOMqtNiM/62uSL2pHg/TVlR8N4+iLOAcTnuzpXgYv5k=; b=eMtqGKBBQgyL+GhnbAQuGCG/1E7YjueUtyhi4dTmZs+ss93qO25rYlLQFE8Kl08D6I 9C1Ur7uQKJ+Z5NUSPnW2+2gH/wxwG0a3ybEMBt/y389V7hQ/E3G7/ldvhRuFT+4VQKnh 2aUg3H2nSBGDi4TTQzhEsd1oRSSG+8B0MLVd/cUlbpjqwezUQStnJdrirfUsI9C+U9Nf W9+llaSsYI2CDhaNs5GNEjOjauHw+C4riQaZtOUaDvFahRM6D5gO1F0+2NOS6WAs3E3/ mMdYVk9qjcB7OK/j9OpuTGinjOwU5m1NteDJnuLZtCr2w9J2bA99cM5uDKvV84ywhBYB g7aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JOMqtNiM/62uSL2pHg/TVlR8N4+iLOAcTnuzpXgYv5k=; b=HwenuN9KN8Z9x+ehviyAWRWhuYzpMqHrcxBEx0AS2CCASAJoK6U83e9Ybri6gPvizX 7qm6TBF55Ex9uYD2PDTXfsoF7UPFXYB142EJW+/67CAbt6rxurgxEhoLqw5fx9YdE10J dg7pQpbrkH//CxctlYk7fFgbUTRpQTd4Mx7i7aLyeBN74QnEoWAUiCFdodKiWstqyoGi 9H2w2TNDUmKR9YmtmV5TRe9gXB4TTGPYdTNsuYNC3kcKWVucyD0pv+ivnfAaO8DBQw5H n/r3EhlnUujpgvSf7IvKM0a7HNKlrCtJa6tAflTYHtFh9Fcckhvas2++wcmlo10owdPv ISeg== X-Gm-Message-State: ALQs6tDGpv+H6wxDKy5eN1A+kOPPRwafrrG1X8iwPjvec/pv3YXFrWKF 8T3S2LtkL66MiEEbnNbcxRH8KTn6 X-Google-Smtp-Source: AB8JxZpYoHfPu9VaNvMh9BVwrXu0zycyb1M3TMyEoewKTLLf2N4exa0UkOH/emMW6kO4hHm6Hes/eA== X-Received: by 2002:a17:902:5481:: with SMTP id e1-v6mr3268591pli.137.1524856344560; Fri, 27 Apr 2018 12:12:24 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:c404:7136:37e6:4e4a? ([2601:647:4700:1280:c404:7136:37e6:4e4a]) by smtp.gmail.com with ESMTPSA id v15sm4100832pfa.116.2018.04.27.12.12.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Apr 2018 12:12:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Mahesh Jethanandani In-Reply-To: <528EB5B2-E031-49FB-8348-B27C0FA6B718@juniper.net> Date: Fri, 27 Apr 2018 12:12:22 -0700 Cc: "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <528EB5B2-E031-49FB-8348-B27C0FA6B718@juniper.net> To: Kent Watsen X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [netmod] ACL (-18) issues found during shepherd write-up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 19:12:27 -0000 Kent, > On Apr 25, 2018, at 6:18 PM, Kent Watsen wrote: >=20 > Authors, >=20 > Just a few minor things found while going through the shepherd = checklist. These won't block the write-up, but should be fixed before we = submit for publication. For now, the write-up will explain that these = will be fixed, and I'll clear these comments as soon as an update is = posted: >=20 > 1) Obsolete normative reference: RFC 6536 should be RFC 8341 Updated. >=20 > 2) Outdated reference: draft-ietf-netmod-rfc7223bis has been published > as RFC 8343 Updated. >=20 > 3) Outdated reference: draft-ietf-netmod-yang-tree-diagrams has been=20= > published as RFC 8340 Updated. >=20 > 4) some artwork has the comment "[note: '\' line wrapping for = formatting > only]" even when there are no folded lines in the artwork. [hint,=20= > only use the "," version of the INSERT macro for artwork = that > you know contains a long line, or fix the macro to be smart enough = to > only insert the header when needed] Removed the note. >=20 > 5) it is good to see that now the 'reference' statements now follow = the > "number: title" convention, but many of the "titles" are not the=20 > actual title of the referenced draft, as they should be. The titles use well known acronyms like IPv6, TCP and ICMP. Anyway, I = have expanded it to the full title. >=20 > 6) The document has examples using IPv4 documentation addresses = according > to RFC6890, but does not use any IPv6 documentation addresses. = Maybe > there should be IPv6 examples, too? Added an IPv6 example. >=20 > 7) I question if all the normative references are really normative. = For > instance, RFCs 3688, 5246, 6020, 6241, 6242, 6536, 8040 stand out as > not needing to be normative. Moved them to informative section with 6535 updated to 8341. >=20 > 8) Section 2, 1st paragraph: s/YANG/YANG 1.1/? Done. >=20 >=20 >=20 > Thanks, > Kent >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Fri Apr 27 13:07:00 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 158B712E058; Fri, 27 Apr 2018 13:06:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152485961900.5909.4273132466548574395@ietfa.amsl.com> Date: Fri, 27 Apr 2018 13:06:59 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-19.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 20:06:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Network Access Control List (ACL) YANG Data Model Authors : Mahesh Jethanandani Lisa Huang Sonal Agarwal Dana Blair Filename : draft-ietf-netmod-acl-model-19.txt Pages : 59 Date : 2018-04-27 Abstract: This document defines a data model for Access Control List (ACL). An ACL is a user-ordered set of rules, used to configure the forwarding behavior in device. Each rule is used to find a match on a packet, and define actions that will be performed on the packet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-19 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 30 07:09:44 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D42D12DA54 for ; Mon, 30 Apr 2018 07:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgkHPtO4-dMV for ; Mon, 30 Apr 2018 07:09:41 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 12E1E12DA53 for ; Mon, 30 Apr 2018 07:09:40 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 0FC36182015B; Mon, 30 Apr 2018 16:14:44 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 08C5E1820157; Mon, 30 Apr 2018 16:14:41 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman Cc: Juergen Schoenwaelder , NetMod WG In-Reply-To: References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <20180427144708.6ekknrajexvz5yvf@elstar.local> <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> Mail-Followup-To: Andy Bierman , Juergen Schoenwaelder , NetMod WG Date: Mon, 30 Apr 2018 16:09:43 +0200 Message-ID: <87d0yglra0.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 14:09:44 -0000 Andy Bierman writes: > On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka wrote: > >> On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote: >> > On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote: >> > >> > > [...] define a special datastore for it, such as "error-messages". >> > >> > This seems worse than using, well, RFC 8040 yang-data. The proper >> >> Why it seems worse? >> >> > Because this is not part of the NMDA. NMDA is extensible. > IMO, the yang-data defined in RFC 8040 has a clear purpose, and it > is sufficient for that purpose, which is a YANG representation of > an instance document (such as a protocol message or file). The same is basically true even without the extension. For example, I fail to see any benefit from using yang-data in a module like ietf-zerotouch-information. > > YANG is useful for defining data structures that can be represented in > different formats, yet it is independent of any 1 format. Of course I see this potential. Unfortunately, YANG spec was explicitly written for a very specific context. Using an extension for removing this specificity is IMO an ugly hack that undermines the architecture. > > I am in favor if keeping the yang-data in RFC 8040 and not > creating a new version of it that is unconstrained. > There does not seem to be consensus on how to do this, > or even consensus that it is a good idea. > If the extension is deemed necessary, I would also prefer this approach to making the extension a Proposed Standard. Lada > > >> > clear solution for RPCs and actions would be to enable the definition >> > of error details right in the rpc/action definition (input, output, >> > error). >> >> Agreed. >> >> > >> > But something like yang-data seems to have uses in other contexts. >> >> So other datastores may be defined. I assume that YANG library data can be >> used >> independently, not just on a NC/RC server, pretty much along the lines of >> draft- >> lengyel-netmod-yang-instance-data. >> >> Lada >> >> > >> > > Andy > > > >> > /js >> > >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Apr 30 10:34:30 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8DE1201F8 for ; Mon, 30 Apr 2018 10:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jwggbS7Fw9k for ; Mon, 30 Apr 2018 10:34:26 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBEC31201F2 for ; Mon, 30 Apr 2018 10:34:26 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3UHTqs7008143; Mon, 30 Apr 2018 10:34:26 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=vyB2oHKHx1Aww6qc6HVcP3GZ6GV6HLZpicM+1wqFxl4=; b=EcDCe50K/s5CtN0CW+KI7Eo4Suy3OpffWzuZfpoBFAKJeUeM0X58/aiuSOIMFsCaT6GZ 179z0WKZRPOBuhKFDMUnH86Kq9Gputtjmhu9fT1m0txUVAFPo0VtaL716ViI1lVsDsGR lPeeI+D2Elnr3R1g9I5oPWP6X2OJ0ToCoK7sCkwI9e/+o+I6eW8yLGsFiXvqteq3hCp8 zNBAMfUOn6U75RmfIy05ljbocrReiebaVpwcdEvjc9rQOZReYmosrGgtyKrEQFSneZOJ g4MEvqbE5LGfEOFpOpQeUwb79uo8hFe7m5goZ83fV5Tk1ACu4ceGMFobt2QVY4d3oc3G vw== Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0016.outbound.protection.outlook.com [216.32.181.16]) by mx0a-00273201.pphosted.com with ESMTP id 2hp2p5gjbw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Apr 2018 10:34:26 -0700 Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4389.namprd05.prod.outlook.com (52.135.202.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.735.6; Mon, 30 Apr 2018 17:34:24 +0000 Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::44ac:d4a9:49d0:101e]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::44ac:d4a9:49d0:101e%13]) with mapi id 15.20.0715.014; Mon, 30 Apr 2018 17:34:24 +0000 From: Kent Watsen To: Martin Bjorklund CC: "andy@yumaworks.com" , "netmod@ietf.org" Thread-Topic: [netmod] yang-data-ext issues Thread-Index: AQHT1YJYRSnZmZlnhU6JIK4LoPfNTqQDdYgAgAAS9YCAAAZpAIAACwoAgAAFOICAAuemAIAAR8IAgAABIACAAAEwgIAHI10AgABILICAAAT7AIAAS8EAgABAMYCAAAJrgIAAAtqAgAGEfoD//9zuAIAA5miAgAhKboA= Date: Mon, 30 Apr 2018 17:34:23 +0000 Message-ID: References: <20180423.220815.526647366558506966.mbj@tail-f.com> <403C417C-4546-48FA-AEA5-6ABA3D5A3845@juniper.net> <20180425.085751.1552281751468645335.mbj@tail-f.com> In-Reply-To: <20180425.085751.1552281751468645335.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4389; 7:unOCWESquyjbMFZdVauFa8BHrFRDOU4J3Qrpcvp6lfEiqgFLsOAEQ6+/2E7oC8IzDio1ggh0d364Z4mKAtybb9i/9RK7awZTHFCeA+YBCzBLE9nO8LLO9XpM/FCU/G2tGICSXPHnymG4s2V37KmKpnPgGMAJVRIx9qeBVWlzvHTWG2WgxBpSMtjNE+4lrUZ77phJ/rUQtWIjkV4XJc8UKbrSMHND3Xx2PtNyyVZSvVw9ojFdIQMLBoso5Tv2zZY5 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4389; x-ms-traffictypediagnostic: BYAPR05MB4389: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:BYAPR05MB4389; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4389; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(396003)(366004)(346002)(376002)(199004)(189003)(66066001)(476003)(446003)(99286004)(11346002)(2616005)(83716003)(105586002)(486006)(26005)(5660300001)(82746002)(102836004)(2900100001)(305945005)(76176011)(86362001)(7736002)(81156014)(81166006)(8936002)(478600001)(6506007)(8676002)(97736004)(25786009)(3660700001)(93886005)(6246003)(186003)(229853002)(6916009)(6486002)(3280700002)(53936002)(6436002)(36756003)(3846002)(106356001)(5250100002)(33656002)(2906002)(316002)(6116002)(14454004)(58126008)(6512007)(4326008)(68736007)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4389; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: frcovb/jdbIe0izugXaGpfNRWbOI4f7gDEdm6magdrtkxvjkJv5i1+JgEezjezHp8hb0QYBDVkKs1+rRHOIcZZF8d8BqSCW4vG3lvFM97GzgsgY9ulyyuTBCsbTu6W4/R63+I/TNQIoc5BnKz6sc3gocB/NXWkykzUYlgQ/D2p2mQhvyBDFp42MWGcaaYjUV spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4EADEB335671904F9686A10B66BA13B3@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1b83b3ee-94a6-473f-8987-08d5aec09d6d X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 1b83b3ee-94a6-473f-8987-08d5aec09d6d X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2018 17:34:24.0479 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4389 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-30_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=990 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804300168 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 17:34:29 -0000 DQoNCj5NYXJ0aW4gd3JvdGUgYmVmb3JlOg0KPiBObyBJIHdhcyB0aGlua2luZyBhbG9uZyB0aGUg bGluZXMgb2Y6DQo+DQo+ICB5ZHg6eWFuZy1kYXRhIG15LWZpcnN0LXJwYy1lcnJvci1pbmZvIHsN Cj4gICAgLi4uDQo+ICB9DQo+DQo+ICBycGMgbXktZmlyc3QtcnBjIHsNCj4gICAgLi4uDQo+ICAg IG9weDplcnJvci1pbmZvLXN0cnVjdHVyZSBteS1maXJzdC1ycGMtZXJyb3ItaW5mbzsNCj4gIH0N Cj4NCj4gSS5lLiwgdXNlIHlhbmctZGF0YSB0byBkZWZpbmUgYSBzdHJ1Y3R1cmUsIGFuZCB1c2Ug YW5vdGhlciBzdGF0ZW1lbnQNCj4gdG8gdGllIHRoZW0gdG9nZXRoZXIuDQo+DQo+IElmIHdlIGRl ZmluZSBzcGVjaWFsIHN0YXRlbWVudHMgd2l0aCBpbmxpbmUgc3RydWN0dXJlcywgd2UgcHJvYmFi bHkNCj4gYWxzbyBuZWVkIHNwZWNpYWwgYXVnbWVudCBzdGF0ZW1lbnRzOyB3aXRoIHlvdXIgZXhh bXBsZToNCj4NCj4NCj4gIHJwYyBteS1maXJzdC1ycGMgew0KPiAgICAuLi4NCj4gICAgb3B4OmVy cm9yLWluZm8tc3RydWN0dXJlIG15LWZpcnN0LXJwYy1lcnJvci1pbmZvIHsNCj4gICAgICAuLi4N Cj4gICAgfQ0KPiAgfQ0KPg0KPg0KPiAgb3B4OmF1Z21lbnQtZXJyb3ItaW5mby1zdHJ1Y3R1cmUg Jy9tOm15LWZpcnN0LXJwYycNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArICcv bTpteS1maXJzdC1ycGMtZXJyb3ItaW5mbyB7DQo+ICAgIC4uLg0KPiAgfQ0KICANCg0KDQpDYW4g dGhlIGRlZmluaXRpb24gYmUgaW5saW5lZCwgbGlrZSB0aGlzPw0KDQogIG1vZHVsZSBteS1tb2R1 bGUgew0KICAgIC4uLg0KICAgIHJwYyBteS1maXJzdC1ycGMgew0KICAgICAgaW5wdXQgew0KICAg ICAgICAgLi4uDQogICAgICB9DQogICAgICBvdXRwdXQgew0KICAgICAgICAgLi4uDQogICAgICB9 DQogICAgICBvcHg6ZXJyb3ItaW5mby1zdHJ1Y3R1cmUgew0KICAgICAgICBsZWFmIGVycm9yLXR5 cGUgew0KICAgICAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAgICAgICAgICAgZW51bSBlcnJv ci1hOw0KICAgICAgICAgICAgZW51bSBlcnJvci1iOw0KICAgICAgICAgICAgZW51bSBlcnJvci1j Ow0KICAgICAgICAgIH0NCiAgICAgICAgfQ0KICAgICAgICBjaG9pY2UgZXJyb3ItaW5mbyB7DQog ICAgICAgICAgY2FzZSBlcnJvci1hIHsNCiAgICAgICAgICAgIC4uLg0KICAgICAgICAgIH0NCiAg ICAgICAgICBjYXNlIGVycm9yLWIgew0KICAgICAgICAgICAgLi4uDQogICAgICAgICAgfQ0KICAg ICAgICAgIGNhc2UgZXJyb3ItYyB7DQogICAgICAgICAgICAuLi4NCiAgICAgICAgICB9DQogICAg ICAgIH0gICAgIA0KICAgICAgfQ0KICAgIH0NCiAgfQ0KDQoNCg0KS2VudCAvLyBjb250cmlidXRv cg0KDQoNCg0K From nobody Mon Apr 30 10:48:40 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E316F124239 for ; Mon, 30 Apr 2018 10:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDp88uoYCEgQ for ; Mon, 30 Apr 2018 10:48:35 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA121201F2 for ; Mon, 30 Apr 2018 10:48:34 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id g12-v6so13256955lfb.10 for ; Mon, 30 Apr 2018 10:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Tjj2ykyBMWTTE8WJDEc3XDMbmxZFtvrAt3lDMK5R56w=; b=VvoLqP+ILHtskkZ7wi4HqZh8vCu163RuGKs73lShwTfri/gXlXxV9ElgXUuGrfZfp9 S7iw2YDWyXCzY8CpemLqgdjWDeqo7NJIKGmvX7thCIQwHh7Rp9d59R1sen80XuR65a7X 2Sbjs5FLSAFqyybkg/YppM4STasos1J75l86Gg0ZenpeDWPTHb6wJ/SihCU/s7lS+mVo 5kp+Z8O2sfAi0eNNu9kMdYRMHkETzLagHMbd0A+GdoAE51Hdd8L1m2TBqxCZ1cL/Ds4Q reUXCq+vKogvpfQf0Yar5629Uxe/ichbqRur4w2PQYInie7EhjHzAdhQEtIPaO3tzMKy Su/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Tjj2ykyBMWTTE8WJDEc3XDMbmxZFtvrAt3lDMK5R56w=; b=F5Cf+FzJk6CDgs/DhTllCqMCypcQ7eT/uEhSmauCFDhxQl1PuPxvDPhS/bpU/MpH0U JwsAsQLh0ZXcU+HY2Q/6O7YJ0dQCRaSDRGJXhy2/YZYi8ptHXxuibNxWeL0Kv0pzOP69 s1h8k0MWkrTrPSY7ZfpEmYzOzCe0o6cGYGPPK8F61z4rURDgkUwtGlqvONawv+T/EyMC O+KvfZp+6A71KuMkHob/4keu173yEFB7myQt1br+zuXe46M6xbo+emuYJbBjCZSFJKlU hHzzHR000NWUBZOlXYpUr6wu568mVh3XZd8ppolnA8NsJRBNED47CcxM3XK7kZZHOFT2 8llg== X-Gm-Message-State: ALQs6tB8wMy7ctdPswtW/BP6N3xC4vUnfr7Oy89bde+7f33SVr5Lplj+ HE6CFr+83el5L1rvZf2BBMmhAgYWPbZzVtcDvrTkLA== X-Google-Smtp-Source: AB8JxZq7qhsK+EKSduBA6a5tioxT9O4Hs8lcohLGeqsooOPp7VzlKoGRqGboOk4h0BrjQDGwu0vnSGW5LsGIpw8sEFs= X-Received: by 2002:a19:2092:: with SMTP id g140-v6mr8146505lfg.38.1525110512982; Mon, 30 Apr 2018 10:48:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 30 Apr 2018 10:48:31 -0700 (PDT) In-Reply-To: <87d0yglra0.fsf@nic.cz> References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <20180427144708.6ekknrajexvz5yvf@elstar.local> <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> <87d0yglra0.fsf@nic.cz> From: Andy Bierman Date: Mon, 30 Apr 2018 10:48:31 -0700 Message-ID: To: Andy Bierman , Juergen Schoenwaelder , NetMod WG Content-Type: multipart/alternative; boundary="0000000000005eb011056b1476d9" Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 17:48:38 -0000 --0000000000005eb011056b1476d9 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 30, 2018 at 7:09 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka wrote: > > > >> On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote: > >> > On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote: > >> > > >> > > [...] define a special datastore for it, such as "error-messages". > >> > > >> > This seems worse than using, well, RFC 8040 yang-data. The proper > >> > >> Why it seems worse? > >> > >> > > Because this is not part of the NMDA. > > NMDA is extensible. > If your only tool is a hammer, then all your problems look like nails. I fail to see how an "error-messages" datastore fits in with NMDA > > > IMO, the yang-data defined in RFC 8040 has a clear purpose, and it > > is sufficient for that purpose, which is a YANG representation of > > an instance document (such as a protocol message or file). > > The same is basically true even without the extension. For example, I > fail to see any benefit from using yang-data in a module like > ietf-zerotouch-information. > I don't see the benefit of pretending all data-def-stmts represent configuration or operational data. Wrapping the data-def-stmts in an extension says "this is not configuration or operational data". This is useful for tools that can process YANG in other contexts. > > > > YANG is useful for defining data structures that can be represented in > > different formats, yet it is independent of any 1 format. > > Of course I see this potential. Unfortunately, YANG spec was explicitly > written for a very specific context. Using an extension for removing > this specificity is IMO an ugly hack that undermines the architecture. > > I don't see the architecture as fragile or damaged if yang-data is used. People are going to continue to push the boundaries of YANG capabilities. This will happen with or without the IETF. Maybe this work should remain proprietary or get moved to an opensource project. > > > > I am in favor if keeping the yang-data in RFC 8040 and not > > creating a new version of it that is unconstrained. > > There does not seem to be consensus on how to do this, > > or even consensus that it is a good idea. > > > > If the extension is deemed necessary, I would also prefer this approach > to making the extension a Proposed Standard. > > Lada > Andy > > > > > > >> > clear solution for RPCs and actions would be to enable the definition > >> > of error details right in the rpc/action definition (input, output, > >> > error). > >> > >> Agreed. > >> > >> > > >> > But something like yang-data seems to have uses in other contexts. > >> > >> So other datastores may be defined. I assume that YANG library data can > be > >> used > >> independently, not just on a NC/RC server, pretty much along the lines > of > >> draft- > >> lengyel-netmod-yang-instance-data. > >> > >> Lada > >> > >> > > >> > > > > Andy > > > > > > > >> > /js > >> > > >> -- > >> Ladislav Lhotka > >> Head, CZ.NIC Labs > >> PGP Key ID: 0xB8F92B08A9F76C67 > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > --0000000000005eb011056b1476d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 30, 2018 at 7:09 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writ= es:

> On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote: >> > On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wro= te:
>> >
>> > > [...] define a special datastore for it, such as "e= rror-messages".
>> >
>> > This seems worse than using, well, RFC 8040 yang-data. The pr= oper
>>
>> Why it seems worse?
>>
>>
> Because this is not part of the NMDA.

NMDA is extensible.


If y= our only tool is a hammer, then all your problems look like nails.
I fail to see how an "error-messages" datastore fits in with NM= DA

=C2=A0

> IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
> is sufficient for that purpose, which is a YANG representation of
> an instance document (such as a protocol message or file).

The same is basically true even without the extension. For example, I
fail to see any benefit from using yang-data in a module like
ietf-zerotouch-information.

=C2=A0
I don't see the benefit of pretending all data-def-stmts represen= t
configuration or operational data.

Wra= pping the data-def-stmts in an extension says "this is not configurati= on
or operational data".=C2=A0 This is useful for tools that= can process YANG in
other contexts.


>
> YANG is useful for defining data structures that can be represented in=
> different formats, yet it is independent of any 1 format.

Of course I see this potential. Unfortunately, YANG spec was explicitly
written for a very specific context. Using an extension for removing
this specificity is IMO an ugly hack that undermines the architecture.



I don't see the arc= hitecture as fragile or damaged if yang-data is used.

<= div>People are going to continue to push the boundaries of YANG capabilitie= s.
This will happen with or without the IETF. Maybe this work sho= uld remain
proprietary or get moved to an opensource project.


=C2=A0
>
> I am in favor if keeping the yang-data in RFC 8040 and not
> creating a new version of it that is unconstrained.
> There does not seem to be consensus on how to do this,
> or even consensus that it is a good idea.
>

If the extension is deemed necessary, I would also prefer this approach
to making the extension a Proposed Standard.

Lada


Andy
=C2= =A0

>
>
>> > clear solution for RPCs and actions would be to enable the de= finition
>> > of error details right in the rpc/action definition (input, o= utput,
>> > error).
>>
>> Agreed.
>>
>> >
>> > But something like yang-data seems to have uses in other cont= exts.
>>
>> So other datastores may be defined. I assume that YANG library dat= a can be
>> used
>> independently, not just on a NC/RC server, pretty much along the l= ines of
>> draft-
>> lengyel-netmod-yang-instance-data.
>>
>> Lada
>>
>> >
>>
>
> Andy
>
>
>
>> > /js
>> >
>>= ; --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/netm= od
>>

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

--0000000000005eb011056b1476d9-- From nobody Mon Apr 30 10:57:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7F2124239 for ; Mon, 30 Apr 2018 10:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Lv-MBFJaerE for ; Mon, 30 Apr 2018 10:57:38 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2851201F2 for ; Mon, 30 Apr 2018 10:57:38 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3UHsdmW014031; Mon, 30 Apr 2018 10:57:37 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=KhyF6yTlD9Xd96gRmEspRvtyrUbQCQJoEUvPlQTr264=; b=jof5ID2BDg02hLfz/ZNyVNhTyepxbatozlZIWb9aV18GyxgF6w66Llx0XAj5oKYm8DFA x0vdYxlkCGGHWIT87922U/HvGfSLEWdmnIXTE46127EmmI5Ko/PLs4xs05Q1bkvN+d9x 46HeufT0tGUpepc9et5Z6UiCdMOuDL3oBMbCr7hHzoQVf/dJoBVZk90EIaxjRWOn3Kb+ loHvk2gG7dcQ7RrQ9dG4yJecrA4imflG16BpyEVz4anmpj49ZttdGSUW/IFwuDkQ8x7n 21Gb2pm4tOjtCDRvPDOSeNUCIAUaRktB6Em9NkLxMXB7DzKz1M/EPVGvtk4mk4lTycBh Bw== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0183.outbound.protection.outlook.com [216.32.181.183]) by mx0b-00273201.pphosted.com with ESMTP id 2hp293rp7c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Apr 2018 10:57:37 -0700 Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4152.namprd05.prod.outlook.com (52.135.199.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.715.11; Mon, 30 Apr 2018 17:57:34 +0000 Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::44ac:d4a9:49d0:101e]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::44ac:d4a9:49d0:101e%13]) with mapi id 15.20.0715.014; Mon, 30 Apr 2018 17:57:34 +0000 From: Kent Watsen To: Ladislav Lhotka , Andy Bierman CC: NetMod WG Thread-Topic: [netmod] yang-data-ext issues Thread-Index: AQHT1YJYRSnZmZlnhU6JIK4LoPfNTqQEcM6AgAYAzwCAAlYhgIAB08UAgAAyUgCAATikgIAAAaSAgAGHGgCAAAK9AIAAEH6AgAACpYCAAPWtAIABPh0AgACT0YCAAAY/gIAABasAgAALQACAAARkgIAANngAgAADfgCAAAdSAIAADKEAgASYmID///yYAA== Date: Mon, 30 Apr 2018 17:57:34 +0000 Message-ID: References: <87muxq1pk9.fsf@nic.cz> <065a363753a67ee12f8bde6224009207b5fe7ee7.camel@nic.cz> <20180427.120325.419501937185262392.mbj@tail-f.com> <11da9315-40d9-60cd-d32f-b0ac4a5640c4@cisco.com> <45f5a97d205a9251b382687f54865c62250787cb.camel@nic.cz> <99aac5c0-aa2f-1a35-8a5c-ad97635e5a40@cisco.com> <20180427144708.6ekknrajexvz5yvf@elstar.local> <4305e62a9d301da22f89a0dd9a34c9c4882735af.camel@nic.cz> <87d0yglra0.fsf@nic.cz> In-Reply-To: <87d0yglra0.fsf@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4152; 7:A6y4yqJ7dlIR0gfXyNi2FuD8jvl5/CsTU5Jhi0ST2pBYk8K1TWFIFwwYRlo/a9wPasdybK8SvjQVJ/VJZaot3LgJ9W9rrNCzCr9H1+sk2ikOHfWoIhIUhUmJkHdB2A8EkhXvThqKrx7mw1ZtL7ZDXAmtWR0A68hKhOdzVQ+bhn+SmvEruxCe7VE4CAThWs6aiczf2jAiWGtI2TjpBl24yNRgYJUXytqaxA0QGfXo7wOju/NefDV04D40heEUGDCS x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4152; x-ms-traffictypediagnostic: BYAPR05MB4152: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:BYAPR05MB4152; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4152; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(396003)(39860400002)(39380400002)(199004)(189003)(99286004)(110136005)(93886005)(305945005)(478600001)(2906002)(316002)(5660300001)(6486002)(14454004)(102836004)(3660700001)(6506007)(6346003)(486006)(2900100001)(186003)(68736007)(476003)(446003)(6246003)(86362001)(11346002)(2616005)(26005)(3280700002)(4326008)(58126008)(25786009)(83716003)(82746002)(97736004)(33656002)(36756003)(8936002)(229853002)(66066001)(81156014)(7736002)(5250100002)(6436002)(76176011)(6116002)(6512007)(59450400001)(53936002)(105586002)(3846002)(106356001)(8676002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4152; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: JrBPpTD1TaBh9Jx5X2ss5kD8Gnl4qoydsduTZ6EHzvKdqEPkYeHY4N5t/FHBbwgqfZ7rJc9BT5gOzsOlUXFTU70s0SAYisZBiC8gVhkIjox3ke1iKT+6lUmDhgZcPWKDqGqTYd0i6zDu7UWCBBE0uLlTdlW1s3dwjvS73+PBz3NsDV9ixmq731m6oWhyq6g7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <18A0BA17EBD49344A1CB00E1301D5C36@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 90db90e5-e8cf-47e7-5ccb-08d5aec3da17 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 90db90e5-e8cf-47e7-5ccb-08d5aec3da17 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2018 17:57:34.2312 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4152 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-30_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804300173 Archived-At: Subject: Re: [netmod] yang-data-ext issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 17:57:40 -0000 DQpMYWRhIHdyaXRlczoNCj4gQW5keSB3cml0ZXM6DQo+PklNTywgdGhlIHlhbmctZGF0YSBkZWZp bmVkIGluIFJGQyA4MDQwIGhhcyBhIGNsZWFyIHB1cnBvc2UsIGFuZCBpdA0KPj5pcyBzdWZmaWNp ZW50IGZvciB0aGF0IHB1cnBvc2UsIHdoaWNoIGlzIGEgWUFORyByZXByZXNlbnRhdGlvbiBvZg0K Pj5hbiBpbnN0YW5jZSBkb2N1bWVudCAoc3VjaCBhcyBhIHByb3RvY29sIG1lc3NhZ2Ugb3IgZmls ZSkuDQo+DQo+IFRoZSBzYW1lIGlzIGJhc2ljYWxseSB0cnVlIGV2ZW4gd2l0aG91dCB0aGUgZXh0 ZW5zaW9uLiBGb3IgZXhhbXBsZSwgSQ0KPiBmYWlsIHRvIHNlZSBhbnkgYmVuZWZpdCBmcm9tIHVz aW5nIHlhbmctZGF0YSBpbiBhIG1vZHVsZSBsaWtlDQo+IGlldGYtemVyb3RvdWNoLWluZm9ybWF0 aW9uLg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgdGhpcywgaG93IGVsc2Ugd291bGQgeW91IHByb3Bv c2UgdG8gZGVmaW5lIHRoZQ0KSlNPTi1vci1YTUwgZW5jb2RlZCBwYXlsb2FkIG9mIHRoZSBDTVMg c3RydWN0dXJlPw0KDQoNCj4+IEkgYW0gaW4gZmF2b3IgaWYga2VlcGluZyB0aGUgeWFuZy1kYXRh IGluIFJGQyA4MDQwIGFuZCBub3QNCj4+IGNyZWF0aW5nIGEgbmV3IHZlcnNpb24gb2YgaXQgdGhh dCBpcyB1bmNvbnN0cmFpbmVkLg0KPj4gVGhlcmUgZG9lcyBub3Qgc2VlbSB0byBiZSBjb25zZW5z dXMgb24gaG93IHRvIGRvIHRoaXMsDQo+PiBvciBldmVuIGNvbnNlbnN1cyB0aGF0IGl0IGlzIGEg Z29vZCBpZGVhLg0KPg0KPiBJZiB0aGUgZXh0ZW5zaW9uIGlzIGRlZW1lZCBuZWNlc3NhcnksIEkg d291bGQgYWxzbyBwcmVmZXIgdGhpcyANCj4gYXBwcm9hY2ggdG8gbWFraW5nIHRoZSBleHRlbnNp b24gYSBQcm9wb3NlZCBTdGFuZGFyZC4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHRhbGsgYWJvdXQg YWJhbmRvbmluZyB0aGlzIGRyYWZ0LiAgVGhlcmUgaXMgbm8gcXVlc3Rpb24NCnRoYXQgaXQgaXMg bmVlZGVkIChlLmcuLCBhbmltYSB2b3VjaCwgemVyb3RvdWNoLCB0YWlsLWYncyAic3RydWN0dXJl IiksDQphbmQgUkZDIDgwNDAgaXMgdW5zYXRpc2ZhY3RvcnkgYmVjYXVzZSAxKSBpdCBkb2Vzbid0 IGFsbG93IGEgdG9wLWxldmVsDQonY2hvaWNlJyBiZXR3ZWVuIHR3byBjb250YWluZXJzIGFuZCAy KSBpdCByZXF1aXJlcyBkcmFmdHMgdG8gcmVmZXJlbmNlIA0KUkZDIDgwNDAsIGV2ZW4gdGhvdWdo IHRoZSBkcmFmdHMgbWF5IGhhdmUgbm90aGluZyB0byBkbyB3aXRoIFJFU1RDT05GLg0KDQpTdXJl LCBtYXliZSB3ZSBoYXZlIGNvbnZpbmNlZCBvdXJzZWx2ZXMgdGhhdCB5YW5nLWRhdGEgaXMgbm90 IG5lZWRlZA0KdG8gbW9kZWwgZXJyb3ItaW5mbywgYnV0IHRoYXQgZG9lc24ndCBuZWdhdGUgdGhl IG90aGVyIHVzZSBjYXNlLg0KDQpXZSBuZWVkIGEgd2F5IHRvIGluZGljYXRlIHRoYXQgc29tZSBk YXRhLW1vZGVsIHJlcHJlc2VudHMgYSBzdGFuZC1hbG9uZQ0KZGF0YSBzdHJ1Y3R1cmUuICBJdCBp cyBub3QgY29uZmlndXJhdGlvbiwgb3BlcmF0aW9uYWwgc3RhdGUsIGFuIFJQQywgb3INCmEgbm90 aWZpY2F0aW9uLiAgSXQgY2FuIG9ubHkgYXBwZWFyIGFzIGEgZGVzY2VuZGVudCBvZiB0aGUgJ21v ZHVsZScNCnN0YXRlbWVudC4gIEFsbCAnYWN0aW9uJywgJ25vdGlmaWNhdGlvbicsICdjb25maWcn LCBhbmQgJ2lmLWZlYXR1cmUnDQpkZXNjZW5kZW50IHN0YXRlbWVudHMgYXJlIGlnbm9yZWQuICBG b3IgdGhlIHB1cnBvc2Ugb2YgJ211c3QnIGFuZCAnDQp3aGVuJyBzdGF0ZW1lbnRzLCB0aGUgeWFu Zy1kYXRhIHN0cnVjdHVyZSBpcyBpdHMgb3duIGNvbnRleHQgcm9vdC4gIEl0DQpoYXMgYSBuYW1l c3BhY2UgYW5kIGEgdW5pcXVlIGxvY2FsIG5hbWUgKHVuaXF1ZSBvbmx5IHRvIG90aGVyIHlhbmct ZGF0YQ0KZGVmaW5lZCB3aXRoaW4gdGhlIHNhbWUgbW9kdWxlOyBpdCdzIG9rYXkgaWYgYW4gUlBD LCBub3RpZmljYXRpb24sIG9yDQp0b3AtbGV2ZWwgZGF0YSBub2RlIGhhcyB0aGUgc2FtZSBuYW1l KS4gIEFueXRoaW5nIGVsc2U/DQoNCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoNCg0K