From nobody Wed Jan 2 05:59:02 2019 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 82CDE127AC2 for ; Wed, 2 Jan 2019 05:59:01 -0800 (PST) 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 h-YrOawFBl_C for ; Wed, 2 Jan 2019 05:58:59 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5135C126CC7 for ; Wed, 2 Jan 2019 05:58:59 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id EA5851820191; Wed, 2 Jan 2019 15:06:30 +0100 (CET) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 24F5A182018D; Wed, 2 Jan 2019 15:06:28 +0100 (CET) From: Ladislav Lhotka To: Rohit R Ranade , "netmod\@ietf.org" In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BCB50C7@dggeml530-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6BCB50C7@dggeml530-mbs.china.huawei.com> Mail-Followup-To: Rohit R Ranade , "netmod\@ietf.org" Date: Wed, 02 Jan 2019 14:58:54 +0100 Message-ID: <878t03duu9.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Schema Mount with Inline Type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2019 13:59:02 -0000 Hi Rohit, Rohit R Ranade writes: > Hi All, > > module: ietf-yang-schema-mount > +--ro schema-mounts > +--ro namespace* [prefix] > | +--ro prefix yang:yang-identifier > | +--ro uri? inet:uri > +--ro mount-point* [module label] > +--ro module yang:yang-identifier > +--ro label yang:yang-identifier > +--ro config? boolean > +--ro (schema-ref) > +--:(inline) > | +--ro inline! > +--:(shared-schema) > +--ro shared-schema! > +--ro parent-reference* yang:xpath1.0 > > Any reason for not adding "parent-reference" for "inline" type ? What > is the solution for the modules defined under such mount points to > refer to parent schema ? The inline case was intentionally designed with an impenetrable "mount jail". Do you see any use case where parent references are needed and the "shared-schema" strategy cannot be used? Lada > > With Regards, > Rohit > _______________________________________________ > 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 Jan 2 07:29:20 2019 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 77D4D128B01; Wed, 2 Jan 2019 07:29:17 -0800 (PST) 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.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154644295748.32551.5073017408727781318.idtracker@ietfa.amsl.com> Date: Wed, 02 Jan 2019 07:29:17 -0800 Archived-At: Subject: [netmod] netmod - New Meeting Session Request for IETF 104 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2019 15:29:17 -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): 2 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 Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jan 2 21:05:30 2019 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 732171310DD for ; Wed, 2 Jan 2019 21:05:29 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 gcrQcrzI80EW for ; Wed, 2 Jan 2019 21:05:28 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 CC4121310D1 for ; Wed, 2 Jan 2019 21:05:27 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id BB863E1820AFB; Thu, 3 Jan 2019 05:05:22 +0000 (GMT) Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 3 Jan 2019 05:05:24 +0000 Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0415.000; Thu, 3 Jan 2019 13:05:13 +0800 From: Rohit R Ranade To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] Schema Mount with Inline Type Thread-Index: AdSY8QlqYjMVcg7lQlazR9ZWHav3JQJbzSAAAC8C7KA= Date: Thu, 3 Jan 2019 05:05:13 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCBEF10@dggeml530-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6BCB50C7@dggeml530-mbs.china.huawei.com> <878t03duu9.fsf@nic.cz> In-Reply-To: <878t03duu9.fsf@nic.cz> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Schema Mount with Inline Type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 05:05:29 -0000 Hi, I donot have a specific scenario as of now. But the scenario used in the dr= aft is that a module which is mounted needs to refer to its parent-schema. = I donot see how that is related to "mount point instances having shared-sch= ema or different schema".=20 If we look at the LNE draft, I think it avoids the "parent-reference" by ha= ving a " bind-lne-name" which binds the interface to the LNE and also creat= es a "system" configuration for that interface inside the LNE instance. So = the interface references inside the mount jail get resolved. So in future, if "inlined" schema needs to use parent-schema, it needs to u= se a "bind" mechanism to add entries from the module in parent-schema to th= e same module under mount-point ? -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: 02 January 2019 19:29 To: Rohit R Ranade ; netmod@ietf.org Subject: Re: [netmod] Schema Mount with Inline Type Hi Rohit, Rohit R Ranade writes: > Hi All, > > module: ietf-yang-schema-mount > +--ro schema-mounts > +--ro namespace* [prefix] > | +--ro prefix yang:yang-identifier > | +--ro uri? inet:uri > +--ro mount-point* [module label] > +--ro module yang:yang-identifier > +--ro label yang:yang-identifier > +--ro config? boolean > +--ro (schema-ref) > +--:(inline) > | +--ro inline! > +--:(shared-schema) > +--ro shared-schema! > +--ro parent-reference* yang:xpath1.0 > > Any reason for not adding "parent-reference" for "inline" type ? What=20 > is the solution for the modules defined under such mount points to=20 > refer to parent schema ? The inline case was intentionally designed with an impenetrable "mount jail= ". Do you see any use case where parent references are needed and the "shar= ed-schema" strategy cannot be used? Lada > > With Regards, > Rohit > _______________________________________________ > 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 Jan 4 04:51:44 2019 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 6F22B12875B for ; Fri, 4 Jan 2019 04:51:43 -0800 (PST) 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 P73zTTapXW8K for ; Fri, 4 Jan 2019 04:51:40 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E23861277BB for ; Fri, 4 Jan 2019 04:51:39 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id 3A4F21820191; Fri, 4 Jan 2019 13:51:34 +0100 (CET) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 4A376182015B; Fri, 4 Jan 2019 13:51:31 +0100 (CET) From: Ladislav Lhotka To: Rohit R Ranade , "netmod\@ietf.org" In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BCBEF10@dggeml530-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6BCB50C7@dggeml530-mbs.china.huawei.com> <878t03duu9.fsf@nic.cz> <991B70D8B4112A4699D5C00DDBBF878A6BCBEF10@dggeml530-mbs.china.huawei.com> Mail-Followup-To: Rohit R Ranade , "netmod\@ietf.org" Date: Fri, 04 Jan 2019 13:51:34 +0100 Message-ID: <8736q8io15.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Schema Mount with Inline Type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 12:51:43 -0000 Rohit R Ranade writes: > Hi, > > I donot have a specific scenario as of now. But the scenario used in the draft is that a module which is mounted needs to refer to its parent-schema. I donot see how that is related to "mount point instances having shared-schema or different schema". > > If we look at the LNE draft, I think it avoids the "parent-reference" > by having a " bind-lne-name" which binds the interface to the LNE and > also creates a "system" configuration for that interface inside the > LNE instance. So the interface references inside the mount jail get > resolved. If I understand it correctly (maybe not), the "bind-lne-name" is used at the level of Network Device to assign an interface to a configured LNE. This information IMO is not meaningful inside the LNE itself. If it is so, there is in fact no parent reference. > > So in future, if "inlined" schema needs to use parent-schema, it needs > to use a "bind" mechanism to add entries from the module in > parent-schema to the same module under mount-point ? In my view, the inline case makes only sense in the split management scenario where each mount jail is managed via a separate NC/RC server. In this case it makes no sense to refer to data outside the mount jail. My standard complaint is that schema mount mixes up two rather different concepts: the shared-schema case is a data modelling concept whereas the inline case is more about combining instance data. This causes a lot of complexity and confusion. Lada > > > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: 02 January 2019 19:29 > To: Rohit R Ranade ; netmod@ietf.org > Subject: Re: [netmod] Schema Mount with Inline Type > > Hi Rohit, > > Rohit R Ranade writes: > >> Hi All, >> >> module: ietf-yang-schema-mount >> +--ro schema-mounts >> +--ro namespace* [prefix] >> | +--ro prefix yang:yang-identifier >> | +--ro uri? inet:uri >> +--ro mount-point* [module label] >> +--ro module yang:yang-identifier >> +--ro label yang:yang-identifier >> +--ro config? boolean >> +--ro (schema-ref) >> +--:(inline) >> | +--ro inline! >> +--:(shared-schema) >> +--ro shared-schema! >> +--ro parent-reference* yang:xpath1.0 >> >> Any reason for not adding "parent-reference" for "inline" type ? What >> is the solution for the modules defined under such mount points to >> refer to parent schema ? > > The inline case was intentionally designed with an impenetrable "mount jail". Do you see any use case where parent references are needed and the "shared-schema" strategy cannot be used? > > Lada > >> >> With Regards, >> Rohit >> _______________________________________________ >> 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 Sun Jan 6 18:04:12 2019 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 BDF61130E68 for ; Sun, 6 Jan 2019 18:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 61CXfOnoO-TX for ; Sun, 6 Jan 2019 18:04:08 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A88ED12872C for ; Sun, 6 Jan 2019 18:04:08 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 64B8E58A473AA8AD0329; Mon, 7 Jan 2019 02:04:06 +0000 (GMT) Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 7 Jan 2019 02:04:06 +0000 Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 7 Jan 2019 02:04:05 +0000 Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Mon, 7 Jan 2019 02:04:04 +0000 Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0415.000; Mon, 7 Jan 2019 10:03:57 +0800 From: Rohit R Ranade To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] Schema Mount with Inline Type Thread-Index: AdSY8QlqYjMVcg7lQlazR9ZWHav3JQJbzSAAAC8C7KAAMzhHAACQ9MyQ Date: Mon, 7 Jan 2019 02:03:56 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCC1258@dggeml530-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6BCB50C7@dggeml530-mbs.china.huawei.com> <878t03duu9.fsf@nic.cz> <991B70D8B4112A4699D5C00DDBBF878A6BCBEF10@dggeml530-mbs.china.huawei.com> <8736q8io15.fsf@nic.cz> In-Reply-To: <8736q8io15.fsf@nic.cz> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Schema Mount with Inline Type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 02:04:11 -0000 -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: 04 January 2019 18:22 To: Rohit R Ranade ; netmod@ietf.org Subject: RE: [netmod] Schema Mount with Inline Type Rohit R Ranade writes: > Hi, > > I donot have a specific scenario as of now. But the scenario used in the = draft is that a module which is mounted needs to refer to its parent-schema= . I donot see how that is related to "mount point instances having shared-s= chema or different schema".=20 > > If we look at the LNE draft, I think it avoids the "parent-reference" > by having a " bind-lne-name" which binds the interface to the LNE and=20 > also creates a "system" configuration for that interface inside the=20 > LNE instance. So the interface references inside the mount jail get=20 > resolved. If I understand it correctly (maybe not), the "bind-lne-name" is used at th= e level of Network Device to assign an interface to a configured LNE. This = information IMO is not meaningful inside the LNE itself. If it is so, there= is in fact no parent reference. > > So in future, if "inlined" schema needs to use parent-schema, it needs=20 > to use a "bind" mechanism to add entries from the module in=20 > parent-schema to the same module under mount-point ? In my view, the inline case makes only sense in the split management scenar= io where each mount jail is managed via a separate NC/RC server. In this ca= se it makes no sense to refer to data outside the mount jail. My standard complaint is that schema mount mixes up two rather different concepts: the shared-schema case is a data modelling concept whereas the in= line case is more about combining instance data. This causes a lot of compl= exity and confusion. [Rohit R Ranade] +1 =20 Lada > > > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: 02 January 2019 19:29 > To: Rohit R Ranade ; netmod@ietf.org > Subject: Re: [netmod] Schema Mount with Inline Type > > Hi Rohit, > > Rohit R Ranade writes: > >> Hi All, >> >> module: ietf-yang-schema-mount >> +--ro schema-mounts >> +--ro namespace* [prefix] >> | +--ro prefix yang:yang-identifier >> | +--ro uri? inet:uri >> +--ro mount-point* [module label] >> +--ro module yang:yang-identifier >> +--ro label yang:yang-identifier >> +--ro config? boolean >> +--ro (schema-ref) >> +--:(inline) >> | +--ro inline! >> +--:(shared-schema) >> +--ro shared-schema! >> +--ro parent-reference* yang:xpath1.0 >> >> Any reason for not adding "parent-reference" for "inline" type ? What=20 >> is the solution for the modules defined under such mount points to=20 >> refer to parent schema ? > > The inline case was intentionally designed with an impenetrable "mount ja= il". Do you see any use case where parent references are needed and the "sh= ared-schema" strategy cannot be used? > > Lada > >> >> With Regards, >> Rohit >> _______________________________________________ >> 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 Sun Jan 13 21:34:58 2019 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 CF88C130F4F for ; Sun, 13 Jan 2019 21:34:56 -0800 (PST) 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 ITV6c99E3YE7 for ; Sun, 13 Jan 2019 21:34:55 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2ACCA12008A for ; Sun, 13 Jan 2019 21:34:55 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 5E5B76ED4FA76D27A925; Mon, 14 Jan 2019 05:34:52 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 14 Jan 2019 05:34:51 +0000 Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0415.000; Mon, 14 Jan 2019 13:34:39 +0800 From: Rohit R Ranade To: Martin Bjorklund , Ladislav Lhotka CC: "netmod@ietf.org" Thread-Topic: Schema Mount Yang Library Update Thread-Index: AdSeYUFYxAmOUSMrRlSaqc+d9z9IXANaVz1A Date: Mon, 14 Jan 2019 05:34:39 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCC5C7C@dggeml530-mbs.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_991B70D8B4112A4699D5C00DDBBF878A6BCC5C7Cdggeml530mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] FW: Schema Mount Yang Library Update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 05:34:57 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A6BCC5C7Cdggeml530mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, Any suggestions regarding the question in the below mail ? With Regards, Rohit From: Rohit R Ranade Sent: 28 December 2018 09:37 To: netmod@ietf.org Subject: Schema Mount Yang Library Update Hi All, For the shared-schema type, the draft mentions "all instances of the same m= ount point MUST have the same YANG library content identifier". I think to achieve above condition, most vendors will plan to have only one= YANG library instance for that mount-point. If use multiple instances for Yang library, it is possible that the algorit= hm may generate a new content identifier for same data as per below stateme= nt in Yang library 1.1 draft: "There is no requirement that the same information always results in the sa= me "content-id" value." If use single instance of Yang library, when a YANG library update happens,= for which mount-point instance should a YANG library update notification b= e sent ? What is the guideline for the implementers of this draft regarding this poi= nt? With Regards, Rohit --_000_991B70D8B4112A4699D5C00DDBBF878A6BCC5C7Cdggeml530mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Auth= ors,

&n= bsp;

Any sug= gestions regarding the question in the below mail ?

&n= bsp;

With Re= gards,

Rohit

&n= bsp;

From: Rohit R Ranade
Sent: 28 December 2018 09:37
To: netmod@ietf.org
Subject: Schema Mount Yang Library Update

 

Hi All,

 

For the shared-schema type, the draft mention= s “all instances of the same mount point MUST have the same YANG library content identifier”. 

 

I think to achieve above condition, most vend= ors will plan to have only one YANG library instance for that mount-point.

 

If use multiple instances for Yang library, i= t is possible that the algorithm may generate a new content identifier for = same data as per below statement in Yang library 1.1 draft:

“The=
re is no requirement that the same information always results in the same &=
quot;content-id" value.”<=
/span>
 

If use single instance of Yang library, when = a YANG library update happens, for which mount-point instance should a YANG= library update notification be sent ?

What is the guideline for the implementers of= this draft regarding this point?

 

With Regards,

Rohit

--_000_991B70D8B4112A4699D5C00DDBBF878A6BCC5C7Cdggeml530mbschi_-- From nobody Mon Jan 14 04:32:08 2019 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 65BA5129AA0 for ; Mon, 14 Jan 2019 04:32:06 -0800 (PST) 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 6ZQypaJ1R56B for ; Mon, 14 Jan 2019 04:32:04 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1066613104F for ; Mon, 14 Jan 2019 04:32:02 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id 9E1A41820188; Mon, 14 Jan 2019 13:41:09 +0100 (CET) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 999F11820155; Mon, 14 Jan 2019 13:41:07 +0100 (CET) From: Ladislav Lhotka To: Rohit R Ranade , Martin Bjorklund Cc: "netmod\@ietf.org" In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BCC5C7C@dggeml530-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6BCC5C7C@dggeml530-mbs.china.huawei.com> Mail-Followup-To: Rohit R Ranade , Martin Bjorklund , "netmod\@ietf.org" Date: Mon, 14 Jan 2019 13:31:58 +0100 Message-ID: <877ef7fmip.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] FW: Schema Mount Yang Library Update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 12:32:06 -0000 Hi Rohit, I am sorry that nobody answered your question, but I don't feel competent to do so because I don't like the way how the "shared-schema" case is currently modeled in the first place. Lada Rohit R Ranade writes: > Hi Authors, > > Any suggestions regarding the question in the below mail ? > > With Regards, > Rohit > > From: Rohit R Ranade > Sent: 28 December 2018 09:37 > To: netmod@ietf.org > Subject: Schema Mount Yang Library Update > > Hi All, > > For the shared-schema type, the draft mentions "all instances of the same mount point MUST have the same YANG library content identifier". > > I think to achieve above condition, most vendors will plan to have only one YANG library instance for that mount-point. > > If use multiple instances for Yang library, it is possible that the algorithm may generate a new content identifier for same data as per below statement in Yang library 1.1 draft: > > "There is no requirement that the same information always results in the same "content-id" value." > > > If use single instance of Yang library, when a YANG library update happens, for which mount-point instance should a YANG library update notification be sent ? > What is the guideline for the implementers of this draft regarding this point? > > With Regards, > Rohit -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Jan 14 05:06:13 2019 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 54A94130FF7 for ; Mon, 14 Jan 2019 05:06:11 -0800 (PST) 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 BVs7IpiAmLbM for ; Mon, 14 Jan 2019 05:06:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 93DF112785F for ; Mon, 14 Jan 2019 05:06:08 -0800 (PST) Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id 722251AE0443; Mon, 14 Jan 2019 14:06:05 +0100 (CET) Date: Mon, 14 Jan 2019 14:06:04 +0100 (CET) Message-Id: <20190114.140604.503517025389060984.mbj@tail-f.com> To: rohitrranade@huawei.com Cc: lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BCC5C7C@dggeml530-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6BCC5C7C@dggeml530-mbs.china.huawei.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] Schema Mount Yang Library Update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 13:06:11 -0000 Hi, I think the only reasonable answer is that this behavior must not be dependent on your implementation strategy so the answer must be the same if you choose to use a shared YL or separate YLs. Hence, if a mount point's YL changes, the notif is sent from that instance. /martin Rohit R Ranade wrote: > Hi Authors, > > Any suggestions regarding the question in the below mail ? > > With Regards, > Rohit > > From: Rohit R Ranade > Sent: 28 December 2018 09:37 > To: netmod@ietf.org > Subject: Schema Mount Yang Library Update > > Hi All, > > For the shared-schema type, the draft mentions "all instances of the > same mount point MUST have the same YANG library content identifier". > > I think to achieve above condition, most vendors will plan to have > only one YANG library instance for that mount-point. > > If use multiple instances for Yang library, it is possible that the > algorithm may generate a new content identifier for same data as per > below statement in Yang library 1.1 draft: > > "There is no requirement that the same information always results in > the same "content-id" value." > > > If use single instance of Yang library, when a YANG library update > happens, for which mount-point instance should a YANG library update > notification be sent ? > What is the guideline for the implementers of this draft regarding > this point? > > With Regards, > Rohit From nobody Mon Jan 14 09:07:36 2019 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 067E31311BA for ; Mon, 14 Jan 2019 09:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 (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 Y9Mn92Qf2ivu for ; Mon, 14 Jan 2019 09:07:33 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 58F7C1311B6 for ; Mon, 14 Jan 2019 09:07:33 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id c19-v6so19697627lja.5 for ; Mon, 14 Jan 2019 09:07:33 -0800 (PST) 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=ksNqFjbFqSIRxWLvw+fHqLmBtfHOTPCT05SvTgIeGzw=; b=Rpz/55bt76GrUAzQmyAp/GBkAOGtERiM+OTkXxWgbd351pjFpb6rfX6Q6ULpDX5Gq0 pA/lU2YHA6vDETYZyF1fbs0oJ/XCyTR3ZY2qNMYd5HyNbJj38bL4weYH5XAHDVP2db6P yZX/wiGiWRS0d/MebGDZl+3mF2DcB6moW/xWD9bm7NavJ1b0FT/h/qCWEEEYaL6cCt4d T4hd6H5RYjaT+oLrYAi1F80TzM3qLz7+F/XQKptodu3jWXH5U8d8tkjzsXFTBCOiGg9f CA3DAw1ZKAt3vQIuj7pvRgNj/+/dSXg1q80L49t/7GTXZX1/zB6DzwSCQqHOp/YrofMv 5Pww== 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=ksNqFjbFqSIRxWLvw+fHqLmBtfHOTPCT05SvTgIeGzw=; b=cMxw6YxPIe4blqr/oHSkvyZGyg5DZd0NugM4cZuUFAEOS+mnQB/FuZjLtYQdCZVkl2 vTs0iu5577Z5oDmsCGfeGefy9B0m8cR5bkM4m8Ia0OkQIS6N2LNch6lqj+lVv86XArB/ IUIXKtRhpWE+3lQBL1yabvtphAkXZj3kajza1bBNwGRc67mn134znC+EbT6hRbjwZkQk Zm9Kjn2E9wgMOP69SslUJFBnGqzy7t8LrSJ85h07zVwpAQWZVx/9Ld8e2eAnU37uCtwo HtPgzaiVHy/xvg8W4zlUHwoQ+4h1Z1TkzioE3kWj56WzUYehkt6V832chHlcmevFgxZi kdbA== X-Gm-Message-State: AJcUukegmQxuagag6MSDwaEchCxXOuDsY/hP2LonZt76IfQ1c1WluV9S FlCwBxXo56E+ik5kCwbv7oS57cu+vu7rMwebA4vKqMaN X-Google-Smtp-Source: ALg8bN54Acc8VCdm4AO8Y392ZweRC8nfu/19VSEn+R6eFsinLoqK4ayKxEYn6Cm6UnbIl7cMVrkgBbFN51MC1b1zMxk= X-Received: by 2002:a2e:145a:: with SMTP id 26-v6mr15017445lju.116.1547485650943; Mon, 14 Jan 2019 09:07:30 -0800 (PST) MIME-Version: 1.0 From: Andy Bierman Date: Mon, 14 Jan 2019 09:07:20 -0800 Message-ID: To: NetMod WG Content-Type: multipart/alternative; boundary="00000000000085291d057f6e141b" Archived-At: Subject: [netmod] yang-next meeting at IETF 104? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 17:07:35 -0000 --00000000000085291d057f6e141b Content-Type: text/plain; charset="UTF-8" Hi, Is there any interest in 1 or more side meetings at the next IETF to discuss the yang-next issue list, towards the goal of determining the problem space in scope for YANG 1.2? Those of us who would need to make travel plans would appreciate it if meetings like this were scheduled ASAP instead of ALAP ;-) Andy --00000000000085291d057f6e141b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Is there any interest in 1 or more = side meetings at the next IETF to
discuss the yang-next issue lis= t, towards the goal of determining the
problem space in scope for= YANG 1.2?

Those of us who would need to make trav= el plans would appreciate it
if meetings like this were scheduled= ASAP instead of ALAP ;-)


Andy

--00000000000085291d057f6e141b-- From nobody Mon Jan 14 09:10:35 2019 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 3B54D1311BA for ; Mon, 14 Jan 2019 09:10:34 -0800 (PST) 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 4qFastNJ7hqN for ; Mon, 14 Jan 2019 09:10:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A33501311B6 for ; Mon, 14 Jan 2019 09:10:32 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 188451AE0443; Mon, 14 Jan 2019 18:10:31 +0100 (CET) Date: Mon, 14 Jan 2019 18:10:30 +0100 (CET) Message-Id: <20190114.181030.1714833278513265488.mbj@tail-f.com> To: andy@yumaworks.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 25.2 / 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-next meeting at IETF 104? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 17:10:34 -0000 Hi, Andy Bierman wrote: > Hi, > > Is there any interest in 1 or more side meetings at the next IETF to > discuss the yang-next issue list, towards the goal of determining the > problem space in scope for YANG 1.2? I am interested in this. I prefer a meeting during the week; my plan is to arrive Sunday afternoon. /martin > Those of us who would need to make travel plans would appreciate it > if meetings like this were scheduled ASAP instead of ALAP ;-) > > > Andy From nobody Mon Jan 14 09:19:35 2019 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 5BA041311CC for ; Mon, 14 Jan 2019 09:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.053 X-Spam-Level: X-Spam-Status: No, score=-19.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 B87G1jmgBNKE for ; Mon, 14 Jan 2019 09:19:32 -0800 (PST) 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 70FE61311BB for ; Mon, 14 Jan 2019 09:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=916; q=dns/txt; s=iport; t=1547486371; x=1548695971; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Ev+UFl6TY4cTfRqIi6u+Pwl7OVmXGFE5mzRpfHh2cQ8=; b=Dn4qRMxqMpmORCyzVUNQNjaQO1YaQdbWX7Eoyx0e9H96BeH9xNh9Yq25 E55YdwC2cST1wOSl4vVMl3EWddXoAlAyRNCxPUyBi6UH5WLOZpwUGRxvI RhKDPn04wru3VRJsusoOWIxOrCS4O0KkLc7VjVJGOlng6IQgZQ7LSatTO o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/AADQwzxc/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYJqTyESJ4QBiHmMbi2Zdw0YC4QDRgKCYTgSAQMBAQI?= =?us-ascii?q?BAQJtHAyFSwEBAQMBASEPAQU2CxALDgoCAiYCAicwBgEMBgIBAYMeAYIBD60?= =?us-ascii?q?3gS+FQoRdBYELi0uBQD+BESeCa4FBgV0BAYRqglcCiTWYTwmSAgYYihqHZYl?= =?us-ascii?q?1iW2HCoFdIYFWMxoIGxU7gmyCM4hqhT4BPwMwil8BAQ?= X-IronPort-AV: E=Sophos;i="5.56,478,1539648000"; d="scan'208";a="9435636" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2019 17:19:29 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x0EHJUaT023476; Mon, 14 Jan 2019 17:19:30 GMT To: Martin Bjorklund , andy@yumaworks.com Cc: netmod@ietf.org References: <20190114.181030.1714833278513265488.mbj@tail-f.com> From: Robert Wilton Message-ID: <9292f38a-1f09-d738-6d4c-0645d78f86d5@cisco.com> Date: Mon, 14 Jan 2019 17:19:29 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190114.181030.1714833278513265488.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] yang-next meeting at IETF 104? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 17:19:34 -0000 I would also be interested.  During the week would also be best. Friday morning could also be a possibility depending on whether there are sessions scheduled. Thanks, Rob On 14/01/2019 17:10, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> Is there any interest in 1 or more side meetings at the next IETF to >> discuss the yang-next issue list, towards the goal of determining the >> problem space in scope for YANG 1.2? > I am interested in this. I prefer a meeting during the week; my plan > is to arrive Sunday afternoon. > > > /martin > >> Those of us who would need to make travel plans would appreciate it >> if meetings like this were scheduled ASAP instead of ALAP ;-) >> >> >> Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Jan 14 11:45:19 2019 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 DFE4113126B for ; Mon, 14 Jan 2019 11:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.253 X-Spam-Level: X-Spam-Status: No, score=-5.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 PetFrqnwF-Ug for ; Mon, 14 Jan 2019 11:45:14 -0800 (PST) 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 E0E50129AB8 for ; Mon, 14 Jan 2019 11:45:13 -0800 (PST) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0EJW6Jj011058; Mon, 14 Jan 2019 11:45:12 -0800 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=7i5M/XVO1O9uiCa5twxa2UaPlQTAYem07HsU0JQhdm0=; b=iuEZQzGi0fdFjN9dInzRZUnuvVk2UZpki5C9f+j9/4v7pcYRzQAEmxu7Xp1/zyMOyeDZ 78De4E7BWhZQYpbEtmTog48m0Gj35WrfWAQixZZKKFqHHa7CPmta+cgTuJQC+n2Fvb4N m/+7tOesg01OZ3pV2VbRjEXolWJs6KJquanBVUjcYSWSO1QVL4zGjPr5To/V7FS+rU0+ TnS7OnJ9LAeJ8dVDRl59AFN95baexq8I//x1B9P7DRqXU814wYc8Vv8xPfruAXMGLD13 03kXcdBaCP2E4ccKvHqw3KsNDHwadT97F71nvXXdqYrPG7r5UWSjW22SQr5FaI6DD4Xk NQ== Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp2055.outbound.protection.outlook.com [104.47.40.55]) by mx0b-00273201.pphosted.com with ESMTP id 2q0y870521-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 11:45:12 -0800 Received: from BYAPR05MB5416.namprd05.prod.outlook.com (20.177.184.221) by BYAPR05MB5031.namprd05.prod.outlook.com (20.177.230.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.17; Mon, 14 Jan 2019 19:45:09 +0000 Received: from BYAPR05MB5416.namprd05.prod.outlook.com ([fe80::ccee:5d54:3370:e50b]) by BYAPR05MB5416.namprd05.prod.outlook.com ([fe80::ccee:5d54:3370:e50b%5]) with mapi id 15.20.1537.018; Mon, 14 Jan 2019 19:45:09 +0000 From: Kent Watsen To: Robert Wilton , Martin Bjorklund , "andy@yumaworks.com" CC: "netmod@ietf.org" Thread-Topic: [netmod] yang-next meeting at IETF 104? Thread-Index: AQHUrCuq8LA2K3fznUKN5CVaZ7vS9qWu/8MAgAACgoD//9TgAA== Date: Mon, 14 Jan 2019 19:45:09 +0000 Message-ID: References: <20190114.181030.1714833278513265488.mbj@tail-f.com> <9292f38a-1f09-d738-6d4c-0645d78f86d5@cisco.com> In-Reply-To: <9292f38a-1f09-d738-6d4c-0645d78f86d5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.5.181209 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB5031; 6:9wHefMCCDdP3aUvc9H76KAEc4QUs/w92cUOC9MbGr9hXxn0mCGyDWZuSOkTjuV7sTghtjnbgFb/xSLwEPPMtNoluFjabLE77sdM50t2nfeHxh9W9HBwNXYJBRwl1hbpA2FnRuAYRUQaImKBb9c7v8xFLHrNHxIEj1B3MKx/yLg0gN7wsJz3SKz6ka6cD/WB3KMCNkjankS9IXt6QzQuZoTXXZU185B/9cdLA+i2GnlWs4difcKb7KOCG9Uia3F7gUzD3dAZtfGSR81IFRTMW24PWydJacuw8oIMJ9thrrn0F3Qx95/hMkgCegy0tWPVtqxTWQuQcACEQQCAdqYuRwjejUQ7ERU3RSm2EQDKsUj5GCu/UBEN9/lxjbnsGzjuOgCtzuGB3klumFAKyVeDlK7mAv1eQPFlDXC5Iju9ZiyrR+eI6Mpti7Dt5zmG4MA6DTFAYaGqBN99+pGvYUasgRw==; 5:3fV0++0IQc/4NXvoaXmJHo/hwaLGyqlY1iS+n4l7N2EDmRRaErM1qpbOyCMJNY09aHQD7Gnhg0oOGM1Py2QPLZNH0Dh89qd8kO5uXV5P3//NJuJlrtQnDttpuQx5k7Q3r1WLZnm+xkxZH2v8OK+UlgYXNGgeiVgxVzzmmiSTnQhPAJeeEXhmCD62Wc4Jrw/lzuUSuDdnu+YsaaJ1IzESmw==; 7:G+n9XlqJm+3Ga2YNBKeoA/os0ZC7E49suePJw8nNzd161L06Mur83haQhhdpI7nE1Ullc/c/nK5pXVcfo0qdLcxQwYnvzwR6T0PPJW4QuiScmICRA5X84yXaTukD2hku8EwFyf9iLAmTFFomB7zRtA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a7ff6786-6418-4eea-008b-08d67a58cabe x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5031; x-ms-traffictypediagnostic: BYAPR05MB5031: x-microsoft-antispam-prvs: x-forefront-prvs: 0917DFAC67 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(136003)(366004)(396003)(199004)(189003)(52024003)(13464003)(53936002)(76176011)(82746002)(106356001)(5660300001)(229853002)(6486002)(6116002)(14454004)(3846002)(105586002)(6436002)(25786009)(71200400001)(575784001)(71190400001)(97736004)(86362001)(476003)(446003)(11346002)(2616005)(256004)(83716004)(486006)(110136005)(6306002)(53546011)(6506007)(102836004)(33656002)(186003)(58126008)(26005)(2906002)(316002)(6512007)(2501003)(99286004)(4326008)(36756003)(68736007)(966005)(6246003)(478600001)(81166006)(8676002)(81156014)(8936002)(305945005)(66066001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5031; H:BYAPR05MB5416.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zz7BjHtVbG96P/YTSrQ8tUBfsKWy4iV7CMKgSS7kx5oPRxol2Hj+G+vyFlTpKQQzkG7CqV+ZJK7M//nvElbOfozL/z0IM2jqDcTY2wqdikcabLOkJJYxFs7VgOpeX1DVyvhvYswRgMTUQfj+cXo9wPNh8teaDXV2inTYi80wDUhz6Zyn+9lr1b+ITpsk+j4c3wJYIbkbudThNj8VpDhkzOx9baQq0nm0Q0CtgI/FcBDoHPxJA2e5xuJ77+67W25nFE4cDSgFmfqVM5l2RIL0VJNZ79ehR/d4fAF6oanWXQl7BT8gW1QeN/8VaHX3JfAZYeREXSsOpsRYOuQz1tx1XW8EqjTyoJOclvTH7VJ2kEy63flJDHYxdj9OihlFuRlpRUmi2oLWicRgD/OWYtCAmakjxea/xFuXeNjMqfTviow= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9DBD28924918014CB49FC9FBE914D8C4@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: a7ff6786-6418-4eea-008b-08d67a58cabe X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2019 19:45:09.5933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5031 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-14_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-1810050000 definitions=main-1901140151 Archived-At: Subject: Re: [netmod] yang-next meeting at IETF 104? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 19:45:17 -0000 SSdtIGludGVyZXN0ZWQgYXMgd2VsbC4NCg0KUFM6IEkndmUgYmVlbiB0b28gYnVzeSB0byBzZXR1 cCBhIHZpcnR1YWwgbWVldGluZyBmb3IgdXMgdG8gZmluaXNoIHRoZSByZXZpZXcgb2YgdGhlIFlB TkctbmV4dCBpdGVtcyBpbiB0aGUgR2l0SHViIHRyYWNrZXIuICBCdXQgdGhpbmdzIGFyZSBqdXN0 IGJlZ2lubmluZyB0byBmcmVlIHVwIGEgbGl0dGxlIGZvciBtZSBub3cuICBXb3VsZCBmb2xrcyBs aWtlIHRvIGhhdmUgYSBtZWV0aW5nIGJlZm9yZSAxMDQgdG8gZmluaXNoIHRoYXQgcmV2aWV3Pw0K DQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBSb2Jl cnQgV2lsdG9uIDxyd2lsdG9uQGNpc2NvLmNvbT4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSAxNCwg MjAxOSBhdCAxMjoxOSBQTQ0KVG86IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiwg ImFuZHlAeXVtYXdvcmtzLmNvbSIgPGFuZHlAeXVtYXdvcmtzLmNvbT4NCkNjOiBORVRNT0QgV29y a2luZyBHcm91cCA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIHlhbmct bmV4dCBtZWV0aW5nIGF0IElFVEYgMTA0Pw0KDQpJIHdvdWxkIGFsc28gYmUgaW50ZXJlc3RlZC4g IER1cmluZyB0aGUgd2VlayB3b3VsZCBhbHNvIGJlIGJlc3QuIEZyaWRheSANCm1vcm5pbmcgY291 bGQgYWxzbyBiZSBhIHBvc3NpYmlsaXR5IGRlcGVuZGluZyBvbiB3aGV0aGVyIHRoZXJlIGFyZSAN CnNlc3Npb25zIHNjaGVkdWxlZC4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KT24gMTQvMDEvMjAxOSAx NzoxMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gSGksDQo+DQo+IEFuZHkgQmllcm1hbiA8 YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCj4+IEhpLA0KPj4NCj4+IElzIHRoZXJlIGFueSBp bnRlcmVzdCBpbiAxIG9yIG1vcmUgc2lkZSBtZWV0aW5ncyBhdCB0aGUgbmV4dCBJRVRGIHRvDQo+ PiBkaXNjdXNzIHRoZSB5YW5nLW5leHQgaXNzdWUgbGlzdCwgdG93YXJkcyB0aGUgZ29hbCBvZiBk ZXRlcm1pbmluZyB0aGUNCj4+IHByb2JsZW0gc3BhY2UgaW4gc2NvcGUgZm9yIFlBTkcgMS4yPw0K PiBJIGFtIGludGVyZXN0ZWQgaW4gdGhpcy4gIEkgcHJlZmVyIGEgbWVldGluZyBkdXJpbmcgdGhl IHdlZWs7IG15IHBsYW4NCj4gaXMgdG8gYXJyaXZlIFN1bmRheSBhZnRlcm5vb24uDQo+DQo+DQo+ IC9tYXJ0aW4NCj4NCj4+IFRob3NlIG9mIHVzIHdobyB3b3VsZCBuZWVkIHRvIG1ha2UgdHJhdmVs IHBsYW5zIHdvdWxkIGFwcHJlY2lhdGUgaXQNCj4+IGlmIG1lZXRpbmdzIGxpa2UgdGhpcyB3ZXJl IHNjaGVkdWxlZCBBU0FQIGluc3RlYWQgb2YgQUxBUCA7LSkNCj4+DQo+Pg0KPj4gQW5keQ0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2Qg bWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX25ldG1vZCZkPUR3SUdhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9E VFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09 QmZHbmpZZWpyR2pROTN4QXpZMXB6QTlNOXdYWFk3ck5GZVd5M2RLWlhXYyZzPWZOT2EyVUlPTWhO RGNPM25GRUZCZHFRU2RyUS1LYVlORjJHYVRnZlJzZ0kmZT0NCj4gLg0KPg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlz dA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3 SUdhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQ MHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09QmZHbmpZZWpyR2pROTN4 QXpZMXB6QTlNOXdYWFk3ck5GZVd5M2RLWlhXYyZzPWZOT2EyVUlPTWhORGNPM25GRUZCZHFRU2Ry US1LYVlORjJHYVRnZlJzZ0kmZT0NCg0K From nobody Mon Jan 14 11:57:29 2019 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 8C7E413125F for ; Mon, 14 Jan 2019 11:57:26 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 akOnBJ1enx-H for ; Mon, 14 Jan 2019 11:57:24 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 127D8129AB8 for ; Mon, 14 Jan 2019 11:57:24 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id g189so108544pgc.5 for ; Mon, 14 Jan 2019 11:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=lzv1QBUqu0a8qvS0uBhsNY9OTWE+7hnjmFS0V5VWWkI=; b=vEJWkZV/lw5XU7uIHUv56LgBu9XYvwbc22u1k9xjCXfmc2a0XqI+Mpi+z6rj1i0Mdt hbv1kg4EwcM3kkxEbzx8ye4S/7HUGYjkyflcACDZIEEqLljxGtTBkBfMEqSk3uXFecNF 5Jjmlbv/Bz/0o93ZB1OqneM8UX1rn0PfibHFZgT3GOZ+6eeHIIkYrwx1BIivdzGvfGow yh1dcU9tuCbj5U9ixyVyldekCLxFgDx/65mi3pxkORGsBMxcjD7B4rp6ipuAG3IYAXSJ VUAx8Utzp7RAQYGkooH93ahL4S1nQONngrWWRBchFJDAWXgYYeB+oIGc+p9XXxrYvCpM XZow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=lzv1QBUqu0a8qvS0uBhsNY9OTWE+7hnjmFS0V5VWWkI=; b=TYnGvR+HkyVtASAHFLRTmSctpGgOoGYhZ5ZH7lWMcaMIXDJevGR95IhjLO2+uOgHk/ YkkuGdS9o5TBWYLMhF1GishbE1o/qQ44/thJHHMhDn+r52AWohnx8nrwGSohRiUy38IM FlI86V2EJtrtaGtPiAHf+sgC/v4dyvMnmGdNWSrtFhpEoaKcl62SfgbsmbfjQk8DYtJ1 G6WtIxUxJiagZqiHwDDpIW1Ka5b73ncffUjrcbZrMflN3mv2FLjH5oR6NCgDXcDWYn4B yp1SXxMIn+vTWEvzp714tmTkDRJ/z/xQ+1ydOhf6v29LTSStq6uwqY0vhdt8CDsbNh+F I+1w== X-Gm-Message-State: AJcUukfXapPCaZz9k3h9eAJCbYLeRUubc8LXQhcET8yLVhaAhhbw8gdg Xo0f2IxWF0W23IbPDnOe/VKqvffpeF8= X-Google-Smtp-Source: ALg8bN4dW3mlvusZ+c9RZpJN9UiRLOy0WWf9anQnLOPhit0flWzUkVZx4TKMxCi5BqKMnidmR/QsLA== X-Received: by 2002:a63:3858:: with SMTP id h24mr171179pgn.300.1547495843592; Mon, 14 Jan 2019 11:57:23 -0800 (PST) Received: from ?IPv6:2001:8003:2396:6700:5041:fd65:5952:ed65? ([2001:8003:2396:6700:5041:fd65:5952:ed65]) by smtp.gmail.com with ESMTPSA id s84sm2983888pfi.15.2019.01.14.11.57.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 14 Jan 2019 11:57:22 -0800 (PST) References: <20190114.181030.1714833278513265488.mbj@tail-f.com> <9292f38a-1f09-d738-6d4c-0645d78f86d5@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <9DB95AF9-E199-44DF-A10B-DBB74D4FACAD@gmail.com> Cc: Robert Wilton , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" X-Mailer: iPad Mail (13G36) From: Mahesh Jethanandani Date: Tue, 15 Jan 2019 06:57:19 +1100 To: Kent Watsen Archived-At: Subject: Re: [netmod] yang-next meeting at IETF 104? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 19:57:27 -0000 Hi Kent, I think it makes sense to have a virtual meeting before 104.=20 Mahesh Jethanandani mjethanandani@gmail.com > On Jan 15, 2019, at 6:45 AM, Kent Watsen wrote: >=20 > I'm interested as well. >=20 > PS: I've been too busy to setup a virtual meeting for us to finish the rev= iew of the YANG-next items in the GitHub tracker. But things are just begin= ning to free up a little for me now. Would folks like to have a meeting bef= ore 104 to finish that review? >=20 > Kent // contributor >=20 >=20 > =EF=BB=BF-----Original Message----- > From: netmod on behalf of Robert Wilton > Date: Monday, January 14, 2019 at 12:19 PM > To: Martin Bjorklund , "andy@yumaworks.com" > Cc: NETMOD Working Group > Subject: Re: [netmod] yang-next meeting at IETF 104? >=20 > I would also be interested. During the week would also be best. Friday=20= > morning could also be a possibility depending on whether there are=20 > sessions scheduled. >=20 > Thanks, > Rob >=20 >=20 >> On 14/01/2019 17:10, Martin Bjorklund wrote: >> Hi, >>=20 >> Andy Bierman wrote: >>> Hi, >>>=20 >>> Is there any interest in 1 or more side meetings at the next IETF to >>> discuss the yang-next issue list, towards the goal of determining the >>> problem space in scope for YANG 1.2? >> I am interested in this. I prefer a meeting during the week; my plan >> is to arrive Sunday afternoon. >>=20 >>=20 >> /martin >>=20 >>> Those of us who would need to make travel plans would appreciate it >>> if meetings like this were scheduled ASAP instead of ALAP ;-) >>>=20 >>>=20 >>> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_netmod&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoC= I&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DBfGnjYejrGjQ93xAzY1pzA= 9M9wXXY7rNFeWy3dKZXWc&s=3DfNOa2UIOMhNDcO3nFEFBdqQSdrQ-KaYNF2GaTgfRsgI&e=3D >> . >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_netmod&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI= &r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DBfGnjYejrGjQ93xAzY1pzA9= M9wXXY7rNFeWy3dKZXWc&s=3DfNOa2UIOMhNDcO3nFEFBdqQSdrQ-KaYNF2GaTgfRsgI&e=3D >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Jan 14 12:01:47 2019 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 3ABB01312AF for ; Mon, 14 Jan 2019 12:01:39 -0800 (PST) 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 UoCVKhdJ_vxE for ; Mon, 14 Jan 2019 12:01:36 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A7D411312B2 for ; Mon, 14 Jan 2019 12:01:36 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id BCC8D1AE0443; Mon, 14 Jan 2019 21:01:35 +0100 (CET) Date: Mon, 14 Jan 2019 21:01:35 +0100 (CET) Message-Id: <20190114.210135.1957093582321067772.mbj@tail-f.com> To: kwatsen@juniper.net Cc: rwilton@cisco.com, andy@yumaworks.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190114.181030.1714833278513265488.mbj@tail-f.com> <9292f38a-1f09-d738-6d4c-0645d78f86d5@cisco.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / 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-next meeting at IETF 104? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 20:01:45 -0000 S2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiBJJ20gaW50ZXJlc3Rl ZCBhcyB3ZWxsLg0KPiANCj4gUFM6IEkndmUgYmVlbiB0b28gYnVzeSB0byBzZXR1cCBhIHZpcnR1 YWwgbWVldGluZyBmb3IgdXMgdG8gZmluaXNoIHRoZQ0KPiByZXZpZXcgb2YgdGhlIFlBTkctbmV4 dCBpdGVtcyBpbiB0aGUgR2l0SHViIHRyYWNrZXIuICBCdXQgdGhpbmdzIGFyZQ0KPiBqdXN0IGJl Z2lubmluZyB0byBmcmVlIHVwIGEgbGl0dGxlIGZvciBtZSBub3cuICBXb3VsZCBmb2xrcyBsaWtl IHRvDQo+IGhhdmUgYSBtZWV0aW5nIGJlZm9yZSAxMDQgdG8gZmluaXNoIHRoYXQgcmV2aWV3Pw0K DQpJIHRoaW5rIHRoYXQncyB3aGF0IHRoZSBzaWRlIG1lZXRpbmcgd291bGQgZG8gLSByZXZpZXcg dGhlIGN1cnJlbnQNCml0ZW1zIHRvIHNlZSB3aGF0IG1ha2VzIHNlbnNlLg0KDQoNCi9tYXJ0aW4N Cg0KDQoNCj4gDQo+IEtlbnQgLy8gY29udHJpYnV0b3INCj4gDQo+IA0KPiDvu78tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgUm9iZXJ0IFdpbHRvbg0KPiA8cndpbHRvbkBjaXNjby5jb20+DQo+IERh dGU6IE1vbmRheSwgSmFudWFyeSAxNCwgMjAxOSBhdCAxMjoxOSBQTQ0KPiBUbzogTWFydGluIEJq b3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+LCAiYW5keUB5dW1hd29ya3MuY29tIg0KPiA8YW5keUB5 dW1hd29ya3MuY29tPg0KPiBDYzogTkVUTU9EIFdvcmtpbmcgR3JvdXAgPG5ldG1vZEBpZXRmLm9y Zz4NCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIHlhbmctbmV4dCBtZWV0aW5nIGF0IElFVEYgMTA0 Pw0KPiANCj4gSSB3b3VsZCBhbHNvIGJlIGludGVyZXN0ZWQuICBEdXJpbmcgdGhlIHdlZWsgd291 bGQgYWxzbyBiZQ0KPiBiZXN0LiBGcmlkYXkNCj4gbW9ybmluZyBjb3VsZCBhbHNvIGJlIGEgcG9z c2liaWxpdHkgZGVwZW5kaW5nIG9uIHdoZXRoZXIgdGhlcmUgYXJlIA0KPiBzZXNzaW9ucyBzY2hl ZHVsZWQuDQo+IA0KPiBUaGFua3MsDQo+IFJvYg0KPiANCj4gDQo+IE9uIDE0LzAxLzIwMTkgMTc6 MTAsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4gSGksDQo+ID4NCj4gPiBBbmR5IEJpZXJt YW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBJcyB0 aGVyZSBhbnkgaW50ZXJlc3QgaW4gMSBvciBtb3JlIHNpZGUgbWVldGluZ3MgYXQgdGhlIG5leHQg SUVURiB0bw0KPiA+PiBkaXNjdXNzIHRoZSB5YW5nLW5leHQgaXNzdWUgbGlzdCwgdG93YXJkcyB0 aGUgZ29hbCBvZiBkZXRlcm1pbmluZyB0aGUNCj4gPj4gcHJvYmxlbSBzcGFjZSBpbiBzY29wZSBm b3IgWUFORyAxLjI/DQo+ID4gSSBhbSBpbnRlcmVzdGVkIGluIHRoaXMuICBJIHByZWZlciBhIG1l ZXRpbmcgZHVyaW5nIHRoZSB3ZWVrOyBteSBwbGFuDQo+ID4gaXMgdG8gYXJyaXZlIFN1bmRheSBh ZnRlcm5vb24uDQo+ID4NCj4gPg0KPiA+IC9tYXJ0aW4NCj4gPg0KPiA+PiBUaG9zZSBvZiB1cyB3 aG8gd291bGQgbmVlZCB0byBtYWtlIHRyYXZlbCBwbGFucyB3b3VsZCBhcHByZWNpYXRlIGl0DQo+ ID4+IGlmIG1lZXRpbmdzIGxpa2UgdGhpcyB3ZXJlIHNjaGVkdWxlZCBBU0FQIGluc3RlYWQgb2Yg QUxBUCA7LSkNCj4gPj4NCj4gPj4NCj4gPj4gQW5keQ0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9 RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6 a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1CZkdualllanJHalE5 M3hBelkxcHpBOU05d1hYWTdyTkZlV3kzZEtaWFdjJnM9Zk5PYTJVSU9NaE5EY08zbkZFRkJkcVFT ZHJRLUthWU5GMkdhVGdmUnNnSSZlPQ0KPiA+IC4NCj4gPg0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0K PiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1E d0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXpr UDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPUJmR25qWWVqckdqUTkz eEF6WTFwekE5TTl3WFhZN3JORmVXeTNkS1pYV2Mmcz1mTk9hMlVJT01oTkRjTzNuRkVGQmRxUVNk clEtS2FZTkYyR2FUZ2ZSc2dJJmU9DQo+IA0K From nobody Mon Jan 14 14:27:20 2019 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 5E4141313F0 for ; Mon, 14 Jan 2019 14:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, 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 LQCkCxb0G63h for ; Mon, 14 Jan 2019 14:27:17 -0800 (PST) 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 171C71313EC for ; Mon, 14 Jan 2019 14:27:16 -0800 (PST) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0EMRFkm021956; Mon, 14 Jan 2019 14:27:15 -0800 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=1IvYOHI3/sNBjHnR8G3ZtGfihrE/HsBK/uXUav2vd80=; b=UhgyWaKCBzsPJr9BvTIMDSrkUwTh79vemuJ5Lv55M/rJgB8eNXJAGv+NQGK4mo8IlJSP BbVdzsLUV1ZWTaSagzn5U0lEC4anTM3Hc6SJy/NE4Y9fgqy60e5kgcicjHSLPNmMFDtA ozPH2Wo3PXn1YstkAqeCywyL9eEjA7Qux3cKnWgnKElTOE7aRUebJXvmnJyhMLiNqbnr sIy6Rw6X+XcYZxP1lPlKEpvtk8TmkEEPf9y+jvaB6ue90uAsP0QhOr4k5zVWMeBywtih Xn5jx+7pjDGecnVUM3FnEknxVxIdcRQrR1MsJC69JCOgzZWZMPXe7p/N3LnO40r9eB9n yA== Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp2052.outbound.protection.outlook.com [104.47.49.52]) by mx0b-00273201.pphosted.com with ESMTP id 2q0yfv8ap7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 14:27:15 -0800 Received: from BYAPR05MB5416.namprd05.prod.outlook.com (20.177.184.221) by BYAPR05MB4741.namprd05.prod.outlook.com (52.135.233.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.19; Mon, 14 Jan 2019 22:27:12 +0000 Received: from BYAPR05MB5416.namprd05.prod.outlook.com ([fe80::ccee:5d54:3370:e50b]) by BYAPR05MB5416.namprd05.prod.outlook.com ([fe80::ccee:5d54:3370:e50b%5]) with mapi id 15.20.1537.018; Mon, 14 Jan 2019 22:27:12 +0000 From: Kent Watsen To: Martin Bjorklund CC: "rwilton@cisco.com" , "andy@yumaworks.com" , "netmod@ietf.org" Thread-Topic: [netmod] yang-next meeting at IETF 104? Thread-Index: AQHUrCuq8LA2K3fznUKN5CVaZ7vS9qWu/8MAgAACgoD//9TgAIAAWGqA///U3YA= Date: Mon, 14 Jan 2019 22:27:12 +0000 Message-ID: References: <20190114.181030.1714833278513265488.mbj@tail-f.com> <9292f38a-1f09-d738-6d4c-0645d78f86d5@cisco.com> <20190114.210135.1957093582321067772.mbj@tail-f.com> In-Reply-To: <20190114.210135.1957093582321067772.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.5.181209 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4741; 6:Pw2ohuvGseFUhBCbJUlb/7GlGf38yLavPgo4YIeFYZQNK8/ajT/aYDZsSpxuLuWj8uPaBmO9Nw9MByV0ncrxhD+SypdzlB0tSpT7yMz9nuwuoDRUqj6XIEJAeLG77TQJCMHy+H4xHtGRoniADTyAQ3+1q6T9ZkKPf6gb+YMszwpe5cQua2Ex8rGehB8prKterVdm44amb1V+9Bvmsw2tViwMtgsKqNNdXTO8uO9IRjQIcUMsaIfa/iuGFDWtBQ3zxW+wzv81jXVJveN7sZF3PNERqj/F38aDEKaFE2uX25FROkWkC1WsvdXXq6hyVwNXjzQv0tdK4SY/1Xjl3dbnXGkjO2R5KgodV82MOGbfC1wQPlPQz9vAvVqYjMFDDjCwM7EkOp5iaBITYsbI66r1/q8C6+ih3l4OhtZKao9V8OhHxURBsKfe8Emg0EPcrOKLBRoZowQ5wovbok0IF8ZUgA==; 5:AyxZcZn9gcMxmecMg55tkE7Bx2Ix1jVblh6jeyy1F2TQNb2H6TiaEWT9KHtfX7erczH+Q6G4RlMHMIuCKt+OfwcxZNMoOZ9vjBPFuuecxwW85p8E46+ZOWHbUFvAOmX7J+Ar/JM9h3ZMHbj8swmnboeOJx/BLGgMWFtzT466S2+BKDFYjE2eqX1YD8FZgW6yduJONlHKsNmEyPU1q2aw7w==; 7:BGdtsWvclkp/+Zv+Hov5jDp/N9lKg7dd5YRLVZfT2MVn7L5RZAckcm5bmdhu0ip2h/+N83DgbExUbWkhCRoV2s3ItUw0uQbYJyaDcaGgkE2nzSxjRIRutaQqACvUDc3SrVxd6SiK5+2iO4lNiyViIQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: dfe4be0d-5560-4620-db27-08d67a6f6e39 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4741; x-ms-traffictypediagnostic: BYAPR05MB4741: x-microsoft-antispam-prvs: x-forefront-prvs: 0917DFAC67 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39850400004)(376002)(346002)(366004)(396003)(199004)(189003)(52024003)(51444003)(6512007)(25786009)(186003)(76176011)(82746002)(229853002)(4326008)(99286004)(105586002)(6306002)(53936002)(316002)(256004)(476003)(486006)(54906003)(68736007)(5660300001)(97736004)(14454004)(26005)(58126008)(6246003)(106356001)(6486002)(2616005)(305945005)(8936002)(11346002)(6436002)(6506007)(8676002)(6916009)(86362001)(36756003)(33656002)(446003)(3846002)(6116002)(2906002)(7736002)(83716004)(81166006)(66066001)(81156014)(71190400001)(71200400001)(478600001)(102836004)(93886005)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4741; H:BYAPR05MB5416.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: VddZZzA4BlMJVFYI/aIAG3qyii/vPZhgDUw7gQ2IDoUow/r3pkw+con75YD+D2trb/Gnit2isMHKT/uGGog3aOuW2ba4zwm+Sm2JB4f4664vQmgw0I8SQmtFwPEHpJncNsCFMwO5yIKV3RxDwbPswiQDye3Ygpx2tUhgMXjn+I7z+9uoa9x2RxjDv89dDsN7DS8HSRAMvxw0O3yj9sQERyEd5u/XVvATyMytxMzHjvSHywtvWnpHKY1xEjI/0r00D8IHaWyxJ/q4bnQ0gGbDZJYmN9z+QB3chbVMn4FohtjIqcgAolN3ZvMMFTpml///61Zb5XJhF3kZVFj69LKi12cGMJzPluRNRmFaGwvQLfsk+eoqdfEM34RIlfSQjBXELN7iXf+QVG33ccuolCUv36lgfMOQ6sZu+69jlp3l38k= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: dfe4be0d-5560-4620-db27-08d67a6f6e39 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2019 22:27:12.7687 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4741 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-14_12:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901140173 Archived-At: Subject: Re: [netmod] yang-next meeting at IETF 104? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 22:27:19 -0000 Pj4gUFM6IEkndmUgYmVlbiB0b28gYnVzeSB0byBzZXR1cCBhIHZpcnR1YWwgbWVldGluZyBmb3Ig dXMgdG8gZmluaXNoIHRoZQ0KPj4gcmV2aWV3IG9mIHRoZSBZQU5HLW5leHQgaXRlbXMgaW4gdGhl IEdpdEh1YiB0cmFja2VyLiAgQnV0IHRoaW5ncyBhcmUNCj4+IGp1c3QgYmVnaW5uaW5nIHRvIGZy ZWUgdXAgYSBsaXR0bGUgZm9yIG1lIG5vdy4gIFdvdWxkIGZvbGtzIGxpa2UgdG8NCj4+IGhhdmUg YSBtZWV0aW5nIGJlZm9yZSAxMDQgdG8gZmluaXNoIHRoYXQgcmV2aWV3Pw0KPg0KPiBJIHRoaW5r IHRoYXQncyB3aGF0IHRoZSBzaWRlIG1lZXRpbmcgd291bGQgZG8gLSByZXZpZXcgdGhlIGN1cnJl bnQNCj4gaXRlbXMgdG8gc2VlIHdoYXQgbWFrZXMgc2Vuc2UuDQoNClN1cmUsIGJ1dCBwZXJoYXBz IHRoZSBpbi1wZXJzb24gdGltZSB3b3VsZCBiZSBiZXR0ZXIgc3BlbnQgYW5hbHl6aW5nIHRoZSBy ZXN1bHRzIG9mIHRoZSByZXZpZXdzPyAgUmVjYWxsIHRoYXQgd2UncmUgdHJ5aW5nIHRvIHNjb3Jl IGVhY2ggaXRlbSBvbiB0aHJlZSBheGlzOiBpbXBvcnRhbmNlLCBjb21wbGV4aXR5LCBiYWNrd2Fy ZC1jb21wYXRpYmlsaXR5Lg0KDQpDdXJyZW50IHJlc3VsdHMgaGVyZTogIGh0dHBzOi8vZ2l0aHVi LmNvbS9uZXRtb2Qtd2cveWFuZy1uZXh0L2lzc3Vlcz9xPWlzJTNBaXNzdWUraXMlM0FvcGVuK3Nv cnQlM0FjcmVhdGVkLWFzYy4NCg0KQXQgdGhlIHJhdGUgd2Ugd2VyZSBnb2luZyAoYWJvdXQgNDAl IGRvbmUpLCBJIGltYWdpbmUgaXQgdGFraW5nIDItNCBob3VycyB0byBzY29yZSB0aGUgcmVtYWlu aW5nIGlzc3Vlcy4gIFRoaXMgbWF5IG5vdCBiZSBhbiBpc3N1ZSBpZiB3ZSBjYW4gbWVldCBtdWx0 aXBsZSB0aW1lcyBkdXJpbmcgdGhlIHdlZWsgYnV0LCBpZiB0aW1lIGlzIHRpZ2h0LCBJJ2QgcmF0 aGVyIGhhdmUgdGhpcyBwYXJ0IGRvbmUgYmVmb3JlIHdlIG1lZXQuDQoNCktlbnQgLy8gY29udHJp YnV0b3INCg0KDQo= From nobody Mon Jan 14 15:32:31 2019 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 93D1D131443 for ; Mon, 14 Jan 2019 15:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 9u3KX49G_0EX for ; Mon, 14 Jan 2019 15:32:23 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 2AA0A126F72 for ; Mon, 14 Jan 2019 15:32:23 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id v5so596111lfe.7 for ; Mon, 14 Jan 2019 15:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I+scEO2MJqUxn3fL4dlvfDZxJWrJPEQmefX3/gMAoJc=; b=NkEAkdun8YDylgwi/7DfglYB2Qm5MDx2t/FL6QTjb+Zow8/bXxX/zwG1e9G9OYOjZ9 vQ8J42WVSqBt/YOl79+ehBAmsH0kCeRD1fFAghEUshZYjABX0JgSHvioRmKDbg4qX75w xLlc1BRQMJwvcK3NHsxhHgvGHIND9S2TzEhsEKVCO/l8u+54kxwoXmRhdAN0ei5Rq+Wh 6kdkEKEd0UBhP0LhhasAGaTO7hOOB1G0RDDmggKAQGHiCGvtol8idn1kxvljvNSr0bfs dxgrbDjHDa07dec6WSjcG3VkhQHMkf2h3Qx/3xN8V3aKWid5WeGwZX1h4kTH+0CLDSIG dOHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I+scEO2MJqUxn3fL4dlvfDZxJWrJPEQmefX3/gMAoJc=; b=OwTINWBjHf/oFP4rgYG40U/53z3rF04SNmBwES4rXU10SgSOxcaO9Qma0kSf9rHWR6 CY9i8okOdoOgXFCDmqliKY7/m5X0DuvTgHVwwpHcLRR8MahcnlHCgVcZ9sjGUkbKhawM gbJpd23WaExZOP1Ti/OKq9370BfxOB3qhyEkZv8/1303K+YV6CjNA890GPAu5YrCk1ru SdjdU8K5Mqan+6/oPhp8bikXzRBUD4jYOB+s64HfJZ4/rj6rvA14wsp6pl6ryWGQnKjq QGta61m5R+0bhL/tXTqeUDZToxYwwuCaKuqsQsaA4sXi19IaYJll8ih08mbffuU0Xa4L YtfA== X-Gm-Message-State: AJcUuke3Jyz6kbkLdg9sVceNIcKYBjmpAFE5eUDDpVeIx9qjo8YrXaS7 w4w5VS6Fd7zRS/67aAzenz/OCnhcNlufFYAcLFNvEw== X-Google-Smtp-Source: ALg8bN5WYRLG2Kayvw3MZ3PyBfR/95DDmgKq/3NizpHMdNYGRzXTvmJj87mMDeGUO5qoEzBdrVvn9YSSeQl7RvBltL8= X-Received: by 2002:a19:ca51:: with SMTP id h17mr620326lfj.126.1547508741190; Mon, 14 Jan 2019 15:32:21 -0800 (PST) MIME-Version: 1.0 References: <20190114.181030.1714833278513265488.mbj@tail-f.com> <9292f38a-1f09-d738-6d4c-0645d78f86d5@cisco.com> <20190114.210135.1957093582321067772.mbj@tail-f.com> In-Reply-To: From: Andy Bierman Date: Mon, 14 Jan 2019 15:32:10 -0800 Message-ID: To: Kent Watsen Cc: Martin Bjorklund , "rwilton@cisco.com" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ce6f49057f737464" Archived-At: Subject: Re: [netmod] yang-next meeting at IETF 104? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 23:32:29 -0000 --000000000000ce6f49057f737464 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 14, 2019 at 2:27 PM Kent Watsen wrote: > >> PS: I've been too busy to setup a virtual meeting for us to finish the > >> review of the YANG-next items in the GitHub tracker. But things are > >> just beginning to free up a little for me now. Would folks like to > >> have a meeting before 104 to finish that review? > > > > I think that's what the side meeting would do - review the current > > items to see what makes sense. > > Sure, but perhaps the in-person time would be better spent analyzing the > results of the reviews? Recall that we're trying to score each item on > three axis: importance, complexity, backward-compatibility. > > I agree with this approach. It is too easy to get bogged down on how a solution might work (or worse, let's compare 2 or 3 different solutions right now) and never finish the issue list. There are spot solutions in progress (e.g., on-change notification, yang-data) that might be much better handled with robust generalized solutions in YANG. I have some concern that a patchwork of optional extensions is worse for end-users in the long-term, than a new YANG language version. Current results here: > https://github.com/netmod-wg/yang-next/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc > . > > At the rate we were going (about 40% done), I imagine it taking 2-4 hours > to score the remaining issues. This may not be an issue if we can meet > multiple times during the week but, if time is tight, I'd rather have this > part done before we meet. > > Kent // contributor > > > Andy --000000000000ce6f49057f737464 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 14, 2019 at 2:27 PM Kent Watsen <kwatsen@juniper.net> wrote:
>> PS: I've been = too busy to setup a virtual meeting for us to finish the
>> review of the YANG-next items in the GitHub tracker.=C2=A0 But thi= ngs are
>> just beginning to free up a little for me now.=C2=A0 Would folks l= ike to
>> have a meeting before 104 to finish that review?
>
> I think that's what the side meeting would do - review the current=
> items to see what makes sense.

Sure, but perhaps the in-person time would be better spent analyzing the re= sults of the reviews?=C2=A0 Recall that we're trying to score each item= on three axis: importance, complexity, backward-compatibility.


I agree with this approach.=C2=A0 It i= s too easy to get
bogged down on how a solution might work (or wo= rse, let's compare
2 or 3 different solutions right now) and = never finish the issue list.

There are spot soluti= ons in progress (e.g., on-change notification,=C2=A0=C2=A0yang-data)
<= div>that might be much better handled with robust generalized solutions in = YANG.
I have some concern that a patchwork of optional extensions= is worse for end-users
in the long-term, than a new YANG languag= e version.


Current results here:=C2=A0 https://github.com/netmod-wg/yang-next/issues?q=3Dis%3Aiss= ue+is%3Aopen+sort%3Acreated-asc.

At the rate we were going (about 40% done), I imagine it taking 2-4 hours t= o score the remaining issues.=C2=A0 This may not be an issue if we can meet= multiple times during the week but, if time is tight, I'd rather have = this part done before we meet.

Kent // contributor




Andy
=C2=A0
--000000000000ce6f49057f737464-- From nobody Tue Jan 15 00:23:48 2019 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 7A655130E09 for ; Tue, 15 Jan 2019 00:23:46 -0800 (PST) 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 l0Q7MrAV_dSc for ; Tue, 15 Jan 2019 00:23:44 -0800 (PST) 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 3D60D130DDA for ; Tue, 15 Jan 2019 00:23:44 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 860FC6295B for ; Tue, 15 Jan 2019 09:23:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1547540622; bh=7tLpCzX8/L5UvjVq3Q6MAh6kIjsTsojTigbRHf0Z1ZI=; h=From:To:Date; b=HgGM1a5e/H97Ij0mULHNP1AbXWRH3FshDF/EbIjrqqj9rj4IMpK15j0RTUVfHnmcx GrtGETdBjzJOJoPn7NVcfbtnMIyAq3xWzTjPj/ILUACJ4Do6g9UKXTKMdL5mjxeDkf XthlkmJcpiaapRqqJiE9xPmEh+xVmQEBoWdg4pMc= Message-ID: From: Ladislav Lhotka To: netmod@ietf.org Date: Tue, 15 Jan 2019 09:23:42 +0100 In-Reply-To: References: Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.4 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-next meeting at IETF 104? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 08:23:47 -0000 On Mon, 2019-01-14 at 09:07 -0800, Andy Bierman wrote: > Hi, > > Is there any interest in 1 or more side meetings at the next IETF to > discuss the yang-next issue list, towards the goal of determining the > problem space in scope for YANG 1.2? Yes, I would be interested. I have no preferences in terms of timing. Lada > > Those of us who would need to make travel plans would appreciate it > if meetings like this were scheduled ASAP instead of ALAP ;-) > > > Andy > > _______________________________________________ > 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 Jan 15 12:28:52 2019 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 195BB1295D8 for ; Tue, 15 Jan 2019 12:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.643 X-Spam-Level: X-Spam-Status: No, score=-14.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 UtuIo0OYNAxF for ; Tue, 15 Jan 2019 12:28:47 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C101294D0 for ; Tue, 15 Jan 2019 12:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1996; q=dns/txt; s=iport; t=1547584127; x=1548793727; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HCJO0OVkioj4E5LWUqO15zLpzEnofg+yCjWDwZ1uIJY=; b=NvbKBpnIrsPxRZZEkyHQMRYrUirQcB4KMWfgwc6g6J+dKkzPrx8108TB MYHnxY8hrtsokFF2cPiULkVQu8oiUj8d8vzJpkmYe4cHCJ2w+q+HsWlCy EeLDunUnEmbp8SxpkTh+Czvh7CCqdlS5goqRhgmCdSWLjYUnVjsMyG8Kq s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACWQT5c/5JdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmgQInCoN3iBqLcoFoJZd8gXsLAQE?= =?us-ascii?q?YDQeDekYCF4IrIjQJDQEDAQECAQECbRwMhUsBAQMBAQEhEToLEAIBCA4MAiY?= =?us-ascii?q?CAgIlCxUQAgQBDQWDIgGBeQgPrGOBL4VChGgFgQuLNBeBQD+BOAwTgkyBQYF?= =?us-ascii?q?dAQECGIFHF4JyMYImAqIFCQKHHoptGJIAiXiFEYtAAhEUgScfOIFWcBU7KgG?= =?us-ascii?q?CQYIzg1aFFIU/coEoiGYBgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.56,483,1539648000"; d="scan'208";a="225877018" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2019 20:28:46 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x0FKSkO8001977 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Jan 2019 20:28:46 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 15 Jan 2019 14:28:45 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Tue, 15 Jan 2019 14:28:45 -0600 From: "Reshad Rahman (rrahman)" To: Kent Watsen , Martin Bjorklund CC: "netmod@ietf.org" Thread-Topic: [netmod] yang-next meeting at IETF 104? Thread-Index: AQHUrCuvYp1ErZRJck2GnO0IAz2VAKWvZFgAgAACgoCAACizgIAABJiAgAAorwCAAR1ogA== Date: Tue, 15 Jan 2019 20:28:45 +0000 Message-ID: <19833711-114D-458E-A36D-15105C1DDB17@cisco.com> References: <20190114.181030.1714833278513265488.mbj@tail-f.com> <9292f38a-1f09-d738-6d4c-0645d78f86d5@cisco.com> <20190114.210135.1957093582321067772.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/10.10.5.181209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.39] Content-Type: text/plain; charset="utf-8" Content-ID: <6BE9A820A094D64BA90A29B3379CAA07@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [netmod] yang-next meeting at IETF 104? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 20:28:50 -0000 SSBhbSBpbnRlcmVzdGVkIGluIGF0dGVuZGluZyB0aGUgdmlydHVhbCBtZWV0aW5nKHMpIGFuZCB0 aGUgaW4tcGVyc29uIG1lZXRpbmcgaW4gUHJhZ3VlIChNb25kYXktVGh1cnNkYXkgcHJlZmVyYWJs eSkuDQoNCu+7v09uIDIwMTktMDEtMTQsIDU6MjcgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEtl bnQgV2F0c2VuIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGt3YXRzZW5A anVuaXBlci5uZXQ+IHdyb3RlOg0KDQogICAgPj4gUFM6IEkndmUgYmVlbiB0b28gYnVzeSB0byBz ZXR1cCBhIHZpcnR1YWwgbWVldGluZyBmb3IgdXMgdG8gZmluaXNoIHRoZQ0KICAgID4+IHJldmll dyBvZiB0aGUgWUFORy1uZXh0IGl0ZW1zIGluIHRoZSBHaXRIdWIgdHJhY2tlci4gIEJ1dCB0aGlu Z3MgYXJlDQogICAgPj4ganVzdCBiZWdpbm5pbmcgdG8gZnJlZSB1cCBhIGxpdHRsZSBmb3IgbWUg bm93LiAgV291bGQgZm9sa3MgbGlrZSB0bw0KICAgID4+IGhhdmUgYSBtZWV0aW5nIGJlZm9yZSAx MDQgdG8gZmluaXNoIHRoYXQgcmV2aWV3Pw0KICAgID4NCiAgICA+IEkgdGhpbmsgdGhhdCdzIHdo YXQgdGhlIHNpZGUgbWVldGluZyB3b3VsZCBkbyAtIHJldmlldyB0aGUgY3VycmVudA0KICAgID4g aXRlbXMgdG8gc2VlIHdoYXQgbWFrZXMgc2Vuc2UuDQogICAgDQogICAgU3VyZSwgYnV0IHBlcmhh cHMgdGhlIGluLXBlcnNvbiB0aW1lIHdvdWxkIGJlIGJldHRlciBzcGVudCBhbmFseXppbmcgdGhl IHJlc3VsdHMgb2YgdGhlIHJldmlld3M/ICBSZWNhbGwgdGhhdCB3ZSdyZSB0cnlpbmcgdG8gc2Nv cmUgZWFjaCBpdGVtIG9uIHRocmVlIGF4aXM6IGltcG9ydGFuY2UsIGNvbXBsZXhpdHksIGJhY2t3 YXJkLWNvbXBhdGliaWxpdHkuDQogICAgDQogICAgQ3VycmVudCByZXN1bHRzIGhlcmU6ICBodHRw czovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL3lhbmctbmV4dC9pc3N1ZXM/cT1pcyUzQWlzc3VlK2lz JTNBb3Blbitzb3J0JTNBY3JlYXRlZC1hc2MuDQogICAgDQogICAgQXQgdGhlIHJhdGUgd2Ugd2Vy ZSBnb2luZyAoYWJvdXQgNDAlIGRvbmUpLCBJIGltYWdpbmUgaXQgdGFraW5nIDItNCBob3VycyB0 byBzY29yZSB0aGUgcmVtYWluaW5nIGlzc3Vlcy4gIFRoaXMgbWF5IG5vdCBiZSBhbiBpc3N1ZSBp ZiB3ZSBjYW4gbWVldCBtdWx0aXBsZSB0aW1lcyBkdXJpbmcgdGhlIHdlZWsgYnV0LCBpZiB0aW1l IGlzIHRpZ2h0LCBJJ2QgcmF0aGVyIGhhdmUgdGhpcyBwYXJ0IGRvbmUgYmVmb3JlIHdlIG1lZXQu DQogICAgDQogICAgS2VudCAvLyBjb250cmlidXRvcg0KICAgIA0KICAgIA0KICAgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbmV0bW9kIG1haWxp bmcgbGlzdA0KICAgIG5ldG1vZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgDQoNCg== From nobody Wed Jan 16 02:17:17 2019 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 5C47E130DEC for ; Wed, 16 Jan 2019 02:17:15 -0800 (PST) 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 fEmgWfgZkrhP for ; Wed, 16 Jan 2019 02:17:09 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E5E01130FBA for ; Wed, 16 Jan 2019 02:17:08 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CB97BB94A2EA2A96CDE9 for ; Wed, 16 Jan 2019 10:17:05 +0000 (GMT) Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 16 Jan 2019 10:17:05 +0000 Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0415.000; Wed, 16 Jan 2019 18:16:55 +0800 From: Rohit R Ranade To: "netmod@ietf.org" Thread-Topic: NACM interaction for Schema Mount Thread-Index: AdStfcvILhOTH9zzQSO8JfdYi2weUA== Date: Wed, 16 Jan 2019 10:16:55 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCC89D5@dggeml530-mbs.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_991B70D8B4112A4699D5C00DDBBF878A6BCC89D5dggeml530mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] NACM interaction for Schema Mount X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 10:17:16 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A6BCC89D5dggeml530mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Consider that we have a physical device, where a LNE (say "lne1" ) has been= created. This LNE will be mounting some modules. Note: For brevity sake, I have not included the prefix for each node in the= xpaths mentioned below. Consider the following scenario : 1. NACM module exists in the same level as the LNE Module, and it has= a rule to 'permit' create operation on /logical-network-elements/logical-n= etwork-element/root/interfaces path on group 'g1'. 2. NACM module also exists 'mounted' under the LNE "lne1" instance, a= nd it has a rule to 'deny' create operation on /interfaces path on group 'g= 1'. The question arises, when an create operation is sent on the = /logical-network-elements/logical-network-element/root/interfaces path, whi= ch rule is matched first ? (consider that user belongs to group 'g1' ) My thought is as below: 1. As per NACM rules, when the physical device rules are checked , we= arrive at a result to permit/deny. 2. So there is no chance to check the rules under the mount-point at = all. Hence there is no point in mounting a NACM module at all. Any other thoughts ? With Regards, Rohit --_000_991B70D8B4112A4699D5C00DDBBF878A6BCC89D5dggeml530mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Consider that we have a physica= l device, where a LNE (say “lne1” ) has been created. This LNE = will be mounting some modules.

 

Note: For brevity sake, I have = not included the prefix for each node in the xpaths mentioned below.

Consider the following scenario= :

1= .   &= nbsp;   NACM module exists in t= he same level as the LNE Module, and it has a rule to ‘permit’ = create operation on /logical-network-elements/logical-network-element/root/interfaces pa= th on group ‘g1’.

2= .   &= nbsp;   NACM module also exists= ‘mounted’ under the LNE “lne1” instance, and it ha= s a rule to ‘deny’ create operation on /interfaces path on group ‘g1’.

 

The question arises, when an &l= t;edit-config> create operation is sent on the /logical-network-elements/logical-network-element/root/interfaces pa= th, which rule is matched first ?  (consider that user belongs to grou= p ‘g1’ )

My thought is as below:

1= .   &= nbsp;   As per NACM rules, when= the physical device rules are checked , we arrive at a result to permit/de= ny.

2= .   &= nbsp;   So there is no chance t= o check the rules under the mount-point at all. Hence there is no point in = mounting a NACM module at all.

 

Any other thoughts ?=

 

With Regards,=

Rohit

--_000_991B70D8B4112A4699D5C00DDBBF878A6BCC89D5dggeml530mbschi_-- From nobody Wed Jan 16 19:42:19 2019 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 71232130F4C for ; Wed, 16 Jan 2019 19:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7LOxjrp0LyXA for ; Wed, 16 Jan 2019 19:42:16 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 B619C12785F for ; Wed, 16 Jan 2019 19:42:16 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BBA70C83594C0ABC675C; Thu, 17 Jan 2019 03:42:13 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 17 Jan 2019 03:42:13 +0000 Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0415.000; Thu, 17 Jan 2019 11:42:04 +0800 From: Rohit R Ranade To: Martin Bjorklund CC: "lhotka@nic.cz" , "netmod@ietf.org" Thread-Topic: Schema Mount Yang Library Update Thread-Index: AdSeYUFYxAmOUSMrRlSaqc+d9z9IXANaVz1A///4dgD/+2IUUA== Date: Thu, 17 Jan 2019 03:42:03 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCC954E@dggeml530-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6BCC5C7C@dggeml530-mbs.china.huawei.com> <20190114.140604.503517025389060984.mbj@tail-f.com> In-Reply-To: <20190114.140604.503517025389060984.mbj@tail-f.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Schema Mount Yang Library Update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 03:42:19 -0000 Hi Martin, If we use separate YLs for shared-schema, then during YL update there may b= e a small time gap, where-in all the YLs may not have generated the same co= ntent-id, violating one of the constraints for the shared-schema mount-poin= t.=20 On a separate note, a mount-point is mentioned as shared-schema, so that th= e Client can leverage this information to store the schema only once and us= e it for parsing the data for all mount-point instances. Is there any other= reason ? With Regards, Rohit -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: 14 January 2019 18:36 To: Rohit R Ranade Cc: lhotka@nic.cz; netmod@ietf.org Subject: Re: Schema Mount Yang Library Update Hi, I think the only reasonable answer is that this behavior must not be depend= ent on your implementation strategy so the answer must be the same if you c= hoose to use a shared YL or separate YLs. Hence, if a mount point's YL cha= nges, the notif is sent from that instance. /martin Rohit R Ranade wrote: > Hi Authors, >=20 > Any suggestions regarding the question in the below mail ? >=20 > With Regards, > Rohit >=20 > From: Rohit R Ranade > Sent: 28 December 2018 09:37 > To: netmod@ietf.org > Subject: Schema Mount Yang Library Update >=20 > Hi All, >=20 > For the shared-schema type, the draft mentions "all instances of the=20 > same mount point MUST have the same YANG library content identifier". >=20 > I think to achieve above condition, most vendors will plan to have=20 > only one YANG library instance for that mount-point. >=20 > If use multiple instances for Yang library, it is possible that the=20 > algorithm may generate a new content identifier for same data as per=20 > below statement in Yang library 1.1 draft: >=20 > "There is no requirement that the same information always results in=20 > the same "content-id" value." >=20 >=20 > If use single instance of Yang library, when a YANG library update=20 > happens, for which mount-point instance should a YANG library update=20 > notification be sent ? > What is the guideline for the implementers of this draft regarding=20 > this point? >=20 > With Regards, > Rohit From nobody Wed Jan 16 22:10:50 2019 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 222C7126DBF for ; Wed, 16 Jan 2019 22:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=CLfFBtqD; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Jo7rtKds 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 YDpbolJ_fO9D for ; Wed, 16 Jan 2019 22:10:46 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 68283126CB6 for ; Wed, 16 Jan 2019 22:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1547705443; x=1550297443; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding: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=+UTN4DVK4d4XpM+rrsVJy2zXzKVZM2XKpETYi2L5Ryw=; b=CLfFBtqD5jMcZxtmdNa7mhhDDmeIo8JbtC1yP9VRHwwu8S/M4x3INvSLndeYXb/p H79jy1jPi+SdY0y2fykLeXHJ3OqbF/y+5k7kDyjJjM1atYs2DvsiG2eiAgbk6+IY AjWA5Fz8zdtT+f2f0IERzekqE+Jdhjuqo14gF++XoHY=; X-AuditID: c1b4fb30-fabff7000000355c-8d-5c401c63c6e2 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CD.E9.13660.36C104C5; Thu, 17 Jan 2019 07:10:43 +0100 (CET) Received: from ESESBMR501.ericsson.se (153.88.183.129) by ESESSMB501.ericsson.se (153.88.183.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 17 Jan 2019 07:10:42 +0100 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 17 Jan 2019 07:10:41 +0100 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 17 Jan 2019 07:10:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+UTN4DVK4d4XpM+rrsVJy2zXzKVZM2XKpETYi2L5Ryw=; b=Jo7rtKds4HdjKf8U/X413OYSCMr8utJ3KV2lzhaJL4SIEc82JVl0uRs1uxR70M3kSzoVO1jDUSCoc6XYl9WIT3yIVy+epKUFrWxdCv9NeqUbzy9SUA/Ogi302uXy8hS8+D0AVO57EdrFZOexw/6cpOgo0bYSa5mhL5MBJ3gOsKw= Received: from VI1PR07MB4192.eurprd07.prod.outlook.com (20.176.6.29) by VI1PR07MB5520.eurprd07.prod.outlook.com (20.178.14.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.18; Thu, 17 Jan 2019 06:10:41 +0000 Received: from VI1PR07MB4192.eurprd07.prod.outlook.com ([fe80::108b:2fd5:83ad:f83b]) by VI1PR07MB4192.eurprd07.prod.outlook.com ([fe80::108b:2fd5:83ad:f83b%5]) with mapi id 15.20.1537.018; Thu, 17 Jan 2019 06:10:40 +0000 From: Hongji Zhao To: "netmod@ietf.org" Thread-Topic: [netmod] Question about if-feature Thread-Index: AdSuKghHLJLy/pvFSW+ohtziVoMRjg== Date: Thu, 17 Jan 2019 06:10:40 +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=hongji.zhao@ericsson.com; x-originating-ip: [106.38.5.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB5520; 6:heN2xrPQMqmNKe0EYi3KoFPyR7nxU3p1W8EUiIC+guUdATe021n3WGZpKM336SyTLRaP6rCNzTzBC1+dvYduCj0Hep5PSeIhGTiyM3amTj4DpTRp/blDI0VSpwiDTpTRwFReh6kkGuS8sGRWKGEtrxUeyZvkxmaqRr+2qKAFqORQm8ZVKZsBuT2T3m99NVXtyVt2Fy6PNPC+kRWx93Mmbv4uCyqs5s4Nw9/EIvGEG8izxG1o0lgyZDS006Z109OzMvJ961cxL2vIzDVLQTAFjMDI1RmsgjEzdB7rejP3PpCPQ2shRZXYfD8t0wIKKPist4ZxK8eHnXVL4izdJTe9RiDbGDhEfon2rESdTCt9mthRp8PWigbi+dfXSQltg5LPZDBS3y6ezkOdjbQ1envB/MFBTMM5nBwr4kb7IpCDdP+S7Cm2/xMwXq6OuAwSLFpbHwc7jBbOaLaFe/y7P0J8vQ==; 5:B081DeHUtt9YCJHCRY7a9pcjIHsBgsf0Wohx8s/NcVf132YUqZk5NUAdZDyGngcGEncMViQXS5j/KPW1R25RwDA4wDv3lSOo/OaZcVpo10uU51q9BmL43DDhWH6F0/HCQIFCWd4hc/cGCJ6iTxyc1PeWb8vKoBhomr/xS8/0VEqDDlnUWXp7LTP8ONnpDyq/iLUxGmSNsBodDpRvOEP5mQ==; 7:Xmq6y6WxnnweTH/39X8Z2TXKeKsUp08F0CTliaZerwR13BpygzYupfwvek5sYinGGfgCmMQWjmLkbDr20r3AEdtbzxYyx1S5GJ7uOi60fbyqXW9MHp0Nhnkp3hHm0P+J/OXUkvaWSVQ0hxvbGVC2Dw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 14280a10-1244-44a7-fc8d-08d67c4281f7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB5520; x-ms-traffictypediagnostic: VI1PR07MB5520: x-microsoft-antispam-prvs: x-forefront-prvs: 0920602B08 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(136003)(396003)(346002)(39860400002)(199004)(189003)(68736007)(256004)(9326002)(33656002)(2906002)(25786009)(2351001)(8936002)(478600001)(3846002)(790700001)(6116002)(106356001)(26005)(186003)(105586002)(14454004)(5660300001)(53936002)(55016002)(486006)(9686003)(7696005)(6436002)(5640700003)(86362001)(2501003)(102836004)(71190400001)(74316002)(66066001)(316002)(71200400001)(6506007)(97736004)(8676002)(99286004)(54896002)(6306002)(53376002)(1730700003)(81166006)(81156014)(44832011)(7736002)(6916009)(476003)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5520; H:VI1PR07MB4192.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6YVzpsoA43AVLDg10D/1Yfecg+ZuJW5UlXa9G466b4BEBo+Akr8s78y9SNlzw5UA7V9Y7EGUa02kwwTdodl9DoTOOyiI2EF5Hl1457qnuVpYtP1bYd3jY0xdB+NwZvMN/42F1LC+iQp7ZZy3SqzKiOdBqWXECltSaeUPsA8FoJ9+BEJkCBelTeD6KqPloEJU85Ii+VYOivdOk6A5R+EhhPvB4FB+uAxZbjMOM3bPNuOP8BUTnos0Y7O7xyo7Y5IvKTnLbckccikuTS4kHP/co4w0cG9+6C4YawYPJH8S5xHOY6BfvHYptYCgYUB//4PMGingPmmU0y/ll2ZEHJpPEqKF8egmQuH/kejjjCkwivKfehnEDqd4hhtKCp21fFVK4g7V4twm6epIbZKN3zBkjvtLOtQAdtMDtqZAuwNWOyA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB419236918BC951A290365C1396830VI1PR07MB4192eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 14280a10-1244-44a7-fc8d-08d67c4281f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2019 06:10:40.7901 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5520 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsUyM2J7uW6yjEOMweI5uhbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoEro//1bpaCFeEVW//3szYwfgnpYuTkkBAwkdh78jlLFyMXh5DA EUaJ/5+WsUI43xglzi1qZoRzDja8YoJwljBJ/H14jA3EYRGYwCwxY+EldojMRCaJa2sPQfU8 YpRYMPsdI8gaNgEdic7urcwgtoiAusTMnevZQGxhAW2Jzvf7mSDiBhJHexewQth6EjvONrCD 2CwCqhLvL9wAi/MKxEhs2jYHzGYUEJP4fmoNWC+zgLjErSfzmSBeEpBYsuc8M4QtKvHy8T+o +miJdUcb2SHichIv1k2GqpGVuDS/G+xoCYEmdok355+wQSR0JT5MnQpV5Csxu2MplH2BUeLY pAQIW0ti4ZXvLBB2tsSe+U+hamQkjpzcyAYx9CqrxOY9Z8CKhARSJZavbWWEuWJV70OWCYw6 s5A8MYuRA8jOl7jxUWwW2M+CEidnPmGBCGtKrN+lD1GtKDGl+yE7hK0h0TpnLjuy+AJG9lWM osWpxUm56UZGeqlFmcnFxfl5enmpJZsYgenm4JbfBjsYXz53PMQowMGoxMN7QMghRog1say4 MvcQowQHs5II788ldjFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEef8ICcYICaQnlqRmp6YWpBbB ZJk4OKUaGCet0G6P51GMa18pr/fhi+c7ucdHik+0PeLL/HpDpqzrsHj2miD9/AiR9R+dTC91 JEhVfU3Q+bbnmZGeZ8GbJY2yh25dCOVniA1fEpT56oLQwrc5VReCn6986nqfpzZrY9orz5cc sb+5j7i4HW77kP/h4lJGwc3W0zb+tondfyzvg/cd9Yz+JUosxRmJhlrMRcWJAIK2LRozAwAA Archived-At: Subject: [netmod] Question about if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 06:10:48 -0000 --_000_VI1PR07MB419236918BC951A290365C1396830VI1PR07MB4192eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgdGhlIHVzYWdlIG9mIGltcG9ydC4NCklu IHRoZSB0ZXN0LWltcG9ydCBtb2R1bGUgSSB3b3VsZCBsaWtlIHRvIG1ha2Ugc3VyZSBpbnRlcmZh Y2UgbmFtZSBub3QgaW4gdGhlIGludGVyZmFjZSBsaXN0IG9mIHBpbS1iYXNlLg0KU28gSSBpbXBv cnQgaWV0Zi1waW0tYmFzZSBtb2R1bGUgYW5kIGRlc2lnbiB0aGUgbXVzdCBzdGF0ZW1lbnQuDQoN Ck15IHF1ZXN0aW9uIGlzLCBpZiB0aGUgZGV2aWNlIGRvZXNuJ3Qgc3VwcG9ydCBQSU0sIHdpbGwg aXQgcmFpc2UgZXJyb3Igd2hlbiAiaW1wb3J0IGlldGYtcGltLWJhc2UiPw0KDQpUaGFua3MgYSBs b3QhDQoNCm1vZHVsZSB0ZXN0LWltcG9ydCB7DQpuYW1lc3BhY2UgImh0dHA6Ly9leGFtcGxlLmNv bS9ucy90ZXN0IjsNCnByZWZpeCB0ZjsNCiBpbXBvcnQgaWV0Zi1yb3V0aW5nIHsNCiAgcHJlZml4 ICJydCI7DQp9DQoNCmltcG9ydCBpZXRmLWludGVyZmFjZXMgew0KICBwcmVmaXggImlmIjsNCn0N Cg0KaW1wb3J0IGlldGYtcGltLWJhc2Ugew0KICBwcmVmaXggInBpbS1iYXNlIjsNCn0NCiBjb250 YWluZXIgaW50ZXJmYWNlcyB7DQogIGxpc3QgaW50ZXJmYWNlIHsNCiAgIGtleSAibmFtZSI7DQog ICBsZWFmIG5hbWUgew0KICAgIHR5cGUgaWY6aW50ZXJmYWNlLXJlZjsNCg0KICAgIG11c3QgImN1 cnJlbnQoKSAhPSAvcnQ6cm91dGluZy9ydDpjb250cm9sLXBsYW5lLXByb3RvY29scy9waW0tYmFz ZTpwaW0vcGltLWJhc2U6aW50ZXJmYWNlcy9waW0tYmFzZTppbnRlcmZhY2UvcGltLWJhc2U6bmFt ZSI7DQoNCiAgIH0NCiAgfQ0KfQ0KfQ0KDQptb2R1bGU6IGlldGYtcGltLWJhc2UNCiAgYXVnbWVu dCAvcnQ6cm91dGluZy9ydDpjb250cm9sLXBsYW5lLXByb3RvY29sczoNCiAgICArLS1ydyBwaW0h DQogICAgICAgICAgICAgICAgICAgKy0tcncgZ3JhY2VmdWwtcmVzdGFydA0KICAgICAgIHwgICst LXJ3IGVuYWJsZWQ/ICAgIGJvb2xlYW4NCiAgICAgICB8ICArLS1ydyBkdXJhdGlvbj8gICB1aW50 MTYNCiAgICAgICArLS1ydyBhZGRyZXNzLWZhbWlseSogW2FkZHJlc3MtZmFtaWx5XQ0KICAgICAg IHwgICstLXJ3IGFkZHJlc3MtZmFtaWx5ICAgICAgICBpZGVudGl0eXJlZg0KICAgICAgIHwgICst LXJ3IGdyYWNlZnVsLXJlc3RhcnQNCiAgICAgICAgICAgICAgICAgICAuLi4NCiAgICAgICAgICAg ICAgICAgICArLS1ydyBpbnRlcmZhY2VzDQogICAgICAgICAgKy0tcncgaW50ZXJmYWNlKiBbbmFt ZV0NCiAgICAgICAgICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICBpZjppbnRlcmZhY2UtcmVm DQogICAgICAgICAgICAgKy0tcncgYWRkcmVzcy1mYW1pbHkqIFthZGRyZXNzLWZhbWlseV0NCg0K DQoNCg0KDQpCUi9Ib25namkNCui1teWuj+WQiQ0KDQo= --_000_VI1PR07MB419236918BC951A290365C1396830VI1PR07MB4192eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgYSBxdWVzdGlvbiBhYm91dCB0aGUgdXNhZ2Ug b2YgaW1wb3J0LiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu IHRoZSB0ZXN0LWltcG9ydCBtb2R1bGUgSSB3b3VsZCBsaWtlIHRvIG1ha2Ugc3VyZSBpbnRlcmZh Y2UgbmFtZSBub3QgaW4gdGhlIGludGVyZmFjZSBsaXN0IG9mIHBpbS1iYXNlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gSSBpbXBvcnQgaWV0Zi1waW0tYmFzZSBtb2R1 bGUgYW5kIGRlc2lnbiB0aGUgbXVzdCBzdGF0ZW1lbnQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TXkgcXVlc3Rpb24gaXMsIGlmIHRoZSBkZXZpY2UgZG9lc24ndCBzdXBwb3J0IFBJTSwgd2ls bCBpdCByYWlzZSBlcnJvciB3aGVuICZxdW90O2ltcG9ydCBpZXRmLXBpbS1iYXNlJnF1b3Q7PyZu YnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBhIGxvdCE8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+bW9kdWxlIHRlc3QtaW1wb3J0IHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPm5hbWVzcGFjZSAmcXVvdDtodHRwOi8vZXhhbXBsZS5jb20vbnMvdGVzdCZx dW90Ozs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnByZWZpeCB0Zjs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7aW1wb3J0IGlldGYtcm91dGluZyB7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgcHJlZml4ICZxdW90O3J0JnF1b3Q7OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fSZuYnNwOyA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+aW1wb3J0IGlldGYtaW50ZXJmYWNlcyB7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgcHJlZml4ICZxdW90O2lmJnF1b3Q7OzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbXBvcnQg aWV0Zi1waW0tYmFzZSB7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgcHJlZml4ICZxdW90O3BpbS1iYXNlJnF1b3Q7OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+fTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtjb250YWluZXIgaW50ZXJmYWNl cyB7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgbGlzdCBpbnRl cmZhY2UgezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 IGtleSAmcXVvdDtuYW1lJnF1b3Q7OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7IGxlYWYgbmFtZSB7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBpZjppbnRlcmZhY2UtcmVmOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgbXVzdCAmcXVvdDtjdXJyZW50KCkg IT0gL3J0OnJvdXRpbmcvcnQ6Y29udHJvbC1wbGFuZS1wcm90b2NvbHMvcGltLWJhc2U6cGltL3Bp bS1iYXNlOmludGVyZmFjZXMvcGltLWJhc2U6aW50ZXJmYWNlL3BpbS1iYXNlOm5hbWUmcXVvdDs7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDt9 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7fTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPn08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bW9kdWxlOiBpZXRmLXBp bS1iYXNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgYXVnbWVu dCAvcnQ6cm91dGluZy9ydDpjb250cm9sLXBsYW5lLXByb3RvY29sczo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgcGltITxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAmIzQzOy0tcncgZ3JhY2VmdWwtcmVzdGFydDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGVuYWJsZWQ/Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGJvb2xlYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBkdXJhdGlvbj8mbmJz cDsmbmJzcDsgdWludDE2PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGFkZHJlc3MtZmFtaWx5 KiBbYWRkcmVzcy1mYW1pbHldPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgYWRk cmVzcy1mYW1pbHkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWRl bnRpdHlyZWY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBncmFjZWZ1bC1yZXN0 YXJ0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyAmIzQzOy0tcncgaW50ZXJmYWNlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7LS1ydyBpbnRlcmZhY2UqIFtuYW1lXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBuYW1lJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGlmOmludGVyZmFjZS1yZWY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYWRkcmVzcy1mYW1pbHkqIFthZGRyZXNzLWZh bWlseV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CUi9Ib25namk8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1m YW1pbHk6U2ltU3VuIj7otbXlro/lkIk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_VI1PR07MB419236918BC951A290365C1396830VI1PR07MB4192eurp_-- From nobody Thu Jan 24 02:15:43 2019 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 D40991310E8 for ; Thu, 24 Jan 2019 02:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dtu.dk 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 dnuU_H2CYuxA for ; Thu, 24 Jan 2019 02:15:38 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70081.outbound.protection.outlook.com [40.107.7.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 E208A1310E7 for ; Thu, 24 Jan 2019 02:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dtu.dk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R4EoZ8IFFLDDylmLqpVBwSrihfKQMKao76/5cvk1Xd4=; b=kPnN9Q2X2BcuGujcOPGm5jndnEptPszIV/hG8yB5FAt8tIzU+lalys9wNZ+57Djtufy/qYt6d3YMg6ug1GAk22n0UIJ7Rt1lJICrfALT5+EZvhfBdlpRDmEkmIw4htNO4RsGIUJmHfriMOb2mDQ0TIacVtJrW2UdC9CIv3TLGu4= Received: from AM6P192CA0108.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:8d::49) by AM0P192MB0449.EURP192.PROD.OUTLOOK.COM (2603:10a6:208:50::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.18; Thu, 24 Jan 2019 10:15:35 +0000 Received: from HE1EUR01FT010.eop-EUR01.prod.protection.outlook.com (2a01:111:f400:7e1f::208) by AM6P192CA0108.outlook.office365.com (2603:10a6:209:8d::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.16 via Frontend Transport; Thu, 24 Jan 2019 10:15:35 +0000 Authentication-Results: spf=pass (sender IP is 192.38.82.194) smtp.mailfrom=dtu.dk; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=dtu.dk; Received-SPF: Pass (protection.outlook.com: domain of dtu.dk designates 192.38.82.194 as permitted sender) receiver=protection.outlook.com; client-ip=192.38.82.194; helo=mail.win.dtu.dk; Received: from mail.win.dtu.dk (192.38.82.194) by HE1EUR01FT010.mail.protection.outlook.com (10.152.0.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1558.11 via Frontend Transport; Thu, 24 Jan 2019 10:15:34 +0000 Received: from ait-pexsrv03.win.dtu.dk (192.38.82.196) by ait-pexsrv01.win.dtu.dk (192.38.82.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 24 Jan 2019 11:15:34 +0100 Received: from ait-pexsrv03.win.dtu.dk ([192.38.82.196]) by ait-pexsrv03.win.dtu.dk ([192.38.82.196]) with mapi id 15.01.1591.012; Thu, 24 Jan 2019 11:15:34 +0100 From: Voica Maria Gavrilut To: "netmod@ietf.org" Thread-Topic: Questions about yang models Thread-Index: AQHUs82+PW/lzJ3Wg0yG0wgKTAegJA== Date: Thu, 24 Jan 2019 10:15:34 +0000 Message-ID: <00328be68942482da898ac45a2f881bc@dtu.dk> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.38.82.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:192.38.82.194; IPV:CAL; SCL:-1; CTRY:DK; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(376002)(346002)(2980300002)(189003)(199004)(46406003)(36756003)(6916009)(6116002)(3846002)(23726003)(53416004)(316002)(786003)(426003)(3480700005)(1730700003)(66066001)(8676002)(102836004)(86362001)(14444005)(33896004)(8746002)(47776003)(8936002)(246002)(7736002)(356004)(305945005)(8976002)(186003)(97756001)(26005)(336012)(7696005)(106002)(108616005)(478600001)(26826003)(24736004)(126002)(486006)(476003)(2616005)(956004)(74482002)(2501003)(2351001)(50466002)(106466001)(2906002)(5640700003)(170073001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0P192MB0449; H:mail.win.dtu.dk; FPR:; SPF:Pass; LANG:en; PTR:ait-pexsrv01.win.dtu.dk; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR01FT010; 1:1xzUQWWpsAY8k1k+YK/FSQeYmau0TPzp8xLTsGcqB4IxqsMGJ0Cg0CkoB4GrTpmOVhI8B99xfOm+LovrZxZx4Gc2u1bSqUOqsahmZaLU+O4KmhoO/6djZcB2B5kLq5HGYVmwPB1ByYGt9N9LswkzTu2fJRTRPj01CdUS3FUlRSk= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2f64ad2c-ad9c-4904-b593-08d681e4e10d X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:AM0P192MB0449; X-Microsoft-Exchange-Diagnostics: 1; AM0P192MB0449; 3:+8X+t0gbeytJBDkb7JsQab/BStfwK+9jSJIqhBLDQjrKBUS0JvAiCVNjnzw+8JZydrDuAP0ysaKl6NGEP7l78NxL/E6R+TtKZ3rEM5EDzU9XzYttItFZI1nJyYdL2rvNU80DVbDXeExjwa+7s8+oiXJVepoF7ZMc4YdvzxtHe0hxo3DcyQ1ErIpRxhXU4L2ZdpT3Dijvbc3XcnHHonRqYughsyRURx4dxfeSpHP3NeSqSHnCYCifCDTHhbiK2SrZpFJsTOAEQY6n4h883b+Kc0ARBjc6R6/x4s283d8+2NWLrC011ck6s7mLIGpS8krVKMG4vVzOlfUCKFyz2jroIhdad1rPYBGGJn6Ia5eOcGgPw7dGjBkb8HLkdYtI4EYH; 25:gOI7G8VKo3Ed1a+/sdhyXrqXC0z4vkBXFtMYUM13y4/K0C52JYeDyr3SHUD04V/lAxthhwErhZgdxEB2KtSJG1JtEOzTGFYIvD1LNRn5eQKsn7ZUJleFcLeKquotDo4SZLEfDbIsKwh+k+4lv91DNbtwrT7aNCqqhD8u4w8ixv5K21E9iaxT6dHJe6rEzijqCe0usPwD51gYc3NtqEV7SlNuIeqsOnOrrWOWlJBgLFupVbeZultQspaEBbXzlgSpRy97HiYTsHunDjlRs9pE52F7/h7poJ5daBj7ju+/3OGzBAKOS81NIRSmXarwcaFNUEVcljYLcYBHXQuUG61taQ== X-MS-TrafficTypeDiagnostic: AM0P192MB0449: X-Microsoft-Exchange-Diagnostics: 1; AM0P192MB0449; 31:5Kr+Vhh4I8hv6od5dQI0D592HnFkabcCIR3fO2vGD4L9qZIxP4HhZnXTqbt4iX9RMwNGrso19oH8L56J7dljJfilEga5g2tQndhBTPKU/ThYP4KHnboYlu6LfFdH6iA7HmnKMTgFTp+DvIodeCTpAwNtWBS7+AfBLZsD4OH7o+WG+7uDzNfhKRuQjW2bIknJFLDJ2WOji5Qqkyrm9e8CTghsoFkGTVodD3Tq+Eiu81M=; 20:CTrQC0rk41cOuZTQ4zDmwmeoFw/jbCV2m65nVLIaJVU6HoMJmFqAgdqNpsicySQCXoH5nfyGR304s7Kr4ucRSmcQEbEyG2tKNoc1rswk7uMjSPCfUDMPYgLUpHwudDvPcJU8PuZ7yhEyL/mzid2O/RMfjEYxmEzXV/gk+GDzglFe2BOQ/tn7y/+v9J0qbNoCM2itsWT94W3KEs7Q8hBFuZei755mpgx3GaU08EtVehKTI9v+4z20cSjImso44Z1C; 4:zY2m5Cb2/v07e5cxkBH5MGRJbNXEvG0/iD2Eo/J0c07tzD0uYyJsx5W58CmAgV3+G4+LheilkfKX7IvTEgGanFMqksE0y4VUKxXRM83WI4cTGIArXLDhDJKFNKW5MEnomhPhKpwaIg6MeHFKTp7CDwu39ie94u8c+uoFFCzjZXfKgQ4mqR/WEXcdTv5stSVAh2BLAO4uepdl34Kj98xJp0u8ccrIoP7Z4yreiORooStxtFooR2P1pHPz3bRm/pZijZYqkn90//gVelFQU5NLyxuenX5dT1XNn/qFXOiEJHk= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0927AA37C7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM0P192MB0449; 23:Pu8njxzbGdt9EIjoIffIBVBe9dcYw7WINv0ZTPEc9?= =?us-ascii?Q?4JndTO1iojVeoQ+i1w7IUFtdmjd+/mY/4zciGMmpkpYm+oETdffTjgvsdI6J?= =?us-ascii?Q?nXmu/UU82DMozyRYLN6+BleRMnuQwxubQW6Xq24l4hrRm0neZecJFK61FgU3?= =?us-ascii?Q?my9Mz28w2xFglxuLsHBRbUWHnAJKQf8zeEfXVDmG0SGmdAWeo0gI12tcKO1M?= =?us-ascii?Q?ky4qodDmIF9LRTNsibOOT+d9q3dMFgtofyEqwUIz8caCA5SpsShcWAsFB2Uq?= =?us-ascii?Q?EabheTk3XVkOUQGxvH44TSWiSQClMdpwT+KW0YTMF99uoCSh1d8pZmRTy2Qf?= =?us-ascii?Q?PAM1wTqqDlR/wp/MxIlICE2Tj+XuS6fcn8OurDCFUOHy5UOJbcDS1LsGqgj7?= =?us-ascii?Q?LQWVJ4cg/xztrHkQ6aq1j17XBVUb9IY/wwfPb5S3B0ce7o7BZwPIjBAPD3b7?= =?us-ascii?Q?ElDRfe2dKQK9kntXBeEXOE8PJt9oLEyxPLR7PsvvLtmTdtmRK5KNuMPwTB4K?= =?us-ascii?Q?pgcVnf3j94yyXgtiLJR1cBnehowXf9qQAFUuYBqwka0u6RiTdbIu/mmixX4l?= =?us-ascii?Q?kSJuPuqKfs5SgV6r4JlgUHBRaEH27sTOVX9hzvvZKYlSMIFkc+gFw+xey5Lw?= =?us-ascii?Q?+dNmTB3n+q8gLGNIIwscIamXCCwphIvOkjZs7TLyfNZ+4LptdS1E9fa38U5A?= =?us-ascii?Q?vEfLX+Iq0+iNR9/3t6FUfzpOW0jxhb6uvTIP8vue4cqmMvPFy6+NlOlgCEXI?= =?us-ascii?Q?OLp1KFr2ccN5e/JRDiQasD6Pk7fuenXz8BaTixEaNvISQ5e3qsCbpy/r27wl?= =?us-ascii?Q?dvQp2Yv1Q0TuRSe9g7eJ6GZBQ59DQijP96XkR7e4s0Q35rRwuSI4+ZP6dTSB?= =?us-ascii?Q?T1+44SaaE6nlyLNY3RE69Y5m+bWLQbmyUW+UgtkntQWepKjpwYiV6MCMR7YL?= =?us-ascii?Q?yghx+4iy4vJeMvNdVB6JbPCbj1vB3wnZDJC8Rx8qHJ9lvLpWZimePI9e5qqr?= =?us-ascii?Q?R92Riu5wCcrW5QEOcl8JXhRG08WXMTDm6usGUkH0d8D2leu/im4ORQ9pT1k9?= =?us-ascii?Q?84estgaO9gO0Xnes2v8xzJGtQ/jjSFdT06jDyQ5VPRwN62bkJkd5viGtXG8B?= =?us-ascii?Q?Kqo8Nwnbq0A8MIj1kEyTVpSeIIc1697zAYYiyHMFPR51KsPr+gYRNRpbllRT?= =?us-ascii?Q?BWMPYnOCVdkyOC7bmEy0BQZFSCwanNHOoLnNGkqXw2/szPXvBN4W2Cn9Qiwa?= =?us-ascii?Q?S0Sxrax1cavXWRYt14=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: ZHexClxp5MLI+rZT7DAi/JaaAibbH4oezP/yKcD3VKArRQ7gCIbFmdMIsMye9rKxuAOizjfBVlvktXKLieMpRkGh3F4bKg6jclvIwx8/xlPMaD4DmfCekcNaNWCrpyvvg/AmB1vTIkHS7O21iL8E9dONLzzf2rVJj97lA7w8dXr6mmAYoDuUAFa+NC4EcwAZHVmSb2NC98frm32E2urF7R9MeWjEJcWo8qaq2n2r7C2QAeu1D9H8zAPfGwe7ibL3iGaS5nD0e8xjJO2gxnvDQKPCn3/fOOC5hYYz4qxxsYgDeYWHUebOnfkZEkTpNPfYSg37WOd3rWc4tkro7W2+XmMU7Iy7H1ta0GxajWEf3b9bwTxgeSjsDfezqWEP0ZEaGCV3qGwIHrGF+2aNNq4lWcW0oxoce0V8xl6obH87u6o= X-Microsoft-Exchange-Diagnostics: 1; AM0P192MB0449; 6:rU/dOTiCU5++VqiMla/tH7xug6qh/E5eNf3tB5MqP6aDPp0cqTjjbGUQZvfC5aaDFuBcnIfeAb9zdI9zF9nJS8UdOdP9VqUamd1ETHjvSlP/fvWuwKaj/FZcSeqtbLlgT1Vef7FJANZow9GJLqryC1eRfo8/DVMqKAm+KJhvUYtktZ5g0xyIrl+jNtMfkkUAe/6QE2pQfWSrju8pUET49Rt6RV7TF85Z7amh7yf8qHPUvui7cfyPNTy2mit/UjVtTJYceqgzv8B2kgAG4l1bZhsxAZGJAIVwpvV+JdWABlNCY1KAiGrqzfSySfA8X7p7DNBlrt4vKbrUvXlTK5yvd55UJ5m1t43k+8V4EE83/6V/GZCHe3Lq+yO20EXBu7aWAz5LGuYxWScElZtlyqZyoezCAP19FB2CJ+PPhuj4iJKC1J1BFpLZoMjfccwCNKzNEeiogVZ5osYEdIbFo10jkA==; 5:gfF387L7IrgxoHBFPFvnuimTU0dkHdhlnLvtNx5d2YAaGTJ6INaMpXfsG+BjdYd7vT/qb3EJ6att04+TIo6J3rb2R34l/WyWi3QF6JLgldWeNmlebxxKokMSjX14hJaR7pH3Lrx1cSQ28HYBHnke73InF6QNZFvFPP2PRz4vVbN1v+jQbydhTiWjomj/p2lA38AMt/tpQOyTYFP+yZf7cA==; 7:RldPCIRhesQZq3P33O2mvDe5LyI0Uoz2U8UmfGqPUspARwDQoCQP1bBCBs2NQxHDYn8FYWidh+MM6zLPDN4++mC7tlW1GqBCQX5tDShQkFmUGa5sEytZHij0hNtp7gAKMFxoui8FihfzGYPw5L3cnw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: dtu.dk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jan 2019 10:15:34.7177 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2f64ad2c-ad9c-4904-b593-08d681e4e10d X-MS-Exchange-CrossTenant-Id: f251f123-c9ce-448e-9277-34bb285911d9 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f251f123-c9ce-448e-9277-34bb285911d9; Ip=[192.38.82.194]; Helo=[mail.win.dtu.dk] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P192MB0449 Archived-At: Subject: [netmod] Questions about yang models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 10:15:41 -0000 Hello,=20 I work now to output some configuration parameters in TSN-specific formats.= I was able to obtain IEEE 802.1Qcw compliant formats, but I cannot export = the topology or the routing in a similar manner. Could you help me please w= ith some information? 1. To describe the global topology. I found the network-topology.yang model= , but when I use the pyang tool to convert the yang model to python code I = get the following warnings and error: " network-topology.yang:288: warning: XPath for "boolean(../underlay-topology= [*]/node[./supporting-nodes/node-ref])" does not exist network-topology.yang:320: warning: XPath for "boolean(../underlay-topology= /link[./supporting-link])" does not exist network-topology.yang:322: warning: XPath for "boolean(../node[./source/sou= rce-node])" does not exist network-topology.yang:324: warning: XPath for "boolean(../node[./destinatio= n/dest-node])" does not exist network-topology.yang:326: warning: XPath for "boolean(../node/termination-= point[./source/source-tp])" does not exist network-topology.yang:328: warning: XPath for "boolean(../node/termination-= point[./destination/dest-tp])" does not exist FATAL: pyangbind cannot build module that pyang has found errors with. " There is other updated and functional version of network-topology model? I = was using both versions, from 2013-07-12 and 2013-07-15.=20 2. To describe static determined routes. For routing I could not find any m= odel for static routing, could someone help me please with a yang model tha= t could be used for such type of routing?=20 All best Voica= From nobody Thu Jan 24 02:30:34 2019 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 41A461310EB for ; Thu, 24 Jan 2019 02:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dtu.dk 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 lsOOtZVxLGH2 for ; Thu, 24 Jan 2019 02:30:27 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on061b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::61b]) (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 7726413115D for ; Thu, 24 Jan 2019 02:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dtu.dk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R4EoZ8IFFLDDylmLqpVBwSrihfKQMKao76/5cvk1Xd4=; b=RSbCW15k3aeAXMXmv6W1aIn33VJjcV6tIeLmfRa1Z/7j0upN/wOf2a0F8WgqWeW1N1wqJofcLIhBlPBVa60C5P1S3Pe4FZtdZxZXaiczWiNLXR9PgQ9XLAnkrPiOSkv9tBgb2XrVSnCHkmCZX7GrA9ztsONaso7eUFWZNtJEcVo= Received: from AM6P192CA0052.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:82::29) by HE1P192MB0235.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:104::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.29; Thu, 24 Jan 2019 10:30:24 +0000 Received: from HE1EUR01FT055.eop-EUR01.prod.protection.outlook.com (2a01:111:f400:7e1f::200) by AM6P192CA0052.outlook.office365.com (2603:10a6:209:82::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.17 via Frontend Transport; Thu, 24 Jan 2019 10:30:24 +0000 Authentication-Results: spf=pass (sender IP is 192.38.82.194) smtp.mailfrom=dtu.dk; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=dtu.dk; Received-SPF: Pass (protection.outlook.com: domain of dtu.dk designates 192.38.82.194 as permitted sender) receiver=protection.outlook.com; client-ip=192.38.82.194; helo=mail.win.dtu.dk; Received: from mail.win.dtu.dk (192.38.82.194) by HE1EUR01FT055.mail.protection.outlook.com (10.152.1.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1558.11 via Frontend Transport; Thu, 24 Jan 2019 10:30:24 +0000 Received: from ait-pexsrv05.win.dtu.dk (192.38.82.198) by ait-pexsrv01.win.dtu.dk (192.38.82.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 24 Jan 2019 11:30:23 +0100 Received: from ait-pexsrv03.win.dtu.dk (192.38.82.196) by ait-pexsrv05.win.dtu.dk (192.38.82.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 24 Jan 2019 11:30:23 +0100 Received: from ait-pexsrv03.win.dtu.dk ([192.38.82.196]) by ait-pexsrv03.win.dtu.dk ([192.38.82.196]) with mapi id 15.01.1591.012; Thu, 24 Jan 2019 11:30:23 +0100 From: Voica Maria Gavrilut To: "netmod@ietf.org" Thread-Topic: Questions about yang models Thread-Index: AQHUs8/Q4sO7Ren3g0axrY/+jr9BlQ== Date: Thu, 24 Jan 2019 10:30:23 +0000 Message-ID: <89bded91c5fa4db49c3d42a3fc4bdee8@dtu.dk> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.38.82.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:192.38.82.194; IPV:CAL; SCL:-1; CTRY:DK; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(39860400002)(396003)(2980300002)(199004)(189003)(36756003)(53416004)(33896004)(246002)(186003)(26826003)(50466002)(102836004)(2906002)(14444005)(97756001)(336012)(476003)(26005)(106466001)(956004)(2616005)(486006)(478600001)(2351001)(24736004)(126002)(108616005)(106002)(7696005)(6916009)(5640700003)(47776003)(23726003)(7736002)(316002)(786003)(426003)(356004)(74482002)(8676002)(305945005)(46406003)(2501003)(1730700003)(8746002)(6116002)(3846002)(8976002)(86362001)(3480700005)(8936002)(66066001)(170073001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P192MB0235; H:mail.win.dtu.dk; FPR:; SPF:Pass; LANG:en; PTR:ait-pexsrv01.win.dtu.dk; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR01FT055; 1:KMyGVSf6zNqismFQJ1lo1KkLXaZdOgVhBZVbYcORpxWUbtdJOxLhNQOJ5zlRRrbKtPhTvhdZzvY1S/gdrpK0Ga3aHdspMUIBUqnbPWPouaGK71RRXPClLlKaqkbvgQlbxG0kBs6XvBWDNr5h3UjA7FpczhxfmmjHM2GYx6mZJDk= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3f22edf3-ab9c-42a4-a676-08d681e6f334 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4608076)(4709027)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1P192MB0235; X-Microsoft-Exchange-Diagnostics: 1; HE1P192MB0235; 3:yR0ejHgH1+0MT4vDZN8RGGGEvXUht0mQClRZMvABXwF1FjiUJic1ll2voViRC6xileLTaYAukbghIM0EvXxcM4KZvHgcppSrfPMMSeC43+JGRxjB+RifX0ZIJ9SZhvrNLKoxYilmXKMfggw6kdu4qjjU9e+zqaXKaRtZpf8auka1B6yJCWqAkPHM3LVY0b5IOxFJJCedBjG1+4OH/zfeoZo5E7C4CEHaeNlh9N7np4jI1HN2zVm0PzvwNZKwNmjv5y5B9AUB8HVMn08ybH6/ztHCJcE63jboyXnX0avlaEwYl8HmuHtWo6F2Z8hcn4FzjmdLdz1cIzWvil8oNKWXRRce+HOOWHHfwfGLxvzOTfgL16X5uhRBFG++Ehex3ULk; 25:CIHOJOcNQIbf4Y+k9diOIzbRKFCkjoLWPJwySh8N/AWOFv45HqSjY637CACFIfzd4d8ENAsjBflBNDct5lBlv8p1UJq9HkDMPIw25nGE52qinnbIIRephDFYTd9dkSS4MKlG1hMflzPI/9viD0hF6n1KOerE23nipqTSUZ3dOSPehSonRTaWhGLvI7Hv00FwedX9XZMQRV0J9huXsORDRjUh9YJ0eY4vpAju2d1s59wGU0lgL1xWYlJl5aIBfThwfEeYVG6PfLDJJe2o2LBnQv1RkWZXISTV3g2kiuzKBUwzz1iCgUAdor+w7B6wmFnSjhoSPC6GQyIsyaxRtYPn+w== X-MS-TrafficTypeDiagnostic: HE1P192MB0235: X-Microsoft-Exchange-Diagnostics: 1; HE1P192MB0235; 31:J1iK1OaKe0eMC3kb8Y+xU3A0/saBoq4pGlxMK5uIwZswH4b6zwxOIaDpHpxJdFC2leABzypFn/b0otLO8shHY2ylDPQ/h+h3/RbH7vv31J7Cgm8dOAz9mmuYWVGhKA3LBRZi6tH7Obs5YJ+IYxlVBoNeqHvzTwdEJbaWjj+m4MTs/a/Q3yOEN/wJhbNNHKJztzGu6TQCZuu7VqUZ4edZFHjZYDUvPAHsQ1eKm1IByMQ=; 20:2ywHWcQY85sJeSwranVFGPIqWWFuQxcWLVDXUuldZD7zKtyq+CLHiaE6wc+7At/XImw3a9tEDupG6cGpF7Svnozp+HZlB3TWjdGPR+1JfbHRV1UCDSgWZ2N7EytV/vn5M5tPDCKbKoRpmy/aEAKuNY5Vg55/dFXdd3/ewpBbo45fZvXad0o6BGW7ElUae4Rvd3yvO2r5DI2Z9ootZZb25wtUqE+MafJcZ40mDk00v7+8IJeYArrv0lJSqK5uk3cQ; 4:34MxPKUUnZTVm3ngbhEcuPfzGW0ht5KWCqPkUg+8k19GfvtSVHS8r5GoW28XAV3vKe9mM6nx1chxPunFyABoyAvo9/g7gXpVpqDKJmks5C7mU5aLfUik3hDwxWps4r1VF2j3SDaZhDCoS6EnKbgfgj6HbM7r16CW+MbTIeBzmV+ygUqm0Kku2HwtdaFOsstIGolayRbB44iunhtG4JzQZGnANGMqlmKaArHT6Zt4cwZMEFXkkCo7aWnKkJjWV+cEkDcBWkIrd/+5KtgEo4tn8Za0V/JOdJkIOat3Qmzt3lA= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0927AA37C7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1P192MB0235; 23:ZJb20F1roaGU7576YhRBUR2pDjj35tfzdKKh+Gm6h?= =?us-ascii?Q?kSy6pG3SJ4gg2ahr4jogD2vlegSe4pbTLu97kaf2EzJ8ntgxfaGiTgddEkZr?= =?us-ascii?Q?AhbYmaIl1wO/FyBsw7PIjb5m5mXDsdEuuteJop7Ci4OoO8weOTNzwoocYWfy?= =?us-ascii?Q?OWklu0Utuka7C1LghWeiu7SAvYF8wM5C3i+wdbMryR16drheo7havByJv1vI?= =?us-ascii?Q?43s491QfoFbX6oIsIQX9J14pYq9+pmFcMLmx80+B9KUxcw8RWVT9uarkBJWu?= =?us-ascii?Q?lTKzAWsJHWkOsGZBVRb3RLyHmAdO0YY9PMGTAwh3F/9uXdiMUhO6UmziZHLx?= =?us-ascii?Q?fkP13tM4PZfRCq7vk0KVAT72gl5CaFD2eOagRokCZuuhoyOWa8oDRGmdMKYo?= =?us-ascii?Q?UIzAjISe8H7rUBG+sujR5g+gl0FZ9z2zXa1/Zvp4v5aCgNi84ytwbLK6YSeP?= =?us-ascii?Q?WutJgWCPrugN0JiDCiJ09zgvGde1QGaxFMEo4CNpcbRvq4TGDZ3lHsY/d2qU?= =?us-ascii?Q?+hpJuPcv+ixlU5tkKI5aINsWMwaDPXkC7vtA365NOml1mFBgFtmd4Mb3i/Cg?= =?us-ascii?Q?ByM+cGeGtd8fhheLqXv0Dqv6rkxOYtlXqdMXsTJQp9Lcg6dVe7xX9cxtZ2L0?= =?us-ascii?Q?PvMeJqVOvDQRa8gzsYpPsD3Zs6ldkEDBKbtx/b24xdhFL7ZnuWuTcGxherF+?= =?us-ascii?Q?becMhUr1qWETc6jbqT55SxX6zgIXp8iD2rSnhZWmxrRxkZofLnbesxz8HpIw?= =?us-ascii?Q?bu1sJ8d3RnLarkfxObHgHOMqjL9touvdP8Q/r7CUnUxLk8EGJZjpyHA7S6Yz?= =?us-ascii?Q?wPUo6gT34vYKsFksrg2oBlUd7c31kdlJ7kKm5RSrs0VsXLG1Atd/qlo/glCK?= =?us-ascii?Q?GEo2vaamVw2JF/U50BAllfn1VZXemO/Y0GHi0j7SLlPRJNAWHAU2iGQEAmSk?= =?us-ascii?Q?8B3dZHy/yAM9NTltjrQcqpgNTbTmZXGH1IEt5DuPDGSj6hb3Kwv01Y0QJ2d9?= =?us-ascii?Q?PagfiVnuwD9SJ99DJwcbqKQZP2+C7Glxy8uM3/zDs7b44U5LjKP7YL7qB2rU?= =?us-ascii?Q?UzQNdxemFA3zz4a8foL1KmEHetB3XXjqpnkcAQXqLLTZli9Qp2JxVW6Ij4tI?= =?us-ascii?Q?pG88PeitjCejMHch21goiKslWTQyYblpYWeXroVEkz229PCsuPcSuDkx3PU+?= =?us-ascii?Q?wtHfAATJfgFHqeC4ITnaQcXBkNPNs3SOQg7eGvNY3Dsu4N8qtWCNHk+yYMKz?= =?us-ascii?Q?2M5YNbHdjqROc0HoEA=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: SpcTRdfogwJ3D9LF3wMQ9x6VTFJljMvbdrDqhGqUK+JtBuMlVPbkuwcbraEzy4wMjpJQ4A+Sj2v/uVHlVaoMVSyjaNVp8oIMZ6tKSg7kC7/KpsLLlySw5T+iYwpUw5dbxPatsO9NyO08GtkwAUveJWP1sam5i6Np6zcovQRhTayf4vQe2Y7MhC0blyqs8WDrJzEYmm/2YgZ3PcjWBqXnbWwiNZYZbkjH94qZOtG8c3wZ0iNL6hLTXSP/9Yml05SZYEa/pDdaNBDY8Ww4WWTPkwnApWoNShkAPrCZ2zeKMyJOjB2KlwL109MievHcAXOTedqWSIRI2cvR1/nMQSZjNzM1LQ0LVsJBAxw6U1HctWcikAarE52SDGh2VeziskOkFZIpv4zquXiEPRClZSLa6RhaVIBggBQ3Y0AjSlRtGrM= X-Microsoft-Exchange-Diagnostics: 1; HE1P192MB0235; 6:Qpj/lvjrf7HkvSpqS9g7q6yQoZSUZTFdBHncHl3ySx0fOn/Y2EwzyWFDhHOUBDlzSuj/HUadq/3UIDrD6qhPTHjnzon78wRkNSzMIaCty31/pGlyNyxc+a8CzgUlZqPgyF7rpnPCWCuAfIhuZdCem66MTl3O4K2pqDwWvPdi8FZVYLeI0c6BM8lUVmrf6RPKuP22ohVCy7gW69F3JKBzCEJCSQsO4xfl1KmS30acSXRaIhn14Ff0kecIT6YRpFxI8NMyv5PiV5dD6TgSuED/T3bNtAPgeOLAriq+siNrJreaYNeRNqh6sTi3i1EJXIFy84prYab5HKnyDwUecvrlg3UjJjq3ouv5G9s/nL/uCUxzPYRNdg488SLxXFw+0B8vTGMSxxpoYOrsMUlYma5a84OdZeDh7KHe5AICXgWnMiuKeueHwPeWlkeOj9cH9bgswOmB3+Qe9fO+ykdx34Blug==; 5:gAggmjt5pZydKZAWpP2cD2PlkOBTepr/cNd2Ni3GBeeM9RofeLE//DI+9WrWP2xQ+7LguyPvK5eWECs3fpATLmBPV1Hok8xVPI6xAyQ431vhg5+is88U7vTIcNrLqQu4Zp2MzUwS+Q/EjpG7fGdNJ7QLbJ52ePMcF/9PW6pr71NDuUm5rRxBlgv2dgqPSFf31cheC9xxfV/1GwWO9oM1TQ==; 7:4joVQtP1+RlR1b84S+8itH0bDI+9nvFVF4LgDMLNuPALRZbRBIyZcnSVmUIVW+4mrzWvDbtKpGsCz6CuffRBNEl426d/J3lEUg5EJD35QRTLK2z63PAAHyQtX5vgwRJEHtpnOtYGPo4rRL0EPbTlcQ== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: dtu.dk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jan 2019 10:30:24.1654 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3f22edf3-ab9c-42a4-a676-08d681e6f334 X-MS-Exchange-CrossTenant-Id: f251f123-c9ce-448e-9277-34bb285911d9 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f251f123-c9ce-448e-9277-34bb285911d9; Ip=[192.38.82.194]; Helo=[mail.win.dtu.dk] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P192MB0235 Archived-At: Subject: [netmod] Questions about yang models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 10:30:32 -0000 Hello,=20 I work now to output some configuration parameters in TSN-specific formats.= I was able to obtain IEEE 802.1Qcw compliant formats, but I cannot export = the topology or the routing in a similar manner. Could you help me please w= ith some information? 1. To describe the global topology. I found the network-topology.yang model= , but when I use the pyang tool to convert the yang model to python code I = get the following warnings and error: " network-topology.yang:288: warning: XPath for "boolean(../underlay-topology= [*]/node[./supporting-nodes/node-ref])" does not exist network-topology.yang:320: warning: XPath for "boolean(../underlay-topology= /link[./supporting-link])" does not exist network-topology.yang:322: warning: XPath for "boolean(../node[./source/sou= rce-node])" does not exist network-topology.yang:324: warning: XPath for "boolean(../node[./destinatio= n/dest-node])" does not exist network-topology.yang:326: warning: XPath for "boolean(../node/termination-= point[./source/source-tp])" does not exist network-topology.yang:328: warning: XPath for "boolean(../node/termination-= point[./destination/dest-tp])" does not exist FATAL: pyangbind cannot build module that pyang has found errors with. " There is other updated and functional version of network-topology model? I = was using both versions, from 2013-07-12 and 2013-07-15.=20 2. To describe static determined routes. For routing I could not find any m= odel for static routing, could someone help me please with a yang model tha= t could be used for such type of routing?=20 All best Voica= From nobody Thu Jan 24 02:52:03 2019 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 7BB501310EF for ; Thu, 24 Jan 2019 02:52:00 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hhFlyfhktfMR for ; Thu, 24 Jan 2019 02:51:57 -0800 (PST) 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 7172E1310ED for ; Thu, 24 Jan 2019 02:51:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9DFA110B7; Thu, 24 Jan 2019 11:51:55 +0100 (CET) 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 GtmEUw4Cvo5U; Thu, 24 Jan 2019 11:51:55 +0100 (CET) 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; Thu, 24 Jan 2019 11:51:55 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8714020046; Thu, 24 Jan 2019 11:51:55 +0100 (CET) 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 IwH-mNaG6yk7; Thu, 24 Jan 2019 11:51:55 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 1EC0020045; Thu, 24 Jan 2019 11:51:54 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 24 Jan 2019 11:51:54 +0100 Received: by anna.localdomain (Postfix, from userid 501) id E7DCB3005D7508; Thu, 24 Jan 2019 11:51:53 +0100 (CET) Date: Thu, 24 Jan 2019 11:51:53 +0100 From: Juergen Schoenwaelder To: Voica Maria Gavrilut CC: "netmod@ietf.org" Message-ID: <20190124105152.ynhxtt7oslluo72w@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Voica Maria Gavrilut , "netmod@ietf.org" References: <00328be68942482da898ac45a2f881bc@dtu.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <00328be68942482da898ac45a2f881bc@dtu.dk> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] Questions about yang models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 10:52:01 -0000 Dear Voica Maria Gavrilut, the IETF network topology model got published as part of RFC 8345 and you may want to use that. In case you find problems with the model, you should direct your questions to the i2rs working group as this is the working group which created these models (and RFC 8345). I am not sure I understand your second question but the IETF core routing modules are published in RFC 8349. BTW, you can find an overview of the IETF published YANG modules on wikipedia: https://en.wikipedia.org/wiki/YANG#Usage_in_Standards-Track_Data_Models_of_the_IETF Modules that you find in Internet Drafts are work in progress and moving targets and they may have issues. /js On Thu, Jan 24, 2019 at 10:15:34AM +0000, Voica Maria Gavrilut wrote: > Hello, > > I work now to output some configuration parameters in TSN-specific formats. I was able to obtain IEEE 802.1Qcw compliant formats, but I cannot export the topology or the routing in a similar manner. Could you help me please with some information? > > 1. To describe the global topology. I found the network-topology.yang model, but when I use the pyang tool to convert the yang model to python code I get the following warnings and error: > " > network-topology.yang:288: warning: XPath for "boolean(../underlay-topology[*]/node[./supporting-nodes/node-ref])" does not exist > network-topology.yang:320: warning: XPath for "boolean(../underlay-topology/link[./supporting-link])" does not exist > network-topology.yang:322: warning: XPath for "boolean(../node[./source/source-node])" does not exist > network-topology.yang:324: warning: XPath for "boolean(../node[./destination/dest-node])" does not exist > network-topology.yang:326: warning: XPath for "boolean(../node/termination-point[./source/source-tp])" does not exist > network-topology.yang:328: warning: XPath for "boolean(../node/termination-point[./destination/dest-tp])" does not exist > FATAL: pyangbind cannot build module that pyang has found errors with. > > " > There is other updated and functional version of network-topology model? I was using both versions, from 2013-07-12 and 2013-07-15. > > 2. To describe static determined routes. For routing I could not find any model for static routing, could someone help me please with a yang model that could be used for such type of routing? > > All best > Voica > _______________________________________________ > 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 Thu Jan 24 06:56:58 2019 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 B2CB312867A for ; Thu, 24 Jan 2019 06:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 FIT2mkmOLOxj for ; Thu, 24 Jan 2019 06:56:51 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30096.outbound.protection.outlook.com [40.107.3.96]) (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 66058124BE5 for ; Thu, 24 Jan 2019 06:56:49 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=KWLGAOQ08zqwfuA0BQWymPkPKAlIXMW+lHqHkOSm/II=; b=D1GTxcGA1HVkoxcWBSKT4g0JZFVJyIBrLj4iIjFyMupVV5ilbSkzxRnsKbBeFtSvj6uDzsri89l9rSmgyp9eWMONDyUGtWVjAvHf+4cKKt0vynQlCYFOtzFqZpQOO4iNHRbBJD9WTPNDnfDCE/LVPawN4LUfIvMxVGrzVrFoaWg= Received: from DB7PR07MB3978.eurprd07.prod.outlook.com (52.134.100.23) by DB7PR07MB5801.eurprd07.prod.outlook.com (20.178.105.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.5; Thu, 24 Jan 2019 14:56:45 +0000 Received: from DB7PR07MB3978.eurprd07.prod.outlook.com ([fe80::bc27:df4c:48f:81e7]) by DB7PR07MB3978.eurprd07.prod.outlook.com ([fe80::bc27:df4c:48f:81e7%3]) with mapi id 15.20.1580.007; Thu, 24 Jan 2019 14:56:45 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Robert Wilton , "netmod@ietf.org" Thread-Topic: initial comments on draft-rwilton-netmod-yang-packages Thread-Index: AdSz8QbnZ8VnKEK7ROOBuiejK/DkvQ== Date: Thu, 24 Jan 2019 14:56:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.20.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR07MB5801; 6:fU6INEX2BvP9PgYkpTJZIDzrHMZWLcLCAMnQVNAohhL0sC10CVqCkyMrDRM0kcZYOvXEuT9gF/3DC9IOxQvdoY/Opam5TtgefBSrqbY6eBvbmtFsyTxUybSYk2Zn61t5irL/2QPrPgB5wB7sHl8zLNgZ6E8eVh6Lum5z6Z42kPMSFZZLv72VtafLxO9Sf8kESBTf9A+uCrCknvMEa1MoTe37EcvUwrs9OibpP0OT103jFpfKb3QkcJdMBtmKcq4tXiUbDwoNIubo0azFIaJ4aFy+tTLK8AmeLW/3YlvyfIJyMbz2uwvRZkbnUy2Ct3aYidiHEfxrrnxvmQq4eR8nI6lXPGWoOngMecK1WVny5Py+MMHx0zEtt11NqMxpeDXxOZWa0Gkq3829vckLPxKwMwmYBiO4wll87qrUJICk8zZu6n8rGYSC5uv3YtGtbF8MVobbBA3+p0I729TFf9q/zw==; 5:qmEpCDT8NovjwaBEyJpoC0/t3C2NSz06xFRFyc0Y/eHZCwmTtQiOiPEx+SDoOXWmOS0ptNzS+s30LJ9kLvK2LrWFvBxhByCE1tFVOUXEUt6qLiwF3JczaIhuBEP0dZQt2SVH/gwmjVccvjTf0TStXjfWm/cvWHfVqihFwraHypPlA8ugavXyLbRPKHqaJGmyMiaPqkQVJIl+jpobAsgm6g==; 7:cfGKTpZAdKlb6724AY04favVANCuuLqIi9gx04rVl0dyQxdZLArxcnVnQtf1CmplCmpvYygWPgOrD9+ZKlIz9yC6Hi+4bPf6df4LxDqpGs8Z4mTOtcQRfDR2FcYTx6luUU0DxuMhwnRGFhW/NU+FuA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 84458122-2859-480e-612a-08d6820c28a1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB7PR07MB5801; x-ms-traffictypediagnostic: DB7PR07MB5801: x-microsoft-antispam-prvs: x-forefront-prvs: 0927AA37C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(366004)(136003)(396003)(199004)(189003)(51444003)(6346003)(102836004)(99286004)(53546011)(316002)(476003)(6506007)(186003)(7696005)(74316002)(66066001)(68736007)(105586002)(110136005)(26005)(2906002)(33656002)(106356001)(86362001)(7736002)(8676002)(81156014)(81166006)(8936002)(2501003)(97736004)(790700001)(25786009)(486006)(6116002)(54896002)(9686003)(71190400001)(14444005)(606006)(14454004)(966005)(478600001)(53936002)(236005)(6306002)(256004)(71200400001)(6436002)(55016002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5801; H:DB7PR07MB3978.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /8fjSFH1R6LERV1Q5uRzloaqNiF9kZGx30Ep9/rBTNldEpRhluQgVl9H6juw1XbXeikJ4qwyO3DF5sVppc8EI70fEMUH+gunlTZDA8AZ7/9mESGvi9gkNXdEhMsoySJwUkon9fx1LLdeJqgSfniZj3eM/BEaFXxUiUd9Ngrs4n7arFLAa6k+b0YILRC1QNWCa/4ktfuMGdHiDYSTCIfFKyil1PiH+yYjU9vfsnAjnYM2mPOHPG/hyOzh8gwSe881VrJ1fbs3Mtni00+s9wSPqr5XzcRVdpBFL/PFI4lW9gf4++CVXO4+TNKTHzm2b/9CI8/1Zu/9p6p8VLqaM7dx2gku6Rr7U4PfOydM09fDILbSFCSq9CqutyJFbGHB5D6nV17P7TVwmn8xytKGb/wAWfxS7aRobW+jRyp72/ZyV8E= Content-Type: multipart/alternative; boundary="_000_DB7PR07MB397887BD6B69B474618FD1469B9A0DB7PR07MB3978eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84458122-2859-480e-612a-08d6820c28a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2019 14:56:45.1176 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5801 Archived-At: Subject: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 14:56:55 -0000 --_000_DB7PR07MB397887BD6B69B474618FD1469B9A0DB7PR07MB3978eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZ3V5cywNCg0KSSd2ZSBnb3R0ZW4gbW9zdCBvZiB0aGUgd2F5IHRocm91Z2ggdGhlIGRyYWZ0 IGFuZCBoYXZlIHNvbWUgaW5pdGlhbCBjb21tZW50cy4gSSBoYXZlbid0IGRpZ2VzdGVkIHRoZSBz ZWN0aW9uIDEwIG9wZW4gaXNzdWVzIHlldCBvciB0aGUgZXhhbXBsZXMuDQoNClNlY3Rpb24gNSBt ZW50aW9ucyB0aGUgZm9sbG93aW5nOg0KICAgWUFORyBsaWJyYXJ5IGlzIGF1Z21lbnRlZCB0byBh bGxvdyBzZXJ2ZXJzIHRvIHJlcG9ydCB0aGUgcGFja2FnZXMNCiAgIHRoYXQgdGhleSBpbXBsZW1l bnQgYW5kIHRvIGFzc29jaWF0ZSB0aG9zZSBwYWNrYWdlcyBiYWNrIHRvDQogICBwYXJ0aWN1bGFy IGRhdGFzdG9yZSBzY2hlbWEuDQoNCkRvZXMgdGhlIGNvbWJpbmF0aW9uIG9mIHRoaXMgZHJhZnQg YW5kIHJmYzc4OTViaXMgc29tZWhvdyBhbGxvdyB0aGUgc2FtZSBwYWNrYWdlIHRvIGJlIGFkdmVy dGlzZWQgaW4gMiBkaWZmZXJlbnQgZGF0YXN0b3JlcywgYnV0IHdpdGggZGlmZmVyZW50IGRldmlh dGlvbnMgaW4gZWFjaCBkYXRhc3RvcmU/IEknbSB0aGlua2luZyBvZiBhIGNhc2UsIGZvciBleGFt cGxlLCB3aGVyZSBhIHBhY2thZ2UgaXMgZnVsbHkgc3VwcG9ydGVkIGluIHRoZSBydW5uaW5nIGJ1 dCB0aGUgcGFja2FnZSBtaW51cyBhIGZldyBtb2R1bGVzIChvciBwYXJ0cyBvZiBtb2R1bGVzKSBp cyBzdXBwb3J0ZWQgaW4gdGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZS4gVGhlcmUgc2VlbXMgdG8g YmUgYSAxOjEgcmVsYXRpb25zaGlwIGJldHdlZW4gcGFja2FnZSBhbmQgcmZjNzg5NWJpcyBzY2hl bWEuDQoNClRoZSBwYWNrYWdlcyBkcmFmdCBkb2Vzbid0IGluY2x1ZGUgYW55IHNwZWNpZmljIGxl YWYtbGlzdCBmb3IgZGV2aWF0aW9ucy4gU2VjdGlvbiA3LjIgbWVudGlvbnMgdGhhdCBkZXZpYXRp b25zIGNvdWxkIGJlIGV4cHJlc3NlZCBieSBpbmNsdWRpbmcgbW9kdWxlcyB0aGF0IGhhcHBlbiB0 byBjb250YWluIGRldmlhdGlvbnMuIFRoYXQgc2VlbXMgYSBiaXQgaW5jb25zaXN0ZW50IHdpdGgg cmZjNzg5NWJpcyB0aGF0IGhhcyBhIHNwZWNpZmljIGxlYWYtbGlzdCBvZiBkZXZpYXRpb25zIChh bmQgTkVUQ09ORiBoZWxsbyB0aGF0IHNwZWNpZmljYWxseSBleHBsaWNpdGx5IGxhYmVscyBkZXZp YXRpb24gbW9kdWxlcykuDQoNClNlY3Rpb24gNS4xIHNheXMgdGhlIHBhY2thZ2UgbXVzdCBiZSBy ZWZlcmVudGlhbGx5IGNvbXBsZXRlLiBJIGNhbiBzZWUgdGhlIGFkdmFudGFnZXMgb2YgdGhhdCBh bHRob3VnaCB3b25kZXJpbmcgaWYgdGhhdCBtaWdodCBsaW1pdCBmbGV4aWJpbGl0eSBvZiBwYXJ0 aXRpb25pbmcgbW9kdWxlcyBpbnRvIHBhY2thZ2VzLiBJIGNvdWxkIGltYWdpbmUgdXNlIGNhc2Vz IGZvciBkaXZpZGluZyBhIGxhcmdlIHNldCBvZiBtb2R1bGVzIGludG8gYSBmZXcgcGFja2FnZXMg dGhhdCBtaWdodCByZXYgaW5kZXBlbmRlbnRseSBidXQgY2FuIHN0aWxsIGFsbCB3b3JrIHRvZ2V0 aGVyIChlc3BlY2lhbGx5IGlmIHRoZXkgcmV2IGluIGEgYmMgbWFubmVyKS4gQnV0IG1heWJlIHRo YXQganVzdCBzdGFydHMgdG8gaW50cm9kdWNlIHRvbyBtdWNoIGNvbXBsZXhpdHk/DQoNCkkgZGlk bid0IHVuZGVyc3RhbmQgdGhpcyBwYXJ0IG9mIHNlY3Rpb24gNS4xLiBDYW4geW91IG1heWJlIGls bHVzdHJhdGUgd2l0aCBhbiBleGFtcGxlPw0KICAgICAgVGhlIHZlcnNpb24vcmV2aXNpb24gb2Yg YSBtb2R1bGUgbGlzdGVkIGluIHRoZSBwYWNrYWdlIG1vZHVsZSBsaXN0DQogICAgICBzdXBlcmNl ZGVzIGFueSB2ZXJzaW9uL3JldmlzaW9uIG9mIHRoZSBtb2R1bGUgbGlzdGVkIGluIGEgaW1wb3J0 ZWQNCiAgICAgIHBhY2thZ2UgbW9kdWxlIGxpc3QuICBUaGlzIGFsbG93cyBhIHBhY2thZ2UgdG8g cmVzb2x2ZSBhbnkNCiAgICAgIGNvbmZsaWN0aW5nIGltcGxlbWVudGVkIG1vZHVsZSB2ZXJzaW9u cy9yZXZpc2lvbnMgaW4gaW1wb3J0ZWQNCiAgICAgIHBhY2thZ2VzLg0KDQpJdCBtaWdodCBiZSBh IGdvb2QgaWRlYSB0byBhZGQgYSBwYXJlbnQtdmVyc2lvbiB0byB0aGUgcGFja2FnZSBtb2R1bGUg KHRvIGFsbG93IHRyYWNraW5nIGxpbmVhZ2Ugb2YgcGFja2FnZXMpLg0KDQpJIGxpa2UgdGhlIHVz ZSBvZiBncm91cGluZ3MuIFRoYXQgYWxsb3dzIGEgbWFuYWdlciB0byB1c2UgdGhpcyBhcyBhIGJ1 aWxkaW5nIGJsb2NrIHRvIGNvbXBvc2UgYSBtb2RlbCB0aGF0IGhhcyBhIGxpc3Qgb2YgcGFja2Fn ZXMuDQoNCkhhdmluZyBhIGdsb2JhbCBsaXN0IG9mIG1hbmRhdG9yeSBmZWF0dXJlcyAodnMgaGF2 aW5nIHRoZSBtYW5kYXRvcnkgZmVhdHVyZSBhIHBlci1tb2R1bGUgbGlzdCkgbWVhbnMgaW52ZW50 aW5nIHRoZSBuZXcgPG1vZHVsZS1uYW1lPjo8ZmVhdHVyZT4gZm9ybWF0LiBTaG91bGQgd2UgaW5z dGVhZCBzb21laG93IHB1dCB0aGUgbWFuZGF0b3J5IGZlYXR1cmVzIGFnYWluc3QgZWFjaCBtb2R1 bGUgb2YgdGhlIHBhY2thZ2U/DQoNClRoZSBsb2NhdGlvbiBsZWFmIGlzIGEgdXJpIGJ1dCB0aGVu IHRoZSBkZXNjcmlwdGlvbiBzYXlzIGl0IG11c3QgYmUgYSB1cmwgKHdoZXJlIHRoZSBtb2RlbCBj YW4gYmUgcmV0cmlldmVkKS4gSSBkbyBsaWtlIHRoYXQgdGhlIG5hbWVzcGFjZSBpcyBzZXBhcmF0 ZSBmcm9tIHRoZSBsb2NhdGlvbiwgYnV0IG1heWJlIHdlIHNob3VsZCBtYWtlIGxvY2F0aW9uIGEg dXJsIHR5cGU/DQoNCkRvIHdlIG5lZWQgYSBuYW1lc3BhY2UgZm9yIHBhY2thZ2UgbmFtZXMgaW4g dGhlIG1vZGVsPw0KDQpJbiA3LjMgd2Ugb25seSByZWZlcmVuY2UgbW9kdWxlLXNldHMgYW5kIG5v dCBtb2R1bGVzLiBTbyB0aGUgZ3JvdXBpbmcgb2YgbW9kdWxlcyBpbnRvIHNldHMgYW5kIHBhY2th Z2VzIG11c3QgYmUgdGhlIHNhbWU/DQoNCkEgc2NoZW1hIGNhbiBvbmx5IGhhdmUgYSBzaW5nbGUg cGFja2FnZS4gSSB0aGluayB0aGF0IHdvcmtzIGJ1dCBpdCBtZWFucyBhIHNlcnZlciB3b3VsZCBh ZHZlcnRpc2UgbXVsdGlwbGUgc2NoZW1hcyBpZiBpdCB3YW50cyB0byBzdXBwb3J0IG11bHRpcGxl IHBhY2thZ2VzLiBJJ20gbm90IHN1cmUgaWYgdGhlcmUgYXJlIHNvbWUgZG93bnNpZGVzIHRvIHRo YXQgKGl0IGp1c3Qgc3VycHJpc2VkIG1lKS4NCg0KSmFzb24NCg0KDQoNCkZyb206IG5ldG1vZCA8 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSb2JlcnQgV2lsdG9uDQpTZW50 OiBUaHVyc2RheSwgRGVjZW1iZXIgMjAsIDIwMTggMTI6NDUgUE0NClRvOiBuZXRtb2RAaWV0Zi5v cmcNClN1YmplY3Q6IFtuZXRtb2RdIFlBTkcgUGFja2FnZXMNCg0KDQpIaSwNCg0KSSd2ZSB3cml0 dGVuIHVwIGFuIElEIGZvciBhIHBvdGVudGlhbCBzb2x1dGlvbiBmb3IgWUFORyBwYWNrYWdlcyB1 c2luZyBpbnN0YW5jZSBkYXRhOg0KDQpBYnN0cmFjdA0KDQoNCg0KICAgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIFlBTkcgcGFja2FnZXMsIGFuIG9yZ2FuaXphdGlvbmFsIHN0cnVjdHVyZQ0KDQogICBo b2xkaW5nIGEgc2V0IG9mIHJlbGF0ZWQgWUFORyBtb2R1bGVzLCB0aGF0IGNhbiBiZSB1c2VkIHRv IHNpbXBsaWZ5DQoNCiAgIHRoZSBjb25mb3JtYW5jZSBhbmQgc2hhcmluZyBvZiBZQU5HIHNjaGVt YS4gIEl0IGRlc2NyaWJlcyBob3cgWUFORw0KDQogICBpbnN0YW5jZSBkYXRhIGRvY3VtZW50cyBh cmUgdXNlZCB0byBkZWZpbmUgWUFORyBwYWNrYWdlcywgYW5kIGhvdyB0aGUNCg0KICAgWUFORyBs aWJyYXJ5IGluZm9ybWF0aW9uIHB1Ymxpc2hlZCBieSBhIHNlcnZlciBjYW4gYmUgYXVnbWVudGVk IHdpdGgNCg0KICAgYWRkaXRpb25hbCBwYWNrYWdpbmcgcmVsYXRlZCBpbmZvcm1hdGlvbi4NCg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcndpbHRvbi1uZXRtb2QteWFu Zy1wYWNrYWdlcy8NCg0KUG90ZW50aWFsbHkgdGhpcyB3b3JrIG1heSBiZSBvZiB1c2UgYXMgcGFy dCBvZiB0aGUgWUFORyB2ZXJzaW9uaW5nIGRlc2lnbiB0ZWFtIHdvcmsuICBJbiBhZGRpdGlvbiwg aWYgdGhlIFdHIGxpa2VzIHRoaXMgYXBwcm9hY2ggb2YgZGVmaW5pbmcgWUFORyBwYWNrYWdlcywg dGhlbiBpdCBtaWdodCBhbHNvIGJlIHVzZWZ1bCB0byBiaW5kIGEgc2NoZW1hIHRvIGEgWUFORyBp bnN0YW5jZSBkYXRhIGRvY3VtZW50Lg0KDQpTb21lIHF1ZXN0aW9ucyBmb3IgbWVtYmVycyBvZiB0 aGUgV0c6DQoNCjEpIERvIG1lbWJlcnMgb2YgdGhlIFdHIGFncmVlIHRoYXQgWUFORyBwYWNrYWdl cyBpcyBzb21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBzb2x2ZWQ/DQoNCjIpIElzIHRoZSBhcHBy b2FjaCBpbiB0aGlzIGRyYWZ0IG9mIGRlZmluaW5nIHRoZXNlIGFzIGluc3RhbmNlIGRhdGEgZG9j dW1lbnRzIGEgZ29vZCBzdGFydGluZyBwb2ludD8NCg0KMykgVGhpcyBhcHByb2FjaCBhdWdtZW50 cyBZQU5HIGxpYnJhcnktYmlzLCByZXVzaW5nIG1vZHVsZS1zZXRzLCBidXQgbm90IHJlcGxhY2lu ZyB0aGUgd2F5IHRoYXQgbW9kdWxlcyBhcmUgcmVwb3J0ZWQgaW4gWUFORyBsaWJyYXJ5LWJpcy4g IElzIHRoaXMgdGhlIHJpZ2h0IGFwcHJvYWNoPyAgVGhpcyBhcHByb2FjaCB0cmllcyB0byBhbGxv dyBtb2R1bGUtc2V0cyB0byBiZSByZXVzZWQgZm9yIGJvdGggc2NoZW1hIGFuZCBwYWNrYWdlcywg YnV0IHRoZSBZQU5HIGxpYnJhcnktYmlzIHJ1bGVzIGZvciBjb21iaW5pbmcgbW9kdWxlLXNldHMg KGkuZS4gbm8gY29uZmxpY3RzKSBtYXkgbWFrZSB0aGlzIGhhcmRlciB0byByZWFsbHkgcmV1c2Ug dGhlIG1vZHVsZS1zZXRzIGZvciBib3RoIHB1cnBvc2VzLg0KDQpPZiBjb3Vyc2UsIGFueSBvdGhl ciBjb21tZW50cyBvciBmZWVkYmFjayBpcyB3ZWxjb21lIGFuZCBhcHByZWNpYXRlZC4NCg0KVGhh bmtzLA0KUm9iDQo= --_000_DB7PR07MB397887BD6B69B474618FD1469B9A0DB7PR07MB3978eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OiJDb25zb2xhcyIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5taA0KCXttc28tc3R5 bGUtbmFtZTptX2g7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBndXlzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSd2ZSBnb3R0ZW4gbW9zdCBvZiB0aGUgd2F5IHRo cm91Z2ggdGhlIGRyYWZ0IGFuZCBoYXZlIHNvbWUgaW5pdGlhbCBjb21tZW50cy4gSSBoYXZlbid0 IGRpZ2VzdGVkIHRoZSBzZWN0aW9uIDEwIG9wZW4gaXNzdWVzIHlldCBvciB0aGUgZXhhbXBsZXMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TZWN0aW9uIDUgbWVudGlv bnMgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+Jm5ic3A7Jm5ic3A7IFlBTkcgbGlicmFyeSBpcyBhdWdtZW50ZWQgdG8gYWxsb3cgc2Vy dmVycyB0byByZXBvcnQgdGhlIHBhY2thZ2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyB0aGF0IHRoZXkgaW1wbGVtZW50IGFuZCB0byBh c3NvY2lhdGUgdGhvc2UgcGFja2FnZXMgYmFjayB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgcGFydGljdWxhciBkYXRhc3RvcmUgc2No ZW1hLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+RG9lcyB0aGUgY29t YmluYXRpb24gb2YgdGhpcyBkcmFmdCBhbmQgcmZjNzg5NWJpcyBzb21laG93IGFsbG93IHRoZSBz YW1lIHBhY2thZ2UgdG8gYmUgYWR2ZXJ0aXNlZCBpbiAyIGRpZmZlcmVudCBkYXRhc3RvcmVzLCBi dXQgd2l0aCBkaWZmZXJlbnQgZGV2aWF0aW9ucyBpbiBlYWNoIGRhdGFzdG9yZT8gSSdtDQogdGhp bmtpbmcgb2YgYSBjYXNlLCBmb3IgZXhhbXBsZSwgd2hlcmUgYSBwYWNrYWdlIGlzIGZ1bGx5IHN1 cHBvcnRlZCBpbiB0aGUgcnVubmluZyBidXQgdGhlIHBhY2thZ2UgbWludXMgYSBmZXcgbW9kdWxl cyAob3IgcGFydHMgb2YgbW9kdWxlcykgaXMgc3VwcG9ydGVkIGluIHRoZSBvcGVyYXRpb25hbCBk YXRhc3RvcmUuIFRoZXJlIHNlZW1zIHRvIGJlIGEgMToxIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHBh Y2thZ2UgYW5kIHJmYzc4OTViaXMgc2NoZW1hLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+VGhlIHBhY2thZ2VzIGRyYWZ0IGRvZXNuJ3QgaW5jbHVkZSBhbnkgc3BlY2lm aWMgbGVhZi1saXN0IGZvciBkZXZpYXRpb25zLiBTZWN0aW9uIDcuMiBtZW50aW9ucyB0aGF0IGRl dmlhdGlvbnMgY291bGQgYmUgZXhwcmVzc2VkIGJ5IGluY2x1ZGluZyBtb2R1bGVzIHRoYXQgaGFw cGVuIHRvIGNvbnRhaW4gZGV2aWF0aW9ucy4NCiBUaGF0IHNlZW1zIGEgYml0IGluY29uc2lzdGVu dCB3aXRoIHJmYzc4OTViaXMgdGhhdCBoYXMgYSBzcGVjaWZpYyBsZWFmLWxpc3Qgb2YgZGV2aWF0 aW9ucyAoYW5kIE5FVENPTkYgaGVsbG8gdGhhdCBzcGVjaWZpY2FsbHkgZXhwbGljaXRseSBsYWJl bHMgZGV2aWF0aW9uIG1vZHVsZXMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+U2VjdGlvbiA1LjEgc2F5cyB0aGUgcGFja2FnZSBtdXN0IGJlIHJlZmVyZW50aWFsbHkg Y29tcGxldGUuIEkgY2FuIHNlZSB0aGUgYWR2YW50YWdlcyBvZiB0aGF0IGFsdGhvdWdoIHdvbmRl cmluZyBpZiB0aGF0IG1pZ2h0IGxpbWl0IGZsZXhpYmlsaXR5IG9mIHBhcnRpdGlvbmluZyBtb2R1 bGVzIGludG8gcGFja2FnZXMuDQogSSBjb3VsZCBpbWFnaW5lIHVzZSBjYXNlcyBmb3IgZGl2aWRp bmcgYSBsYXJnZSBzZXQgb2YgbW9kdWxlcyBpbnRvIGEgZmV3IHBhY2thZ2VzIHRoYXQgbWlnaHQg cmV2IGluZGVwZW5kZW50bHkgYnV0IGNhbiBzdGlsbCBhbGwgd29yayB0b2dldGhlciAoZXNwZWNp YWxseSBpZiB0aGV5IHJldiBpbiBhIGJjIG1hbm5lcikuIEJ1dCBtYXliZSB0aGF0IGp1c3Qgc3Rh cnRzIHRvIGludHJvZHVjZSB0b28gbXVjaCBjb21wbGV4aXR5PzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBkaWRuJ3QgdW5kZXJzdGFuZCB0aGlzIHBhcnQgb2Ygc2Vj dGlvbiA1LjEuIENhbiB5b3UgbWF5YmUgaWxsdXN0cmF0ZSB3aXRoIGFuIGV4YW1wbGU/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUaGUgdmVyc2lvbi9yZXZpc2lvbiBvZiBhIG1vZHVsZSBsaXN0ZWQgaW4g dGhlIHBhY2thZ2UgbW9kdWxlIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1cGVyY2VkZXMgYW55 IHZlcnNpb24vcmV2aXNpb24gb2YgdGhlIG1vZHVsZSBsaXN0ZWQgaW4gYSBpbXBvcnRlZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgcGFja2FnZSBtb2R1bGUgbGlzdC4mbmJzcDsgVGhpcyBhbGxvd3MgYSBw YWNrYWdlIHRvIHJlc29sdmUgYW55PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25mbGljdGluZyBpbXBs ZW1lbnRlZCBtb2R1bGUgdmVyc2lvbnMvcmV2aXNpb25zIGluIGltcG9ydGVkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBwYWNrYWdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pkl0IG1pZ2h0IGJlIGEgZ29vZCBpZGVhIHRvIGFkZCBhIHBhcmVudC12ZXJzaW9uIHRvIHRoZSBw YWNrYWdlIG1vZHVsZSAodG8gYWxsb3cgdHJhY2tpbmcgbGluZWFnZSBvZiBwYWNrYWdlcykuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5J IGxpa2UgdGhlIHVzZSBvZiBncm91cGluZ3MuIFRoYXQgYWxsb3dzIGEgbWFuYWdlciB0byB1c2Ug dGhpcyBhcyBhIGJ1aWxkaW5nIGJsb2NrIHRvIGNvbXBvc2UgYSBtb2RlbCB0aGF0IGhhcyBhIGxp c3Qgb2YgcGFja2FnZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5IYXZpbmcgYSBnbG9iYWwgbGlzdCBvZiBtYW5kYXRvcnkgZmVhdHVy ZXMgKHZzIGhhdmluZyB0aGUgbWFuZGF0b3J5IGZlYXR1cmUgYSBwZXItbW9kdWxlIGxpc3QpIG1l YW5zIGludmVudGluZyB0aGUgbmV3ICZsdDttb2R1bGUtbmFtZSZndDs6Jmx0O2ZlYXR1cmUmZ3Q7 IGZvcm1hdC4gU2hvdWxkIHdlIGluc3RlYWQgc29tZWhvdyBwdXQgdGhlIG1hbmRhdG9yeSBmZWF0 dXJlcyBhZ2FpbnN0IGVhY2gNCiBtb2R1bGUgb2YgdGhlIHBhY2thZ2U/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGUgbG9jYXRpb24gbGVhZiBpcyBhIHVyaSBidXQgdGhlbiB0aGUgZGVzY3JpcHRpb24g c2F5cyBpdCBtdXN0IGJlIGEgdXJsICh3aGVyZSB0aGUgbW9kZWwgY2FuIGJlIHJldHJpZXZlZCku IEkgZG8gbGlrZSB0aGF0IHRoZSBuYW1lc3BhY2UgaXMgc2VwYXJhdGUgZnJvbSB0aGUgbG9jYXRp b24sIGJ1dCBtYXliZSB3ZSBzaG91bGQgbWFrZSBsb2NhdGlvbiBhIHVybCB0eXBlPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+RG8gd2UgbmVlZCBhIG5hbWVzcGFjZSBmb3IgcGFja2FnZSBuYW1lcyBpbiB0 aGUgbW9kZWw/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiA3LjMgd2Ugb25seSByZWZlcmVuY2UgbW9k dWxlLXNldHMgYW5kIG5vdCBtb2R1bGVzLiBTbyB0aGUgZ3JvdXBpbmcgb2YgbW9kdWxlcyBpbnRv IHNldHMgYW5kIHBhY2thZ2VzIG11c3QgYmUgdGhlIHNhbWU/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5B IHNjaGVtYSBjYW4gb25seSBoYXZlIGEgc2luZ2xlIHBhY2thZ2UuIEkgdGhpbmsgdGhhdCB3b3Jr cyBidXQgaXQgbWVhbnMgYSBzZXJ2ZXIgd291bGQgYWR2ZXJ0aXNlIG11bHRpcGxlIHNjaGVtYXMg aWYgaXQgd2FudHMgdG8gc3VwcG9ydCBtdWx0aXBsZSBwYWNrYWdlcy4gSSdtIG5vdCBzdXJlIGlm IHRoZXJlIGFyZSBzb21lIGRvd25zaWRlcyB0byB0aGF0IChpdCBqdXN0IHN1cnByaXNlZA0KIG1l KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkphc29uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndp bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPiBuZXRtb2QgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+ T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgV2lsdG9uPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBEZWNlbWJlciAyMCwgMjAxOCAxMjo0NSBQTTxicj4NCjxiPlRvOjwvYj4gbmV0bW9kQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtuZXRtb2RdIFlBTkcgUGFja2FnZXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cD5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwPkkndmUgd3JpdHRlbiB1 cCBhbiBJRCBmb3IgYSBwb3RlbnRpYWwgc29sdXRpb24gZm9yIFlBTkcgcGFja2FnZXMgdXNpbmcg aW5zdGFuY2UgZGF0YTo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBh cmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDgu MHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3Jk ZXI6bm9uZTtwYWRkaW5nOjBjbTtib3gtc2l6aW5nOiBib3JkZXItYm94O292ZXJmbG93LXdyYXA6 IGJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czogNHB4O2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5v cm1hbDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IDI7dGV4dC1hbGlnbjpzdGFy dDt3aWRvd3M6IDI7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3RleHQtZGVjb3JhdGlv bi1zdHlsZTogaW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7b3ZlcmZsb3c6 YXV0bzt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBjbGFzcz0ibWgiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0Ij5BYnN0cmFjdDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJv dHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVy Om5vbmU7cGFkZGluZzowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7 YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRp bmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyBZQU5HIHBhY2thZ2VzLCBhbiBvcmdhbml6YXRpb25hbCBzdHJ1Y3R1 cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45 cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3Bh ZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IGhv bGRpbmcgYSBzZXQgb2YgcmVsYXRlZCBZQU5HIG1vZHVsZXMsIHRoYXQgY2FuIGJlIHVzZWQgdG8g c2ltcGxpZnk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpu b25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5i c3A7IHRoZSBjb25mb3JtYW5jZSBhbmQgc2hhcmluZyBvZiBZQU5HIHNjaGVtYS4mbmJzcDsgSXQg ZGVzY3JpYmVzIGhvdyBZQU5HPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs bDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi PiZuYnNwOyZuYnNwOyBpbnN0YW5jZSBkYXRhIGRvY3VtZW50cyBhcmUgdXNlZCB0byBkZWZpbmUg WUFORyBwYWNrYWdlcywgYW5kIGhvdyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6 YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IFlBTkcgbGlicmFyeSBpbmZvcm1hdGlvbiBwdWJsaXNoZWQg YnkgYSBzZXJ2ZXIgY2FuIGJlIGF1Z21lbnRlZCB3aXRoPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3Jk LWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBhZGRpdGlvbmFsIHBhY2thZ2luZyByZWxhdGVk IGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8cD48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yd2lsdG9uLW5ldG1vZC15 YW5nLXBhY2thZ2VzLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcndp bHRvbi1uZXRtb2QteWFuZy1wYWNrYWdlcy88L2E+PG86cD48L286cD48L3A+DQo8cD5Qb3RlbnRp YWxseSB0aGlzIHdvcmsgbWF5IGJlIG9mIHVzZSBhcyBwYXJ0IG9mIHRoZSBZQU5HIHZlcnNpb25p bmcgZGVzaWduIHRlYW0gd29yay4mbmJzcDsgSW4gYWRkaXRpb24sIGlmIHRoZSBXRyBsaWtlcyB0 aGlzIGFwcHJvYWNoIG9mIGRlZmluaW5nIFlBTkcgcGFja2FnZXMsIHRoZW4gaXQgbWlnaHQgYWxz byBiZSB1c2VmdWwgdG8gYmluZCBhIHNjaGVtYSB0byBhIFlBTkcgaW5zdGFuY2UgZGF0YSBkb2N1 bWVudC48bzpwPjwvbzpwPjwvcD4NCjxwPlNvbWUgcXVlc3Rpb25zIGZvciBtZW1iZXJzIG9mIHRo ZSBXRzo8YnI+DQo8YnI+DQoxKSBEbyBtZW1iZXJzIG9mIHRoZSBXRyBhZ3JlZSB0aGF0IFlBTkcg cGFja2FnZXMgaXMgc29tZXRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgc29sdmVkPzxvOnA+PC9vOnA+ PC9wPg0KPHA+MikgSXMgdGhlIGFwcHJvYWNoIGluIHRoaXMgZHJhZnQgb2YgZGVmaW5pbmcgdGhl c2UgYXMgaW5zdGFuY2UgZGF0YSBkb2N1bWVudHMgYSBnb29kIHN0YXJ0aW5nIHBvaW50PzxvOnA+ PC9vOnA+PC9wPg0KPHA+MykgVGhpcyBhcHByb2FjaCBhdWdtZW50cyBZQU5HIGxpYnJhcnktYmlz LCByZXVzaW5nIG1vZHVsZS1zZXRzLCBidXQgbm90IHJlcGxhY2luZyB0aGUgd2F5IHRoYXQgbW9k dWxlcyBhcmUgcmVwb3J0ZWQgaW4gWUFORyBsaWJyYXJ5LWJpcy4mbmJzcDsgSXMgdGhpcyB0aGUg cmlnaHQgYXBwcm9hY2g/Jm5ic3A7IFRoaXMgYXBwcm9hY2ggdHJpZXMgdG8gYWxsb3cgbW9kdWxl LXNldHMgdG8gYmUgcmV1c2VkIGZvciBib3RoIHNjaGVtYSBhbmQgcGFja2FnZXMsIGJ1dA0KIHRo ZSBZQU5HIGxpYnJhcnktYmlzIHJ1bGVzIGZvciBjb21iaW5pbmcgbW9kdWxlLXNldHMgKGkuZS4g bm8gY29uZmxpY3RzKSBtYXkgbWFrZSB0aGlzIGhhcmRlciB0byByZWFsbHkgcmV1c2UgdGhlIG1v ZHVsZS1zZXRzIGZvciBib3RoIHB1cnBvc2VzLjxvOnA+PC9vOnA+PC9wPg0KPHA+T2YgY291cnNl LCBhbnkgb3RoZXIgY29tbWVudHMgb3IgZmVlZGJhY2sgaXMgd2VsY29tZSBhbmQgYXBwcmVjaWF0 ZWQuPG86cD48L286cD48L3A+DQo8cD5UaGFua3MsPGJyPg0KUm9iPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DB7PR07MB397887BD6B69B474618FD1469B9A0DB7PR07MB3978eurp_-- From nobody Thu Jan 24 10:16:31 2019 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 4EFF4131304 for ; Thu, 24 Jan 2019 10:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.042 X-Spam-Level: X-Spam-Status: No, score=-19.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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_KAM_HTML_FONT_INVALID=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 k3M6Yscxrbod for ; Thu, 24 Jan 2019 10:16:25 -0800 (PST) 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 F013A1312EA for ; Thu, 24 Jan 2019 10:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31147; q=dns/txt; s=iport; t=1548353785; x=1549563385; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=LNKIP7T5O504cb0+F0+1HgL6PW/3O300xWXPo8xxo1c=; b=gAtMzQe1T2/PnJtUxcO3ldc5WyzMw6/NzKy8krZtBC+3Ne3nVlMeK1xH Qowv1j8dBBJWY9y+Ebisdc5qhhkIZrQexCqeJha+F4tod6xAgci7nRwd/ o5QmoJMnmVQwNDmBdxMZk2hFaadF8V74HO/nv7LIOvExQIrmD5gPTyzLT 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAADv/Ulc/xbLJq0ZAUoaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFSBAEBAQELAQGBDIFdcRInhAGIeYx0CCWYB4F7DSOESQK?= =?us-ascii?q?DJTUIDQEDAQECAQECbRwMhUoBAQEBAgEjCkUMCwkCEQQBAQEgAQkCAk8IBgE?= =?us-ascii?q?MBgIBAReDBwGBeQgPjyGBQZthgS8fhCNBQIRmBYxYgUA/gTgMgWF+gx4CAwG?= =?us-ascii?q?BNxCDH4JXAolGUIV5hlmKaVwJhyqKdgYYii2HcooMhSOEc4cVgUgCNCiBLjM?= =?us-ascii?q?aCBsVO4Jsix2FPz8DMIhigkwBAQ?= X-IronPort-AV: E=Sophos;i="5.56,517,1539648000"; d="scan'208,217";a="9649814" 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 Jan 2019 18:16:22 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x0OIGMvu012273; Thu, 24 Jan 2019 18:16:22 GMT To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" References: From: Robert Wilton Message-ID: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> Date: Thu, 24 Jan 2019 18:16:21 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8A2BDE503AED88F64D6E2AC0" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 18:16:29 -0000 This is a multi-part message in MIME format. --------------8A2BDE503AED88F64D6E2AC0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jason, Thanks for the review and comments. I've put some responses inline ... On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote: > > Hi guys, > > I've gotten most of the way through the draft and have some initial > comments. I haven't digested the section 10 open issues yet or the > examples. > > Section 5 mentions the following: > >    YANG library is augmented to allow servers to report the packages > >    that they implement and to associate those packages back to > > particular datastore schema. > > Does the combination of this draft and rfc7895bis somehow allow the > same package to be advertised in 2 different datastores, but with > different deviations in each datastore? I'm thinking of a case, for > example, where a package is fully supported in the running but the > package minus a few modules (or parts of modules) is supported in the > operational datastore. There seems to be a 1:1 relationship between > package and rfc7895bis schema. > So, the intention is no, not directly. My aim here is that would implement package "foo", and would implement package "modified-foo".  Package "modified-foo" would import package "foo" and also specify the set of modules that contain the deviations "foo". I didn't want a server to be able to see that I implement package "foo", but then I have all these deviations that change its behavior.  Instead, it is really implementing a different package that is based on "foo". > The packages draft doesn't include any specific leaf-list for > deviations. Section 7.2 mentions that deviations could be expressed by > including modules that happen to contain deviations. That seems a bit > inconsistent with rfc7895bis that has a specific leaf-list of > deviations (and NETCONF hello that specifically explicitly labels > deviation modules). > I'm conflicted on this one.  I don't really like the deviation list in YANG library because I regard it as a duplicate source of information, and then there is a question of which source of data do you trust.  E.g. do you process a deviation in a module that is not listed in the deviations module list? > Section 5.1 says the package must be referentially complete. I can see > the advantages of that although wondering if that might limit > flexibility of partitioning modules into packages. I could imagine use > cases for dividing a large set of modules into a few packages that > might rev independently but can still all work together (especially if > they rev in a bc manner). But maybe that just starts to introduce too > much complexity? > Yes, having partial packages may be useful.  Perhaps just adding a leaf to indicate whether a package is referentially complete could be the answer here. > I didn't understand this part of section 5.1. Can you maybe illustrate > with an example? > > The version/revision of a module listed in the package module list > > supercedes any version/revision of the module listed in a imported > > package module list.  This allows a package to resolve any > > conflicting implemented module versions/revisions in imported > > packages. > Probably best to see example B.3. in the appendix because it exactly illustrates this point. Basically: 1) Packages must explicitly list all versions of all modules they define/import. 2) If two imported packages define different versions of modules, then the package that is importing them needs a way to define which version to use. 3) A package needs a way to override the version of module specified in an imported package. > It might be a good idea to add a parent-version to the package module > (to allow tracking lineage of packages). > Agreed, or maybe allowing a revision history like modules.  Not sure which is better here.  Packages could get a lot of updates, and a long revision history would not be helpful at all. > I like the use of groupings. That allows a manager to use this as a > building block to compose a model that has a list of packages. > OK. > Having a global list of mandatory features (vs having the mandatory > feature a per-module list) means inventing the new > : format. Should we instead somehow put the > mandatory features against each module of the package? > Perhaps.  My thinking here was to have the list of features high up and very easy to find/parse. > The location leaf is a uri but then the description says it must be a > url (where the model can be retrieved). I do like that the namespace > is separate from the location, but maybe we should make location a url > type? > Yes, I was thinking that is should be a URL. > Do we need a namespace for package names in the model? > I had them in an earlier version, but I took them out, because I wasn't sure that they are really useful/required. Defining a format to make package names themselves globally unique might be sufficient. > In 7.3 we only reference module-sets and not modules. So the grouping > of modules into sets and packages must be the same? > Not necessarily. I am trying to reuse the module-set definitions as much as possible (to avoid duplication).  One issue here is that module-sets are combined then all the modules must not overlap, which doesn't make the mapping to module-sets quite so clean. > A schema can only have a single package. I think that works but it > means a server would advertise multiple schemas if it wants to support > multiple packages. I'm not sure if there are some downsides to that > (it just surprised me). > My aim here was:  - multiple packages are advertised in yang-library/packages  - datastores only report that they "implement" one [top level] package version.  [The package itself might import other packages.] If we do package selection, then for a given YANG client session, and the version of YANG library available/reported by that session, it would appear as if the server only implements one top level package for a datastore.  Different clients choosing different versions would see slightly different output depending on which package version they had selected to use. Thanks again for the review and the comments! Rob > Jason > > *From:*netmod *On Behalf Of *Robert Wilton > *Sent:* Thursday, December 20, 2018 12:45 PM > *To:* netmod@ietf.org > *Subject:* [netmod] YANG Packages > > Hi, > > I've written up an ID for a potential solution for YANG packages using > instance data: > > Abstract >    This document defines YANG packages, an organizational structure >    holding a set of related YANG modules, that can be used to simplify >    the conformance and sharing of YANG schema.  It describes how YANG >    instance data documents are used to define YANG packages, and how the >    YANG library information published by a server can be augmented with >    additional packaging related information. > > https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ > > Potentially this work may be of use as part of the YANG versioning > design team work.  In addition, if the WG likes this approach of > defining YANG packages, then it might also be useful to bind a schema > to a YANG instance data document. > > Some questions for members of the WG: > > 1) Do members of the WG agree that YANG packages is something that > needs to be solved? > > 2) Is the approach in this draft of defining these as instance data > documents a good starting point? > > 3) This approach augments YANG library-bis, reusing module-sets, but > not replacing the way that modules are reported in YANG library-bis.  > Is this the right approach? This approach tries to allow module-sets > to be reused for both schema and packages, but the YANG library-bis > rules for combining module-sets (i.e. no conflicts) may make this > harder to really reuse the module-sets for both purposes. > > Of course, any other comments or feedback is welcome and appreciated. > > Thanks, > Rob > --------------8A2BDE503AED88F64D6E2AC0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi guys,

 

I've gotten most of the way through the draft and have some initial comments. I haven't digested the section 10 open issues yet or the examples.

 

Section 5 mentions the following:

   YANG library is augmented to allow servers to report the packages

   that they implement and to associate those packages back to

   particular datastore schema.

 

Does the combination of this draft and rfc7895bis somehow allow the same package to be advertised in 2 different datastores, but with different deviations in each datastore? I'm thinking of a case, for example, where a package is fully supported in the running but the package minus a few modules (or parts of modules) is supported in the operational datastore. There seems to be a 1:1 relationship between package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that <running> would implement package "foo", and <operational> would implement package "modified-foo".  Package "modified-foo" would import package "foo" and also specify the set of modules that contain the deviations "foo".

I didn't want a server to be able to see that I implement package "foo", but then I have all these deviations that change its behavior.  Instead, it is really implementing a different package that is based on "foo".


 

The packages draft doesn't include any specific leaf-list for deviations. Section 7.2 mentions that deviations could be expressed by including modules that happen to contain deviations. That seems a bit inconsistent with rfc7895bis that has a specific leaf-list of deviations (and NETCONF hello that specifically explicitly labels deviation modules).

I'm conflicted on this one.  I don't really like the deviation list in YANG library because I regard it as a duplicate source of information, and then there is a question of which source of data do you trust.  E.g. do you process a deviation in a module that is not listed in the deviations module list?


 

Section 5.1 says the package must be referentially complete. I can see the advantages of that although wondering if that might limit flexibility of partitioning modules into packages. I could imagine use cases for dividing a large set of modules into a few packages that might rev independently but can still all work together (especially if they rev in a bc manner). But maybe that just starts to introduce too much complexity?

Yes, having partial packages may be useful.  Perhaps just adding a leaf to indicate whether a package is referentially complete could be the answer here.


 

I didn't understand this part of section 5.1. Can you maybe illustrate with an example?

      The version/revision of a module listed in the package module list

      supercedes any version/revision of the module listed in a imported

      package module list.  This allows a package to resolve any

      conflicting implemented module versions/revisions in imported

      packages.

Probably best to see example B.3. in the appendix because it exactly illustrates this point.

Basically:
1) Packages must explicitly list all versions of all modules they define/import.
2) If two imported packages define different versions of modules, then the package that is importing them needs a way to define which version to use.
3) A package needs a way to override the version of module specified in an imported package.


 

It might be a good idea to add a parent-version to the package module (to allow tracking lineage of packages).

Agreed, or maybe allowing a revision history like modules.  Not sure which is better here.  Packages could get a lot of updates, and a long revision history would not be helpful at all.


 

I like the use of groupings. That allows a manager to use this as a building block to compose a model that has a list of packages.

OK.


 

Having a global list of mandatory features (vs having the mandatory feature a per-module list) means inventing the new <module-name>:<feature> format. Should we instead somehow put the mandatory features against each module of the package?

Perhaps.  My thinking here was to have the list of features high up and very easy to find/parse.


 

The location leaf is a uri but then the description says it must be a url (where the model can be retrieved). I do like that the namespace is separate from the location, but maybe we should make location a url type?

Yes, I was thinking that is should be a URL.


 

Do we need a namespace for package names in the model?

I had them in an earlier version, but I took them out, because I wasn't sure that they are really useful/required.

Defining a format to make package names themselves globally unique might be sufficient.


 

In 7.3 we only reference module-sets and not modules. So the grouping of modules into sets and packages must be the same?

Not necessarily.

I am trying to reuse the module-set definitions as much as possible (to avoid duplication).  One issue here is that module-sets are combined then all the modules must not overlap, which doesn't make the mapping to module-sets quite so clean.


 

A schema can only have a single package. I think that works but it means a server would advertise multiple schemas if it wants to support multiple packages. I'm not sure if there are some downsides to that (it just surprised me).

My aim here was:
 - multiple packages are advertised in yang-library/packages
 - datastores only report that they "implement" one [top level] package version.  [The package itself might import other packages.]

If we do package selection, then for a given YANG client session, and the version of YANG library available/reported by that session, it would appear as if the server only implements one top level package for a datastore.  Different clients choosing different versions would see slightly different output depending on which package version they had selected to use.

Thanks again for the review and the comments!

Rob



 

Jason

 

 

 

From: netmod <netmod-bounces@ietf.org> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: netmod@ietf.org
Subject: [netmod] YANG Packages

 

Hi,

I've written up an ID for a potential solution for YANG packages using instance data:

Abstract
 
   This document defines YANG packages, an organizational structure
   holding a set of related YANG modules, that can be used to simplify
   the conformance and sharing of YANG schema.  It describes how YANG
   instance data documents are used to define YANG packages, and how the
   YANG library information published by a server can be augmented with
   additional packaging related information.

https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/

Potentially this work may be of use as part of the YANG versioning design team work.  In addition, if the WG likes this approach of defining YANG packages, then it might also be useful to bind a schema to a YANG instance data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs to be solved?

2) Is the approach in this draft of defining these as instance data documents a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not replacing the way that modules are reported in YANG library-bis.  Is this the right approach?  This approach tries to allow module-sets to be reused for both schema and packages, but the YANG library-bis rules for combining module-sets (i.e. no conflicts) may make this harder to really reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.

Thanks,
Rob

--------------8A2BDE503AED88F64D6E2AC0-- From nobody Thu Jan 24 12:34:36 2019 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 F1B1C12426A; Thu, 24 Jan 2019 12:34:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154836207489.29316.10261924074846695076@ietfa.amsl.com> Date: Thu, 24 Jan 2019 12:34:34 -0800 Archived-At: Subject: [netmod] Network Modeling (netmod) WG Virtual Meeting: 2019-02-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 20:34:35 -0000 The Network Modeling (netmod) Working Group will hold a virtual interim meeting on 2019-02-06 from 10:00 to 12:00 America/New_York. Agenda: Goal: To continue scoring the YANG Next feature requests listed here: https://github.com/netmod-wg/yang-next/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc. Non-Goal: This is NOT a YANG-next planning meeting. We only want to score the items in preparation for a planning meeting to take place at IETF 104 in Prague. Meeting Link: https://ietf.webex.com/ietf/j.php?MTID=m43c8c25cbece0879a425f3cab6bff338 Early joins may occur 5-minutes before start. Meeting number: 646 020 675 Meeting password: 5p45ZVKa Audio connection: 1-650-479-3208 Call-in toll number (US/Canada) Access code: 646 020 675 Information about remote participation: Remote participation via WebEx From nobody Fri Jan 25 02:38:47 2019 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 9A26D130F6A for ; Fri, 25 Jan 2019 02:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 A6QIWFdr-sp2 for ; Fri, 25 Jan 2019 02:38:43 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on071f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::71f]) (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 6A6A4130EBD for ; Fri, 25 Jan 2019 02:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PHDNzijDFnk+DyOJmJI3iGoiwxN1IE5avTUZfBeeNUo=; b=RBTbaoQ0vsCsRs3eNxd8QQQhNGue/KlbNsaxv6gSafoq+Bi6MqbG01MGS6oSJZNacxVsH+kBnIsludM9+kZCWgixWXWo0OUxoerWjJh23JXD11i53KjLt9IFzwpEb6o6ZGNxJF+FSTl/i/OXF78q2OqvXLxoH5ffL4+b4URtVZM= Received: from DB7PR07MB4795.eurprd07.prod.outlook.com (52.135.141.153) by DB7SPR01MB0024.eurprd07.prod.outlook.com (20.177.195.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.5; Fri, 25 Jan 2019 10:38:35 +0000 Received: from DB7PR07MB4795.eurprd07.prod.outlook.com ([fe80::c43e:f439:da1b:46c5]) by DB7PR07MB4795.eurprd07.prod.outlook.com ([fe80::c43e:f439:da1b:46c5%4]) with mapi id 15.20.1580.007; Fri, 25 Jan 2019 10:38:35 +0000 From: tom petch To: Hongji Zhao , "netmod@ietf.org" Thread-Topic: [netmod] Question about if-feature Thread-Index: AQHUtJof9Aj8qDJS/0WIqHPqu1Ttkg== Date: Fri, 25 Jan 2019 10:38:35 +0000 Message-ID: <01c201d4b499$fccbd600$4001a8c0@gateway.2wire.net> References: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P123CA0016.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::28) To DB7PR07MB4795.eurprd07.prod.outlook.com (2603:10a6:5:3c::25) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.184] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7SPR01MB0024; 6:vQRfKfG1w8v7hGkI47P54NWRgyXvVRf67q3fow/sEMA6pYpbWkdTq6j5E33rvnZLPWaW5Ji2mDln0m8p8rVlyLIdPE1EQsx57tWTVh77utgIKWhu60uH2kQbz8l9QVgM/fPBCUmxswIHwDnPUVXeNpgamJJe0ntte8nWJqAzw6tyvhye/cQ+IuxRkRLCKZqPotYOzJhhVOpDzGhrSn9YQBVcqZmUWC183tSz063gppbyLB7LX2smUVCkeJotAdgvN84leonZBFx101Ju9hSmNlteAIwiZo/Wuggqfv2dHycfRzFcHzOCFjv9TihZVxpRfRRlrti33ljq0ZBbq83JUAGb6ymddwlak9Wnq4OWcds67irOoUMaZv5kBQzj+MjCmAraCdzQNaRSXNbQ+yBFZJB7KF2+Y17Y/ZQRrDlTVI+5AsMJj7WIe++B0l+FheoYKF43hx2WdFeBb1QVrTsKyA==; 5:HLc/VzCwMYdKy8ueWNtkBZ4UJX/QcAbTZIS3vRnR3lkABQJ8HZ3wQz2yHE7ggX8SZr/zHYR00nqSdAbqIqH3awKjC1ffrfIVRvminp63AXcwqdcf7I6Mndzp/9KJJSg29lVwjTmkr4uq3l3pdZ03WSlDlUzEYbqlCOA5snqaf1G5k3TmEfnILIN7wb0+U7YKNycHojeUWwfJUwJsfstpXQ==; 7:zassRFHxEMlnq2YPF73T0CRLbsgZqMH564r+RK10IHN+QWWG3e2GJv7RZz45TuOPMk3yjtPqQoWd79NyNHsl0e1ggSjyPEN2RANjO7y9anZBHbYKsE4yDG/OpCpd8H031gpv0HeXq8V2FTWGyfNeQA== x-ms-office365-filtering-correlation-id: 1975fd2e-1471-4421-ca73-08d682b1420d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7193020); SRVR:DB7SPR01MB0024; x-ms-traffictypediagnostic: DB7SPR01MB0024: x-microsoft-antispam-prvs: x-forefront-prvs: 0928072091 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(396003)(136003)(39860400002)(199004)(189003)(13464003)(6506007)(386003)(3846002)(102836004)(6116002)(99286004)(6306002)(76176011)(81686011)(6512007)(9686003)(81816011)(6436002)(33896004)(186003)(229853002)(61296003)(19273905006)(53936002)(6486002)(26005)(44736005)(8676002)(81166006)(81156014)(1556002)(7736002)(68736007)(486006)(52116002)(305945005)(86152003)(8936002)(50226002)(2906002)(62236002)(84392002)(44716002)(256004)(25786009)(86362001)(97736004)(14496001)(14454004)(66066001)(446003)(476003)(4720700003)(106356001)(53376002)(2501003)(478600001)(71190400001)(71200400001)(105586002)(110136005)(6246003)(316002)(966005)(74416001)(7726001)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7SPR01MB0024; H:DB7PR07MB4795.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IPovTmuoQY/E6buf6qZZ7IiB69jcPYbKCJ8yxFsLLls7+YSQJBEibi0MXpQoU3+F/5sTQhcxEFF7sfXd/gjKiSrtg0GjIViWVThjRa4f3ptODRLrRYR6DE61VS/H83eyTl/niAgqJQLjKKQIMmitVcJNK/y2NVlUYuggNpBJGGmyBME0L03WXCkXPblmnRWDOFT9E/OJblc0tRvyYl+PxE2vRWj7KUJUymiFQtrTejSCbksSGxb1vhcSZLXWKBtJJkPBGcImLIw1pj/o/Gsk9L0rBo82I7hWwg4z1qEGZjEgrHvCbhgjsSkcqS5eLHp6t+/4ceEjqArNEPeYAcVwi3L16Uabwms4FPWv+xDNSgusg81N6Ep9bO7SQfeP/rrkjv0j9/xa3O/N9djVqzJSTq4/7ZC0w0L5vqHTGmX+68c= Content-Type: text/plain; charset="utf-8" Content-ID: <8E549D61CCC9C74DB91DC226AFC6FC15@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1975fd2e-1471-4421-ca73-08d682b1420d X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2019 10:38:34.6354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7SPR01MB0024 Archived-At: Subject: Re: [netmod] Question about if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 10:38:45 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkhvbmdqaSBaaGFvIiA8aG9uZ2pp LnpoYW9AZXJpY3Nzb24uY29tPg0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTcsIDIwMTkgNjox MCBBTQ0KDQo+IEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IHRoZSB1c2FnZSBvZiBpbXBvcnQuDQo+ IEluIHRoZSB0ZXN0LWltcG9ydCBtb2R1bGUgSSB3b3VsZCBsaWtlIHRvIG1ha2Ugc3VyZSBpbnRl cmZhY2UgbmFtZSBub3QNCmluIHRoZSBpbnRlcmZhY2UgbGlzdCBvZiBwaW0tYmFzZS4NCj4gU28g SSBpbXBvcnQgaWV0Zi1waW0tYmFzZSBtb2R1bGUgYW5kIGRlc2lnbiB0aGUgbXVzdCBzdGF0ZW1l bnQuDQo+DQo+IE15IHF1ZXN0aW9uIGlzLCBpZiB0aGUgZGV2aWNlIGRvZXNuJ3Qgc3VwcG9ydCBQ SU0sIHdpbGwgaXQgcmFpc2UgZXJyb3INCndoZW4gImltcG9ydCBpZXRmLXBpbS1iYXNlIj8NCg0K QW4gb2J2aW91cyBxdWVzdGlvbiB0byB3aGljaCB0aGUgYW5zd2VyIHNlZW1zIG5vdCBvYnZpb3Vz Lg0KDQpSRkM3OTUwIHMuNS42LjUgc2F5cw0KIiAgIElmIGEgc2VydmVyIGltcGxlbWVudHMgYSBt b2R1bGUgQSB0aGF0IGltcG9ydHMgYSBtb2R1bGUgQyB3aXRob3V0DQogICBzcGVjaWZ5aW5nIHRo ZSByZXZpc2lvbiBkYXRlIG9mIG1vZHVsZSBDIGFuZCB0aGUgc2VydmVyIGRvZXMgbm90DQogICBp bXBsZW1lbnQgQyAoZS5nLiwgaWYgQyBvbmx5IGRlZmluZXMgc29tZSB0eXBlZGVmcyksIHRoZSBz ZXJ2ZXIgTVVTVA0KICAgbGlzdCBtb2R1bGUgQyBpbiB0aGUgIi9tb2R1bGVzLXN0YXRlL21vZHVs ZSIgbGlzdCBmcm9tDQogICAiaWV0Zi15YW5nLWxpYnJhcnkiIFtSRkM3ODk1XSwgYW5kIGl0IE1V U1Qgc2V0IHRoZSBsZWFmDQogICAiY29uZm9ybWFuY2UtdHlwZSIgdG8gImltcG9ydCIgZm9yIHRo aXMgbW9kdWxlLg0KIg0Kc28geW91IGNhbiBmaW5kIG91dCB0aGF0IHRoZSBtb2R1bGUgaXMgbm90 IHRoZXJlIHdpdGggTkVUQ09ORi4NCg0KUkZDNzk1MCBoYXMgYSBsb3Qgb2YgTVVTVCB3aGljaCBt dXN0IGJlIGZvbGxvd2VkKCEpIGJ1dCB0aGUgbGlzdCBvZg0KZXJyb3IgbWVzc2FnZXMgaW4gcy4x NSBpcyBsaW1pdGVkIGFuZCB0aGVyZSBpcyBub3RoaW5nIHRoZXJlIHRoYXQgd291bGQNCnNlZW0g dG8gZml0IChub3IgaXMgdGhlcmUgYW55dGhpbmcgaW4gTkVUQ09ORiBub3Igd291bGQgSSBleHBl Y3QgdGhlcmUNCnRvIGJlKS4NCg0KRmFpbGluZyB0byBpbXBvcnQgd2hhdCB0aGUgbW9kdWxlIHRl bGxzIHlvdSB0byBzZWVtcyBsaWtlIGEgYmFzaWMgZXJyb3INCmFuZCBpZiB0aGUgc2VydmVyIGRv ZXMgdGhhdCwgdGhlbiBpdCBtaWdodCB3ZWxsIGZhaWwgdG8gZm9sbG93IHRoZSBNVVNUDQpJIHF1 b3RlIGFib3ZlIHNvIEkgd291bGQgbm90IHJlbHkgb24gaXQuDQoNCk1vcmUgZ2VuZXJhbGx5LCBZ QU5HIGlzIGEgbGFuZ3VhZ2UgYW5kIG1vc3QgbGFuZ3VhZ2VzIGRvIG5vdCBzcGVjaWZ5DQplcnJv ciBtZXNzYWdlcywgcmF0aGVyIHRoZXkgbGVhdmUgaXQgdXAgdG8gdGhlICdjb21waWxlcicgdG8g ZG8gd2hhdA0KdGhleSB0aGluayBhcHByb3ByaWF0ZSBhbmQgY29tbXVuaWNhdGUgdGhhdCBob3cg dGhleSB0aGluayBmaXQuDQoNClNvLCBib3R0b20gbGluZSwgY2hlY2sgaWV0Zi15YW5nLWxpYnJh cnkgYnV0IGFsc28gYXNrIHlvdXIgaW1wbGVtZW50b3IuDQoNClRvbSBQZXRjaA0KDQoNCg0KDQoN Cg0KDQo+DQo+IFRoYW5rcyBhIGxvdCENCj4NCj4gbW9kdWxlIHRlc3QtaW1wb3J0IHsNCj4gbmFt ZXNwYWNlICJodHRwOi8vZXhhbXBsZS5jb20vbnMvdGVzdCI7DQo+IHByZWZpeCB0ZjsNCj4gIGlt cG9ydCBpZXRmLXJvdXRpbmcgew0KPiAgIHByZWZpeCAicnQiOw0KPiB9DQo+DQo+IGltcG9ydCBp ZXRmLWludGVyZmFjZXMgew0KPiAgIHByZWZpeCAiaWYiOw0KPiB9DQo+DQo+IGltcG9ydCBpZXRm LXBpbS1iYXNlIHsNCj4gICBwcmVmaXggInBpbS1iYXNlIjsNCj4gfQ0KPiAgY29udGFpbmVyIGlu dGVyZmFjZXMgew0KPiAgIGxpc3QgaW50ZXJmYWNlIHsNCj4gICAga2V5ICJuYW1lIjsNCj4gICAg bGVhZiBuYW1lIHsNCj4gICAgIHR5cGUgaWY6aW50ZXJmYWNlLXJlZjsNCj4NCj4gICAgIG11c3Qg ImN1cnJlbnQoKSAhPQ0KL3J0OnJvdXRpbmcvcnQ6Y29udHJvbC1wbGFuZS1wcm90b2NvbHMvcGlt LWJhc2U6cGltL3BpbS1iYXNlOmludGVyZmFjZXMvDQpwaW0tYmFzZTppbnRlcmZhY2UvcGltLWJh c2U6bmFtZSI7DQo+DQo+ICAgIH0NCj4gICB9DQo+IH0NCj4gfQ0KPg0KPiBtb2R1bGU6IGlldGYt cGltLWJhc2UNCj4gICBhdWdtZW50IC9ydDpyb3V0aW5nL3J0OmNvbnRyb2wtcGxhbmUtcHJvdG9j b2xzOg0KPiAgICAgKy0tcncgcGltIQ0KPiAgICAgICAgICAgICAgICAgICAgKy0tcncgZ3JhY2Vm dWwtcmVzdGFydA0KPiAgICAgICAgfCAgKy0tcncgZW5hYmxlZD8gICAgYm9vbGVhbg0KPiAgICAg ICAgfCAgKy0tcncgZHVyYXRpb24/ICAgdWludDE2DQo+ICAgICAgICArLS1ydyBhZGRyZXNzLWZh bWlseSogW2FkZHJlc3MtZmFtaWx5XQ0KPiAgICAgICAgfCAgKy0tcncgYWRkcmVzcy1mYW1pbHkg ICAgICAgIGlkZW50aXR5cmVmDQo+ICAgICAgICB8ICArLS1ydyBncmFjZWZ1bC1yZXN0YXJ0DQo+ ICAgICAgICAgICAgICAgICAgICAuLi4NCj4gICAgICAgICAgICAgICAgICAgICstLXJ3IGludGVy ZmFjZXMNCj4gICAgICAgICAgICstLXJ3IGludGVyZmFjZSogW25hbWVdDQo+ICAgICAgICAgICAg ICArLS1ydyBuYW1lICAgICAgICAgICAgICBpZjppbnRlcmZhY2UtcmVmDQo+ICAgICAgICAgICAg ICArLS1ydyBhZGRyZXNzLWZhbWlseSogW2FkZHJlc3MtZmFtaWx5XQ0KPg0KPg0KPg0KPg0KPg0K PiBCUi9Ib25namkNCj4g6LW15a6P5ZCJDQo+DQo+DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0t LS0tLQ0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4NCg0K From nobody Tue Jan 29 13:14:02 2019 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 598C2130F0D; Tue, 29 Jan 2019 13:13:51 -0800 (PST) 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.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <154879643130.7537.17148195558637146851@ietfa.amsl.com> Date: Tue, 29 Jan 2019 13:13:51 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-module-tags-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 21:13:52 -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 Module Tags Authors : Christan Hopps Lou Berger Dean Bogdanovic Filename : draft-ietf-netmod-module-tags-04.txt Pages : 13 Date : 2019-01-29 Abstract: This document provides for the association of tags with YANG modules. The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading and writing a modules tags is provided. Tags may be standardized and assigned during module definition; assigned by implementations; or dynamically defined and set by users. This document provides guidance to future model writers and, as such, this document updates [RFC8407]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-module-tags-04 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-04 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 Tue Jan 29 16:55:41 2019 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 158B5131056 for ; Tue, 29 Jan 2019 16:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 B00Zb1kdMKQR for ; Tue, 29 Jan 2019 16:55:34 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10130.outbound.protection.outlook.com [40.107.1.130]) (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 611D51310B3 for ; Tue, 29 Jan 2019 16:55:27 -0800 (PST) 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:X-MS-Exchange-SenderADCheck; bh=At6MS9PLi56MiqwXJxM7pNcp2afkk9vTYyr4l7KxP1E=; b=KIxQ8MsikilTsRhgrzzTcIo7vB06YAC+gKKo7o/F09PlpXUPqoHBTgneaW87GTz8jsV0wf05605+l2DmUid5TigmNSyrC/hLYXou0QCImJX9EGm8mamFQKS4GBNELd4D0sH6itCSeHBus9/orumNfndwJTP/Z7+WMVqAsHgRzX0= Received: from VI1PR07MB3981.eurprd07.prod.outlook.com (52.134.28.141) by VI1PR07MB4606.eurprd07.prod.outlook.com (20.177.56.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10; Wed, 30 Jan 2019 00:55:24 +0000 Received: from VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::f164:23ba:8cf2:d395]) by VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::f164:23ba:8cf2:d395%3]) with mapi id 15.20.1580.014; Wed, 30 Jan 2019 00:55:24 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Robert Wilton , "netmod@ietf.org" Thread-Topic: initial comments on draft-rwilton-netmod-yang-packages Thread-Index: AdSz8QbnZ8VnKEK7ROOBuiejK/DkvQAH+FeAAQiyqtA= Date: Wed, 30 Jan 2019 00:55:24 +0000 Message-ID: References: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> In-Reply-To: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> 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=jason.sterne@nokia.com; x-originating-ip: [184.151.246.227] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB4606; 6:+/uFpmfCUj1SLh6iGGBtotII8+eKcHT7gVRcUlbfQ4G3FJhsIsR/W2vSy4TBMrdxikAOzrVZXQqwB1pdGXq53a+QXTRTGFnkxolj+51XVQsSF8wpJ7lbnKCO40gO3Gj0zm/0+iNc+MOnPrKF50kJr7wrlRa/UcIPA5RW3ZYp4wt6fr3Z6DA2Rp32YCN7tYIx6044EoG9pkqSd14RgHZAuNdWW2yhXXg5RWmt/BjgUd0spZU8eWTAQVzjgZwYqJNinHpUyXw8zG1eImpqD9zNUWPGXdd9z5koaBVvw+iNA3SjLCC9sowf9KRu+b4O22fAK3POuyNoxONiAi71K9FgxUMR6cqb1zJHAPnaEle6/1Auuxp8GyNC+Zxew32NvGl6HeXOi5qAkUcrf4wcvDgYgsu2u0jblYqAx8NxSiqWKR4jtp/VAIWSFTD0OYjoAV+0Nxtsj5p+cKGFcKT4G+UiHQ==; 5:B83yNn7tIon6Ja0Ai34nLvWrReRG8YKSVpppVx9qUioja9SsinqzT0UPDHl/3S9FV5NfVZGTAsmEwFQooa3fDpVj5NRX1xqKIgj/cUq11/6ccaEYeOOH4C4iRHUGz8oNIm6/UlDW4TA2sgWU50SSYOUdISz/gPmySUoy1vrbB6zgrK9LkxSuQPGizpABaMpQOR0y0ov9Hp75Izw39G76pg==; 7:bkrGWDAyRhSDVP1m74nMVyuLAuo7k6xbsINTAut0RS3L0p+BmFU/Z7Ds6q3QFOZ8LwylncIAe9jQ144EFbURj4smlxSwek+vR6/EgskkqOfntiREa4ihm607QZRHHhpZl9k6vYO68+rftjpysBlTuw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e63e4616-6a2f-4f97-cd8b-08d6864d9e2c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7193020); SRVR:VI1PR07MB4606; x-ms-traffictypediagnostic: VI1PR07MB4606: x-microsoft-antispam-prvs: x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(396003)(39860400002)(376002)(346002)(51914003)(51444003)(199004)(189003)(966005)(97736004)(478600001)(606006)(790700001)(3846002)(316002)(14454004)(66066001)(229853002)(6116002)(55016002)(110136005)(6436002)(86362001)(53936002)(6246003)(6306002)(68736007)(54896002)(2906002)(25786009)(81166006)(81156014)(236005)(26005)(7696005)(8676002)(8936002)(7736002)(105586002)(76176011)(186003)(106356001)(74316002)(53546011)(102836004)(6506007)(256004)(14444005)(486006)(71190400001)(2501003)(11346002)(446003)(476003)(9686003)(71200400001)(99286004)(33656002)(21314003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4606; H:VI1PR07MB3981.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: +4vf0TURpAf+9ZlpjE2iiEKwminT5cnFbm+6XT5/fvqaLrGtg2h5x/bGrTehmIESrb6UgDSZpIy4HBwl30nGcJhzqAKqBIcWRh4uUfPizkL31MRrOsTrs777ayv9tqFjCzpUdVew/j2wCXdIjp4a/5figSrwFaHs7yqN1U4irLNoD3pEwrKvymT0mKU2ESi2i6LXY57s46gdkQGc765rFP+zmn2xvieS+vwUnzkFfKjym6RD1rLoWwUiqSct2OkC6YUe783aj8+vmJiiyE2RPlWXyk/dUBhI/tnt2qPE1NmKObnjJFuPMLRszQeE5FY/T7602Hd8ZU5Ep+/3h+/roLCxoI6PlN0XTDjHIzFY9fRU8rkXVbkpcgQ5IYjAO5rxfT3YtVgNIfgh3VowelCnixh50hF6XqMHd3II05+m2pU= Content-Type: multipart/alternative; boundary="_000_VI1PR07MB39818961D1CA989CD8E1A48A9B900VI1PR07MB3981eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: e63e4616-6a2f-4f97-cd8b-08d6864d9e2c X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2019 00:55:24.2693 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4606 Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 00:55:38 -0000 --_000_VI1PR07MB39818961D1CA989CD8E1A48A9B900VI1PR07MB3981eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFJvYi4gUGxlYXNlIHNlZSBpbmxpbmUuDQpKYXNvbg0KDQpGcm9tOiBSb2JlcnQgV2ls dG9uIDxyd2lsdG9uQGNpc2NvLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI0LCAyMDE5 IDE6MTYgUE0NClRvOiBTdGVybmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkgPGphc29uLnN0 ZXJuZUBub2tpYS5jb20+OyBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBpbml0aWFsIGNv bW1lbnRzIG9uIGRyYWZ0LXJ3aWx0b24tbmV0bW9kLXlhbmctcGFja2FnZXMNCg0KDQpIaSBKYXNv biwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3IGFuZCBjb21tZW50cy4NCg0KSSd2ZSBwdXQgc29t ZSByZXNwb25zZXMgaW5saW5lIC4uLg0KT24gMjQvMDEvMjAxOSAxNDo1NiwgU3Rlcm5lLCBKYXNv biAoTm9raWEgLSBDQS9PdHRhd2EpIHdyb3RlOg0KSGkgZ3V5cywNCg0KSSd2ZSBnb3R0ZW4gbW9z dCBvZiB0aGUgd2F5IHRocm91Z2ggdGhlIGRyYWZ0IGFuZCBoYXZlIHNvbWUgaW5pdGlhbCBjb21t ZW50cy4gSSBoYXZlbid0IGRpZ2VzdGVkIHRoZSBzZWN0aW9uIDEwIG9wZW4gaXNzdWVzIHlldCBv ciB0aGUgZXhhbXBsZXMuDQoNClNlY3Rpb24gNSBtZW50aW9ucyB0aGUgZm9sbG93aW5nOg0KICAg WUFORyBsaWJyYXJ5IGlzIGF1Z21lbnRlZCB0byBhbGxvdyBzZXJ2ZXJzIHRvIHJlcG9ydCB0aGUg cGFja2FnZXMNCiAgIHRoYXQgdGhleSBpbXBsZW1lbnQgYW5kIHRvIGFzc29jaWF0ZSB0aG9zZSBw YWNrYWdlcyBiYWNrIHRvDQogICBwYXJ0aWN1bGFyIGRhdGFzdG9yZSBzY2hlbWEuDQoNCkRvZXMg dGhlIGNvbWJpbmF0aW9uIG9mIHRoaXMgZHJhZnQgYW5kIHJmYzc4OTViaXMgc29tZWhvdyBhbGxv dyB0aGUgc2FtZSBwYWNrYWdlIHRvIGJlIGFkdmVydGlzZWQgaW4gMiBkaWZmZXJlbnQgZGF0YXN0 b3JlcywgYnV0IHdpdGggZGlmZmVyZW50IGRldmlhdGlvbnMgaW4gZWFjaCBkYXRhc3RvcmU/IEkn bSB0aGlua2luZyBvZiBhIGNhc2UsIGZvciBleGFtcGxlLCB3aGVyZSBhIHBhY2thZ2UgaXMgZnVs bHkgc3VwcG9ydGVkIGluIHRoZSBydW5uaW5nIGJ1dCB0aGUgcGFja2FnZSBtaW51cyBhIGZldyBt b2R1bGVzIChvciBwYXJ0cyBvZiBtb2R1bGVzKSBpcyBzdXBwb3J0ZWQgaW4gdGhlIG9wZXJhdGlv bmFsIGRhdGFzdG9yZS4gVGhlcmUgc2VlbXMgdG8gYmUgYSAxOjEgcmVsYXRpb25zaGlwIGJldHdl ZW4gcGFja2FnZSBhbmQgcmZjNzg5NWJpcyBzY2hlbWEuDQoNClNvLCB0aGUgaW50ZW50aW9uIGlz IG5vLCBub3QgZGlyZWN0bHkuDQoNCk15IGFpbSBoZXJlIGlzIHRoYXQgPHJ1bm5pbmc+IHdvdWxk IGltcGxlbWVudCBwYWNrYWdlICJmb28iLCBhbmQgPG9wZXJhdGlvbmFsPiB3b3VsZCBpbXBsZW1l bnQgcGFja2FnZSAibW9kaWZpZWQtZm9vIi4gIFBhY2thZ2UgIm1vZGlmaWVkLWZvbyIgd291bGQg aW1wb3J0IHBhY2thZ2UgImZvbyIgYW5kIGFsc28gc3BlY2lmeSB0aGUgc2V0IG9mIG1vZHVsZXMg dGhhdCBjb250YWluIHRoZSBkZXZpYXRpb25zICJmb28iLg0KDQpJIGRpZG4ndCB3YW50IGEgc2Vy dmVyIHRvIGJlIGFibGUgdG8gc2VlIHRoYXQgSSBpbXBsZW1lbnQgcGFja2FnZSAiZm9vIiwgYnV0 IHRoZW4gSSBoYXZlIGFsbCB0aGVzZSBkZXZpYXRpb25zIHRoYXQgY2hhbmdlIGl0cyBiZWhhdmlv ci4gIEluc3RlYWQsIGl0IGlzIHJlYWxseSBpbXBsZW1lbnRpbmcgYSBkaWZmZXJlbnQgcGFja2Fn ZSB0aGF0IGlzIGJhc2VkIG9uICJmb28iLg0KDQoNCg0KVGhlIHBhY2thZ2VzIGRyYWZ0IGRvZXNu J3QgaW5jbHVkZSBhbnkgc3BlY2lmaWMgbGVhZi1saXN0IGZvciBkZXZpYXRpb25zLiBTZWN0aW9u IDcuMiBtZW50aW9ucyB0aGF0IGRldmlhdGlvbnMgY291bGQgYmUgZXhwcmVzc2VkIGJ5IGluY2x1 ZGluZyBtb2R1bGVzIHRoYXQgaGFwcGVuIHRvIGNvbnRhaW4gZGV2aWF0aW9ucy4gVGhhdCBzZWVt cyBhIGJpdCBpbmNvbnNpc3RlbnQgd2l0aCByZmM3ODk1YmlzIHRoYXQgaGFzIGEgc3BlY2lmaWMg bGVhZi1saXN0IG9mIGRldmlhdGlvbnMgKGFuZCBORVRDT05GIGhlbGxvIHRoYXQgc3BlY2lmaWNh bGx5IGV4cGxpY2l0bHkgbGFiZWxzIGRldmlhdGlvbiBtb2R1bGVzKS4NCg0KSSdtIGNvbmZsaWN0 ZWQgb24gdGhpcyBvbmUuICBJIGRvbid0IHJlYWxseSBsaWtlIHRoZSBkZXZpYXRpb24gbGlzdCBp biBZQU5HIGxpYnJhcnkgYmVjYXVzZSBJIHJlZ2FyZCBpdCBhcyBhIGR1cGxpY2F0ZSBzb3VyY2Ug b2YgaW5mb3JtYXRpb24sIGFuZCB0aGVuIHRoZXJlIGlzIGEgcXVlc3Rpb24gb2Ygd2hpY2ggc291 cmNlIG9mIGRhdGEgZG8geW91IHRydXN0LiAgRS5nLiBkbyB5b3UgcHJvY2VzcyBhIGRldmlhdGlv biBpbiBhIG1vZHVsZSB0aGF0IGlzIG5vdCBsaXN0ZWQgaW4gdGhlIGRldmlhdGlvbnMgbW9kdWxl IGxpc3Q/DQoNCls+PkpUUzogXSBHb29kIHBvaW50LiBJIHN1cHBvc2UgdGhpcyBpc3N1ZSBhcHBs aWVzIHRvZGF5IGFscmVhZHkuIGkuZS4gd2hhdCBpZiBvbmUgb2YgdGhlIG1vZHVsZXMgYWR2ZXJ0 aXNlZCBpbiB0aGUgPGhlbGxvPiBpcyBhIG1vZHVsZSBvZiBkZXZpYXRpb25zICh3aXRob3V0IGhh dmluZyBiZWVuIHJlZmVyZW5jZWQgYnkgYW5vdGhlciBtb2R1bGUgYXMgYSBkZXZpYXRpb24gbW9k dWxlKS4NCg0KDQoNClNlY3Rpb24gNS4xIHNheXMgdGhlIHBhY2thZ2UgbXVzdCBiZSByZWZlcmVu dGlhbGx5IGNvbXBsZXRlLiBJIGNhbiBzZWUgdGhlIGFkdmFudGFnZXMgb2YgdGhhdCBhbHRob3Vn aCB3b25kZXJpbmcgaWYgdGhhdCBtaWdodCBsaW1pdCBmbGV4aWJpbGl0eSBvZiBwYXJ0aXRpb25p bmcgbW9kdWxlcyBpbnRvIHBhY2thZ2VzLiBJIGNvdWxkIGltYWdpbmUgdXNlIGNhc2VzIGZvciBk aXZpZGluZyBhIGxhcmdlIHNldCBvZiBtb2R1bGVzIGludG8gYSBmZXcgcGFja2FnZXMgdGhhdCBt aWdodCByZXYgaW5kZXBlbmRlbnRseSBidXQgY2FuIHN0aWxsIGFsbCB3b3JrIHRvZ2V0aGVyIChl c3BlY2lhbGx5IGlmIHRoZXkgcmV2IGluIGEgYmMgbWFubmVyKS4gQnV0IG1heWJlIHRoYXQganVz dCBzdGFydHMgdG8gaW50cm9kdWNlIHRvbyBtdWNoIGNvbXBsZXhpdHk/DQoNClllcywgaGF2aW5n IHBhcnRpYWwgcGFja2FnZXMgbWF5IGJlIHVzZWZ1bC4gIFBlcmhhcHMganVzdCBhZGRpbmcgYSBs ZWFmIHRvIGluZGljYXRlIHdoZXRoZXIgYSBwYWNrYWdlIGlzIHJlZmVyZW50aWFsbHkgY29tcGxl dGUgY291bGQgYmUgdGhlIGFuc3dlciBoZXJlLg0KDQoNCg0KSSBkaWRuJ3QgdW5kZXJzdGFuZCB0 aGlzIHBhcnQgb2Ygc2VjdGlvbiA1LjEuIENhbiB5b3UgbWF5YmUgaWxsdXN0cmF0ZSB3aXRoIGFu IGV4YW1wbGU/DQogICAgICBUaGUgdmVyc2lvbi9yZXZpc2lvbiBvZiBhIG1vZHVsZSBsaXN0ZWQg aW4gdGhlIHBhY2thZ2UgbW9kdWxlIGxpc3QNCiAgICAgIHN1cGVyY2VkZXMgYW55IHZlcnNpb24v cmV2aXNpb24gb2YgdGhlIG1vZHVsZSBsaXN0ZWQgaW4gYSBpbXBvcnRlZA0KICAgICAgcGFja2Fn ZSBtb2R1bGUgbGlzdC4gIFRoaXMgYWxsb3dzIGEgcGFja2FnZSB0byByZXNvbHZlIGFueQ0KICAg ICAgY29uZmxpY3RpbmcgaW1wbGVtZW50ZWQgbW9kdWxlIHZlcnNpb25zL3JldmlzaW9ucyBpbiBp bXBvcnRlZA0KICAgICAgcGFja2FnZXMuDQoNClByb2JhYmx5IGJlc3QgdG8gc2VlIGV4YW1wbGUg Qi4zLiBpbiB0aGUgYXBwZW5kaXggYmVjYXVzZSBpdCBleGFjdGx5IGlsbHVzdHJhdGVzIHRoaXMg cG9pbnQuDQoNCkJhc2ljYWxseToNCjEpIFBhY2thZ2VzIG11c3QgZXhwbGljaXRseSBsaXN0IGFs bCB2ZXJzaW9ucyBvZiBhbGwgbW9kdWxlcyB0aGV5IGRlZmluZS9pbXBvcnQuDQoyKSBJZiB0d28g aW1wb3J0ZWQgcGFja2FnZXMgZGVmaW5lIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBtb2R1bGVzLCB0 aGVuIHRoZSBwYWNrYWdlIHRoYXQgaXMgaW1wb3J0aW5nIHRoZW0gbmVlZHMgYSB3YXkgdG8gZGVm aW5lIHdoaWNoIHZlcnNpb24gdG8gdXNlLg0KMykgQSBwYWNrYWdlIG5lZWRzIGEgd2F5IHRvIG92 ZXJyaWRlIHRoZSB2ZXJzaW9uIG9mIG1vZHVsZSBzcGVjaWZpZWQgaW4gYW4gaW1wb3J0ZWQgcGFj a2FnZS4NCg0KWz4+SlRTOiBdIFRoeC4gVGhhdCBleGFtcGxlIGRvZXMgaGVscC4gSSBzdXBwb3Nl IHRoZSBkZXNpZ25lciBvZiB0aGUgcGFja2FnZSBuZWVkcyB0byBjYXJlZnVsbHkgY2hlY2sgdGhh dCB0aGUgdmVyc2lvbiB0aGV5IHNlbGVjdCBjYW4gYmUgc3VjY2Vzc2Z1bGx5IHVzZWQgYnkgYWxs IHRoZSBtb2R1bGVzIGluIHRoZSBwYWNrYWdlLg0KDQpJIHRoaW5rIHRoZXJlIGlzIGEgbWlub3Ig dHlwbyBpbiBleGFtcGxlIEIuMy4gIFRoZSBleGFtcGxlLTMtcGtnIGlzIGltcG9ydGluZyAiIGV4 YW1wbGUtaW1wb3J0LTEiIGJ1dCBJIGJlbGlldmUgeW91IG1lYW50ICIgZXhhbXBsZS1pbXBvcnQt MS1wa2ciIChhbmQgc29tZSBmb3IgaW1wb3J0LTIpLg0KDQpJdCBtaWdodCBiZSBhIGdvb2QgaWRl YSB0byBhZGQgYSBwYXJlbnQtdmVyc2lvbiB0byB0aGUgcGFja2FnZSBtb2R1bGUgKHRvIGFsbG93 IHRyYWNraW5nIGxpbmVhZ2Ugb2YgcGFja2FnZXMpLg0KDQpBZ3JlZWQsIG9yIG1heWJlIGFsbG93 aW5nIGEgcmV2aXNpb24gaGlzdG9yeSBsaWtlIG1vZHVsZXMuICBOb3Qgc3VyZSB3aGljaCBpcyBi ZXR0ZXIgaGVyZS4gIFBhY2thZ2VzIGNvdWxkIGdldCBhIGxvdCBvZiB1cGRhdGVzLCBhbmQgYSBs b25nIHJldmlzaW9uIGhpc3Rvcnkgd291bGQgbm90IGJlIGhlbHBmdWwgYXQgYWxsLg0KDQpbPj5K VFM6IF0gSSB0aGluayBhIG1pbmltdW0gb2YganVzdCBzcGVjaWZ5aW5nIHRoZSBkaXJlY3QgcGFy ZW50IGlzIGVub3VnaCB0byBidWlsZCB0aGUgZnVsbCB0cmVlIG9mIGxpbmVhZ2UuIFdlIGRvbid0 IG5lZWQgYSBsb25nIGhpc3Rvcnkgb2YgTiByZXZpc2lvbnMuDQoNCg0KDQpJIGxpa2UgdGhlIHVz ZSBvZiBncm91cGluZ3MuIFRoYXQgYWxsb3dzIGEgbWFuYWdlciB0byB1c2UgdGhpcyBhcyBhIGJ1 aWxkaW5nIGJsb2NrIHRvIGNvbXBvc2UgYSBtb2RlbCB0aGF0IGhhcyBhIGxpc3Qgb2YgcGFja2Fn ZXMuDQoNCk9LLg0KDQoNCg0KSGF2aW5nIGEgZ2xvYmFsIGxpc3Qgb2YgbWFuZGF0b3J5IGZlYXR1 cmVzICh2cyBoYXZpbmcgdGhlIG1hbmRhdG9yeSBmZWF0dXJlIGEgcGVyLW1vZHVsZSBsaXN0KSBt ZWFucyBpbnZlbnRpbmcgdGhlIG5ldyA8bW9kdWxlLW5hbWU+OjxmZWF0dXJlPiBmb3JtYXQuIFNo b3VsZCB3ZSBpbnN0ZWFkIHNvbWVob3cgcHV0IHRoZSBtYW5kYXRvcnkgZmVhdHVyZXMgYWdhaW5z dCBlYWNoIG1vZHVsZSBvZiB0aGUgcGFja2FnZT8NCg0KUGVyaGFwcy4gIE15IHRoaW5raW5nIGhl cmUgd2FzIHRvIGhhdmUgdGhlIGxpc3Qgb2YgZmVhdHVyZXMgaGlnaCB1cCBhbmQgdmVyeSBlYXN5 IHRvIGZpbmQvcGFyc2UuDQoNCg0KDQpUaGUgbG9jYXRpb24gbGVhZiBpcyBhIHVyaSBidXQgdGhl biB0aGUgZGVzY3JpcHRpb24gc2F5cyBpdCBtdXN0IGJlIGEgdXJsICh3aGVyZSB0aGUgbW9kZWwg Y2FuIGJlIHJldHJpZXZlZCkuIEkgZG8gbGlrZSB0aGF0IHRoZSBuYW1lc3BhY2UgaXMgc2VwYXJh dGUgZnJvbSB0aGUgbG9jYXRpb24sIGJ1dCBtYXliZSB3ZSBzaG91bGQgbWFrZSBsb2NhdGlvbiBh IHVybCB0eXBlPw0KDQpZZXMsIEkgd2FzIHRoaW5raW5nIHRoYXQgaXMgc2hvdWxkIGJlIGEgVVJM Lg0KDQoNCg0KRG8gd2UgbmVlZCBhIG5hbWVzcGFjZSBmb3IgcGFja2FnZSBuYW1lcyBpbiB0aGUg bW9kZWw/DQoNCkkgaGFkIHRoZW0gaW4gYW4gZWFybGllciB2ZXJzaW9uLCBidXQgSSB0b29rIHRo ZW0gb3V0LCBiZWNhdXNlIEkgd2Fzbid0IHN1cmUgdGhhdCB0aGV5IGFyZSByZWFsbHkgdXNlZnVs L3JlcXVpcmVkLg0KDQpEZWZpbmluZyBhIGZvcm1hdCB0byBtYWtlIHBhY2thZ2UgbmFtZXMgdGhl bXNlbHZlcyBnbG9iYWxseSB1bmlxdWUgbWlnaHQgYmUgc3VmZmljaWVudC4NCg0KWz4+SlRTOiBd IEknbSBPSyB3aXRoIHRoYXQuIEl0IGlzIHNpbWlsYXIgdG8gaG93IHdlJ3JlIGZpbmRpbmcgdGhh dCBpdCBpcyB1c2VmdWwgdGhhdCBZQU5HIG1vZHVsZSBuYW1lcyBhcmUgZ2xvYmFsbHkgdW5pcXVl IChpLmUuIGJ5IG5hbWluZyB3aXRoIGlldGYteHh4eCBvciBjb21wYW55YWJjLXh4eCkuDQoNCg0K DQpJbiA3LjMgd2Ugb25seSByZWZlcmVuY2UgbW9kdWxlLXNldHMgYW5kIG5vdCBtb2R1bGVzLiBT byB0aGUgZ3JvdXBpbmcgb2YgbW9kdWxlcyBpbnRvIHNldHMgYW5kIHBhY2thZ2VzIG11c3QgYmUg dGhlIHNhbWU/DQoNCk5vdCBuZWNlc3NhcmlseS4NCg0KSSBhbSB0cnlpbmcgdG8gcmV1c2UgdGhl IG1vZHVsZS1zZXQgZGVmaW5pdGlvbnMgYXMgbXVjaCBhcyBwb3NzaWJsZSAodG8gYXZvaWQgZHVw bGljYXRpb24pLiAgT25lIGlzc3VlIGhlcmUgaXMgdGhhdCBtb2R1bGUtc2V0cyBhcmUgY29tYmlu ZWQgdGhlbiBhbGwgdGhlIG1vZHVsZXMgbXVzdCBub3Qgb3ZlcmxhcCwgd2hpY2ggZG9lc24ndCBt YWtlIHRoZSBtYXBwaW5nIHRvIG1vZHVsZS1zZXRzIHF1aXRlIHNvIGNsZWFuLg0KDQoNCg0KQSBz Y2hlbWEgY2FuIG9ubHkgaGF2ZSBhIHNpbmdsZSBwYWNrYWdlLiBJIHRoaW5rIHRoYXQgd29ya3Mg YnV0IGl0IG1lYW5zIGEgc2VydmVyIHdvdWxkIGFkdmVydGlzZSBtdWx0aXBsZSBzY2hlbWFzIGlm IGl0IHdhbnRzIHRvIHN1cHBvcnQgbXVsdGlwbGUgcGFja2FnZXMuIEknbSBub3Qgc3VyZSBpZiB0 aGVyZSBhcmUgc29tZSBkb3duc2lkZXMgdG8gdGhhdCAoaXQganVzdCBzdXJwcmlzZWQgbWUpLg0K DQpNeSBhaW0gaGVyZSB3YXM6DQogLSBtdWx0aXBsZSBwYWNrYWdlcyBhcmUgYWR2ZXJ0aXNlZCBp biB5YW5nLWxpYnJhcnkvcGFja2FnZXMNCiAtIGRhdGFzdG9yZXMgb25seSByZXBvcnQgdGhhdCB0 aGV5ICJpbXBsZW1lbnQiIG9uZSBbdG9wIGxldmVsXSBwYWNrYWdlIHZlcnNpb24uICBbVGhlIHBh Y2thZ2UgaXRzZWxmIG1pZ2h0IGltcG9ydCBvdGhlciBwYWNrYWdlcy5dDQoNCklmIHdlIGRvIHBh Y2thZ2Ugc2VsZWN0aW9uLCB0aGVuIGZvciBhIGdpdmVuIFlBTkcgY2xpZW50IHNlc3Npb24sIGFu ZCB0aGUgdmVyc2lvbiBvZiBZQU5HIGxpYnJhcnkgYXZhaWxhYmxlL3JlcG9ydGVkIGJ5IHRoYXQg c2Vzc2lvbiwgaXQgd291bGQgYXBwZWFyIGFzIGlmIHRoZSBzZXJ2ZXIgb25seSBpbXBsZW1lbnRz IG9uZSB0b3AgbGV2ZWwgcGFja2FnZSBmb3IgYSBkYXRhc3RvcmUuICBEaWZmZXJlbnQgY2xpZW50 cyBjaG9vc2luZyBkaWZmZXJlbnQgdmVyc2lvbnMgd291bGQgc2VlIHNsaWdodGx5IGRpZmZlcmVu dCBvdXRwdXQgZGVwZW5kaW5nIG9uIHdoaWNoIHBhY2thZ2UgdmVyc2lvbiB0aGV5IGhhZCBzZWxl Y3RlZCB0byB1c2UuDQoNClRoYW5rcyBhZ2FpbiBmb3IgdGhlIHJldmlldyBhbmQgdGhlIGNvbW1l bnRzIQ0KDQpSb2INCg0KDQoNCg0KDQpKYXNvbg0KDQoNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2Qt Ym91bmNlc0BpZXRmLm9yZz48bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhh bGYgT2YgUm9iZXJ0IFdpbHRvbg0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDIwLCAyMDE4IDEy OjQ1IFBNDQpUbzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbbmV0bW9kXSBZQU5HIFBhY2thZ2VzDQoNCg0KSGksDQoNCkkndmUgd3JpdHRlbiB1cCBh biBJRCBmb3IgYSBwb3RlbnRpYWwgc29sdXRpb24gZm9yIFlBTkcgcGFja2FnZXMgdXNpbmcgaW5z dGFuY2UgZGF0YToNCg0KQWJzdHJhY3QNCg0KDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBZ QU5HIHBhY2thZ2VzLCBhbiBvcmdhbml6YXRpb25hbCBzdHJ1Y3R1cmUNCg0KICAgaG9sZGluZyBh IHNldCBvZiByZWxhdGVkIFlBTkcgbW9kdWxlcywgdGhhdCBjYW4gYmUgdXNlZCB0byBzaW1wbGlm eQ0KDQogICB0aGUgY29uZm9ybWFuY2UgYW5kIHNoYXJpbmcgb2YgWUFORyBzY2hlbWEuICBJdCBk ZXNjcmliZXMgaG93IFlBTkcNCg0KICAgaW5zdGFuY2UgZGF0YSBkb2N1bWVudHMgYXJlIHVzZWQg dG8gZGVmaW5lIFlBTkcgcGFja2FnZXMsIGFuZCBob3cgdGhlDQoNCiAgIFlBTkcgbGlicmFyeSBp bmZvcm1hdGlvbiBwdWJsaXNoZWQgYnkgYSBzZXJ2ZXIgY2FuIGJlIGF1Z21lbnRlZCB3aXRoDQoN CiAgIGFkZGl0aW9uYWwgcGFja2FnaW5nIHJlbGF0ZWQgaW5mb3JtYXRpb24uDQoNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJ3aWx0b24tbmV0bW9kLXlhbmctcGFja2Fn ZXMvDQoNClBvdGVudGlhbGx5IHRoaXMgd29yayBtYXkgYmUgb2YgdXNlIGFzIHBhcnQgb2YgdGhl IFlBTkcgdmVyc2lvbmluZyBkZXNpZ24gdGVhbSB3b3JrLiAgSW4gYWRkaXRpb24sIGlmIHRoZSBX RyBsaWtlcyB0aGlzIGFwcHJvYWNoIG9mIGRlZmluaW5nIFlBTkcgcGFja2FnZXMsIHRoZW4gaXQg bWlnaHQgYWxzbyBiZSB1c2VmdWwgdG8gYmluZCBhIHNjaGVtYSB0byBhIFlBTkcgaW5zdGFuY2Ug ZGF0YSBkb2N1bWVudC4NCg0KU29tZSBxdWVzdGlvbnMgZm9yIG1lbWJlcnMgb2YgdGhlIFdHOg0K DQoxKSBEbyBtZW1iZXJzIG9mIHRoZSBXRyBhZ3JlZSB0aGF0IFlBTkcgcGFja2FnZXMgaXMgc29t ZXRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgc29sdmVkPw0KDQoyKSBJcyB0aGUgYXBwcm9hY2ggaW4g dGhpcyBkcmFmdCBvZiBkZWZpbmluZyB0aGVzZSBhcyBpbnN0YW5jZSBkYXRhIGRvY3VtZW50cyBh IGdvb2Qgc3RhcnRpbmcgcG9pbnQ/DQoNCjMpIFRoaXMgYXBwcm9hY2ggYXVnbWVudHMgWUFORyBs aWJyYXJ5LWJpcywgcmV1c2luZyBtb2R1bGUtc2V0cywgYnV0IG5vdCByZXBsYWNpbmcgdGhlIHdh eSB0aGF0IG1vZHVsZXMgYXJlIHJlcG9ydGVkIGluIFlBTkcgbGlicmFyeS1iaXMuICBJcyB0aGlz IHRoZSByaWdodCBhcHByb2FjaD8gIFRoaXMgYXBwcm9hY2ggdHJpZXMgdG8gYWxsb3cgbW9kdWxl LXNldHMgdG8gYmUgcmV1c2VkIGZvciBib3RoIHNjaGVtYSBhbmQgcGFja2FnZXMsIGJ1dCB0aGUg WUFORyBsaWJyYXJ5LWJpcyBydWxlcyBmb3IgY29tYmluaW5nIG1vZHVsZS1zZXRzIChpLmUuIG5v IGNvbmZsaWN0cykgbWF5IG1ha2UgdGhpcyBoYXJkZXIgdG8gcmVhbGx5IHJldXNlIHRoZSBtb2R1 bGUtc2V0cyBmb3IgYm90aCBwdXJwb3Nlcy4NCg0KT2YgY291cnNlLCBhbnkgb3RoZXIgY29tbWVu dHMgb3IgZmVlZGJhY2sgaXMgd2VsY29tZSBhbmQgYXBwcmVjaWF0ZWQuDQoNClRoYW5rcywNClJv Yg0K --_000_VI1PR07MB39818961D1CA989CD8E1A48A9B900VI1PR07MB3981eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4ubWgNCgl7bXNvLXN0eWxlLW5hbWU6 bV9oO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tQ0EiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MgUm9iLiBQbGVhc2Ugc2VlIGlubGluZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SmFzb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQiPiBSb2JlcnQgV2lsdG9uICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZn dDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAyNCwgMjAxOSAxOjE2IFBN PGJyPg0KPGI+VG86PC9iPiBTdGVybmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkgJmx0O2ph c29uLnN0ZXJuZUBub2tpYS5jb20mZ3Q7OyBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IGluaXRpYWwgY29tbWVudHMgb24gZHJhZnQtcndpbHRvbi1uZXRtb2QteWFuZy1w YWNrYWdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPkhpIEphc29uLDxvOnA+PC9vOnA+ PC9wPg0KPHA+VGhhbmtzIGZvciB0aGUgcmV2aWV3IGFuZCBjb21tZW50cy48bzpwPjwvbzpwPjwv cD4NCjxwPkkndmUgcHV0IHNvbWUgcmVzcG9uc2VzIGlubGluZSAuLi4gPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjQvMDEvMjAxOSAxNDo1NiwgU3Rlcm5l LCBKYXNvbiAoTm9raWEgLSBDQS9PdHRhd2EpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBndXlzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+SSd2ZSBnb3R0ZW4gbW9zdCBvZiB0aGUgd2F5IHRocm91Z2ggdGhl IGRyYWZ0IGFuZCBoYXZlIHNvbWUgaW5pdGlhbCBjb21tZW50cy4gSSBoYXZlbid0IGRpZ2VzdGVk IHRoZSBzZWN0aW9uIDEwIG9wZW4gaXNzdWVzIHlldCBvciB0aGUgZXhhbXBsZXMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TZWN0aW9uIDUgbWVudGlvbnMgdGhlIGZv bGxvd2luZzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5i c3A7Jm5ic3A7IFlBTkcgbGlicmFyeSBpcyBhdWdtZW50ZWQgdG8gYWxsb3cgc2VydmVycyB0byBy ZXBvcnQgdGhlIHBhY2thZ2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPiZuYnNwOyZuYnNwOyB0aGF0IHRoZXkgaW1wbGVtZW50IGFuZCB0byBhc3NvY2lhdGUg dGhvc2UgcGFja2FnZXMgYmFjayB0bzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgcGFydGljdWxhciBkYXRhc3RvcmUgc2NoZW1hLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+RG9lcyB0aGUgY29tYmluYXRpb24g b2YgdGhpcyBkcmFmdCBhbmQgcmZjNzg5NWJpcyBzb21laG93IGFsbG93IHRoZSBzYW1lIHBhY2th Z2UgdG8gYmUgYWR2ZXJ0aXNlZCBpbiAyIGRpZmZlcmVudCBkYXRhc3RvcmVzLCBidXQgd2l0aCBk aWZmZXJlbnQgZGV2aWF0aW9ucyBpbiBlYWNoIGRhdGFzdG9yZT8gSSdtDQogdGhpbmtpbmcgb2Yg YSBjYXNlLCBmb3IgZXhhbXBsZSwgd2hlcmUgYSBwYWNrYWdlIGlzIGZ1bGx5IHN1cHBvcnRlZCBp biB0aGUgcnVubmluZyBidXQgdGhlIHBhY2thZ2UgbWludXMgYSBmZXcgbW9kdWxlcyAob3IgcGFy dHMgb2YgbW9kdWxlcykgaXMgc3VwcG9ydGVkIGluIHRoZSBvcGVyYXRpb25hbCBkYXRhc3RvcmUu IFRoZXJlIHNlZW1zIHRvIGJlIGEgMToxIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHBhY2thZ2UgYW5k IHJmYzc4OTViaXMgc2NoZW1hLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwPlNvLCB0aGUgaW50ZW50aW9uIGlzIG5vLCBub3QgZGlyZWN0bHkuPG86cD48L286cD48L3A+ DQo8cD5NeSBhaW0gaGVyZSBpcyB0aGF0ICZsdDtydW5uaW5nJmd0OyB3b3VsZCBpbXBsZW1lbnQg cGFja2FnZSAmcXVvdDtmb28mcXVvdDssIGFuZCAmbHQ7b3BlcmF0aW9uYWwmZ3Q7IHdvdWxkIGlt cGxlbWVudCBwYWNrYWdlICZxdW90O21vZGlmaWVkLWZvbyZxdW90Oy4mbmJzcDsgUGFja2FnZSAm cXVvdDttb2RpZmllZC1mb28mcXVvdDsgd291bGQgaW1wb3J0IHBhY2thZ2UgJnF1b3Q7Zm9vJnF1 b3Q7IGFuZCBhbHNvIHNwZWNpZnkgdGhlIHNldCBvZiBtb2R1bGVzIHRoYXQgY29udGFpbiB0aGUg ZGV2aWF0aW9ucyAmcXVvdDtmb28mcXVvdDsuPG86cD48L286cD48L3A+DQo8cD5JIGRpZG4ndCB3 YW50IGEgc2VydmVyIHRvIGJlIGFibGUgdG8gc2VlIHRoYXQgSSBpbXBsZW1lbnQgcGFja2FnZSAm cXVvdDtmb28mcXVvdDssIGJ1dCB0aGVuIEkgaGF2ZSBhbGwgdGhlc2UgZGV2aWF0aW9ucyB0aGF0 IGNoYW5nZSBpdHMgYmVoYXZpb3IuJm5ic3A7IEluc3RlYWQsIGl0IGlzIHJlYWxseSBpbXBsZW1l bnRpbmcgYSBkaWZmZXJlbnQgcGFja2FnZSB0aGF0IGlzIGJhc2VkIG9uICZxdW90O2ZvbyZxdW90 Oy48bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPlRoZSBwYWNrYWdlcyBkcmFmdCBkb2Vzbid0IGluY2x1ZGUgYW55IHNwZWNpZmljIGxl YWYtbGlzdCBmb3IgZGV2aWF0aW9ucy4gU2VjdGlvbiA3LjIgbWVudGlvbnMgdGhhdCBkZXZpYXRp b25zIGNvdWxkIGJlIGV4cHJlc3NlZCBieSBpbmNsdWRpbmcgbW9kdWxlcyB0aGF0IGhhcHBlbiB0 byBjb250YWluIGRldmlhdGlvbnMuDQogVGhhdCBzZWVtcyBhIGJpdCBpbmNvbnNpc3RlbnQgd2l0 aCByZmM3ODk1YmlzIHRoYXQgaGFzIGEgc3BlY2lmaWMgbGVhZi1saXN0IG9mIGRldmlhdGlvbnMg KGFuZCBORVRDT05GIGhlbGxvIHRoYXQgc3BlY2lmaWNhbGx5IGV4cGxpY2l0bHkgbGFiZWxzIGRl dmlhdGlvbiBtb2R1bGVzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 cD5JJ20gY29uZmxpY3RlZCBvbiB0aGlzIG9uZS4mbmJzcDsgSSBkb24ndCByZWFsbHkgbGlrZSB0 aGUgZGV2aWF0aW9uIGxpc3QgaW4gWUFORyBsaWJyYXJ5IGJlY2F1c2UgSSByZWdhcmQgaXQgYXMg YSBkdXBsaWNhdGUgc291cmNlIG9mIGluZm9ybWF0aW9uLCBhbmQgdGhlbiB0aGVyZSBpcyBhIHF1 ZXN0aW9uIG9mIHdoaWNoIHNvdXJjZSBvZiBkYXRhIGRvIHlvdSB0cnVzdC4mbmJzcDsgRS5nLiBk byB5b3UgcHJvY2VzcyBhIGRldmlhdGlvbiBpbiBhIG1vZHVsZQ0KIHRoYXQgaXMgbm90IGxpc3Rl ZCBpbiB0aGUgZGV2aWF0aW9ucyBtb2R1bGUgbGlzdD88bzpwPjwvbzpwPjwvcD4NCjxwPjxiPjxp PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5bJmd0OyZndDtKVFM6IF0gR29vZCBwb2lu dC4gSSBzdXBwb3NlIHRoaXMgaXNzdWUgYXBwbGllcyB0b2RheSBhbHJlYWR5LiBpLmUuIHdoYXQg aWYgb25lIG9mIHRoZSBtb2R1bGVzIGFkdmVydGlzZWQgaW4gdGhlICZsdDtoZWxsbyZndDsgaXMg YSBtb2R1bGUgb2YgZGV2aWF0aW9ucyAod2l0aG91dCBoYXZpbmcgYmVlbiByZWZlcmVuY2VkIGJ5 IGFub3RoZXIgbW9kdWxlIGFzIGEgZGV2aWF0aW9uIG1vZHVsZSkuPC9zcGFuPjwvaT48L2I+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNlY3Rpb24gNS4xIHNheXMg dGhlIHBhY2thZ2UgbXVzdCBiZSByZWZlcmVudGlhbGx5IGNvbXBsZXRlLiBJIGNhbiBzZWUgdGhl IGFkdmFudGFnZXMgb2YgdGhhdCBhbHRob3VnaCB3b25kZXJpbmcgaWYgdGhhdCBtaWdodCBsaW1p dCBmbGV4aWJpbGl0eSBvZiBwYXJ0aXRpb25pbmcgbW9kdWxlcyBpbnRvIHBhY2thZ2VzLg0KIEkg Y291bGQgaW1hZ2luZSB1c2UgY2FzZXMgZm9yIGRpdmlkaW5nIGEgbGFyZ2Ugc2V0IG9mIG1vZHVs ZXMgaW50byBhIGZldyBwYWNrYWdlcyB0aGF0IG1pZ2h0IHJldiBpbmRlcGVuZGVudGx5IGJ1dCBj YW4gc3RpbGwgYWxsIHdvcmsgdG9nZXRoZXIgKGVzcGVjaWFsbHkgaWYgdGhleSByZXYgaW4gYSBi YyBtYW5uZXIpLiBCdXQgbWF5YmUgdGhhdCBqdXN0IHN0YXJ0cyB0byBpbnRyb2R1Y2UgdG9vIG11 Y2ggY29tcGxleGl0eT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD5Z ZXMsIGhhdmluZyBwYXJ0aWFsIHBhY2thZ2VzIG1heSBiZSB1c2VmdWwuJm5ic3A7IFBlcmhhcHMg anVzdCBhZGRpbmcgYSBsZWFmIHRvIGluZGljYXRlIHdoZXRoZXIgYSBwYWNrYWdlIGlzIHJlZmVy ZW50aWFsbHkgY29tcGxldGUgY291bGQgYmUgdGhlIGFuc3dlciBoZXJlLjxvOnA+PC9vOnA+PC9w Pg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBkaWRuJ3Qg dW5kZXJzdGFuZCB0aGlzIHBhcnQgb2Ygc2VjdGlvbiA1LjEuIENhbiB5b3UgbWF5YmUgaWxsdXN0 cmF0ZSB3aXRoIGFuIGV4YW1wbGU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgdmVyc2lvbi9yZXZp c2lvbiBvZiBhIG1vZHVsZSBsaXN0ZWQgaW4gdGhlIHBhY2thZ2UgbW9kdWxlIGxpc3Q8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHN1cGVyY2VkZXMgYW55IHZlcnNpb24vcmV2aXNpb24gb2YgdGhlIG1vZHVs ZSBsaXN0ZWQgaW4gYSBpbXBvcnRlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFja2FnZSBtb2R1bGUg bGlzdC4mbmJzcDsgVGhpcyBhbGxvd3MgYSBwYWNrYWdlIHRvIHJlc29sdmUgYW55PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjb25mbGljdGluZyBpbXBsZW1lbnRlZCBtb2R1bGUgdmVyc2lvbnMvcmV2aXNp b25zIGluIGltcG9ydGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYWNrYWdlcy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD5Qcm9iYWJseSBiZXN0IHRvIHNlZSBleGFtcGxl IEIuMy4gaW4gdGhlIGFwcGVuZGl4IGJlY2F1c2UgaXQgZXhhY3RseSBpbGx1c3RyYXRlcyB0aGlz IHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPHA+QmFzaWNhbGx5Ojxicj4NCjEpIFBhY2thZ2VzIG11 c3QgZXhwbGljaXRseSBsaXN0IGFsbCB2ZXJzaW9ucyBvZiBhbGwgbW9kdWxlcyB0aGV5IGRlZmlu ZS9pbXBvcnQuPGJyPg0KMikgSWYgdHdvIGltcG9ydGVkIHBhY2thZ2VzIGRlZmluZSBkaWZmZXJl bnQgdmVyc2lvbnMgb2YgbW9kdWxlcywgdGhlbiB0aGUgcGFja2FnZSB0aGF0IGlzIGltcG9ydGlu ZyB0aGVtIG5lZWRzIGEgd2F5IHRvIGRlZmluZSB3aGljaCB2ZXJzaW9uIHRvIHVzZS48YnI+DQoz KSBBIHBhY2thZ2UgbmVlZHMgYSB3YXkgdG8gb3ZlcnJpZGUgdGhlIHZlcnNpb24gb2YgbW9kdWxl IHNwZWNpZmllZCBpbiBhbiBpbXBvcnRlZCBwYWNrYWdlLjxvOnA+PC9vOnA+PC9wPg0KPHA+PGI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlsmZ3Q7Jmd0O0pUUzogXSBUaHguIFRo YXQgZXhhbXBsZSBkb2VzIGhlbHAuIEkgc3VwcG9zZSB0aGUgZGVzaWduZXIgb2YgdGhlIHBhY2th Z2UgbmVlZHMgdG8gY2FyZWZ1bGx5IGNoZWNrIHRoYXQgdGhlIHZlcnNpb24gdGhleSBzZWxlY3Qg Y2FuIGJlIHN1Y2Nlc3NmdWxseSB1c2VkIGJ5IGFsbCB0aGUgbW9kdWxlcyBpbiB0aGUgcGFja2Fn ZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQiPkkgdGhpbmsgdGhlcmUgaXMgYSBtaW5vciB0eXBvIGluIGV4YW1w bGUgQi4zLiZuYnNwOyBUaGUgZXhhbXBsZS0zLXBrZyBpcyBpbXBvcnRpbmcgJnF1b3Q7PC9zcGFu PjwvaT48L2I+DQo8Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+ZXhhbXBsZS1p bXBvcnQtMSZxdW90OyBidXQgSSBiZWxpZXZlIHlvdSBtZWFudCAmcXVvdDs8L3NwYW4+PC9pPjwv Yj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5leGFtcGxlLWltcG9ydC0x LXBrZyZxdW90OyAoYW5kIHNvbWUgZm9yIGltcG9ydC0yKS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JdCBtaWdodCBiZSBhIGdvb2QgaWRlYSB0byBh ZGQgYSBwYXJlbnQtdmVyc2lvbiB0byB0aGUgcGFja2FnZSBtb2R1bGUgKHRvIGFsbG93IHRyYWNr aW5nIGxpbmVhZ2Ugb2YgcGFja2FnZXMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwPkFncmVlZCwgb3IgbWF5YmUgYWxsb3dpbmcgYSByZXZpc2lvbiBoaXN0b3J5IGxp a2UgbW9kdWxlcy4mbmJzcDsgTm90IHN1cmUgd2hpY2ggaXMgYmV0dGVyIGhlcmUuJm5ic3A7IFBh Y2thZ2VzIGNvdWxkIGdldCBhIGxvdCBvZiB1cGRhdGVzLCBhbmQgYSBsb25nIHJldmlzaW9uIGhp c3Rvcnkgd291bGQgbm90IGJlIGhlbHBmdWwgYXQgYWxsLjxvOnA+PC9vOnA+PC9wPg0KPHA+PGI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlsmZ3Q7Jmd0O0pUUzogXSBJIHRoaW5r IGEgbWluaW11bSBvZiBqdXN0IHNwZWNpZnlpbmcgdGhlIGRpcmVjdCBwYXJlbnQgaXMgZW5vdWdo IHRvIGJ1aWxkIHRoZSBmdWxsIHRyZWUgb2YgbGluZWFnZS4gV2UgZG9uJ3QgbmVlZCBhIGxvbmcg aGlzdG9yeSBvZiBOIHJldmlzaW9ucy48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBsaWtlIHRoZSB1c2Ug b2YgZ3JvdXBpbmdzLiBUaGF0IGFsbG93cyBhIG1hbmFnZXIgdG8gdXNlIHRoaXMgYXMgYSBidWls ZGluZyBibG9jayB0byBjb21wb3NlIGEgbW9kZWwgdGhhdCBoYXMgYSBsaXN0IG9mIHBhY2thZ2Vz Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPk9LLjxvOnA+PC9vOnA+ PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SGF2aW5nIGEgZ2xvYmFsIGxpc3Qgb2YgbWFuZGF0b3J5IGZlYXR1cmVzICh2 cyBoYXZpbmcgdGhlIG1hbmRhdG9yeSBmZWF0dXJlIGEgcGVyLW1vZHVsZSBsaXN0KSBtZWFucyBp bnZlbnRpbmcgdGhlIG5ldyAmbHQ7bW9kdWxlLW5hbWUmZ3Q7OiZsdDtmZWF0dXJlJmd0OyBmb3Jt YXQuIFNob3VsZCB3ZSBpbnN0ZWFkIHNvbWVob3cgcHV0IHRoZSBtYW5kYXRvcnkgZmVhdHVyZXMg YWdhaW5zdCBlYWNoDQogbW9kdWxlIG9mIHRoZSBwYWNrYWdlPzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwPlBlcmhhcHMuJm5ic3A7IE15IHRoaW5raW5nIGhlcmUgd2Fz IHRvIGhhdmUgdGhlIGxpc3Qgb2YgZmVhdHVyZXMgaGlnaCB1cCBhbmQgdmVyeSBlYXN5IHRvIGZp bmQvcGFyc2UuPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgbG9j YXRpb24gbGVhZiBpcyBhIHVyaSBidXQgdGhlbiB0aGUgZGVzY3JpcHRpb24gc2F5cyBpdCBtdXN0 IGJlIGEgdXJsICh3aGVyZSB0aGUgbW9kZWwgY2FuIGJlIHJldHJpZXZlZCkuIEkgZG8gbGlrZSB0 aGF0IHRoZSBuYW1lc3BhY2UgaXMgc2VwYXJhdGUgZnJvbSB0aGUgbG9jYXRpb24sIGJ1dCBtYXli ZSB3ZSBzaG91bGQgbWFrZSBsb2NhdGlvbiBhIHVybCB0eXBlPzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwPlllcywgSSB3YXMgdGhpbmtpbmcgdGhhdCBpcyBzaG91bGQg YmUgYSBVUkwuPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5EbyB3ZSBu ZWVkIGEgbmFtZXNwYWNlIGZvciBwYWNrYWdlIG5hbWVzIGluIHRoZSBtb2RlbD88L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD5JIGhhZCB0aGVtIGluIGFuIGVhcmxpZXIg dmVyc2lvbiwgYnV0IEkgdG9vayB0aGVtIG91dCwgYmVjYXVzZSBJIHdhc24ndCBzdXJlIHRoYXQg dGhleSBhcmUgcmVhbGx5IHVzZWZ1bC9yZXF1aXJlZC48bzpwPjwvbzpwPjwvcD4NCjxwPkRlZmlu aW5nIGEgZm9ybWF0IHRvIG1ha2UgcGFja2FnZSBuYW1lcyB0aGVtc2VsdmVzIGdsb2JhbGx5IHVu aXF1ZSBtaWdodCBiZSBzdWZmaWNpZW50LjxvOnA+PC9vOnA+PC9wPg0KPHA+PGI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlsmZ3Q7Jmd0O0pUUzogXSBJJ20gT0sgd2l0aCB0aGF0 LiBJdCBpcyBzaW1pbGFyIHRvIGhvdyB3ZSdyZSBmaW5kaW5nIHRoYXQgaXQgaXMgdXNlZnVsIHRo YXQgWUFORyBtb2R1bGUgbmFtZXMgYXJlIGdsb2JhbGx5IHVuaXF1ZSAoaS5lLiBieSBuYW1pbmcg d2l0aCBpZXRmLXh4eHggb3IgY29tcGFueWFiYy14eHgpLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5JbiA3LjMgd2Ugb25seSByZWZlcmVuY2UgbW9kdWxlLXNldHMgYW5kIG5v dCBtb2R1bGVzLiBTbyB0aGUgZ3JvdXBpbmcgb2YgbW9kdWxlcyBpbnRvIHNldHMgYW5kIHBhY2th Z2VzIG11c3QgYmUgdGhlIHNhbWU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHA+Tm90IG5lY2Vzc2FyaWx5LjxvOnA+PC9vOnA+PC9wPg0KPHA+SSBhbSB0cnlpbmcgdG8g cmV1c2UgdGhlIG1vZHVsZS1zZXQgZGVmaW5pdGlvbnMgYXMgbXVjaCBhcyBwb3NzaWJsZSAodG8g YXZvaWQgZHVwbGljYXRpb24pLiZuYnNwOyBPbmUgaXNzdWUgaGVyZSBpcyB0aGF0IG1vZHVsZS1z ZXRzIGFyZSBjb21iaW5lZCB0aGVuIGFsbCB0aGUgbW9kdWxlcyBtdXN0IG5vdCBvdmVybGFwLCB3 aGljaCBkb2Vzbid0IG1ha2UgdGhlIG1hcHBpbmcgdG8gbW9kdWxlLXNldHMgcXVpdGUgc28gY2xl YW4uPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BIHNjaGVtYSBjYW4g b25seSBoYXZlIGEgc2luZ2xlIHBhY2thZ2UuIEkgdGhpbmsgdGhhdCB3b3JrcyBidXQgaXQgbWVh bnMgYSBzZXJ2ZXIgd291bGQgYWR2ZXJ0aXNlIG11bHRpcGxlIHNjaGVtYXMgaWYgaXQgd2FudHMg dG8gc3VwcG9ydCBtdWx0aXBsZSBwYWNrYWdlcy4gSSdtIG5vdCBzdXJlIGlmIHRoZXJlIGFyZSBz b21lIGRvd25zaWRlcyB0byB0aGF0IChpdCBqdXN0IHN1cnByaXNlZA0KIG1lKS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD5NeSBhaW0gaGVyZSB3YXM6PGJyPg0KJm5i c3A7LSBtdWx0aXBsZSBwYWNrYWdlcyBhcmUgYWR2ZXJ0aXNlZCBpbiB5YW5nLWxpYnJhcnkvcGFj a2FnZXM8YnI+DQombmJzcDstIGRhdGFzdG9yZXMgb25seSByZXBvcnQgdGhhdCB0aGV5ICZxdW90 O2ltcGxlbWVudCZxdW90OyBvbmUgW3RvcCBsZXZlbF0gcGFja2FnZSB2ZXJzaW9uLiZuYnNwOyBb VGhlIHBhY2thZ2UgaXRzZWxmIG1pZ2h0IGltcG9ydCBvdGhlciBwYWNrYWdlcy5dPG86cD48L286 cD48L3A+DQo8cD5JZiB3ZSBkbyBwYWNrYWdlIHNlbGVjdGlvbiwgdGhlbiBmb3IgYSBnaXZlbiBZ QU5HIGNsaWVudCBzZXNzaW9uLCBhbmQgdGhlIHZlcnNpb24gb2YgWUFORyBsaWJyYXJ5IGF2YWls YWJsZS9yZXBvcnRlZCBieSB0aGF0IHNlc3Npb24sIGl0IHdvdWxkIGFwcGVhciBhcyBpZiB0aGUg c2VydmVyIG9ubHkgaW1wbGVtZW50cyBvbmUgdG9wIGxldmVsIHBhY2thZ2UgZm9yIGEgZGF0YXN0 b3JlLiZuYnNwOyBEaWZmZXJlbnQgY2xpZW50cyBjaG9vc2luZyBkaWZmZXJlbnQNCiB2ZXJzaW9u cyB3b3VsZCBzZWUgc2xpZ2h0bHkgZGlmZmVyZW50IG91dHB1dCBkZXBlbmRpbmcgb24gd2hpY2gg cGFja2FnZSB2ZXJzaW9uIHRoZXkgaGFkIHNlbGVjdGVkIHRvIHVzZS48bzpwPjwvbzpwPjwvcD4N CjxwPlRoYW5rcyBhZ2FpbiBmb3IgdGhlIHJldmlldyBhbmQgdGhlIGNvbW1lbnRzITxvOnA+PC9v OnA+PC9wPg0KPHA+Um9iPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkphc29uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOndpbmRvd3RleHQiPiBuZXRtb2QNCjxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0Bp ZXRmLm9yZyI+Jmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0OzwvYT4gPGI+T24gQmVoYWxm IE9mDQo8L2I+Um9iZXJ0IFdpbHRvbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRGVjZW1i ZXIgMjAsIDIwMTggMTI6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpuZXRt b2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW25l dG1vZF0gWUFORyBQYWNrYWdlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkhpLDxvOnA+ PC9vOnA+PC9wPg0KPHA+SSd2ZSB3cml0dGVuIHVwIGFuIElEIGZvciBhIHBvdGVudGlhbCBzb2x1 dGlvbiBmb3IgWUFORyBwYWNrYWdlcyB1c2luZyBpbnN0YW5jZSBkYXRhOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4 LjBwdCA4LjBwdCA4LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tn cm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3gtc2l6aW5nOiBib3JkZXItYm94 O292ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czogNHB4O2ZvbnQtdmFyaWFu dC1saWdhdHVyZXM6IG5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IDI7 dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IDI7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O3RleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6IGlu aXRpYWw7b3ZlcmZsb3c6YXV0bzt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBjbGFzcz0ibWgiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5BYnN0cmFjdDwvc3Bhbj48L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDoj RkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgWUFORyBwYWNrYWdlcywgYW4gb3JnYW5pemF0aW9uYWwgc3RydWN0dXJlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6 I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQiPiZuYnNwOyZuYnNwOyBob2xkaW5nIGEgc2V0IG9mIHJlbGF0ZWQgWUFORyBtb2R1bGVzLCB0 aGF0IGNhbiBiZSB1c2VkIHRvIHNpbXBsaWZ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFr OmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyB0 aGUgY29uZm9ybWFuY2UgYW5kIHNoYXJpbmcgb2YgWUFORyBzY2hlbWEuJm5ic3A7IEl0IGRlc2Ny aWJlcyBob3cgWUFORzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgaW5zdGFuY2UgZGF0YSBk b2N1bWVudHMgYXJlIHVzZWQgdG8gZGVmaW5lIFlBTkcgcGFja2FnZXMsIGFuZCBob3cgdGhlPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2Jh Y2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBZQU5HIGxpYnJhcnkgaW5mb3JtYXRpb24gcHVibGlz aGVkIGJ5IGEgc2VydmVyIGNhbiBiZSBhdWdtZW50ZWQgd2l0aDwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7 d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJz cDsmbmJzcDsgYWRkaXRpb25hbCBwYWNrYWdpbmcgcmVsYXRlZCBpbmZvcm1hdGlvbi48L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHA+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtcndpbHRvbi1uZXRtb2QteWFuZy1wYWNrYWdlcy8iPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJ3aWx0b24tbmV0bW9kLXlhbmctcGFj a2FnZXMvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+UG90ZW50aWFsbHkgdGhpcyB3b3JrIG1heSBi ZSBvZiB1c2UgYXMgcGFydCBvZiB0aGUgWUFORyB2ZXJzaW9uaW5nIGRlc2lnbiB0ZWFtIHdvcmsu Jm5ic3A7IEluIGFkZGl0aW9uLCBpZiB0aGUgV0cgbGlrZXMgdGhpcyBhcHByb2FjaCBvZiBkZWZp bmluZyBZQU5HIHBhY2thZ2VzLCB0aGVuIGl0IG1pZ2h0IGFsc28gYmUgdXNlZnVsIHRvIGJpbmQg YSBzY2hlbWEgdG8gYSBZQU5HIGluc3RhbmNlIGRhdGEgZG9jdW1lbnQuPG86cD48L286cD48L3A+ DQo8cD5Tb21lIHF1ZXN0aW9ucyBmb3IgbWVtYmVycyBvZiB0aGUgV0c6PGJyPg0KPGJyPg0KMSkg RG8gbWVtYmVycyBvZiB0aGUgV0cgYWdyZWUgdGhhdCBZQU5HIHBhY2thZ2VzIGlzIHNvbWV0aGlu ZyB0aGF0IG5lZWRzIHRvIGJlIHNvbHZlZD88bzpwPjwvbzpwPjwvcD4NCjxwPjIpIElzIHRoZSBh cHByb2FjaCBpbiB0aGlzIGRyYWZ0IG9mIGRlZmluaW5nIHRoZXNlIGFzIGluc3RhbmNlIGRhdGEg ZG9jdW1lbnRzIGEgZ29vZCBzdGFydGluZyBwb2ludD88bzpwPjwvbzpwPjwvcD4NCjxwPjMpIFRo aXMgYXBwcm9hY2ggYXVnbWVudHMgWUFORyBsaWJyYXJ5LWJpcywgcmV1c2luZyBtb2R1bGUtc2V0 cywgYnV0IG5vdCByZXBsYWNpbmcgdGhlIHdheSB0aGF0IG1vZHVsZXMgYXJlIHJlcG9ydGVkIGlu IFlBTkcgbGlicmFyeS1iaXMuJm5ic3A7IElzIHRoaXMgdGhlIHJpZ2h0IGFwcHJvYWNoPyZuYnNw OyBUaGlzIGFwcHJvYWNoIHRyaWVzIHRvIGFsbG93IG1vZHVsZS1zZXRzIHRvIGJlIHJldXNlZCBm b3IgYm90aCBzY2hlbWEgYW5kIHBhY2thZ2VzLCBidXQNCiB0aGUgWUFORyBsaWJyYXJ5LWJpcyBy dWxlcyBmb3IgY29tYmluaW5nIG1vZHVsZS1zZXRzIChpLmUuIG5vIGNvbmZsaWN0cykgbWF5IG1h a2UgdGhpcyBoYXJkZXIgdG8gcmVhbGx5IHJldXNlIHRoZSBtb2R1bGUtc2V0cyBmb3IgYm90aCBw dXJwb3Nlcy48bzpwPjwvbzpwPjwvcD4NCjxwPk9mIGNvdXJzZSwgYW55IG90aGVyIGNvbW1lbnRz IG9yIGZlZWRiYWNrIGlzIHdlbGNvbWUgYW5kIGFwcHJlY2lhdGVkLjxvOnA+PC9vOnA+PC9wPg0K PHA+VGhhbmtzLDxicj4NClJvYjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR07MB39818961D1CA989CD8E1A48A9B900VI1PR07MB3981eurp_-- From nobody Tue Jan 29 17:22:22 2019 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 983E91310B9 for ; Tue, 29 Jan 2019 17:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 dtSs1vfU11MS for ; Tue, 29 Jan 2019 17:22:16 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::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 479DA1310B3 for ; Tue, 29 Jan 2019 17:22:15 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id l15-v6so19252423lja.9 for ; Tue, 29 Jan 2019 17:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=49Wk0GuOSRyeBXIZ4v3EV2K2xdYtZaC0+/TYn8SnLGE=; b=r/BqvziLuYAB3Aw7yKAstBmt0Yd7QMmLOd6hohNwgQ4k6eufKH5b7/v9A/GWWpOARE KqgGqj5vP8c5p/PrCiZTlOQ1UVMZ0qSLEwhkaeGXKrXoM+yW5/iuHgTB7DN/ywqyeLBZ ON1k5WjKf7fbpt2iBBToQNNLidoZ0teme2B0wwGuVPJBrF+P/g+2pCVlrmwrJy9Sz7SE CzWppHgHdIv0+I+eFnxP35Jxpwg4Fj2aECEmuC6mscB5YXB4ry4Jl8ONPutcclNS/SxY eki9ilAuGkaFmsxJprtOBoXwEpLKGm9S3UCj3C96C0fUPLG1TBmdZUMSZZ/jtwWNvxix m0Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=49Wk0GuOSRyeBXIZ4v3EV2K2xdYtZaC0+/TYn8SnLGE=; b=YTZLgcSv/JRkwoeba2ifvKkzVkqwrLPBccRh6I61NFffM6NZqniRzU44gAR6oI2TVQ k8pFMRYEexSdE7WMY1mwub8z3ELoA3BQ1UOVLmlBhTwkqqY47iJfqOlDIzZ7J5FuWB6W nrWJ3XT6uxwVzTCHYm045AxQp/xGJbnfqVXihFxdynZsez/gmmmAbAIex4AiUb8sSW9/ ujR+x8D4mPoCqPXCiC4l1ewMxlYtctHgG81FNE4CP5CwnZFSZaNuVH1USEnJCwEUCwl5 hcV+xAO1Mn3pNFJ8z7KkGLbxzUn8Oi+N0B6VYwyLEDrcxP5CJnHOnA+6xW+ZjXgQ7mTm ihrg== X-Gm-Message-State: AJcUukfWzAvefSSstwezGNT4iv9CV3FukJW5T79pbgF2NIXhQ6eChIh+ UksbBdYf5caMCxkdKidQ71Xs3Nlt35/uj8oLXvVgLA== X-Google-Smtp-Source: ALg8bN7D579jvcnTayGglaQSBm2CprWi4tC5FYvLUEE+ayNQtFVw5B8MToMyhXkEHxM4nAhhMogJSgd51PoTxv7E9O8= X-Received: by 2002:a2e:458b:: with SMTP id s133-v6mr24616128lja.170.1548811333286; Tue, 29 Jan 2019 17:22:13 -0800 (PST) MIME-Version: 1.0 References: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> In-Reply-To: From: Andy Bierman Date: Tue, 29 Jan 2019 17:22:02 -0800 Message-ID: To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: Robert Wilton , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000585e5d0580a2bda3" Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 01:22:21 -0000 --000000000000585e5d0580a2bda3 Content-Type: text/plain; charset="UTF-8" Hi, I originally brought up this issue in July 2015 https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ I don't think the WG ever agreed on the problem that needs to be solved, and that is still the case. In reality each server has 1 package -- its entire library. The SEMVER work shows that vendors are treating platforms as independent release trains, and not really developing loadable packages. I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, SEMVER import) and the YANG Catalog can solve the module compatibility issues. It is more of a documentation problem than a standards problem. Andy On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) < jason.sterne@nokia.com> wrote: > Thanks Rob. Please see inline. > > Jason > > > > *From:* Robert Wilton > *Sent:* Thursday, January 24, 2019 1:16 PM > *To:* Sterne, Jason (Nokia - CA/Ottawa) ; > netmod@ietf.org > *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages > > > > Hi Jason, > > Thanks for the review and comments. > > I've put some responses inline ... > > On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote: > > Hi guys, > > > > I've gotten most of the way through the draft and have some initial > comments. I haven't digested the section 10 open issues yet or the examples. > > > > Section 5 mentions the following: > > YANG library is augmented to allow servers to report the packages > > that they implement and to associate those packages back to > > particular datastore schema. > > > > Does the combination of this draft and rfc7895bis somehow allow the same > package to be advertised in 2 different datastores, but with different > deviations in each datastore? I'm thinking of a case, for example, where a > package is fully supported in the running but the package minus a few > modules (or parts of modules) is supported in the operational datastore. > There seems to be a 1:1 relationship between package and rfc7895bis schema. > > So, the intention is no, not directly. > > My aim here is that would implement package "foo", and > would implement package "modified-foo". Package > "modified-foo" would import package "foo" and also specify the set of > modules that contain the deviations "foo". > > I didn't want a server to be able to see that I implement package "foo", > but then I have all these deviations that change its behavior. Instead, it > is really implementing a different package that is based on "foo". > > > > > > The packages draft doesn't include any specific leaf-list for deviations. > Section 7.2 mentions that deviations could be expressed by including > modules that happen to contain deviations. That seems a bit inconsistent > with rfc7895bis that has a specific leaf-list of deviations (and NETCONF > hello that specifically explicitly labels deviation modules). > > I'm conflicted on this one. I don't really like the deviation list in > YANG library because I regard it as a duplicate source of information, and > then there is a question of which source of data do you trust. E.g. do you > process a deviation in a module that is not listed in the deviations module > list? > > *[>>JTS: ] Good point. I suppose this issue applies today already. i.e. > what if one of the modules advertised in the is a module of > deviations (without having been referenced by another module as a deviation > module).* > > > > > > Section 5.1 says the package must be referentially complete. I can see the > advantages of that although wondering if that might limit flexibility of > partitioning modules into packages. I could imagine use cases for dividing > a large set of modules into a few packages that might rev independently but > can still all work together (especially if they rev in a bc manner). But > maybe that just starts to introduce too much complexity? > > Yes, having partial packages may be useful. Perhaps just adding a leaf to > indicate whether a package is referentially complete could be the answer > here. > > > > > > I didn't understand this part of section 5.1. Can you maybe illustrate > with an example? > > The version/revision of a module listed in the package module list > > supercedes any version/revision of the module listed in a imported > > package module list. This allows a package to resolve any > > conflicting implemented module versions/revisions in imported > > packages. > > Probably best to see example B.3. in the appendix because it exactly > illustrates this point. > > Basically: > 1) Packages must explicitly list all versions of all modules they > define/import. > 2) If two imported packages define different versions of modules, then the > package that is importing them needs a way to define which version to use. > 3) A package needs a way to override the version of module specified in an > imported package. > > *[>>JTS: ] Thx. That example does help. I suppose the designer of the > package needs to carefully check that the version they select can be > successfully used by all the modules in the package. * > > *I think there is a minor typo in example B.3. The example-3-pkg is > importing "* *example-import-1" but I believe you meant "* *example-import-1-pkg" > (and some for import-2).* > > > > It might be a good idea to add a parent-version to the package module (to > allow tracking lineage of packages). > > Agreed, or maybe allowing a revision history like modules. Not sure which > is better here. Packages could get a lot of updates, and a long revision > history would not be helpful at all. > > *[>>JTS: ] I think a minimum of just specifying the direct parent is > enough to build the full tree of lineage. We don't need a long history of N > revisions.* > > > > > > I like the use of groupings. That allows a manager to use this as a > building block to compose a model that has a list of packages. > > OK. > > > > > > Having a global list of mandatory features (vs having the mandatory > feature a per-module list) means inventing the new : > format. Should we instead somehow put the mandatory features against each > module of the package? > > Perhaps. My thinking here was to have the list of features high up and > very easy to find/parse. > > > > > > The location leaf is a uri but then the description says it must be a url > (where the model can be retrieved). I do like that the namespace is > separate from the location, but maybe we should make location a url type? > > Yes, I was thinking that is should be a URL. > > > > > > Do we need a namespace for package names in the model? > > I had them in an earlier version, but I took them out, because I wasn't > sure that they are really useful/required. > > Defining a format to make package names themselves globally unique might > be sufficient. > > *[>>JTS: ] I'm OK with that. It is similar to how we're finding that it is > useful that YANG module names are globally unique (i.e. by naming with > ietf-xxxx or companyabc-xxx).* > > > > > > In 7.3 we only reference module-sets and not modules. So the grouping of > modules into sets and packages must be the same? > > Not necessarily. > > I am trying to reuse the module-set definitions as much as possible (to > avoid duplication). One issue here is that module-sets are combined then > all the modules must not overlap, which doesn't make the mapping to > module-sets quite so clean. > > > > > > A schema can only have a single package. I think that works but it means a > server would advertise multiple schemas if it wants to support multiple > packages. I'm not sure if there are some downsides to that (it just > surprised me). > > My aim here was: > - multiple packages are advertised in yang-library/packages > - datastores only report that they "implement" one [top level] package > version. [The package itself might import other packages.] > > If we do package selection, then for a given YANG client session, and the > version of YANG library available/reported by that session, it would appear > as if the server only implements one top level package for a datastore. > Different clients choosing different versions would see slightly different > output depending on which package version they had selected to use. > > Thanks again for the review and the comments! > > Rob > > > > > > > > Jason > > > > > > > > *From:* netmod *On > Behalf Of *Robert Wilton > *Sent:* Thursday, December 20, 2018 12:45 PM > *To:* netmod@ietf.org > *Subject:* [netmod] YANG Packages > > > > Hi, > > I've written up an ID for a potential solution for YANG packages using > instance data: > > Abstract > > > > This document defines YANG packages, an organizational structure > > holding a set of related YANG modules, that can be used to simplify > > the conformance and sharing of YANG schema. It describes how YANG > > instance data documents are used to define YANG packages, and how the > > YANG library information published by a server can be augmented with > > additional packaging related information. > > https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ > > Potentially this work may be of use as part of the YANG versioning design > team work. In addition, if the WG likes this approach of defining YANG > packages, then it might also be useful to bind a schema to a YANG instance > data document. > > Some questions for members of the WG: > > 1) Do members of the WG agree that YANG packages is something that needs > to be solved? > > 2) Is the approach in this draft of defining these as instance data > documents a good starting point? > > 3) This approach augments YANG library-bis, reusing module-sets, but not > replacing the way that modules are reported in YANG library-bis. Is this > the right approach? This approach tries to allow module-sets to be reused > for both schema and packages, but the YANG library-bis rules for combining > module-sets (i.e. no conflicts) may make this harder to really reuse the > module-sets for both purposes. > > Of course, any other comments or feedback is welcome and appreciated. > > Thanks, > Rob > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000585e5d0580a2bda3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I originally broug= ht up this issue in July 2015

I do= n't think the WG ever agreed on the problem that needs to be solved,
and that is still the case.=C2=A0

In reali= ty each server has 1 package -- its entire library. The SEMVER work shows
that vendors are treating platforms as independent release trains,= and not really
developing loadable packages.

I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, = SEMVER import)
and=C2=A0 the YANG Catalog can solve the module co= mpatibility issues. It is more of a documentation
problem than a = standards problem.


Andy
<= br>



On Tue, Jan 29, 2019 at 4:55 P= M Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:

Thanks Rob. Please = see inline.

Jason=

=C2=A0

F= rom: Robert Wilt= on <rwilton@cisco= .com>
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; netmod@ietf.org
Subject: Re: initial comments on draft-rwilton-netmod-yang-packages<= u>

=C2=A0

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottaw= a) wrote:

Hi guys,<= /u>

=C2=A0

I've gotten mos= t of the way through the draft and have some initial comments. I haven'= t digested the section 10 open issues yet or the examples.=

=C2=A0

Section 5 mentions = the following:

=C2=A0=C2=A0 YANG l= ibrary is augmented to allow servers to report the packages

=C2=A0=C2=A0 that t= hey implement and to associate those packages back to<= /p>

=C2=A0=C2=A0 partic= ular datastore schema.

=C2=A0

Does the combinatio= n of this draft and rfc7895bis somehow allow the same package to be adverti= sed in 2 different datastores, but with different deviations in each datast= ore? I'm thinking of a case, for example, where a package is fully supported in the= running but the package minus a few modules (or parts of modules) is suppo= rted in the operational datastore. There seems to be a 1:1 relationship bet= ween package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that <running> would implement package "foo&qu= ot;, and <operational> would implement package "modified-foo&quo= t;.=C2=A0 Package "modified-foo" would import package "foo&q= uot; and also specify the set of modules that contain the deviations "= foo".

I didn't want a server to be able to see that I implement package &q= uot;foo", but then I have all these deviations that change its behavio= r.=C2=A0 Instead, it is really implementing a different package that is bas= ed on "foo".

=C2=A0

=C2=A0

The packages draft = doesn't include any specific leaf-list for deviations. Section 7.2 ment= ions that deviations could be expressed by including modules that happen to= contain deviations. That seems a bit inconsistent with rfc7895bis that has a specific leaf-lis= t of deviations (and NETCONF hello that specifically explicitly labels devi= ation modules).

I'm conflicted on this one.=C2=A0 I don't really like the deviat= ion list in YANG library because I regard it as a duplicate source of infor= mation, and then there is a question of which source of data do you trust.= =C2=A0 E.g. do you process a deviation in a module that is not listed in the deviations module list?

[>>JTS: ] Good point. I sup= pose this issue applies today already. i.e. what if one of the modules adve= rtised in the <hello> is a module of deviations (without having been = referenced by another module as a deviation module).

=C2=A0

=C2=A0

Section 5.1 says th= e package must be referentially complete. I can see the advantages of that = although wondering if that might limit flexibility of partitioning modules = into packages. I could imagine use cases for dividing a large set of modules into a few p= ackages that might rev independently but can still all work together (espec= ially if they rev in a bc manner). But maybe that just starts to introduce = too much complexity?

Yes, having partial packages may be useful.=C2=A0 Perhaps just adding a = leaf to indicate whether a package is referentially complete could be the a= nswer here.

=C2=A0

=C2=A0

I didn't unders= tand this part of section 5.1. Can you maybe illustrate with an example?

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 The version/revision of a module listed in the package module = list

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 supercedes any version/revision of the module listed in a impo= rted

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 package module list.=C2=A0 This allows a package to resolve an= y

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 conflicting implemented module versions/revisions in imported<= /span>

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 packages.

Probably best to see example B.3. in the appendix because it exactly ill= ustrates this point.

Basically:
1) Packages must explicitly list all versions of all modules they define/im= port.
2) If two imported packages define different versions of modules, then the = package that is importing them needs a way to define which version to use.<= br> 3) A package needs a way to override the version of module specified in an = imported package.

[>>JTS: ] Thx. That example= does help. I suppose the designer of the package needs to carefully check = that the version they select can be successfully used by all the modules in= the package.

I think there is a minor typo in = example B.3.=C2=A0 The example-3-pkg is importing " example-import-1" but I believe= you meant " example-import-1-pkg" (and some= for import-2).

=C2=A0

It might be a good = idea to add a parent-version to the package module (to allow tracking linea= ge of packages).

Agreed, or maybe allowing a revision history like modules.=C2=A0 Not sur= e which is better here.=C2=A0 Packages could get a lot of updates, and a lo= ng revision history would not be helpful at all.

[>>JTS: ] I think a minimum= of just specifying the direct parent is enough to build the full tree of l= ineage. We don't need a long history of N revisions.

=C2=A0

=C2=A0

I like the use of groupings. Th= at allows a manager to use this as a building block to compose a model that= has a list of packages.

OK.

=C2=A0

=C2=A0

Having a global list of mandato= ry features (vs having the mandatory feature a per-module list) means inven= ting the new <module-name>:<feature> format. Should we instead = somehow put the mandatory features against each module of the package?

Perhaps.=C2=A0 My thinking here was to have the list of features high up= and very easy to find/parse.

=C2=A0

=C2=A0

The location leaf is a uri but = then the description says it must be a url (where the model can be retrieve= d). I do like that the namespace is separate from the location, but maybe w= e should make location a url type?

Yes, I was thinking that is should be a URL.

=C2=A0

=C2=A0

Do we need a namespace for pack= age names in the model?

I had them in an earlier version, but I took them out, because I wasn= 9;t sure that they are really useful/required.

Defining a format to make package names themselves globally unique might= be sufficient.

[>>JTS: ] I'm OK with t= hat. It is similar to how we're finding that it is useful that YANG mod= ule names are globally unique (i.e. by naming with ietf-xxxx or companyabc-= xxx).<= /p>

=C2=A0

=C2=A0

In 7.3 we only reference module= -sets and not modules. So the grouping of modules into sets and packages mu= st be the same?

Not necessarily.

I am trying to reuse the module-set definitions as much as possible (to = avoid duplication).=C2=A0 One issue here is that module-sets are combined t= hen all the modules must not overlap, which doesn't make the mapping to= module-sets quite so clean.

=C2=A0

=C2=A0

A schema can only have a single= package. I think that works but it means a server would advertise multiple= schemas if it wants to support multiple packages. I'm not sure if ther= e are some downsides to that (it just surprised me).

My aim here was:
=C2=A0- multiple packages are advertised in yang-library/packages
=C2=A0- datastores only report that they "implement" one [top lev= el] package version.=C2=A0 [The package itself might import other packages.= ]

If we do package selection, then for a given YANG client session, and th= e version of YANG library available/reported by that session, it would appe= ar as if the server only implements one top level package for a datastore.= =C2=A0 Different clients choosing different versions would see slightly different output depending on which package ve= rsion they had selected to use.

Thanks again for the review and the comments!

Rob

=C2=A0

=C2=A0

=C2=A0

Jason

=C2=A0

=C2=A0

=C2=A0

F= rom: netmod <netmod-bou= nces@ietf.org> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: netmod@ietf= .org
Subject: [netmod] YANG Packages

=C2=A0

Hi,

I've written up an ID for a potential solution for YANG packages usi= ng instance data:

Abstra=
ct
=C2=A0
=C2=A0=C2=A0 This document define=
s YANG packages, an organizational structure
=C2=A0=C2=A0 holding a set of rel=
ated YANG modules, that can be used to simplify
=C2=A0=C2=A0 the conformance and =
sharing of YANG schema.=C2=A0 It describes how YANG

=C2=A0=C2=A0 instance data docume=
nts are used to define YANG packages, and how the

=C2=A0=C2=A0 YANG library informa=
tion published by a server can be augmented with


=C2=A0=C2=A0 additional packaging=
 related information.

https://datatracker.ietf.org/doc/draft-rwilton-n= etmod-yang-packages/

Potentially this work may be of use as part of the YANG versioning desig= n team work.=C2=A0 In addition, if the WG likes this approach of defining Y= ANG packages, then it might also be useful to bind a schema to a YANG insta= nce data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs to= be solved?

2) Is the approach in this draft of defining these as instance data docu= ments a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not= replacing the way that modules are reported in YANG library-bis.=C2=A0 Is = this the right approach?=C2=A0 This approach tries to allow module-sets to = be reused for both schema and packages, but the YANG library-bis rules for combining module-sets (i.e. no conflicts) m= ay make this harder to really reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.=

Thanks,
Rob

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000585e5d0580a2bda3-- From nobody Tue Jan 29 23:04:41 2019 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 54C141311CA for ; Tue, 29 Jan 2019 23:04:30 -0800 (PST) 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 vM4GYoeJGtpI for ; Tue, 29 Jan 2019 23:04:28 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 DB53A1311C1 for ; Tue, 29 Jan 2019 23:04:27 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id 189so13103631qkj.8 for ; Tue, 29 Jan 2019 23:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Ztw+OWsBo0XtSLC5RT6Pm6bCfvNsMyr0AGhpZlqvLjI=; b=Ue3GaLJvuOUMpaUkA+2vx34yBsvUmMfTGu6WQrbgQSGvYeG4VMsVWmTcYOwNtS5WzN o5+/aPr+4d1rHmTO4zYjuleoFCwPXD3F+sZBVIU7jFpqvb8iw0QQuT7uJF+UmH1puHWi LxnBbv/XnzcOvg+hwsgluxLXOxWo4gsG/B8cdbCtAi7H4zXL58KCjYPHSDJcqC8uQ8Zl znIgK/S/vIKJhGwKofyyEIWr2GGhYpGWJcL863vMfT2GmrRBrosE1Wg7NmZqu0M+a2c6 IWSSFULHqQHhGvXlbQNyS03/3kgfEppaPh8/tbBvKWXHeaV+Yah+IgSbyCXC+bq3uYk0 SL8Q== 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=Ztw+OWsBo0XtSLC5RT6Pm6bCfvNsMyr0AGhpZlqvLjI=; b=qppA4/3BfvnMJYrx2HMTzZ893G2D9yuQrq+54VWKjzgv41uAfRUPkZIE1o61+nUjeO 5zFdVOXYoahJlA62uucjjaM4OQmRPm7Cyt690LU4q59QMZM6GfqtDkYKbzUuOg5V8PvM qp7d8YYKaUG1CbX7cAof3+QOPN+MoUVS+sCSRwK+7wfS/HhoTJqcDrqb/OSSCHcclK88 xmSDAbXwHunEkd1F1PSwa1+CwsE7/Zvxl2ozGZzfZsqIHt67zAlGUb0V/K+NUnZeoN3D rnj6f/djoLNyu4cgjsUwxl7CP33f9pPIeL0utnAB7ifoaqSt5/F47U5V1PfXt/c8Jtam bfDw== X-Gm-Message-State: AJcUukdQQGAnXTKRH3P43IcBBwQiuw5jX1EA7sL4FJF0P4I1cp4kJZf8 mCT3rXuo6PbZx45J088iLq0rF/gtzAYwZmD02noKmQ== X-Google-Smtp-Source: ALg8bN4t+67KUfqwVGoriI4jGiD1L9f9ULAKyW/jEm88B2kE2pW3JDfO6cruTOUgkPcaix529MOTaJu2mdv9Dn5RsVY= X-Received: by 2002:a37:4f4e:: with SMTP id d75mr26347409qkb.257.1548831866772; Tue, 29 Jan 2019 23:04:26 -0800 (PST) MIME-Version: 1.0 From: Amar Jadagoud Date: Wed, 30 Jan 2019 12:34:16 +0530 Message-ID: To: netmod@ietf.org Content-Type: multipart/alternative; boundary="0000000000003c60b30580a785ad" Archived-At: Subject: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 07:04:30 -0000 --0000000000003c60b30580a785ad Content-Type: text/plain; charset="UTF-8" Hi, I have one doubt regarding origin-filter filtering in case of parent-child hierarchy. If child class instance fields match with origin-filter value but parent class instance fields does not, then what should be the rpc-reply content? Does it need to include parent class instance record with only key fields along with child class record or it should not include both parent and child class instance record? Consider example given in 3.1.1.4 section of draft-ietf-netconf-nmda-netconf-08 : ds:operational or:intended or:system 2001:db8::2:3 60794 established In the above example, user has provided origin-filter as system and intended in the RPC request. So rpc-reply has both parent record with "intended" origin and child record with "system" origin. What if user has provided only origin-filter="system" ? Do we need to provide parent record with "intended" origin in the rpc-reply or should not provide both parent and child record ? Thanks, Amar --0000000000003c60b30580a785ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have o= ne doubt regarding origin-filter filtering in case of parent-child hierarch= y.=C2=A0

If child class = instance fields match with origin-filter value but parent class instance fi= elds does not, then what should be the rpc-reply content? Does it need to i= nclude parent class instance record with only key fields along with child c= lass record or it should not include both parent and child class instance r= ecord?=C2=A0

Consider ex= ample given in 3.1.1.4 section of draft-ietf-netconf-nmda-netconf-08 :

<rpc me= ssage-id=3D"102"
=C2=A0xmlns=3D"urn:i= etf:params:xml:ns:netconf:base:1.0">
=C2=A0&= lt;get-data xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-netconf-nmda&quo= t;
=C2=A0xmlns:ds=3D"urn:ietf:params:xml:ns:yan= g:ietf-datastores"
=C2=A0xmlns:or=3D"urn:i= etf:params:xml:ns:yang:ietf-origin">
=C2=A0&= lt;datastore>ds:operational</datastore>
=C2= =A0<subtree-filter>
=C2=A0<bgp xmlns=3D&quo= t;http://example.com/ns/bgp"= />
=C2=A0</subtree-filter>
=C2=A0<origin-filter>or:intended</origin-filter>
=C2=A0<origin-filter>or:system</origin-filter><= /div>
=C2=A0<with-origin/>
= =C2=A0</get-data>
=C2=A0</rpc>


=C2= =A0<rpc-reply message-id=3D"102"
=C2=A0= xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
=C2=A0<data xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-n= etconf-nmda">
=C2=A0<bgp xmlns=3D"http://example.com/ns/bgp"
=C2=A0xmlns:or=3D"urn:ietf:params:xml:ns:yang:ietf= -origin"
=C2=A0or:origin=3D"or:intended&qu= ot;>
=C2=A0<peer>
= =C2=A0<name>2001:db8::2:3</name>
=C2=A0&= lt;local-port or:origin=3D"or:system">60794</local-port>=
=C2=A0<state>established</state>
<= div dir=3D"auto">=C2=A0</peer>
=C2=A0</bgp&= gt;
=C2=A0</data>
=C2= =A0</rpc-reply>

In the above example, user has provided origin-filter as system and int= ended in the RPC request. So rpc-reply has both parent record with "in= tended" origin and child record with "system" origin.=C2=A0<= /div>

What if user has provide= d only origin-filter=3D"system" ? Do we need to provide parent re= cord with "intended" origin in the rpc-reply or should not provid= e both parent and child record ?=C2=A0

Thanks,=C2=A0
Amar
--0000000000003c60b30580a785ad-- From nobody Wed Jan 30 00:56:04 2019 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 A08F5130F1D for ; Wed, 30 Jan 2019 00:56:03 -0800 (PST) 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 cTo3F_CYhr9f for ; Wed, 30 Jan 2019 00:56:01 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA19128CB7 for ; Wed, 30 Jan 2019 00:56:01 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 2A3641AE012C; Wed, 30 Jan 2019 09:55:58 +0100 (CET) Date: Wed, 30 Jan 2019 09:55:58 +0100 (CET) Message-Id: <20190130.095558.1264661153680469484.mbj@tail-f.com> To: ammys.vas@gmail.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 08:56:04 -0000 Hi, Amar Jadagoud wrote: > Hi, > > I have one doubt regarding origin-filter filtering in case of parent-child > hierarchy. > > If child class instance fields match with origin-filter value but parent > class instance fields does not, then what should be the rpc-reply content? > Does it need to include parent class instance record with only key fields > along with child class record or it should not include both parent and > child class instance record? This is not special for origin-filter, but applies to all filters. The description of get-data says: Any ancestor nodes (including list keys) of nodes selected by the filters are included in the response. Hope this answers your question. /martin > > Consider example given in 3.1.1.4 section of > draft-ietf-netconf-nmda-netconf-08 : > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores" > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> > ds:operational > > > > or:intended > or:system > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > or:origin="or:intended"> > > 2001:db8::2:3 > 60794 > established > > > > > > In the above example, user has provided origin-filter as system and > intended in the RPC request. So rpc-reply has both parent record with > "intended" origin and child record with "system" origin. > > What if user has provided only origin-filter="system" ? Do we need to > provide parent record with "intended" origin in the rpc-reply or should not > provide both parent and child record ? > > Thanks, > Amar From nobody Wed Jan 30 01:46:49 2019 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 F0F7A130F28 for ; Wed, 30 Jan 2019 01:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 meJmCsABr2ta for ; Wed, 30 Jan 2019 01:46:46 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 DCD5F130F21 for ; Wed, 30 Jan 2019 01:46:45 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id q1so13276193qkf.13 for ; Wed, 30 Jan 2019 01:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YC4QDiWZ/hm3Naa0YVnEWWeTZefTnvabeLQKo0ysZO8=; b=pqnzUDfDKSHgqJr6ytZKuHWb/GrTr3xxSZuSl4ZexXw/NQjzE1w0Ey0EMNpuC1mYuL JuGMHbfcy6RAM+s8r3LQAc1cj0eNlu5wvVqzvXeylC+7hYLemwKODKpeufbu6vSyFV/f 4fLY983mQO8vvr+0+ySsw2RmCjLKyvUnhjzjXnQJOCoU3whAQvOMXu4dG3UrK6fbpKN2 u/htSKVG8veO8jogVSG9E0asZMzHL+ePqFrGjXwh2QZ5LDAUy5EyLpDM56q7njB+ukVd y51YZdjZorgESVpsibiRb6l+nsTCCnlBAZ+78xtTgKAPxpSIk8AH0GOCI4C8/6Zzb1Hi Rl3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YC4QDiWZ/hm3Naa0YVnEWWeTZefTnvabeLQKo0ysZO8=; b=UYnP5OTwCRx2CaCDSPta5Xk8kTSj9sIgKBiATdnpvsdi0ZJurcHVQlY3Tnni2/3qqM AW6j9L+U71vwRjS4RQ0V7qEYW8X/5UfbjclxGfxuHnJ9naEcMIuUpO4gN4srQraauRpt XDZ8ttb6Shh2e5OLLCmjVxaGUpXTE+ds3Oje0oZkdljXL0bZSdUPZ5sIY8GmF2rJitRD kIAMwdXBWZZwfS+LzkGZ1ge8HVrUpwI5aWbCu2ol+3VmASL1p7X/AmwFayGAdigorMYk fgA5C41oIWPw7Egf33NkHeZt2WaeXr9LxBc8s200f/p4mn1/XoA2yQTK+OsLETc2X2+k lRAA== X-Gm-Message-State: AJcUukeGz0GNI9sflPt29iHem8KJq9GqwxGNk4Qxg9zMmCP2NvyCh/n0 iNvrJ/L5IeW+z6sj88uCfJxwc0KJlRASRaAkqvb7wA== X-Google-Smtp-Source: ALg8bN5dd38yVy8jfNnhL3S+aC7akA70OwP2yjmW0HMaoESjPKbPJGBXNE3zDtA62WgKHViT8T0I+UodiX9CZtnWCfM= X-Received: by 2002:a37:4f4e:: with SMTP id d75mr26713547qkb.257.1548841604667; Wed, 30 Jan 2019 01:46:44 -0800 (PST) MIME-Version: 1.0 References: <20190130.095558.1264661153680469484.mbj@tail-f.com> In-Reply-To: <20190130.095558.1264661153680469484.mbj@tail-f.com> From: Amar Jadagoud Date: Wed, 30 Jan 2019 15:16:33 +0530 Message-ID: To: netmod@ietf.org Content-Type: multipart/alternative; boundary="000000000000a8dea30580a9c95c" Archived-At: Subject: Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 09:46:48 -0000 --000000000000a8dea30580a9c95c Content-Type: text/plain; charset="UTF-8" Hi martin, Yes. I got your point. But what should be the parent record annotation value? Whether it should be intended or origin annotation itself should not exist? Thanks, Amar On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund Hi, > > Amar Jadagoud wrote: > > Hi, > > > > I have one doubt regarding origin-filter filtering in case of > parent-child > > hierarchy. > > > > If child class instance fields match with origin-filter value but parent > > class instance fields does not, then what should be the rpc-reply > content? > > Does it need to include parent class instance record with only key fields > > along with child class record or it should not include both parent and > > child class instance record? > > This is not special for origin-filter, but applies to all filters. > The description of get-data says: > > Any ancestor nodes (including list keys) of nodes selected by > the filters are included in the response. > > Hope this answers your question. > > > /martin > > > > > > Consider example given in 3.1.1.4 section of > > draft-ietf-netconf-nmda-netconf-08 : > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores" > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> > > ds:operational > > > > > > > > or:intended > > or:system > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > > or:origin="or:intended"> > > > > 2001:db8::2:3 > > 60794 > > established > > > > > > > > > > > > In the above example, user has provided origin-filter as system and > > intended in the RPC request. So rpc-reply has both parent record with > > "intended" origin and child record with "system" origin. > > > > What if user has provided only origin-filter="system" ? Do we need to > > provide parent record with "intended" origin in the rpc-reply or should > not > > provide both parent and child record ? > > > > Thanks, > > Amar > --000000000000a8dea30580a9c95c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi martin,

Yes. I got your point. But what s= hould be the parent record annotation value? Whether it should be intended = or origin annotation itself should not exist?=C2=A0

Thanks,=C2=A0
Amar

On Wed 30 Jan, 2019, 2:25 PM Martin Bjork= lund <mbj@tail-f.com wrote:
Hi,

Amar Jadagoud <ammys.vas@gmail.com> wrote:
> Hi,
>
> I have one doubt regarding origin-filter filtering in case of parent-c= hild
> hierarchy.
>
> If child class instance fields match with origin-filter value but pare= nt
> class instance fields does not, then what should be the rpc-reply cont= ent?
> Does it need to include parent class instance record with only key fie= lds
> along with child class record or it should not include both parent and=
> child class instance record?

This is not special for origin-filter, but applies to all filters.
The description of get-data says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0Any ancestor nodes (including list keys) of node= s selected by
=C2=A0 =C2=A0 =C2=A0 =C2=A0the filters are included in the response.

Hope this answers your question.


/martin


>
> Consider example given in 3.1.1.4 section of
> draft-ietf-netconf-nmda-netconf-08 :
>
> <rpc message-id=3D"102"
>=C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"><= br> >=C2=A0 <get-data xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-netc= onf-nmda"
>=C2=A0 xmlns:ds=3D"urn:ietf:params:xml:ns:yang:ietf-datastores&quo= t;
>=C2=A0 xmlns:or=3D"urn:ietf:params:xml:ns:yang:ietf-origin"&g= t;
>=C2=A0 <datastore>ds:operational</datastore>
>=C2=A0 <subtree-filter>
>=C2=A0 <bgp xmlns=3D"http://example.com/ns/bgp&= quot;/>
>=C2=A0 </subtree-filter>
>=C2=A0 <origin-filter>or:intended</origin-filter>
>=C2=A0 <origin-filter>or:system</origin-filter>
>=C2=A0 <with-origin/>
>=C2=A0 </get-data>
>=C2=A0 </rpc>
>
>
>=C2=A0 <rpc-reply message-id=3D"102"
>=C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"><= br> >=C2=A0 <data xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-netconf-= nmda">
>=C2=A0 <bgp xmlns=3D"http://example.com/ns/bgp&= quot;
>=C2=A0 xmlns:or=3D"urn:ietf:params:xml:ns:yang:ietf-origin" >=C2=A0 or:origin=3D"or:intended">
>=C2=A0 <peer>
>=C2=A0 <name>2001:db8::2:3</name>
>=C2=A0 <local-port or:origin=3D"or:system">60794</lo= cal-port>
>=C2=A0 <state>established</state>
>=C2=A0 </peer>
>=C2=A0 </bgp>
>=C2=A0 </data>
>=C2=A0 </rpc-reply>
>
> In the above example, user has provided origin-filter as system and > intended in the RPC request. So rpc-reply has both parent record with<= br> > "intended" origin and child record with "system" o= rigin.
>
> What if user has provided only origin-filter=3D"system" ? Do= we need to
> provide parent record with "intended" origin in the rpc-repl= y or should not
> provide both parent and child record ?
>
> Thanks,
> Amar
--000000000000a8dea30580a9c95c-- From nobody Wed Jan 30 01:55:01 2019 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 8413C130F28 for ; Wed, 30 Jan 2019 01:54:59 -0800 (PST) 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 A0uutBBRjlvD for ; Wed, 30 Jan 2019 01:54:56 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF36130F21 for ; Wed, 30 Jan 2019 01:54:56 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 00B251AE0426; Wed, 30 Jan 2019 10:54:54 +0100 (CET) Date: Wed, 30 Jan 2019 10:54:54 +0100 (CET) Message-Id: <20190130.105454.2093696397478614509.mbj@tail-f.com> To: ammys.vas@gmail.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190130.095558.1264661153680469484.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 09:55:00 -0000 Hi, Amar Jadagoud wrote: > Hi martin, > > Yes. I got your point. But what should be the parent record annotation > value? Whether it should be intended or origin annotation itself should not > exist? I'm not sure I understand your question, but if the "with-origin" parameter is present in the request, the reply will contain "origin" annotations on all nodes (including ancestors) that have it. This handling is separate from any filters included. So even if you filter for "system" you might get nodes in the ancestor hierarchy with origin "intended", if you provided "with-origin". /martin > > Thanks, > Amar > > On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund > > Hi, > > > > Amar Jadagoud wrote: > > > Hi, > > > > > > I have one doubt regarding origin-filter filtering in case of > > parent-child > > > hierarchy. > > > > > > If child class instance fields match with origin-filter value but parent > > > class instance fields does not, then what should be the rpc-reply > > content? > > > Does it need to include parent class instance record with only key fields > > > along with child class record or it should not include both parent and > > > child class instance record? > > > > This is not special for origin-filter, but applies to all filters. > > The description of get-data says: > > > > Any ancestor nodes (including list keys) of nodes selected by > > the filters are included in the response. > > > > Hope this answers your question. > > > > > > /martin > > > > > > > > > > Consider example given in 3.1.1.4 section of > > > draft-ietf-netconf-nmda-netconf-08 : > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores" > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> > > > ds:operational > > > > > > > > > > > > or:intended > > > or:system > > > > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > > > or:origin="or:intended"> > > > > > > 2001:db8::2:3 > > > 60794 > > > established > > > > > > > > > > > > > > > > > > In the above example, user has provided origin-filter as system and > > > intended in the RPC request. So rpc-reply has both parent record with > > > "intended" origin and child record with "system" origin. > > > > > > What if user has provided only origin-filter="system" ? Do we need to > > > provide parent record with "intended" origin in the rpc-reply or should > > not > > > provide both parent and child record ? > > > > > > Thanks, > > > Amar > > From nobody Wed Jan 30 02:13:07 2019 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 49E94130F2F for ; Wed, 30 Jan 2019 02:13:06 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 zn8fgwqvnukr for ; Wed, 30 Jan 2019 02:13:03 -0800 (PST) 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 E1660130F2D for ; Wed, 30 Jan 2019 02:13:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id EBA3010B6; Wed, 30 Jan 2019 11:13:00 +0100 (CET) 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 DBAFrC0c372C; Wed, 30 Jan 2019 11:13:00 +0100 (CET) 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, 30 Jan 2019 11:13:00 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5ED920050; Wed, 30 Jan 2019 11:13:00 +0100 (CET) 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 56rRd3IK9PKn; Wed, 30 Jan 2019 11:13:00 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 92B232004E; Wed, 30 Jan 2019 11:13:00 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Wed, 30 Jan 2019 11:12:59 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 9E54A3005FD2DA; Wed, 30 Jan 2019 11:12:59 +0100 (CET) Date: Wed, 30 Jan 2019 11:12:59 +0100 From: Juergen Schoenwaelder To: Amar Jadagoud CC: Message-ID: <20190130101259.5pjcyrtzzj7fj3nf@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Amar Jadagoud , netmod@ietf.org References: <20190130.095558.1264661153680469484.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 10:13:06 -0000 On Wed, Jan 30, 2019 at 03:16:33PM +0530, Amar Jadagoud wrote: > > Yes. I got your point. But what should be the parent record annotation > value? Whether it should be intended or origin annotation itself should not > exist? > The origin annotation on a non-presence container has no meaning other than providing a default that is inherited downwards. In general, multiple representations are possible that all have the same meaning (but may take different amounts of space on the wire). /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 Jan 30 02:26:28 2019 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 74942130F3A for ; Wed, 30 Jan 2019 02:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 44MXg6WbwJrT for ; Wed, 30 Jan 2019 02:26:25 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 04878130F28 for ; Wed, 30 Jan 2019 02:26:24 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id v11so25638038qtc.2 for ; Wed, 30 Jan 2019 02:26:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ckUyvpQJOb9W6TTbmCfDwClOViaFPnoZNGkR0AkG2Yg=; b=VB60ONu6TQCWdppBG6rNjKkmnnmJtDPsbOOOVYyKyevbJGl8roh1D506BZseC/isS6 e4lvmXTI3DmHqC7VhHKK5O0u1wsPvVPF56/jBPGymCF3G6pK3Z2e6sBR9nfAWW44igtr Jr4XQVqOqYH8Fyn9h9oSyJk9rC75jIM7ZTRc+ETsnx7XKqpE4hzys4EzCEAD/Vx1kOkK jwDfEwrPCNoglVCs+k/aHv4299CSp6ZG8MBQSKmJPJgkUbBqKmV8D2VBKxtKWgTcDSwk QqX1EqVtQmCDr8HRr2YiTF3MQ2lakHLRV+h8EPqrqyfFJVK3EDBZWYOfBFSS/rmETSbr y3tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ckUyvpQJOb9W6TTbmCfDwClOViaFPnoZNGkR0AkG2Yg=; b=FTnwdAph0dp+vvEIAbtHtioZFP1bTyxNazuWRw9TUeFfAGwefkk0v8436xUvtqm/vp lG0VJl9EmX26pfSc7gzjmgZ/8hO0hfH1hCR8ksxORHnCbsPojrWoKfOX7b9VZJDQ8oZi SnfHYQTRl2VtcQeCzpxfRPs1KbbNS2AeLVjx/6WuNqv3HT/nQlcYi/yE4gTFmosUsk4f FXZd0938wYYuZxx+hplqKCqOx8td+qqmVaPFFDxkVVuXluNjFjHOkW1SQZr7Km4ZD5IQ 3KA95Cxctogjswov7Ef91XuMa+TiRkLZk2VLHFwV4F/i9Z4SUtgpIYJLoraqJVth0m3n eJXg== X-Gm-Message-State: AJcUukcL1gxc6ZAGV3xW+DoER9ItDi83kqrXlFHAMjxr4b0LhLHe7L13 JR2fFHeW/0tldPEMrUUbLeUPPSzyqN5QFdhcZlwRAg== X-Google-Smtp-Source: ALg8bN4+KuwOJTd/u7aQArKHqprNePSJ7NWzsCQ3ngHYiPlBnkQq7Rsd+XFQ1aOYRzRKC19DNtem37zhwu31YtXsW1w= X-Received: by 2002:a0c:fb4c:: with SMTP id b12mr27507439qvq.177.1548843983624; Wed, 30 Jan 2019 02:26:23 -0800 (PST) MIME-Version: 1.0 References: <20190130.095558.1264661153680469484.mbj@tail-f.com> <20190130.105454.2093696397478614509.mbj@tail-f.com> In-Reply-To: <20190130.105454.2093696397478614509.mbj@tail-f.com> From: Amar Jadagoud Date: Wed, 30 Jan 2019 15:56:12 +0530 Message-ID: To: netmod@ietf.org Content-Type: multipart/alternative; boundary="00000000000074df000580aa5798" Archived-At: Subject: Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 10:26:27 -0000 --00000000000074df000580aa5798 Content-Type: text/plain; charset="UTF-8" Hi Martin, Yes. I got your point. Thanks. One more question : Libyang does not return error if origin-filter is provided in the rpc request without "with-origin" parameter as ietf-netconf-nmda module does not mandate it. So we consider it as with-origin scenario and provide origin annotation in parent and child record. Does below point holds true for this case too? Thanks, Amar On Wed 30 Jan, 2019, 3:24 PM Martin Bjorklund Hi, > > Amar Jadagoud wrote: > > Hi martin, > > > > Yes. I got your point. But what should be the parent record annotation > > value? Whether it should be intended or origin annotation itself should > not > > exist? > > I'm not sure I understand your question, but if the "with-origin" > parameter is present in the request, the reply will contain "origin" > annotations on all nodes (including ancestors) that have it. This > handling is separate from any filters included. So even if you filter > for "system" you might get nodes in the ancestor hierarchy with origin > "intended", if you provided "with-origin". > > > /martin > > > > > > > > Thanks, > > Amar > > > > On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund > > > > Hi, > > > > > > Amar Jadagoud wrote: > > > > Hi, > > > > > > > > I have one doubt regarding origin-filter filtering in case of > > > parent-child > > > > hierarchy. > > > > > > > > If child class instance fields match with origin-filter value but > parent > > > > class instance fields does not, then what should be the rpc-reply > > > content? > > > > Does it need to include parent class instance record with only key > fields > > > > along with child class record or it should not include both parent > and > > > > child class instance record? > > > > > > This is not special for origin-filter, but applies to all filters. > > > The description of get-data says: > > > > > > Any ancestor nodes (including list keys) of nodes selected by > > > the filters are included in the response. > > > > > > Hope this answers your question. > > > > > > > > > /martin > > > > > > > > > > > > > > Consider example given in 3.1.1.4 section of > > > > draft-ietf-netconf-nmda-netconf-08 : > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores" > > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> > > > > ds:operational > > > > > > > > > > > > > > > > or:intended > > > > or:system > > > > > > > > > > > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > > > > or:origin="or:intended"> > > > > > > > > 2001:db8::2:3 > > > > 60794 > > > > established > > > > > > > > > > > > > > > > > > > > > > > > In the above example, user has provided origin-filter as system and > > > > intended in the RPC request. So rpc-reply has both parent record with > > > > "intended" origin and child record with "system" origin. > > > > > > > > What if user has provided only origin-filter="system" ? Do we need to > > > > provide parent record with "intended" origin in the rpc-reply or > should > > > not > > > > provide both parent and child record ? > > > > > > > > Thanks, > > > > Amar > > > > --00000000000074df000580aa5798 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,=C2=A0

Yes. I got your point. Thanks.=C2=A0

One more question :

Libyang does not return error if origin-filter is provid= ed in the rpc request without "with-origin" parameter as ietf-net= conf-nmda module does not mandate it. So we consider it as with-origin scen= ario and provide origin annotation in parent and child record. Does below p= oint holds true for this case too?=C2=A0

<= div dir=3D"auto">Thanks,=C2=A0
Amar

On Wed 30 Jan, 2019, 3:24= PM Martin Bjorklund <mbj@tail-f.com wrote:
Hi,

Amar Jadagoud <ammys.vas@gmail.com> wrote:
> Hi martin,
>
> Yes. I got your point. But what should be the parent record annotation=
> value? Whether it should be intended or origin annotation itself shoul= d not
> exist?

I'm not sure I understand your question, but if the "with-origin&q= uot;
parameter is present in the request, the reply will contain "origin&qu= ot;
annotations on all nodes (including ancestors) that have it.=C2=A0 This
handling is separate from any filters included.=C2=A0 So even if you filter=
for "system" you might get nodes in the ancestor hierarchy with o= rigin
"intended", if you provided "with-origin".


/martin




>
> Thanks,
> Amar
>
> On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund <mbj@tail-f.com wrote= :
>
> > Hi,
> >
> > Amar Jadagoud <ammys.vas@gmail.com> wrote:
> > > Hi,
> > >
> > > I have one doubt regarding origin-filter filtering in case o= f
> > parent-child
> > > hierarchy.
> > >
> > > If child class instance fields match with origin-filter valu= e but parent
> > > class instance fields does not, then what should be the rpc-= reply
> > content?
> > > Does it need to include parent class instance record with on= ly key fields
> > > along with child class record or it should not include both = parent and
> > > child class instance record?
> >
> > This is not special for origin-filter, but applies to all filters= .
> > The description of get-data says:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Any ancestor nodes (including list key= s) of nodes selected by
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the filters are included in the respon= se.
> >
> > Hope this answers your question.
> >
> >
> > /martin
> >
> >
> > >
> > > Consider example given in 3.1.1.4 section of
> > > draft-ietf-netconf-nmda-netconf-08 :
> > >
> > > <rpc message-id=3D"102"
> > >=C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0&= quot;>
> > >=C2=A0 <get-data xmlns=3D"urn:ietf:params:xml:ns:yang= :ietf-netconf-nmda"
> > >=C2=A0 xmlns:ds=3D"urn:ietf:params:xml:ns:yang:ietf-data= stores"
> > >=C2=A0 xmlns:or=3D"urn:ietf:params:xml:ns:yang:ietf-orig= in">
> > >=C2=A0 <datastore>ds:operational</datastore>
> > >=C2=A0 <subtree-filter>
> > >=C2=A0 <bgp xmlns=3D"http://example.com/ns= /bgp"/>
> > >=C2=A0 </subtree-filter>
> > >=C2=A0 <origin-filter>or:intended</origin-filter>=
> > >=C2=A0 <origin-filter>or:system</origin-filter> > > >=C2=A0 <with-origin/>
> > >=C2=A0 </get-data>
> > >=C2=A0 </rpc>
> > >
> > >
> > >=C2=A0 <rpc-reply message-id=3D"102"
> > >=C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0&= quot;>
> > >=C2=A0 <data xmlns=3D"urn:ietf:params:xml:ns:yang:iet= f-netconf-nmda">
> > >=C2=A0 <bgp xmlns=3D"http://example.com/ns= /bgp"
> > >=C2=A0 xmlns:or=3D"urn:ietf:params:xml:ns:yang:ietf-orig= in"
> > >=C2=A0 or:origin=3D"or:intended">
> > >=C2=A0 <peer>
> > >=C2=A0 <name>2001:db8::2:3</name>
> > >=C2=A0 <local-port or:origin=3D"or:system">60= 794</local-port>
> > >=C2=A0 <state>established</state>
> > >=C2=A0 </peer>
> > >=C2=A0 </bgp>
> > >=C2=A0 </data>
> > >=C2=A0 </rpc-reply>
> > >
> > > In the above example, user has provided origin-filter as sys= tem and
> > > intended in the RPC request. So rpc-reply has both parent re= cord with
> > > "intended" origin and child record with "syst= em" origin.
> > >
> > > What if user has provided only origin-filter=3D"system&= quot; ? Do we need to
> > > provide parent record with "intended" origin in th= e rpc-reply or should
> > not
> > > provide both parent and child record ?
> > >
> > > Thanks,
> > > Amar
> >
--00000000000074df000580aa5798-- From nobody Wed Jan 30 02:35:18 2019 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 70D841311D8 for ; Wed, 30 Jan 2019 02:35:16 -0800 (PST) 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, 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 aMudjQfmKbjM for ; Wed, 30 Jan 2019 02:35:14 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4422130F28 for ; Wed, 30 Jan 2019 02:35:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6074DB80ED2; Wed, 30 Jan 2019 02:35:14 -0800 (PST) To: mbj@tail-f.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, kent+ietf@watsen.net, lberger@labn.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: marek.michalak@nokia.com, netmod@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190130103514.6074DB80ED2@rfc-editor.org> Date: Wed, 30 Jan 2019 02:35:14 -0800 (PST) Archived-At: Subject: [netmod] [Technical Errata Reported] RFC7950 (5617) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 10:35:17 -0000 The following errata report has been submitted for RFC7950, "The YANG 1.1 Data Modeling Language". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5617 -------------------------------------- Type: Technical Reported by: Marek Michalak, Pawel Koch Section: 14 Original Text ------------- path-arg = absolute-path / relative-path Corrected Text -------------- path-arg = deref-expr / path-str deref-expr = deref-function-invocation *WSP "/" *WSP relative-path path-str = absolute-path / relative-path deref-function-invocation = deref-keyword *WSP "(" *WSP path-str *WSP ")" deref-keyword = %s"deref" Notes ----- This is to allow path statement to contain also "deref" function invocation which is supported by pyang and Cisco compiler but for now is not supported by i.e. yanglint validator because of above statement which does not allow for it. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7950 (draft-ietf-netmod-rfc6020bis-14) -------------------------------------- Title : The YANG 1.1 Data Modeling Language Publication Date : August 2016 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : Network Modeling Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Wed Jan 30 02:36:07 2019 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 9D49B1311DA for ; Wed, 30 Jan 2019 02:36:04 -0800 (PST) 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 HA1_QTMjvX1q for ; Wed, 30 Jan 2019 02:35:58 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D97581311D8 for ; Wed, 30 Jan 2019 02:35:57 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id E32051AE012C; Wed, 30 Jan 2019 11:35:56 +0100 (CET) Date: Wed, 30 Jan 2019 11:35:56 +0100 (CET) Message-Id: <20190130.113556.191284102173613639.mbj@tail-f.com> To: ammys.vas@gmail.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190130.105454.2093696397478614509.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 10:36:06 -0000 Amar Jadagoud wrote: > Hi Martin, > > Yes. I got your point. Thanks. > > One more question : > > Libyang does not return error if origin-filter is provided in the rpc > request without "with-origin" parameter as ietf-netconf-nmda module does > not mandate it. Yes, this is intentional. "with-origin" is orthogonal from any filters. > So we consider it as with-origin scenario and provide > origin annotation in parent and child record. If the client didn't pass the "with-origin" parameter, the server should not fill in the "origin" annotations, even if "origin-filter" was passed. /martin > Does below point holds true > for this case too? > > Thanks, > Amar > > On Wed 30 Jan, 2019, 3:24 PM Martin Bjorklund > > Hi, > > > > Amar Jadagoud wrote: > > > Hi martin, > > > > > > Yes. I got your point. But what should be the parent record annotation > > > value? Whether it should be intended or origin annotation itself should > > not > > > exist? > > > > I'm not sure I understand your question, but if the "with-origin" > > parameter is present in the request, the reply will contain "origin" > > annotations on all nodes (including ancestors) that have it. This > > handling is separate from any filters included. So even if you filter > > for "system" you might get nodes in the ancestor hierarchy with origin > > "intended", if you provided "with-origin". > > > > > > /martin > > > > > > > > > > > > > > Thanks, > > > Amar > > > > > > On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund > > > > > > Hi, > > > > > > > > Amar Jadagoud wrote: > > > > > Hi, > > > > > > > > > > I have one doubt regarding origin-filter filtering in case of > > > > parent-child > > > > > hierarchy. > > > > > > > > > > If child class instance fields match with origin-filter value but > > parent > > > > > class instance fields does not, then what should be the rpc-reply > > > > content? > > > > > Does it need to include parent class instance record with only key > > fields > > > > > along with child class record or it should not include both parent > > and > > > > > child class instance record? > > > > > > > > This is not special for origin-filter, but applies to all filters. > > > > The description of get-data says: > > > > > > > > Any ancestor nodes (including list keys) of nodes selected by > > > > the filters are included in the response. > > > > > > > > Hope this answers your question. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > Consider example given in 3.1.1.4 section of > > > > > draft-ietf-netconf-nmda-netconf-08 : > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores" > > > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> > > > > > ds:operational > > > > > > > > > > > > > > > > > > > > or:intended > > > > > or:system > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > > > > > or:origin="or:intended"> > > > > > > > > > > 2001:db8::2:3 > > > > > 60794 > > > > > established > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the above example, user has provided origin-filter as system and > > > > > intended in the RPC request. So rpc-reply has both parent record with > > > > > "intended" origin and child record with "system" origin. > > > > > > > > > > What if user has provided only origin-filter="system" ? Do we need to > > > > > provide parent record with "intended" origin in the rpc-reply or > > should > > > > not > > > > > provide both parent and child record ? > > > > > > > > > > Thanks, > > > > > Amar > > > > > > From nobody Wed Jan 30 02:45:58 2019 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 415FA1311DA for ; Wed, 30 Jan 2019 02:45:57 -0800 (PST) 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 JFeqnlKFYHVd for ; Wed, 30 Jan 2019 02:45:54 -0800 (PST) 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 E2D92130F44 for ; Wed, 30 Jan 2019 02:45:53 -0800 (PST) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id EC6C662657; Wed, 30 Jan 2019 11:45:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1548845152; bh=tLCXKwOBzt9gqNjB22MwLyAT8lpLf61j+JfsCy0za4Q=; h=From:To:Date; b=xl1cK24ZxSER36rs55GuGf9zyDwcm+wS6EvmBKf6n70DMcpKOj4xvR2YxhFCuJE/3 QPXgd86q5+WnevpbKfLOBpKe6GBZ/cbvI6mPlBRQ+G9AMQhLrKYWRCK/zZcOfwi1rn 4KMjYZYUnRu0oE33XRWnn8d4S1y7McjldT/5CIMg= Message-ID: From: Ladislav Lhotka To: RFC Errata System , mbj@tail-f.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, kent+ietf@watsen.net, lberger@labn.net Cc: marek.michalak@nokia.com, netmod@ietf.org Date: Wed, 30 Jan 2019 11:45:51 +0100 In-Reply-To: <20190130103514.6074DB80ED2@rfc-editor.org> References: <20190130103514.6074DB80ED2@rfc-editor.org> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.4 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] [Technical Errata Reported] RFC7950 (5617) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 10:45:57 -0000 Hi, this erratum should be rejected. It is a substantial technical change of the spec, and section 9.9.2 doesn't indicate any possibility of using deref(). Lada On Wed, 2019-01-30 at 02:35 -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC7950, > "The YANG 1.1 Data Modeling Language". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5617 > > -------------------------------------- > Type: Technical > Reported by: Marek Michalak, Pawel Koch > > Section: 14 > > Original Text > ------------- > path-arg = absolute-path / relative-path > > Corrected Text > -------------- > path-arg = deref-expr / path-str > > deref-expr = deref-function-invocation *WSP "/" *WSP > relative-path > > path-str = absolute-path / relative-path > > deref-function-invocation = deref-keyword *WSP > "(" *WSP path-str *WSP ")" > > deref-keyword = %s"deref" > > Notes > ----- > This is to allow path statement to contain also "deref" function invocation > which is supported by pyang and Cisco compiler but for now is not supported by > i.e. yanglint validator because of above statement which does not allow for > it. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7950 (draft-ietf-netmod-rfc6020bis-14) > -------------------------------------- > Title : The YANG 1.1 Data Modeling Language > Publication Date : August 2016 > Author(s) : M. Bjorklund, Ed. > Category : PROPOSED STANDARD > Source : Network Modeling > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > 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 Jan 30 02:46:19 2019 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 0DA0D1311DA for ; Wed, 30 Jan 2019 02:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 4Ddn6exobMQ3 for ; Wed, 30 Jan 2019 02:46:15 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 6C032130F44 for ; Wed, 30 Jan 2019 02:46:15 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id r14so25743013qtp.1 for ; Wed, 30 Jan 2019 02:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=EQUaf2uioHbidA7KgDteYKsd2rtyLIMkvseJIqU3RRc=; b=ql6re8ADGLWlgIywaZZLxJmL8pEE7B+D0XilZYgnrpDYdt/iWTHBNjjofMHLMlR4DZ SG20DzXVo5sv5+debiz25jiIZgO086/arDJMokJKX0EHxTgrkAeNmKdDYtZ7bjaKnZxa pg1/IFwCg/x1CkSG3g+WmLTiLRsYW9fy7gs8rNy3Ha/m0YIoGl898vSJehka4vieabql ubmbJtdmbXrKKvz9Q+WpJiDEgHnVucb3aDKJ8Ugqg3d5qmXOlsP+p8n0s91KzAavD/Ew y0hTgrkZkbzh7t4rrQHNpVXFT51odQebxr4JH3dshGGzs1dSoVPfybXrYA2adDE/I1rb gQxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=EQUaf2uioHbidA7KgDteYKsd2rtyLIMkvseJIqU3RRc=; b=M4VAF1mDQqP7eV88gUtT8JvWtCMb97u9i5VDM4Y9oRb1QEW16l0072J+5cT3RF0zkN t3Q7x5IEMS/RdxlJiRkDMHUMOSrc3pROz0JiYVdMFiKYNQHFaenmJPrV48w3f3VGP3GN 4B0kb6F+jyA2WfBdxY7B93WGF+1AGpI6gcwkUpnjvEvAtZHwbRaXbibeHc7a475Q6mwr poRKs+buVYoDB7rSsM1sfoLm8oTwQzrhqumULAGxDYWPQ1yHYzPtRTEtmTdbRcK2JH2e lI/7iovALLsue74DXLTPR1idZQPhyJsdy2H2dI4YJEr6epnv7SwGbZE5sOjERTHZcd+k rf5Q== X-Gm-Message-State: AJcUukfLpyEeKEJPr+d6bj+G02eLnCZu7V7kMT80wJzURQiWeqQEvCkN CEExbXcEcdbbmsn0NssYS2FNmdeZUT8ugMVhCXtGZA== X-Google-Smtp-Source: ALg8bN50/N9ySBJR/Eqd6mMv7+HU1glW+5F/68PIwo8RlrDOA86AFnm+Btjabjx+MtwGspB0vCHLLs5kYAYySMTvJx0= X-Received: by 2002:a0c:fb4c:: with SMTP id b12mr27559090qvq.177.1548845174363; Wed, 30 Jan 2019 02:46:14 -0800 (PST) MIME-Version: 1.0 References: <20190130.105454.2093696397478614509.mbj@tail-f.com> <20190130.113556.191284102173613639.mbj@tail-f.com> In-Reply-To: <20190130.113556.191284102173613639.mbj@tail-f.com> From: Amar Jadagoud Date: Wed, 30 Jan 2019 16:16:02 +0530 Message-ID: To: netmod@ietf.org Content-Type: multipart/alternative; boundary="0000000000006e1d610580aa9ee8" Archived-At: Subject: Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 10:46:18 -0000 --0000000000006e1d610580aa9ee8 Content-Type: text/plain; charset="UTF-8" So do you mean that origin-filter needs to be applied on the response data but origin annotation should not be provided in the rpc-reply? On Wed 30 Jan, 2019, 4:05 PM Martin Bjorklund Amar Jadagoud wrote: > > Hi Martin, > > > > Yes. I got your point. Thanks. > > > > One more question : > > > > Libyang does not return error if origin-filter is provided in the rpc > > request without "with-origin" parameter as ietf-netconf-nmda module does > > not mandate it. > > Yes, this is intentional. "with-origin" is orthogonal from any > filters. > > > So we consider it as with-origin scenario and provide > > origin annotation in parent and child record. > > If the client didn't pass the "with-origin" parameter, the server > should not fill in the "origin" annotations, even if "origin-filter" > was passed. > > > /martin > > > > Does below point holds true > > for this case too? > > > > > > > Thanks, > > Amar > > > > On Wed 30 Jan, 2019, 3:24 PM Martin Bjorklund > > > > Hi, > > > > > > Amar Jadagoud wrote: > > > > Hi martin, > > > > > > > > Yes. I got your point. But what should be the parent record > annotation > > > > value? Whether it should be intended or origin annotation itself > should > > > not > > > > exist? > > > > > > I'm not sure I understand your question, but if the "with-origin" > > > parameter is present in the request, the reply will contain "origin" > > > annotations on all nodes (including ancestors) that have it. This > > > handling is separate from any filters included. So even if you filter > > > for "system" you might get nodes in the ancestor hierarchy with origin > > > "intended", if you provided "with-origin". > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > Thanks, > > > > Amar > > > > > > > > On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund > > > > > > > > Hi, > > > > > > > > > > Amar Jadagoud wrote: > > > > > > Hi, > > > > > > > > > > > > I have one doubt regarding origin-filter filtering in case of > > > > > parent-child > > > > > > hierarchy. > > > > > > > > > > > > If child class instance fields match with origin-filter value but > > > parent > > > > > > class instance fields does not, then what should be the rpc-reply > > > > > content? > > > > > > Does it need to include parent class instance record with only > key > > > fields > > > > > > along with child class record or it should not include both > parent > > > and > > > > > > child class instance record? > > > > > > > > > > This is not special for origin-filter, but applies to all filters. > > > > > The description of get-data says: > > > > > > > > > > Any ancestor nodes (including list keys) of nodes selected > by > > > > > the filters are included in the response. > > > > > > > > > > Hope this answers your question. > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > Consider example given in 3.1.1.4 section of > > > > > > draft-ietf-netconf-nmda-netconf-08 : > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores" > > > > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> > > > > > > ds:operational > > > > > > > > > > > > > > > > > > > > > > > > or:intended > > > > > > or:system > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > > > > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > > > > > > or:origin="or:intended"> > > > > > > > > > > > > 2001:db8::2:3 > > > > > > 60794 > > > > > > established > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the above example, user has provided origin-filter as system > and > > > > > > intended in the RPC request. So rpc-reply has both parent record > with > > > > > > "intended" origin and child record with "system" origin. > > > > > > > > > > > > What if user has provided only origin-filter="system" ? Do we > need to > > > > > > provide parent record with "intended" origin in the rpc-reply or > > > should > > > > > not > > > > > > provide both parent and child record ? > > > > > > > > > > > > Thanks, > > > > > > Amar > > > > > > > > > --0000000000006e1d610580aa9ee8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So do you mean that origin-filter needs to be applie= d on the response data but origin annotation should not be provided in the = rpc-reply?=C2=A0

On Wed = 30 Jan, 2019, 4:05 PM Martin Bjorklund <mbj@tail-f.com wrote:
Amar Ja= dagoud <ammys.vas@gmail.com> wrote:
> Hi Martin,
>
> Yes. I got your point. Thanks.
>
> One more question :
>
> Libyang does not return error if origin-filter is provided in the rpc<= br> > request without "with-origin" parameter as ietf-netconf-nmda= module does
> not mandate it.

Yes, this is intentional.=C2=A0 "with-origin" is orthogonal from = any
filters.

> So we consider it as with-origin scenario and provide
> origin annotation in parent and child record.

If the client didn't pass the "with-origin" parameter, the se= rver
should not fill in the "origin" annotations, even if "origin= -filter"
was passed.


/martin


> Does below point holds true
> for this case too?



>
> Thanks,
> Amar
>
> On Wed 30 Jan, 2019, 3:24 PM Martin Bjorklund <mbj@tail-f.com wrote= :
>
> > Hi,
> >
> > Amar Jadagoud <ammys.vas@gmail.com> wrote:
> > > Hi martin,
> > >
> > > Yes. I got your point. But what should be the parent record = annotation
> > > value? Whether it should be intended or origin annotation it= self should
> > not
> > > exist?
> >
> > I'm not sure I understand your question, but if the "wit= h-origin"
> > parameter is present in the request, the reply will contain "= ;origin"
> > annotations on all nodes (including ancestors) that have it.=C2= =A0 This
> > handling is separate from any filters included.=C2=A0 So even if = you filter
> > for "system" you might get nodes in the ancestor hierar= chy with origin
> > "intended", if you provided "with-origin". > >
> >
> > /martin
> >
> >
> >
> >
> > >
> > > Thanks,
> > > Amar
> > >
> > > On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund <mbj@tail-f.com= wrote:
> > >
> > > > Hi,
> > > >
> > > > Amar Jadagoud <ammys.vas@gmail.com> wrote: > > > > > Hi,
> > > > >
> > > > > I have one doubt regarding origin-filter filtering= in case of
> > > > parent-child
> > > > > hierarchy.
> > > > >
> > > > > If child class instance fields match with origin-f= ilter value but
> > parent
> > > > > class instance fields does not, then what should b= e the rpc-reply
> > > > content?
> > > > > Does it need to include parent class instance reco= rd with only key
> > fields
> > > > > along with child class record or it should not inc= lude both parent
> > and
> > > > > child class instance record?
> > > >
> > > > This is not special for origin-filter, but applies to a= ll filters.
> > > > The description of get-data says:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Any ancestor nodes (includin= g list keys) of nodes selected by
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the filters are included in = the response.
> > > >
> > > > Hope this answers your question.
> > > >
> > > >
> > > > /martin
> > > >
> > > >
> > > > >
> > > > > Consider example given in 3.1.1.4 section of
> > > > > draft-ietf-netconf-nmda-netconf-08 :
> > > > >
> > > > > <rpc message-id=3D"102"
> > > > >=C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf= :base:1.0">
> > > > >=C2=A0 <get-data xmlns=3D"urn:ietf:params:x= ml:ns:yang:ietf-netconf-nmda"
> > > > >=C2=A0 xmlns:ds=3D"urn:ietf:params:xml:ns:yang= :ietf-datastores"
> > > > >=C2=A0 xmlns:or=3D"urn:ietf:params:xml:ns:yang= :ietf-origin">
> > > > >=C2=A0 <datastore>ds:operational</datastor= e>
> > > > >=C2=A0 <subtree-filter>
> > > > >=C2=A0 <bgp xmlns=3D"http://exam= ple.com/ns/bgp"/>
> > > > >=C2=A0 </subtree-filter>
> > > > >=C2=A0 <origin-filter>or:intended</origin-= filter>
> > > > >=C2=A0 <origin-filter>or:system</origin-fi= lter>
> > > > >=C2=A0 <with-origin/>
> > > > >=C2=A0 </get-data>
> > > > >=C2=A0 </rpc>
> > > > >
> > > > >
> > > > >=C2=A0 <rpc-reply message-id=3D"102" > > > > >=C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf= :base:1.0">
> > > > >=C2=A0 <data xmlns=3D"urn:ietf:params:xml:n= s:yang:ietf-netconf-nmda">
> > > > >=C2=A0 <bgp xmlns=3D"http://exam= ple.com/ns/bgp"
> > > > >=C2=A0 xmlns:or=3D"urn:ietf:params:xml:ns:yang= :ietf-origin"
> > > > >=C2=A0 or:origin=3D"or:intended">
> > > > >=C2=A0 <peer>
> > > > >=C2=A0 <name>2001:db8::2:3</name>
> > > > >=C2=A0 <local-port or:origin=3D"or:system&q= uot;>60794</local-port>
> > > > >=C2=A0 <state>established</state>
> > > > >=C2=A0 </peer>
> > > > >=C2=A0 </bgp>
> > > > >=C2=A0 </data>
> > > > >=C2=A0 </rpc-reply>
> > > > >
> > > > > In the above example, user has provided origin-fil= ter as system and
> > > > > intended in the RPC request. So rpc-reply has both= parent record with
> > > > > "intended" origin and child record with = "system" origin.
> > > > >
> > > > > What if user has provided only origin-filter=3D&qu= ot;system" ? Do we need to
> > > > > provide parent record with "intended" or= igin in the rpc-reply or
> > should
> > > > not
> > > > > provide both parent and child record ?
> > > > >
> > > > > Thanks,
> > > > > Amar
> > > >
> >
--0000000000006e1d610580aa9ee8-- From nobody Wed Jan 30 02:49:10 2019 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 E568D130F44 for ; Wed, 30 Jan 2019 02:49:08 -0800 (PST) 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 3PVlKzfWiPBR for ; Wed, 30 Jan 2019 02:49:02 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 55A8E1311DB for ; Wed, 30 Jan 2019 02:49:02 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 6968D1AE012C; Wed, 30 Jan 2019 11:49:01 +0100 (CET) Date: Wed, 30 Jan 2019 11:49:01 +0100 (CET) Message-Id: <20190130.114901.1507797823108224115.mbj@tail-f.com> To: ammys.vas@gmail.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190130.113556.191284102173613639.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 10:49:09 -0000 Amar Jadagoud wrote: > So do you mean that origin-filter needs to be applied on the response data > but origin annotation should not be provided in the rpc-reply? Yes. The filters is a set of mechanisms to reduce the result to match certain criteria. "with-origin" (and "with-defaults") are separate mechanisms to tag the resulting nodes with meta data. /martin > > On Wed 30 Jan, 2019, 4:05 PM Martin Bjorklund > > Amar Jadagoud wrote: > > > Hi Martin, > > > > > > Yes. I got your point. Thanks. > > > > > > One more question : > > > > > > Libyang does not return error if origin-filter is provided in the rpc > > > request without "with-origin" parameter as ietf-netconf-nmda module does > > > not mandate it. > > > > Yes, this is intentional. "with-origin" is orthogonal from any > > filters. > > > > > So we consider it as with-origin scenario and provide > > > origin annotation in parent and child record. > > > > If the client didn't pass the "with-origin" parameter, the server > > should not fill in the "origin" annotations, even if "origin-filter" > > was passed. > > > > > > /martin > > > > > > > Does below point holds true > > > for this case too? > > > > > > > > > > > > Thanks, > > > Amar > > > > > > On Wed 30 Jan, 2019, 3:24 PM Martin Bjorklund > > > > > > Hi, > > > > > > > > Amar Jadagoud wrote: > > > > > Hi martin, > > > > > > > > > > Yes. I got your point. But what should be the parent record > > annotation > > > > > value? Whether it should be intended or origin annotation itself > > should > > > > not > > > > > exist? > > > > > > > > I'm not sure I understand your question, but if the "with-origin" > > > > parameter is present in the request, the reply will contain "origin" > > > > annotations on all nodes (including ancestors) that have it. This > > > > handling is separate from any filters included. So even if you filter > > > > for "system" you might get nodes in the ancestor hierarchy with origin > > > > "intended", if you provided "with-origin". > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > Amar > > > > > > > > > > On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund > > > > > > > > > > Hi, > > > > > > > > > > > > Amar Jadagoud wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I have one doubt regarding origin-filter filtering in case of > > > > > > parent-child > > > > > > > hierarchy. > > > > > > > > > > > > > > If child class instance fields match with origin-filter value but > > > > parent > > > > > > > class instance fields does not, then what should be the rpc-reply > > > > > > content? > > > > > > > Does it need to include parent class instance record with only > > key > > > > fields > > > > > > > along with child class record or it should not include both > > parent > > > > and > > > > > > > child class instance record? > > > > > > > > > > > > This is not special for origin-filter, but applies to all filters. > > > > > > The description of get-data says: > > > > > > > > > > > > Any ancestor nodes (including list keys) of nodes selected > > by > > > > > > the filters are included in the response. > > > > > > > > > > > > Hope this answers your question. > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > Consider example given in 3.1.1.4 section of > > > > > > > draft-ietf-netconf-nmda-netconf-08 : > > > > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > > xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores" > > > > > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> > > > > > > > ds:operational > > > > > > > > > > > > > > > > > > > > > > > > > > > > or:intended > > > > > > > or:system > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > > > > > > > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > > > > > > > or:origin="or:intended"> > > > > > > > > > > > > > > 2001:db8::2:3 > > > > > > > 60794 > > > > > > > established > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the above example, user has provided origin-filter as system > > and > > > > > > > intended in the RPC request. So rpc-reply has both parent record > > with > > > > > > > "intended" origin and child record with "system" origin. > > > > > > > > > > > > > > What if user has provided only origin-filter="system" ? Do we > > need to > > > > > > > provide parent record with "intended" origin in the rpc-reply or > > > > should > > > > > > not > > > > > > > provide both parent and child record ? > > > > > > > > > > > > > > Thanks, > > > > > > > Amar > > > > > > > > > > > > From nobody Wed Jan 30 04:19:24 2019 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 BCEA61311DF for ; Wed, 30 Jan 2019 04:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.042 X-Spam-Level: X-Spam-Status: No, score=-19.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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_KAM_HTML_FONT_INVALID=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 m1-khzRZduNu for ; Wed, 30 Jan 2019 04:19:18 -0800 (PST) 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 A3BD81311DE for ; Wed, 30 Jan 2019 04:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45450; q=dns/txt; s=iport; t=1548850757; x=1550060357; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=LulSfqkJUfqHbtON1gF9f1qHYazQhIw/Lv9Lyn6E/LU=; b=gmgu/i0qeRwl8UxdUamEUI9Jo82cxypKNKABGkZ6bIZ2BGqm2W1TMa2P dbL62Mkrvyh7hL36wSCce8LioCXtONKWskQ8wKapMA2KUzNGk/CEx5FDl d5tZAlBOawUEdVdE581SZ8P+yYI2N2GVz3SDyb903tPzCnMS9J/OH79Hy A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAABblVFc/xbLJq0YAUoaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFUAgEBAQELAQGBDIFdUTInhAOIeY0CJZoEBA0YAQqEA0Y?= =?us-ascii?q?Cgyg3Bg0BAwEBAgEBAm0cDIVKAQEBAQIBAQEYCUsEDAsJAhEEAQEBIAEGAwI?= =?us-ascii?q?CJx8JCAYBDAYCAQEXgwcBgXkID41IgUSbYYEvH4QjQUCEcAWMV4FAP4E4DIF?= =?us-ascii?q?hfoMeAQEDAYE3EEyCU4JXAolMUAIDgUuENIZhintcCYcuin4GGIFrhTmDFYd?= =?us-ascii?q?6ihmFLIUFhxiBXCIogS4zGggbFTuCbIsdhT8/AzCNY4JMAQE?= X-IronPort-AV: E=Sophos;i="5.56,540,1539648000"; d="scan'208,217";a="9761930" 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; 30 Jan 2019 12:19:14 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x0UCJEhc018760; Wed, 30 Jan 2019 12:19:14 GMT To: Andy Bierman , "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" References: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> From: Robert Wilton Message-ID: Date: Wed, 30 Jan 2019 12:19:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------50060E4727DE96A7758AD551" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 12:19:22 -0000 This is a multi-part message in MIME format. --------------50060E4727DE96A7758AD551 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andy, Thanks for the comments. On 30/01/2019 01:22, Andy Bierman wrote: > Hi, > > I originally brought up this issue in July 2015 > https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ Yes. The solution I propose is different in the sense that it uses YANG instance data to define YANG packages rather than new YANG keywords.   I believe that this should make it a lower cost solution to define and implement. > > I don't think the WG ever agreed on the problem that needs to be solved, > and that is still the case. That wasn't quite my impression.  I also think that folks were busy focusing on other WG activity and didn't necessarily have the time to concentrate on this. My draft was aiming on solving two broad problems: The main goals of YANG package definitions include, but are not restricted to: o To act as a simplified YANG conformance mechanism. Rather than conformance being performed against a set of individual YANG module revisions, conformance could also be more simply stated in terms of YANG packages, with a set modifications (e.g. additional modules, deviations, or features). o To allow YANG datastore schema to be specified in a more concise way rather than having to list all modules and revisions. YANG package definitions can be defined in documents that can be referenced by a URL rather than requiring explicit lists of modules to be shared between client and server. Hence, a YANG package must contain sufficient information to allow a client or server to precisely construct the schema associated with the package. > > In reality each server has 1 package -- its entire library. This doesn't apply to all servers.  For a long time, as a vendor, we have had separate packages that can be independently installed, and which extend the management model to cover the new functionality.  E.g. BNG functionality could be in a separate, independently installable, package on top of the base router functionality. For a Linux server, the manageability interface will depend on what applications have been installed. > The SEMVER work shows > that vendors are treating platforms as independent release trains, and > not really > developing loadable packages. This depends on the vendor.  The YANG versioning work is trying to find a solution that works across the industry.  I believe that the versioning requirements are different for standards developed modules, vs industry developed modules, vs vendor modules. > > I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, > SEMVER import) > and  the YANG Catalog can solve the module compatibility issues. It is > more of a documentation > problem than a standards problem. Having a standard YANG module that can be used to define packages is something this is useful and should be standardized.  I believe that this is better than each vendor coming up with their own solution for this problem. Thanks, Rob > > > Andy > > > > > On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) > > wrote: > > Thanks Rob. Please see inline. > > Jason > > *From:*Robert Wilton > > *Sent:* Thursday, January 24, 2019 1:16 PM > *To:* Sterne, Jason (Nokia - CA/Ottawa) >; netmod@ietf.org > > *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages > > Hi Jason, > > Thanks for the review and comments. > > I've put some responses inline ... > > On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote: > > Hi guys, > > I've gotten most of the way through the draft and have some > initial comments. I haven't digested the section 10 open > issues yet or the examples. > > Section 5 mentions the following: > > YANG library is augmented to allow servers to report the packages > > that they implement and to associate those packages back to > > particular datastore schema. > > Does the combination of this draft and rfc7895bis somehow > allow the same package to be advertised in 2 different > datastores, but with different deviations in each datastore? > I'm thinking of a case, for example, where a package is fully > supported in the running but the package minus a few modules > (or parts of modules) is supported in the operational > datastore. There seems to be a 1:1 relationship between > package and rfc7895bis schema. > > So, the intention is no, not directly. > > My aim here is that would implement package "foo", and > would implement package "modified-foo".  Package > "modified-foo" would import package "foo" and also specify the set > of modules that contain the deviations "foo". > > I didn't want a server to be able to see that I implement package > "foo", but then I have all these deviations that change its > behavior.  Instead, it is really implementing a different package > that is based on "foo". > > The packages draft doesn't include any specific leaf-list for > deviations. Section 7.2 mentions that deviations could be > expressed by including modules that happen to contain > deviations. That seems a bit inconsistent with rfc7895bis that > has a specific leaf-list of deviations (and NETCONF hello that > specifically explicitly labels deviation modules). > > I'm conflicted on this one.  I don't really like the deviation > list in YANG library because I regard it as a duplicate source of > information, and then there is a question of which source of data > do you trust.  E.g. do you process a deviation in a module that is > not listed in the deviations module list? > > */[>>JTS: ] Good point. I suppose this issue applies today > already. i.e. what if one of the modules advertised in the > is a module of deviations (without having been referenced by > another module as a deviation module)./* > > Section 5.1 says the package must be referentially complete. I > can see the advantages of that although wondering if that > might limit flexibility of partitioning modules into packages. > I could imagine use cases for dividing a large set of modules > into a few packages that might rev independently but can still > all work together (especially if they rev in a bc manner). But > maybe that just starts to introduce too much complexity? > > Yes, having partial packages may be useful.  Perhaps just adding a > leaf to indicate whether a package is referentially complete could > be the answer here. > > I didn't understand this part of section 5.1. Can you maybe > illustrate with an example? > > The version/revision of a module listed in the package module list > > supercedes any version/revision of the module listed in a imported > > package module list.  This allows a package to resolve any > > conflicting implemented module versions/revisions in imported > > packages. > > Probably best to see example B.3. in the appendix because it > exactly illustrates this point. > > Basically: > 1) Packages must explicitly list all versions of all modules they > define/import. > 2) If two imported packages define different versions of modules, > then the package that is importing them needs a way to define > which version to use. > 3) A package needs a way to override the version of module > specified in an imported package. > > */[>>JTS: ] Thx. That example does help. I suppose the designer of > the package needs to carefully check that the version they select > can be successfully used by all the modules in the package. /* > > */I think there is a minor typo in example B.3.  The example-3-pkg > is importing "/* */example-import-1" but I believe you meant "/* > */example-import-1-pkg" (and some for import-2)./* > > It might be a good idea to add a parent-version to the package > module (to allow tracking lineage of packages). > > Agreed, or maybe allowing a revision history like modules.  Not > sure which is better here.  Packages could get a lot of updates, > and a long revision history would not be helpful at all. > > */[>>JTS: ] I think a minimum of just specifying the direct parent > is enough to build the full tree of lineage. We don't need a long > history of N revisions./* > > I like the use of groupings. That allows a manager to use this > as a building block to compose a model that has a list of > packages. > > OK. > > Having a global list of mandatory features (vs having the > mandatory feature a per-module list) means inventing the new > : format. Should we instead somehow put > the mandatory features against each module of the package? > > Perhaps.  My thinking here was to have the list of features high > up and very easy to find/parse. > > The location leaf is a uri but then the description says it > must be a url (where the model can be retrieved). I do like > that the namespace is separate from the location, but maybe we > should make location a url type? > > Yes, I was thinking that is should be a URL. > > Do we need a namespace for package names in the model? > > I had them in an earlier version, but I took them out, because I > wasn't sure that they are really useful/required. > > Defining a format to make package names themselves globally unique > might be sufficient. > > */[>>JTS: ] I'm OK with that. It is similar to how we're finding > that it is useful that YANG module names are globally unique (i.e. > by naming with ietf-xxxx or companyabc-xxx)./* > > In 7.3 we only reference module-sets and not modules. So the > grouping of modules into sets and packages must be the same? > > Not necessarily. > > I am trying to reuse the module-set definitions as much as > possible (to avoid duplication).  One issue here is that > module-sets are combined then all the modules must not overlap, > which doesn't make the mapping to module-sets quite so clean. > > A schema can only have a single package. I think that works > but it means a server would advertise multiple schemas if it > wants to support multiple packages. I'm not sure if there are > some downsides to that (it just surprised me). > > My aim here was: >  - multiple packages are advertised in yang-library/packages >  - datastores only report that they "implement" one [top level] > package version.  [The package itself might import other packages.] > > If we do package selection, then for a given YANG client session, > and the version of YANG library available/reported by that > session, it would appear as if the server only implements one top > level package for a datastore.  Different clients choosing > different versions would see slightly different output depending > on which package version they had selected to use. > > Thanks again for the review and the comments! > > Rob > > Jason > > *From:*netmod > *On Behalf Of *Robert Wilton > *Sent:* Thursday, December 20, 2018 12:45 PM > *To:* netmod@ietf.org > *Subject:* [netmod] YANG Packages > > Hi, > > I've written up an ID for a potential solution for YANG > packages using instance data: > > Abstract > >    This document defines YANG packages, an organizational > structure > >    holding a set of related YANG modules, that can be used to > simplify > >    the conformance and sharing of YANG schema.  It describes > how YANG > >    instance data documents are used to define YANG packages, > and how the > >    YANG library information published by a server can be > augmented with > >    additional packaging related information. > > https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ > > Potentially this work may be of use as part of the YANG > versioning design team work.  In addition, if the WG likes > this approach of defining YANG packages, then it might also be > useful to bind a schema to a YANG instance data document. > > Some questions for members of the WG: > > 1) Do members of the WG agree that YANG packages is something > that needs to be solved? > > 2) Is the approach in this draft of defining these as instance > data documents a good starting point? > > 3) This approach augments YANG library-bis, reusing > module-sets, but not replacing the way that modules are > reported in YANG library-bis.  Is this the right approach?  > This approach tries to allow module-sets to be reused for both > schema and packages, but the YANG library-bis rules for > combining module-sets (i.e. no conflicts) may make this harder > to really reuse the module-sets for both purposes. > > Of course, any other comments or feedback is welcome and > appreciated. > > Thanks, > Rob > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --------------50060E4727DE96A7758AD551 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andy,

Thanks for the comments.

On 30/01/2019 01:22, Andy Bierman wrote:
Hi,

I originally brought up this issue in July 2015

Yes.

The solution I propose is different in the sense that it uses YANG instance data to define YANG packages rather than new YANG keywords.   I believe that this should make it a lower cost solution to define and implement.



I don't think the WG ever agreed on the problem that needs to be solved,
and that is still the case.

That wasn't quite my impression.  I also think that folks were busy focusing on other WG activity and didn't necessarily have the time to concentrate on this.

My draft was aiming on solving two broad problems:

   The main goals of YANG package definitions include, but are not
   restricted to:

   o  To act as a simplified YANG conformance mechanism.  Rather than
      conformance being performed against a set of individual YANG
      module revisions, conformance could also be more simply stated in
      terms of YANG packages, with a set modifications (e.g. additional
      modules, deviations, or features).

   o  To allow YANG datastore schema to be specified in a more concise
      way rather than having to list all modules and revisions.  YANG
      package definitions can be defined in documents that can be
      referenced by a URL rather than requiring explicit lists of
      modules to be shared between client and server.  Hence, a YANG
      package must contain sufficient information to allow a client or
      server to precisely construct the schema associated with the
      package.


 

In reality each server has 1 package -- its entire library.

This doesn't apply to all servers.  For a long time, as a vendor, we have had separate packages that can be independently installed, and which extend the management model to cover the new functionality.  E.g. BNG functionality could be in a separate, independently installable, package on top of the base router functionality.

For a Linux server, the manageability interface will depend on what applications have been installed.


The SEMVER work shows
that vendors are treating platforms as independent release trains, and not really
developing loadable packages.

This depends on the vendor.  The YANG versioning work is trying to find a solution that works across the industry.  I believe that the versioning requirements are different for standards developed modules, vs industry developed modules, vs vendor modules.



I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, SEMVER import)
and  the YANG Catalog can solve the module compatibility issues. It is more of a documentation
problem than a standards problem.

Having a standard YANG module that can be used to define packages is something this is useful and should be standardized.  I believe that this is better than each vendor coming up with their own solution for this problem.

Thanks,
Rob




Andy




On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:

Thanks Rob. Please see inline.

Jason

 

From: Robert Wilton <rwilton@cisco.com>
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; netmod@ietf.org
Subject: Re: initial comments on draft-rwilton-netmod-yang-packages

 

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi guys,

 

I've gotten most of the way through the draft and have some initial comments. I haven't digested the section 10 open issues yet or the examples.

 

Section 5 mentions the following:

   YANG library is augmented to allow servers to report the packages

   that they implement and to associate those packages back to

   particular datastore schema.

 

Does the combination of this draft and rfc7895bis somehow allow the same package to be advertised in 2 different datastores, but with different deviations in each datastore? I'm thinking of a case, for example, where a package is fully supported in the running but the package minus a few modules (or parts of modules) is supported in the operational datastore. There seems to be a 1:1 relationship between package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that <running> would implement package "foo", and <operational> would implement package "modified-foo".  Package "modified-foo" would import package "foo" and also specify the set of modules that contain the deviations "foo".

I didn't want a server to be able to see that I implement package "foo", but then I have all these deviations that change its behavior.  Instead, it is really implementing a different package that is based on "foo".

 

 

The packages draft doesn't include any specific leaf-list for deviations. Section 7.2 mentions that deviations could be expressed by including modules that happen to contain deviations. That seems a bit inconsistent with rfc7895bis that has a specific leaf-list of deviations (and NETCONF hello that specifically explicitly labels deviation modules).

I'm conflicted on this one.  I don't really like the deviation list in YANG library because I regard it as a duplicate source of information, and then there is a question of which source of data do you trust.  E.g. do you process a deviation in a module that is not listed in the deviations module list?

[>>JTS: ] Good point. I suppose this issue applies today already. i.e. what if one of the modules advertised in the <hello> is a module of deviations (without having been referenced by another module as a deviation module).

 

 

Section 5.1 says the package must be referentially complete. I can see the advantages of that although wondering if that might limit flexibility of partitioning modules into packages. I could imagine use cases for dividing a large set of modules into a few packages that might rev independently but can still all work together (especially if they rev in a bc manner). But maybe that just starts to introduce too much complexity?

Yes, having partial packages may be useful.  Perhaps just adding a leaf to indicate whether a package is referentially complete could be the answer here.

 

 

I didn't understand this part of section 5.1. Can you maybe illustrate with an example?

      The version/revision of a module listed in the package module list

      supercedes any version/revision of the module listed in a imported

      package module list.  This allows a package to resolve any

      conflicting implemented module versions/revisions in imported

      packages.

Probably best to see example B.3. in the appendix because it exactly illustrates this point.

Basically:
1) Packages must explicitly list all versions of all modules they define/import.
2) If two imported packages define different versions of modules, then the package that is importing them needs a way to define which version to use.
3) A package needs a way to override the version of module specified in an imported package.

[>>JTS: ] Thx. That example does help. I suppose the designer of the package needs to carefully check that the version they select can be successfully used by all the modules in the package.

I think there is a minor typo in example B.3.  The example-3-pkg is importing " example-import-1" but I believe you meant " example-import-1-pkg" (and some for import-2).

 

It might be a good idea to add a parent-version to the package module (to allow tracking lineage of packages).

Agreed, or maybe allowing a revision history like modules.  Not sure which is better here.  Packages could get a lot of updates, and a long revision history would not be helpful at all.

[>>JTS: ] I think a minimum of just specifying the direct parent is enough to build the full tree of lineage. We don't need a long history of N revisions.

 

 

I like the use of groupings. That allows a manager to use this as a building block to compose a model that has a list of packages.

OK.

 

 

Having a global list of mandatory features (vs having the mandatory feature a per-module list) means inventing the new <module-name>:<feature> format. Should we instead somehow put the mandatory features against each module of the package?

Perhaps.  My thinking here was to have the list of features high up and very easy to find/parse.

 

 

The location leaf is a uri but then the description says it must be a url (where the model can be retrieved). I do like that the namespace is separate from the location, but maybe we should make location a url type?

Yes, I was thinking that is should be a URL.

 

 

Do we need a namespace for package names in the model?

I had them in an earlier version, but I took them out, because I wasn't sure that they are really useful/required.

Defining a format to make package names themselves globally unique might be sufficient.

[>>JTS: ] I'm OK with that. It is similar to how we're finding that it is useful that YANG module names are globally unique (i.e. by naming with ietf-xxxx or companyabc-xxx).

 

 

In 7.3 we only reference module-sets and not modules. So the grouping of modules into sets and packages must be the same?

Not necessarily.

I am trying to reuse the module-set definitions as much as possible (to avoid duplication).  One issue here is that module-sets are combined then all the modules must not overlap, which doesn't make the mapping to module-sets quite so clean.

 

 

A schema can only have a single package. I think that works but it means a server would advertise multiple schemas if it wants to support multiple packages. I'm not sure if there are some downsides to that (it just surprised me).

My aim here was:
 - multiple packages are advertised in yang-library/packages
 - datastores only report that they "implement" one [top level] package version.  [The package itself might import other packages.]

If we do package selection, then for a given YANG client session, and the version of YANG library available/reported by that session, it would appear as if the server only implements one top level package for a datastore.  Different clients choosing different versions would see slightly different output depending on which package version they had selected to use.

Thanks again for the review and the comments!

Rob

 

 

 

Jason

 

 

 

From: netmod <netmod-bounces@ietf.org> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: netmod@ietf.org
Subject: [netmod] YANG Packages

 

Hi,

I've written up an ID for a potential solution for YANG packages using instance data:

Abstract
 
   This document defines YANG packages, an organizational structure
   holding a set of related YANG modules, that can be used to simplify
   the conformance and sharing of YANG schema.  It describes how YANG
   instance data documents are used to define YANG packages, and how the
   YANG library information published by a server can be augmented with
   additional packaging related information.

https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/

Potentially this work may be of use as part of the YANG versioning design team work.  In addition, if the WG likes this approach of defining YANG packages, then it might also be useful to bind a schema to a YANG instance data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs to be solved?

2) Is the approach in this draft of defining these as instance data documents a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not replacing the way that modules are reported in YANG library-bis.  Is this the right approach?  This approach tries to allow module-sets to be reused for both schema and packages, but the YANG library-bis rules for combining module-sets (i.e. no conflicts) may make this harder to really reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.

Thanks,
Rob

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--------------50060E4727DE96A7758AD551-- From nobody Wed Jan 30 06:50:38 2019 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 EF8A712950A for ; Wed, 30 Jan 2019 06:50:36 -0800 (PST) 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 XtwlkXMNzugA for ; Wed, 30 Jan 2019 06:50:34 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B58E1124408 for ; Wed, 30 Jan 2019 06:50:34 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id 6C612182015B; Wed, 30 Jan 2019 15:50:31 +0100 (CET) Received: from localhost (unknown [195.113.220.122]) by trail.lhotka.name (Postfix) with ESMTPSA id 02922182015B for ; Wed, 30 Jan 2019 15:50:29 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org Mail-Followup-To: netmod@ietf.org Date: Wed, 30 Jan 2019 15:50:31 +0100 Message-ID: <877eemjj2g.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] LL comments on draft-rwilton-netmod-yang-packages-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 14:50:37 -0000 Hi, I think it is a good start, here are my comments (some of them were already raised by Jason): - I like the fact that this work doesn't require any changes to YANG, except perhaps semver. - I think the augments to YANG library is a separate problem that should perhaps be addressed in a different document. Servers supporting multiple package revisions may not be that common. - I was expecting that a package could specify a range of revisions for some modules that may be used together with teh others. This doesn't seem to be the case. If so, it would be somewhat unwieldy because every combination of module revisions would require a separate package revision. - As Jason pointed out, there seems to be no use for the package namespace, as packages don't define any names on their own. - I would also prefer mandatory-features to be bundled with each module. - This draft nicely shows that there is really no need for any "yang-data" extensions. But I also don't see any benefit from using ietf-yang-instance-data in this case. It would IMO be perfectly fine to get rid of two levels of data hierarchy: { "ietf-yang-package:yang-package": { ... } } Thanks, Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 30 07:17:07 2019 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 9B80B130DF6 for ; Wed, 30 Jan 2019 07:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 Ze-ZJjm4WvzB for ; Wed, 30 Jan 2019 07:17:01 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 3783C12F1AB for ; Wed, 30 Jan 2019 07:17:01 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id u18so17635993lff.10 for ; Wed, 30 Jan 2019 07:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jxttWrNpPiu0a+27Xob47oJrtKgEcaj+ayVh8x5CQyg=; b=WsuDn45M8uosPVEhybRXsSEG1EP+xUGtP+jFKI6+AliT7Wj/5Hzx2Q5bNHnptCIbzx y7eYNM7uZ6NUy6WiR9FBssMffaSpc8ek9vHhcfXfB0CGHJ3l/qutXXo/7ebzvifNYeC9 TucybGXfq/TdYlIHPLsDpD+5hTZNutWWeM6gFy+sxIsw4iiNqxHwFjkCFzDmbyYn48No KBtJ7C4+XB+B3Ye8ji7tYBX3ddnYxgmUKMKAL0IpP1uTJGRVR7SRdF2OIIMPJ7FjpJ7y 1kLL92iGKL3ZmNlfal0SkW1RDCcdYJpG+HO9MSoHh5oj11ZTxx8QmoHsli8uMzS6L5H0 cidw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jxttWrNpPiu0a+27Xob47oJrtKgEcaj+ayVh8x5CQyg=; b=qrMwPc0ZIAPDgfwG7to9Z4LWyO0kSxfQ9Yu8f3dZpoIskt2i5fQGtMb6iiAnVuqbOT E8KA384fGeyxRAUEu3pVDsN9KjjWqy4u2Y6yZsA3RYVTEa0ifqVwgWb+BwtpxPTokdTw cfC9EFlBxbmVgEVL8V+YPaZSi0gZuPiX5c9xlhYj4YWJ19ymBM8RNBJ/fLbNuBsq41bQ t7c8ODqHO1oDsD0Lr5w3YAq3t55S7zs8YqfV/JNQkWXwCsK+Ds+sAe2GR1XC5t+BMJk/ Hj4m4FPG8KnqpGvLbyjuz9NJPWxUYkckTuUT61erC5FoQGVD2rqqCmcXp8VR8qPudX2l Ns3w== X-Gm-Message-State: AJcUukcpC3TBC2NkwmRFRdBh5q3bPjHg0/SRBOzhFa6zladOWtK8cote 40ofx2Ipi8hYwKdyZcGtm8RoQ/SKYgOatlkAahAZpQ== X-Google-Smtp-Source: ALg8bN4PNVA8/LX8qUWjUVPE+1myDUh9rQfEDSAmSC5iW18Uu0GF02m5vmUCpT88A6ekQcZNs/1oCF/udYxkYFcDgPg= X-Received: by 2002:a19:d90c:: with SMTP id q12mr25307656lfg.24.1548861418961; Wed, 30 Jan 2019 07:16:58 -0800 (PST) MIME-Version: 1.0 References: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> In-Reply-To: From: Andy Bierman Date: Wed, 30 Jan 2019 07:16:47 -0800 Message-ID: To: Robert Wilton Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000af1c770580ae661a" Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 15:17:06 -0000 --000000000000af1c770580ae661a Content-Type: text/plain; charset="UTF-8" On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton wrote: > Hi Andy, > > Thanks for the comments. > On 30/01/2019 01:22, Andy Bierman wrote: > > Hi, > > I originally brought up this issue in July 2015 > https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ > > Yes. > > The solution I propose is different in the sense that it uses YANG > instance data to define YANG packages rather than new YANG keywords. I > believe that this should make it a lower cost solution to define and > implement. > > > I think yangvalidator.org has a better solution that does not change YANG conformance. Andy > > I don't think the WG ever agreed on the problem that needs to be solved, > and that is still the case. > > That wasn't quite my impression. I also think that folks were busy > focusing on other WG activity and didn't necessarily have the time to > concentrate on this. > > My draft was aiming on solving two broad problems: > > The main goals of YANG package definitions include, but are not > restricted to: > > o To act as a simplified YANG conformance mechanism. Rather than > conformance being performed against a set of individual YANG > module revisions, conformance could also be more simply stated in > terms of YANG packages, with a set modifications (e.g. additional > modules, deviations, or features). > > o To allow YANG datastore schema to be specified in a more concise > way rather than having to list all modules and revisions. YANG > package definitions can be defined in documents that can be > referenced by a URL rather than requiring explicit lists of > modules to be shared between client and server. Hence, a YANG > package must contain sufficient information to allow a client or > server to precisely construct the schema associated with the > package. > > > > > > In reality each server has 1 package -- its entire library. > > This doesn't apply to all servers. For a long time, as a vendor, we have > had separate packages that can be independently installed, and which extend > the management model to cover the new functionality. E.g. BNG > functionality could be in a separate, independently installable, package on > top of the base router functionality. > > For a Linux server, the manageability interface will depend on what > applications have been installed. > > > The SEMVER work shows > that vendors are treating platforms as independent release trains, and not > really > developing loadable packages. > > This depends on the vendor. The YANG versioning work is trying to find a > solution that works across the industry. I believe that the versioning > requirements are different for standards developed modules, vs industry > developed modules, vs vendor modules. > > > > I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, > SEMVER import) > and the YANG Catalog can solve the module compatibility issues. It is > more of a documentation > problem than a standards problem. > > Having a standard YANG module that can be used to define packages is > something this is useful and should be standardized. I believe that this > is better than each vendor coming up with their own solution for this > problem. > > Thanks, > Rob > > > > > Andy > > > > > On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) < > jason.sterne@nokia.com> wrote: > >> Thanks Rob. Please see inline. >> >> Jason >> >> >> >> *From:* Robert Wilton >> *Sent:* Thursday, January 24, 2019 1:16 PM >> *To:* Sterne, Jason (Nokia - CA/Ottawa) ; >> netmod@ietf.org >> *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages >> >> >> >> Hi Jason, >> >> Thanks for the review and comments. >> >> I've put some responses inline ... >> >> On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote: >> >> Hi guys, >> >> >> >> I've gotten most of the way through the draft and have some initial >> comments. I haven't digested the section 10 open issues yet or the examples. >> >> >> >> Section 5 mentions the following: >> >> YANG library is augmented to allow servers to report the packages >> >> that they implement and to associate those packages back to >> >> particular datastore schema. >> >> >> >> Does the combination of this draft and rfc7895bis somehow allow the same >> package to be advertised in 2 different datastores, but with different >> deviations in each datastore? I'm thinking of a case, for example, where a >> package is fully supported in the running but the package minus a few >> modules (or parts of modules) is supported in the operational datastore. >> There seems to be a 1:1 relationship between package and rfc7895bis schema. >> >> So, the intention is no, not directly. >> >> My aim here is that would implement package "foo", and >> would implement package "modified-foo". Package >> "modified-foo" would import package "foo" and also specify the set of >> modules that contain the deviations "foo". >> >> I didn't want a server to be able to see that I implement package "foo", >> but then I have all these deviations that change its behavior. Instead, it >> is really implementing a different package that is based on "foo". >> >> >> >> >> >> The packages draft doesn't include any specific leaf-list for deviations. >> Section 7.2 mentions that deviations could be expressed by including >> modules that happen to contain deviations. That seems a bit inconsistent >> with rfc7895bis that has a specific leaf-list of deviations (and NETCONF >> hello that specifically explicitly labels deviation modules). >> >> I'm conflicted on this one. I don't really like the deviation list in >> YANG library because I regard it as a duplicate source of information, and >> then there is a question of which source of data do you trust. E.g. do you >> process a deviation in a module that is not listed in the deviations module >> list? >> >> *[>>JTS: ] Good point. I suppose this issue applies today already. i.e. >> what if one of the modules advertised in the is a module of >> deviations (without having been referenced by another module as a deviation >> module).* >> >> >> >> >> >> Section 5.1 says the package must be referentially complete. I can see >> the advantages of that although wondering if that might limit flexibility >> of partitioning modules into packages. I could imagine use cases for >> dividing a large set of modules into a few packages that might rev >> independently but can still all work together (especially if they rev in a >> bc manner). But maybe that just starts to introduce too much complexity? >> >> Yes, having partial packages may be useful. Perhaps just adding a leaf >> to indicate whether a package is referentially complete could be the answer >> here. >> >> >> >> >> >> I didn't understand this part of section 5.1. Can you maybe illustrate >> with an example? >> >> The version/revision of a module listed in the package module list >> >> supercedes any version/revision of the module listed in a imported >> >> package module list. This allows a package to resolve any >> >> conflicting implemented module versions/revisions in imported >> >> packages. >> >> Probably best to see example B.3. in the appendix because it exactly >> illustrates this point. >> >> Basically: >> 1) Packages must explicitly list all versions of all modules they >> define/import. >> 2) If two imported packages define different versions of modules, then >> the package that is importing them needs a way to define which version to >> use. >> 3) A package needs a way to override the version of module specified in >> an imported package. >> >> *[>>JTS: ] Thx. That example does help. I suppose the designer of the >> package needs to carefully check that the version they select can be >> successfully used by all the modules in the package. * >> >> *I think there is a minor typo in example B.3. The example-3-pkg is >> importing "* *example-import-1" but I believe you meant "* *example-import-1-pkg" >> (and some for import-2).* >> >> >> >> It might be a good idea to add a parent-version to the package module (to >> allow tracking lineage of packages). >> >> Agreed, or maybe allowing a revision history like modules. Not sure >> which is better here. Packages could get a lot of updates, and a long >> revision history would not be helpful at all. >> >> *[>>JTS: ] I think a minimum of just specifying the direct parent is >> enough to build the full tree of lineage. We don't need a long history of N >> revisions.* >> >> >> >> >> >> I like the use of groupings. That allows a manager to use this as a >> building block to compose a model that has a list of packages. >> >> OK. >> >> >> >> >> >> Having a global list of mandatory features (vs having the mandatory >> feature a per-module list) means inventing the new : >> format. Should we instead somehow put the mandatory features against each >> module of the package? >> >> Perhaps. My thinking here was to have the list of features high up and >> very easy to find/parse. >> >> >> >> >> >> The location leaf is a uri but then the description says it must be a url >> (where the model can be retrieved). I do like that the namespace is >> separate from the location, but maybe we should make location a url type? >> >> Yes, I was thinking that is should be a URL. >> >> >> >> >> >> Do we need a namespace for package names in the model? >> >> I had them in an earlier version, but I took them out, because I wasn't >> sure that they are really useful/required. >> >> Defining a format to make package names themselves globally unique might >> be sufficient. >> >> *[>>JTS: ] I'm OK with that. It is similar to how we're finding that it >> is useful that YANG module names are globally unique (i.e. by naming with >> ietf-xxxx or companyabc-xxx).* >> >> >> >> >> >> In 7.3 we only reference module-sets and not modules. So the grouping of >> modules into sets and packages must be the same? >> >> Not necessarily. >> >> I am trying to reuse the module-set definitions as much as possible (to >> avoid duplication). One issue here is that module-sets are combined then >> all the modules must not overlap, which doesn't make the mapping to >> module-sets quite so clean. >> >> >> >> >> >> A schema can only have a single package. I think that works but it means >> a server would advertise multiple schemas if it wants to support multiple >> packages. I'm not sure if there are some downsides to that (it just >> surprised me). >> >> My aim here was: >> - multiple packages are advertised in yang-library/packages >> - datastores only report that they "implement" one [top level] package >> version. [The package itself might import other packages.] >> >> If we do package selection, then for a given YANG client session, and the >> version of YANG library available/reported by that session, it would appear >> as if the server only implements one top level package for a datastore. >> Different clients choosing different versions would see slightly different >> output depending on which package version they had selected to use. >> >> Thanks again for the review and the comments! >> >> Rob >> >> >> >> >> >> >> >> Jason >> >> >> >> >> >> >> >> *From:* netmod *On >> Behalf Of *Robert Wilton >> *Sent:* Thursday, December 20, 2018 12:45 PM >> *To:* netmod@ietf.org >> *Subject:* [netmod] YANG Packages >> >> >> >> Hi, >> >> I've written up an ID for a potential solution for YANG packages using >> instance data: >> >> Abstract >> >> >> >> This document defines YANG packages, an organizational structure >> >> holding a set of related YANG modules, that can be used to simplify >> >> the conformance and sharing of YANG schema. It describes how YANG >> >> instance data documents are used to define YANG packages, and how the >> >> YANG library information published by a server can be augmented with >> >> additional packaging related information. >> >> https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ >> >> Potentially this work may be of use as part of the YANG versioning design >> team work. In addition, if the WG likes this approach of defining YANG >> packages, then it might also be useful to bind a schema to a YANG instance >> data document. >> >> Some questions for members of the WG: >> >> 1) Do members of the WG agree that YANG packages is something that needs >> to be solved? >> >> 2) Is the approach in this draft of defining these as instance data >> documents a good starting point? >> >> 3) This approach augments YANG library-bis, reusing module-sets, but not >> replacing the way that modules are reported in YANG library-bis. Is this >> the right approach? This approach tries to allow module-sets to be reused >> for both schema and packages, but the YANG library-bis rules for combining >> module-sets (i.e. no conflicts) may make this harder to really reuse the >> module-sets for both purposes. >> >> Of course, any other comments or feedback is welcome and appreciated. >> >> Thanks, >> Rob >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > --000000000000af1c770580ae661a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 30, 2019 at 4:19 AM Rober= t Wilton <rwilton@cisco.com>= wrote:
=20 =20 =20

Hi Andy,

Thanks for the comments.

On 30/01/2019 = 01:22, Andy Bierman wrote:
=20
Hi,

I originally brought up this issue in July 2015

Yes.

The solution I propose is different in the sense that it uses YANG instance data to define YANG packages rather than new YANG keywords.=C2=A0=C2=A0 I believe that this should make it a lower cost solution to define and implement.



I think yangvalidator.org has a better solution that do= es not change YANG conformance.


And= y
=C2=A0
<= div bgcolor=3D"#FFFFFF">


I don't think the WG ever agreed on the problem that needs to be solved,
and that is still the case.

That wasn't quite my impression.=C2=A0 I also think that folks w= ere busy focusing on other WG activity and didn't necessarily have th= e time to concentrate on this.

My draft was aiming on solving two broad problems:

   The main goals of YANG package definitions include, but=
 are not
   restricted to:

   o  To act as a simplified YANG conformance mechanism.  Rather than
      conformance being performed against a set of individual YANG
      module revisions, conformance could also be more simply stated in
      terms of YANG packages, with a set modifications (e.g. additional
      modules, deviations, or features).

   o  To allow YANG datastore schema to be specified in a more concise
      way rather than having to list all modules and revisions.  YANG
      package definitions can be defined in documents that can be
      referenced by a URL rather than requiring explicit lists of
      modules to be shared between client and server.  Hence, a YANG
      package must contain sufficient information to allow a client or
      server to precisely construct the schema associated with the
      package.


=C2=A0

In reality each server has 1 package -- its entire library.

This doesn't apply to all servers.=C2=A0 For a long time, as a v= endor, we have had separate packages that can be independently installed, and which extend the management model to cover the new functionality.=C2=A0 E.g. BNG functionality could be in a separate, independently installable, package on top of the base router functionality.

For a Linux server, the manageability interface will depend on what applications have been installed.


The SEMVER work shows
that vendors are treating platforms as independent release trains, and not really
developing loadable packages.

This depends on the vendor.=C2=A0 The YANG versioning work is trying to find a solution that works across the industry.=C2=A0 I believe th= at the versioning requirements are different for standards developed modules, vs industry developed modules, vs vendor modules.



I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, SEMVER import)
and=C2=A0 the YANG Catalog can solve the module compatibilit= y issues. It is more of a documentation
problem than a standards problem.

Having a standard YANG module that can be used to define packages is something this is useful and should be standardized.=C2=A0 I belie= ve that this is better than each vendor coming up with their own solution for this problem.

Thanks,
Rob




Andy




On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:

Thank= s Rob. Please see inline.

Jason=

=C2= =A0

From: Robert Wilton <rwilton@cisco.com>
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; netmod@ietf.org
Subject: Re: initial comments on draft-rwilton-netmod-yang-packages

=C2=A0

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

H= i guys,

= =C2=A0

I= 've gotten most of the way through the draft and have some initial comments. I haven't digested the section 10 open issues yet or the examples.

= =C2=A0

S= ection 5 mentions the following:

= =C2=A0=C2=A0 YANG library is augmented to allow servers to report the packages

= =C2=A0=C2=A0 that they implement and to associate those packages back to

= =C2=A0=C2=A0 particular datastore schema.

= =C2=A0

D= oes the combination of this draft and rfc7895bis somehow allow the same package to be advertised in 2 different datastores, but with different deviations in each datastore? I'm thinking of a case, for example, where a package is fully supported in the running but the package minus a few modules (or parts of modules) is supported in the operational datastore. There seems to be a 1:1 relationship between package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that <running> would implement package "foo", and <operational> would im= plement package "modified-foo".=C2=A0 Package "mod= ified-foo" would import package "foo" and also specify the set o= f modules that contain the deviations "foo".

I didn't want a server to be able to see that I implement package "foo", but then I have all th= ese deviations that change its behavior.=C2=A0 Instead, it is really implementing a different package that is based on "foo".

=C2=A0

= =C2=A0

T= he packages draft doesn't include any specific leaf-list for deviations. Section 7.2 mentions that deviations could be expressed by including modules that happen to contain deviations. That seems a bit inconsistent with rfc7895bis that has a specific leaf-list of deviations (and NETCONF hello that specifically explicitly labels deviation modules).

I'm conflicted on this one.=C2=A0 I don't really= like the deviation list in YANG library because I regard it as a duplicate source of information, and then there is a question of which source of data do you trust.=C2=A0 E.g. do you process a deviation in a module that is not listed in the deviations module list?

[>>JTS: ] Good point. I suppose this issue applies today already. i.e. what if one of the modules advertised in the <hello> is a module of deviations (without having been referenced by another module as a deviation module).

=C2=A0

= =C2=A0

S= ection 5.1 says the package must be referentially complete. I can see the advantages of that although wondering if that might limit flexibility of partitioning modules into packages. I could imagine use cases for dividing a large set of modules into a few packages that might rev independently but can still all work together (especially if they rev in a bc manner). But maybe that just starts to introduce too much complexity?

Yes, having partial packages may be useful.=C2=A0 Perhap= s just adding a leaf to indicate whether a package is referentially complete could be the answer here.

=C2=A0

= =C2=A0

I didn't understand this part of section 5.1. Can you maybe illustrate with an example?

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The version/revision of a module listed in the package module list

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 supercedes any version/revision of the module listed in a imported

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 package module list.=C2=A0 This allows a package to resolve any

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 conflicting implemented module versions/revisions in imported

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 packages.

Probably best to see example B.3. in the appendix because it exactly illustrates this point.

Basically:
1) Packages must explicitly list all versions of all modules they define/import.
2) If two imported packages define different versions of modules, then the package that is importing them needs a way to define which version to use.
3) A package needs a way to override the version of module specified in an imported package.

[>>JTS: ] Thx. That example does help. I suppose the designer of the package needs to carefully check that the version they select can be successfully used by all the modules in the package.

I think there is a minor typo in example B.3.=C2=A0 The example-3-pk= g is importing " example-import-1&q= uot; but I believe you meant " example-import-1-p= kg" (and some for import-2).

= =C2=A0

I= t might be a good idea to add a parent-version to the package module (to allow tracking lineage of packages).

Agreed, or maybe allowing a revision history like modules.=C2=A0 Not sure which is better here.=C2=A0 Packa= ges could get a lot of updates, and a long revision history would not be helpful at all.

[>>JTS: ] I think a minimum of just specifying the direct parent is enough to build the full tree of lineage. We don't need a long history of N revisions.

=C2=A0

= =C2=A0

I like the us= e of groupings. That allows a manager to use this as a building block to compose a model that has a list of packages.

OK.

=C2=A0

= =C2=A0

Having a global list of mandatory features (vs having the mandatory feature a per-module list) means inventing the new <module-name>:<feature> format. Should we instead somehow put the mandatory features against each module of the package?

Perhaps.=C2=A0 My thinking here was to have the list of features high up and very easy to find/parse.

=C2=A0

=C2=A0=

The location leaf is a uri but then the description says it must be a url (where the model can be retrieved). I do like that the namespace is separate from the location, but maybe we should make location a url type?

Yes, I was thinking that is should be a URL.

=C2=A0

=C2=A0=

Do we need a namespace for package names in the model?

I had them in an earlier version, but I took them out, because I wasn't sure that they are really useful/required.

Defining a format to make package names themselves globally unique might be sufficient.

[>>JTS: ] I'm OK with that. It is similar to how we'r= e finding that it is useful that YANG module names are globally unique (i.e. by naming with ietf-xxxx or companyabc-xxx).

=C2=A0

=C2=A0=

In 7.3 we onl= y reference module-sets and not modules. So the grouping of modules into sets and packages must be the same?

Not necessarily.

I am trying to reuse the module-set definitions as much as possible (to avoid duplication).=C2=A0 One issue here is that module-sets are combined then all the modules must not overlap, which doesn't make the mapping to module-sets quite so clean.

=C2=A0

=C2=A0=

A schema can only have a single package. I think that works but it means a server would advertise multiple schemas if it wants to support multiple packages. I'm not sure if there are some downsides to that (it just surprised me).

My aim here was:
=C2=A0- multiple packages are advertised in yang-library/packages
=C2=A0- datastores only report that they "implement&= quot; one [top level] package version.=C2=A0 [The package itself might import other packages.]

If we do package selection, then for a given YANG client session, and the version of YANG library available/reported by that session, it would appear as if the server only implements one top level package for a datastore.=C2=A0 Different clients choosing differe= nt versions would see slightly different output depending on which package version they had selected to use.

Thanks again for the review and the comments!

Rob

=C2=A0

=C2=A0

=C2=A0=

Jason<= /p>

=C2=A0=

= =C2=A0

= =C2=A0

From: netmod <netmod-bounces@ietf.org> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: netmod@ietf.org
Subject: [netmod] YANG Packages

=C2=A0

Hi,

I've written up an ID for a potential solution for YANG packages using instance data:

Abstract
=C2=A0
=C2=A0=C2=
=A0 This document defines YANG packages, an organizational structure=

=C2=A0=C2=
=A0 holding a set of related YANG modules, that can be used to simplify
=C2=A0=C2=
=A0 the conformance and sharing of YANG schema.=C2=A0 It describes how YANG=

=C2=A0=C2=
=A0 instance data documents are used to define YANG packages, and how the
=C2=A0=C2=
=A0 YANG library information published by a server can be augmented with
=C2=A0=C2=
=A0 additional packaging related information.

https://datatracker.ietf.org= /doc/draft-rwilton-netmod-yang-packages/

Potentially this work may be of use as part of the YANG versioning design team work.=C2=A0 In addition, if the WG likes this approach of defining YANG packages, then it might also be useful to bind a schema to a YANG instance data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs to be solved?

2) Is the approach in this draft of defining these as instance data documents a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not replacing the way that modules are reported in YANG library-bis.=C2=A0 = Is this the right approach?=C2=A0 This approach tries to allow module-sets to be reused for both schema and packages, but the YANG library-bis rules for combining module-sets (i.e. no conflicts) may make this harder to really reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.

Thanks,
Rob

_______________________________________________
netmod mailing list
netmod@ietf.= org
https://www.ietf.org/mailman/listinfo/netmod
--000000000000af1c770580ae661a-- From nobody Wed Jan 30 07:17:37 2019 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 88010130E98 for ; Wed, 30 Jan 2019 07:17:26 -0800 (PST) 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 Ph67wx9jMPZu for ; Wed, 30 Jan 2019 07:17:25 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4276B130E46 for ; Wed, 30 Jan 2019 07:17:25 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id A0EC218205E8; Wed, 30 Jan 2019 16:17:22 +0100 (CET) Received: from localhost (unknown [195.113.220.122]) by trail.lhotka.name (Postfix) with ESMTPSA id 524E7182015B for ; Wed, 30 Jan 2019 16:17:22 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org Mail-Followup-To: netmod@ietf.org Date: Wed, 30 Jan 2019 16:17:23 +0100 Message-ID: <874l9qjhto.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] features in import X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 15:17:36 -0000 Hi, unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for import-only modules. But is it really so that features have no use in such modules? For example, an enum can depend on a feature, and if it is inside a typedef, it can also be in an import-only module. What if that feature is defined in the same module? Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 30 07:32:14 2019 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 523BD130EA9 for ; Wed, 30 Jan 2019 07:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.631 X-Spam-Level: X-Spam-Status: No, score=-14.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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_KAM_HTML_FONT_INVALID=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 NLgsqNbh7eVP for ; Wed, 30 Jan 2019 07:32:09 -0800 (PST) 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 56861130EA3 for ; Wed, 30 Jan 2019 07:32:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39582; q=dns/txt; s=iport; t=1548862328; x=1550071928; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=K1NT6dEp5WMjm2sTAuOpZWbX9cEwnlB930EFnmVdnvw=; b=Hozs58bNMKS0sA+Txik/N+vwm5AWPAT+06meNDEALBmFgvoNZjha3Mup 0cLhQlQny1HXLmWa9ZDlN8t3l+C7P4MLe6LEuBdbqAT8lDEo92/hirliy ikOc915P+l7CB+Bq4w8C1sa0FW+abptO6iBavFDm0Mi2nSuUuvSFky/YH A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8AADTwlFc/xbLJq0ZAUoaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFUAgEBAQELAQGBDIFdUSASJ4QDiHmNJ5oIDSOESQKDKTc?= =?us-ascii?q?GDQEDAQECAQECbRwMhUoBAQEBAgEjCkUMCwkCEQQBAQEgAQYDAgJGCQgGAQw?= =?us-ascii?q?GAgEBF4MHAYF5CA+NdIFlm2GBLx+EI0FAhG4FjFeBQD+BOIFtfoMeAgMBgTc?= =?us-ascii?q?QTIJTglcCiUxQAoYChmGKe1wJhy6KfgYYgWuFOYMVh3qKGYUshQWHGIFcIii?= =?us-ascii?q?BLjMaCBsVO4Jsix2FPz8DMI07gkwBAQ?= X-IronPort-AV: E=Sophos;i="5.56,540,1539648000"; d="scan'208,217";a="9705137" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2019 15:32:04 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x0UFW3vg020603; Wed, 30 Jan 2019 15:32:04 GMT To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" References: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> From: Robert Wilton Message-ID: <3580e12b-1a41-58a8-9bbc-1ba0a511fa36@cisco.com> Date: Wed, 30 Jan 2019 15:32:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2B0BB52BD9C481FBAAAACE6E" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 15:32:13 -0000 This is a multi-part message in MIME format. --------------2B0BB52BD9C481FBAAAACE6E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jason, Please see inline [RW] ... On 30/01/2019 00:55, Sterne, Jason (Nokia - CA/Ottawa) wrote: > > Thanks Rob. Please see inline. > > Jason > > *From:*Robert Wilton > *Sent:* Thursday, January 24, 2019 1:16 PM > *To:* Sterne, Jason (Nokia - CA/Ottawa) ; > netmod@ietf.org > *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages > > Hi Jason, > > Thanks for the review and comments. > > I've put some responses inline ... > > On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote: > > Hi guys, > > I've gotten most of the way through the draft and have some > initial comments. I haven't digested the section 10 open issues > yet or the examples. > > Section 5 mentions the following: > > YANG library is augmented to allow servers to report the packages > > that they implement and to associate those packages back to > > particular datastore schema. > > Does the combination of this draft and rfc7895bis somehow allow > the same package to be advertised in 2 different datastores, but > with different deviations in each datastore? I'm thinking of a > case, for example, where a package is fully supported in the > running but the package minus a few modules (or parts of modules) > is supported in the operational datastore. There seems to be a 1:1 > relationship between package and rfc7895bis schema. > > So, the intention is no, not directly. > > My aim here is that would implement package "foo", and > would implement package "modified-foo".  Package > "modified-foo" would import package "foo" and also specify the set of > modules that contain the deviations "foo". > > I didn't want a server to be able to see that I implement package > "foo", but then I have all these deviations that change its behavior.  > Instead, it is really implementing a different package that is based > on "foo". > > The packages draft doesn't include any specific leaf-list for > deviations. Section 7.2 mentions that deviations could be > expressed by including modules that happen to contain deviations. > That seems a bit inconsistent with rfc7895bis that has a specific > leaf-list of deviations (and NETCONF hello that specifically > explicitly labels deviation modules). > > I'm conflicted on this one.  I don't really like the deviation list in > YANG library because I regard it as a duplicate source of information, > and then there is a question of which source of data do you trust.  > E.g. do you process a deviation in a module that is not listed in the > deviations module list? > > */[>>JTS: ] Good point. I suppose this issue applies today already. > i.e. what if one of the modules advertised in the is a module > of deviations (without having been referenced by another module as a > deviation module)./* > [RW]: One benefit of explicitly listing deviations would be that, if a package wanted to deviate some nodes in modules from an imported package, then it would be required to explicitly list the modules that was being deviated (along with the deviations).  So a reader of the package definition would be able to easily see that it is not using a 100% faithful implementation of the imported package. > Section 5.1 says the package must be referentially complete. I can > see the advantages of that although wondering if that might limit > flexibility of partitioning modules into packages. I could imagine > use cases for dividing a large set of modules into a few packages > that might rev independently but can still all work together > (especially if they rev in a bc manner). But maybe that just > starts to introduce too much complexity? > > Yes, having partial packages may be useful.  Perhaps just adding a > leaf to indicate whether a package is referentially complete could be > the answer here. > > I didn't understand this part of section 5.1. Can you maybe > illustrate with an example? > > The version/revision of a module listed in the package module list > > supercedes any version/revision of the module listed in a imported > > package module list.  This allows a package to resolve any > > conflicting implemented module versions/revisions in imported > > packages. > > Probably best to see example B.3. in the appendix because it exactly > illustrates this point. > > Basically: > 1) Packages must explicitly list all versions of all modules they > define/import. > 2) If two imported packages define different versions of modules, then > the package that is importing them needs a way to define which version > to use. > 3) A package needs a way to override the version of module specified > in an imported package. > > */[>>JTS: ] Thx. That example does help. I suppose the designer of the > package needs to carefully check that the version they select can be > successfully used by all the modules in the package. /* > > */I think there is a minor typo in example B.3.  The example-3-pkg is > importing "/* */example-import-1" but I believe you meant "/* > */example-import-1-pkg" (and some for import-2)./* > [RW]: I think that is an artifact of YANG instance data.  At the moment, the name of the YANG instance data file is "example-import-2-pkg", which defines the YANG package "example-import-2".  Possibly these names could be aligned to the same, but possibly that may be more confusing? > *//* > > It might be a good idea to add a parent-version to the package > module (to allow tracking lineage of packages). > > Agreed, or maybe allowing a revision history like modules. Not sure > which is better here.  Packages could get a lot of updates, and a long > revision history would not be helpful at all. > > */[>>JTS: ] I think a minimum of just specifying the direct parent is > enough to build the full tree of lineage. We don't need a long history > of N revisions./* > [RW]: Yes, I think that I agree.  This field could be optional to implement. > I like the use of groupings. That allows a manager to use this as > a building block to compose a model that has a list of packages. > > OK. > > Having a global list of mandatory features (vs having the > mandatory feature a per-module list) means inventing the new > : format. Should we instead somehow put the > mandatory features against each module of the package? > > Perhaps.  My thinking here was to have the list of features high up > and very easy to find/parse. > > The location leaf is a uri but then the description says it must > be a url (where the model can be retrieved). I do like that the > namespace is separate from the location, but maybe we should make > location a url type? > > Yes, I was thinking that is should be a URL. > > Do we need a namespace for package names in the model? > > I had them in an earlier version, but I took them out, because I > wasn't sure that they are really useful/required. > > Defining a format to make package names themselves globally unique > might be sufficient. > > */[>>JTS: ] I'm OK with that. It is similar to how we're finding that > it is useful that YANG module names are globally unique (i.e. by > naming with ietf-xxxx or companyabc-xxx)./* > [RW]: Agreed. Thanks, Rob > In 7.3 we only reference module-sets and not modules. So the > grouping of modules into sets and packages must be the same? > > Not necessarily. > > I am trying to reuse the module-set definitions as much as possible > (to avoid duplication).  One issue here is that module-sets are > combined then all the modules must not overlap, which doesn't make the > mapping to module-sets quite so clean. > > A schema can only have a single package. I think that works but it > means a server would advertise multiple schemas if it wants to > support multiple packages. I'm not sure if there are some > downsides to that (it just surprised me). > > My aim here was: >  - multiple packages are advertised in yang-library/packages >  - datastores only report that they "implement" one [top level] > package version.  [The package itself might import other packages.] > > If we do package selection, then for a given YANG client session, and > the version of YANG library available/reported by that session, it > would appear as if the server only implements one top level package > for a datastore.  Different clients choosing different versions would > see slightly different output depending on which package version they > had selected to use. > > Thanks again for the review and the comments! > > Rob > > Jason > > *From:*netmod > *On Behalf Of *Robert Wilton > *Sent:* Thursday, December 20, 2018 12:45 PM > *To:* netmod@ietf.org > *Subject:* [netmod] YANG Packages > > Hi, > > I've written up an ID for a potential solution for YANG packages > using instance data: > > Abstract > >    This document defines YANG packages, an organizational structure > >    holding a set of related YANG modules, that can be used to simplify > >    the conformance and sharing of YANG schema.  It describes how YANG > >    instance data documents are used to define YANG packages, and > how the > >    YANG library information published by a server can be augmented > with > >    additional packaging related information. > > https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ > > Potentially this work may be of use as part of the YANG versioning > design team work.  In addition, if the WG likes this approach of > defining YANG packages, then it might also be useful to bind a > schema to a YANG instance data document. > > Some questions for members of the WG: > > 1) Do members of the WG agree that YANG packages is something that > needs to be solved? > > 2) Is the approach in this draft of defining these as instance > data documents a good starting point? > > 3) This approach augments YANG library-bis, reusing module-sets, > but not replacing the way that modules are reported in YANG > library-bis.  Is this the right approach?  This approach tries to > allow module-sets to be reused for both schema and packages, but > the YANG library-bis rules for combining module-sets (i.e. no > conflicts) may make this harder to really reuse the module-sets > for both purposes. > > Of course, any other comments or feedback is welcome and appreciated. > > Thanks, > Rob > --------------2B0BB52BD9C481FBAAAACE6E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Jason,

Please see inline [RW] ...

On 30/01/2019 00:55, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Thanks Rob. Please see inline.

Jason

 

From: Robert Wilton <rwilton@cisco.com>
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; netmod@ietf.org
Subject: Re: initial comments on draft-rwilton-netmod-yang-packages

 

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi guys,

 

I've gotten most of the way through the draft and have some initial comments. I haven't digested the section 10 open issues yet or the examples.

 

Section 5 mentions the following:

   YANG library is augmented to allow servers to report the packages

   that they implement and to associate those packages back to

   particular datastore schema.

 

Does the combination of this draft and rfc7895bis somehow allow the same package to be advertised in 2 different datastores, but with different deviations in each datastore? I'm thinking of a case, for example, where a package is fully supported in the running but the package minus a few modules (or parts of modules) is supported in the operational datastore. There seems to be a 1:1 relationship between package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that <running> would implement package "foo", and <operational> would implement package "modified-foo".  Package "modified-foo" would import package "foo" and also specify the set of modules that contain the deviations "foo".

I didn't want a server to be able to see that I implement package "foo", but then I have all these deviations that change its behavior.  Instead, it is really implementing a different package that is based on "foo".

 

 

The packages draft doesn't include any specific leaf-list for deviations. Section 7.2 mentions that deviations could be expressed by including modules that happen to contain deviations. That seems a bit inconsistent with rfc7895bis that has a specific leaf-list of deviations (and NETCONF hello that specifically explicitly labels deviation modules).

I'm conflicted on this one.  I don't really like the deviation list in YANG library because I regard it as a duplicate source of information, and then there is a question of which source of data do you trust.  E.g. do you process a deviation in a module that is not listed in the deviations module list?

[>>JTS: ] Good point. I suppose this issue applies today already. i.e. what if one of the modules advertised in the <hello> is a module of deviations (without having been referenced by another module as a deviation module).

[RW]: One benefit of explicitly listing deviations would be that, if a package wanted to deviate some nodes in modules from an imported package, then it would be required to explicitly list the modules that was being deviated (along with the deviations).  So a reader of the package definition would be able to easily see that it is not using a 100% faithful implementation of the imported package.


 

 

Section 5.1 says the package must be referentially complete. I can see the advantages of that although wondering if that might limit flexibility of partitioning modules into packages. I could imagine use cases for dividing a large set of modules into a few packages that might rev independently but can still all work together (especially if they rev in a bc manner). But maybe that just starts to introduce too much complexity?

Yes, having partial packages may be useful.  Perhaps just adding a leaf to indicate whether a package is referentially complete could be the answer here.

 

 

I didn't understand this part of section 5.1. Can you maybe illustrate with an example?

      The version/revision of a module listed in the package module list

      supercedes any version/revision of the module listed in a imported

      package module list.  This allows a package to resolve any

      conflicting implemented module versions/revisions in imported

      packages.

Probably best to see example B.3. in the appendix because it exactly illustrates this point.

Basically:
1) Packages must explicitly list all versions of all modules they define/import.
2) If two imported packages define different versions of modules, then the package that is importing them needs a way to define which version to use.
3) A package needs a way to override the version of module specified in an imported package.

[>>JTS: ] Thx. That example does help. I suppose the designer of the package needs to carefully check that the version they select can be successfully used by all the modules in the package.

I think there is a minor typo in example B.3.  The example-3-pkg is importing " example-import-1" but I believe you meant " example-import-1-pkg" (and some for import-2).

[RW]: I think that is an artifact of YANG instance data.  At the moment, the name of the YANG instance data file is "example-import-2-pkg", which defines the YANG package "example-import-2".  Possibly these names could be aligned to the same, but possibly that may be more confusing?


 

It might be a good idea to add a parent-version to the package module (to allow tracking lineage of packages).

Agreed, or maybe allowing a revision history like modules.  Not sure which is better here.  Packages could get a lot of updates, and a long revision history would not be helpful at all.

[>>JTS: ] I think a minimum of just specifying the direct parent is enough to build the full tree of lineage. We don't need a long history of N revisions.

[RW]: Yes, I think that I agree.  This field could be optional to implement.


 

 

I like the use of groupings. That allows a manager to use this as a building block to compose a model that has a list of packages.

OK.

 

 

Having a global list of mandatory features (vs having the mandatory feature a per-module list) means inventing the new <module-name>:<feature> format. Should we instead somehow put the mandatory features against each module of the package?

Perhaps.  My thinking here was to have the list of features high up and very easy to find/parse.

 

 

The location leaf is a uri but then the description says it must be a url (where the model can be retrieved). I do like that the namespace is separate from the location, but maybe we should make location a url type?

Yes, I was thinking that is should be a URL.

 

 

Do we need a namespace for package names in the model?

I had them in an earlier version, but I took them out, because I wasn't sure that they are really useful/required.

Defining a format to make package names themselves globally unique might be sufficient.

[>>JTS: ] I'm OK with that. It is similar to how we're finding that it is useful that YANG module names are globally unique (i.e. by naming with ietf-xxxx or companyabc-xxx).

 

[RW]: Agreed.

Thanks,
Rob


 

In 7.3 we only reference module-sets and not modules. So the grouping of modules into sets and packages must be the same?

Not necessarily.

I am trying to reuse the module-set definitions as much as possible (to avoid duplication).  One issue here is that module-sets are combined then all the modules must not overlap, which doesn't make the mapping to module-sets quite so clean.

 

 

A schema can only have a single package. I think that works but it means a server would advertise multiple schemas if it wants to support multiple packages. I'm not sure if there are some downsides to that (it just surprised me).

My aim here was:
 - multiple packages are advertised in yang-library/packages
 - datastores only report that they "implement" one [top level] package version.  [The package itself might import other packages.]

If we do package selection, then for a given YANG client session, and the version of YANG library available/reported by that session, it would appear as if the server only implements one top level package for a datastore.  Different clients choosing different versions would see slightly different output depending on which package version they had selected to use.

Thanks again for the review and the comments!

Rob

 

 

 

Jason

 

 

 

From: netmod <netmod-bounces@ietf.org> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: netmod@ietf.org
Subject: [netmod] YANG Packages

 

Hi,

I've written up an ID for a potential solution for YANG packages using instance data:

Abstract
 
   This document defines YANG packages, an organizational structure
   holding a set of related YANG modules, that can be used to simplify
   the conformance and sharing of YANG schema.  It describes how YANG
   instance data documents are used to define YANG packages, and how the
   YANG library information published by a server can be augmented with
   additional packaging related information.

https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/

Potentially this work may be of use as part of the YANG versioning design team work.  In addition, if the WG likes this approach of defining YANG packages, then it might also be useful to bind a schema to a YANG instance data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs to be solved?

2) Is the approach in this draft of defining these as instance data documents a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not replacing the way that modules are reported in YANG library-bis.  Is this the right approach?  This approach tries to allow module-sets to be reused for both schema and packages, but the YANG library-bis rules for combining module-sets (i.e. no conflicts) may make this harder to really reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.

Thanks,
Rob

--------------2B0BB52BD9C481FBAAAACE6E-- From nobody Wed Jan 30 07:53:33 2019 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 66834130F58 for ; Wed, 30 Jan 2019 07:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 aaoAeC5vIlWC for ; Wed, 30 Jan 2019 07:53:27 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::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 4F559130F5B for ; Wed, 30 Jan 2019 07:53:26 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id g11-v6so12752ljk.3 for ; Wed, 30 Jan 2019 07:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c7DHT2NDC6wIFmRADuUdJw89PsgDrI4TeZ4EfxpXPLc=; b=FP/vWxGRFqR5lv4Cj9gpljI23rH5pFZQsDVPNHWbgQcz+62fAprQPp9wOkvneoNVvK TbqTJPBDnbBUtrtWdNhRzvJQumLdatdz5ZsQm2hPLM6OJzxaf3BztsJeXWyPOmbODYqH j/UhvaE3/nmn5DKtwRhOKx1ug9AP0k42bGUorRCZ101btS/fwJms/b7KfnNJTEU2P5Dc BXZxrYSfD9Za/aJLSqH/m2nmo4hb67CUPvSY6Be4/eR7qhp0VtB0pgHhO4TeoLCykwO6 y7tcp8DshWmbKAoJZ/1lXKl4w/AO+a9LUIzl3s3Rm/jTBKa8Q7nd4U8mzs/7s/0f9hg5 CmOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c7DHT2NDC6wIFmRADuUdJw89PsgDrI4TeZ4EfxpXPLc=; b=Olrf5E8QWC1TEAH+OlcoMIoRU9KYUk21lCiEXOVm+GpN29Y+ChqUa/5/RGCEzNEH/u csmri01+gRRSLlKr9tzDQrIABIIfuo3jy0+Mj3/sWqw4NfguxjAyRBMZu64g4UxoWz6i WnorSdHI63dt7wun1UEhvs+C2cjCEO2ZFpBHtSQtL4gwb1ckI08EG/D6U2lLuiR6IGXA qr+TN2QdwdSQ8NK07qSPrQ/MKxkgppO47jnMZxGLdWpLtqB/J66rW0ISv/wvhSvq+W93 EQbPCU+crpTLxzmod7fWCGe9Wicz10LRmHS442FMIT4ET6Wd7IETiWr/lnUg1c/dqHAh c2ag== X-Gm-Message-State: AHQUAuY+u7yAk2L8GCB6WwC5xmbBrbdozfnvp7e+8I5txTmYdn1/7Qgf DlxB650KB0MQTXhpVYkB9GRK0rMpATvGH539BfK0hQ== X-Google-Smtp-Source: AHgI3IYE7EIqk6pEGe7KeZdX5LSjRAgQkq0YeCSVxy7V5VxSDQKYAN8u0mVd5zMrzpoqXlxL1MaqFtUxzyOYeD5Mon8= X-Received: by 2002:a2e:6c16:: with SMTP id h22-v6mr7030838ljc.180.1548863604220; Wed, 30 Jan 2019 07:53:24 -0800 (PST) MIME-Version: 1.0 References: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> In-Reply-To: From: Andy Bierman Date: Wed, 30 Jan 2019 07:53:12 -0800 Message-ID: To: Robert Wilton Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ef821d0580aee892" Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 15:53:32 -0000 --000000000000ef821d0580aee892 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 30, 2019 at 7:16 AM Andy Bierman wrote: > > > On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton wrote: > >> Hi Andy, >> >> Thanks for the comments. >> On 30/01/2019 01:22, Andy Bierman wrote: >> >> Hi, >> >> I originally brought up this issue in July 2015 >> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ >> >> Yes. >> >> The solution I propose is different in the sense that it uses YANG >> instance data to define YANG packages rather than new YANG keywords. I >> believe that this should make it a lower cost solution to define and >> implement. >> >> >> > I think yangvalidator.org has a better solution that does not change YANG > conformance. > > oops -- I meant yangcatalog.org I don't agree that: (1) an instance document is easier for readers and writers. It may be easier for tool makers, but that is subjective. But the solution is irrelevant unless we agree on the problem first. (2) we need to specify YANG conformance for groups of modules (3) it simplifies YANG to define conformance for modules and groups of modules (4) it is unclear how the packages are used by an operator (5) the WG agreed on any problem to solve for which YANG packages is the solution Andy > Andy > > >> >> I don't think the WG ever agreed on the problem that needs to be solved, >> and that is still the case. >> >> That wasn't quite my impression. I also think that folks were busy >> focusing on other WG activity and didn't necessarily have the time to >> concentrate on this. >> >> My draft was aiming on solving two broad problems: >> >> The main goals of YANG package definitions include, but are not >> restricted to: >> >> o To act as a simplified YANG conformance mechanism. Rather than >> conformance being performed against a set of individual YANG >> module revisions, conformance could also be more simply stated in >> terms of YANG packages, with a set modifications (e.g. additional >> modules, deviations, or features). >> >> o To allow YANG datastore schema to be specified in a more concise >> way rather than having to list all modules and revisions. YANG >> package definitions can be defined in documents that can be >> referenced by a URL rather than requiring explicit lists of >> modules to be shared between client and server. Hence, a YANG >> package must contain sufficient information to allow a client or >> server to precisely construct the schema associated with the >> package. >> >> >> >> >> >> In reality each server has 1 package -- its entire library. >> >> This doesn't apply to all servers. For a long time, as a vendor, we have >> had separate packages that can be independently installed, and which extend >> the management model to cover the new functionality. E.g. BNG >> functionality could be in a separate, independently installable, package on >> top of the base router functionality. >> >> For a Linux server, the manageability interface will depend on what >> applications have been installed. >> >> >> The SEMVER work shows >> that vendors are treating platforms as independent release trains, and >> not really >> developing loadable packages. >> >> This depends on the vendor. The YANG versioning work is trying to find a >> solution that works across the industry. I believe that the versioning >> requirements are different for standards developed modules, vs industry >> developed modules, vs vendor modules. >> >> >> >> I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, >> SEMVER import) >> and the YANG Catalog can solve the module compatibility issues. It is >> more of a documentation >> problem than a standards problem. >> >> Having a standard YANG module that can be used to define packages is >> something this is useful and should be standardized. I believe that this >> is better than each vendor coming up with their own solution for this >> problem. >> >> Thanks, >> Rob >> >> >> >> >> Andy >> >> >> >> >> On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) < >> jason.sterne@nokia.com> wrote: >> >>> Thanks Rob. Please see inline. >>> >>> Jason >>> >>> >>> >>> *From:* Robert Wilton >>> *Sent:* Thursday, January 24, 2019 1:16 PM >>> *To:* Sterne, Jason (Nokia - CA/Ottawa) ; >>> netmod@ietf.org >>> *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages >>> >>> >>> >>> Hi Jason, >>> >>> Thanks for the review and comments. >>> >>> I've put some responses inline ... >>> >>> On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote: >>> >>> Hi guys, >>> >>> >>> >>> I've gotten most of the way through the draft and have some initial >>> comments. I haven't digested the section 10 open issues yet or the examples. >>> >>> >>> >>> Section 5 mentions the following: >>> >>> YANG library is augmented to allow servers to report the packages >>> >>> that they implement and to associate those packages back to >>> >>> particular datastore schema. >>> >>> >>> >>> Does the combination of this draft and rfc7895bis somehow allow the same >>> package to be advertised in 2 different datastores, but with different >>> deviations in each datastore? I'm thinking of a case, for example, where a >>> package is fully supported in the running but the package minus a few >>> modules (or parts of modules) is supported in the operational datastore. >>> There seems to be a 1:1 relationship between package and rfc7895bis schema. >>> >>> So, the intention is no, not directly. >>> >>> My aim here is that would implement package "foo", and >>> would implement package "modified-foo". Package >>> "modified-foo" would import package "foo" and also specify the set of >>> modules that contain the deviations "foo". >>> >>> I didn't want a server to be able to see that I implement package "foo", >>> but then I have all these deviations that change its behavior. Instead, it >>> is really implementing a different package that is based on "foo". >>> >>> >>> >>> >>> >>> The packages draft doesn't include any specific leaf-list for >>> deviations. Section 7.2 mentions that deviations could be expressed by >>> including modules that happen to contain deviations. That seems a bit >>> inconsistent with rfc7895bis that has a specific leaf-list of deviations >>> (and NETCONF hello that specifically explicitly labels deviation modules). >>> >>> I'm conflicted on this one. I don't really like the deviation list in >>> YANG library because I regard it as a duplicate source of information, and >>> then there is a question of which source of data do you trust. E.g. do you >>> process a deviation in a module that is not listed in the deviations module >>> list? >>> >>> *[>>JTS: ] Good point. I suppose this issue applies today already. i.e. >>> what if one of the modules advertised in the is a module of >>> deviations (without having been referenced by another module as a deviation >>> module).* >>> >>> >>> >>> >>> >>> Section 5.1 says the package must be referentially complete. I can see >>> the advantages of that although wondering if that might limit flexibility >>> of partitioning modules into packages. I could imagine use cases for >>> dividing a large set of modules into a few packages that might rev >>> independently but can still all work together (especially if they rev in a >>> bc manner). But maybe that just starts to introduce too much complexity? >>> >>> Yes, having partial packages may be useful. Perhaps just adding a leaf >>> to indicate whether a package is referentially complete could be the answer >>> here. >>> >>> >>> >>> >>> >>> I didn't understand this part of section 5.1. Can you maybe illustrate >>> with an example? >>> >>> The version/revision of a module listed in the package module list >>> >>> supercedes any version/revision of the module listed in a imported >>> >>> package module list. This allows a package to resolve any >>> >>> conflicting implemented module versions/revisions in imported >>> >>> packages. >>> >>> Probably best to see example B.3. in the appendix because it exactly >>> illustrates this point. >>> >>> Basically: >>> 1) Packages must explicitly list all versions of all modules they >>> define/import. >>> 2) If two imported packages define different versions of modules, then >>> the package that is importing them needs a way to define which version to >>> use. >>> 3) A package needs a way to override the version of module specified in >>> an imported package. >>> >>> *[>>JTS: ] Thx. That example does help. I suppose the designer of the >>> package needs to carefully check that the version they select can be >>> successfully used by all the modules in the package. * >>> >>> *I think there is a minor typo in example B.3. The example-3-pkg is >>> importing "* *example-import-1" but I believe you meant "* *example-import-1-pkg" >>> (and some for import-2).* >>> >>> >>> >>> It might be a good idea to add a parent-version to the package module >>> (to allow tracking lineage of packages). >>> >>> Agreed, or maybe allowing a revision history like modules. Not sure >>> which is better here. Packages could get a lot of updates, and a long >>> revision history would not be helpful at all. >>> >>> *[>>JTS: ] I think a minimum of just specifying the direct parent is >>> enough to build the full tree of lineage. We don't need a long history of N >>> revisions.* >>> >>> >>> >>> >>> >>> I like the use of groupings. That allows a manager to use this as a >>> building block to compose a model that has a list of packages. >>> >>> OK. >>> >>> >>> >>> >>> >>> Having a global list of mandatory features (vs having the mandatory >>> feature a per-module list) means inventing the new : >>> format. Should we instead somehow put the mandatory features against each >>> module of the package? >>> >>> Perhaps. My thinking here was to have the list of features high up and >>> very easy to find/parse. >>> >>> >>> >>> >>> >>> The location leaf is a uri but then the description says it must be a >>> url (where the model can be retrieved). I do like that the namespace is >>> separate from the location, but maybe we should make location a url type? >>> >>> Yes, I was thinking that is should be a URL. >>> >>> >>> >>> >>> >>> Do we need a namespace for package names in the model? >>> >>> I had them in an earlier version, but I took them out, because I wasn't >>> sure that they are really useful/required. >>> >>> Defining a format to make package names themselves globally unique might >>> be sufficient. >>> >>> *[>>JTS: ] I'm OK with that. It is similar to how we're finding that it >>> is useful that YANG module names are globally unique (i.e. by naming with >>> ietf-xxxx or companyabc-xxx).* >>> >>> >>> >>> >>> >>> In 7.3 we only reference module-sets and not modules. So the grouping of >>> modules into sets and packages must be the same? >>> >>> Not necessarily. >>> >>> I am trying to reuse the module-set definitions as much as possible (to >>> avoid duplication). One issue here is that module-sets are combined then >>> all the modules must not overlap, which doesn't make the mapping to >>> module-sets quite so clean. >>> >>> >>> >>> >>> >>> A schema can only have a single package. I think that works but it means >>> a server would advertise multiple schemas if it wants to support multiple >>> packages. I'm not sure if there are some downsides to that (it just >>> surprised me). >>> >>> My aim here was: >>> - multiple packages are advertised in yang-library/packages >>> - datastores only report that they "implement" one [top level] package >>> version. [The package itself might import other packages.] >>> >>> If we do package selection, then for a given YANG client session, and >>> the version of YANG library available/reported by that session, it would >>> appear as if the server only implements one top level package for a >>> datastore. Different clients choosing different versions would see >>> slightly different output depending on which package version they had >>> selected to use. >>> >>> Thanks again for the review and the comments! >>> >>> Rob >>> >>> >>> >>> >>> >>> >>> >>> Jason >>> >>> >>> >>> >>> >>> >>> >>> *From:* netmod *On >>> Behalf Of *Robert Wilton >>> *Sent:* Thursday, December 20, 2018 12:45 PM >>> *To:* netmod@ietf.org >>> *Subject:* [netmod] YANG Packages >>> >>> >>> >>> Hi, >>> >>> I've written up an ID for a potential solution for YANG packages using >>> instance data: >>> >>> Abstract >>> >>> >>> >>> This document defines YANG packages, an organizational structure >>> >>> holding a set of related YANG modules, that can be used to simplify >>> >>> the conformance and sharing of YANG schema. It describes how YANG >>> >>> instance data documents are used to define YANG packages, and how the >>> >>> YANG library information published by a server can be augmented with >>> >>> additional packaging related information. >>> >>> https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ >>> >>> Potentially this work may be of use as part of the YANG versioning >>> design team work. In addition, if the WG likes this approach of defining >>> YANG packages, then it might also be useful to bind a schema to a YANG >>> instance data document. >>> >>> Some questions for members of the WG: >>> >>> 1) Do members of the WG agree that YANG packages is something that needs >>> to be solved? >>> >>> 2) Is the approach in this draft of defining these as instance data >>> documents a good starting point? >>> >>> 3) This approach augments YANG library-bis, reusing module-sets, but not >>> replacing the way that modules are reported in YANG library-bis. Is this >>> the right approach? This approach tries to allow module-sets to be reused >>> for both schema and packages, but the YANG library-bis rules for combining >>> module-sets (i.e. no conflicts) may make this harder to really reuse the >>> module-sets for both purposes. >>> >>> Of course, any other comments or feedback is welcome and appreciated. >>> >>> Thanks, >>> Rob >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> --000000000000ef821d0580aee892 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 30, 2019 at 7:16 AM Andy = Bierman <andy@yumaworks.com>= ; wrote:


On Wed, Jan 30, 2019 at 4:19 AM Robert Wilto= n <rwilton@cisco.= com> wrote:
=20 =20 =20

Hi Andy,

Thanks for the comments.

On 30/01/2019 01:22, Andy Bierman wrote:
=20
Hi,

I originally brought up this issue in July 2015

Yes.

The solution I propose is different in the sense that it uses YANG instance data to define YANG packages rather than new YANG keywords.=C2=A0=C2=A0 I believe that this should make it a lower cost solution to define and implement.



I think yangvalidator.org has a bette= r solution that does not change YANG conformance.



oops -- I meant yangcatalog.org

I don't agree that:

=C2=A0(1) an instance doc= ument is easier for readers and writers.
It may be easier for too= l makers, but that is subjective.
But the solution is irrelevant = unless we agree on the problem first.

=C2=A0(2) we= need to specify YANG conformance for groups of modules

(3) it simplifies YANG to define conformance for modules and groups o= f modules

(4) it is unclear how the packages are u= sed by an operator

(5) the WG agreed on any proble= m to solve for which YANG packages is the solution


Andy


Andy
=C2=A0


I don't think the WG ever agreed on the problem that needs to be solved,
and that is still the case.

That wasn't quite my impression.=C2=A0 I also think that folks w= ere busy focusing on other WG activity and didn't necessarily have th= e time to concentrate on this.

My draft was aiming on solving two broad problems:

   The main goals of YANG packa=
ge definitions include, but are not
   restricted to:

   o  To act as a simplified YANG conformance mechanism.  Rather than
      conformance being performed against a set of individual YANG
      module revisions, conformance could also be more simply stated in
      terms of YANG packages, with a set modifications (e.g. additional
      modules, deviations, or features).

   o  To allow YANG datastore schema to be specified in a more concise
      way rather than having to list all modules and revisions.  YANG
      package definitions can be defined in documents that can be
      referenced by a URL rather than requiring explicit lists of
      modules to be shared between client and server.  Hence, a YANG
      package must contain sufficient information to allow a client or
      server to precisely construct the schema associated with the
      package.


=C2=A0

In reality each server has 1 package -- its entire library.

This doesn't apply to all servers.=C2=A0 For a long time, as a v= endor, we have had separate packages that can be independently installed, and which extend the management model to cover the new functionality.=C2=A0 E.g. BNG functionality could be in a separate, independently installable, package on top of the base router functionality.

For a Linux server, the manageability interface will depend on what applications have been installed.


The SEMVER work shows
that vendors are treating platforms as independent release trains, and not really
developing loadable packages.

This depends on the vendor.=C2=A0 The YANG versioning work is trying to find a solution that works across the industry.=C2=A0 I believe th= at the versioning requirements are different for standards developed modules, vs industry developed modules, vs vendor modules.



I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, SEMVER import)
and=C2=A0 the YANG Catalog can solve the module compatibilit= y issues. It is more of a documentation
problem than a standards problem.

Having a standard YANG module that can be used to define packages is something this is useful and should be standardized.=C2=A0 I belie= ve that this is better than each vendor coming up with their own solution for this problem.

Thanks,
Rob




Andy




On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:

Thank= s Rob. Please see inline.

Jason=

=C2= =A0

From: Robert Wilton <rwilton@cisco.com>
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; netmod@ietf.org
Subject: Re: initial comments on draft-rwilton-netmod-yang-packages

=C2=A0

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

H= i guys,

= =C2=A0

I= 've gotten most of the way through the draft and have some initial comments. I haven't digested the section 10 open issues yet or the examples.

= =C2=A0

S= ection 5 mentions the following:

= =C2=A0=C2=A0 YANG library is augmented to allow servers to report the packages

= =C2=A0=C2=A0 that they implement and to associate those packages back to

= =C2=A0=C2=A0 particular datastore schema.

= =C2=A0

D= oes the combination of this draft and rfc7895bis somehow allow the same package to be advertised in 2 different datastores, but with different deviations in each datastore? I'm thinking of a case, for example, where a package is fully supported in the running but the package minus a few modules (or parts of modules) is supported in the operational datastore. There seems to be a 1:1 relationship between package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that <running> would implement package "foo", and <operational> would im= plement package "modified-foo".=C2=A0 Package "mod= ified-foo" would import package "foo" and also specify the set o= f modules that contain the deviations "foo".

I didn't want a server to be able to see that I implement package "foo", but then I have all th= ese deviations that change its behavior.=C2=A0 Instead, it is really implementing a different package that is based on "foo".

=C2=A0

= =C2=A0

T= he packages draft doesn't include any specific leaf-list for deviations. Section 7.2 mentions that deviations could be expressed by including modules that happen to contain deviations. That seems a bit inconsistent with rfc7895bis that has a specific leaf-list of deviations (and NETCONF hello that specifically explicitly labels deviation modules).

I'm conflicted on this one.=C2=A0 I don't really= like the deviation list in YANG library because I regard it as a duplicate source of information, and then there is a question of which source of data do you trust.=C2=A0 E.g. do you process a deviation in a module that is not listed in the deviations module list?

[>>JTS: ] Good point. I suppose this issue applies today already. i.e. what if one of the modules advertised in the <hello> is a module of deviations (without having been referenced by another module as a deviation module).

=C2=A0

= =C2=A0

S= ection 5.1 says the package must be referentially complete. I can see the advantages of that although wondering if that might limit flexibility of partitioning modules into packages. I could imagine use cases for dividing a large set of modules into a few packages that might rev independently but can still all work together (especially if they rev in a bc manner). But maybe that just starts to introduce too much complexity?

Yes, having partial packages may be useful.=C2=A0 Perhap= s just adding a leaf to indicate whether a package is referentially complete could be the answer here.

=C2=A0

= =C2=A0

I didn't understand this part of section 5.1. Can you maybe illustrate with an example?

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The version/revision of a module listed in the package module list

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 supercedes any version/revision of the module listed in a imported

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 package module list.=C2=A0 This allows a package to resolve any

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 conflicting implemented module versions/revisions in imported

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 packages.

Probably best to see example B.3. in the appendix because it exactly illustrates this point.

Basically:
1) Packages must explicitly list all versions of all modules they define/import.
2) If two imported packages define different versions of modules, then the package that is importing them needs a way to define which version to use.
3) A package needs a way to override the version of module specified in an imported package.

[>>JTS: ] Thx. That example does help. I suppose the designer of the package needs to carefully check that the version they select can be successfully used by all the modules in the package.

I think there is a minor typo in example B.3.=C2=A0 The example-3-pk= g is importing " example-import-1&q= uot; but I believe you meant " example-import-1-p= kg" (and some for import-2).

= =C2=A0

I= t might be a good idea to add a parent-version to the package module (to allow tracking lineage of packages).

Agreed, or maybe allowing a revision history like modules.=C2=A0 Not sure which is better here.=C2=A0 Packa= ges could get a lot of updates, and a long revision history would not be helpful at all.

[>>JTS: ] I think a minimum of just specifying the direct parent is enough to build the full tree of lineage. We don't need a long history of N revisions.

=C2=A0

= =C2=A0

I like the us= e of groupings. That allows a manager to use this as a building block to compose a model that has a list of packages.

OK.

=C2=A0

= =C2=A0

Having a global list of mandatory features (vs having the mandatory feature a per-module list) means inventing the new <module-name>:<feature> format. Should we instead somehow put the mandatory features against each module of the package?

Perhaps.=C2=A0 My thinking here was to have the list of features high up and very easy to find/parse.

=C2=A0

=C2=A0=

The location leaf is a uri but then the description says it must be a url (where the model can be retrieved). I do like that the namespace is separate from the location, but maybe we should make location a url type?

Yes, I was thinking that is should be a URL.

=C2=A0

=C2=A0=

Do we need a namespace for package names in the model?

I had them in an earlier version, but I took them out, because I wasn't sure that they are really useful/required.

Defining a format to make package names themselves globally unique might be sufficient.

[>>JTS: ] I'm OK with that. It is similar to how we'r= e finding that it is useful that YANG module names are globally unique (i.e. by naming with ietf-xxxx or companyabc-xxx).

=C2=A0

=C2=A0=

In 7.3 we onl= y reference module-sets and not modules. So the grouping of modules into sets and packages must be the same?

Not necessarily.

I am trying to reuse the module-set definitions as much as possible (to avoid duplication).=C2=A0 One issue here is that module-sets are combined then all the modules must not overlap, which doesn't make the mapping to module-sets quite so clean.

=C2=A0

=C2=A0=

A schema can only have a single package. I think that works but it means a server would advertise multiple schemas if it wants to support multiple packages. I'm not sure if there are some downsides to that (it just surprised me).

My aim here was:
=C2=A0- multiple packages are advertised in yang-library/packages
=C2=A0- datastores only report that they "implement&= quot; one [top level] package version.=C2=A0 [The package itself might import other packages.]

If we do package selection, then for a given YANG client session, and the version of YANG library available/reported by that session, it would appear as if the server only implements one top level package for a datastore.=C2=A0 Different clients choosing differe= nt versions would see slightly different output depending on which package version they had selected to use.

Thanks again for the review and the comments!

Rob

=C2=A0

=C2=A0

=C2=A0=

Jason<= /p>

=C2=A0=

= =C2=A0

= =C2=A0

From: netmod <netmod-bounces@ietf.org> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: netmod@ietf.org
Subject: [netmod] YANG Packages

=C2=A0

Hi,

I've written up an ID for a potential solution for YANG packages using instance data:

Abstract=

=C2=A0
=C2=A0=C2=
=A0 This document defines YANG packages, an organizational structure=

=C2=A0=C2=
=A0 holding a set of related YANG modules, that can be used to simplify
=C2=A0=C2=
=A0 the conformance and sharing of YANG schema.=C2=A0 It describes how YANG=

=C2=A0=C2=
=A0 instance data documents are used to define YANG packages, and how the
=C2=A0=C2=
=A0 YANG library information published by a server can be augmented with
=C2=A0=C2=
=A0 additional packaging related information.

https://datatracker.ietf.org= /doc/draft-rwilton-netmod-yang-packages/

Potentially this work may be of use as part of the YANG versioning design team work.=C2=A0 In addition, if the WG likes this approach of defining YANG packages, then it might also be useful to bind a schema to a YANG instance data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs to be solved?

2) Is the approach in this draft of defining these as instance data documents a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not replacing the way that modules are reported in YANG library-bis.=C2=A0 = Is this the right approach?=C2=A0 This approach tries to allow module-sets to be reused for both schema and packages, but the YANG library-bis rules for combining module-sets (i.e. no conflicts) may make this harder to really reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.

Thanks,
Rob

_______________________________________________
netmod mailing list
netmod@ietf.= org
https://www.ietf.org/mailman/listinfo/netmod
--000000000000ef821d0580aee892-- From nobody Wed Jan 30 08:02:14 2019 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 77518126F72 for ; Wed, 30 Jan 2019 08:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.631 X-Spam-Level: X-Spam-Status: No, score=-14.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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_KAM_HTML_FONT_INVALID=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 apMmY6e1XFF4 for ; Wed, 30 Jan 2019 08:02:07 -0800 (PST) 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 665CC12426E for ; Wed, 30 Jan 2019 08:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60544; q=dns/txt; s=iport; t=1548864126; x=1550073726; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=JQxOsBxrmyrcn4MfX+kpuCC5a0SoK+RmvvsY7CwxaBs=; b=OKf9raq3pp9rNi6oRtZmo7Gdv7MNX/3vBPEbHJvunXSgq8J8BwQG+xgx 6hi57K0bYO4ZxbJV6/bRZD/K3oEe21aerGb2U1JlxukJ3XLJ8SDtT4j5j L07GBREhKExoD2DIDyDdFHcnHRA0agJxg8KftR3OWnp1OVPngApG0bFgD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAABgyVFc/xbLJq0ZAUoaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFUAgEBAQELAQGBDIFdUSASJ4QDiHmNJ4MIlnwEDRgBCoQ?= =?us-ascii?q?DRgKDKTcGDQEDAQECAQECbRwMhUoBAQEBAgEBARgJSwQHEAkCEQQBAQEgAQY?= =?us-ascii?q?DAgInHwkIBg0GAgEBF4MHAYF5CA+NbIFhm2GBLx+EI0FAhHOMV4FAP4E4gW1?= =?us-ascii?q?+gx4BAQMBgTcQTIJTglcCiUwyHgIDgUuENIZhintcCYcuin4GGIFrUYRogxW?= =?us-ascii?q?Heo9FhQWHGIFcIiiBLjMaCBsVO4JsCYsUhT8/AzCNO4JMAQE?= X-IronPort-AV: E=Sophos;i="5.56,541,1539648000"; d="scan'208,217";a="9707230" 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; 30 Jan 2019 16:02:03 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x0UG23dX018825; Wed, 30 Jan 2019 16:02:03 GMT To: Andy Bierman Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" References: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> From: Robert Wilton Message-ID: Date: Wed, 30 Jan 2019 16:02:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C22F61714558C941D981CB27" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 16:02:11 -0000 This is a multi-part message in MIME format. --------------C22F61714558C941D981CB27 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 30/01/2019 15:16, Andy Bierman wrote: > > > On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton > wrote: > > Hi Andy, > > Thanks for the comments. > > On 30/01/2019 01:22, Andy Bierman wrote: >> Hi, >> >> I originally brought up this issue in July 2015 >> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ > > Yes. > > The solution I propose is different in the sense that it uses YANG > instance data to define YANG packages rather than new YANG > keywords.   I believe that this should make it a lower cost > solution to define and implement. > > > > I think yangvalidator.org has a better > solution that does not change YANG conformance. Do you mean that we can just use zip files with the list of modules? I don't really see how this helps. Consider: - server vendor A, implements some subset of the OpenConfig YANG modules, each at a particular version, along with some deviations and vendor augmentations. - server vendor B, implements the same subset of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations. - server vendor C, implements a slightly different set of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations. As a client, how do I know what module versions to code against, when I want to work with devices provided by all three vendors? I might be wrong, but I think that the OC solution is use git tags, so they tag sets of modules that are expected to work together and also to provide a linear release history of their sets of modules.  So, if everyone implements the module versions associated with a git tag then it should convert a two dimensional problem of module revisions into a linear problem.  The YANG packages draft is aiming to provide a solution to this problem that doesn't require the use of git, or sending zip files of modules around. At the moment, it seems that everyone is doing this in different ways:  - Yumawork customers/servers use zip files of modules for conformance.  - OpenConfig client/server implementations use git tags, or git refpoints.  - Cisco customers use the contents of directories on github YangModels. Finally, this draft doesn't change YANG conformance, it just expresses it in what is intended to be a simpler way. Thanks, Rob > > > Andy > >> >> I don't think the WG ever agreed on the problem that needs to be >> solved, >> and that is still the case. > > That wasn't quite my impression.  I also think that folks were > busy focusing on other WG activity and didn't necessarily have the > time to concentrate on this. > > My draft was aiming on solving two broad problems: > > The main goals of YANG package definitions include, but are not > restricted to: > > o To act as a simplified YANG conformance mechanism. Rather than > conformance being performed against a set of individual YANG > module revisions, conformance could also be more simply stated in > terms of YANG packages, with a set modifications (e.g. additional > modules, deviations, or features). > > o To allow YANG datastore schema to be specified in a more concise > way rather than having to list all modules and revisions. YANG > package definitions can be defined in documents that can be > referenced by a URL rather than requiring explicit lists of > modules to be shared between client and server. Hence, a YANG > package must contain sufficient information to allow a client or > server to precisely construct the schema associated with the > package. > > > >> >> In reality each server has 1 package -- its entire library. > > This doesn't apply to all servers.  For a long time, as a vendor, > we have had separate packages that can be independently installed, > and which extend the management model to cover the new > functionality.  E.g. BNG functionality could be in a separate, > independently installable, package on top of the base router > functionality. > > For a Linux server, the manageability interface will depend on > what applications have been installed. > > >> The SEMVER work shows >> that vendors are treating platforms as independent release >> trains, and not really >> developing loadable packages. > > This depends on the vendor.  The YANG versioning work is trying to > find a solution that works across the industry.  I believe that > the versioning requirements are different for standards developed > modules, vs industry developed modules, vs vendor modules. > > >> >> I think YANG 1.2 improvements for conformance (e.g., >> YANG-redirects, SEMVER import) >> and  the YANG Catalog can solve the module compatibility issues. >> It is more of a documentation >> problem than a standards problem. > > Having a standard YANG module that can be used to define packages > is something this is useful and should be standardized.  I believe > that this is better than each vendor coming up with their own > solution for this problem. > > Thanks, > Rob > > >> >> >> Andy >> >> >> >> >> On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) >> > wrote: >> >> Thanks Rob. Please see inline. >> >> Jason >> >> *From:*Robert Wilton > > >> *Sent:* Thursday, January 24, 2019 1:16 PM >> *To:* Sterne, Jason (Nokia - CA/Ottawa) >> >; >> netmod@ietf.org >> *Subject:* Re: initial comments on >> draft-rwilton-netmod-yang-packages >> >> Hi Jason, >> >> Thanks for the review and comments. >> >> I've put some responses inline ... >> >> On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote: >> >> Hi guys, >> >> I've gotten most of the way through the draft and have >> some initial comments. I haven't digested the section 10 >> open issues yet or the examples. >> >> Section 5 mentions the following: >> >>    YANG library is augmented to allow servers to report >> the packages >> >>    that they implement and to associate those packages >> back to >> >>    particular datastore schema. >> >> Does the combination of this draft and rfc7895bis somehow >> allow the same package to be advertised in 2 different >> datastores, but with different deviations in each >> datastore? I'm thinking of a case, for example, where a >> package is fully supported in the running but the package >> minus a few modules (or parts of modules) is supported in >> the operational datastore. There seems to be a 1:1 >> relationship between package and rfc7895bis schema. >> >> So, the intention is no, not directly. >> >> My aim here is that would implement package "foo", >> and would implement package "modified-foo".  >> Package "modified-foo" would import package "foo" and also >> specify the set of modules that contain the deviations "foo". >> >> I didn't want a server to be able to see that I implement >> package "foo", but then I have all these deviations that >> change its behavior.  Instead, it is really implementing a >> different package that is based on "foo". >> >> The packages draft doesn't include any specific leaf-list >> for deviations. Section 7.2 mentions that deviations >> could be expressed by including modules that happen to >> contain deviations. That seems a bit inconsistent with >> rfc7895bis that has a specific leaf-list of deviations >> (and NETCONF hello that specifically explicitly labels >> deviation modules). >> >> I'm conflicted on this one.  I don't really like the >> deviation list in YANG library because I regard it as a >> duplicate source of information, and then there is a question >> of which source of data do you trust.  E.g. do you process a >> deviation in a module that is not listed in the deviations >> module list? >> >> */[>>JTS: ] Good point. I suppose this issue applies today >> already. i.e. what if one of the modules advertised in the >> is a module of deviations (without having been >> referenced by another module as a deviation module)./* >> >> Section 5.1 says the package must be referentially >> complete. I can see the advantages of that although >> wondering if that might limit flexibility of partitioning >> modules into packages. I could imagine use cases for >> dividing a large set of modules into a few packages that >> might rev independently but can still all work together >> (especially if they rev in a bc manner). But maybe that >> just starts to introduce too much complexity? >> >> Yes, having partial packages may be useful.  Perhaps just >> adding a leaf to indicate whether a package is referentially >> complete could be the answer here. >> >> I didn't understand this part of section 5.1. Can you >> maybe illustrate with an example? >> >>       The version/revision of a module listed in the >> package module list >> >> supercedes any version/revision of the module listed in a >> imported >> >>       package module list.  This allows a package to >> resolve any >> >> conflicting implemented module versions/revisions in imported >> >>       packages. >> >> Probably best to see example B.3. in the appendix because it >> exactly illustrates this point. >> >> Basically: >> 1) Packages must explicitly list all versions of all modules >> they define/import. >> 2) If two imported packages define different versions of >> modules, then the package that is importing them needs a way >> to define which version to use. >> 3) A package needs a way to override the version of module >> specified in an imported package. >> >> */[>>JTS: ] Thx. That example does help. I suppose the >> designer of the package needs to carefully check that the >> version they select can be successfully used by all the >> modules in the package. /* >> >> */I think there is a minor typo in example B.3.  The >> example-3-pkg is importing "/* */example-import-1" but I >> believe you meant "/* */example-import-1-pkg" (and some for >> import-2)./* >> >> It might be a good idea to add a parent-version to the >> package module (to allow tracking lineage of packages). >> >> Agreed, or maybe allowing a revision history like modules.  >> Not sure which is better here.  Packages could get a lot of >> updates, and a long revision history would not be helpful at all. >> >> */[>>JTS: ] I think a minimum of just specifying the direct >> parent is enough to build the full tree of lineage. We don't >> need a long history of N revisions./* >> >> I like the use of groupings. That allows a manager to use >> this as a building block to compose a model that has a >> list of packages. >> >> OK. >> >> Having a global list of mandatory features (vs having the >> mandatory feature a per-module list) means inventing the >> new : format. Should we instead >> somehow put the mandatory features against each module of >> the package? >> >> Perhaps.  My thinking here was to have the list of features >> high up and very easy to find/parse. >> >> The location leaf is a uri but then the description says >> it must be a url (where the model can be retrieved). I do >> like that the namespace is separate from the location, >> but maybe we should make location a url type? >> >> Yes, I was thinking that is should be a URL. >> >> Do we need a namespace for package names in the model? >> >> I had them in an earlier version, but I took them out, >> because I wasn't sure that they are really useful/required. >> >> Defining a format to make package names themselves globally >> unique might be sufficient. >> >> */[>>JTS: ] I'm OK with that. It is similar to how we're >> finding that it is useful that YANG module names are globally >> unique (i.e. by naming with ietf-xxxx or companyabc-xxx)./* >> >> In 7.3 we only reference module-sets and not modules. So >> the grouping of modules into sets and packages must be >> the same? >> >> Not necessarily. >> >> I am trying to reuse the module-set definitions as much as >> possible (to avoid duplication).  One issue here is that >> module-sets are combined then all the modules must not >> overlap, which doesn't make the mapping to module-sets quite >> so clean. >> >> A schema can only have a single package. I think that >> works but it means a server would advertise multiple >> schemas if it wants to support multiple packages. I'm not >> sure if there are some downsides to that (it just >> surprised me). >> >> My aim here was: >>  - multiple packages are advertised in yang-library/packages >>  - datastores only report that they "implement" one [top >> level] package version.  [The package itself might import >> other packages.] >> >> If we do package selection, then for a given YANG client >> session, and the version of YANG library available/reported >> by that session, it would appear as if the server only >> implements one top level package for a datastore.  Different >> clients choosing different versions would see slightly >> different output depending on which package version they had >> selected to use. >> >> Thanks again for the review and the comments! >> >> Rob >> >> Jason >> >> *From:*netmod >> *On Behalf Of *Robert Wilton >> *Sent:* Thursday, December 20, 2018 12:45 PM >> *To:* netmod@ietf.org >> *Subject:* [netmod] YANG Packages >> >> Hi, >> >> I've written up an ID for a potential solution for YANG >> packages using instance data: >> >> Abstract >> >>    This document defines YANG packages, an organizational >> structure >> >>    holding a set of related YANG modules, that can be >> used to simplify >> >>    the conformance and sharing of YANG schema.  It >> describes how YANG >> >>    instance data documents are used to define YANG >> packages, and how the >> >>    YANG library information published by a server can be >> augmented with >> >>    additional packaging related information. >> >> https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ >> >> Potentially this work may be of use as part of the YANG >> versioning design team work.  In addition, if the WG >> likes this approach of defining YANG packages, then it >> might also be useful to bind a schema to a YANG instance >> data document. >> >> Some questions for members of the WG: >> >> 1) Do members of the WG agree that YANG packages is >> something that needs to be solved? >> >> 2) Is the approach in this draft of defining these as >> instance data documents a good starting point? >> >> 3) This approach augments YANG library-bis, reusing >> module-sets, but not replacing the way that modules are >> reported in YANG library-bis.  Is this the right >> approach?  This approach tries to allow module-sets to be >> reused for both schema and packages, but the YANG >> library-bis rules for combining module-sets (i.e. no >> conflicts) may make this harder to really reuse the >> module-sets for both purposes. >> >> Of course, any other comments or feedback is welcome and >> appreciated. >> >> Thanks, >> Rob >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> --------------C22F61714558C941D981CB27 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 30/01/2019 15:16, Andy Bierman wrote:


On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,

Thanks for the comments.

On 30/01/2019 01:22, Andy Bierman wrote:
Hi,

I originally brought up this issue in July 2015

Yes.

The solution I propose is different in the sense that it uses YANG instance data to define YANG packages rather than new YANG keywords.   I believe that this should make it a lower cost solution to define and implement.



I think yangvalidator.org has a better solution that does not change YANG conformance.

Do you mean that we can just use zip files with the list of modules?

I don't really see how this helps.

Consider:
- server vendor A, implements some subset of the OpenConfig YANG modules, each at a particular version, along with some deviations and vendor augmentations.
- server vendor B, implements the same subset of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations.
- server vendor C, implements a slightly different set of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations.

As a client, how do I know what module versions to code against, when I want to work with devices provided by all three vendors?

I might be wrong, but I think that the OC solution is use git tags, so they tag sets of modules that are expected to work together and also to provide a linear release history of their sets of modules.  So, if everyone implements the module versions associated with a git tag then it should convert a two dimensional problem of module revisions into a linear problem.  The YANG packages draft is aiming to provide a solution to this problem that doesn't require the use of git, or sending zip files of modules around.

At the moment, it seems that everyone is doing this in different ways:
 - Yumawork customers/servers use zip files of modules for conformance.
 - OpenConfig client/server implementations use git tags, or git refpoints.
 - Cisco customers use the contents of directories on github YangModels.

Finally, this draft doesn't change YANG conformance, it just expresses it in what is intended to be a simpler way.

Thanks,
Rob




Andy
 


I don't think the WG ever agreed on the problem that needs to be solved,
and that is still the case.

That wasn't quite my impression.  I also think that folks were busy focusing on other WG activity and didn't necessarily have the time to concentrate on this.

My draft was aiming on solving two broad problems:

   The main goals of YANG package definitions include, but are not
   restricted to:

   o  To act as a simplified YANG conformance mechanism.  Rather than
      conformance being performed against a set of individual YANG
      module revisions, conformance could also be more simply stated in
      terms of YANG packages, with a set modifications (e.g. additional
      modules, deviations, or features).

   o  To allow YANG datastore schema to be specified in a more concise
      way rather than having to list all modules and revisions.  YANG
      package definitions can be defined in documents that can be
      referenced by a URL rather than requiring explicit lists of
      modules to be shared between client and server.  Hence, a YANG
      package must contain sufficient information to allow a client or
      server to precisely construct the schema associated with the
      package.


 

In reality each server has 1 package -- its entire library.

This doesn't apply to all servers.  For a long time, as a vendor, we have had separate packages that can be independently installed, and which extend the management model to cover the new functionality.  E.g. BNG functionality could be in a separate, independently installable, package on top of the base router functionality.

For a Linux server, the manageability interface will depend on what applications have been installed.


The SEMVER work shows
that vendors are treating platforms as independent release trains, and not really
developing loadable packages.

This depends on the vendor.  The YANG versioning work is trying to find a solution that works across the industry.  I believe that the versioning requirements are different for standards developed modules, vs industry developed modules, vs vendor modules.



I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, SEMVER import)
and  the YANG Catalog can solve the module compatibility issues. It is more of a documentation
problem than a standards problem.

Having a standard YANG module that can be used to define packages is something this is useful and should be standardized.  I believe that this is better than each vendor coming up with their own solution for this problem.

Thanks,
Rob




Andy




On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:

Thanks Rob. Please see inline.

Jason

 

From: Robert Wilton <rwilton@cisco.com>
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; netmod@ietf.org
Subject: Re: initial comments on draft-rwilton-netmod-yang-packages

 

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi guys,

 

I've gotten most of the way through the draft and have some initial comments. I haven't digested the section 10 open issues yet or the examples.

 

Section 5 mentions the following:

   YANG library is augmented to allow servers to report the packages

   that they implement and to associate those packages back to

   particular datastore schema.

 

Does the combination of this draft and rfc7895bis somehow allow the same package to be advertised in 2 different datastores, but with different deviations in each datastore? I'm thinking of a case, for example, where a package is fully supported in the running but the package minus a few modules (or parts of modules) is supported in the operational datastore. There seems to be a 1:1 relationship between package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that <running> would implement package "foo", and <operational> would implement package "modified-foo".  Package "modified-foo" would import package "foo" and also specify the set of modules that contain the deviations "foo".

I didn't want a server to be able to see that I implement package "foo", but then I have all these deviations that change its behavior.  Instead, it is really implementing a different package that is based on "foo".

 

 

The packages draft doesn't include any specific leaf-list for deviations. Section 7.2 mentions that deviations could be expressed by including modules that happen to contain deviations. That seems a bit inconsistent with rfc7895bis that has a specific leaf-list of deviations (and NETCONF hello that specifically explicitly labels deviation modules).

I'm conflicted on this one.  I don't really like the deviation list in YANG library because I regard it as a duplicate source of information, and then there is a question of which source of data do you trust.  E.g. do you process a deviation in a module that is not listed in the deviations module list?

[>>JTS: ] Good point. I suppose this issue applies today already. i.e. what if one of the modules advertised in the <hello> is a module of deviations (without having been referenced by another module as a deviation module).

 

 

Section 5.1 says the package must be referentially complete. I can see the advantages of that although wondering if that might limit flexibility of partitioning modules into packages. I could imagine use cases for dividing a large set of modules into a few packages that might rev independently but can still all work together (especially if they rev in a bc manner). But maybe that just starts to introduce too much complexity?

Yes, having partial packages may be useful.  Perhaps just adding a leaf to indicate whether a package is referentially complete could be the answer here.

 

 

I didn't understand this part of section 5.1. Can you maybe illustrate with an example?

      The version/revision of a module listed in the package module list

      supercedes any version/revision of the module listed in a imported

      package module list.  This allows a package to resolve any

      conflicting implemented module versions/revisions in imported

      packages.

Probably best to see example B.3. in the appendix because it exactly illustrates this point.

Basically:
1) Packages must explicitly list all versions of all modules they define/import.
2) If two imported packages define different versions of modules, then the package that is importing them needs a way to define which version to use.
3) A package needs a way to override the version of module specified in an imported package.

[>>JTS: ] Thx. That example does help. I suppose the designer of the package needs to carefully check that the version they select can be successfully used by all the modules in the package.

I think there is a minor typo in example B.3.  The example-3-pkg is importing " example-import-1" but I believe you meant " example-import-1-pkg" (and some for import-2).

 

It might be a good idea to add a parent-version to the package module (to allow tracking lineage of packages).

Agreed, or maybe allowing a revision history like modules.  Not sure which is better here.  Packages could get a lot of updates, and a long revision history would not be helpful at all.

[>>JTS: ] I think a minimum of just specifying the direct parent is enough to build the full tree of lineage. We don't need a long history of N revisions.

 

 

I like the use of groupings. That allows a manager to use this as a building block to compose a model that has a list of packages.

OK.

 

 

Having a global list of mandatory features (vs having the mandatory feature a per-module list) means inventing the new <module-name>:<feature> format. Should we instead somehow put the mandatory features against each module of the package?

Perhaps.  My thinking here was to have the list of features high up and very easy to find/parse.

 

 

The location leaf is a uri but then the description says it must be a url (where the model can be retrieved). I do like that the namespace is separate from the location, but maybe we should make location a url type?

Yes, I was thinking that is should be a URL.

 

 

Do we need a namespace for package names in the model?

I had them in an earlier version, but I took them out, because I wasn't sure that they are really useful/required.

Defining a format to make package names themselves globally unique might be sufficient.

[>>JTS: ] I'm OK with that. It is similar to how we're finding that it is useful that YANG module names are globally unique (i.e. by naming with ietf-xxxx or companyabc-xxx).

 

 

In 7.3 we only reference module-sets and not modules. So the grouping of modules into sets and packages must be the same?

Not necessarily.

I am trying to reuse the module-set definitions as much as possible (to avoid duplication).  One issue here is that module-sets are combined then all the modules must not overlap, which doesn't make the mapping to module-sets quite so clean.

 

 

A schema can only have a single package. I think that works but it means a server would advertise multiple schemas if it wants to support multiple packages. I'm not sure if there are some downsides to that (it just surprised me).

My aim here was:
 - multiple packages are advertised in yang-library/packages
 - datastores only report that they "implement" one [top level] package version.  [The package itself might import other packages.]

If we do package selection, then for a given YANG client session, and the version of YANG library available/reported by that session, it would appear as if the server only implements one top level package for a datastore.  Different clients choosing different versions would see slightly different output depending on which package version they had selected to use.

Thanks again for the review and the comments!

Rob

 

 

 

Jason

 

 

 

From: netmod <netmod-bounces@ietf.org> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: netmod@ietf.org
Subject: [netmod] YANG Packages

 

Hi,

I've written up an ID for a potential solution for YANG packages using instance data:

Abstract
 
   This document defines YANG packages, an organizational structure
   holding a set of related YANG modules, that can be used to simplify
   the conformance and sharing of YANG schema.  It describes how YANG
   instance data documents are used to define YANG packages, and how the
   YANG library information published by a server can be augmented with
   additional packaging related information.

https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/

Potentially this work may be of use as part of the YANG versioning design team work.  In addition, if the WG likes this approach of defining YANG packages, then it might also be useful to bind a schema to a YANG instance data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs to be solved?

2) Is the approach in this draft of defining these as instance data documents a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not replacing the way that modules are reported in YANG library-bis.  Is this the right approach?  This approach tries to allow module-sets to be reused for both schema and packages, but the YANG library-bis rules for combining module-sets (i.e. no conflicts) may make this harder to really reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.

Thanks,
Rob

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--------------C22F61714558C941D981CB27-- From nobody Wed Jan 30 09:31:27 2019 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 A4C9C130E5A for ; Wed, 30 Jan 2019 09:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 mGoYK_GlyNvC for ; Wed, 30 Jan 2019 09:31:20 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 E1BDF12D4EF for ; Wed, 30 Jan 2019 09:31:19 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id u89-v6so321063lje.1 for ; Wed, 30 Jan 2019 09:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8lIbaCWpmfV7+WGjPybRE7Bpbn189GPEV8iuqxb1658=; b=XMxUTlzwn15tb+Zqe3gZ4YIP2xNS7iHIgLO4H27Pw6QvRyjWErdRlL2Aw4SWCRDUrV XtoSDI5n6VLeiVv+HFgfik2g3nhcIAFUG6Na2zkSwetNm3g1GmDbMKhi4vWXnVkeuj1v 4jDhDiS8dIYQ27lw9XqDpSKkPS7R/FKkdHfMeGf/LjIG4pNZExgrQ5pDjfTp8+SIlxF5 P5doCubZmNSSK7XTSJkJVSHgypWLzHCfImRUThRYZ520VQ84LMtPb7UBo8zkHwtY3/Eg ID/OiMXs/mJW6ELhlTK0u3wx9854rYhA9s4tPbfrpGA5cvGJ9y7JYSL9ThATsXqJWOhI ZHBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8lIbaCWpmfV7+WGjPybRE7Bpbn189GPEV8iuqxb1658=; b=rdy0+QW++3gx0qW+nYWFsF1Am065C+RQxdkcRMj4y3BpirwSqDZ/LODn+3rvUyAoHm e8k6nLsa6TnbVY0I4f8jPTXIiL90mZym5OYLXlNSx2KeoURHZ0aVZdEZ5c0sDnuqIcM7 5Yjah5B7mTS7ZYUxkS9RmB9eEItjU90THxPHkmRAcN0drDPULXOxvKsVIQYZKOyFhjB4 nuKdONrMnG9QQGkh88LOzS7A8PsP0ttQ9NJeBgOjdNPCbcuqBXVxShgVeTRGUwCqbVJP eOadpTwfAhI/OWccCDtxRGH9YSONURbfWIbU7c4sD5L7hbqX4Auj/mDOW/MMP9vA35oM gBAA== X-Gm-Message-State: AJcUukdY7nJzjrUTe4r5RIoBhePhOwCMdFufxlp4djI0c7Hhz+b1X0vm 7G1/0jwLi4Sr8J3YRkTjmbjKRDAIsrGAiub2izMYHA== X-Google-Smtp-Source: ALg8bN5iCTQOfg15g/d6jztw8fIoRtjAyotGIYHfgCdUdyjq7Ca8vwcGiiOV79/LKrai7rRy94D//poVOHGxzZ/X0aE= X-Received: by 2002:a2e:29d7:: with SMTP id p84-v6mr25314468ljp.12.1548869477773; Wed, 30 Jan 2019 09:31:17 -0800 (PST) MIME-Version: 1.0 References: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> In-Reply-To: From: Andy Bierman Date: Wed, 30 Jan 2019 09:31:06 -0800 Message-ID: To: Robert Wilton Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000006d13a0580b04718" Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 17:31:25 -0000 --00000000000006d13a0580b04718 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton wrote: > > On 30/01/2019 15:16, Andy Bierman wrote: > > > > On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton wrote: > >> Hi Andy, >> >> Thanks for the comments. >> On 30/01/2019 01:22, Andy Bierman wrote: >> >> Hi, >> >> I originally brought up this issue in July 2015 >> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ >> >> Yes. >> >> The solution I propose is different in the sense that it uses YANG >> instance data to define YANG packages rather than new YANG keywords. I >> believe that this should make it a lower cost solution to define and >> implement. >> >> >> > I think yangvalidator.org has a better solution that does not change YANG > conformance. > > Do you mean that we can just use zip files with the list of modules? > I don't care about the solution details yet. They are 2nd order problems. Conformance means "what modules are required to be implemented together". It is not clear that this problem can be solved. The augment-stmt defines implicit multi-module conformance. I am not convinced that the extra work of defining package conformance is worth it. The issue of what modules does vendor A implement is not a conformance problem. It is just more metadata and YANG Catalog is focused on providing that data. I don't really see how this helps. > > Consider: > - server vendor A, implements some subset of the OpenConfig YANG modules, > each at a particular version, along with some deviations and vendor > augmentations. > - server vendor B, implements the same subset of the OpenConfig YANG > modules, but at different versions, along with some deviations and vendor > augmentations. > - server vendor C, implements a slightly different set of the OpenConfig > YANG modules, but at different versions, along with some deviations and > vendor augmentations. > > As a client, how do I know what module versions to code against, when I > want to work with devices provided by all three vendors? > The vendors publish their implementation details on yangcatalog and you get the info and see what modules are in common. There are only market requirements determining what group of modules has to exist in an implementation. It is not clear to me that formalizing these requirements is something the industry will do effectively. Module tags already provide a way to conceptually group modules together. Seems like every vendor has openconfig, foo-openconfig, and foo-openconfig-deviations so that there are no agreed upon subsets. Even if openconfig had properly documented subsets, would your client even be able to code to it (ignoring add-ons and deviations). I might be wrong, but I think that the OC solution is use git tags, so they > tag sets of modules that are expected to work together and also to provide > a linear release history of their sets of modules. So, if everyone > implements the module versions associated with a git tag then it should > convert a two dimensional problem of module revisions into a linear > problem. The YANG packages draft is aiming to provide a solution to this > problem that doesn't require the use of git, or sending zip files of > modules around. > At the moment, it seems that everyone is doing this in different ways: > - Yumawork customers/servers use zip files of modules for conformance. > Not sure what this means. Actually the server libraries can be loaded and unloaded. Module can be standalone libraries or grouped as bundles. But this seems like an implementation detail, unrelated to conformance. - OpenConfig client/server implementations use git tags, or git refpoints. > - Cisco customers use the contents of directories on github YangModels. > > Finally, this draft doesn't change YANG conformance, it just expresses it > in what is intended to be a simpler way. > It adds another conformance system to maintain. The language only recognizes module to module interfaces, not package to package. That adds more complexity. It doesn't take away any complexity. If there was a standard to load and unload modular functionality at boot-time or run-time, then I could see why there is a need to have a standard to define YANG packages. > Thanks, > Rob > > > Andy > > > Andy > > >> >> I don't think the WG ever agreed on the problem that needs to be solved, >> and that is still the case. >> >> That wasn't quite my impression. I also think that folks were busy >> focusing on other WG activity and didn't necessarily have the time to >> concentrate on this. >> >> My draft was aiming on solving two broad problems: >> >> The main goals of YANG package definitions include, but are not >> restricted to: >> >> o To act as a simplified YANG conformance mechanism. Rather than >> conformance being performed against a set of individual YANG >> module revisions, conformance could also be more simply stated in >> terms of YANG packages, with a set modifications (e.g. additional >> modules, deviations, or features). >> >> o To allow YANG datastore schema to be specified in a more concise >> way rather than having to list all modules and revisions. YANG >> package definitions can be defined in documents that can be >> referenced by a URL rather than requiring explicit lists of >> modules to be shared between client and server. Hence, a YANG >> package must contain sufficient information to allow a client or >> server to precisely construct the schema associated with the >> package. >> >> >> >> >> >> In reality each server has 1 package -- its entire library. >> >> This doesn't apply to all servers. For a long time, as a vendor, we have >> had separate packages that can be independently installed, and which extend >> the management model to cover the new functionality. E.g. BNG >> functionality could be in a separate, independently installable, package on >> top of the base router functionality. >> >> For a Linux server, the manageability interface will depend on what >> applications have been installed. >> >> >> The SEMVER work shows >> that vendors are treating platforms as independent release trains, and >> not really >> developing loadable packages. >> >> This depends on the vendor. The YANG versioning work is trying to find a >> solution that works across the industry. I believe that the versioning >> requirements are different for standards developed modules, vs industry >> developed modules, vs vendor modules. >> >> >> >> I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, >> SEMVER import) >> and the YANG Catalog can solve the module compatibility issues. It is >> more of a documentation >> problem than a standards problem. >> >> Having a standard YANG module that can be used to define packages is >> something this is useful and should be standardized. I believe that this >> is better than each vendor coming up with their own solution for this >> problem. >> >> Thanks, >> Rob >> >> >> >> >> Andy >> >> >> >> >> On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) < >> jason.sterne@nokia.com> wrote: >> >>> Thanks Rob. Please see inline. >>> >>> Jason >>> >>> >>> >>> *From:* Robert Wilton >>> *Sent:* Thursday, January 24, 2019 1:16 PM >>> *To:* Sterne, Jason (Nokia - CA/Ottawa) ; >>> netmod@ietf.org >>> *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages >>> >>> >>> >>> Hi Jason, >>> >>> Thanks for the review and comments. >>> >>> I've put some responses inline ... >>> >>> On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote: >>> >>> Hi guys, >>> >>> >>> >>> I've gotten most of the way through the draft and have some initial >>> comments. I haven't digested the section 10 open issues yet or the examples. >>> >>> >>> >>> Section 5 mentions the following: >>> >>> YANG library is augmented to allow servers to report the packages >>> >>> that they implement and to associate those packages back to >>> >>> particular datastore schema. >>> >>> >>> >>> Does the combination of this draft and rfc7895bis somehow allow the same >>> package to be advertised in 2 different datastores, but with different >>> deviations in each datastore? I'm thinking of a case, for example, where a >>> package is fully supported in the running but the package minus a few >>> modules (or parts of modules) is supported in the operational datastore. >>> There seems to be a 1:1 relationship between package and rfc7895bis schema. >>> >>> So, the intention is no, not directly. >>> >>> My aim here is that would implement package "foo", and >>> would implement package "modified-foo". Package >>> "modified-foo" would import package "foo" and also specify the set of >>> modules that contain the deviations "foo". >>> >>> I didn't want a server to be able to see that I implement package "foo", >>> but then I have all these deviations that change its behavior. Instead, it >>> is really implementing a different package that is based on "foo". >>> >>> >>> >>> >>> >>> The packages draft doesn't include any specific leaf-list for >>> deviations. Section 7.2 mentions that deviations could be expressed by >>> including modules that happen to contain deviations. That seems a bit >>> inconsistent with rfc7895bis that has a specific leaf-list of deviations >>> (and NETCONF hello that specifically explicitly labels deviation modules). >>> >>> I'm conflicted on this one. I don't really like the deviation list in >>> YANG library because I regard it as a duplicate source of information, and >>> then there is a question of which source of data do you trust. E.g. do you >>> process a deviation in a module that is not listed in the deviations module >>> list? >>> >>> *[>>JTS: ] Good point. I suppose this issue applies today already. i.e. >>> what if one of the modules advertised in the is a module of >>> deviations (without having been referenced by another module as a deviation >>> module).* >>> >>> >>> >>> >>> >>> Section 5.1 says the package must be referentially complete. I can see >>> the advantages of that although wondering if that might limit flexibility >>> of partitioning modules into packages. I could imagine use cases for >>> dividing a large set of modules into a few packages that might rev >>> independently but can still all work together (especially if they rev in a >>> bc manner). But maybe that just starts to introduce too much complexity? >>> >>> Yes, having partial packages may be useful. Perhaps just adding a leaf >>> to indicate whether a package is referentially complete could be the answer >>> here. >>> >>> >>> >>> >>> >>> I didn't understand this part of section 5.1. Can you maybe illustrate >>> with an example? >>> >>> The version/revision of a module listed in the package module list >>> >>> supercedes any version/revision of the module listed in a imported >>> >>> package module list. This allows a package to resolve any >>> >>> conflicting implemented module versions/revisions in imported >>> >>> packages. >>> >>> Probably best to see example B.3. in the appendix because it exactly >>> illustrates this point. >>> >>> Basically: >>> 1) Packages must explicitly list all versions of all modules they >>> define/import. >>> 2) If two imported packages define different versions of modules, then >>> the package that is importing them needs a way to define which version to >>> use. >>> 3) A package needs a way to override the version of module specified in >>> an imported package. >>> >>> *[>>JTS: ] Thx. That example does help. I suppose the designer of the >>> package needs to carefully check that the version they select can be >>> successfully used by all the modules in the package. * >>> >>> *I think there is a minor typo in example B.3. The example-3-pkg is >>> importing "* *example-import-1" but I believe you meant "* *example-import-1-pkg" >>> (and some for import-2).* >>> >>> >>> >>> It might be a good idea to add a parent-version to the package module >>> (to allow tracking lineage of packages). >>> >>> Agreed, or maybe allowing a revision history like modules. Not sure >>> which is better here. Packages could get a lot of updates, and a long >>> revision history would not be helpful at all. >>> >>> *[>>JTS: ] I think a minimum of just specifying the direct parent is >>> enough to build the full tree of lineage. We don't need a long history of N >>> revisions.* >>> >>> >>> >>> >>> >>> I like the use of groupings. That allows a manager to use this as a >>> building block to compose a model that has a list of packages. >>> >>> OK. >>> >>> >>> >>> >>> >>> Having a global list of mandatory features (vs having the mandatory >>> feature a per-module list) means inventing the new : >>> format. Should we instead somehow put the mandatory features against each >>> module of the package? >>> >>> Perhaps. My thinking here was to have the list of features high up and >>> very easy to find/parse. >>> >>> >>> >>> >>> >>> The location leaf is a uri but then the description says it must be a >>> url (where the model can be retrieved). I do like that the namespace is >>> separate from the location, but maybe we should make location a url type? >>> >>> Yes, I was thinking that is should be a URL. >>> >>> >>> >>> >>> >>> Do we need a namespace for package names in the model? >>> >>> I had them in an earlier version, but I took them out, because I wasn't >>> sure that they are really useful/required. >>> >>> Defining a format to make package names themselves globally unique might >>> be sufficient. >>> >>> *[>>JTS: ] I'm OK with that. It is similar to how we're finding that it >>> is useful that YANG module names are globally unique (i.e. by naming with >>> ietf-xxxx or companyabc-xxx).* >>> >>> >>> >>> >>> >>> In 7.3 we only reference module-sets and not modules. So the grouping of >>> modules into sets and packages must be the same? >>> >>> Not necessarily. >>> >>> I am trying to reuse the module-set definitions as much as possible (to >>> avoid duplication). One issue here is that module-sets are combined then >>> all the modules must not overlap, which doesn't make the mapping to >>> module-sets quite so clean. >>> >>> >>> >>> >>> >>> A schema can only have a single package. I think that works but it means >>> a server would advertise multiple schemas if it wants to support multiple >>> packages. I'm not sure if there are some downsides to that (it just >>> surprised me). >>> >>> My aim here was: >>> - multiple packages are advertised in yang-library/packages >>> - datastores only report that they "implement" one [top level] package >>> version. [The package itself might import other packages.] >>> >>> If we do package selection, then for a given YANG client session, and >>> the version of YANG library available/reported by that session, it would >>> appear as if the server only implements one top level package for a >>> datastore. Different clients choosing different versions would see >>> slightly different output depending on which package version they had >>> selected to use. >>> >>> Thanks again for the review and the comments! >>> >>> Rob >>> >>> >>> >>> >>> >>> >>> >>> Jason >>> >>> >>> >>> >>> >>> >>> >>> *From:* netmod *On >>> Behalf Of *Robert Wilton >>> *Sent:* Thursday, December 20, 2018 12:45 PM >>> *To:* netmod@ietf.org >>> *Subject:* [netmod] YANG Packages >>> >>> >>> >>> Hi, >>> >>> I've written up an ID for a potential solution for YANG packages using >>> instance data: >>> >>> Abstract >>> >>> >>> >>> This document defines YANG packages, an organizational structure >>> >>> holding a set of related YANG modules, that can be used to simplify >>> >>> the conformance and sharing of YANG schema. It describes how YANG >>> >>> instance data documents are used to define YANG packages, and how the >>> >>> YANG library information published by a server can be augmented with >>> >>> additional packaging related information. >>> >>> https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ >>> >>> Potentially this work may be of use as part of the YANG versioning >>> design team work. In addition, if the WG likes this approach of defining >>> YANG packages, then it might also be useful to bind a schema to a YANG >>> instance data document. >>> >>> Some questions for members of the WG: >>> >>> 1) Do members of the WG agree that YANG packages is something that needs >>> to be solved? >>> >>> 2) Is the approach in this draft of defining these as instance data >>> documents a good starting point? >>> >>> 3) This approach augments YANG library-bis, reusing module-sets, but not >>> replacing the way that modules are reported in YANG library-bis. Is this >>> the right approach? This approach tries to allow module-sets to be reused >>> for both schema and packages, but the YANG library-bis rules for combining >>> module-sets (i.e. no conflicts) may make this harder to really reuse the >>> module-sets for both purposes. >>> >>> Of course, any other comments or feedback is welcome and appreciated. >>> >>> Thanks, >>> Rob >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> --00000000000006d13a0580b04718 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 30, 2019 at 8:02 AM Rober= t Wilton <rwilton@cisco.com>= wrote:
=20 =20 =20


On 30/01/201= 9 15:16, Andy Bierman wrote:
=20


On Wed, Jan 30, 2019 at 4:1= 9 AM Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,

Thanks for the comments.

On 30/01/2019 01:22, Andy Bierman wrote:
Hi,

I originally brought up this issue in July 2015

Yes.

The solution I propose is different in the sense that it uses YANG instance data to define YANG packages rather than new YANG keywords.=C2=A0=C2=A0 I believe that t= his should make it a lower cost solution to define and implement.



I think yangvalidator.org has a better solution that does not change YANG conformance.

Do you mean that we can just use zip files with the list of modules?


I don't care a= bout the solution details yet. They are 2nd order problems.

<= /div>
Conformance means "what modules are required to be implement= ed together".
It is not clear that this problem can be solve= d.=C2=A0 The augment-stmt defines implicit
multi-module conforman= ce.=C2=A0 I am not convinced that the extra work of defining package confor= mance
is worth it.

The issue of what mod= ules does vendor A implement is not a conformance problem.
It is = just more metadata and YANG Catalog is focused on providing that data.

I don't really see how this helps.

Consider:
- server vendor A, implements some subset of the OpenConfig YANG modules, each at a particular version, along with some deviations and vendor augmentations.
- server vendor B, implements the same subset of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations.
- server vendor C, implements a slightly different set of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations.

As a client, how do I know what module versions to code against, when I want to work with devices provided by all three vendors?



The vendors publish the= ir implementation details on yangcatalog and you get the info
and= see what modules are in common.

There are only ma= rket requirements determining what group of modules has to exist
= in an implementation.=C2=A0 It is not clear to me that formalizing these re= quirements
is something the industry will do effectively.=C2=A0 M= odule tags already provide a way
to conceptually group modules to= gether.

Seems like every vendor has openconfig, fo= o-openconfig, and foo-openconfig-deviations
so that there are no = agreed upon subsets. Even if openconfig had properly documented
s= ubsets, would your client even be able to code to it (ignoring add-ons and = deviations).

I might be wrong, but I think that the OC solution is use git tags, so they tag sets of modules that are expected to work together and also to provide a linear release history of their sets of modules.=C2=A0 So, if everyone implements the module versions associated with a git tag then it should convert a two dimensional problem of module revisions into a linear problem.=C2=A0 The YANG packages draft is aiming to provide a solution to this problem that doesn't require the use of git, or sending zip files of modules around.


At the moment, it seems that everyone is doing this in different ways:
=C2=A0- Yumawork customers/servers use zip files of modules for conformance.


Not sure w= hat this means.
Actually the server libraries can be loaded and u= nloaded.
Module can be standalone libraries or grouped as bundles= .
But this seems like an implementation detail, unrelated to conf= ormance.


=C2=A0- OpenConfig client/server implementations use git tags, or git refpoints.
=C2=A0- Cisco customers use the contents of directories on github YangModels.

Finally, this draft doesn't change YANG conformance, it just expresses it in what is intended to be a simpler way.


It adds another conformance system to mainta= in.
The language only recognizes module to module interfaces, not= package to package.
That adds more complexity. It doesn't ta= ke away any complexity.

If there was a standard to= load and unload modular functionality at boot-time or run-time,
= then I could see why there is a need to have a standard to define YANG pack= ages.
=C2=A0

Thanks,
Rob



Andy
=C2=A0=



Andy
=C2=A0


I don't think the WG ever agreed on the proble= m that needs to be solved,
and that is still the case.

That wasn't quite my impression.=C2=A0 I also think th= at folks were busy focusing on other WG activity and didn'= t necessarily have the time to concentrate on this.

My draft was aiming on solving two broad problems:

   The main goals of=
 YANG package definitions include, but are not
   restricted to:

   o  To act as a simplified YANG conformance mechanism.  Rather than
      conformance being performed against a set of individual YANG
      module revisions, conformance could also be more simply stated in
      terms of YANG packages, with a set modifications (e.g. additional
      modules, deviations, or features).

   o  To allow YANG datastore schema to be specified in a more concise
      way rather than having to list all modules and revisions.  YANG
      package definitions can be defined in documents that can be
      referenced by a URL rather than requiring explicit lists of
      modules to be shared between client and server.  Hence, a YANG
      package must contain sufficient information to allow a client or
      server to precisely construct the schema associated with the
      package.


=C2=A0

In reality each server has 1 package -- its entire library.

This doesn't apply to all servers.=C2=A0 For a long ti= me, as a vendor, we have had separate packages that can be independently installed, and which extend the management model to cover the new functionality.=C2=A0 E.g. BNG functionality could be in a separate, independently installable, package on top of the base router functionality.

For a Linux server, the manageability interface will depend on what applications have been installed.


The SEMVER work shows
that vendors are treating platforms as independent release trains, and not really
developing loadable packages.

This depends on the vendor.=C2=A0 The YANG versioning work is trying to find a solution that works across the industry.=C2=A0 I believe that the versioning requirements are different for standards developed modules, vs industry developed modules, vs vendor modules.



I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, SEMVER import)
and=C2=A0 the YANG Catalog can solve the module compatibility issues. It is more of a documentation
problem than a standards problem.

Having a standard YANG module that can be used to define packages is something this is useful and should be standardized.=C2=A0 I believe that this is better than each vendor coming up with their own solution for this problem.

Thanks,
Rob




Andy




On Tue, Jan 29, 201= 9 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.co= m> wrote:

Thanks Rob. Please see inline.

Jason

=C2=A0

From: Robert Wilton <rwilton@cisco.com>
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; netmod@ietf.org
Subject: Re: initial comments on draft-rwilton-netmod-yang-packages

=C2=A0

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi guys,

=C2=A0

I've gotten most of the way through the draft and have some initial comments. I haven't digested the section 10 open issues yet or the examples.

=C2=A0

Section 5 mentions the following:

=C2=A0=C2=A0 YANG library is augmented to allow servers to report the packages

=C2=A0=C2=A0 that they implement and to associate those packages back to

=C2=A0=C2=A0 particular datastore schema.

=C2=A0

Does the combination of this draft and rfc7895bis somehow allow the same package to be advertised in 2 different datastores, but with different deviations in each datastore? I'm thinking of a case, for example, where a package is fully supported in the running but the package minus a few modules (or parts of modules) is supported in the operational datastore. There seems to be a 1:1 relationship between package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that <running> would implement package "foo", and <operational> would implement package "modified-foo".=C2=A0 Package "m= odified-foo" would import package "foo" and also s= pecify the set of modules that contain the deviations "foo".

I didn't want a server to be able to see that I implement package "foo", but t= hen I have all these deviations that change its behavior.=C2=A0 Instead, it is really implementing a different package that is based on "foo".

=C2=A0

=C2=A0

The packages draft doesn't include any specific leaf-list for deviations. Section 7.2 mentions that deviations could be expressed by including modules that happen to contain deviations. That seems a bit inconsistent with rfc7895bis that has a specific leaf-list of deviations (and NETCONF hello that specifically explicitly labels deviation modules).

I'm conflicted on this one.=C2=A0 I don= 9;t really like the deviation list in YANG library because I regard it as a duplicate source of information, and then there is a question of which source of data do you trust.=C2=A0 E.g. d= o you process a deviation in a module that is not listed in the deviations module list?

[>&g= t;JTS: ] Good point. I suppose this issue applies today already. i.e. what if one of the modules advertised in the <hello> is a module of deviations (without having been referenced by another module as a deviation module).

=C2=A0

=C2=A0

Section 5.1 says the package must be referentially complete. I can see the advantages of that although wondering if that might limit flexibility of partitioning modules into packages. I could imagine use cases for dividing a large set of modules into a few packages that might rev independently but can still all work together (especially if they rev in a bc manner). But maybe that just starts to introduce too much complexity?

Yes, having partial packages may be useful.=C2=A0 Perhaps just adding a leaf to indicate whether a package is referentially complete could be the answer here.

=C2=A0

=C2=A0

I didn't understand this part of section 5.1. Can you maybe illustrate with an example?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The version/revision of a module listed in the package module list

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 supercedes any version/revision of the module listed in a imported

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 package module list.=C2=A0 This allows a package to resolve any

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 conflicting implemented module versions/revisions in imported

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 packages.

Probably best to see example B.3. in the appendix because it exactly illustrates this point.

Basically:
1) Packages must explicitly list all versions of all modules they define/import.
2) If two imported packages define different versions of modules, then the package that is importing them needs a way to define which version to use.
3) A package needs a way to override the version of module specified in an imported package.

[>&g= t;JTS: ] Thx. That example does help. I suppose the designer of the package needs to carefully check that the version they select can be successfully used by all the modules in the package.

I think there is a minor typo in example B.3.=C2=A0 The example-3-pkg is importing= " example-= import-1" but I believe you meant "= example-= import-1-pkg" (and some for import-2).

=C2=A0

It might be a good idea to add a parent-version to the package module (to allow tracking lineage of packages).

Agreed, or maybe allowing a revision history like modules.=C2=A0 Not sure which is better here.=C2=A0 Packages could get a lot of updates, and a long revision history would not be helpful at all.

[>&g= t;JTS: ] I think a minimum of just specifying the direct parent is enough to build the full tree of lineage. We don't need a long history of N revisions.

=C2=A0

=C2=A0

I like the use of groupings. That allows a manager to use this as a building block to compose a model that has a list of packages.

OK.

=C2=A0

=C2=A0

Hav= ing a global list of mandatory features (vs having the mandatory feature a per-module list) means inventing the new <module-name>:<feature> format. Should we instead somehow put the mandatory features against each module of the package?

Perhaps.=C2=A0 My thinking here was to have th= e list of features high up and very easy to find/parse.

=C2=A0

=C2= =A0

The location leaf is a uri but then the description says it must be a url (where the model can be retrieved). I do like that the namespace is separate from the location, but maybe we should make location a url type?

Yes, I was thinking that is should be a URL.

=C2=A0

=C2= =A0

Do we need a namespace for package names in the model?

I had them in an earlier version, but I took them out, because I wasn't sure that they are really useful/required.

Defining a format to make package names themselves globally unique might be sufficient.

[>&g= t;JTS: ] I'm OK with that. It is similar to how we're finding that it is useful that YANG module names are globally unique (i.e. by naming with ietf-xxxx or companyabc-xxx).

=C2=A0

=C2= =A0

In 7.3 we only reference module-sets and not modules. So the grouping of modules into sets and packages must be the same?

Not necessarily.

I am trying to reuse the module-set definitions as much as possible (to avoid duplication).=C2=A0 One issue here is that module-sets are combined then all the modules must not overlap, which doesn't mak= e the mapping to module-sets quite so clean.

=C2=A0

=C2= =A0

A schema can only have a single package. I think that works but it means a server would advertise multiple schemas if it wants to support multiple packages. I'm not sure if there are some downsides to that (it just surprised me).

My aim here was:
=C2=A0- multiple packages are advertised in yang-library/packages
=C2=A0- datastores only report that they "implement" one [top level] package version.=C2=A0 [The package itself might import other packages.]

If we do package selection, then for a given YANG client session, and the version of YANG library available/reported by that session, it would appear as if the server only implements one top level package for a datastore.=C2=A0 Different clients choosing different versions would see slightly different output depending on which package version they had selected to use.

Thanks again for the review and the comments!

Rob

=C2=A0

=C2=A0

=C2= =A0

Jas= on

=C2= =A0

=C2=A0

=C2=A0

From: netmod <netmod-bounces@ietf.org> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: netmod@ietf.org
Subject: [netmod] YANG Packages

=C2=A0

Hi,

I've written up an ID for a potential solution for YANG packages using instance data:

Abstract
=
=C2=A0
=
=C2=A0=C2=A0 This document defines YANG packages, an organizational structu=
re
=
=C2=A0=C2=A0 holding a set of related YANG modules, that can be used to sim=
plify
=
=C2=A0=C2=A0 the conformance and sharing of YANG schema.=C2=A0 It describes=
 how YANG
=
=C2=A0=C2=A0 instance data documents are used to define YANG packages, and =
how the
=
=C2=A0=C2=A0 YANG library information published by a server can be augmente=
d with
=
=C2=A0=C2=A0 additional packaging related information.

https://datatracke= r.ietf.org/doc/draft-rwilton-netmod-yang-packages/

Potentially this work may be of use as part of the YANG versioning design team work.=C2=A0 In addition, if the WG likes th= is approach of defining YANG packages, then it might also be useful to bind a schema to a YANG instance data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs to be solved?

2) Is the approach in this draft of defining these as instance data documents a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not replacing the way that modules are reported in YANG library-bis.=C2=A0 Is this the right approach?=C2=A0 This approach tri= es to allow module-sets to be reused for both schema and packages, but the YANG library-bis rules for combining module-sets (i.e. no conflicts) may make this harder to really reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.

Thanks,
Rob

_______________________________________________
netmod mailing list
ne= tmod@ietf.org
https://www.ietf.org/mailman/listinf= o/netmod
--00000000000006d13a0580b04718-- From nobody Wed Jan 30 10:04:10 2019 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 545F9131302 for ; Wed, 30 Jan 2019 10:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.042 X-Spam-Level: X-Spam-Status: No, score=-19.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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_KAM_HTML_FONT_INVALID=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 BB2Oy-0Ci734 for ; Wed, 30 Jan 2019 10:04:04 -0800 (PST) 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 127C6131300 for ; Wed, 30 Jan 2019 10:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=87926; q=dns/txt; s=iport; t=1548871444; x=1550081044; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=I4xv5ZGQjHWLn1myS4tyEvJ2IFuJBlCcSz/onquX57s=; b=gjDuhFvYo0TFFvejZhbaWP3/1mRytsp3DiOBLurzufpyRRa+IAzc/Ele CH18p9AEQ7kmdVGMy+3yRbO53k/TDJoyZ5Ja+YLoYVQ1Oz+xnN4WMqQKQ InzDIAQ9sqIL7VWDhGTCDTOkWTqr3Q5dUq7UNaXPiVfiayNeOCYE5k/Pq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAACV5lFc/xbLJq0aAUoaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFUAgEBAQELAQGBDIFdUSASJ4QDiHmNIYMIlnwEDRgBCoQ?= =?us-ascii?q?DRgKDKTcGDQEDAQECAQECbRwMhUoBAQEBAgEBARgBCEsEBwULCQIRBAEBASA?= =?us-ascii?q?BBgMCAicfCQgGDQYCAQEXgwcBgXkID45FggWbYYEvH4QjQUCEc4xXgUA/gTi?= =?us-ascii?q?BbX6DHgEBAwGBNxBMglOCVwKJTBIgHgIDgUuENIZhintcCYcug16HIAYYgWt?= =?us-ascii?q?RhGiDFYd6j0WFBYcYgVwiKIEuMxoIGxU7gmwJixSFPz8DMI07gkwBAQ?= X-IronPort-AV: E=Sophos;i="5.56,541,1539648000"; d="scan'208,217";a="9768181" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2019 18:04:00 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x0UI40Hu004750; Wed, 30 Jan 2019 18:04:00 GMT To: Andy Bierman Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" References: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> From: Robert Wilton Message-ID: <914c99e5-ca38-9e39-32dd-1b0c3ed3294e@cisco.com> Date: Wed, 30 Jan 2019 18:04:00 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------683915C58BEA266375368C4B" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 18:04:09 -0000 This is a multi-part message in MIME format. --------------683915C58BEA266375368C4B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 30/01/2019 17:31, Andy Bierman wrote: > > > On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton > wrote: > > > On 30/01/2019 15:16, Andy Bierman wrote: >> >> >> On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton > > wrote: >> >> Hi Andy, >> >> Thanks for the comments. >> >> On 30/01/2019 01:22, Andy Bierman wrote: >>> Hi, >>> >>> I originally brought up this issue in July 2015 >>> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ >> >> Yes. >> >> The solution I propose is different in the sense that it uses >> YANG instance data to define YANG packages rather than new >> YANG keywords.   I believe that this should make it a lower >> cost solution to define and implement. >> >> >> >> I think yangvalidator.org has a better >> solution that does not change YANG conformance. > > Do you mean that we can just use zip files with the list of modules? > > > I don't care about the solution details yet. They are 2nd order problems. > > Conformance means "what modules are required to be implemented together". > It is not clear that this problem can be solved.  The augment-stmt > defines implicit > multi-module conformance.  I am not convinced that the extra work of > defining package conformance > is worth it. So, I'm not proposing backing any sort of package conformance into the language at all.  A package is just metadata that defines that a set of modules, at particular revisions/versions, work together and can represent part of a YANG schema. This is equivalent to  - how a zip file of YANG modules provided to yangvalidator would work.  - getting the contents of YANG library from a server (but a YANG packages soln can also work offline)  - fetching the modules from YANG catalog (if they have been labelled appropriately), although I'm not convinced that this universally works today. But in terms of the usability of YANG, I don't think that doing conformance only at the module level is really sufficient. Clients need to be coding against sets of modules at particular versions that are known to work together, and known that multiple server vendors will implement. A pick and mix appropriate to module revisions doesn't seem to help anyone. > > The issue of what modules does vendor A implement is not a conformance > problem. > It is just more metadata and YANG Catalog is focused on providing that > data. Does YANG catalog indicate the set of IETF modules that I would need to implement L2VPN services on a device? Module tags could be used to do this (another packaging solution), but this would cause a proliferation of tags when it comes to versioning, since I don't think that you can cleanly bake semver into module tags. > > I don't really see how this helps. > > Consider: > - server vendor A, implements some subset of the OpenConfig YANG > modules, each at a particular version, along with some deviations > and vendor augmentations. > - server vendor B, implements the same subset of the OpenConfig > YANG modules, but at different versions, along with some > deviations and vendor augmentations. > - server vendor C, implements a slightly different set of the > OpenConfig YANG modules, but at different versions, along with > some deviations and vendor augmentations. > > As a client, how do I know what module versions to code against, > when I want to work with devices provided by all three vendors? > > > > The vendors publish their implementation details on yangcatalog and > you get the info > and see what modules are in common. > > There are only market requirements determining what group of modules > has to exist > in an implementation.  It is not clear to me that formalizing these > requirements > is something the industry will do effectively.  Module tags already > provide a way > to conceptually group modules together. > > Seems like every vendor has openconfig, foo-openconfig, and > foo-openconfig-deviations > so that there are no agreed upon subsets. Even if openconfig had > properly documented > subsets, would your client even be able to code to it (ignoring > add-ons and deviations). I think that answer will converge on yes, I don't know how long it will take.  It would probably be better if at the time that protocol specifications are written, that the authors of the specifications also write the YANG modules to manage them at the same time. > > I might be wrong, but I think that the OC solution is use git > tags, so they tag sets of modules that are expected to work > together and also to provide a linear release history of their > sets of modules.  So, if everyone implements the module versions > associated with a git tag then it should convert a two dimensional > problem of module revisions into a linear problem.  The YANG > packages draft is aiming to provide a solution to this problem > that doesn't require the use of git, or sending zip files of > modules around. > > > At the moment, it seems that everyone is doing this in different ways: >  - Yumawork customers/servers use zip files of modules for > conformance. > > > Not sure what this means. > Actually the server libraries can be loaded and unloaded. > Module can be standalone libraries or grouped as bundles. > But this seems like an implementation detail, unrelated to conformance. > > >  - OpenConfig client/server implementations use git tags, or git > refpoints. >  - Cisco customers use the contents of directories on github > YangModels. > > Finally, this draft doesn't change YANG conformance, it just > expresses it in what is intended to be a simpler way. > > > It adds another conformance system to maintain. > The language only recognizes module to module interfaces, not package > to package. I propose that at the language level conformance is at the module level (modulo import-by-version). > That adds more complexity. It doesn't take away any complexity. It is meant to be a simpler way of packaging up, and trying to control and manage the complexity that already exists today. E.g. I could give a YANG compiler the name, version, and location of a package and tell it to build the entire schema associated with that package. In a somewhat similar way, when I write code, my build file specifies which libraries I depend on, and their versions, but I can leave it to the build tool to determine what those libraries themselves depend on and recursively pull in all the dependencies. > > If there was a standard to load and unload modular functionality at > boot-time or run-time, > then I could see why there is a need to have a standard to define YANG > packages. I agree that this is another example of where they could be useful. Thanks, Rob > > Thanks, > Rob > > > > Andy > >> >> >> Andy >> >>> >>> I don't think the WG ever agreed on the problem that needs >>> to be solved, >>> and that is still the case. >> >> That wasn't quite my impression.  I also think that folks >> were busy focusing on other WG activity and didn't >> necessarily have the time to concentrate on this. >> >> My draft was aiming on solving two broad problems: >> >> The main goals of YANG package definitions include, but are not >> restricted to: >> >> o To act as a simplified YANG conformance mechanism. Rather than >> conformance being performed against a set of individual YANG >> module revisions, conformance could also be more simply stated in >> terms of YANG packages, with a set modifications (e.g. additional >> modules, deviations, or features). >> >> o To allow YANG datastore schema to be specified in a more concise >> way rather than having to list all modules and revisions. YANG >> package definitions can be defined in documents that can be >> referenced by a URL rather than requiring explicit lists of >> modules to be shared between client and server. Hence, a YANG >> package must contain sufficient information to allow a client or >> server to precisely construct the schema associated with the >> package. >> >> >> >>> >>> In reality each server has 1 package -- its entire library. >> >> This doesn't apply to all servers.  For a long time, as a >> vendor, we have had separate packages that can be >> independently installed, and which extend the management >> model to cover the new functionality.  E.g. BNG functionality >> could be in a separate, independently installable, package on >> top of the base router functionality. >> >> For a Linux server, the manageability interface will depend >> on what applications have been installed. >> >> >>> The SEMVER work shows >>> that vendors are treating platforms as independent release >>> trains, and not really >>> developing loadable packages. >> >> This depends on the vendor.  The YANG versioning work is >> trying to find a solution that works across the industry.  I >> believe that the versioning requirements are different for >> standards developed modules, vs industry developed modules, >> vs vendor modules. >> >> >>> >>> I think YANG 1.2 improvements for conformance (e.g., >>> YANG-redirects, SEMVER import) >>> and  the YANG Catalog can solve the module compatibility >>> issues. It is more of a documentation >>> problem than a standards problem. >> >> Having a standard YANG module that can be used to define >> packages is something this is useful and should be >> standardized.  I believe that this is better than each vendor >> coming up with their own solution for this problem. >> >> Thanks, >> Rob >> >> >>> >>> >>> Andy >>> >>> >>> >>> >>> On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - >>> CA/Ottawa) >> > wrote: >>> >>> Thanks Rob. Please see inline. >>> >>> Jason >>> >>> *From:*Robert Wilton >> > >>> *Sent:* Thursday, January 24, 2019 1:16 PM >>> *To:* Sterne, Jason (Nokia - CA/Ottawa) >>> >> >; netmod@ietf.org >>> >>> *Subject:* Re: initial comments on >>> draft-rwilton-netmod-yang-packages >>> >>> Hi Jason, >>> >>> Thanks for the review and comments. >>> >>> I've put some responses inline ... >>> >>> On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) >>> wrote: >>> >>> Hi guys, >>> >>> I've gotten most of the way through the draft and >>> have some initial comments. I haven't digested the >>> section 10 open issues yet or the examples. >>> >>> Section 5 mentions the following: >>> >>> YANG library is augmented to allow servers to report >>> the packages >>> >>> that they implement and to associate those packages >>> back to >>> >>> particular datastore schema. >>> >>> Does the combination of this draft and rfc7895bis >>> somehow allow the same package to be advertised in 2 >>> different datastores, but with different deviations >>> in each datastore? I'm thinking of a case, for >>> example, where a package is fully supported in the >>> running but the package minus a few modules (or >>> parts of modules) is supported in the operational >>> datastore. There seems to be a 1:1 relationship >>> between package and rfc7895bis schema. >>> >>> So, the intention is no, not directly. >>> >>> My aim here is that would implement package >>> "foo", and would implement package >>> "modified-foo". Package "modified-foo" would import >>> package "foo" and also specify the set of modules that >>> contain the deviations "foo". >>> >>> I didn't want a server to be able to see that I >>> implement package "foo", but then I have all these >>> deviations that change its behavior.  Instead, it is >>> really implementing a different package that is based on >>> "foo". >>> >>> The packages draft doesn't include any specific >>> leaf-list for deviations. Section 7.2 mentions that >>> deviations could be expressed by including modules >>> that happen to contain deviations. That seems a bit >>> inconsistent with rfc7895bis that has a specific >>> leaf-list of deviations (and NETCONF hello that >>> specifically explicitly labels deviation modules). >>> >>> I'm conflicted on this one.  I don't really like the >>> deviation list in YANG library because I regard it as a >>> duplicate source of information, and then there is a >>> question of which source of data do you trust.  E.g. do >>> you process a deviation in a module that is not listed >>> in the deviations module list? >>> >>> */[>>JTS: ] Good point. I suppose this issue applies >>> today already. i.e. what if one of the modules >>> advertised in the is a module of deviations >>> (without having been referenced by another module as a >>> deviation module)./* >>> >>> Section 5.1 says the package must be referentially >>> complete. I can see the advantages of that although >>> wondering if that might limit flexibility of >>> partitioning modules into packages. I could imagine >>> use cases for dividing a large set of modules into a >>> few packages that might rev independently but can >>> still all work together (especially if they rev in a >>> bc manner). But maybe that just starts to introduce >>> too much complexity? >>> >>> Yes, having partial packages may be useful.  Perhaps >>> just adding a leaf to indicate whether a package is >>> referentially complete could be the answer here. >>> >>> I didn't understand this part of section 5.1. Can >>> you maybe illustrate with an example? >>> >>> The version/revision of a module listed in the >>> package module list >>> >>> supercedes any version/revision of the module listed >>> in a imported >>> >>> package module list.  This allows a package to >>> resolve any >>> >>> conflicting implemented module versions/revisions in >>> imported >>> >>> packages. >>> >>> Probably best to see example B.3. in the appendix >>> because it exactly illustrates this point. >>> >>> Basically: >>> 1) Packages must explicitly list all versions of all >>> modules they define/import. >>> 2) If two imported packages define different versions of >>> modules, then the package that is importing them needs a >>> way to define which version to use. >>> 3) A package needs a way to override the version of >>> module specified in an imported package. >>> >>> */[>>JTS: ] Thx. That example does help. I suppose the >>> designer of the package needs to carefully check that >>> the version they select can be successfully used by all >>> the modules in the package. /* >>> >>> */I think there is a minor typo in example B.3.  The >>> example-3-pkg is importing "/* */example-import-1" but I >>> believe you meant "/* */example-import-1-pkg" (and some >>> for import-2)./* >>> >>> It might be a good idea to add a parent-version to >>> the package module (to allow tracking lineage of >>> packages). >>> >>> Agreed, or maybe allowing a revision history like >>> modules. Not sure which is better here. Packages could >>> get a lot of updates, and a long revision history would >>> not be helpful at all. >>> >>> */[>>JTS: ] I think a minimum of just specifying the >>> direct parent is enough to build the full tree of >>> lineage. We don't need a long history of N revisions./* >>> >>> I like the use of groupings. That allows a manager >>> to use this as a building block to compose a model >>> that has a list of packages. >>> >>> OK. >>> >>> Having a global list of mandatory features (vs >>> having the mandatory feature a per-module list) >>> means inventing the new : >>> format. Should we instead somehow put the mandatory >>> features against each module of the package? >>> >>> Perhaps.  My thinking here was to have the list of >>> features high up and very easy to find/parse. >>> >>> The location leaf is a uri but then the description >>> says it must be a url (where the model can be >>> retrieved). I do like that the namespace is separate >>> from the location, but maybe we should make location >>> a url type? >>> >>> Yes, I was thinking that is should be a URL. >>> >>> Do we need a namespace for package names in the model? >>> >>> I had them in an earlier version, but I took them out, >>> because I wasn't sure that they are really useful/required. >>> >>> Defining a format to make package names themselves >>> globally unique might be sufficient. >>> >>> */[>>JTS: ] I'm OK with that. It is similar to how we're >>> finding that it is useful that YANG module names are >>> globally unique (i.e. by naming with ietf-xxxx or >>> companyabc-xxx)./* >>> >>> In 7.3 we only reference module-sets and not >>> modules. So the grouping of modules into sets and >>> packages must be the same? >>> >>> Not necessarily. >>> >>> I am trying to reuse the module-set definitions as much >>> as possible (to avoid duplication). One issue here is >>> that module-sets are combined then all the modules must >>> not overlap, which doesn't make the mapping to >>> module-sets quite so clean. >>> >>> A schema can only have a single package. I think >>> that works but it means a server would advertise >>> multiple schemas if it wants to support multiple >>> packages. I'm not sure if there are some downsides >>> to that (it just surprised me). >>> >>> My aim here was: >>>  - multiple packages are advertised in yang-library/packages >>>  - datastores only report that they "implement" one [top >>> level] package version.  [The package itself might >>> import other packages.] >>> >>> If we do package selection, then for a given YANG client >>> session, and the version of YANG library >>> available/reported by that session, it would appear as >>> if the server only implements one top level package for >>> a datastore. Different clients choosing different >>> versions would see slightly different output depending >>> on which package version they had selected to use. >>> >>> Thanks again for the review and the comments! >>> >>> Rob >>> >>> Jason >>> >>> *From:*netmod >>> *On Behalf Of >>> *Robert Wilton >>> *Sent:* Thursday, December 20, 2018 12:45 PM >>> *To:* netmod@ietf.org >>> *Subject:* [netmod] YANG Packages >>> >>> Hi, >>> >>> I've written up an ID for a potential solution for >>> YANG packages using instance data: >>> >>> Abstract >>> >>>    This document defines YANG packages, an >>> organizational structure >>> >>>    holding a set of related YANG modules, that can >>> be used to simplify >>> >>>    the conformance and sharing of YANG schema.  It >>> describes how YANG >>> >>>    instance data documents are used to define YANG >>> packages, and how the >>> >>>    YANG library information published by a server >>> can be augmented with >>> >>>    additional packaging related information. >>> >>> https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ >>> >>> Potentially this work may be of use as part of the >>> YANG versioning design team work. In addition, if >>> the WG likes this approach of defining YANG >>> packages, then it might also be useful to bind a >>> schema to a YANG instance data document. >>> >>> Some questions for members of the WG: >>> >>> 1) Do members of the WG agree that YANG packages is >>> something that needs to be solved? >>> >>> 2) Is the approach in this draft of defining these >>> as instance data documents a good starting point? >>> >>> 3) This approach augments YANG library-bis, reusing >>> module-sets, but not replacing the way that modules >>> are reported in YANG library-bis. Is this the right >>> approach? This approach tries to allow module-sets >>> to be reused for both schema and packages, but the >>> YANG library-bis rules for combining module-sets >>> (i.e. no conflicts) may make this harder to really >>> reuse the module-sets for both purposes. >>> >>> Of course, any other comments or feedback is welcome >>> and appreciated. >>> >>> Thanks, >>> Rob >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> --------------683915C58BEA266375368C4B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 30/01/2019 17:31, Andy Bierman wrote:


On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton <rwilton@cisco.com> wrote:


On 30/01/2019 15:16, Andy Bierman wrote:


On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,

Thanks for the comments.

On 30/01/2019 01:22, Andy Bierman wrote:
Hi,

I originally brought up this issue in July 2015

Yes.

The solution I propose is different in the sense that it uses YANG instance data to define YANG packages rather than new YANG keywords.   I believe that this should make it a lower cost solution to define and implement.



I think yangvalidator.org has a better solution that does not change YANG conformance.

Do you mean that we can just use zip files with the list of modules?


I don't care about the solution details yet. They are 2nd order problems.

Conformance means "what modules are required to be implemented together".
It is not clear that this problem can be solved.  The augment-stmt defines implicit
multi-module conformance.  I am not convinced that the extra work of defining package conformance
is worth it.

So, I'm not proposing backing any sort of package conformance into the language at all.  A package is just metadata that defines that a set of modules, at particular revisions/versions, work together and can represent part of a YANG schema.

This is equivalent to
 - how a zip file of YANG modules provided to yangvalidator would work.
 - getting the contents of YANG library from a server (but a YANG packages soln can also work offline)
 - fetching the modules from YANG catalog (if they have been labelled appropriately), although I'm not convinced that this universally works today.

But in terms of the usability of YANG, I don't think that doing conformance only at the module level is really sufficient.  Clients need to be coding against sets of modules at particular versions that are known to work together, and known that multiple server vendors will implement.

A pick and mix appropriate to module revisions doesn't seem to help anyone.



The issue of what modules does vendor A implement is not a conformance problem.
It is just more metadata and YANG Catalog is focused on providing that data.

Does YANG catalog indicate the set of IETF modules that I would need to implement L2VPN services on a device?

Module tags could be used to do this (another packaging solution), but this would cause a proliferation of tags when it comes to versioning, since I don't think that you can cleanly bake semver into module tags.



I don't really see how this helps.

Consider:
- server vendor A, implements some subset of the OpenConfig YANG modules, each at a particular version, along with some deviations and vendor augmentations.
- server vendor B, implements the same subset of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations.
- server vendor C, implements a slightly different set of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations.

As a client, how do I know what module versions to code against, when I want to work with devices provided by all three vendors?



The vendors publish their implementation details on yangcatalog and you get the info
and see what modules are in common.

There are only market requirements determining what group of modules has to exist
in an implementation.  It is not clear to me that formalizing these requirements
is something the industry will do effectively.  Module tags already provide a way
to conceptually group modules together.

Seems like every vendor has openconfig, foo-openconfig, and foo-openconfig-deviations
so that there are no agreed upon subsets. Even if openconfig had properly documented
subsets, would your client even be able to code to it (ignoring add-ons and deviations).

I think that answer will converge on yes, I don't know how long it will take.  It would probably be better if at the time that protocol specifications are written, that the authors of the specifications also write the YANG modules to manage them at the same time.


I might be wrong, but I think that the OC solution is use git tags, so they tag sets of modules that are expected to work together and also to provide a linear release history of their sets of modules.  So, if everyone implements the module versions associated with a git tag then it should convert a two dimensional problem of module revisions into a linear problem.  The YANG packages draft is aiming to provide a solution to this problem that doesn't require the use of git, or sending zip files of modules around.


At the moment, it seems that everyone is doing this in different ways:
 - Yumawork customers/servers use zip files of modules for conformance.


Not sure what this means.
Actually the server libraries can be loaded and unloaded.
Module can be standalone libraries or grouped as bundles.
But this seems like an implementation detail, unrelated to conformance.


 - OpenConfig client/server implementations use git tags, or git refpoints.
 - Cisco customers use the contents of directories on github YangModels.

Finally, this draft doesn't change YANG conformance, it just expresses it in what is intended to be a simpler way.


It adds another conformance system to maintain.
The language only recognizes module to module interfaces, not package to package.

I propose that at the language level conformance is at the module level (modulo import-by-version).


That adds more complexity. It doesn't take away any complexity.

It is meant to be a simpler way of packaging up, and trying to control and manage the complexity that already exists today.

E.g. I could give a YANG compiler the name, version, and location of a package and tell it to build the entire schema associated with that package. 

In a somewhat similar way, when I write code, my build file specifies which libraries I depend on, and their versions, but I can leave it to the build tool to determine what those libraries themselves depend on and recursively pull in all the dependencies.



If there was a standard to load and unload modular functionality at boot-time or run-time,
then I could see why there is a need to have a standard to define YANG packages.

I agree that this is another example of where they could be useful.

Thanks,
Rob


 

Thanks,
Rob



Andy
 



Andy
 


I don't think the WG ever agreed on the problem that needs to be solved,
and that is still the case.

That wasn't quite my impression.  I also think that folks were busy focusing on other WG activity and didn't necessarily have the time to concentrate on this.

My draft was aiming on solving two broad problems:

   The main goals of YANG package definitions include, but are not
   restricted to:

   o  To act as a simplified YANG conformance mechanism.  Rather than
      conformance being performed against a set of individual YANG
      module revisions, conformance could also be more simply stated in
      terms of YANG packages, with a set modifications (e.g. additional
      modules, deviations, or features).

   o  To allow YANG datastore schema to be specified in a more concise
      way rather than having to list all modules and revisions.  YANG
      package definitions can be defined in documents that can be
      referenced by a URL rather than requiring explicit lists of
      modules to be shared between client and server.  Hence, a YANG
      package must contain sufficient information to allow a client or
      server to precisely construct the schema associated with the
      package.


 

In reality each server has 1 package -- its entire library.

This doesn't apply to all servers.  For a long time, as a vendor, we have had separate packages that can be independently installed, and which extend the management model to cover the new functionality.  E.g. BNG functionality could be in a separate, independently installable, package on top of the base router functionality.

For a Linux server, the manageability interface will depend on what applications have been installed.


The SEMVER work shows
that vendors are treating platforms as independent release trains, and not really
developing loadable packages.

This depends on the vendor.  The YANG versioning work is trying to find a solution that works across the industry.  I believe that the versioning requirements are different for standards developed modules, vs industry developed modules, vs vendor modules.



I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, SEMVER import)
and  the YANG Catalog can solve the module compatibility issues. It is more of a documentation
problem than a standards problem.

Having a standard YANG module that can be used to define packages is something this is useful and should be standardized.  I believe that this is better than each vendor coming up with their own solution for this problem.

Thanks,
Rob




Andy




On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:

Thanks Rob. Please see inline.

Jason

 

From: Robert Wilton <rwilton@cisco.com>
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; netmod@ietf.org
Subject: Re: initial comments on draft-rwilton-netmod-yang-packages

 

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi guys,

 

I've gotten most of the way through the draft and have some initial comments. I haven't digested the section 10 open issues yet or the examples.

 

Section 5 mentions the following:

   YANG library is augmented to allow servers to report the packages

   that they implement and to associate those packages back to

   particular datastore schema.

 

Does the combination of this draft and rfc7895bis somehow allow the same package to be advertised in 2 different datastores, but with different deviations in each datastore? I'm thinking of a case, for example, where a package is fully supported in the running but the package minus a few modules (or parts of modules) is supported in the operational datastore. There seems to be a 1:1 relationship between package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that <running> would implement package "foo", and <operational> would implement package "modified-foo".  Package "modified-foo" would import package "foo" and also specify the set of modules that contain the deviations "foo".

I didn't want a server to be able to see that I implement package "foo", but then I have all these deviations that change its behavior.  Instead, it is really implementing a different package that is based on "foo".

 

 

The packages draft doesn't include any specific leaf-list for deviations. Section 7.2 mentions that deviations could be expressed by including modules that happen to contain deviations. That seems a bit inconsistent with rfc7895bis that has a specific leaf-list of deviations (and NETCONF hello that specifically explicitly labels deviation modules).

I'm conflicted on this one.  I don't really like the deviation list in YANG library because I regard it as a duplicate source of information, and then there is a question of which source of data do you trust.  E.g. do you process a deviation in a module that is not listed in the deviations module list?

[>>JTS: ] Good point. I suppose this issue applies today already. i.e. what if one of the modules advertised in the <hello> is a module of deviations (without having been referenced by another module as a deviation module).

 

 

Section 5.1 says the package must be referentially complete. I can see the advantages of that although wondering if that might limit flexibility of partitioning modules into packages. I could imagine use cases for dividing a large set of modules into a few packages that might rev independently but can still all work together (especially if they rev in a bc manner). But maybe that just starts to introduce too much complexity?

Yes, having partial packages may be useful.  Perhaps just adding a leaf to indicate whether a package is referentially complete could be the answer here.

 

 

I didn't understand this part of section 5.1. Can you maybe illustrate with an example?

      The version/revision of a module listed in the package module list

      supercedes any version/revision of the module listed in a imported

      package module list.  This allows a package to resolve any

      conflicting implemented module versions/revisions in imported

      packages.

Probably best to see example B.3. in the appendix because it exactly illustrates this point.

Basically:
1) Packages must explicitly list all versions of all modules they define/import.
2) If two imported packages define different versions of modules, then the package that is importing them needs a way to define which version to use.
3) A package needs a way to override the version of module specified in an imported package.

[>>JTS: ] Thx. That example does help. I suppose the designer of the package needs to carefully check that the version they select can be successfully used by all the modules in the package.

I think there is a minor typo in example B.3.  The example-3-pkg is importing " example-import-1" but I believe you meant " example-import-1-pkg" (and some for import-2).

 

It might be a good idea to add a parent-version to the package module (to allow tracking lineage of packages).

Agreed, or maybe allowing a revision history like modules.  Not sure which is better here.  Packages could get a lot of updates, and a long revision history would not be helpful at all.

[>>JTS: ] I think a minimum of just specifying the direct parent is enough to build the full tree of lineage. We don't need a long history of N revisions.

 

 

I like the use of groupings. That allows a manager to use this as a building block to compose a model that has a list of packages.

OK.

 

 

Having a global list of mandatory features (vs having the mandatory feature a per-module list) means inventing the new <module-name>:<feature> format. Should we instead somehow put the mandatory features against each module of the package?

Perhaps.  My thinking here was to have the list of features high up and very easy to find/parse.

 

 

The location leaf is a uri but then the description says it must be a url (where the model can be retrieved). I do like that the namespace is separate from the location, but maybe we should make location a url type?

Yes, I was thinking that is should be a URL.

 

 

Do we need a namespace for package names in the model?

I had them in an earlier version, but I took them out, because I wasn't sure that they are really useful/required.

Defining a format to make package names themselves globally unique might be sufficient.

[>>JTS: ] I'm OK with that. It is similar to how we're finding that it is useful that YANG module names are globally unique (i.e. by naming with ietf-xxxx or companyabc-xxx).

 

 

In 7.3 we only reference module-sets and not modules. So the grouping of modules into sets and packages must be the same?

Not necessarily.

I am trying to reuse the module-set definitions as much as possible (to avoid duplication).  One issue here is that module-sets are combined then all the modules must not overlap, which doesn't make the mapping to module-sets quite so clean.

 

 

A schema can only have a single package. I think that works but it means a server would advertise multiple schemas if it wants to support multiple packages. I'm not sure if there are some downsides to that (it just surprised me).

My aim here was:
 - multiple packages are advertised in yang-library/packages
 - datastores only report that they "implement" one [top level] package version.  [The package itself might import other packages.]

If we do package selection, then for a given YANG client session, and the version of YANG library available/reported by that session, it would appear as if the server only implements one top level package for a datastore.  Different clients choosing different versions would see slightly different output depending on which package version they had selected to use.

Thanks again for the review and the comments!

Rob

 

 

 

Jason

 

 

 

From: netmod <netmod-bounces@ietf.org> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: netmod@ietf.org
Subject: [netmod] YANG Packages

 

Hi,

I've written up an ID for a potential solution for YANG packages using instance data:

Abstract
 
   This document defines YANG packages, an organizational structure
   holding a set of related YANG modules, that can be used to simplify
   the conformance and sharing of YANG schema.  It describes how YANG
   instance data documents are used to define YANG packages, and how the
   YANG library information published by a server can be augmented with
   additional packaging related information.

https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/

Potentially this work may be of use as part of the YANG versioning design team work.  In addition, if the WG likes this approach of defining YANG packages, then it might also be useful to bind a schema to a YANG instance data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs to be solved?

2) Is the approach in this draft of defining these as instance data documents a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not replacing the way that modules are reported in YANG library-bis.  Is this the right approach?  This approach tries to allow module-sets to be reused for both schema and packages, but the YANG library-bis rules for combining module-sets (i.e. no conflicts) may make this harder to really reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.

Thanks,
Rob

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--------------683915C58BEA266375368C4B-- From nobody Wed Jan 30 10:12:08 2019 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 601FE131305 for ; Wed, 30 Jan 2019 10:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.643 X-Spam-Level: X-Spam-Status: No, score=-14.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 AbnT_r98l_om for ; Wed, 30 Jan 2019 10:12:04 -0800 (PST) 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 35D2D130ECE for ; Wed, 30 Jan 2019 10:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3512; q=dns/txt; s=iport; t=1548871924; x=1550081524; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=aD56lK9Tc5tvOJjjn3um8bNTUlw+4lWKk0u2ATmrl78=; b=UEW7NRk0mHiBRrUaomOOz2NZ8yvw7Ig3e+gMQoXYXWyHSBruItCUv4qA PFBjvPAiYrW0SDJJpF2nYhA9OmBR300EEknnx8Ki1qjSZG+m+HnbtCy0o ErUurPr7tgOYYg7kqIiXxjQpupjk8rogUOwo4E/x0ZvYnv9lb6xj/UDI2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/AADA51Fc/xbLJq1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVAMBAQELAYFVgWYgEoQqiHmNIZoIDYRsAoMpNwYNAQMBAQIBAQJ?= =?us-ascii?q?tKIVKAQEBAQIBIw8BBVELGAICJgICVxMIAQEXgweBegisOoEvhUOEcoELi0y?= =?us-ascii?q?BQD+BOIJrhGuDH4JXAoohmDcJkiwGGIo5h3qUSocYgVwigVYzGggbFTuCbYI?= =?us-ascii?q?mF44ePwOQNwEB?= X-IronPort-AV: E=Sophos;i="5.56,541,1539648000"; d="scan'208";a="9768341" 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; 30 Jan 2019 18:12:02 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x0UIC2iM020572 for ; Wed, 30 Jan 2019 18:12:02 GMT To: netmod@ietf.org References: <877eemjj2g.fsf@nic.cz> From: Robert Wilton Message-ID: Date: Wed, 30 Jan 2019 18:12:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <877eemjj2g.fsf@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] LL comments on draft-rwilton-netmod-yang-packages-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 18:12:06 -0000 Hi Lada, Thanks for the review and comments ... I've added some thoughts inline ... On 30/01/2019 14:50, Ladislav Lhotka wrote: > Hi, > > I think it is a good start, here are my comments (some of them were > already raised by Jason): > > - I like the fact that this work doesn't require any changes to YANG, > except perhaps semver. RW: OK. > > - I think the augments to YANG library is a separate problem that should > perhaps be addressed in a different document. Servers supporting > multiple package revisions may not be that common. RW: I completely agree that servers supporting multiple package revisions may not be that common, and I agree that any specification on how a server could support multiple packages, and perform package selection should be in a separate draft. But the YANG library augmentations aren't there only to support this use case.  My intention is to make it easier for devices to advertise a package representing what each datastore schema is rather than having to fetch the full contents of YANG library. E.g. a server might implement 900+ modules/sub-modules for a given release.  Different hardware will mostly implement the same modules, but there might be some differences.  If bugs have been patched then there might be some differences.  I'm aiming for a solution where a client doesn't have to fetch the full list of YANG modules for each server to figure out the schema for the device, which is probably the same as another 1000 devices in the network. Instead, I would like the vendor to publish a package for that particular release, with variants depending on the hardware.  The device can then advertise that it uses that base package, along with the small set of differences (e.g. due to bug fixes). > > - I was expecting that a package could specify a range of revisions for > some modules that may be used together with teh others. This doesn't > seem to be the case. If so, it would be somewhat unwieldy because every > combination of module revisions would require a separate package > revision. RW: Yes, this is an interesting point. My intention is that there is a roughly linear history of package versions.  E.g. if there was a package of all IETF modules, then every time a new version of an IETF module is published, the package definition would be updated to a new version that includes the new published module revision. I think that we need to try and somewhat constraint the versions of modules that can sensibly be used together. > > - As Jason pointed out, there seems to be no use for the package > namespace, as packages don't define any names on their own. Yes, I will remove the text about namespaces.  Globally unique package names should be sufficient. > > - I would also prefer mandatory-features to be bundled with each module. > > - This draft nicely shows that there is really no need for any > "yang-data" extensions. But I also don't see any benefit from using > ietf-yang-instance-data in this case. It would IMO be perfectly fine > to get rid of two levels of data hierarchy: > > { "ietf-yang-package:yang-package": { > ... > } > } That's an interesting point.  My thought is that all at rest YANG data would be encoded in YANG instance data documents to make them more easily machine parse-able. Thanks, Rob > > Thanks, Lada > > From nobody Wed Jan 30 11:02:54 2019 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 6FF8E130F80 for ; Wed, 30 Jan 2019 11:02:53 -0800 (PST) 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 CR5_MckqV2EC for ; Wed, 30 Jan 2019 11:02:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B9E94130EB2 for ; Wed, 30 Jan 2019 11:02:51 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 81E661AE012C; Wed, 30 Jan 2019 20:02:50 +0100 (CET) Date: Wed, 30 Jan 2019 20:02:50 +0100 (CET) Message-Id: <20190130.200250.2298112466859908310.mbj@tail-f.com> To: lhotka@nic.cz Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <874l9qjhto.fsf@nic.cz> References: <874l9qjhto.fsf@nic.cz> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] features in import X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 19:02:53 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for > import-only modules. But is it really so that features have no use in > such modules? > > For example, an enum can depend on a feature, and if it is inside a > typedef, it can also be in an import-only module. What if that feature > is defined in the same module? I think you're right, and that this is an unfortunate omission. The fix is simple though; we would have to add the leaf-list features to import-only. Probably refactor the "feature" leaf-list into a grouping so it works like the grouping location-leaf-list: grouping feature-leaf-list { leaf-list feature { type yang:yang-identifier; description "List of all YANG feature names from this module that are supported by the server, regardless whether they are defined in the module or any included submodule."; } } And then "uses feature-leaf-list": OLD: grouping module-implementation-parameters { description "Parameters for describing the implementation of a module."; leaf-list feature { type yang:yang-identifier; description "List of all YANG feature names from this module that are supported by the server, regardless whether they are defined in the module or any included submodule."; } NEW: grouping module-implementation-parameters { description "Parameters for describing the implementation of a module."; uses feature-leaf-list; And in the list "import-only": OLD: uses location-leaf-list; uses feature-leaf-list; /martin From nobody Wed Jan 30 12:52:21 2019 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 DF89113103A for ; Wed, 30 Jan 2019 12:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 9VkVIVQDcz70 for ; Wed, 30 Jan 2019 12:52:14 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 33A8B130FEB for ; Wed, 30 Jan 2019 12:52:13 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id x85-v6so810125ljb.2 for ; Wed, 30 Jan 2019 12:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QD4TpOdCYzOnvWsFaia0f09TumNLSTlbFwF8M/r1C+s=; b=B+jHS4sIg3unFcnbX2l+DDP4vW2fBZaDfrUPYjcR41RMYz6J861lubeaTLOKT993tl WddXg9lRhRLWCu8hTd3YhdEYXRLJ5ik4BuIIJHiyXgjOAAGtetcL208eYckaGfJYWBwh XKj40YvUYf4g7aJEbBHeh4/8BU/pIaOAV7WZfLrSiYK9weJ+6BWzzPJmnUcFFe26vxNl lLDL2jZzoSjQr7GZPnh8ejakuKK1qYpkC2ZlhIGJ8KAylyvwjthSYNOafzUT2AsAA9JH 6seND9mbbrMj4PgpWqeo5JahYD0Mb1EL4HYSWtVrAO3pYnBzxYmKE6mRHmc2vbgKirg9 XfeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QD4TpOdCYzOnvWsFaia0f09TumNLSTlbFwF8M/r1C+s=; b=mzDYUNuQZ5LQWDXInq1eNmz72MK7UJB+r7INPQAbct6692Rz6wRUVQuzETjFd99LVd HaNk62tDy90VBauaHMaPioajXRGwyMx942VELW8bJPMNM6fqayVRHknhWC3+10pAiFBV k8g+PD0xbt2lL8h8E0fqYdS44Uh5LZizAUGkK4jnimd9KX2JELqYKc9fm0LRyr44fkIx xZUl1KZfvbENOxbPVfSEf2S1dVw0ykW/MJvnYmm3zgQPK2w+LMBLy9aPNp13TW29bR9X 6aJWwIWzCMGEeaf8CxDVZtPLKF0e4H9Sy7wz4Vw2eRAvyWrg/76s5P6TPX78FcoMaznY vXTw== X-Gm-Message-State: AJcUukcmUjXUq4nvM3Z8hzcGhEmrR3phTTyIpi0aElksCOgF3HCKgZr4 ucHNpPOv8zx4qiPz+gt64Z5An6MA3bS9CvKckqz3jA== X-Google-Smtp-Source: ALg8bN7bVAnYxHqaw3K8yaL+q+HPJKyQSMTHgzX/CK1XzkElIdG91+MxY6p3o6fw7euPqA+hCMtNkAKIj0ni57Z5wTs= X-Received: by 2002:a2e:29d7:: with SMTP id p84-v6mr25828426ljp.12.1548881531061; Wed, 30 Jan 2019 12:52:11 -0800 (PST) MIME-Version: 1.0 References: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> <914c99e5-ca38-9e39-32dd-1b0c3ed3294e@cisco.com> In-Reply-To: <914c99e5-ca38-9e39-32dd-1b0c3ed3294e@cisco.com> From: Andy Bierman Date: Wed, 30 Jan 2019 12:51:59 -0800 Message-ID: To: Robert Wilton Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007566c80580b3154a" Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 20:52:20 -0000 --0000000000007566c80580b3154a Content-Type: text/plain; charset="UTF-8" On Wed, Jan 30, 2019 at 10:04 AM Robert Wilton wrote: > > On 30/01/2019 17:31, Andy Bierman wrote: > > > > On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton wrote: > >> >> On 30/01/2019 15:16, Andy Bierman wrote: >> >> >> >> On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton wrote: >> >>> Hi Andy, >>> >>> Thanks for the comments. >>> On 30/01/2019 01:22, Andy Bierman wrote: >>> >>> Hi, >>> >>> I originally brought up this issue in July 2015 >>> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ >>> >>> Yes. >>> >>> The solution I propose is different in the sense that it uses YANG >>> instance data to define YANG packages rather than new YANG keywords. I >>> believe that this should make it a lower cost solution to define and >>> implement. >>> >>> >>> >> I think yangvalidator.org has a better solution that does not change >> YANG conformance. >> >> Do you mean that we can just use zip files with the list of modules? >> > > I don't care about the solution details yet. They are 2nd order problems. > > Conformance means "what modules are required to be implemented together". > It is not clear that this problem can be solved. The augment-stmt defines > implicit > multi-module conformance. I am not convinced that the extra work of > defining package conformance > is worth it. > > So, I'm not proposing backing any sort of package conformance into the > language at all. A package is just metadata that defines that a set of > modules, at particular revisions/versions, work together and can represent > part of a YANG schema. > > This is equivalent to > - how a zip file of YANG modules provided to yangvalidator would work. > - getting the contents of YANG library from a server (but a YANG packages > soln can also work offline) > - fetching the modules from YANG catalog (if they have been labelled > appropriately), although I'm not convinced that this universally works > today. > > This sort of metadata could be provided by module tags. A vendor or SDO could define module-tags that represent packages. > But in terms of the usability of YANG, I don't think that doing > conformance only at the module level is really sufficient. Clients need to > be coding against sets of modules at particular versions that are known to > work together, and known that multiple server vendors will implement. > > A pick and mix appropriate to module revisions doesn't seem to help anyone. > > > I get all the different components and variables one might have for a package. I am not as convinced (as in 2015) that standard packages could be simple and widely deployed.. Now it seems vendors implement an ad-hoc subset + additions to everything. It doesn't help to define a new package variant to match the vendor implementation. The YANG library can do that already. You seem more optimistic than me that the industry is actually ready, willing, and able to implement standard YANG packages. > The issue of what modules does vendor A implement is not a conformance > problem. > It is just more metadata and YANG Catalog is focused on providing that > data. > > Does YANG catalog indicate the set of IETF modules that I would need to > implement L2VPN services on a device? > > This seems like a separate problem, but actually it can help by searching a lot of known modules. In order to know what vendor A, B, and C have in common, you need to get the catalog info for each vendor. Module tags can also solve this problem. > Module tags could be used to do this (another packaging solution), but > this would cause a proliferation of tags when it comes to versioning, since > I don't think that you can cleanly bake semver into module tags. > > > > I don't really see how this helps. >> >> Consider: >> - server vendor A, implements some subset of the OpenConfig YANG modules, >> each at a particular version, along with some deviations and vendor >> augmentations. >> - server vendor B, implements the same subset of the OpenConfig YANG >> modules, but at different versions, along with some deviations and vendor >> augmentations. >> - server vendor C, implements a slightly different set of the OpenConfig >> YANG modules, but at different versions, along with some deviations and >> vendor augmentations. >> >> As a client, how do I know what module versions to code against, when I >> want to work with devices provided by all three vendors? >> > > > The vendors publish their implementation details on yangcatalog and you > get the info > and see what modules are in common. > > There are only market requirements determining what group of modules has > to exist > in an implementation. It is not clear to me that formalizing these > requirements > is something the industry will do effectively. Module tags already > provide a way > to conceptually group modules together. > > Seems like every vendor has openconfig, foo-openconfig, and > foo-openconfig-deviations > so that there are no agreed upon subsets. Even if openconfig had properly > documented > subsets, would your client even be able to code to it (ignoring add-ons > and deviations). > > I think that answer will converge on yes, I don't know how long it will > take. It would probably be better if at the time that protocol > specifications are written, that the authors of the specifications also > write the YANG modules to manage them at the same time. > > > I might be wrong, but I think that the OC solution is use git tags, so >> they tag sets of modules that are expected to work together and also to >> provide a linear release history of their sets of modules. So, if everyone >> implements the module versions associated with a git tag then it should >> convert a two dimensional problem of module revisions into a linear >> problem. The YANG packages draft is aiming to provide a solution to this >> problem that doesn't require the use of git, or sending zip files of >> modules around. >> > > At the moment, it seems that everyone is doing this in different ways: >> - Yumawork customers/servers use zip files of modules for conformance. >> > > Not sure what this means. > Actually the server libraries can be loaded and unloaded. > Module can be standalone libraries or grouped as bundles. > But this seems like an implementation detail, unrelated to conformance. > > > - OpenConfig client/server implementations use git tags, or git refpoints. >> - Cisco customers use the contents of directories on github YangModels. >> >> Finally, this draft doesn't change YANG conformance, it just expresses it >> in what is intended to be a simpler way. >> > > It adds another conformance system to maintain. > The language only recognizes module to module interfaces, not package to > package. > > I propose that at the language level conformance is at the module level > (modulo import-by-version). > > > That adds more complexity. It doesn't take away any complexity. > > It is meant to be a simpler way of packaging up, and trying to control and > manage the complexity that already exists today. > > E.g. I could give a YANG compiler the name, version, and location of a > package and tell it to build the entire schema associated with that > package. > This is a tool implementation detail, not a conformance issue. It would be nice to have a standard format for the YANG library for a tool to use. You seem to be proposing an artifact containing ietf-yang-library information. That seems OK to me, but it should not have anything to do with conformance. It is just a standard way to express a module-set in a yang-data artifact. > In a somewhat similar way, when I write code, my build file specifies > which libraries I depend on, and their versions, but I can leave it to the > build tool to determine what those libraries themselves depend on and > recursively pull in all the dependencies. > > > > If there was a standard to load and unload modular functionality at > boot-time or run-time, > then I could see why there is a need to have a standard to define YANG > packages. > > I agree that this is another example of where they could be useful. > > Thanks, > Rob > > > Andy > > >> Thanks, >> Rob >> >> >> > Andy > > >> >> >> Andy >> >> >>> >>> I don't think the WG ever agreed on the problem that needs to be solved, >>> and that is still the case. >>> >>> That wasn't quite my impression. I also think that folks were busy >>> focusing on other WG activity and didn't necessarily have the time to >>> concentrate on this. >>> >>> My draft was aiming on solving two broad problems: >>> >>> The main goals of YANG package definitions include, but are not >>> restricted to: >>> >>> o To act as a simplified YANG conformance mechanism. Rather than >>> conformance being performed against a set of individual YANG >>> module revisions, conformance could also be more simply stated in >>> terms of YANG packages, with a set modifications (e.g. additional >>> modules, deviations, or features). >>> >>> o To allow YANG datastore schema to be specified in a more concise >>> way rather than having to list all modules and revisions. YANG >>> package definitions can be defined in documents that can be >>> referenced by a URL rather than requiring explicit lists of >>> modules to be shared between client and server. Hence, a YANG >>> package must contain sufficient information to allow a client or >>> server to precisely construct the schema associated with the >>> package. >>> >>> >>> >>> >>> >>> In reality each server has 1 package -- its entire library. >>> >>> This doesn't apply to all servers. For a long time, as a vendor, we >>> have had separate packages that can be independently installed, and which >>> extend the management model to cover the new functionality. E.g. BNG >>> functionality could be in a separate, independently installable, package on >>> top of the base router functionality. >>> >>> For a Linux server, the manageability interface will depend on what >>> applications have been installed. >>> >>> >>> The SEMVER work shows >>> that vendors are treating platforms as independent release trains, and >>> not really >>> developing loadable packages. >>> >>> This depends on the vendor. The YANG versioning work is trying to find >>> a solution that works across the industry. I believe that the versioning >>> requirements are different for standards developed modules, vs industry >>> developed modules, vs vendor modules. >>> >>> >>> >>> I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, >>> SEMVER import) >>> and the YANG Catalog can solve the module compatibility issues. It is >>> more of a documentation >>> problem than a standards problem. >>> >>> Having a standard YANG module that can be used to define packages is >>> something this is useful and should be standardized. I believe that this >>> is better than each vendor coming up with their own solution for this >>> problem. >>> >>> Thanks, >>> Rob >>> >>> >>> >>> >>> Andy >>> >>> >>> >>> >>> On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) < >>> jason.sterne@nokia.com> wrote: >>> >>>> Thanks Rob. Please see inline. >>>> >>>> Jason >>>> >>>> >>>> >>>> *From:* Robert Wilton >>>> *Sent:* Thursday, January 24, 2019 1:16 PM >>>> *To:* Sterne, Jason (Nokia - CA/Ottawa) ; >>>> netmod@ietf.org >>>> *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages >>>> >>>> >>>> >>>> Hi Jason, >>>> >>>> Thanks for the review and comments. >>>> >>>> I've put some responses inline ... >>>> >>>> On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote: >>>> >>>> Hi guys, >>>> >>>> >>>> >>>> I've gotten most of the way through the draft and have some initial >>>> comments. I haven't digested the section 10 open issues yet or the examples. >>>> >>>> >>>> >>>> Section 5 mentions the following: >>>> >>>> YANG library is augmented to allow servers to report the packages >>>> >>>> that they implement and to associate those packages back to >>>> >>>> particular datastore schema. >>>> >>>> >>>> >>>> Does the combination of this draft and rfc7895bis somehow allow the >>>> same package to be advertised in 2 different datastores, but with different >>>> deviations in each datastore? I'm thinking of a case, for example, where a >>>> package is fully supported in the running but the package minus a few >>>> modules (or parts of modules) is supported in the operational datastore. >>>> There seems to be a 1:1 relationship between package and rfc7895bis schema. >>>> >>>> So, the intention is no, not directly. >>>> >>>> My aim here is that would implement package "foo", and >>>> would implement package "modified-foo". Package >>>> "modified-foo" would import package "foo" and also specify the set of >>>> modules that contain the deviations "foo". >>>> >>>> I didn't want a server to be able to see that I implement package >>>> "foo", but then I have all these deviations that change its behavior. >>>> Instead, it is really implementing a different package that is based on >>>> "foo". >>>> >>>> >>>> >>>> >>>> >>>> The packages draft doesn't include any specific leaf-list for >>>> deviations. Section 7.2 mentions that deviations could be expressed by >>>> including modules that happen to contain deviations. That seems a bit >>>> inconsistent with rfc7895bis that has a specific leaf-list of deviations >>>> (and NETCONF hello that specifically explicitly labels deviation modules). >>>> >>>> I'm conflicted on this one. I don't really like the deviation list in >>>> YANG library because I regard it as a duplicate source of information, and >>>> then there is a question of which source of data do you trust. E.g. do you >>>> process a deviation in a module that is not listed in the deviations module >>>> list? >>>> >>>> *[>>JTS: ] Good point. I suppose this issue applies today already. i.e. >>>> what if one of the modules advertised in the is a module of >>>> deviations (without having been referenced by another module as a deviation >>>> module).* >>>> >>>> >>>> >>>> >>>> >>>> Section 5.1 says the package must be referentially complete. I can see >>>> the advantages of that although wondering if that might limit flexibility >>>> of partitioning modules into packages. I could imagine use cases for >>>> dividing a large set of modules into a few packages that might rev >>>> independently but can still all work together (especially if they rev in a >>>> bc manner). But maybe that just starts to introduce too much complexity? >>>> >>>> Yes, having partial packages may be useful. Perhaps just adding a leaf >>>> to indicate whether a package is referentially complete could be the answer >>>> here. >>>> >>>> >>>> >>>> >>>> >>>> I didn't understand this part of section 5.1. Can you maybe illustrate >>>> with an example? >>>> >>>> The version/revision of a module listed in the package module list >>>> >>>> supercedes any version/revision of the module listed in a imported >>>> >>>> package module list. This allows a package to resolve any >>>> >>>> conflicting implemented module versions/revisions in imported >>>> >>>> packages. >>>> >>>> Probably best to see example B.3. in the appendix because it exactly >>>> illustrates this point. >>>> >>>> Basically: >>>> 1) Packages must explicitly list all versions of all modules they >>>> define/import. >>>> 2) If two imported packages define different versions of modules, then >>>> the package that is importing them needs a way to define which version to >>>> use. >>>> 3) A package needs a way to override the version of module specified in >>>> an imported package. >>>> >>>> *[>>JTS: ] Thx. That example does help. I suppose the designer of the >>>> package needs to carefully check that the version they select can be >>>> successfully used by all the modules in the package. * >>>> >>>> *I think there is a minor typo in example B.3. The example-3-pkg is >>>> importing "* *example-import-1" but I believe you meant "* *example-import-1-pkg" >>>> (and some for import-2).* >>>> >>>> >>>> >>>> It might be a good idea to add a parent-version to the package module >>>> (to allow tracking lineage of packages). >>>> >>>> Agreed, or maybe allowing a revision history like modules. Not sure >>>> which is better here. Packages could get a lot of updates, and a long >>>> revision history would not be helpful at all. >>>> >>>> *[>>JTS: ] I think a minimum of just specifying the direct parent is >>>> enough to build the full tree of lineage. We don't need a long history of N >>>> revisions.* >>>> >>>> >>>> >>>> >>>> >>>> I like the use of groupings. That allows a manager to use this as a >>>> building block to compose a model that has a list of packages. >>>> >>>> OK. >>>> >>>> >>>> >>>> >>>> >>>> Having a global list of mandatory features (vs having the mandatory >>>> feature a per-module list) means inventing the new : >>>> format. Should we instead somehow put the mandatory features against each >>>> module of the package? >>>> >>>> Perhaps. My thinking here was to have the list of features high up and >>>> very easy to find/parse. >>>> >>>> >>>> >>>> >>>> >>>> The location leaf is a uri but then the description says it must be a >>>> url (where the model can be retrieved). I do like that the namespace is >>>> separate from the location, but maybe we should make location a url type? >>>> >>>> Yes, I was thinking that is should be a URL. >>>> >>>> >>>> >>>> >>>> >>>> Do we need a namespace for package names in the model? >>>> >>>> I had them in an earlier version, but I took them out, because I wasn't >>>> sure that they are really useful/required. >>>> >>>> Defining a format to make package names themselves globally unique >>>> might be sufficient. >>>> >>>> *[>>JTS: ] I'm OK with that. It is similar to how we're finding that it >>>> is useful that YANG module names are globally unique (i.e. by naming with >>>> ietf-xxxx or companyabc-xxx).* >>>> >>>> >>>> >>>> >>>> >>>> In 7.3 we only reference module-sets and not modules. So the grouping >>>> of modules into sets and packages must be the same? >>>> >>>> Not necessarily. >>>> >>>> I am trying to reuse the module-set definitions as much as possible (to >>>> avoid duplication). One issue here is that module-sets are combined then >>>> all the modules must not overlap, which doesn't make the mapping to >>>> module-sets quite so clean. >>>> >>>> >>>> >>>> >>>> >>>> A schema can only have a single package. I think that works but it >>>> means a server would advertise multiple schemas if it wants to support >>>> multiple packages. I'm not sure if there are some downsides to that (it >>>> just surprised me). >>>> >>>> My aim here was: >>>> - multiple packages are advertised in yang-library/packages >>>> - datastores only report that they "implement" one [top level] package >>>> version. [The package itself might import other packages.] >>>> >>>> If we do package selection, then for a given YANG client session, and >>>> the version of YANG library available/reported by that session, it would >>>> appear as if the server only implements one top level package for a >>>> datastore. Different clients choosing different versions would see >>>> slightly different output depending on which package version they had >>>> selected to use. >>>> >>>> Thanks again for the review and the comments! >>>> >>>> Rob >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Jason >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From:* netmod *On >>>> Behalf Of *Robert Wilton >>>> *Sent:* Thursday, December 20, 2018 12:45 PM >>>> *To:* netmod@ietf.org >>>> *Subject:* [netmod] YANG Packages >>>> >>>> >>>> >>>> Hi, >>>> >>>> I've written up an ID for a potential solution for YANG packages using >>>> instance data: >>>> >>>> Abstract >>>> >>>> >>>> >>>> This document defines YANG packages, an organizational structure >>>> >>>> holding a set of related YANG modules, that can be used to simplify >>>> >>>> the conformance and sharing of YANG schema. It describes how YANG >>>> >>>> instance data documents are used to define YANG packages, and how the >>>> >>>> YANG library information published by a server can be augmented with >>>> >>>> additional packaging related information. >>>> >>>> https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ >>>> >>>> Potentially this work may be of use as part of the YANG versioning >>>> design team work. In addition, if the WG likes this approach of defining >>>> YANG packages, then it might also be useful to bind a schema to a YANG >>>> instance data document. >>>> >>>> Some questions for members of the WG: >>>> >>>> 1) Do members of the WG agree that YANG packages is something that >>>> needs to be solved? >>>> >>>> 2) Is the approach in this draft of defining these as instance data >>>> documents a good starting point? >>>> >>>> 3) This approach augments YANG library-bis, reusing module-sets, but >>>> not replacing the way that modules are reported in YANG library-bis. Is >>>> this the right approach? This approach tries to allow module-sets to be >>>> reused for both schema and packages, but the YANG library-bis rules for >>>> combining module-sets (i.e. no conflicts) may make this harder to really >>>> reuse the module-sets for both purposes. >>>> >>>> Of course, any other comments or feedback is welcome and appreciated. >>>> >>>> Thanks, >>>> Rob >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>> --0000000000007566c80580b3154a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 30, 2019 at 10:04 AM Robe= rt Wilton <rwilton@cisco.com>= ; wrote:
=20 =20 =20


On 30/01/201= 9 17:31, Andy Bierman wrote:
=20


On Wed, Jan 30, 2019 at 8:0= 2 AM Robert Wilton <rwilton@cisco.com> wrote:


On 30/01/2019 15:16, Andy Bierman wrote:


On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,

Thanks for the comments.

On 30/01/2019 01:22, Andy Bierman wrote:
Hi,

I originally brought up this issue in July 2015

Yes.

The solution I propose is different in the sense that it uses YANG instance data to define YANG packages rather than new YANG keywords.=C2=A0=C2=A0 I believe that this should = make it a lower cost solution to define and implement.



I think yangvalidator.org has a better solution that does not change YANG conformance.

Do you mean that we can just use zip files with the list of modules?


I don't care about the solution details yet. They are 2n= d order problems.

Conformance means "what modules are required to be implemented together".
It is not clear that this problem can be solved.=C2=A0 The augment-stmt defines implicit
multi-module conformance.=C2=A0 I am not convinced that the extra work of defining package conformance
is worth it.

So, I'm not proposing backing any sort of package conformance into the language at all.=C2=A0 A package is just metadata that defin= es that a set of modules, at particular revisions/versions, work together and can represent part of a YANG schema.

This is equivalent to
=C2=A0- how a zip file of YANG modules provided to yangvalidator woul= d work.
=C2=A0- getting the contents of YANG library from a server (but a YAN= G packages soln can also work offline)
=C2=A0- fetching the modules from YANG catalog (if they have been labelled appropriately), although I'm not convinced that this universally works today.


This sort of metadata cou= ld be provided by module tags.
A vendor or SDO could define modul= e-tags that represent packages.


=C2= =A0

But in terms of the usability of YANG, I don't think that d= oing conformance only at the module level is really sufficient.=C2=A0 Clients need to be coding against sets of modules at particular versions that are known to work together, and known that multiple server vendors will implement.

A pick and mix appropriate to module revisions doesn't seem to help anyone.



I get all the differe= nt components and variables one might have for a package.
I am no= t as convinced (as in 2015) that standard packages could be simple and wide= ly deployed..
Now it seems vendors implement an ad-hoc subset= =C2=A0+ additions to everything.
It doesn't help to define a = new package variant to match the vendor implementation.
The YANG = library can do that already.

You seem more optimis= tic than me that the industry is actually ready, willing, and able
to implement standard YANG packages.


<= div>


The issue of what modules does vendor A implement is not a conformance problem.
It is just more metadata and YANG Catalog is focused on providing that data.

Does YANG catalog indicate the set of IETF modules that I would need to implement L2VPN services on a device?


This seems like a sepa= rate problem, but actually it can help by searching a lot of known modules.=
In order to know what vendor A, B, and C have in common, you nee= d to get the catalog info for each vendor.

Module = tags can also solve this problem.
=C2=A0

Module tags could be used to do this (another packaging solution), but this would cause a proliferation of tags when it comes to versioning, since I don't think that you can cleanly bake semver into module tags.



I don't really see how this helps.

Consider:
- server vendor A, implements some subset of the OpenConfig YANG modules, each at a particular version, along with some deviations and vendor augmentations.
- server vendor B, implements the same subset of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations.
- server vendor C, implements a slightly different set of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations.

As a client, how do I know what module versions to code against, when I want to work with devices provided by all three vendors?



The vendors publish their implementation details on yangcatalog and you get the info
and see what modules are in common.

There are only market requirements determining what group of modules has to exist
in an implementation.=C2=A0 It is not clear to me that formalizing these requirements
is something the industry will do effectively.=C2=A0 Module tags already provide a way
to conceptually group modules together.

Seems like every vendor has openconfig, foo-openconfig, and foo-openconfig-deviations
so that there are no agreed upon subsets. Even if openconfig had properly documented
subsets, would your client even be able to code to it (ignoring add-ons and deviations).

I think that answer will converge on yes, I don't know how long it will take.=C2=A0 It would probably be better if at the time that protocol specifications are written, that the authors of the specifications also write the YANG modules to manage them at the same time.


I might be wrong, but I think that the OC solution is use git tags, so they tag sets of modules that are expected to work together and also to provide a linear release history of their sets of modules.=C2=A0 So, if everyone implements the module versions associated with a git tag then it should convert a two dimensional problem of module revisions into a linear problem.=C2=A0 Th= e YANG packages draft is aiming to provide a solution to this problem that doesn't require the use of git, or sending zip files of modules around.


At the moment, it seems that everyone is doing this in different ways:
=C2=A0- Yumawork customers/servers use zip files of modules for conformance.


Not sure what this means.
Actually the server libraries can be loaded and unloaded.
Module can be standalone libraries or grouped as bundles.
But this seems like an implementation detail, unrelated to conformance.


=C2=A0- OpenConfig client/server implementations use git tags, or git refpoints.
=C2=A0- Cisco customers use the contents of directories on github YangModels.

Finally, this draft doesn't change YANG conformance, i= t just expresses it in what is intended to be a simpler way.


It adds another conformance system to maintain.
The language only recognizes module to module interfaces, not package to package.

I propose that at the language level conformance is at the module level (modulo import-by-version).


That adds more complexity. It doesn't take away any complexity.

It is meant to be a simpler way of packaging up, and trying to control and manage the complexity that already exists today.

E.g. I could give a YANG compiler the name, version, and location of a package and tell it to build the entire schema associated with that package.=C2=A0


This is a tool implementation detail, not a conformance issue.
It would be nice to have a standard format for the YANG library for a tool= to use.
You seem to be proposing an artifact containing ietf-yan= g-library information.
That seems OK to me, but it should not hav= e anything to do with conformance.
It is just a standard way to e= xpress a module-set in a yang-data artifact.

=C2= =A0

In a somewhat similar way, when I write code, my build file specifies which libraries I depend on, and their versions, but I can leave it to the build tool to determine what those libraries themselves depend on and recursively pull in all the dependencies.



If there was a standard to load and unload modular functionality at boot-time or run-time,
then I could see why there is a need to have a standard to define YANG packages.

I agree that this is another example of where they could be useful.

Thanks,
Rob



Andy
=C2=A0=

=C2=A0

Thanks,
Rob



Andy
=C2=A0



Andy
=C2=A0


I don't think the WG ever agreed on the problem that needs to be solved,
and that is still the case.

That wasn't quite my impression.=C2=A0 I als= o think that folks were busy focusing on other WG activity and didn't necessarily have the time to concentrate on this.

My draft was aiming on solving two broad problems:

   The main goals of YANG package definitions include, bu=
t are not
   restricted to:

   o  To act as a simplified YANG conformance mechanism.  Rather than
      conformance being performed against a set of individual YANG
      module revisions, conformance could also be more simply stated in
      terms of YANG packages, with a set modifications (e.g. additional
      modules, deviations, or features).

   o  To allow YANG datastore schema to be specified in a more concise
      way rather than having to list all modules and revisions.  YANG
      package definitions can be defined in documents that can be
      referenced by a URL rather than requiring explicit lists of
      modules to be shared between client and server.  Hence, a YANG
      package must contain sufficient information to allow a client or
      server to precisely construct the schema associated with the
      package.


=C2=A0

In reality each server has 1 package -- its entire library.

This doesn't apply to all servers.=C2=A0 For= a long time, as a vendor, we have had separate packages that can be independently installed, and which extend the management model to cover the new functionality.=C2=A0 E.g. BNG functionali= ty could be in a separate, independently installable, package on top of the base router functionality.

For a Linux server, the manageability interface will depend on what applications have been installed.


The SEMVER work shows
that vendors are treating platforms as independent release trains, and not really
developing loadable packages.

This depends on the vendor.=C2=A0 The YANG versioning work is trying to find a solution that works across the industry.=C2=A0 I believe that the versioning requirements are different for standards developed modules, vs industry developed modules, vs vendor modules.



I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, SEMVER import)
and=C2=A0 the YANG Catalog can solve the module compatibility issues. It is more of a documentation
problem than a standards problem.

Having a standard YANG module that can be used to define packages is something this is useful and should be standardized.=C2=A0 I believ= e that this is better than each vendor coming up with their own solution for this problem.

Thanks,
Rob




Andy




On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:

Thanks Rob. Please see inline.

Jason

=C2=A0

From: Robert Wilton <rwilton@cisco.com>
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com= >; netmod@ietf.org
Subject: Re: initial comments on draft-rwilton-netmod-yang-packa= ges

=C2=A0

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi guys,

=C2=A0

I've gotten most of the way through the draft and have some initial comments. I haven't digested the section 10 open issues yet or the examples.

=C2=A0

Section 5 mentions the following:<= /p>

=C2=A0=C2=A0 YANG library is augmented to allow servers to report the packages

=C2=A0=C2=A0 that they implement and to associate those packages back to

=C2=A0=C2=A0 particular datastore schema.

=C2=A0

Does the combination of this draft and rfc7895bis somehow allow the same package to be advertised in 2 different datastores, but with different deviations in each datastore? I'm thinking of a case, for example, where a package is fully supported in the running but the package minus a few modules (or parts of modules) is supported in the operational datastore. There seems to be a 1:1 relationship between package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that <running> would implement package "foo", and <operational> would implement package "modified-foo&= quot;.=C2=A0 Package "modified-foo" woul= d import package "foo" and al= so specify the set of modules that contain the deviations "foo"= ;.

I didn't want a server to be abl= e to see that I implement package "foo", but then I have all = these deviations that change its behavior.=C2=A0 Instead, it is really implementing a different package that is based on "foo".

=C2=A0

=C2=A0

The packages draft doesn't includ= e any specific leaf-list for deviations. Section 7.2 mentions that deviations could be expressed by including modules that happen to contain deviations. That seems a bit inconsistent with rfc7895bis that has a specific leaf-list of deviations (and NETCONF hello that specifically explicitly labels deviation modules).

I'm conflicted on this one.=C2= =A0 I don't really like the deviation list in YANG library because I regard it as a duplicate source of information, and then there is a question of which source of data do you trust.=C2=A0 E.g. do you proce= ss a deviation in a module that is not listed in the deviations module list?

[>>JTS: ] Good point. I suppose this issue applies today already. i.e. what if one of the modules advertised in the <hello> is a module of deviations (without having been referenced by another module as a deviation module).

=C2=A0

=C2=A0

Section 5.1 says the package must be referentially complete. I can see the advantages of that although wondering if that might limit flexibility of partitioning modules into packages. I could imagine use cases for dividing a large set of modules into a few packages that might rev independently but can still all work together (especially if they rev in a bc manner). But maybe that just starts to introduce too much complexity?

Yes, having partial packages may be useful.=C2=A0 Perhaps just adding = a leaf to indicate whether a package is referentially complete could be the answer here.

=C2=A0

=C2=A0

I didn't understand this part o= f section 5.1. Can you maybe illustrate with an example?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The version/revision of a module listed in the package module list

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 supercedes any version/revision of the module listed in a imported

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 package module list.=C2=A0 This allows a package to resolve any

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 conflicting implemented module versions/revisions in imported

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 packages.

Probably best to see example B.3. in the appendix because it exactly illustrates this point.

Basically:
1) Packages must explicitly list all versions of all modules they define/import.
2) If two imported packages define different versions of modules, then the package that is importing them needs a way to define which version to use.
3) A package needs a way to override the version of module specified in an imported package.

[>>JTS: ] Thx. That example does help. I suppose the designer of the package needs to carefully check that the version they select can be successfully used by all the modules in the package. =

I think there is a minor typo in example B.3.=C2=A0 The example-3-pkg is importing &quo= t; example-import-1" but I believe you meant "<= /span> example-import-1-pkg" (and some for import-2).=

=C2=A0

It might be a good idea to add a parent-version to the package module (to allow tracking lineage of packages).

Agreed, or maybe allowing a revision history like modules.=C2=A0 Not sure which is better here.=C2=A0 Packages could get a lot of updates, and a long revision history would not be helpful at all.

[>>JTS: ] I think a minimum of just specifying the direct parent is enough to build the full tree of lineage. We don't need a long history of N revisions.

=C2=A0

=C2=A0

I like the use of groupings. That allows a manager to use this as a building block to compose a model that has a list of packages.

OK.

=C2=A0

=C2=A0

Having a global list of mandatory features (vs having the mandatory feature a per-module list) means inventing the new <module-name>:<feature&g= t; format. Should we instead somehow put the mandatory features against each module of the package?

Perhaps.=C2=A0 My thinking here was = to have the list of features high up and very easy to find/parse.

=C2=A0

=C2=A0

The location leaf is a uri but then the description says it must be a url (where the model can be retrieved). I do like that the namespace is separate from the location, but maybe we should make location a url type?<= /p>

Yes, I was thinking that is should be a URL.

=C2=A0

=C2=A0

Do we need a namespace for package names in the model?

I had them in an earlier version, but I took them out, because I wasn't sure that they are really useful/required.

Defining a format to make package names themselves globally unique might be sufficient.

[>>JTS: ] I'm OK with that. It is similar to how we're findin= g that it is useful that YANG module names are globally unique (i.e. by naming with ietf-xxxx or companyabc-xxx).=

=C2=A0

=C2=A0

In 7.3 we only reference module-sets and not modules. So the grouping of modules into sets and packages must be the same?

Not necessarily.

I am trying to reuse the module-set definitions as much as possible (to avoid duplication).=C2= =A0 One issue here is that module-sets are combined then all the modules must not overlap, which doesn't make the mapping to module-sets quite so clean.

=C2=A0

=C2=A0

A schema can only have a single package. I think that works but it means a server would advertise multiple schemas if it wants to support multiple packages. I'm not sure if there are som= e downsides to that (it just surprised me).

My aim here was:
=C2=A0- multiple packages are advertised in yang-library/packages
=C2=A0- datastores only report that they "implement" one [top l= evel] package version.=C2=A0 [The package itself might import other packages.]

If we do package selection, then for a given YANG client session, and the version of YANG library available/reported by that session, it would appear as if the server only implements one top level package for a datastore.=C2=A0 Different clients choosing different versions would see slightly different output depending on which package version they had selected to use.

Thanks again for the review and the comments!

Rob

=C2=A0

=C2=A0

=C2=A0

Jason

=C2=A0

=C2=A0

=C2=A0

From: netmod <netmod-bounces@ietf.org> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: netmod@ietf.org
Subject: [netmod] YANG Packages

=C2=A0

Hi,

I've written up an ID for a potential solution for YANG packages using instance data:

Abstract
=C2=A0
=C2=A0=C2=A0 This document defines YANG packages, an organizationa=
l structure
=C2=A0=C2=A0 holding a set of related YANG modules, that can be us=
ed to simplify
=C2=A0=C2=A0 the conformance and sharing of YANG schema.=C2=A0 It =
describes how YANG
=C2=A0=C2=A0 instance data documents are used to define YANG packa=
ges, and how the
=C2=A0=C2=A0 YANG library information published by a server can be=
 augmented with
=C2=A0=C2=A0 additional packaging related information.

https://= datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/

Potentially this work may be of use as part of the YANG versioning design team work.=C2= =A0 In addition, if the WG likes this approach of defining YANG packages, then it might also be useful to bind a schema to a YANG instance data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs to be solved?

2) Is the approach in this draft of defining these as instance data documents a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not replacing the way that modules are reported in YANG library-bis.=C2= =A0 Is this the right approach?=C2=A0 This approach tries to allow module-sets to be reused for both schema and packages, but the YANG library-bis rules for combining module-sets (i.e. no conflicts) may make this harder to really reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.

Thanks,
Rob

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailm= an/listinfo/netmod
--0000000000007566c80580b3154a-- From nobody Wed Jan 30 16:39:29 2019 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 6C2C5130EBF for ; Wed, 30 Jan 2019 16:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 (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 T4FTkdSHAdRn for ; Wed, 30 Jan 2019 16:39:25 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::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 24725126CC7 for ; Wed, 30 Jan 2019 16:39:25 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id g11-v6so1173005ljk.3 for ; Wed, 30 Jan 2019 16:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=odZCOaW1kfGrds8ZFcCouP/CINU/vEraf3LkDGCNEUQ=; b=xBDHd7vk8W3FHc1QuUI+BGIgLDY5rHfD1XWdwtY5whPTxsS1gS2dr2Ml+imBxCJNyf r1JhTzGeMoTKgv4BTk7FaYyw7YknvqKrj9qj861GQNLx2USpKMvjUo/0WrSJAGgj3jlC cvQuIXN9Z7ZuO8aPEmrJArcWVwzu7EFSVIRpFxVrdHc8JHlSlMzdb9tuy1oAqYsuwo9l 5O3DCYeNCkZpETQvvtAXNzc+9fYYjIIzd4rEa2u3Hj3lCjKILiCUxfNCnWDpOyKumYcn jIF6C+YmtJr9mCslOq0OwEtHTOwga2q/2DYsijMYWEvtkbaWwNtb/hHdS/+2+lLcntJn A0SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=odZCOaW1kfGrds8ZFcCouP/CINU/vEraf3LkDGCNEUQ=; b=N6plbyIuxPCUKqiRJQRH8zKchnVvufyq2orzDf4SWJ+cQQ3sjcwreETAzbVdWfPQ4Y 4q+O7esx2OAw08KLv0ZUvzZ80NyRMobbUT1YdbjLw8zew8wrAvNlUCJpS5LDvzbh4/vA 6saj0Lhi+oMTPSkNXj5LuXjrUdR027BlWYS7q7F6RZWrNq1QojbtLlI445iWrtaNNEiP xN2MqWpzNr6Dnn5mid5Zb8Iaghi1HdrGA9Q3zAstqHTPeUNVPwxu4BxLm6RIhAQ89E9J p6fYMWBY4xzgdIpjmf3xpn6JMDizNM6nmCYQHpLBFjKsGJt5ETnugVpMkX6Ba2WivFk+ Cowg== X-Gm-Message-State: AHQUAuYTlJ29Xm91xz3JPHAxx0BKgvU3Ln8s6nDdNU6tLEgSNkV28JpT 0jIkMgN0sdw81auyWqk3Qe/7uGowCj02eXB9J6hz5nRC X-Google-Smtp-Source: AHgI3IZXEqd/tRL0tiv4Md25RVvhAf6+BXeI2F+qGwsnCVosa7v73h7zFSXuMw7SKbbRhX2QFqxJ8CN0W3jpT9t/TEI= X-Received: by 2002:a2e:9694:: with SMTP id q20-v6mr14409162lji.173.1548895163062; Wed, 30 Jan 2019 16:39:23 -0800 (PST) MIME-Version: 1.0 References: <874l9qjhto.fsf@nic.cz> <20190130.200250.2298112466859908310.mbj@tail-f.com> In-Reply-To: <20190130.200250.2298112466859908310.mbj@tail-f.com> From: Andy Bierman Date: Wed, 30 Jan 2019 16:39:12 -0800 Message-ID: To: Martin Bjorklund Cc: Ladislav Lhotka , NetMod WG Content-Type: multipart/alternative; boundary="000000000000fd2ef20580b6411a" Archived-At: Subject: Re: [netmod] features in import X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 00:39:28 -0000 --000000000000fd2ef20580b6411a Content-Type: text/plain; charset="UTF-8" Hi, I do not agree these changes should be made at this late date. It seems to me that in order to support a feature you have to implement it, and therefore if any features are set then the module is implemented, not imported. All features should be set to false in an import-only module. IMO this interpretation holds for typedef modules like iana-crypt-hash. We list that as implemented (because it is) and the features that are supported are set. Andy On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund wrote: > Hi, > > Ladislav Lhotka wrote: > > Hi, > > > > unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for > > import-only modules. But is it really so that features have no use in > > such modules? > > > > For example, an enum can depend on a feature, and if it is inside a > > typedef, it can also be in an import-only module. What if that feature > > is defined in the same module? > > I think you're right, and that this is an unfortunate omission. > > The fix is simple though; we would have to add the leaf-list features > to import-only. Probably refactor the "feature" leaf-list into a > grouping so it works like the grouping location-leaf-list: > > grouping feature-leaf-list { > leaf-list feature { > type yang:yang-identifier; > description > "List of all YANG feature names from this module that are > supported by the server, regardless whether they are defined > in the module or any included submodule."; > } > } > > And then "uses feature-leaf-list": > > OLD: > > grouping module-implementation-parameters { > description > "Parameters for describing the implementation of a module."; > > leaf-list feature { > type yang:yang-identifier; > description > "List of all YANG feature names from this module that are > supported by the server, regardless whether they are defined > in the module or any included submodule."; > } > > NEW: > > grouping module-implementation-parameters { > description > "Parameters for describing the implementation of a module."; > > uses feature-leaf-list; > > > And in the list "import-only": > > OLD: > > uses location-leaf-list; > > uses feature-leaf-list; > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000fd2ef20580b6411a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I do not agree these changes should= be made at this late date.
It seems to me that in order to suppo= rt a feature you have to implement it,
and therefore if any featu= res are set then the module is implemented, not imported.
All fea= tures should be set to false in an import-only module.

=
IMO this interpretation holds for typedef modules like iana-crypt-hash= .
We list that as implemented (because it is) and the features th= at are supported are set.


Andy

On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

Ladislav Lhotka <lhot= ka@nic.cz> wrote:
> Hi,
>
> unlike RFC 7895, 7895bis doesn't provide the "feature" l= eaf list for
> import-only modules. But is it really so that features have no use in<= br> > such modules?
>
> For example, an enum can depend on a feature, and if it is inside a > typedef, it can also be in an import-only module. What if that feature=
> is defined in the same module?

I think you're right, and that this is an unfortunate omission.

The fix is simple though; we would have to add the leaf-list features
to import-only.=C2=A0 Probably refactor the "feature" leaf-list i= nto a
grouping so it works like the grouping location-leaf-list:

=C2=A0 grouping feature-leaf-list {
=C2=A0 =C2=A0 leaf-list feature {
=C2=A0 =C2=A0 =C2=A0 type yang:yang-identifier;
=C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "List of all YANG feature names from this = module that are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0supported by the server, regardless wheth= er they are defined
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the module or any included submodule.&= quot;;
=C2=A0 =C2=A0 }
=C2=A0 }

And then "uses feature-leaf-list":

OLD:

=C2=A0 grouping module-implementation-parameters {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "Parameters for describing the implementation of = a module.";

=C2=A0 =C2=A0 leaf-list feature {
=C2=A0 =C2=A0 =C2=A0 type yang:yang-identifier;
=C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "List of all YANG feature names from this = module that are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0supported by the server, regardless wheth= er they are defined
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the module or any included submodule.&= quot;;
=C2=A0 =C2=A0 }

NEW:

=C2=A0 grouping module-implementation-parameters {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "Parameters for describing the implementation of = a module.";

=C2=A0 =C2=A0 uses feature-leaf-list;


And in the list "import-only":

OLD:

=C2=A0 =C2=A0 =C2=A0 uses location-leaf-list;

=C2=A0 =C2=A0 =C2=A0 uses feature-leaf-list;



/martin

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000fd2ef20580b6411a-- From nobody Thu Jan 31 00:44:16 2019 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 3BDC1130EB0 for ; Thu, 31 Jan 2019 00:44:14 -0800 (PST) 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 wxhoEefqJJmV for ; Thu, 31 Jan 2019 00:44:12 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BADA6130E99 for ; Thu, 31 Jan 2019 00:44:11 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id E44D81AE0397; Thu, 31 Jan 2019 09:44:08 +0100 (CET) Date: Thu, 31 Jan 2019 09:44:07 +0100 (CET) Message-Id: <20190131.094407.267764793396247491.mbj@tail-f.com> To: andy@yumaworks.com Cc: lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <874l9qjhto.fsf@nic.cz> <20190130.200250.2298112466859908310.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] features in import X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 08:44:14 -0000 Andy Bierman wrote: > Hi, > > I do not agree these changes should be made at this late date. > It seems to me that in order to support a feature you have to implement it, > and therefore if any features are set then the module is implemented, not > imported. But this is not what RFC 7950 says about implement: A server implements a module if it implements the module's data nodes, RPCs, actions, notifications, and deviations. > All features should be set to false in an import-only module. > > IMO this interpretation holds for typedef modules like iana-crypt-hash. > We list that as implemented (because it is) and the features that are > supported are set. If a module consists only of typedefs, there is no problem. Conformance "import" or "import-only" modules exist in YL b/c modules may have a mix of typedefs and data nodes etc. So in the case that Lada brought up, a server would have to list the module as implemented with a certain set of features; and then also deviate all nodes/rpc/notifc etc as 'not-implemented'. /martin > > > Andy > > On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund wrote: > > > Hi, > > > > Ladislav Lhotka wrote: > > > Hi, > > > > > > unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for > > > import-only modules. But is it really so that features have no use in > > > such modules? > > > > > > For example, an enum can depend on a feature, and if it is inside a > > > typedef, it can also be in an import-only module. What if that feature > > > is defined in the same module? > > > > I think you're right, and that this is an unfortunate omission. > > > > The fix is simple though; we would have to add the leaf-list features > > to import-only. Probably refactor the "feature" leaf-list into a > > grouping so it works like the grouping location-leaf-list: > > > > grouping feature-leaf-list { > > leaf-list feature { > > type yang:yang-identifier; > > description > > "List of all YANG feature names from this module that are > > supported by the server, regardless whether they are defined > > in the module or any included submodule."; > > } > > } > > > > And then "uses feature-leaf-list": > > > > OLD: > > > > grouping module-implementation-parameters { > > description > > "Parameters for describing the implementation of a module."; > > > > leaf-list feature { > > type yang:yang-identifier; > > description > > "List of all YANG feature names from this module that are > > supported by the server, regardless whether they are defined > > in the module or any included submodule."; > > } > > > > NEW: > > > > grouping module-implementation-parameters { > > description > > "Parameters for describing the implementation of a module."; > > > > uses feature-leaf-list; > > > > > > And in the list "import-only": > > > > OLD: > > > > uses location-leaf-list; > > > > uses feature-leaf-list; > > > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Thu Jan 31 02:23:37 2019 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 C860E130EDD for ; Thu, 31 Jan 2019 02:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.054 X-Spam-Level: X-Spam-Status: No, score=-19.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 S_T91a74uRGM for ; Thu, 31 Jan 2019 02:23:33 -0800 (PST) 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 29B2D131045 for ; Thu, 31 Jan 2019 02:23:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4379; q=dns/txt; s=iport; t=1548930212; x=1550139812; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=i+zK6eVmdhjyFgZ7eenc5rayngEA8EbMZ9syY1Y2ih0=; b=akPAVQHP4G0hAKPsx3oZLtVwuovARvwRBLusCDaLI8vDv4voawLBPi1x c0vQupd41rWlXuz+3b+TnLTqCgua1yg/jmuv/4D/e+MxgXE4Dw8FoZd0K RvVxxykWTSAdexwTsu8W+MVvugMt4iO3/smXrQRJFPKbdVxcBkua8O2aG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BZAAA7y1Jc/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYJrUAEgEieEA4h5jHQtmgkNGAuEA0YCgy84EgEDAQECAQE?= =?us-ascii?q?CbRwMhUsBAQEDAQEhFTYbCw4KAgImAgInMAYBDAYCAQGDHgGCAQ+sU4EvhUO?= =?us-ascii?q?EagWBC4tMgUA/gTiCa4MeAQGBS4MfglcCkHCRFVwJiw+HIAYZij6Hfoofiji?= =?us-ascii?q?HHYFdIYFWMxoIGxU7gmyCJhiIX4U/PwMwkA0BAQ?= X-IronPort-AV: E=Sophos;i="5.56,543,1539648000"; d="scan'208";a="9722785" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2019 10:23:30 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x0VANTc2016074; Thu, 31 Jan 2019 10:23:29 GMT To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org References: <874l9qjhto.fsf@nic.cz> <20190130.200250.2298112466859908310.mbj@tail-f.com> <20190131.094407.267764793396247491.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Thu, 31 Jan 2019 10:23:29 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190131.094407.267764793396247491.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [netmod] features in import X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 10:23:36 -0000 Hi Martin, Andy, Despite what YANG the language allows, I think that it is much cleaner use of the language to split types/groupings that are expected to be shared by other modules into separate "*_types.yang" modules. I agree with Andy that it is strange to support a feature in a module that is not itself implemented. My hope with YANG library-bis is that most implementations can get by with an empty "import-only-modules" list, and that they can define all modules (including types only modules) in the "module" list of implemented modules. So, I actually think that the workaround using deviations below is OK, because this scenario should be avoidable by having a clean separation between external reusable types and implementable nodes. Thanks, Rob On 31/01/2019 08:44, Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> I do not agree these changes should be made at this late date. >> It seems to me that in order to support a feature you have to implement it, >> and therefore if any features are set then the module is implemented, not >> imported. > But this is not what RFC 7950 says about implement: > > A server implements a module if it implements the module's data > nodes, RPCs, actions, notifications, and deviations. > >> All features should be set to false in an import-only module. >> >> IMO this interpretation holds for typedef modules like iana-crypt-hash. >> We list that as implemented (because it is) and the features that are >> supported are set. > If a module consists only of typedefs, there is no problem. > Conformance "import" or "import-only" modules exist in YL b/c modules > may have a mix of typedefs and data nodes etc. > > So in the case that Lada brought up, a server would have to list the > module as implemented with a certain set of features; and then also > deviate all nodes/rpc/notifc etc as 'not-implemented'. > > > /martin > >> >> Andy >> >> On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund wrote: >> >>> Hi, >>> >>> Ladislav Lhotka wrote: >>>> Hi, >>>> >>>> unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for >>>> import-only modules. But is it really so that features have no use in >>>> such modules? >>>> >>>> For example, an enum can depend on a feature, and if it is inside a >>>> typedef, it can also be in an import-only module. What if that feature >>>> is defined in the same module? >>> I think you're right, and that this is an unfortunate omission. >>> >>> The fix is simple though; we would have to add the leaf-list features >>> to import-only. Probably refactor the "feature" leaf-list into a >>> grouping so it works like the grouping location-leaf-list: >>> >>> grouping feature-leaf-list { >>> leaf-list feature { >>> type yang:yang-identifier; >>> description >>> "List of all YANG feature names from this module that are >>> supported by the server, regardless whether they are defined >>> in the module or any included submodule."; >>> } >>> } >>> >>> And then "uses feature-leaf-list": >>> >>> OLD: >>> >>> grouping module-implementation-parameters { >>> description >>> "Parameters for describing the implementation of a module."; >>> >>> leaf-list feature { >>> type yang:yang-identifier; >>> description >>> "List of all YANG feature names from this module that are >>> supported by the server, regardless whether they are defined >>> in the module or any included submodule."; >>> } >>> >>> NEW: >>> >>> grouping module-implementation-parameters { >>> description >>> "Parameters for describing the implementation of a module."; >>> >>> uses feature-leaf-list; >>> >>> >>> And in the list "import-only": >>> >>> OLD: >>> >>> uses location-leaf-list; >>> >>> uses feature-leaf-list; >>> >>> >>> >>> /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 Thu Jan 31 02:41:08 2019 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 0C49A130ED6 for ; Thu, 31 Jan 2019 02:41:07 -0800 (PST) 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 15BM6z0xTGmO for ; Thu, 31 Jan 2019 02:41:04 -0800 (PST) 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 DDB11130EBA for ; Thu, 31 Jan 2019 02:41:03 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:a744:2697:a0ec:a420]) by mail.nic.cz (Postfix) with ESMTPSA id 1E11F6251F for ; Thu, 31 Jan 2019 11:41:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1548931262; bh=fN/Qu3cKWz8e2h2TfAg3V2dTzbW6SPixM9Xqwfzx/yI=; h=From:To:Date; b=os6S+WJgV66zdhaxlRHmr950XLzV+GXx1y2uJReRYShd+N9V+DLMZsXovmGEChgnS 1ywauUFZiR7KzTQUmi8KNOhiFoOfcWc6KP7/IVRKeSQJFZftx5HVII+ARIgt1en5eT 8gzFFmACR3F+e0GRV1jkcEYKykVs1Gh6Ba+mcvgs= Message-ID: From: Ladislav Lhotka To: netmod@ietf.org Date: Thu, 31 Jan 2019 11:41:01 +0100 In-Reply-To: References: <874l9qjhto.fsf@nic.cz> <20190130.200250.2298112466859908310.mbj@tail-f.com> <20190131.094407.267764793396247491.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.4 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] features in import X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 10:41:07 -0000 On Thu, 2019-01-31 at 10:23 +0000, Robert Wilton wrote: > Hi Martin, Andy, > > Despite what YANG the language allows, I think that it is much cleaner > use of the language to split types/groupings that are expected to be > shared by other modules into separate "*_types.yang" modules. But it is not always the case. For example, ietf-routing has a couple of groupings and typedefs that may be useful for other purposes. Another potential issue is that multiple revisions of import-only modules may be used while only one revision is permitted for implemented modules. Such problems may not be very common but, on the other hand, it may be worth fixing before 7895bis becomes an RFC. Lada > > I agree with Andy that it is strange to support a feature in a module > that is not itself implemented. > > My hope with YANG library-bis is that most implementations can get by > with an empty "import-only-modules" list, and that they can define all > modules (including types only modules) in the "module" list of > implemented modules. > > So, I actually think that the workaround using deviations below is OK, > because this scenario should be avoidable by having a clean separation > between external reusable types and implementable nodes. > > Thanks, > Rob > > > On 31/01/2019 08:44, Martin Bjorklund wrote: > > Andy Bierman wrote: > > > Hi, > > > > > > I do not agree these changes should be made at this late date. > > > It seems to me that in order to support a feature you have to implement > > > it, > > > and therefore if any features are set then the module is implemented, not > > > imported. > > But this is not what RFC 7950 says about implement: > > > > A server implements a module if it implements the module's data > > nodes, RPCs, actions, notifications, and deviations. > > > > > All features should be set to false in an import-only module. > > > > > > IMO this interpretation holds for typedef modules like iana-crypt-hash. > > > We list that as implemented (because it is) and the features that are > > > supported are set. > > If a module consists only of typedefs, there is no problem. > > Conformance "import" or "import-only" modules exist in YL b/c modules > > may have a mix of typedefs and data nodes etc. > > > > So in the case that Lada brought up, a server would have to list the > > module as implemented with a certain set of features; and then also > > deviate all nodes/rpc/notifc etc as 'not-implemented'. > > > > > > /martin > > > > > Andy > > > > > > On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund wrote: > > > > > > > Hi, > > > > > > > > Ladislav Lhotka wrote: > > > > > Hi, > > > > > > > > > > unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for > > > > > import-only modules. But is it really so that features have no use in > > > > > such modules? > > > > > > > > > > For example, an enum can depend on a feature, and if it is inside a > > > > > typedef, it can also be in an import-only module. What if that feature > > > > > is defined in the same module? > > > > I think you're right, and that this is an unfortunate omission. > > > > > > > > The fix is simple though; we would have to add the leaf-list features > > > > to import-only. Probably refactor the "feature" leaf-list into a > > > > grouping so it works like the grouping location-leaf-list: > > > > > > > > grouping feature-leaf-list { > > > > leaf-list feature { > > > > type yang:yang-identifier; > > > > description > > > > "List of all YANG feature names from this module that are > > > > supported by the server, regardless whether they are defined > > > > in the module or any included submodule."; > > > > } > > > > } > > > > > > > > And then "uses feature-leaf-list": > > > > > > > > OLD: > > > > > > > > grouping module-implementation-parameters { > > > > description > > > > "Parameters for describing the implementation of a module."; > > > > > > > > leaf-list feature { > > > > type yang:yang-identifier; > > > > description > > > > "List of all YANG feature names from this module that are > > > > supported by the server, regardless whether they are defined > > > > in the module or any included submodule."; > > > > } > > > > > > > > NEW: > > > > > > > > grouping module-implementation-parameters { > > > > description > > > > "Parameters for describing the implementation of a module."; > > > > > > > > uses feature-leaf-list; > > > > > > > > > > > > And in the list "import-only": > > > > > > > > OLD: > > > > > > > > uses location-leaf-list; > > > > > > > > uses feature-leaf-list; > > > > > > > > > > > > > > > > /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 > > . > > > > _______________________________________________ > 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 Jan 31 02:46:33 2019 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 1371A130EBA for ; Thu, 31 Jan 2019 02:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 (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 Rs9b1TYabw7d for ; Thu, 31 Jan 2019 02:46:29 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 1AB84128CE4 for ; Thu, 31 Jan 2019 02:46:29 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id l10so1925240lfh.9 for ; Thu, 31 Jan 2019 02:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U+qzgTw1/2F4TZM7fhpI1gepIjxDrTyIoC3LFalvgTM=; b=C0PKTdtN1RjKC+7fMavRubGO6seDmnDm+7OWyDX7Pp6A0VN99B3Qygi8HrmQTTz/qH i/Zd2B7RfSwcYxBJkozMb5D4czbGkc8CfNJqD60vVIpq9oigZLZmOQbeDEm64HZXcOih 5CR/nJRpuGNlrX/3GsILVIzMB8n+WA7VJa36Xg2N/CP54wMfv+zAEXwBbNP9yozW+F+y d28hXse5AXgszlTWl+pRGmeaafb044OA+/ssbDEGMdfie2o/HQFYiZGLJFqxVa/BQ8Mm YafttJtYokHvwJFJpxcNwOJGVmX+J9h1nfOTGnTwQ+myQj9G2/J3tRjcqcG764+7kILo sGoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U+qzgTw1/2F4TZM7fhpI1gepIjxDrTyIoC3LFalvgTM=; b=COjpj5IJTXJ8Jc/ACOJhFkalhtBjNC+7zdCZFEa6NXjEf6kaOzEgIfKYO6ioiOn6J+ 7kNXLdNFYqxim3PlHDEXP/LOif+lwELESwLLEkAtXTznPT70dYGABTbwSVeSqm/sDreL uu0JS7dm8s5Wdv3Sjz6CAciBAGZAmGk5x2dSgrGTpIxR0/NEJGfBmZNA1AExBxKkmnjU Od2w9P9tx4aD6CxaigLBuYQAGAAZKy30wLWfp8C6mJp8JHpoxR3aDuu3FMYjRrp+/e+0 pARqDKyTYt3y+0Ln8EqznLibNA/1TL0lEQd1Q8hjappjmi7Ptx/CxyBku12gr1gqnWXo WIpw== X-Gm-Message-State: AJcUukc/4rg6O/EYH3Bs0FGZIXpkIU9psPVT1gKfusrOuBPi/TxuWpG4 CnUsDczE2wOH6l/OpXT0XtyrtPBiB3vpzP4muJJPKETf X-Google-Smtp-Source: ALg8bN7xHvdX6QC5j2ee0irTraXkmXiY+V2G9Bu1Dni2QKHlKvSzLgcWomt8KFXYk3lrYoGqregniKbz6nhJHAOlnJ4= X-Received: by 2002:a19:40cc:: with SMTP id n195mr26325168lfa.40.1548931586992; Thu, 31 Jan 2019 02:46:26 -0800 (PST) MIME-Version: 1.0 References: <874l9qjhto.fsf@nic.cz> <20190130.200250.2298112466859908310.mbj@tail-f.com> <20190131.094407.267764793396247491.mbj@tail-f.com> In-Reply-To: <20190131.094407.267764793396247491.mbj@tail-f.com> From: Andy Bierman Date: Thu, 31 Jan 2019 02:46:15 -0800 Message-ID: To: Martin Bjorklund Cc: Ladislav Lhotka , NetMod WG Content-Type: multipart/alternative; boundary="0000000000000645a90580bebd4f" Archived-At: Subject: Re: [netmod] features in import X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 10:46:32 -0000 --0000000000000645a90580bebd4f Content-Type: text/plain; charset="UTF-8" On Thu, Jan 31, 2019 at 12:44 AM Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I do not agree these changes should be made at this late date. > > It seems to me that in order to support a feature you have to implement > it, > > and therefore if any features are set then the module is implemented, not > > imported. > > But this is not what RFC 7950 says about implement: > > A server implements a module if it implements the module's data > nodes, RPCs, actions, notifications, and deviations. > > > All features should be set to false in an import-only module. > > > > IMO this interpretation holds for typedef modules like iana-crypt-hash. > > We list that as implemented (because it is) and the features that are > > supported are set. > > If a module consists only of typedefs, there is no problem. > Conformance "import" or "import-only" modules exist in YL b/c modules > may have a mix of typedefs and data nodes etc. > > So in the case that Lada brought up, a server would have to list the > module as implemented with a certain set of features; and then also > deviate all nodes/rpc/notifc etc as 'not-implemented'. > > So what. Using deviate(not-supported) to cherry-pick what you want to implement out of a module is how it is supposed to work. A server has to implement a feature to advertise it. Therefore the module containing the feature cannot be import-only. > /martin > > Andy > > > > > > Andy > > > > On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund > wrote: > > > > > Hi, > > > > > > Ladislav Lhotka wrote: > > > > Hi, > > > > > > > > unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for > > > > import-only modules. But is it really so that features have no use in > > > > such modules? > > > > > > > > For example, an enum can depend on a feature, and if it is inside a > > > > typedef, it can also be in an import-only module. What if that > feature > > > > is defined in the same module? > > > > > > I think you're right, and that this is an unfortunate omission. > > > > > > The fix is simple though; we would have to add the leaf-list features > > > to import-only. Probably refactor the "feature" leaf-list into a > > > grouping so it works like the grouping location-leaf-list: > > > > > > grouping feature-leaf-list { > > > leaf-list feature { > > > type yang:yang-identifier; > > > description > > > "List of all YANG feature names from this module that are > > > supported by the server, regardless whether they are defined > > > in the module or any included submodule."; > > > } > > > } > > > > > > And then "uses feature-leaf-list": > > > > > > OLD: > > > > > > grouping module-implementation-parameters { > > > description > > > "Parameters for describing the implementation of a module."; > > > > > > leaf-list feature { > > > type yang:yang-identifier; > > > description > > > "List of all YANG feature names from this module that are > > > supported by the server, regardless whether they are defined > > > in the module or any included submodule."; > > > } > > > > > > NEW: > > > > > > grouping module-implementation-parameters { > > > description > > > "Parameters for describing the implementation of a module."; > > > > > > uses feature-leaf-list; > > > > > > > > > And in the list "import-only": > > > > > > OLD: > > > > > > uses location-leaf-list; > > > > > > uses feature-leaf-list; > > > > > > > > > > > > /martin > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > --0000000000000645a90580bebd4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 31, 2019 at 12:44 AM Mart= in Bjorklund <mbj@tail-f.com> w= rote:
Andy Bierm= an <andy@yumawor= ks.com> wrote:
> Hi,
>
> I do not agree these changes should be made at this late date.
> It seems to me that in order to support a feature you have to implemen= t it,
> and therefore if any features are set then the module is implemented, = not
> imported.

But this is not what RFC 7950 says about implement:

=C2=A0 =C2=A0A server implements a module if it implements the module's= data
=C2=A0 =C2=A0nodes, RPCs, actions, notifications, and deviations.

> All features should be set to false in an import-only module.
>
> IMO this interpretation holds for typedef modules like iana-crypt-hash= .
> We list that as implemented (because it is) and the features that are<= br> > supported are set.

If a module consists only of typedefs, there is no problem.
Conformance "import" or "import-only" modules exist in = YL b/c modules
may have a mix of typedefs and data nodes etc.

So in the case that Lada brought up, a server would have to list the
module as implemented with a certain set of features; and then also
deviate all nodes/rpc/notifc etc as 'not-implemented'.


So what. Using deviate(not-supported) = to cherry-pick what you want to implement
out of a module is how = it is supposed to work.

A server has to implement = a feature to advertise it.
Therefore the module containing the fe= ature cannot be import-only.



/martin


Andy
=C2=A0
>
>
> Andy
>
> On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Hi,
> >
> > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > Hi,
> > >
> > > unlike RFC 7895, 7895bis doesn't provide the "featu= re" leaf list for
> > > import-only modules. But is it really so that features have = no use in
> > > such modules?
> > >
> > > For example, an enum can depend on a feature, and if it is i= nside a
> > > typedef, it can also be in an import-only module. What if th= at feature
> > > is defined in the same module?
> >
> > I think you're right, and that this is an unfortunate omissio= n.
> >
> > The fix is simple though; we would have to add the leaf-list feat= ures
> > to import-only.=C2=A0 Probably refactor the "feature" l= eaf-list into a
> > grouping so it works like the grouping location-leaf-list:
> >
> >=C2=A0 =C2=A0grouping feature-leaf-list {
> >=C2=A0 =C2=A0 =C2=A0leaf-list feature {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type yang:yang-identifier;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"List of all YANG feature n= ames from this module that are
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 supported by the server, regard= less whether they are defined
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the module or any included s= ubmodule.";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> > And then "uses feature-leaf-list":
> >
> > OLD:
> >
> >=C2=A0 =C2=A0grouping module-implementation-parameters {
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Parameters for describing the imp= lementation of a module.";
> >
> >=C2=A0 =C2=A0 =C2=A0leaf-list feature {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type yang:yang-identifier;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"List of all YANG feature n= ames from this module that are
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 supported by the server, regard= less whether they are defined
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the module or any included s= ubmodule.";
> >=C2=A0 =C2=A0 =C2=A0}
> >
> > NEW:
> >
> >=C2=A0 =C2=A0grouping module-implementation-parameters {
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Parameters for describing the imp= lementation of a module.";
> >
> >=C2=A0 =C2=A0 =C2=A0uses feature-leaf-list;
> >
> >
> > And in the list "import-only":
> >
> > OLD:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0uses location-leaf-list;
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0uses feature-leaf-list;
> >
> >
> >
> > /martin
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.= org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
--0000000000000645a90580bebd4f-- From nobody Thu Jan 31 02:58:40 2019 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 EFD42128CE4 for ; Thu, 31 Jan 2019 02:58:33 -0800 (PST) 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 VzfsZcpD9wMJ for ; Thu, 31 Jan 2019 02:58:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9064A130EBA for ; Thu, 31 Jan 2019 02:58:31 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 1042F1AE0397; Thu, 31 Jan 2019 11:58:29 +0100 (CET) Date: Thu, 31 Jan 2019 11:58:28 +0100 (CET) Message-Id: <20190131.115828.2130777685875370834.mbj@tail-f.com> To: andy@yumaworks.com Cc: lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190131.094407.267764793396247491.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] features in import X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 10:58:34 -0000 Andy Bierman wrote: > On Thu, Jan 31, 2019 at 12:44 AM Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > Hi, > > > > > > I do not agree these changes should be made at this late date. > > > It seems to me that in order to support a feature you have to implement > > it, > > > and therefore if any features are set then the module is implemented, not > > > imported. > > > > But this is not what RFC 7950 says about implement: > > > > A server implements a module if it implements the module's data > > nodes, RPCs, actions, notifications, and deviations. > > > > > All features should be set to false in an import-only module. > > > > > > IMO this interpretation holds for typedef modules like iana-crypt-hash. > > > We list that as implemented (because it is) and the features that are > > > supported are set. > > > > If a module consists only of typedefs, there is no problem. > > Conformance "import" or "import-only" modules exist in YL b/c modules > > may have a mix of typedefs and data nodes etc. > > > > So in the case that Lada brought up, a server would have to list the > > module as implemented with a certain set of features; and then also > > deviate all nodes/rpc/notifc etc as 'not-implemented'. > > > > > So what. Using deviate(not-supported) to cherry-pick what you want to > implement > out of a module is how it is supposed to work. > > A server has to implement a feature to advertise it. As per 7950, this is not true, as I pointed out earlier. Note that with current YL (RFC 7895), it *is* in fact possible to handle this case; you can list the features supported for an import-only module. The new YL removes this possibility (by mistake). /martin > Therefore the module containing the feature cannot be import-only. > > > > > /martin > > > > > Andy > > > > > > > > > > > Andy > > > > > > On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund > > wrote: > > > > > > > Hi, > > > > > > > > Ladislav Lhotka wrote: > > > > > Hi, > > > > > > > > > > unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for > > > > > import-only modules. But is it really so that features have no use in > > > > > such modules? > > > > > > > > > > For example, an enum can depend on a feature, and if it is inside a > > > > > typedef, it can also be in an import-only module. What if that > > feature > > > > > is defined in the same module? > > > > > > > > I think you're right, and that this is an unfortunate omission. > > > > > > > > The fix is simple though; we would have to add the leaf-list features > > > > to import-only. Probably refactor the "feature" leaf-list into a > > > > grouping so it works like the grouping location-leaf-list: > > > > > > > > grouping feature-leaf-list { > > > > leaf-list feature { > > > > type yang:yang-identifier; > > > > description > > > > "List of all YANG feature names from this module that are > > > > supported by the server, regardless whether they are defined > > > > in the module or any included submodule."; > > > > } > > > > } > > > > > > > > And then "uses feature-leaf-list": > > > > > > > > OLD: > > > > > > > > grouping module-implementation-parameters { > > > > description > > > > "Parameters for describing the implementation of a module."; > > > > > > > > leaf-list feature { > > > > type yang:yang-identifier; > > > > description > > > > "List of all YANG feature names from this module that are > > > > supported by the server, regardless whether they are defined > > > > in the module or any included submodule."; > > > > } > > > > > > > > NEW: > > > > > > > > grouping module-implementation-parameters { > > > > description > > > > "Parameters for describing the implementation of a module."; > > > > > > > > uses feature-leaf-list; > > > > > > > > > > > > And in the list "import-only": > > > > > > > > OLD: > > > > > > > > uses location-leaf-list; > > > > > > > > uses feature-leaf-list; > > > > > > > > > > > > > > > > /martin > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > From nobody Thu Jan 31 03:04:23 2019 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 2C52F130EBB for ; Thu, 31 Jan 2019 03:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.054 X-Spam-Level: X-Spam-Status: No, score=-19.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 bgldwL96W445 for ; Thu, 31 Jan 2019 03:04:19 -0800 (PST) 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 6AF8A128CE4 for ; Thu, 31 Jan 2019 03:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6768; q=dns/txt; s=iport; t=1548932659; x=1550142259; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=jlumtYsyQNZCdiSpoGm+dOVTLs6bqqIu3m7qec+kLv8=; b=V7sm7slw6wuMQWQnAHSRI0UNwEkEccVjVIajjBJc5grIvdxk95FwoD0v bKsBpEK9Iz99XY13jDgQGqhGKC/W6uq+xuL1DDDrrItYJsTXGGtp53loA +Aof7SMD3uWd95OQuCt89wfORO0B/gTDgkrueC+BRNXxrgP7ZoPa0KuQJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BZAADG1VJc/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYJrUAEgEieEA4h5jHQIJZoJDRgLhANGAoMvOBIBAwEBAgE?= =?us-ascii?q?BAm0cDIVKAQEBAQIBAQEhDwEFNhsLGAICJgICJzAGAQwGAgEBgx4BgXkID6x?= =?us-ascii?q?LgS+FQ4RqBYELi0yBQD+BOAyBYX6DHgEBgUuDH4JXAolxMpdiXAmLD4cgBhm?= =?us-ascii?q?Ba4U9gxaHfoofijiHHYFdIYFWMxoIGxU7gmyCJhiIX4U/PwMwkA0BAQ?= X-IronPort-AV: E=Sophos;i="5.56,544,1539648000"; d="scan'208";a="9723495" 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; 31 Jan 2019 11:04:17 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x0VB4GYV016277; Thu, 31 Jan 2019 11:04:16 GMT To: Ladislav Lhotka , netmod@ietf.org References: <874l9qjhto.fsf@nic.cz> <20190130.200250.2298112466859908310.mbj@tail-f.com> <20190131.094407.267764793396247491.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Thu, 31 Jan 2019 11:04:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] features in import X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 11:04:22 -0000 Hi Lada, Please see inline ... On 31/01/2019 10:41, Ladislav Lhotka wrote: > On Thu, 2019-01-31 at 10:23 +0000, Robert Wilton wrote: >> Hi Martin, Andy, >> >> Despite what YANG the language allows, I think that it is much cleaner >> use of the language to split types/groupings that are expected to be >> shared by other modules into separate "*_types.yang" modules. > But it is not always the case. For example, ietf-routing has a couple of > groupings and typedefs that may be useful for other purposes. In this case, it would be better for the groupings and types to be in ietf-routing-types.yang instead. OK, that has already been published, so "import-only-modules" can be used. But if you have a module that: (i) have external typedefs/groupings not in "*_types.yang" module, and (ii) the server doesn't actually implement that module, and (iii) some of the types/grouping depend on features, then (iv) the module could still be "implemented" and deviated. I'm just not sure how many modules/implementations will really fit into this category.  Are we increasing the complexity of YANG to handle an obscure corner case?  Do all servers/clients handle import-only feature handling? > > Another potential issue is that multiple revisions of import-only modules may be > used while only one revision is permitted for implemented modules. I'm not convinced that we really want to encourage multiple versions of the same typedef floating around for a given schema. For me, the import-by-revision that we have today, is potentially most useful if a module wants to pull in a specific definition of a grouping.  Possibly it seems like it might have been helpful if the YANG import statement could have restricted what types of symbols it was actually importing or dependent on. > > Such problems may not be very common but, on the other hand, it may be worth > fixing before 7895bis becomes an RFC. I'm not arguing against allowing import-only features because of the 7895bis timeline.  I'm arguing against them because I'm not sure that they are worth the extra complexity. Thanks, Rob > > Lada > >> I agree with Andy that it is strange to support a feature in a module >> that is not itself implemented. >> >> My hope with YANG library-bis is that most implementations can get by >> with an empty "import-only-modules" list, and that they can define all >> modules (including types only modules) in the "module" list of >> implemented modules. >> >> So, I actually think that the workaround using deviations below is OK, >> because this scenario should be avoidable by having a clean separation >> between external reusable types and implementable nodes. >> >> Thanks, >> Rob >> >> >> On 31/01/2019 08:44, Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> I do not agree these changes should be made at this late date. >>>> It seems to me that in order to support a feature you have to implement >>>> it, >>>> and therefore if any features are set then the module is implemented, not >>>> imported. >>> But this is not what RFC 7950 says about implement: >>> >>> A server implements a module if it implements the module's data >>> nodes, RPCs, actions, notifications, and deviations. >>> >>>> All features should be set to false in an import-only module. >>>> >>>> IMO this interpretation holds for typedef modules like iana-crypt-hash. >>>> We list that as implemented (because it is) and the features that are >>>> supported are set. >>> If a module consists only of typedefs, there is no problem. >>> Conformance "import" or "import-only" modules exist in YL b/c modules >>> may have a mix of typedefs and data nodes etc. >>> >>> So in the case that Lada brought up, a server would have to list the >>> module as implemented with a certain set of features; and then also >>> deviate all nodes/rpc/notifc etc as 'not-implemented'. >>> >>> >>> /martin >>> >>>> Andy >>>> >>>> On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund wrote: >>>> >>>>> Hi, >>>>> >>>>> Ladislav Lhotka wrote: >>>>>> Hi, >>>>>> >>>>>> unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for >>>>>> import-only modules. But is it really so that features have no use in >>>>>> such modules? >>>>>> >>>>>> For example, an enum can depend on a feature, and if it is inside a >>>>>> typedef, it can also be in an import-only module. What if that feature >>>>>> is defined in the same module? >>>>> I think you're right, and that this is an unfortunate omission. >>>>> >>>>> The fix is simple though; we would have to add the leaf-list features >>>>> to import-only. Probably refactor the "feature" leaf-list into a >>>>> grouping so it works like the grouping location-leaf-list: >>>>> >>>>> grouping feature-leaf-list { >>>>> leaf-list feature { >>>>> type yang:yang-identifier; >>>>> description >>>>> "List of all YANG feature names from this module that are >>>>> supported by the server, regardless whether they are defined >>>>> in the module or any included submodule."; >>>>> } >>>>> } >>>>> >>>>> And then "uses feature-leaf-list": >>>>> >>>>> OLD: >>>>> >>>>> grouping module-implementation-parameters { >>>>> description >>>>> "Parameters for describing the implementation of a module."; >>>>> >>>>> leaf-list feature { >>>>> type yang:yang-identifier; >>>>> description >>>>> "List of all YANG feature names from this module that are >>>>> supported by the server, regardless whether they are defined >>>>> in the module or any included submodule."; >>>>> } >>>>> >>>>> NEW: >>>>> >>>>> grouping module-implementation-parameters { >>>>> description >>>>> "Parameters for describing the implementation of a module."; >>>>> >>>>> uses feature-leaf-list; >>>>> >>>>> >>>>> And in the list "import-only": >>>>> >>>>> OLD: >>>>> >>>>> uses location-leaf-list; >>>>> >>>>> uses feature-leaf-list; >>>>> >>>>> >>>>> >>>>> /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 >>> . >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jan 31 03:13:48 2019 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 45069130EBB for ; Thu, 31 Jan 2019 03:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.054 X-Spam-Level: X-Spam-Status: No, score=-19.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 zybPw9iSHtdJ for ; Thu, 31 Jan 2019 03:13:44 -0800 (PST) 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 07EDE128CE4 for ; Thu, 31 Jan 2019 03:13:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4742; q=dns/txt; s=iport; t=1548933224; x=1550142824; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=QsFi6BJVCana+yCn/S8put4r9GvtRnZ0c9X9cRTDmLk=; b=Weawr4qqNRnMsqEMCnh4drQpM6saJ1oWfds19+1pSGcq5Q+eN7GWpnd9 oraL1DlAuhf6CPaU6l1i+vnNMtTgqVlrGL55GhveX/dX70O8HdbZJRV5R lAPdu5OKKMTZF14/r60LT+y0O7qI8xbdZOaIkvKy6Q0wc3YZa//Qf/B3E w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAADW11Jc/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYFWgRVQASASJ4QDiHmMdAglmgkNGAuEA0YCgy84EgE?= =?us-ascii?q?DAQECAQECbRwMhUsBAQEDAQEhFTYLEAsOCgICJgICJzAGAQwGAgEBgx4BggE?= =?us-ascii?q?PrEiBL4VDhGoFgQuLTIFAP4E4DIJfgx4BAYFLgx+CVwKJcYZ/kRVcCYsPhyA?= =?us-ascii?q?GGYo+h36KH4o4hx2BXSGBVjMaCBsVO4JsgiYYiF+FPz8DMJANAQE?= X-IronPort-AV: E=Sophos;i="5.56,544,1539648000"; d="scan'208";a="9722223" 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; 31 Jan 2019 11:13:41 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x0VBDfLh028626; Thu, 31 Jan 2019 11:13:41 GMT To: Martin Bjorklund , andy@yumaworks.com Cc: netmod@ietf.org References: <20190131.094407.267764793396247491.mbj@tail-f.com> <20190131.115828.2130777685875370834.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Thu, 31 Jan 2019 11:13:41 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190131.115828.2130777685875370834.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] features in import X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 11:13:46 -0000 On 31/01/2019 10:58, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Thu, Jan 31, 2019 at 12:44 AM Martin Bjorklund wrote: >> >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> I do not agree these changes should be made at this late date. >>>> It seems to me that in order to support a feature you have to implement >>> it, >>>> and therefore if any features are set then the module is implemented, not >>>> imported. >>> But this is not what RFC 7950 says about implement: >>> >>> A server implements a module if it implements the module's data >>> nodes, RPCs, actions, notifications, and deviations. >>> >>>> All features should be set to false in an import-only module. >>>> >>>> IMO this interpretation holds for typedef modules like iana-crypt-hash. >>>> We list that as implemented (because it is) and the features that are >>>> supported are set. >>> If a module consists only of typedefs, there is no problem. >>> Conformance "import" or "import-only" modules exist in YL b/c modules >>> may have a mix of typedefs and data nodes etc. >>> >>> So in the case that Lada brought up, a server would have to list the >>> module as implemented with a certain set of features; and then also >>> deviate all nodes/rpc/notifc etc as 'not-implemented'. >>> >>> >> So what. Using deviate(not-supported) to cherry-pick what you want to >> implement >> out of a module is how it is supposed to work. >> >> A server has to implement a feature to advertise it. > As per 7950, this is not true, as I pointed out earlier. > > Note that with current YL (RFC 7895), it *is* in fact possible to > handle this case; you can list the features supported for an > import-only module. The new YL removes this possibility (by > mistake). This presumably also means that clients/servers also have to handle the fact that different features can be advertised for each revision of an import-only module that has been imported. Thanks, Rob > > > /martin > > >> Therefore the module containing the feature cannot be import-only. >> >> >> >>> /martin >>> >>> >> Andy >> >> >>>> >>>> Andy >>>> >>>> On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund >>> wrote: >>>>> Hi, >>>>> >>>>> Ladislav Lhotka wrote: >>>>>> Hi, >>>>>> >>>>>> unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for >>>>>> import-only modules. But is it really so that features have no use in >>>>>> such modules? >>>>>> >>>>>> For example, an enum can depend on a feature, and if it is inside a >>>>>> typedef, it can also be in an import-only module. What if that >>> feature >>>>>> is defined in the same module? >>>>> I think you're right, and that this is an unfortunate omission. >>>>> >>>>> The fix is simple though; we would have to add the leaf-list features >>>>> to import-only. Probably refactor the "feature" leaf-list into a >>>>> grouping so it works like the grouping location-leaf-list: >>>>> >>>>> grouping feature-leaf-list { >>>>> leaf-list feature { >>>>> type yang:yang-identifier; >>>>> description >>>>> "List of all YANG feature names from this module that are >>>>> supported by the server, regardless whether they are defined >>>>> in the module or any included submodule."; >>>>> } >>>>> } >>>>> >>>>> And then "uses feature-leaf-list": >>>>> >>>>> OLD: >>>>> >>>>> grouping module-implementation-parameters { >>>>> description >>>>> "Parameters for describing the implementation of a module."; >>>>> >>>>> leaf-list feature { >>>>> type yang:yang-identifier; >>>>> description >>>>> "List of all YANG feature names from this module that are >>>>> supported by the server, regardless whether they are defined >>>>> in the module or any included submodule."; >>>>> } >>>>> >>>>> NEW: >>>>> >>>>> grouping module-implementation-parameters { >>>>> description >>>>> "Parameters for describing the implementation of a module."; >>>>> >>>>> uses feature-leaf-list; >>>>> >>>>> >>>>> And in the list "import-only": >>>>> >>>>> OLD: >>>>> >>>>> uses location-leaf-list; >>>>> >>>>> uses feature-leaf-list; >>>>> >>>>> >>>>> >>>>> /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 Thu Jan 31 06:01:07 2019 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 E6B6F130F24 for ; Thu, 31 Jan 2019 06:01:01 -0800 (PST) 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 a4j_CGWm1ULS for ; Thu, 31 Jan 2019 06:00:59 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5D62E130F1B for ; Thu, 31 Jan 2019 06:00:57 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id 2870A18205E8; Thu, 31 Jan 2019 15:00:48 +0100 (CET) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 2BA681820186; Thu, 31 Jan 2019 15:00:45 +0100 (CET) From: Ladislav Lhotka To: Robert Wilton , netmod@ietf.org In-Reply-To: References: <877eemjj2g.fsf@nic.cz> Mail-Followup-To: Robert Wilton , netmod@ietf.org Date: Thu, 31 Jan 2019 15:00:53 +0100 Message-ID: <87zhrhncyy.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] LL comments on draft-rwilton-netmod-yang-packages-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 14:01:05 -0000 Robert Wilton writes: > Hi Lada, > > Thanks for the review and comments ... > > I've added some thoughts inline ... > > On 30/01/2019 14:50, Ladislav Lhotka wrote: >> Hi, >> >> I think it is a good start, here are my comments (some of them were >> already raised by Jason): >> >> - I like the fact that this work doesn't require any changes to YANG, >> except perhaps semver. > > RW: OK. > > >> >> - I think the augments to YANG library is a separate problem that should >> perhaps be addressed in a different document. Servers supporting >> multiple package revisions may not be that common. > > RW: > > I completely agree that servers supporting multiple package revisions=20 > may not be that common, and I agree that any specification on how a=20 > server could support multiple packages, and perform package selection=20 > should be in a separate draft. > > But the YANG library augmentations aren't there only to support this use= =20 > case.=C2=A0 My intention is to make it easier for devices to advertise a= =20 > package representing what each datastore schema is rather than having to= =20 > fetch the full contents of YANG library. > > E.g. a server might implement 900+ modules/sub-modules for a given=20 > release.=C2=A0 Different hardware will mostly implement the same modules,= but=20 > there might be some differences.=C2=A0 If bugs have been patched then the= re=20 > might be some differences.=C2=A0 I'm aiming for a solution where a client= =20 > doesn't have to fetch the full list of YANG modules for each server to=20 > figure out the schema for the device, which is probably the same as=20 > another 1000 devices in the network. > > Instead, I would like the vendor to publish a package for that=20 > particular release, with variants depending on the hardware.=C2=A0 The de= vice=20 > can then advertise that it uses that base package, along with the small=20 > set of differences (e.g. due to bug fixes). > OK, I missed this purpose. Perhaps one of the examples can be expanded to illustrate this situation. But doesn't it defeat the purpose of packages? Even if I know that my client works with package X, it needn't be the case with the vendor's changes. > >> >> - I was expecting that a package could specify a range of revisions for >> some modules that may be used together with teh others. This doesn't >> seem to be the case. If so, it would be somewhat unwieldy because eve= ry >> combination of module revisions would require a separate package >> revision. > > RW: > > Yes, this is an interesting point. > > My intention is that there is a roughly linear history of package=20 > versions.=C2=A0 E.g. if there was a package of all IETF modules, then eve= ry=20 > time a new version of an IETF module is published, the package=20 > definition would be updated to a new version that includes the new=20 > published module revision. I think that we need to try and somewhat=20 > constraint the versions of modules that can sensibly be used together. > With semver, would it make sense to be able to specify only a major version number of a module? The "yang-sem-ver" type requires the complete version number. > >> >> - As Jason pointed out, there seems to be no use for the package >> namespace, as packages don't define any names on their own. > > Yes, I will remove the text about namespaces.=C2=A0 Globally unique packa= ge=20 > names should be sufficient. > > >> >> - I would also prefer mandatory-features to be bundled with each >> module. >> >> - This draft nicely shows that there is really no need for any >> "yang-data" extensions. But I also don't see any benefit from using >> ietf-yang-instance-data in this case. It would IMO be perfectly fine >> to get rid of two levels of data hierarchy: >> >> { "ietf-yang-package:yang-package": { >> ... >> } >> } > > That's an interesting point.=C2=A0 My thought is that all at rest YANG da= ta=20 > would be encoded in YANG instance data documents to make them more=20 > easily machine parse-able. I don't see how the two extra levels make the JSON more easy to parse. If we want to have some standard metadata for inclusion in standalone instance document, it would be probably better to define the metadata as a grouping that can be used right under "ietf-yang-package:yang-package". In the DSDL schemas (RFC 6110) we used Dublin Core metadata for a similar purpose. Lada > > Thanks, > Rob > > >> >> Thanks, Lada >> >> > > _______________________________________________ > 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 Thu Jan 31 07:32:38 2019 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 5938E12958B for ; Thu, 31 Jan 2019 07:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 (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 gODcRkjvHysf for ; Thu, 31 Jan 2019 07:32:34 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 20CCC1286D9 for ; Thu, 31 Jan 2019 07:32:34 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id x85-v6so3060990ljb.2 for ; Thu, 31 Jan 2019 07:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q1999hFGtd7wlQzoxu6O/30ANn8Wl2FLG3Zs6Mbus4I=; b=DHN8yc2aRGyacSm81569KArsLDW39POel+o4dY9yzvW2Yk4G71c2x5Xa3WLt7JPB7j x+V5jN/JZ47J418LdkxV5XsojL5tuMMGlnfwOuzJjRsrNu/Rykb8o/ruo/2uNbRYpJNG 9oRzhxbJAUeBJ5K4uJT81O9mP0jTce4qTj4dv5tCUX7etzoF/weVPn8yhKrWfPMqta7z 8dSmF9CtcGIuGHcHIqWjaPHlcClP/PpgufV0uWJ2OdnK/4Co8eiyhHLO6ttEDhA7Z1WP oydxttDbfSnv9/m9pUSmLsb/k/sNAjlReHOmRIWmnKh+63ccezNSzsTrSO4yxl5tQqD/ WnAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q1999hFGtd7wlQzoxu6O/30ANn8Wl2FLG3Zs6Mbus4I=; b=L3v7M5RnPLrD9oCfD36B/DXXmHPbjUTOXNO6UmtskeUtQy+oqz86lHHRUR6qIuQ8XD kKC3YdMXy7kkcwHUy3Yi59zSl1N9V+OTEt4Cy7YNAXHxN+lkVMvnZqO7eJgyxMJRdIKO iiqQK6MO/9u2I9WVTpdIOGdvYR9c7xEmN3sFWxII2LkcCaUvxEWES25YsyGBQZBh9CR0 s0WD8bpz++kVOJ7u8dEub/WiBwomtFDzZhZMKdu/cFU+ywAUV8Xl4FdDEktVDIdhx7o5 NPilatYKFPzNUGoBkFgb64OnPHAyZ/s930/xot4NumO1km45zrKUSZtd2WVaqVE6NCVA bEFw== X-Gm-Message-State: AJcUuke2TIHzBa4oXibUCOdW6rhVPcOqQW4w905LS/SgPVMq4Q7G2U4A JiPoGNXNs0Na/zm8/z40TNrZDTkqmret9iBWFjZrkQ== X-Google-Smtp-Source: ALg8bN5za3ZhI5V/w3s7/GHI56bIrWJneh+3viJ1YXI9OrQkdYWOiAneeQHYBawrMrPtEfaGvHA549oZVkOjj2B9a24= X-Received: by 2002:a2e:458b:: with SMTP id s133-v6mr30696948lja.170.1548948751901; Thu, 31 Jan 2019 07:32:31 -0800 (PST) MIME-Version: 1.0 References: <20190131.094407.267764793396247491.mbj@tail-f.com> <20190131.115828.2130777685875370834.mbj@tail-f.com> In-Reply-To: <20190131.115828.2130777685875370834.mbj@tail-f.com> From: Andy Bierman Date: Thu, 31 Jan 2019 07:32:20 -0800 Message-ID: To: Martin Bjorklund Cc: Ladislav Lhotka , NetMod WG Content-Type: multipart/alternative; boundary="000000000000220bb80580c2bca6" Archived-At: Subject: Re: [netmod] features in import X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 15:32:37 -0000 --000000000000220bb80580c2bca6 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 31, 2019 at 2:58 AM Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Jan 31, 2019 at 12:44 AM Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > Hi, > > > > > > > > I do not agree these changes should be made at this late date. > > > > It seems to me that in order to support a feature you have to > implement > > > it, > > > > and therefore if any features are set then the module is > implemented, not > > > > imported. > > > > > > But this is not what RFC 7950 says about implement: > > > > > > A server implements a module if it implements the module's data > > > nodes, RPCs, actions, notifications, and deviations. > > > > > > > All features should be set to false in an import-only module. > > > > > > > > IMO this interpretation holds for typedef modules like > iana-crypt-hash. > > > > We list that as implemented (because it is) and the features that are > > > > supported are set. > > > > > > If a module consists only of typedefs, there is no problem. > > > Conformance "import" or "import-only" modules exist in YL b/c modules > > > may have a mix of typedefs and data nodes etc. > > > > > > So in the case that Lada brought up, a server would have to list the > > > module as implemented with a certain set of features; and then also > > > deviate all nodes/rpc/notifc etc as 'not-implemented'. > > > > > > > > So what. Using deviate(not-supported) to cherry-pick what you want to > > implement > > out of a module is how it is supposed to work. > > > > A server has to implement a feature to advertise it. > > As per 7950, this is not true, as I pointed out earlier. > > I think 7950 is wrong then > Note that with current YL (RFC 7895), it *is* in fact possible to > handle this case; you can list the features supported for an > import-only module. The new YL removes this possibility (by > mistake). > > It is not a mistake. The draft was reviewed 100 times. It looks intentional. I still don't understand the logic behind implementing a feature in a module you don't implement. There are plenty of cases (augment) where the imported module must also be an implemented module. Not sure what problem is solved by listing the module with features as a real module. I don't think the new YL should be changed at this late date. > > /martin > Andy > > > > Therefore the module containing the feature cannot be import-only. > > > > > > > > > /martin > > > > > > > > Andy > > > > > > > > > > > > > > > > Andy > > > > > > > > On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > Ladislav Lhotka wrote: > > > > > > Hi, > > > > > > > > > > > > unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list > for > > > > > > import-only modules. But is it really so that features have no > use in > > > > > > such modules? > > > > > > > > > > > > For example, an enum can depend on a feature, and if it is > inside a > > > > > > typedef, it can also be in an import-only module. What if that > > > feature > > > > > > is defined in the same module? > > > > > > > > > > I think you're right, and that this is an unfortunate omission. > > > > > > > > > > The fix is simple though; we would have to add the leaf-list > features > > > > > to import-only. Probably refactor the "feature" leaf-list into a > > > > > grouping so it works like the grouping location-leaf-list: > > > > > > > > > > grouping feature-leaf-list { > > > > > leaf-list feature { > > > > > type yang:yang-identifier; > > > > > description > > > > > "List of all YANG feature names from this module that are > > > > > supported by the server, regardless whether they are > defined > > > > > in the module or any included submodule."; > > > > > } > > > > > } > > > > > > > > > > And then "uses feature-leaf-list": > > > > > > > > > > OLD: > > > > > > > > > > grouping module-implementation-parameters { > > > > > description > > > > > "Parameters for describing the implementation of a module."; > > > > > > > > > > leaf-list feature { > > > > > type yang:yang-identifier; > > > > > description > > > > > "List of all YANG feature names from this module that are > > > > > supported by the server, regardless whether they are > defined > > > > > in the module or any included submodule."; > > > > > } > > > > > > > > > > NEW: > > > > > > > > > > grouping module-implementation-parameters { > > > > > description > > > > > "Parameters for describing the implementation of a module."; > > > > > > > > > > uses feature-leaf-list; > > > > > > > > > > > > > > > And in the list "import-only": > > > > > > > > > > OLD: > > > > > > > > > > uses location-leaf-list; > > > > > > > > > > uses feature-leaf-list; > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > --000000000000220bb80580c2bca6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 31, 2019 at 2:58 AM Marti= n Bjorklund <mbj@tail-f.com> wr= ote:
Andy Bierma= n <andy@yumawork= s.com> wrote:
> On Thu, Jan 31, 2019 at 12:44 AM Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaworks.com> wrote:
> > > Hi,
> > >
> > > I do not agree these changes should be made at this late dat= e.
> > > It seems to me that in order to support a feature you have t= o implement
> > it,
> > > and therefore if any features are set then the module is imp= lemented, not
> > > imported.
> >
> > But this is not what RFC 7950 says about implement:
> >
> >=C2=A0 =C2=A0 A server implements a module if it implements the mo= dule's data
> >=C2=A0 =C2=A0 nodes, RPCs, actions, notifications, and deviations.=
> >
> > > All features should be set to false in an import-only module= .
> > >
> > > IMO this interpretation holds for typedef modules like iana-= crypt-hash.
> > > We list that as implemented (because it is) and the features= that are
> > > supported are set.
> >
> > If a module consists only of typedefs, there is no problem.
> > Conformance "import" or "import-only" modules= exist in YL b/c modules
> > may have a mix of typedefs and data nodes etc.
> >
> > So in the case that Lada brought up, a server would have to list = the
> > module as implemented with a certain set of features; and then al= so
> > deviate all nodes/rpc/notifc etc as 'not-implemented'. > >
> >
> So what. Using deviate(not-supported) to cherry-pick what you want to<= br> > implement
> out of a module is how it is supposed to work.
>
> A server has to implement a feature to advertise it.

As per 7950, this is not true, as I pointed out earlier.


I think 7950 is wrong then
= =C2=A0
Note that with current YL (RFC 7895), it *is* in fact possible to
handle this case; you can list the features supported for an
import-only module.=C2=A0 The new YL removes this possibility (by
mistake).


It is not a mistake.
The dra= ft was reviewed 100 times.
It looks intentional.

I still don't understand the logic behind implementing a featu= re in a module you don't implement.
There are plenty of cases= (augment) where the imported module must also be
an implemented = module.=C2=A0 Not sure what problem is solved by listing the module with
features as a real module.

I don't thi= nk the new YL should be changed at this late date.

=C2=A0

/martin

Andy
=C2=A0


> Therefore the module containing the feature cannot be import-only.
>
>
>
> > /martin
> >
> >
> Andy
>
>
> > >
> > >
> > > Andy
> > >
> > > On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > > Hi,
> > > > >
> > > > > unlike RFC 7895, 7895bis doesn't provide the &= quot;feature" leaf list for
> > > > > import-only modules. But is it really so that feat= ures have no use in
> > > > > such modules?
> > > > >
> > > > > For example, an enum can depend on a feature, and = if it is inside a
> > > > > typedef, it can also be in an import-only module. = What if that
> > feature
> > > > > is defined in the same module?
> > > >
> > > > I think you're right, and that this is an unfortuna= te omission.
> > > >
> > > > The fix is simple though; we would have to add the leaf= -list features
> > > > to import-only.=C2=A0 Probably refactor the "featu= re" leaf-list into a
> > > > grouping so it works like the grouping location-leaf-li= st:
> > > >
> > > >=C2=A0 =C2=A0grouping feature-leaf-list {
> > > >=C2=A0 =C2=A0 =C2=A0leaf-list feature {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type yang:yang-identifier; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"List of all YANG= feature names from this module that are
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 supported by the serv= er, regardless whether they are defined
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the module or any = included submodule.";
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >=C2=A0 =C2=A0}
> > > >
> > > > And then "uses feature-leaf-list":
> > > >
> > > > OLD:
> > > >
> > > >=C2=A0 =C2=A0grouping module-implementation-parameters {=
> > > >=C2=A0 =C2=A0 =C2=A0description
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Parameters for describi= ng the implementation of a module.";
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0leaf-list feature {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type yang:yang-identifier; > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"List of all YANG= feature names from this module that are
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 supported by the serv= er, regardless whether they are defined
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the module or any = included submodule.";
> > > >=C2=A0 =C2=A0 =C2=A0}
> > > >
> > > > NEW:
> > > >
> > > >=C2=A0 =C2=A0grouping module-implementation-parameters {=
> > > >=C2=A0 =C2=A0 =C2=A0description
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Parameters for describi= ng the implementation of a module.";
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0uses feature-leaf-list;
> > > >
> > > >
> > > > And in the list "import-only":
> > > >
> > > > OLD:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0uses location-leaf-list;
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0uses feature-leaf-list;
> > > >
> > > >
> > > >
> > > > /martin
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > ne= tmod@ietf.org
> > > > https://www.ietf.org/mailman/listinf= o/netmod
> > > >
> >
--000000000000220bb80580c2bca6-- From nobody Thu Jan 31 08:01:10 2019 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 D8B32123FFD for ; Thu, 31 Jan 2019 08:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 (2048-bit key) header.d=kumari-net.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 Hg5UuqO6dlqv for ; Thu, 31 Jan 2019 08:01:04 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 14CEC1200D7 for ; Thu, 31 Jan 2019 08:01:03 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id r10so3853231wrs.10 for ; Thu, 31 Jan 2019 08:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bXTZNrSx0ZOLB+Em7nO76aeIJRW60TkYns80Frpqo9s=; b=CMRq3o2ODBhGtlrzE7EdwS2nKOmg8amEn3KQtx6/tYi0cPTAvYakftcMaqkxfnQcxL LGLLtZaW9114HXfTVfa2PSybYKiBO+o0WbZptWMbrfOQIxyQYx5GQ5VBJt5gEzZfDvo0 xpP8QgBiuzuSyidFe9WXTayE8dgWMXCSPGrNEzmtTfuv8Ci8iLUhV9m3dyguUyobPFts x5A58giIFkZRK091fQFLtRWOSwFFzgAX5wSvxP8UalTK+znqU/bi3ELnERpkvhBswNjB fzdvSb2VA9E2rgg/mWXPxukKbqi2U5/dwZiEW3Im7BRuIYHgyDW6YRtFg2OltxsK5/DW FNeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bXTZNrSx0ZOLB+Em7nO76aeIJRW60TkYns80Frpqo9s=; b=dPfuBXB8P82iFKnFe9az2qQL4G0GVq5qlFh5Eu5Zzb45iiAKLxRXZJwskwQEZULOJp wyBMv0vKCLLEoHstmS4Nk7FTYyu3PaAl59Cm2R30w9ToUXrK4v5xikkpl21rmvdze22G WiNKfL0CHwDOvKQGtqHZ2nyFk6CWzbsRbeayE6SG99ACiHoPt+rzn9CCtTN4X0Kg5KnA 84mBi1DL09+kY4aPvMaUJO+Fn5rQJoCQZE/bdzIF2OJ2idS1iSKaYH+u//7Vnuzy5/rg XkIsDl7I5j7o2XsdPTgz0NSLaSR7/9wSX8MjwNmKwVjPrnR86FQ1DCnHFR4cIBPEtjh6 830Q== X-Gm-Message-State: AJcUukeVy5ZxrGnTNuxkGqOXg44Bb51kyxdRuxdjR35fx7r7+lOpmFQm iCYFQ/T0fvZD9vIcC8Hn2uCNCXQ0kZYBDig3wfsvnQ== X-Google-Smtp-Source: ALg8bN7bWHZiYV7pVhgz3JPOeTkE74wGKRNP24UWr6b2BvkzPChGEdGSXQdxEm/YC7F4zn1gwTp4CRPJPhAHkYuOI4M= X-Received: by 2002:adf:f101:: with SMTP id r1mr35826905wro.32.1548950461978; Thu, 31 Jan 2019 08:01:01 -0800 (PST) MIME-Version: 1.0 References: <20190130103514.6074DB80ED2@rfc-editor.org> In-Reply-To: From: Warren Kumari Date: Thu, 31 Jan 2019 11:00:25 -0500 Message-ID: To: Ladislav Lhotka Cc: RFC Errata System , =?UTF-8?Q?martin_bj=C3=B6rklund?= , Ignas Bagdonas , Joel Jaeggli , kent+ietf@watsen.net, Lou Berger , marek.michalak@nokia.com, netmod@ietf.org Content-Type: multipart/alternative; boundary="0000000000000fb7290580c32248" Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5617) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 16:01:08 -0000 --0000000000000fb7290580c32248 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 30, 2019 at 5:45 AM Ladislav Lhotka wrote: > Hi, > > this erratum should be rejected. It is a substantial technical change of > the > spec, and section 9.9.2 doesn't indicate any possibility of using deref(). > > Yup, while it might be a good idea, it isn't an errata, and would need a -bis or similar.... W > Lada > > On Wed, 2019-01-30 at 02:35 -0800, RFC Errata System wrote: > > The following errata report has been submitted for RFC7950, > > "The YANG 1.1 Data Modeling Language". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5617 > > > > -------------------------------------- > > Type: Technical > > Reported by: Marek Michalak, Pawel Koch > > > > Section: 14 > > > > Original Text > > ------------- > > path-arg = absolute-path / relative-path > > > > Corrected Text > > -------------- > > path-arg = deref-expr / path-str > > > > deref-expr = deref-function-invocation *WSP "/" *WSP > > relative-path > > > > path-str = absolute-path / relative-path > > > > deref-function-invocation = deref-keyword *WSP > > "(" *WSP path-str *WSP ")" > > > > deref-keyword = %s"deref" > > > > Notes > > ----- > > This is to allow path statement to contain also "deref" function > invocation > > which is supported by pyang and Cisco compiler but for now is not > supported by > > i.e. yanglint validator because of above statement which does not allow > for > > it. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC7950 (draft-ietf-netmod-rfc6020bis-14) > > -------------------------------------- > > Title : The YANG 1.1 Data Modeling Language > > Publication Date : August 2016 > > Author(s) : M. Bjorklund, Ed. > > Category : PROPOSED STANDARD > > Source : Network Modeling > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000000fb7290580c32248 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 30, 2019 at 5:45 AM Ladi= slav Lhotka <lhotka@nic.cz> wrot= e:
Hi,

this erratum should be rejected. It is a substantial technical change of th= e
spec, and section 9.9.2 doesn't indicate any possibility of using deref= ().


Yup, while it might be a good idea, it isn&= #39;t an errata, and would need a -bis or similar....
W

=C2=A0
Lada

On Wed, 2019-01-30 at 02:35 -0800, RFC Errata System wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5617
>
> --------------------------------------
> Type: Technical
> Reported by: Marek Michalak, Pawel Koch <marek.michalak@nokia.com>
>
> Section: 14
>
> Original Text
> -------------
> path-arg=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D absolute-path / = relative-path
>
> Corrected Text
> --------------
> path-arg=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D deref-expr / pat= h-str
>
> deref-expr=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D deref-function-invoca= tion *WSP "/" *WSP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0relative-path
>
> path-str=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D absolute-path / = relative-path
>
> deref-function-invocation =3D deref-keyword *WSP
>=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"(" *WSP path-str *WSP ")&= quot;
>
> deref-keyword=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D %s"deref"
>
> Notes
> -----
> This is to allow path statement to contain also "deref" func= tion invocation
> which is supported by pyang and Cisco compiler but for now is not supp= orted by
> i.e. yanglint validator because of above statement which does not allo= w for
> it.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party=C2=A0
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The YANG= 1.1 Data Modeling Language
> Publication Date=C2=A0 =C2=A0 : August 2016
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Bjorklund, Ed.<= br> > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Model= ing
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operatio= ns and Management
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod --
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67



--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--0000000000000fb7290580c32248-- From nobody Thu Jan 31 09:24:30 2019 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 23138130DFA for ; Thu, 31 Jan 2019 09:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.632 X-Spam-Level: X-Spam-Status: No, score=-14.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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_KAM_HTML_FONT_INVALID=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 gWu09Zd7wJSW for ; Thu, 31 Jan 2019 09:24:24 -0800 (PST) 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 30BFD130E0A for ; Thu, 31 Jan 2019 09:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=120843; q=dns/txt; s=iport; t=1548955463; x=1550165063; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=oMSGxuiCYpfeNG/wabNN7Sz3iIZ5GxB2r3jVNBbZ+zA=; b=aODqKxXw/TYg3A6AqTDqOzKcRlpkucmaQYfe1AyCl+NqKv/+82lTuv1Y 9u7hJ3GNjHONmQ2hVARYG66cU5DLNDBiCEMEHuZCPDthfhOJ/MNhEZj5Q xx4msvPugn2GlqYpLx5fLADuXB0B6xoiEPUQxY+H2BfSeP6LhnXrgUtF9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAQCMLlNc/xbLJq0YAUAKGgEBAQE?= =?us-ascii?q?BAgEBAQEHAgEBAQGBZQKBDEiBFVABMieEA4h5jHMIJZoFBA0YAQqBVIIvRgK?= =?us-ascii?q?DMDgSAQMBAQIBAQJtHAyFSgEBAQECAQEBGAEISwQHBQsJAhEEAQEBIAEGAwI?= =?us-ascii?q?CJx8JCAYNBgIBAReDBwGBeQgPjiyCO5thgS8fhBMDCwJAAUCEa4xXgUA/gTg?= =?us-ascii?q?MgWF+gx4BAQMBgTIFEEyCU4JXAolREg4SHgIDgUuENYZiin1cCYcvg2CHIAY?= =?us-ascii?q?CF4FrUoRsgxaHfo9OhQqHHYFdISiBLjMaCBsVO4JsCYsUhT8/AzCNQIJMAQE?= X-IronPort-AV: E=Sophos;i="5.56,545,1539648000"; d="scan'208,217";a="9729256" 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; 31 Jan 2019 17:24:20 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x0VHOIZd020462; Thu, 31 Jan 2019 17:24:18 GMT To: Andy Bierman Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" References: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> <914c99e5-ca38-9e39-32dd-1b0c3ed3294e@cisco.com> From: Robert Wilton Message-ID: <47132640-a71a-596a-6b07-253c4defb5c3@cisco.com> Date: Thu, 31 Jan 2019 17:24:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9702831B070CBE528C4D8EAD" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 17:24:28 -0000 This is a multi-part message in MIME format. --------------9702831B070CBE528C4D8EAD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 30/01/2019 20:51, Andy Bierman wrote: > > > On Wed, Jan 30, 2019 at 10:04 AM Robert Wilton > wrote: > > > On 30/01/2019 17:31, Andy Bierman wrote: >> >> >> On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton > > wrote: >> >> >> On 30/01/2019 15:16, Andy Bierman wrote: >>> >>> >>> On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton >>> > wrote: >>> >>> Hi Andy, >>> >>> Thanks for the comments. >>> >>> On 30/01/2019 01:22, Andy Bierman wrote: >>>> Hi, >>>> >>>> I originally brought up this issue in July 2015 >>>> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ >>> >>> Yes. >>> >>> The solution I propose is different in the sense that it >>> uses YANG instance data to define YANG packages rather >>> than new YANG keywords.   I believe that this should >>> make it a lower cost solution to define and implement. >>> >>> >>> >>> I think yangvalidator.org has a >>> better solution that does not change YANG conformance. >> >> Do you mean that we can just use zip files with the list of >> modules? >> >> >> I don't care about the solution details yet. They are 2nd order >> problems. >> >> Conformance means "what modules are required to be implemented >> together". >> It is not clear that this problem can be solved.  The >> augment-stmt defines implicit >> multi-module conformance.  I am not convinced that the extra work >> of defining package conformance >> is worth it. > > So, I'm not proposing backing any sort of package conformance into > the language at all.  A package is just metadata that defines that > a set of modules, at particular revisions/versions, work together > and can represent part of a YANG schema. > > This is equivalent to >  - how a zip file of YANG modules provided to yangvalidator would > work. >  - getting the contents of YANG library from a server (but a YANG > packages soln can also work offline) >  - fetching the modules from YANG catalog (if they have been > labelled appropriately), although I'm not convinced that this > universally works today. > > > This sort of metadata could be provided by module tags. > A vendor or SDO could define module-tags that represent packages. Yes, this is a different way to assigning membership, although I'm not convinced that it is better. I think that such a scheme could work without versioning, but I'm not sure that it will work so well once package versioning is considered, because to handle versioning the tags don't just need to represent which package they belong to, they also should identify which version of that package. E.g. ietf-interfaces@2014-05-08.yang might be tagged with: "ietf-base-pkg@0.0.1", "ietf-base-pkg@0.0.2", "ietf-base-pkg@1.0.0", ietf-base-pkg@1.1.0", ... If packages change quite frequently then you might find that a module needs 50+ tags to identify which particular packages it belongs to. Any without knowing the package version, I don't see that there would be enough information to build a schema since you wouldn't know which versions of YANG modules to use. > > > But in terms of the usability of YANG, I don't think that doing > conformance only at the module level is really sufficient.  > Clients need to be coding against sets of modules at particular > versions that are known to work together, and known that multiple > server vendors will implement. > > A pick and mix appropriate to module revisions doesn't seem to > help anyone. > > > > I get all the different components and variables one might have for a > package. > I am not as convinced (as in 2015) that standard packages could be > simple and widely deployed.. > Now it seems vendors implement an ad-hoc subset + additions to everything. > It doesn't help to define a new package variant to match the vendor > implementation. > The YANG library can do that already. YANG library is only on the box at the moment, and it just gives a flat list of modules. I would like it to also be available off the box and have more structure. E.g. I would like IETF to define an L2VPN package that contains the basic set of YANG modules that a device that supports L2VPN services would be expected to implement at a minimum. Then, rather that checking the output of YANG library to see that it has all the necessary modules to implement an L2VPN service, I could instead check whether the package implemented by the device imports the L2VPN package.  And if it does import that package, I can then also see which version of that package it implements (rather than checking every module version). > > You seem more optimistic than me that the industry is actually ready, > willing, and able > to implement standard YANG packages. If we want YANG to be properly successful then I see that it has go there.  But nobody can do this today until there is a way that such packages can be defined, and versioned, and we start defining what these standard packages look like. > > > >> >> The issue of what modules does vendor A implement is not a >> conformance problem. >> It is just more metadata and YANG Catalog is focused on providing >> that data. > > Does YANG catalog indicate the set of IETF modules that I would > need to implement L2VPN services on a device? > > > This seems like a separate problem, but actually it can help by > searching a lot of known modules. > In order to know what vendor A, B, and C have in common, you need to > get the catalog info for each vendor. > > Module tags can also solve this problem. But when there are multiple vendors with multiple devices, with multiple versions of software available then this looks like a hard problem to solve. I would like someone (or a program) to be able to look at a package definition file, and determine if it implements what is required, and what software version is needed, and whether they are deviations that matter. When my client then connects to that device, I would like the client to be able to check that it implements that modules that I expect it to.  I would strongly prefer if this could be done by returning a small amount of data, rather than a list of 1000 modules/sub-modules for every server that I connect to. Module tags won't tell the client that it implements all the required modules that implement the L2VPN service, it will just indicate that implements some modules which can be used to implement an L2VPN service. > Module tags could be used to do this (another packaging solution), > but this would cause a proliferation of tags when it comes to > versioning, since I don't think that you can cleanly bake semver > into module tags. > > >> >> I don't really see how this helps. >> >> Consider: >> - server vendor A, implements some subset of the OpenConfig >> YANG modules, each at a particular version, along with some >> deviations and vendor augmentations. >> - server vendor B, implements the same subset of the >> OpenConfig YANG modules, but at different versions, along >> with some deviations and vendor augmentations. >> - server vendor C, implements a slightly different set of the >> OpenConfig YANG modules, but at different versions, along >> with some deviations and vendor augmentations. >> >> As a client, how do I know what module versions to code >> against, when I want to work with devices provided by all >> three vendors? >> >> >> >> The vendors publish their implementation details on yangcatalog >> and you get the info >> and see what modules are in common. >> >> There are only market requirements determining what group of >> modules has to exist >> in an implementation.  It is not clear to me that formalizing >> these requirements >> is something the industry will do effectively. Module tags >> already provide a way >> to conceptually group modules together. >> >> Seems like every vendor has openconfig, foo-openconfig, and >> foo-openconfig-deviations >> so that there are no agreed upon subsets. Even if openconfig had >> properly documented >> subsets, would your client even be able to code to it (ignoring >> add-ons and deviations). > > I think that answer will converge on yes, I don't know how long it > will take.  It would probably be better if at the time that > protocol specifications are written, that the authors of the > specifications also write the YANG modules to manage them at the > same time. > >> >> I might be wrong, but I think that the OC solution is use git >> tags, so they tag sets of modules that are expected to work >> together and also to provide a linear release history of >> their sets of modules.  So, if everyone implements the module >> versions associated with a git tag then it should convert a >> two dimensional problem of module revisions into a linear >> problem.  The YANG packages draft is aiming to provide a >> solution to this problem that doesn't require the use of git, >> or sending zip files of modules around. >> >> >> At the moment, it seems that everyone is doing this in >> different ways: >>  - Yumawork customers/servers use zip files of modules for >> conformance. >> >> >> Not sure what this means. >> Actually the server libraries can be loaded and unloaded. >> Module can be standalone libraries or grouped as bundles. >> But this seems like an implementation detail, unrelated to >> conformance. >> >> >>  - OpenConfig client/server implementations use git tags, or >> git refpoints. >>  - Cisco customers use the contents of directories on github >> YangModels. >> >> Finally, this draft doesn't change YANG conformance, it just >> expresses it in what is intended to be a simpler way. >> >> >> It adds another conformance system to maintain. >> The language only recognizes module to module interfaces, not >> package to package. > > I propose that at the language level conformance is at the module > level (modulo import-by-version). > > >> That adds more complexity. It doesn't take away any complexity. > > It is meant to be a simpler way of packaging up, and trying to > control and manage the complexity that already exists today. > > E.g. I could give a YANG compiler the name, version, and location > of a package and tell it to build the entire schema associated > with that package. > > > This is a tool implementation detail, not a conformance issue. > It would be nice to have a standard format for the YANG library for a > tool to use. > You seem to be proposing an artifact containing ietf-yang-library > information. > That seems OK to me, but it should not have anything to do with > conformance. > It is just a standard way to express a module-set in a yang-data artifact. Yes, what I am proposing is close to a file containing ietf-yang-library information, but I want it to be hierarchical/recursive, where as the schema defined by YANG library bis is flat, and I want the data to also optionally be made available in YANG library. What I am proposing here doesn't change conformance of the YANG language in any way, not does it replace YANG library. Thanks, Rob > > > In a somewhat similar way, when I write code, my build file > specifies which libraries I depend on, and their versions, but I > can leave it to the build tool to determine what those libraries > themselves depend on and recursively pull in all the dependencies. > > >> >> If there was a standard to load and unload modular functionality >> at boot-time or run-time, >> then I could see why there is a need to have a standard to define >> YANG packages. > > I agree that this is another example of where they could be useful. > > Thanks, > Rob > > > > Andy > >> >> Thanks, >> Rob >> >> >> >> Andy >> >>> >>> >>> Andy >>> >>>> >>>> I don't think the WG ever agreed on the problem that >>>> needs to be solved, >>>> and that is still the case. >>> >>> That wasn't quite my impression.  I also think that >>> folks were busy focusing on other WG activity and didn't >>> necessarily have the time to concentrate on this. >>> >>> My draft was aiming on solving two broad problems: >>> >>> The main goals of YANG package definitions include, but are not >>> restricted to: >>> >>> o To act as a simplified YANG conformance mechanism. Rather than >>> conformance being performed against a set of individual YANG >>> module revisions, conformance could also be more simply stated in >>> terms of YANG packages, with a set modifications (e.g. additional >>> modules, deviations, or features). >>> >>> o To allow YANG datastore schema to be specified in a more concise >>> way rather than having to list all modules and revisions. YANG >>> package definitions can be defined in documents that can be >>> referenced by a URL rather than requiring explicit lists of >>> modules to be shared between client and server. Hence, a YANG >>> package must contain sufficient information to allow a client or >>> server to precisely construct the schema associated with the >>> package. >>> >>> >>> >>>> >>>> In reality each server has 1 package -- its entire library. >>> >>> This doesn't apply to all servers. For a long time, as a >>> vendor, we have had separate packages that can be >>> independently installed, and which extend the management >>> model to cover the new functionality.  E.g. BNG >>> functionality could be in a separate, independently >>> installable, package on top of the base router >>> functionality. >>> >>> For a Linux server, the manageability interface will >>> depend on what applications have been installed. >>> >>> >>>> The SEMVER work shows >>>> that vendors are treating platforms as independent >>>> release trains, and not really >>>> developing loadable packages. >>> >>> This depends on the vendor.  The YANG versioning work is >>> trying to find a solution that works across the >>> industry.  I believe that the versioning requirements >>> are different for standards developed modules, vs >>> industry developed modules, vs vendor modules. >>> >>> >>>> >>>> I think YANG 1.2 improvements for conformance (e.g., >>>> YANG-redirects, SEMVER import) >>>> and  the YANG Catalog can solve the module >>>> compatibility issues. It is more of a documentation >>>> problem than a standards problem. >>> >>> Having a standard YANG module that can be used to define >>> packages is something this is useful and should be >>> standardized.  I believe that this is better than each >>> vendor coming up with their own solution for this problem. >>> >>> Thanks, >>> Rob >>> >>> >>>> >>>> >>>> Andy >>>> >>>> >>>> >>>> >>>> On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - >>>> CA/Ottawa) >>> > wrote: >>>> >>>> Thanks Rob. Please see inline. >>>> >>>> Jason >>>> >>>> *From:*Robert Wilton >>> > >>>> *Sent:* Thursday, January 24, 2019 1:16 PM >>>> *To:* Sterne, Jason (Nokia - CA/Ottawa) >>>> >>> >; netmod@ietf.org >>>> >>>> *Subject:* Re: initial comments on >>>> draft-rwilton-netmod-yang-packages >>>> >>>> Hi Jason, >>>> >>>> Thanks for the review and comments. >>>> >>>> I've put some responses inline ... >>>> >>>> On 24/01/2019 14:56, Sterne, Jason (Nokia - >>>> CA/Ottawa) wrote: >>>> >>>> Hi guys, >>>> >>>> I've gotten most of the way through the draft >>>> and have some initial comments. I haven't >>>> digested the section 10 open issues yet or the >>>> examples. >>>> >>>> Section 5 mentions the following: >>>> >>>>    YANG library is augmented to allow servers >>>> to report the packages >>>> >>>>    that they implement and to associate those >>>> packages back to >>>> >>>>    particular datastore schema. >>>> >>>> Does the combination of this draft and >>>> rfc7895bis somehow allow the same package to be >>>> advertised in 2 different datastores, but with >>>> different deviations in each datastore? I'm >>>> thinking of a case, for example, where a >>>> package is fully supported in the running but >>>> the package minus a few modules (or parts of >>>> modules) is supported in the operational >>>> datastore. There seems to be a 1:1 relationship >>>> between package and rfc7895bis schema. >>>> >>>> So, the intention is no, not directly. >>>> >>>> My aim here is that would implement >>>> package "foo", and would implement >>>> package "modified-foo".  Package "modified-foo" >>>> would import package "foo" and also specify the set >>>> of modules that contain the deviations "foo". >>>> >>>> I didn't want a server to be able to see that I >>>> implement package "foo", but then I have all these >>>> deviations that change its behavior. Instead, it is >>>> really implementing a different package that is >>>> based on "foo". >>>> >>>> The packages draft doesn't include any specific >>>> leaf-list for deviations. Section 7.2 mentions >>>> that deviations could be expressed by including >>>> modules that happen to contain deviations. That >>>> seems a bit inconsistent with rfc7895bis that >>>> has a specific leaf-list of deviations (and >>>> NETCONF hello that specifically explicitly >>>> labels deviation modules). >>>> >>>> I'm conflicted on this one.  I don't really like >>>> the deviation list in YANG library because I regard >>>> it as a duplicate source of information, and then >>>> there is a question of which source of data do you >>>> trust.  E.g. do you process a deviation in a module >>>> that is not listed in the deviations module list? >>>> >>>> */[>>JTS: ] Good point. I suppose this issue >>>> applies today already. i.e. what if one of the >>>> modules advertised in the is a module of >>>> deviations (without having been referenced by >>>> another module as a deviation module)./* >>>> >>>> Section 5.1 says the package must be >>>> referentially complete. I can see the >>>> advantages of that although wondering if that >>>> might limit flexibility of partitioning modules >>>> into packages. I could imagine use cases for >>>> dividing a large set of modules into a few >>>> packages that might rev independently but can >>>> still all work together (especially if they rev >>>> in a bc manner). But maybe that just starts to >>>> introduce too much complexity? >>>> >>>> Yes, having partial packages may be useful. Perhaps >>>> just adding a leaf to indicate whether a package is >>>> referentially complete could be the answer here. >>>> >>>> I didn't understand this part of section 5.1. >>>> Can you maybe illustrate with an example? >>>> >>>>       The version/revision of a module listed >>>> in the package module list >>>> >>>>       supercedes any version/revision of the >>>> module listed in a imported >>>> >>>>       package module list.  This allows a >>>> package to resolve any >>>> >>>>       conflicting implemented module >>>> versions/revisions in imported >>>> >>>>       packages. >>>> >>>> Probably best to see example B.3. in the appendix >>>> because it exactly illustrates this point. >>>> >>>> Basically: >>>> 1) Packages must explicitly list all versions of >>>> all modules they define/import. >>>> 2) If two imported packages define different >>>> versions of modules, then the package that is >>>> importing them needs a way to define which version >>>> to use. >>>> 3) A package needs a way to override the version of >>>> module specified in an imported package. >>>> >>>> */[>>JTS: ] Thx. That example does help. I suppose >>>> the designer of the package needs to carefully >>>> check that the version they select can be >>>> successfully used by all the modules in the package. /* >>>> >>>> */I think there is a minor typo in example B.3.  >>>> The example-3-pkg is importing "/* >>>> */example-import-1" but I believe you meant "/* >>>> */example-import-1-pkg" (and some for import-2)./* >>>> >>>> It might be a good idea to add a parent-version >>>> to the package module (to allow tracking >>>> lineage of packages). >>>> >>>> Agreed, or maybe allowing a revision history like >>>> modules. Not sure which is better here.  Packages >>>> could get a lot of updates, and a long revision >>>> history would not be helpful at all. >>>> >>>> */[>>JTS: ] I think a minimum of just specifying >>>> the direct parent is enough to build the full tree >>>> of lineage. We don't need a long history of N >>>> revisions./* >>>> >>>> I like the use of groupings. That allows a >>>> manager to use this as a building block to >>>> compose a model that has a list of packages. >>>> >>>> OK. >>>> >>>> Having a global list of mandatory features (vs >>>> having the mandatory feature a per-module list) >>>> means inventing the new : >>>> format. Should we instead somehow put the >>>> mandatory features against each module of the >>>> package? >>>> >>>> Perhaps.  My thinking here was to have the list of >>>> features high up and very easy to find/parse. >>>> >>>> The location leaf is a uri but then the >>>> description says it must be a url (where the >>>> model can be retrieved). I do like that the >>>> namespace is separate from the location, but >>>> maybe we should make location a url type? >>>> >>>> Yes, I was thinking that is should be a URL. >>>> >>>> Do we need a namespace for package names in the >>>> model? >>>> >>>> I had them in an earlier version, but I took them >>>> out, because I wasn't sure that they are really >>>> useful/required. >>>> >>>> Defining a format to make package names themselves >>>> globally unique might be sufficient. >>>> >>>> */[>>JTS: ] I'm OK with that. It is similar to how >>>> we're finding that it is useful that YANG module >>>> names are globally unique (i.e. by naming with >>>> ietf-xxxx or companyabc-xxx)./* >>>> >>>> In 7.3 we only reference module-sets and not >>>> modules. So the grouping of modules into sets >>>> and packages must be the same? >>>> >>>> Not necessarily. >>>> >>>> I am trying to reuse the module-set definitions as >>>> much as possible (to avoid duplication).  One issue >>>> here is that module-sets are combined then all the >>>> modules must not overlap, which doesn't make the >>>> mapping to module-sets quite so clean. >>>> >>>> A schema can only have a single package. I >>>> think that works but it means a server would >>>> advertise multiple schemas if it wants to >>>> support multiple packages. I'm not sure if >>>> there are some downsides to that (it just >>>> surprised me). >>>> >>>> My aim here was: >>>>  - multiple packages are advertised in >>>> yang-library/packages >>>>  - datastores only report that they "implement" one >>>> [top level] package version. [The package itself >>>> might import other packages.] >>>> >>>> If we do package selection, then for a given YANG >>>> client session, and the version of YANG library >>>> available/reported by that session, it would appear >>>> as if the server only implements one top level >>>> package for a datastore.  Different clients >>>> choosing different versions would see slightly >>>> different output depending on which package version >>>> they had selected to use. >>>> >>>> Thanks again for the review and the comments! >>>> >>>> Rob >>>> >>>> Jason >>>> >>>> *From:*netmod >>>> *On Behalf Of >>>> *Robert Wilton >>>> *Sent:* Thursday, December 20, 2018 12:45 PM >>>> *To:* netmod@ietf.org >>>> *Subject:* [netmod] YANG Packages >>>> >>>> Hi, >>>> >>>> I've written up an ID for a potential solution >>>> for YANG packages using instance data: >>>> >>>> Abstract >>>> >>>>    This document defines YANG packages, an >>>> organizational structure >>>> >>>>    holding a set of related YANG modules, that >>>> can be used to simplify >>>> >>>>    the conformance and sharing of YANG schema.  >>>> It describes how YANG >>>> >>>>    instance data documents are used to define >>>> YANG packages, and how the >>>> >>>>    YANG library information published by a >>>> server can be augmented with >>>> >>>>    additional packaging related information. >>>> >>>> https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ >>>> >>>> Potentially this work may be of use as part of >>>> the YANG versioning design team work.  In >>>> addition, if the WG likes this approach of >>>> defining YANG packages, then it might also be >>>> useful to bind a schema to a YANG instance data >>>> document. >>>> >>>> Some questions for members of the WG: >>>> >>>> 1) Do members of the WG agree that YANG >>>> packages is something that needs to be solved? >>>> >>>> 2) Is the approach in this draft of defining >>>> these as instance data documents a good >>>> starting point? >>>> >>>> 3) This approach augments YANG library-bis, >>>> reusing module-sets, but not replacing the way >>>> that modules are reported in YANG library-bis.  >>>> Is this the right approach?  This approach >>>> tries to allow module-sets to be reused for >>>> both schema and packages, but the YANG >>>> library-bis rules for combining module-sets >>>> (i.e. no conflicts) may make this harder to >>>> really reuse the module-sets for both purposes. >>>> >>>> Of course, any other comments or feedback is >>>> welcome and appreciated. >>>> >>>> Thanks, >>>> Rob >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> --------------9702831B070CBE528C4D8EAD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 30/01/2019 20:51, Andy Bierman wrote:


On Wed, Jan 30, 2019 at 10:04 AM Robert Wilton <rwilton@cisco.com> wrote:


On 30/01/2019 17:31, Andy Bierman wrote:


On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton <rwilton@cisco.com> wrote:


On 30/01/2019 15:16, Andy Bierman wrote:


On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,

Thanks for the comments.

On 30/01/2019 01:22, Andy Bierman wrote:
Hi,

I originally brought up this issue in July 2015

Yes.

The solution I propose is different in the sense that it uses YANG instance data to define YANG packages rather than new YANG keywords.   I believe that this should make it a lower cost solution to define and implement.



I think yangvalidator.org has a better solution that does not change YANG conformance.

Do you mean that we can just use zip files with the list of modules?


I don't care about the solution details yet. They are 2nd order problems.

Conformance means "what modules are required to be implemented together".
It is not clear that this problem can be solved.  The augment-stmt defines implicit
multi-module conformance.  I am not convinced that the extra work of defining package conformance
is worth it.

So, I'm not proposing backing any sort of package conformance into the language at all.  A package is just metadata that defines that a set of modules, at particular revisions/versions, work together and can represent part of a YANG schema.

This is equivalent to
 - how a zip file of YANG modules provided to yangvalidator would work.
 - getting the contents of YANG library from a server (but a YANG packages soln can also work offline)
 - fetching the modules from YANG catalog (if they have been labelled appropriately), although I'm not convinced that this universally works today.


This sort of metadata could be provided by module tags.
A vendor or SDO could define module-tags that represent packages.

Yes, this is a different way to assigning membership, although I'm not convinced that it is better.

I think that such a scheme could work without versioning, but I'm not sure that it will work so well once package versioning is considered, because to handle versioning the tags don't just need to represent which package they belong to, they also should identify which version of that package.

E.g. ietf-interfaces@2014-05-08.yang might be tagged with:
"ietf-base-pkg@0.0.1", "ietf-base-pkg@0.0.2", "ietf-base-pkg@1.0.0", ietf-base-pkg@1.1.0", ...

If packages change quite frequently then you might find that a module needs 50+ tags to identify which particular packages it belongs to.

Any without knowing the package version, I don't see that there would be enough information to build a schema since you wouldn't know which versions of YANG modules to use.




 

But in terms of the usability of YANG, I don't think that doing conformance only at the module level is really sufficient.  Clients need to be coding against sets of modules at particular versions that are known to work together, and known that multiple server vendors will implement.

A pick and mix appropriate to module revisions doesn't seem to help anyone.



I get all the different components and variables one might have for a package.
I am not as convinced (as in 2015) that standard packages could be simple and widely deployed..
Now it seems vendors implement an ad-hoc subset + additions to everything.
It doesn't help to define a new package variant to match the vendor implementation.
The YANG library can do that already.

YANG library is only on the box at the moment, and it just gives a flat list of modules.
I would like it to also be available off the box and have more structure.

E.g. I would like IETF to define an L2VPN package that contains the basic set of YANG modules that a device that supports L2VPN services would be expected to implement at a minimum.

Then, rather that checking the output of YANG library to see that it has all the necessary modules to implement an L2VPN service, I could instead check whether the package implemented by the device imports the L2VPN package.  And if it does import that package, I can then also see which version of that package it implements (rather than checking every module version).


You seem more optimistic than me that the industry is actually ready, willing, and able
to implement standard YANG packages.

If we want YANG to be properly successful then I see that it has go there.  But nobody can do this today until there is a way that such packages can be defined, and versioned, and we start defining what these standard packages look like.






The issue of what modules does vendor A implement is not a conformance problem.
It is just more metadata and YANG Catalog is focused on providing that data.

Does YANG catalog indicate the set of IETF modules that I would need to implement L2VPN services on a device?


This seems like a separate problem, but actually it can help by searching a lot of known modules.
In order to know what vendor A, B, and C have in common, you need to get the catalog info for each vendor.

Module tags can also solve this problem.

But when there are multiple vendors with multiple devices, with multiple versions of software available then this looks like a hard problem to solve.

I would like someone (or a program) to be able to look at a package definition file, and determine if it implements what is required, and what software version is needed, and whether they are deviations that matter.

When my client then connects to that device, I would like the client to be able to check that it implements that modules that I expect it to.  I would strongly prefer if this could be done by returning a small amount of data, rather than a list of 1000 modules/sub-modules for every server that I connect to.

Module tags won't tell the client that it implements all the required modules that implement the L2VPN service, it will just indicate that implements some modules which can be used to implement an L2VPN service.


 

Module tags could be used to do this (another packaging solution), but this would cause a proliferation of tags when it comes to versioning, since I don't think that you can cleanly bake semver into module tags.



I don't really see how this helps.

Consider:
- server vendor A, implements some subset of the OpenConfig YANG modules, each at a particular version, along with some deviations and vendor augmentations.
- server vendor B, implements the same subset of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations.
- server vendor C, implements a slightly different set of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations.

As a client, how do I know what module versions to code against, when I want to work with devices provided by all three vendors?



The vendors publish their implementation details on yangcatalog and you get the info
and see what modules are in common.

There are only market requirements determining what group of modules has to exist
in an implementation.  It is not clear to me that formalizing these requirements
is something the industry will do effectively.  Module tags already provide a way
to conceptually group modules together.

Seems like every vendor has openconfig, foo-openconfig, and foo-openconfig-deviations
so that there are no agreed upon subsets. Even if openconfig had properly documented
subsets, would your client even be able to code to it (ignoring add-ons and deviations).

I think that answer will converge on yes, I don't know how long it will take.  It would probably be better if at the time that protocol specifications are written, that the authors of the specifications also write the YANG modules to manage them at the same time.


I might be wrong, but I think that the OC solution is use git tags, so they tag sets of modules that are expected to work together and also to provide a linear release history of their sets of modules.  So, if everyone implements the module versions associated with a git tag then it should convert a two dimensional problem of module revisions into a linear problem.  The YANG packages draft is aiming to provide a solution to this problem that doesn't require the use of git, or sending zip files of modules around.


At the moment, it seems that everyone is doing this in different ways:
 - Yumawork customers/servers use zip files of modules for conformance.


Not sure what this means.
Actually the server libraries can be loaded and unloaded.
Module can be standalone libraries or grouped as bundles.
But this seems like an implementation detail, unrelated to conformance.


 - OpenConfig client/server implementations use git tags, or git refpoints.
 - Cisco customers use the contents of directories on github YangModels.

Finally, this draft doesn't change YANG conformance, it just expresses it in what is intended to be a simpler way.


It adds another conformance system to maintain.
The language only recognizes module to module interfaces, not package to package.

I propose that at the language level conformance is at the module level (modulo import-by-version).


That adds more complexity. It doesn't take away any complexity.

It is meant to be a simpler way of packaging up, and trying to control and manage the complexity that already exists today.

E.g. I could give a YANG compiler the name, version, and location of a package and tell it to build the entire schema associated with that package. 


This is a tool implementation detail, not a conformance issue.
It would be nice to have a standard format for the YANG library for a tool to use.
You seem to be proposing an artifact containing ietf-yang-library information.
That seems OK to me, but it should not have anything to do with conformance.
It is just a standard way to express a module-set in a yang-data artifact.

Yes, what I am proposing is close to a file containing ietf-yang-library information, but I want it to be hierarchical/recursive, where as the schema defined by YANG library bis is flat, and I want the data to also optionally be made available in YANG library.

What I am proposing here doesn't change conformance of the YANG language in any way, not does it replace YANG library.

Thanks,
Rob



 

In a somewhat similar way, when I write code, my build file specifies which libraries I depend on, and their versions, but I can leave it to the build tool to determine what those libraries themselves depend on and recursively pull in all the dependencies.



If there was a standard to load and unload modular functionality at boot-time or run-time,
then I could see why there is a need to have a standard to define YANG packages.

I agree that this is another example of where they could be useful.

Thanks,
Rob



Andy
 

 

Thanks,
Rob



Andy
 



Andy
 


I don't think the WG ever agreed on the problem that needs to be solved,
and that is still the case.

That wasn't quite my impression.  I also think that folks were busy focusing on other WG activity and didn't necessarily have the time to concentrate on this.

My draft was aiming on solving two broad problems:

   The main goals of YANG package definitions include, but are not
   restricted to:

   o  To act as a simplified YANG conformance mechanism.  Rather than
      conformance being performed against a set of individual YANG
      module revisions, conformance could also be more simply stated in
      terms of YANG packages, with a set modifications (e.g. additional
      modules, deviations, or features).

   o  To allow YANG datastore schema to be specified in a more concise
      way rather than having to list all modules and revisions.  YANG
      package definitions can be defined in documents that can be
      referenced by a URL rather than requiring explicit lists of
      modules to be shared between client and server.  Hence, a YANG
      package must contain sufficient information to allow a client or
      server to precisely construct the schema associated with the
      package.


 

In reality each server has 1 package -- its entire library.

This doesn't apply to all servers.  For a long time, as a vendor, we have had separate packages that can be independently installed, and which extend the management model to cover the new functionality.  E.g. BNG functionality could be in a separate, independently installable, package on top of the base router functionality.

For a Linux server, the manageability interface will depend on what applications have been installed.


The SEMVER work shows
that vendors are treating platforms as independent release trains, and not really
developing loadable packages.

This depends on the vendor.  The YANG versioning work is trying to find a solution that works across the industry.  I believe that the versioning requirements are different for standards developed modules, vs industry developed modules, vs vendor modules.



I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, SEMVER import)
and  the YANG Catalog can solve the module compatibility issues. It is more of a documentation
problem than a standards problem.

Having a standard YANG module that can be used to define packages is something this is useful and should be standardized.  I believe that this is better than each vendor coming up with their own solution for this problem.

Thanks,
Rob




Andy




On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:

Thanks Rob. Please see inline.

Jason

 

From: Robert Wilton <rwilton@cisco.com>
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; netmod@ietf.org
Subject: Re: initial comments on draft-rwilton-netmod-yang-packages

 

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi guys,

 

I've gotten most of the way through the draft and have some initial comments. I haven't digested the section 10 open issues yet or the examples.

 

Section 5 mentions the following:

   YANG library is augmented to allow servers to report the packages

   that they implement and to associate those packages back to

   particular datastore schema.

 

Does the combination of this draft and rfc7895bis somehow allow the same package to be advertised in 2 different datastores, but with different deviations in each datastore? I'm thinking of a case, for example, where a package is fully supported in the running but the package minus a few modules (or parts of modules) is supported in the operational datastore. There seems to be a 1:1 relationship between package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that <running> would implement package "foo", and <operational> would implement package "modified-foo".  Package "modified-foo" would import package "foo" and also specify the set of modules that contain the deviations "foo".

I didn't want a server to be able to see that I implement package "foo", but then I have all these deviations that change its behavior.  Instead, it is really implementing a different package that is based on "foo".

 

 

The packages draft doesn't include any specific leaf-list for deviations. Section 7.2 mentions that deviations could be expressed by including modules that happen to contain deviations. That seems a bit inconsistent with rfc7895bis that has a specific leaf-list of deviations (and NETCONF hello that specifically explicitly labels deviation modules).

I'm conflicted on this one.  I don't really like the deviation list in YANG library because I regard it as a duplicate source of information, and then there is a question of which source of data do you trust.  E.g. do you process a deviation in a module that is not listed in the deviations module list?

[>>JTS: ] Good point. I suppose this issue applies today already. i.e. what if one of the modules advertised in the <hello> is a module of deviations (without having been referenced by another module as a deviation module).

 

 

Section 5.1 says the package must be referentially complete. I can see the advantages of that although wondering if that might limit flexibility of partitioning modules into packages. I could imagine use cases for dividing a large set of modules into a few packages that might rev independently but can still all work together (especially if they rev in a bc manner). But maybe that just starts to introduce too much complexity?

Yes, having partial packages may be useful.  Perhaps just adding a leaf to indicate whether a package is referentially complete could be the answer here.

 

 

I didn't understand this part of section 5.1. Can you maybe illustrate with an example?

      The version/revision of a module listed in the package module list

      supercedes any version/revision of the module listed in a imported

      package module list.  This allows a package to resolve any

      conflicting implemented module versions/revisions in imported

      packages.

Probably best to see example B.3. in the appendix because it exactly illustrates this point.

Basically:
1) Packages must explicitly list all versions of all modules they define/import.
2) If two imported packages define different versions of modules, then the package that is importing them needs a way to define which version to use.
3) A package needs a way to override the version of module specified in an imported package.

[>>JTS: ] Thx. That example does help. I suppose the designer of the package needs to carefully check that the version they select can be successfully used by all the modules in the package.

I think there is a minor typo in example B.3.  The example-3-pkg is importing " example-import-1" but I believe you meant " example-import-1-pkg" (and some for import-2).

 

It might be a good idea to add a parent-version to the package module (to allow tracking lineage of packages).

Agreed, or maybe allowing a revision history like modules.  Not sure which is better here.  Packages could get a lot of updates, and a long revision history would not be helpful at all.

[>>JTS: ] I think a minimum of just specifying the direct parent is enough to build the full tree of lineage. We don't need a long history of N revisions.

 

 

I like the use of groupings. That allows a manager to use this as a building block to compose a model that has a list of packages.

OK.

 

 

Having a global list of mandatory features (vs having the mandatory feature a per-module list) means inventing the new <module-name>:<feature> format. Should we instead somehow put the mandatory features against each module of the package?

Perhaps.  My thinking here was to have the list of features high up and very easy to find/parse.

 

 

The location leaf is a uri but then the description says it must be a url (where the model can be retrieved). I do like that the namespace is separate from the location, but maybe we should make location a url type?

Yes, I was thinking that is should be a URL.

 

 

Do we need a namespace for package names in the model?

I had them in an earlier version, but I took them out, because I wasn't sure that they are really useful/required.

Defining a format to make package names themselves globally unique might be sufficient.

[>>JTS: ] I'm OK with that. It is similar to how we're finding that it is useful that YANG module names are globally unique (i.e. by naming with ietf-xxxx or companyabc-xxx).

 

 

In 7.3 we only reference module-sets and not modules. So the grouping of modules into sets and packages must be the same?

Not necessarily.

I am trying to reuse the module-set definitions as much as possible (to avoid duplication).  One issue here is that module-sets are combined then all the modules must not overlap, which doesn't make the mapping to module-sets quite so clean.

 

 

A schema can only have a single package. I think that works but it means a server would advertise multiple schemas if it wants to support multiple packages. I'm not sure if there are some downsides to that (it just surprised me).

My aim here was:
 - multiple packages are advertised in yang-library/packages
 - datastores only report that they "implement" one [top level] package version.  [The package itself might import other packages.]

If we do package selection, then for a given YANG client session, and the version of YANG library available/reported by that session, it would appear as if the server only implements one top level package for a datastore.  Different clients choosing different versions would see slightly different output depending on which package version they had selected to use.

Thanks again for the review and the comments!

Rob

 

 

 

Jason

 

 

 

From: netmod <netmod-bounces@ietf.org> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: netmod@ietf.org
Subject: [netmod] YANG Packages

 

Hi,

I've written up an ID for a potential solution for YANG packages using instance data:

Abstract
 
   This document defines YANG packages, an organizational structure
   holding a set of related YANG modules, that can be used to simplify
   the conformance and sharing of YANG schema.  It describes how YANG
   instance data documents are used to define YANG packages, and how the
   YANG library information published by a server can be augmented with
   additional packaging related information.

https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/

Potentially this work may be of use as part of the YANG versioning design team work.  In addition, if the WG likes this approach of defining YANG packages, then it might also be useful to bind a schema to a YANG instance data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs to be solved?

2) Is the approach in this draft of defining these as instance data documents a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not replacing the way that modules are reported in YANG library-bis.  Is this the right approach?  This approach tries to allow module-sets to be reused for both schema and packages, but the YANG library-bis rules for combining module-sets (i.e. no conflicts) may make this harder to really reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.

Thanks,
Rob

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--------------9702831B070CBE528C4D8EAD-- From nobody Thu Jan 31 09:45:26 2019 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 3B1C212D4F2 for ; Thu, 31 Jan 2019 09:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 3L0rvQ25Fr1t for ; Thu, 31 Jan 2019 09:45:19 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 982AD1277D2 for ; Thu, 31 Jan 2019 09:45:18 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id k15-v6so3427269ljc.8 for ; Thu, 31 Jan 2019 09:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JWIKrIneu4N0FEZKODtsnl8OHxU6LOxsQxkwUjbda+M=; b=KEy0N4fcPaW3FYpYzQ2PjDiAv+CTWSiarc92W8qpo/+NSonwNLYrsmMGcX8q8pTLQ9 RB6wwC4UDzr/U9lgvi8KOMVLZUIgj3faR+6i4UY7T7UZmxGPX4+4kw5k4cpJeG8/TxCB h7Lk9IbcVhpj9bVaINkvB7jf8HSRo54Ytqs1BsCVTPnR6hVAXzOA/pWU9Q086f0tVHyC v3aYAHqA4XSHO7JYJT0YXkvI4xBX7wrIlqzny3fj+cOymrRkUFUByS2Gc1iNSWJTGXy4 zysKakcDgEa2STqWn3W2ydHMI65Mmpu3gBhvQUTohZopdPqx4Cz1wRd+OAPulNbuYwPE kcaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JWIKrIneu4N0FEZKODtsnl8OHxU6LOxsQxkwUjbda+M=; b=HLVyziNAexRfq/B9fc3hFJziiXDJAwYg1KM+WRR6EbDwAsKTAmc50djFfsSS1wuR6D I23AZO1SVVyOV1lp0lW3NiTEU4sBSrHERrGB1wjWzuY7DX3bRFP4sS8M6K4EQ0BjOVlC i4Aev+KNkV5zwMSyinb8JqBjrF70IWiihtREQgqv0dP7tGBi7afsSfOepopRHQZt9weM sRs5p3StckEwo4jvpTFEP+3UKrnmDHQufynYd4qwn3UOQ7w61lNR2Dfyhd4UX+/y//b9 U4gkW9hOJsYIO+G3Ri2dIwUaas8UGTZp8o/GmWwB+PeXOxLDFzkeWTaoPA39FMpGCt3H qj8A== X-Gm-Message-State: AHQUAuYD0C0zLu3WpA6oT/qjfSQL0saSPj4UpIBsw4gY4MAsrSocI1oB STk/diabIkAAzBMFyG8FEQMP9RjNAnkw1/Q1y8I3Yg== X-Google-Smtp-Source: ALg8bN6WqK/Ynes6o0qXl98390vYke2V9z1KvsBH4R0YqbzJNX7zSkb+JK19wEjS3tvDlj5VU/hbXP8RgyjFpAr6eq0= X-Received: by 2002:a2e:6a13:: with SMTP id f19-v6mr22814428ljc.41.1548956716442; Thu, 31 Jan 2019 09:45:16 -0800 (PST) MIME-Version: 1.0 References: <98469d28-4d53-c5c5-6487-a873a289e073@cisco.com> <914c99e5-ca38-9e39-32dd-1b0c3ed3294e@cisco.com> <47132640-a71a-596a-6b07-253c4defb5c3@cisco.com> In-Reply-To: <47132640-a71a-596a-6b07-253c4defb5c3@cisco.com> From: Andy Bierman Date: Thu, 31 Jan 2019 09:45:04 -0800 Message-ID: To: Robert Wilton Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000db46180580c496ce" Archived-At: Subject: Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 17:45:24 -0000 --000000000000db46180580c496ce Content-Type: text/plain; charset="UTF-8" Hi, I can see some utility in a module-set artifact. Every tool has a different way of specifying a set of [module, revision, features, deviations]. The module-set has these parameters (plus other metadata) rc:yang-data module-set { container module-set { uses yanglib:module-set-parameters; } } The application purpose of the module-set is not relevant here. It could be the library subset needed for L2VPN, it could be the entire module list for a specific vendor/model/version. It could be the module-set needed to reproduce a bug. Andy On Thu, Jan 31, 2019 at 9:24 AM Robert Wilton wrote: > > On 30/01/2019 20:51, Andy Bierman wrote: > > > > On Wed, Jan 30, 2019 at 10:04 AM Robert Wilton wrote: > >> >> On 30/01/2019 17:31, Andy Bierman wrote: >> >> >> >> On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton wrote: >> >>> >>> On 30/01/2019 15:16, Andy Bierman wrote: >>> >>> >>> >>> On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton wrote: >>> >>>> Hi Andy, >>>> >>>> Thanks for the comments. >>>> On 30/01/2019 01:22, Andy Bierman wrote: >>>> >>>> Hi, >>>> >>>> I originally brought up this issue in July 2015 >>>> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ >>>> >>>> Yes. >>>> >>>> The solution I propose is different in the sense that it uses YANG >>>> instance data to define YANG packages rather than new YANG keywords. I >>>> believe that this should make it a lower cost solution to define and >>>> implement. >>>> >>>> >>>> >>> I think yangvalidator.org has a better solution that does not change >>> YANG conformance. >>> >>> Do you mean that we can just use zip files with the list of modules? >>> >> >> I don't care about the solution details yet. They are 2nd order problems. >> >> Conformance means "what modules are required to be implemented together". >> It is not clear that this problem can be solved. The augment-stmt >> defines implicit >> multi-module conformance. I am not convinced that the extra work of >> defining package conformance >> is worth it. >> >> So, I'm not proposing backing any sort of package conformance into the >> language at all. A package is just metadata that defines that a set of >> modules, at particular revisions/versions, work together and can represent >> part of a YANG schema. >> >> This is equivalent to >> - how a zip file of YANG modules provided to yangvalidator would work. >> - getting the contents of YANG library from a server (but a YANG >> packages soln can also work offline) >> - fetching the modules from YANG catalog (if they have been labelled >> appropriately), although I'm not convinced that this universally works >> today. >> > > This sort of metadata could be provided by module tags. > A vendor or SDO could define module-tags that represent packages. > > Yes, this is a different way to assigning membership, although I'm not > convinced that it is better. > > I think that such a scheme could work without versioning, but I'm not sure > that it will work so well once package versioning is considered, because to > handle versioning the tags don't just need to represent which package they > belong to, they also should identify which version of that package. > > E.g. ietf-interfaces@2014-05-08.yang might be tagged with: > "ietf-base-pkg@0.0.1" , "ietf-base-pkg@0.0.2" > , "ietf-base-pkg@1.0.0" , > ietf-base-pkg@1.1.0", ... > > If packages change quite frequently then you might find that a module > needs 50+ tags to identify which particular packages it belongs to. > > Any without knowing the package version, I don't see that there would be > enough information to build a schema since you wouldn't know which versions > of YANG modules to use. > > > > > > >> But in terms of the usability of YANG, I don't think that doing >> conformance only at the module level is really sufficient. Clients need to >> be coding against sets of modules at particular versions that are known to >> work together, and known that multiple server vendors will implement. >> >> A pick and mix appropriate to module revisions doesn't seem to help >> anyone. >> >> >> > I get all the different components and variables one might have for a > package. > I am not as convinced (as in 2015) that standard packages could be simple > and widely deployed.. > Now it seems vendors implement an ad-hoc subset + additions to everything. > It doesn't help to define a new package variant to match the vendor > implementation. > The YANG library can do that already. > > YANG library is only on the box at the moment, and it just gives a flat > list of modules. > I would like it to also be available off the box and have more structure. > > E.g. I would like IETF to define an L2VPN package that contains the basic > set of YANG modules that a device that supports L2VPN services would be > expected to implement at a minimum. > > Then, rather that checking the output of YANG library to see that it has > all the necessary modules to implement an L2VPN service, I could instead > check whether the package implemented by the device imports the L2VPN > package. And if it does import that package, I can then also see which > version of that package it implements (rather than checking every module > version). > > > You seem more optimistic than me that the industry is actually ready, > willing, and able > to implement standard YANG packages. > > If we want YANG to be properly successful then I see that it has go > there. But nobody can do this today until there is a way that such > packages can be defined, and versioned, and we start defining what these > standard packages look like. > > > > > > >> The issue of what modules does vendor A implement is not a conformance >> problem. >> It is just more metadata and YANG Catalog is focused on providing that >> data. >> >> Does YANG catalog indicate the set of IETF modules that I would need to >> implement L2VPN services on a device? >> >> > This seems like a separate problem, but actually it can help by searching > a lot of known modules. > In order to know what vendor A, B, and C have in common, you need to get > the catalog info for each vendor. > > Module tags can also solve this problem. > > But when there are multiple vendors with multiple devices, with multiple > versions of software available then this looks like a hard problem to solve. > > I would like someone (or a program) to be able to look at a package > definition file, and determine if it implements what is required, and what > software version is needed, and whether they are deviations that matter. > > When my client then connects to that device, I would like the client to be > able to check that it implements that modules that I expect it to. I would > strongly prefer if this could be done by returning a small amount of data, > rather than a list of 1000 modules/sub-modules for every server that I > connect to. > > Module tags won't tell the client that it implements all the required > modules that implement the L2VPN service, it will just indicate that > implements some modules which can be used to implement an L2VPN service. > > > > >> Module tags could be used to do this (another packaging solution), but >> this would cause a proliferation of tags when it comes to versioning, since >> I don't think that you can cleanly bake semver into module tags. >> >> >> >> I don't really see how this helps. >>> >>> Consider: >>> - server vendor A, implements some subset of the OpenConfig YANG >>> modules, each at a particular version, along with some deviations and >>> vendor augmentations. >>> - server vendor B, implements the same subset of the OpenConfig YANG >>> modules, but at different versions, along with some deviations and vendor >>> augmentations. >>> - server vendor C, implements a slightly different set of the OpenConfig >>> YANG modules, but at different versions, along with some deviations and >>> vendor augmentations. >>> >>> As a client, how do I know what module versions to code against, when I >>> want to work with devices provided by all three vendors? >>> >> >> >> The vendors publish their implementation details on yangcatalog and you >> get the info >> and see what modules are in common. >> >> There are only market requirements determining what group of modules has >> to exist >> in an implementation. It is not clear to me that formalizing these >> requirements >> is something the industry will do effectively. Module tags already >> provide a way >> to conceptually group modules together. >> >> Seems like every vendor has openconfig, foo-openconfig, and >> foo-openconfig-deviations >> so that there are no agreed upon subsets. Even if openconfig had properly >> documented >> subsets, would your client even be able to code to it (ignoring add-ons >> and deviations). >> >> I think that answer will converge on yes, I don't know how long it will >> take. It would probably be better if at the time that protocol >> specifications are written, that the authors of the specifications also >> write the YANG modules to manage them at the same time. >> >> >> I might be wrong, but I think that the OC solution is use git tags, so >>> they tag sets of modules that are expected to work together and also to >>> provide a linear release history of their sets of modules. So, if everyone >>> implements the module versions associated with a git tag then it should >>> convert a two dimensional problem of module revisions into a linear >>> problem. The YANG packages draft is aiming to provide a solution to this >>> problem that doesn't require the use of git, or sending zip files of >>> modules around. >>> >> >> At the moment, it seems that everyone is doing this in different ways: >>> - Yumawork customers/servers use zip files of modules for conformance. >>> >> >> Not sure what this means. >> Actually the server libraries can be loaded and unloaded. >> Module can be standalone libraries or grouped as bundles. >> But this seems like an implementation detail, unrelated to conformance. >> >> >> - OpenConfig client/server implementations use git tags, or git >>> refpoints. >>> - Cisco customers use the contents of directories on github YangModels. >>> >>> Finally, this draft doesn't change YANG conformance, it just expresses >>> it in what is intended to be a simpler way. >>> >> >> It adds another conformance system to maintain. >> The language only recognizes module to module interfaces, not package to >> package. >> >> I propose that at the language level conformance is at the module level >> (modulo import-by-version). >> >> >> That adds more complexity. It doesn't take away any complexity. >> >> It is meant to be a simpler way of packaging up, and trying to control >> and manage the complexity that already exists today. >> >> E.g. I could give a YANG compiler the name, version, and location of a >> package and tell it to build the entire schema associated with that >> package. >> > > This is a tool implementation detail, not a conformance issue. > It would be nice to have a standard format for the YANG library for a tool > to use. > You seem to be proposing an artifact containing ietf-yang-library > information. > That seems OK to me, but it should not have anything to do with > conformance. > It is just a standard way to express a module-set in a yang-data artifact. > > Yes, what I am proposing is close to a file containing ietf-yang-library > information, but I want it to be hierarchical/recursive, where as the > schema defined by YANG library bis is flat, and I want the data to also > optionally be made available in YANG library. > > What I am proposing here doesn't change conformance of the YANG language > in any way, not does it replace YANG library. > > Thanks, > Rob > > > > > >> In a somewhat similar way, when I write code, my build file specifies >> which libraries I depend on, and their versions, but I can leave it to the >> build tool to determine what those libraries themselves depend on and >> recursively pull in all the dependencies. >> >> >> >> If there was a standard to load and unload modular functionality at >> boot-time or run-time, >> then I could see why there is a need to have a standard to define YANG >> packages. >> >> I agree that this is another example of where they could be useful. >> >> Thanks, >> Rob >> >> >> > Andy > > >> >> >>> Thanks, >>> Rob >>> >>> >>> >> Andy >> >> >>> >>> >>> Andy >>> >>> >>>> >>>> I don't think the WG ever agreed on the problem that needs to be solved, >>>> and that is still the case. >>>> >>>> That wasn't quite my impression. I also think that folks were busy >>>> focusing on other WG activity and didn't necessarily have the time to >>>> concentrate on this. >>>> >>>> My draft was aiming on solving two broad problems: >>>> >>>> The main goals of YANG package definitions include, but are not >>>> restricted to: >>>> >>>> o To act as a simplified YANG conformance mechanism. Rather than >>>> conformance being performed against a set of individual YANG >>>> module revisions, conformance could also be more simply stated in >>>> terms of YANG packages, with a set modifications (e.g. additional >>>> modules, deviations, or features). >>>> >>>> o To allow YANG datastore schema to be specified in a more concise >>>> way rather than having to list all modules and revisions. YANG >>>> package definitions can be defined in documents that can be >>>> referenced by a URL rather than requiring explicit lists of >>>> modules to be shared between client and server. Hence, a YANG >>>> package must contain sufficient information to allow a client or >>>> server to precisely construct the schema associated with the >>>> package. >>>> >>>> >>>> >>>> >>>> >>>> In reality each server has 1 package -- its entire library. >>>> >>>> This doesn't apply to all servers. For a long time, as a vendor, we >>>> have had separate packages that can be independently installed, and which >>>> extend the management model to cover the new functionality. E.g. BNG >>>> functionality could be in a separate, independently installable, package on >>>> top of the base router functionality. >>>> >>>> For a Linux server, the manageability interface will depend on what >>>> applications have been installed. >>>> >>>> >>>> The SEMVER work shows >>>> that vendors are treating platforms as independent release trains, and >>>> not really >>>> developing loadable packages. >>>> >>>> This depends on the vendor. The YANG versioning work is trying to find >>>> a solution that works across the industry. I believe that the versioning >>>> requirements are different for standards developed modules, vs industry >>>> developed modules, vs vendor modules. >>>> >>>> >>>> >>>> I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, >>>> SEMVER import) >>>> and the YANG Catalog can solve the module compatibility issues. It is >>>> more of a documentation >>>> problem than a standards problem. >>>> >>>> Having a standard YANG module that can be used to define packages is >>>> something this is useful and should be standardized. I believe that this >>>> is better than each vendor coming up with their own solution for this >>>> problem. >>>> >>>> Thanks, >>>> Rob >>>> >>>> >>>> >>>> >>>> Andy >>>> >>>> >>>> >>>> >>>> On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) < >>>> jason.sterne@nokia.com> wrote: >>>> >>>>> Thanks Rob. Please see inline. >>>>> >>>>> Jason >>>>> >>>>> >>>>> >>>>> *From:* Robert Wilton >>>>> *Sent:* Thursday, January 24, 2019 1:16 PM >>>>> *To:* Sterne, Jason (Nokia - CA/Ottawa) ; >>>>> netmod@ietf.org >>>>> *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages >>>>> >>>>> >>>>> >>>>> Hi Jason, >>>>> >>>>> Thanks for the review and comments. >>>>> >>>>> I've put some responses inline ... >>>>> >>>>> On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> >>>>> >>>>> I've gotten most of the way through the draft and have some initial >>>>> comments. I haven't digested the section 10 open issues yet or the examples. >>>>> >>>>> >>>>> >>>>> Section 5 mentions the following: >>>>> >>>>> YANG library is augmented to allow servers to report the packages >>>>> >>>>> that they implement and to associate those packages back to >>>>> >>>>> particular datastore schema. >>>>> >>>>> >>>>> >>>>> Does the combination of this draft and rfc7895bis somehow allow the >>>>> same package to be advertised in 2 different datastores, but with different >>>>> deviations in each datastore? I'm thinking of a case, for example, where a >>>>> package is fully supported in the running but the package minus a few >>>>> modules (or parts of modules) is supported in the operational datastore. >>>>> There seems to be a 1:1 relationship between package and rfc7895bis schema. >>>>> >>>>> So, the intention is no, not directly. >>>>> >>>>> My aim here is that would implement package "foo", and >>>>> would implement package "modified-foo". Package >>>>> "modified-foo" would import package "foo" and also specify the set of >>>>> modules that contain the deviations "foo". >>>>> >>>>> I didn't want a server to be able to see that I implement package >>>>> "foo", but then I have all these deviations that change its behavior. >>>>> Instead, it is really implementing a different package that is based on >>>>> "foo". >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The packages draft doesn't include any specific leaf-list for >>>>> deviations. Section 7.2 mentions that deviations could be expressed by >>>>> including modules that happen to contain deviations. That seems a bit >>>>> inconsistent with rfc7895bis that has a specific leaf-list of deviations >>>>> (and NETCONF hello that specifically explicitly labels deviation modules). >>>>> >>>>> I'm conflicted on this one. I don't really like the deviation list in >>>>> YANG library because I regard it as a duplicate source of information, and >>>>> then there is a question of which source of data do you trust. E.g. do you >>>>> process a deviation in a module that is not listed in the deviations module >>>>> list? >>>>> >>>>> *[>>JTS: ] Good point. I suppose this issue applies today already. >>>>> i.e. what if one of the modules advertised in the is a module of >>>>> deviations (without having been referenced by another module as a deviation >>>>> module).* >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Section 5.1 says the package must be referentially complete. I can see >>>>> the advantages of that although wondering if that might limit flexibility >>>>> of partitioning modules into packages. I could imagine use cases for >>>>> dividing a large set of modules into a few packages that might rev >>>>> independently but can still all work together (especially if they rev in a >>>>> bc manner). But maybe that just starts to introduce too much complexity? >>>>> >>>>> Yes, having partial packages may be useful. Perhaps just adding a >>>>> leaf to indicate whether a package is referentially complete could be the >>>>> answer here. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I didn't understand this part of section 5.1. Can you maybe illustrate >>>>> with an example? >>>>> >>>>> The version/revision of a module listed in the package module >>>>> list >>>>> >>>>> supercedes any version/revision of the module listed in a >>>>> imported >>>>> >>>>> package module list. This allows a package to resolve any >>>>> >>>>> conflicting implemented module versions/revisions in imported >>>>> >>>>> packages. >>>>> >>>>> Probably best to see example B.3. in the appendix because it exactly >>>>> illustrates this point. >>>>> >>>>> Basically: >>>>> 1) Packages must explicitly list all versions of all modules they >>>>> define/import. >>>>> 2) If two imported packages define different versions of modules, then >>>>> the package that is importing them needs a way to define which version to >>>>> use. >>>>> 3) A package needs a way to override the version of module specified >>>>> in an imported package. >>>>> >>>>> *[>>JTS: ] Thx. That example does help. I suppose the designer of the >>>>> package needs to carefully check that the version they select can be >>>>> successfully used by all the modules in the package. * >>>>> >>>>> *I think there is a minor typo in example B.3. The example-3-pkg is >>>>> importing "* *example-import-1" but I believe you meant "* *example-import-1-pkg" >>>>> (and some for import-2).* >>>>> >>>>> >>>>> >>>>> It might be a good idea to add a parent-version to the package module >>>>> (to allow tracking lineage of packages). >>>>> >>>>> Agreed, or maybe allowing a revision history like modules. Not sure >>>>> which is better here. Packages could get a lot of updates, and a long >>>>> revision history would not be helpful at all. >>>>> >>>>> *[>>JTS: ] I think a minimum of just specifying the direct parent is >>>>> enough to build the full tree of lineage. We don't need a long history of N >>>>> revisions.* >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I like the use of groupings. That allows a manager to use this as a >>>>> building block to compose a model that has a list of packages. >>>>> >>>>> OK. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Having a global list of mandatory features (vs having the mandatory >>>>> feature a per-module list) means inventing the new : >>>>> format. Should we instead somehow put the mandatory features against each >>>>> module of the package? >>>>> >>>>> Perhaps. My thinking here was to have the list of features high up >>>>> and very easy to find/parse. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The location leaf is a uri but then the description says it must be a >>>>> url (where the model can be retrieved). I do like that the namespace is >>>>> separate from the location, but maybe we should make location a url type? >>>>> >>>>> Yes, I was thinking that is should be a URL. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Do we need a namespace for package names in the model? >>>>> >>>>> I had them in an earlier version, but I took them out, because I >>>>> wasn't sure that they are really useful/required. >>>>> >>>>> Defining a format to make package names themselves globally unique >>>>> might be sufficient. >>>>> >>>>> *[>>JTS: ] I'm OK with that. It is similar to how we're finding that >>>>> it is useful that YANG module names are globally unique (i.e. by naming >>>>> with ietf-xxxx or companyabc-xxx).* >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> In 7.3 we only reference module-sets and not modules. So the grouping >>>>> of modules into sets and packages must be the same? >>>>> >>>>> Not necessarily. >>>>> >>>>> I am trying to reuse the module-set definitions as much as possible >>>>> (to avoid duplication). One issue here is that module-sets are combined >>>>> then all the modules must not overlap, which doesn't make the mapping to >>>>> module-sets quite so clean. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> A schema can only have a single package. I think that works but it >>>>> means a server would advertise multiple schemas if it wants to support >>>>> multiple packages. I'm not sure if there are some downsides to that (it >>>>> just surprised me). >>>>> >>>>> My aim here was: >>>>> - multiple packages are advertised in yang-library/packages >>>>> - datastores only report that they "implement" one [top level] >>>>> package version. [The package itself might import other packages.] >>>>> >>>>> If we do package selection, then for a given YANG client session, and >>>>> the version of YANG library available/reported by that session, it would >>>>> appear as if the server only implements one top level package for a >>>>> datastore. Different clients choosing different versions would see >>>>> slightly different output depending on which package version they had >>>>> selected to use. >>>>> >>>>> Thanks again for the review and the comments! >>>>> >>>>> Rob >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Jason >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* netmod *On >>>>> Behalf Of *Robert Wilton >>>>> *Sent:* Thursday, December 20, 2018 12:45 PM >>>>> *To:* netmod@ietf.org >>>>> *Subject:* [netmod] YANG Packages >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I've written up an ID for a potential solution for YANG packages using >>>>> instance data: >>>>> >>>>> Abstract >>>>> >>>>> >>>>> >>>>> This document defines YANG packages, an organizational structure >>>>> >>>>> holding a set of related YANG modules, that can be used to simplify >>>>> >>>>> the conformance and sharing of YANG schema. It describes how YANG >>>>> >>>>> instance data documents are used to define YANG packages, and how the >>>>> >>>>> YANG library information published by a server can be augmented with >>>>> >>>>> additional packaging related information. >>>>> >>>>> https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ >>>>> >>>>> Potentially this work may be of use as part of the YANG versioning >>>>> design team work. In addition, if the WG likes this approach of defining >>>>> YANG packages, then it might also be useful to bind a schema to a YANG >>>>> instance data document. >>>>> >>>>> Some questions for members of the WG: >>>>> >>>>> 1) Do members of the WG agree that YANG packages is something that >>>>> needs to be solved? >>>>> >>>>> 2) Is the approach in this draft of defining these as instance data >>>>> documents a good starting point? >>>>> >>>>> 3) This approach augments YANG library-bis, reusing module-sets, but >>>>> not replacing the way that modules are reported in YANG library-bis. Is >>>>> this the right approach? This approach tries to allow module-sets to be >>>>> reused for both schema and packages, but the YANG library-bis rules for >>>>> combining module-sets (i.e. no conflicts) may make this harder to really >>>>> reuse the module-sets for both purposes. >>>>> >>>>> Of course, any other comments or feedback is welcome and appreciated. >>>>> >>>>> Thanks, >>>>> Rob >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>> --000000000000db46180580c496ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I can see some utility in a module-= set artifact.
Every tool has a different way of specifying a set = of [module, revision, features, deviations].
The module-set has t= hese parameters (plus other metadata)

=C2=A0 =C2= =A0 rc:yang-data module-set {
=C2=A0 =C2=A0 =C2=A0 container modu= le-set {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uses yanglib:module-s= et-parameters;
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2= =A0 }


The application purpose of th= e module-set is not relevant here.
It could be the library su= bset needed for L2VPN, it could be the entire module list
for a s= pecific vendor/model/version. It could be the module-set needed=C2=A0
=
to reproduce a bug.


Andy
=



On Thu, Jan 31, 2019 at 9:24 AM Robert Wilton= <rwilton@cisco.com> wrote:<= br>
=20 =20 =20


On 30/01/201= 9 20:51, Andy Bierman wrote:
=20


On Wed, Jan 30, 2019 at 10:04 AM Robert Wilton <rwilton@cisco.com> wrote:


On 30/01/2019 17:31, Andy Bierman wrote:


On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton <rwilton@cisco.com> wrote:


On 30/01/2019 15:16, Andy Bierman wrote:


On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,

Thanks for the comments.

On 30/01/2019 01:22, Andy Bierman wrote:
Hi,

I originally brought up this issue in July 2015

Yes.

The solution I propose is different in the sense that it uses YANG instance data to define YANG packages rather than new YANG keywords.=C2=A0=C2=A0 I believe that th= is should make it a lower cost solution to define and implement.



I think yangvalidator.org has a better solution that does not change YANG conformance.

Do you mean that we can just use zip files with the list of modules?


I don't care about the solution details yet. They are 2nd order problems.

Conformance means "what modules are required = to be implemented together".
It is not clear that this problem can be solved.=C2=A0 The augment-stmt defines implicit
multi-module conformance.=C2=A0 I am not convinced that the extra work of defining package conformance
is worth it.

So, I'm not proposing backing any sort of package conformance into the language at all.=C2=A0 A package is ju= st metadata that defines that a set of modules, at particular revisions/versions, work together and can represent part of a YANG schema.

This is equivalent to
=C2=A0- how a zip file of YANG modules provided to yangvalidator would work.
=C2=A0- getting the contents of YANG library from a server (but a YANG packages soln can also work offline)
=C2=A0- fetching the modules from YANG catalog (if they hav= e been labelled appropriately), although I'm not convince= d that this universally works today.


This sort of metadata could be provided by module tags.
A vendor or SDO could define module-tags that represent packages.

Yes, this is a different way to assigning membership, although I'm not convinced that it is better.

I think that such a scheme could work without versioning, but I'= m not sure that it will work so well once package versioning is considered, because to handle versioning the tags don't just need to represent which package they belong to, they also should identify which version of that package.

E.g. ietf-i= nterfaces@2014-05-08.yang might be tagged with:
"ietf-base-pkg@0.0.1= ", "ietf-base-pkg@0= .0.2", "ietf-base-pkg@1.0.0= ", ietf-base-pkg@1.1.= 0", ...

If packages change quite frequently then you might find that a module needs 50+ tags to identify which particular packages it belongs to.

Any without knowing the package version, I don't see that there would be enough information to build a schema since you wouldn't know which versions of YANG modules to use.




=C2=A0

But in terms of the usability of YANG, I don't think that doing conformance only at the module level is really sufficient.=C2=A0 Clients need to be coding against sets of modules at particular versions that are known to work together, and known that multiple server vendors will implement.

A pick and mix appropriate to module revisions doesn't seem to help anyone.



I get all the different components and variables one might have for a package.
I am not as convinced (as in 2015) that standard packages could be simple and widely deployed..
Now it seems vendors implement an ad-hoc subset=C2=A0+ additions to everything.
It doesn't help to define a new package variant to match the vendor implementation.
The YANG library can do that already.

YANG library is only on the box at the moment, and it just gives a flat list of modules.
I would like it to also be available off the box and have more structure.

E.g. I would like IETF to define an L2VPN package that contains the basic set of YANG modules that a device that supports L2VPN services would be expected to implement at a minimum.

Then, rather that checking the output of YANG library to see that it has all the necessary modules to implement an L2VPN service, I could instead check whether the package implemented by the device imports the L2VPN package.=C2=A0 And if it does import that package, = I can then also see which version of that package it implements (rather than checking every module version).


You seem more optimistic than me that the industry is actually ready, willing, and able
to implement standard YANG packages.

If we want YANG to be properly successful then I see that it has go there.=C2=A0 But nobody can do this today until there is a way tha= t such packages can be defined, and versioned, and we start defining what these standard packages look like.






The issue of what modules does vendor A implement is not a conformance problem.
It is just more metadata and YANG Catalog is focused on providing that data.

Does YANG catalog indicate the set of IETF modules that I would need to implement L2VPN services on a device?


This seems like a separate problem, but actually it can help by searching a lot of known modules.
In order to know what vendor A, B, and C have in common, you need to get the catalog info for each vendor.

Module tags can also solve this problem.

But when there are multiple vendors with multiple devices, with multiple versions of software available then this looks like a hard problem to solve.

I would like someone (or a program) to be able to look at a package definition file, and determine if it implements what is required, and what software version is needed, and whether they are deviations that matter.

When my client then connects to that device, I would like the client to be able to check that it implements that modules that I expect it to.=C2=A0 I would strongly prefer if this could be done by returning a small amount of data, rather than a list of 1000 modules/sub-modules for every server that I connect to.

Module tags won't tell the client that it implements all the required modules that implement the L2VPN service, it will just indicate that implements some modules which can be used to implement an L2VPN service.


=C2=A0

Module tags could be used to do this (another packaging solution), but this would cause a proliferation of tags when it comes to versioning, since I don't think that you can cleanly bake semver into module tags.



I don't really see how this helps.

Consider:
- server vendor A, implements some subset of the OpenConfig YANG modules, each at a particular version, along with some deviations and vendor augmentations.
- server vendor B, implements the same subset of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations.
- server vendor C, implements a slightly different set of the OpenConfig YANG modules, but at different versions, along with some deviations and vendor augmentations.

As a client, how do I know what module versions to code against, when I want to work with devices provided by all three vendors?



The vendors publish their implementation details on yangcatalog and you get the info
and see what modules are in common.

There are only market requirements determining what group of modules has to exist
in an implementation.=C2=A0 It is not clear to me that formalizing these requirements
is something the industry will do effectively.=C2= =A0 Module tags already provide a way
to conceptually group modules together.

Seems like every vendor has openconfig, foo-openconfig, and foo-openconfig-deviations
so that there are no agreed upon subsets. Even if openconfig had properly documented
subsets, would your client even be able to code to it (ignoring add-ons and deviations).

I think that answer will converge on yes, I don't know how long it will take.=C2=A0 It would probably be better if at the time that protocol specifications are written, that the authors of the specifications also write the YANG modules to manage them at the same time.


I might be wrong, but I think that the OC solution is use git tags, so they tag sets of modules that are expected to work together and also to provide a linear release history of their sets of modules.=C2=A0 So, if everyone implements the module versions associated with a git tag then it should convert a two dimensional problem of module revisions into a linear problem.=C2=A0 The YANG packages draft is aiming to provide a solution to this problem that doesn't require the use of git, or sending zip files of modules around.


At the moment, it seems that everyone is doing this in different ways:
=C2=A0- Yumawork customers/servers use zip files = of modules for conformance.


Not sure what this means.
Actually the server libraries can be loaded and unloaded.
Module can be standalone libraries or grouped as bundles.
But this seems like an implementation detail, unrelated to conformance.


=C2=A0- OpenConfig client/server implementation= s use git tags, or git refpoints.
=C2=A0- Cisco customers use the contents of directories on github YangModels.

Finally, this draft doesn't change YANG conformance, it just expresses it in what is intended to be a simpler way.


It adds another conformance system to maintain.
The language only recognizes module to module interfaces, not package to package.

I propose that at the language level conformance is at the module level (modulo import-by-version).


That adds more complexity. It doesn't take awa= y any complexity.

It is meant to be a simpler way of packaging up, and trying to control and manage the complexity that already exists today.

E.g. I could give a YANG compiler the name, version, and location of a package and tell it to build the entire schema associated with that package.=C2=A0


This is a tool implementation detail, not a conformance issue.
It would be nice to have a standard format for the YANG library for a tool to use.
You seem to be proposing an artifact containing ietf-yang-library information.
That seems OK to me, but it should not have anything to do with conformance.
It is just a standard way to express a module-set in a yang-data artifact.

Yes, what I am proposing is close to a file containing ietf-yang-library information, but I want it to be hierarchical/recursive, where as the schema defined by YANG library bis is flat, and I want the data to also optionally be made available in YANG library.

What I am proposing here doesn't change conformance of the YANG language in any way, not does it replace YANG library.

Thanks,
Rob



=C2=A0

In a somewhat similar way, when I write code, my build file specifies which libraries I depend on, and their versions, but I can leave it to the build tool to determine what those libraries themselves depend on and recursively pull in all the dependencies.



If there was a standard to load and unload modular functionality at boot-time or run-time,
then I could see why there is a need to have a standard to define YANG packages.

I agree that this is another example of where they could be useful.

Thanks,
Rob



Andy
=C2=A0

=C2=A0

Thanks,
Rob



Andy
=C2=A0



Andy
=C2=A0


I don't think the WG ever agreed on the problem that needs to be solved,
and that is still the case.

That wasn't quite my impression.= =C2=A0 I also think that folks were busy focusing on other WG activity and didn't necessarily have the time to concentrate on this.

My draft was aiming on solving two broad problems:

   The main goals o=
f YANG package definitions include, but are not
   restricted to:

   o  To act as a simplified YANG conformance mechanism.  Rather than
      conformance being performed against a set of individual YANG
      module revisions, conformance could also be more simply stated in
      terms of YANG packages, with a set modifications (e.g. additional
      modules, deviations, or features).

   o  To allow YANG datastore schema to be specified in a more concise
      way rather than having to list all modules and revisions.  YANG
      package definitions can be defined in documents that can be
      referenced by a URL rather than requiring explicit lists of
      modules to be shared between client and server.  Hence, a YANG
      package must contain sufficient information to allow a client or
      server to precisely construct the schema associated with the
      package.


=C2=A0

In reality each server has 1 package -- its entire library.

This doesn't apply to all servers.= =C2=A0 For a long time, as a vendor, we have had separate packages that can be independently installed, and which extend the management model to cover the new functionality.=C2=A0 E.g. BNG functionality could be in a separate, independently installable, package on top of the base router functionality.

For a Linux server, the manageability interface will depend on what applications have been installed.


The SEMVER work shows
that vendors are treating platforms as independent release trains, and not really
developing loadable packages.

This depends on the vendor.=C2=A0 The YANG versioning work is trying to find a solution that works across the industry.=C2=A0 I believe that the versioning requirements are different for standards developed modules, vs industry developed modules, vs vendor modules.



I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, SEMVER import)
and=C2=A0 the YANG Catalog can solve the module compatibility issues. It is more of a documentation
problem than a standards problem.

Having a standard YANG module that can be used to define packages is something this is useful and should be standardized.=C2=A0 I believe that this is better than each vendor coming up with their own solution for this problem.

Thanks,
Rob




Andy




On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:

Thanks Rob. Please see inline.

Jason

=C2=A0

From: Robert Wilton <rwilton@cisco.com&g= t;
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.co= m>; netmod@ietf.org
Subject: Re: initial comments on draft-rwilton-netmod-= yang-packages

=C2=A0=

Hi Jason,

Thanks for the review and comments.

I've put some response= s inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi guys,

=C2=A0

I've gotten most of the way through the dr= aft and have some initial comments. I haven't digested th= e section 10 open issues yet or the examples.

=C2=A0

Section 5 mentions the following:

=C2=A0=C2=A0 YANG library is augmented to allo= w servers to report the packages

=C2=A0=C2=A0 that they implement and to associ= ate those packages back to=

=C2=A0=C2=A0 particular datastore schema.

=C2=A0

Does the combination of this draft and rfc7895bis somehow allow the same package to be advertised in 2 different datastores, but with different deviations in each datastore? I'm thinking of a case, for example, where a package is fully supported in the running but the package minus a few modules (or parts of modules) is supported in the operational datastore. There seems to be a 1:1 relationship between package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that <running> would implement package "foo= ", and <operational> would implement package "modified-foo".= =C2=A0 Package "modified-foo" wo= uld import package "foo&qu= ot; and also specify the set of modules that contain the deviations "foo".=

I didn't want a server to be able to see that I implement package "foo= ", but then I have all these deviations that change its behavior.=C2=A0 Instead, it is really implementing a different package that is based on "foo".

=C2=A0

=C2=A0

The packages draft doesn't include any spe= cific leaf-list for deviations. Section 7.2 mentions that deviations could be expressed by including modules that happen to contain deviations. That seems a bit inconsistent with rfc7895bis that has a specific leaf-list of deviations (and NETCONF hello that specifically explicitly labels deviation modules).

I'm conflicted on this one.=C2=A0 I don't real= ly like the deviation list in YANG library because I regard it as a duplicate source of information, and then there is a question of which source of data do you trust.=C2=A0 E.g. do yo= u process a deviation in a module that is not listed in the deviations module list?

[>>JTS: ] Good point. I suppose this issue applies today already. i.e. what if one of the modules advertised in the <hello> is a module of deviations (without having been referenced by another module as a deviation module).

=C2=A0

=C2=A0

Section 5.1 says the package must be referentially complete. I can see the advantages of that although wondering if that might limit flexibility of partitioning modules into packages. I could imagine use cases for dividing a large set of modules into a few packages that might rev independently but can still all work together (especially if they rev in a bc manner). But maybe that just starts to introduce too much complexity?

Yes, having partial packages may be useful.=C2= =A0 Perhaps just adding a leaf to indicate whether a package is referentially complete could be the answer here.

=C2=A0

=C2=A0

I didn't understand this part of section 5= .1. Can you maybe illustrate with an example?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The version/rev= ision of a module listed in the package module list

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 supercedes any = version/revision of the module listed in a imported

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 package module = list.=C2=A0 This allows a package to resolve any

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 conflicting imp= lemented module versions/revisions in imported

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 packages.

Probably best to see example B.3. in the appendix because it exactly illustrates this point.

Basically:
1) Packages must explicitly list all versions of all modules they define/import.
2) If two imported packages define different versions of modules, then the package that is importing them needs a way to define which version to use.
3) A package needs a way to override the version of module specified in an imported package.

[>>JTS: ] Thx. That example does help. I suppose the designer of the package needs to carefully check that the version they select can be successfully used by all the modules in the package.

I think there is a minor typo in example B.3.=C2=A0 Th= e example-3-pkg is importing " example-import-1" but I believe you meant " example-import-1-pkg" (and some for import-2).=

=C2=A0

It might be a good idea to add a parent-versio= n to the package module (to allow tracking lineage of packages).

Agreed, or maybe allowing a revision history like modules.=C2=A0 Not sure which is better here.=C2=A0 Packages could get a lot of updates, and a long revision history would not be helpful at all.

[>>JTS: ] I think a minimum of just specifying the direct parent is enough to build the full tree of lineage. We don't need a long history of N revisions.=

=C2=A0

=C2=A0

I like the use of groupings. That allows a manager to use this as a building block to compose a model that has a list of packages.

OK.

=C2=A0

=C2=A0

Having a global list of mandatory features (vs having the mandatory feature a per-module list) means inventing the new <module-name>:<= ;feature> format. Should we instead somehow put the mandatory features against each module of the package?

Perhaps.=C2=A0 My thinking here was to have the list of features high up and very easy to find/parse.

=C2=A0

=C2=A0

The location leaf is a uri but then the description says it must be a url (where the model can be retrieved). I do like that the namespace is separate from the location, but maybe we should make location a url type?

Yes, I was thinking that is should be a URL.

=C2=A0

=C2=A0

Do we need a namespace for package names in the model?

I had them in an earlier version, but I took them out, because I wasn't sure that they are really useful/required.

Defining a format to make package names themselves globally unique might be sufficient.

[>>JTS: ] I'm OK with that. It is similar to how we're finding tha= t it is useful that YANG module names are globally unique (i.e. by naming with ietf-xxxx or companyabc-xxx).

=C2=A0

=C2=A0

In 7.3 we only reference module-sets and not modules. So the grouping of modules into sets and packages must be the same?

Not necessarily.

I am trying to reuse the module-set definitions as much as possible (to avoid duplication).=C2=A0 One iss= ue here is that module-sets are combined then all the modules must not overlap, which doesn't make the mapping to module-sets quite so clean.

=C2=A0

=C2=A0

A schema can only have a single package. I think that works but it means a server would advertise multiple schemas if it wants to support multiple packages. I'm not sure if there are some downsides to that (it just surprised me).

My aim here was:
=C2=A0- multiple packages a= re advertised in yang-library/packages
=C2=A0- datastores only report that they "implement" one [= top level] package version.=C2= =A0 [The package itself might import other packages.]

If we do package selection, then for a given YANG client session, and the version of YANG library available/reported by that session, it would appear as if the server only implements one top level package for a datastore.=C2=A0 Different clients choosing different versions would see slightly different output depending on which package version they had selected to use.

Thanks again for the review and the comments!

Rob

=C2=A0

=C2=A0

=C2=A0

Jason

=C2=A0

=C2=A0

=C2=A0

From: netmod <netmod-bounces@ietf.= org> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: netmod@ietf.org
Subject: [netmod] YANG Packages

= =C2=A0

Hi,

I've written up an ID for a potential solution for YANG packages using instance data:

Abstract
=C2=A0
=C2=A0=C2=A0 This document defines YANG packages, an org=
anizational structure
=C2=A0=C2=A0 holding a set of related YANG modules, that=
 can be used to simplify
=C2=A0=C2=A0 the conformance and sharing of YANG schema.=
=C2=A0 It describes how YANG
=C2=A0=C2=A0 instance data documents are used to define =
YANG packages, and how the
=C2=A0=C2=A0 YANG library information published by a ser=
ver can be augmented with
=C2=A0=C2=A0 additional packaging related information.

https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/<= /p>

Potentially this work may be of use as part of the YANG versioning design team work.=C2=A0 In addition, if the WG likes this approach of defining YANG packages, then it might also be useful to bind a schema to a YANG instance data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs to be solved?

2) Is the approach in this draft of defining these as instance data documents a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not replacing the way that modules are reported in YANG library-bis.=C2=A0 Is this the right approach?=C2=A0 This approach tries to allow module-sets to be reused for both schema and packages, but the YANG library-bis rules for combining module-sets (i.e. no conflicts) may make this harder to really reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.

Thanks,
Rob

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