From nobody Wed Mar 1 00:06:28 2017 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 DDC841294C9; Wed, 1 Mar 2017 00:06:27 -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, RP_MATCHES_RCVD=-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 WODEu3V57VBG; Wed, 1 Mar 2017 00:06:26 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B8C1294C8; Wed, 1 Mar 2017 00:06:25 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E865F788; Wed, 1 Mar 2017 09:06:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id biaNavK0AV0D; Wed, 1 Mar 2017 09:06:22 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Mar 2017 09:06:23 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7A85200D0; Wed, 1 Mar 2017 09:06:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9fDq1EvrOdzi; Wed, 1 Mar 2017 09:06:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E8E2200CD; Wed, 1 Mar 2017 09:06:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 007493E8DF6A; Wed, 1 Mar 2017 09:06:26 +0100 (CET) Date: Wed, 1 Mar 2017 09:06:26 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20170301080626.GC74969@elstar.local> Mail-Followup-To: Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 08:06:28 -0000 On Tue, Feb 28, 2017 at 11:41:35PM +0000, Kent Watsen wrote: > > Hi NETMOD WG, > > Please find below draft-2 having the following changes: > - clarified responsibility 'c' > - s/encoding/representation/g > - moved intf-ext-yang from Oct to Dec > So are we going through all NETMOD/NETCONF documents now to replace 'encoding' with 'representation', which also includes changing document titles? I am not necessarily against that change but I think it is good to understand the implications that go well beyond some charter text. (I did do my own analysis how frequently we have used encoding in our documents, I assume others have done this as well.) /js PS: RFC 7951 JSON Encoding of Data Modeled with YANG. L. Lhotka. August 2016. -- 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 Mar 1 00:32:44 2017 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 9EDD9129460; Wed, 1 Mar 2017 00:32:41 -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, RP_MATCHES_RCVD=-0.001, 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 PoG_Cfa8IHwO; Wed, 1 Mar 2017 00:32:40 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDE91294C9; Wed, 1 Mar 2017 00:32:39 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:ddb5:e7d5:e3da:2a2d] (unknown [IPv6:2001:718:1a02:1:ddb5:e7d5:e3da:2a2d]) by mail.nic.cz (Postfix) with ESMTPSA id 8795C66A1F; Wed, 1 Mar 2017 09:32:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1488357158; bh=wWSO1uEtD7v6s4ctQaMjk+9xi23z8RfVeFdKw6hHv0I=; h=From:Date:To; b=OYmB9MoSUd8GjIjhdIIXTyLNpRSDc+sasqUKQ3zZulDo48ZYW/5Xo/AMVmQp8BSaO 0Lqihn9goQ3u+uIZHJRN45u1pAglOKhu5d9YzjU8FuJoq0jEv/NGqLYkPP1PECtz9W zp+7/4ndVE49ae0ZhihUOMbqREbuzZj1beqxCJiQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170301080626.GC74969@elstar.local> Date: Wed, 1 Mar 2017 09:32:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 08:32:41 -0000 > On 1 Mar 2017, at 09:06, Juergen Schoenwaelder = wrote: >=20 > On Tue, Feb 28, 2017 at 11:41:35PM +0000, Kent Watsen wrote: >>=20 >> Hi NETMOD WG, >>=20 >> Please find below draft-2 having the following changes: >> - clarified responsibility 'c' >> - s/encoding/representation/g >> - moved intf-ext-yang from Oct to Dec >>=20 >=20 > So are we going through all NETMOD/NETCONF documents now to replace > 'encoding' with 'representation', which also includes changing > document titles? I am not necessarily against that change but I think > it is good to understand the implications that go well beyond some > charter text. (I did do my own analysis how frequently we have used > encoding in our documents, I assume others have done this as well.) >=20 I don't think it is necessary to immediately update old RFCs with this = new term. I do think though it is important to stop using "encoding". = People have to realize that - different representations of conceptual data/resources cannot be = automatically translated to each other as the term "encoding" might = suggest - it is important to think about what representation to use for a given = use case (this may influence the choice of protocols and/or tools). This terminology will also help app folks understand what we are dealing = with in NETCONF/NETMOD. Lada > /js >=20 > PS: RFC 7951 JSON Encoding of Data Modeled with YANG. L. Lhotka. = August 2016. >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 1 01:46:33 2017 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 7F3AC1298BA; Wed, 1 Mar 2017 01:46:31 -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, RP_MATCHES_RCVD=-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 8HhkST-gbYZo; Wed, 1 Mar 2017 01:46:30 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50D61298AB; Wed, 1 Mar 2017 01:46:29 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8AD5513F3; Wed, 1 Mar 2017 10:46:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fRaRLyFrrAbw; Wed, 1 Mar 2017 10:46:27 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Mar 2017 10:46:28 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A5C0200D5; Wed, 1 Mar 2017 10:46:28 +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 f1wslhJtFU7m; Wed, 1 Mar 2017 10:46:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6FC5200D0; Wed, 1 Mar 2017 10:46:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4C2303E8E20C; Wed, 1 Mar 2017 10:46:30 +0100 (CET) Date: Wed, 1 Mar 2017 10:46:29 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20170301094629.GA75542@elstar.local> Mail-Followup-To: Ladislav Lhotka , Kent Watsen , "netmod-chairs@ietf.org" , "netmod@ietf.org" References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 09:46:31 -0000 On Wed, Mar 01, 2017 at 09:32:37AM +0100, Ladislav Lhotka wrote: > > > So are we going through all NETMOD/NETCONF documents now to replace > > 'encoding' with 'representation', which also includes changing > > document titles? I am not necessarily against that change but I think > > it is good to understand the implications that go well beyond some > > charter text. (I did do my own analysis how frequently we have used > > encoding in our documents, I assume others have done this as well.) > > > > I don't think it is necessary to immediately update old RFCs with this new term. I do think though it is important to stop using "encoding". People have to realize that > > - different representations of conceptual data/resources cannot be automatically translated to each other as the term "encoding" might suggest > I do not think that encoding implies that encoding A can be converted to encoding B nor do I think representation does not imply that representation A can be converted into representation B. > - it is important to think about what representation to use for a given use case (this may influence the choice of protocols and/or tools). The same has always been true before as well. > This terminology will also help app folks understand what we are dealing with in NETCONF/NETMOD. I am not against changing terminology but I think we should make sure that there is agreement, ideally in NETMOD and NETCONF, to adopt this new terminology. The worst result would be if documents end up being inconsistent in their terminology for a long period of time. So it is also useful to consider how long the transition to a new terminology is realistically going to be, i.e., how many documents are affected and how much and when it is likely that they can move to a new terminology. In other words, if we make this change, we may consider to have this explicitly mentioned in both charters. /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 Mar 1 02:45:30 2017 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 9360512996A; Wed, 1 Mar 2017 02:45:24 -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, RP_MATCHES_RCVD=-0.001, 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 TsG8j1Ug8ZO2; Wed, 1 Mar 2017 02:45:15 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE221294FF; Wed, 1 Mar 2017 02:45:15 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:ddb5:e7d5:e3da:2a2d] (unknown [IPv6:2001:718:1a02:1:ddb5:e7d5:e3da:2a2d]) by mail.nic.cz (Postfix) with ESMTPSA id A50D56C174; Wed, 1 Mar 2017 11:45:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1488365113; bh=yiEeZWaCPGyLEwrwHEInzgAENs0nf2rTpIiZzYni+FY=; h=From:Date:To; b=XTy9V+urrF3nckzQrACXQgcmNdZd2G712ZXIerF4xWqbOMqbvbINYojimwC1SWFIe efB3UEjbeylYKkRNImgDZgBLiPtEQHsy1aFTjrM4fLcVyeQ4u9SmyqiCdCZNcdVM0b AJNHODVtmI66zio8xl1BCFa+5hFd1BctdgJVfPv8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170301094629.GA75542@elstar.local> Date: Wed, 1 Mar 2017 11:45:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> <20170301094629.GA75542@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 10:45:24 -0000 > On 1 Mar 2017, at 10:46, Juergen Schoenwaelder = wrote: >=20 > On Wed, Mar 01, 2017 at 09:32:37AM +0100, Ladislav Lhotka wrote: >>=20 >>> So are we going through all NETMOD/NETCONF documents now to replace >>> 'encoding' with 'representation', which also includes changing >>> document titles? I am not necessarily against that change but I = think >>> it is good to understand the implications that go well beyond some >>> charter text. (I did do my own analysis how frequently we have used >>> encoding in our documents, I assume others have done this as well.) >>>=20 >>=20 >> I don't think it is necessary to immediately update old RFCs with = this new term. I do think though it is important to stop using = "encoding". People have to realize that >>=20 >> - different representations of conceptual data/resources cannot be = automatically translated to each other as the term "encoding" might = suggest >>=20 >=20 > I do not think that encoding implies that encoding A can be converted But, if my memory serves me well, you have always insisted on being able = to do the roundtrip conversion between XML and JSON (without using the = data model, or in anydata).=20 > to encoding B nor do I think representation does not imply that > representation A can be converted into representation B. >=20 >> - it is important to think about what representation to use for a = given use case (this may influence the choice of protocols and/or = tools). >=20 > The same has always been true before as well. At one point, it looked like XML will be the mandatory "encoding" for = RESTCONF, despite my fierce opposition, as if it was the the same as = requiring everybody to support UTF-8. Fortunately this was eventually = overturned. >=20 >> This terminology will also help app folks understand what we are = dealing with in NETCONF/NETMOD. >=20 > I am not against changing terminology but I think we should make sure > that there is agreement, ideally in NETMOD and NETCONF, to adopt this > new terminology. The worst result would be if documents end up being > inconsistent in their terminology for a long period of time. So it is > also useful to consider how long the transition to a new terminology > is realistically going to be, i.e., how many documents are affected > and how much and when it is likely that they can move to a new > terminology. Yes, "representation" should be one of the terms newly defined in = 7950bis, and it can also be mentioned that "encoding" was used = informally in the past. As far as I know, "encoding" has never been = defined before in this context, so IMO no complicated transition is = otherwise needed. And the fact that the term "representation" is used in = this sense in related areas can only help. >=20 > In other words, if we make this change, we may consider to have this > explicitly mentioned in both charters. I don't mind although I don't think it is *that* important. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 1 03:07:54 2017 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 AEF83129970; Wed, 1 Mar 2017 03:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 MjKfOEA9XsTS; Wed, 1 Mar 2017 03:07:50 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0090.outbound.protection.outlook.com [104.47.1.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383711293DF; Wed, 1 Mar 2017 03:07:50 -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; bh=rHut7UCTj5ujJkVtq/CS8L81ZXYGf2dkR8XSuW9x5yM=; b=QRErjFclzbsL1VTCEz708/W9UoYNXUTBIBGDVe0S9SU0pMHcIi/QtCYZpk1SkWsq94LJMlXH0hhNFF4XG1CLGktJ63RTf5kDXvRrCEgIUzOhAU4zNUIXWCuuNkcXleZR9CR4k7aw2NSv1yMOrE1TzE3qVqrftAtkchBE45NmJ7c= Authentication-Results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.203.75) by AM5PR0701MB2995.eurprd07.prod.outlook.com (10.168.156.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Wed, 1 Mar 2017 11:07:47 +0000 Message-ID: <05eb01d2927b$a75d2da0$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder , Ladislav Lhotka References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> <20170301094629.GA75542@elstar.local> Date: Wed, 1 Mar 2017 10:53:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.203.75] X-ClientProxiedBy: DB6PR0202CA0025.eurprd02.prod.outlook.com (10.171.70.11) To AM5PR0701MB2995.eurprd07.prod.outlook.com (10.168.156.145) X-MS-Office365-Filtering-Correlation-Id: 8eaebe51-8942-481d-1827-08d4609331c7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2995; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 3:+kfwa7o1CPXywBaFx+AYHWX8KRS3SF4NX9ItDPjZnKnvSFZd09MvxxrMw8Pu5b7M45TkZfEWvPdNxGwHU0rs+lALrTn4dVGF6ptXARu67Au6kM6XD+Qha3U84Hf0zcuRPgk3EgnBrVdSWc6Gru9cdiKW7zSgc1h+IFZS7vcmGHc2Bx10u9CUbB1F3x/f6MJKckTetO738hCnJfsQLUyrIQ5YguFSLC9BeOosk7ygyLh+jhRoAi6AESAQXFopDHHpw9xyMzE7ErtEWrWjRMnAvw==; 25:mYd6SY1JCWwwh/rkn3bln2nE/ryRspJ2ybPrcNtNNbA4igXuQWBoM2Rq9GvY1bOADUnGMRlhd4HpxIIGYAHG2yZEkjgrizHxAA9UbuBU4CShUSkspRvmbDX/oxGpbGInX7Itz+kAV+3P7H7A5unJs+Cs907y+BJhb9lmWm7neK1lSi1h0PYqb9DOxuknhN1QU2knE7oFmQYb2OdauVNa6FVGPbKDa1/RWUqQCDAGiLTiZS1H2sfO6vT0NVdc2/BnWXuxq7yhNusmRuhG6urKcMFwI36jk7YT2pvR3I44gNs2mJccmjaieOLsKZuMCc+VwJfCkaGN28niz8AS8O7w0mFQrSsEIwM9XCtBlCdYC0WeLZqCG4wQvMh6LAAzkidAwkuPvxyBVK1dHnhZb+4mRfxx61+1aVZSMXNLFU0+RVhAszmp5MJnSIN2FQU4P/1f/3HRb94D2/FBU9MMnvEkMA== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 31:jlDoBsaAHuAmZVlfmc+u+Ij22sXkIo941pbDQuaKKKmhubUvURGU6p6UbLBBBDioBIqJhgo/gKUBruaDQSInQaGLOkt5jb9aXGyUYuZ0i7CouCsrNbvbgYHjQpga1T/MumZeDUdqbEWiNpR1u5Wq9+h5q00suO2w8O1VDAJTPamqcZIi6/ywl18chVgOTwEJ+1jqRqCl7hPdB027Mluq1R7r+vAc//LdlekDTJHMDWjoXHEocls/JwrRyovgUGwc5JVBNqyoZXZ6X6tqMfkbBC2D1L+56+Q/sfwSuPW/9qA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:AM5PR0701MB2995; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2995; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 4:i3WVumaDmJ3EnT5McOfSzOozULEXm6fERsR4DO/oXj8LuBmZE/JkrCYb81UFG6+NWHQjzfq6d3QpsKeXsv6Gmvvu6rJQiAp1XIypouu5lOdD/7bm04AWATwp6RYDev4HMD0PI/Y6wgaM+rtzaU3nQEKrHRxURg3wnXN+r7L8qTz6UKUcFGrSFxc7SqgKBCQCm4sXWAb2TO4JXF8SIE/RQj1NqzFa95MgEcxVP9fK5FIZS6bJoa0IYVGI72cSCRL/olC6CEms0JsJUOnRiy7RAobPsYlGkCM7wvQC1OFasWgxKU3dcceGmEPNznN0dCL7c6FwGOoq5TbEP/j9RLcVe7Q3xV7VaubxYDL7bT4Ezy7ThsGWjCNPwHmnoTDHuvfGV+76YsN05kWeLoFppX4OQIavs/faDEB39/k7CxI14Ysw0SeClOYModDDT/YFCaUwkYwspNRaDUrvtndoS9syqHVErPCA6TgML3NTUqPGXvZxN3OD4i37/7OYTChd7v9uyjdHd0mbeOAOx26TtZSdZZGG+u2FXWNqhQcVK+3PxpEatv0CMRW4aH2UFgvUPWEbCpS8860LSmS/EsWPbN/MSJGkmIFM12TQAWmsO9nCjQi9fpVONHcT/nPn7u9cBRSdF6k1q20vPmxdg8i7ZGjbJg== X-Forefront-PRVS: 0233768B38 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(51444003)(24454002)(377454003)(13464003)(5660300001)(4720700003)(66066001)(44716002)(6666003)(47776003)(62236002)(61296003)(1456003)(42186005)(92566002)(81686999)(81816999)(50986999)(76176999)(116806002)(7110500001)(33646002)(86362001)(8676002)(38730400002)(81166006)(50226002)(14496001)(93886004)(189998001)(6246003)(6496005)(229853002)(6486002)(9686003)(6306002)(44736005)(25786008)(54906002)(84392002)(10710500007)(53936002)(1556002)(3846002)(7736002)(305945005)(2906002)(15650500001)(4326008)(23756003)(230700001)(50466002)(6116002)(2420400007)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2995; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM5PR0701MB2995; 23:hSLE8hjZzRlGago8TDMGYUx4mN3wA3qHtTvA1?= =?iso-8859-1?Q?1wxWiISVt2dWQzzIZb/8sjUJ4AgQT/bWu1VrktlKVwKoEqeMpmo9ibncDt?= =?iso-8859-1?Q?exUU9PLRjSlVC1W79Q9mfGS3d56N108ze25KbVBFcBvyMslrur3Sl/BJ5u?= =?iso-8859-1?Q?1NXOQFK8Gr7SXVCYBcGaDyKE0w+LCGKx9qd4tYE1Q+c4cP3yF3OZ4Myrkg?= =?iso-8859-1?Q?fhnN1DEEPF+P31z6IJEzUooFZQxal7EalDW8fEmUzNWqDQ2uW9SGsS1a/a?= =?iso-8859-1?Q?lTjhSRBQvxZMlPuTeK5ls7mTpYH4huezwigmlLoaA5tBwMJNckJMUN0fJB?= =?iso-8859-1?Q?rTRNBJ9OTOrWuLFQj53ogQI/dwwg+Q2IDRGqwmIw8WHVvQq3S0d7sXjjgJ?= =?iso-8859-1?Q?R2PxHat49DKYCzIZnrZS+x9CW+3Lo7LHixfnyJ5cSmWEl/dgB6K3UbNaBD?= =?iso-8859-1?Q?uQ4WRT7MvXfTphho0/qRiQiQMtGAeWlCv8n+O0kogyyHCBjGFNA6yN8RuC?= =?iso-8859-1?Q?lgj2u6FV89TlAf8sHo6VwtbBVD1KlxJxAUwwpw8dq79vIokwIrRCUMChlC?= =?iso-8859-1?Q?aVpB6JBtWDNn+k0fzMa2XxrL1R6UNqJpFUTRXyXpTtmXCH42HVtS5iWHbA?= =?iso-8859-1?Q?IBooMKXrXanUUkifVLivVPdSrSeDlt9fiFCpJw002HPQ3aU5ji4ArIpjGT?= =?iso-8859-1?Q?iVzuYBu8ac9KfbxDpWbpbuyV76XYYopX31cPeBJNlMqmY5KanzgAecXXoR?= =?iso-8859-1?Q?/qXVFF2X8S+uPP31O6D+vR2LmbAAYvMhMm30AT2nRQKsobZxbvmU1Xf9V6?= =?iso-8859-1?Q?1Gn6RmD0dyxk/RHeew5twxANkknd9RSEhy+l7nC/uRkFsjnNGvBd+Dh17M?= =?iso-8859-1?Q?UC6A2piMY1OD4TtN3F+0nVK2zQAgqL+QDVZmPjy5GCYlxsc7hzZzy15SfW?= =?iso-8859-1?Q?WYWWr4qELaqwxZcVMo7Ooo/bh6kG6VDi8n6Ncjh1mnFaVJUp4T7ySIh7qi?= =?iso-8859-1?Q?lXrG9ZQFAutcIBD58FQh/eK89sVRj8FLckmAUbfLYjTjM6U1q46PznCO7o?= =?iso-8859-1?Q?SCqAA8DQTJwuUFeOlwjqDc0rWsKi4Lr5EXQO++6wHxzZ302CFuyE8kQcod?= =?iso-8859-1?Q?r/BkPKfp1Vh3FMbrCP4M16Ha/sND2D4IgH2DiIkcev7kj5/maKxZnbw0gg?= =?iso-8859-1?Q?TfeMXsAsKgmOE5qzya6O70EwEqlQc0SE2y6uvz4nlGwZJHOgS2tKJh1VdV?= =?iso-8859-1?Q?jMEd17ASpmO5zTJkyIYbSCbp5BbujtVzgwa3uc/sKQrT/wM5BmP11gm6qD?= =?iso-8859-1?Q?v8xqq0tPPz6L9FN9LWdjzEXCXOHBE/uBJCXT+Pg8Xwd6uGUmx3uKJSnPv1?= =?iso-8859-1?Q?542hUNF/CaV+KIYPdOPnMY/sVO7coKmT3K/+q7LHft0745wVb4gkO0q7cX?= =?iso-8859-1?Q?GYUdmr4mSdzxlfrSfRpVSrnrLxyZ7pa9mwa8JOS7+rH2JBepDEqFfLZP/F?= =?iso-8859-1?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 6:mN/M7N2YzbQuAIn2XlNciVpNZ6B+sCmvLMkFxeFWGDh8VUWqsOalCp9b/PqsarwBMXa2FY8q/JzJjQ7R0tDudCO7v0AU6OcDW/L9m/M5lIT2u8/V2CMabWTH/cEm7JHYa/1OBgaE9BDLGmElOiRTV8Mrmk6cfPPM2K2CZTFLuHVuXouTBUTAgv9YBZtqF9kT6O5U0FYjFryfJ3fbsO6yqaAs0gwKkknfP5JV1hFa86gDwJnxzjP2hXQO37lPBGH9Bg+ZjwbLXhQGIgZ0sR/JISoR01Iku0+Z4ntFhEGL5sILKZlv5K4jZmEe4C+XN0V5NREVqFIkEhoh4rpxuicGADeYUtHByEygXqTBEVVqZtom3QFp3Vh3RjGCyCkktikbVwyrf7qijPTM1wst0XTyPw==; 5:ycyX8+0dciNRc3I9bDeKm4hXJ1DeAV+RnvbznkliRciJabNJSlk6z1anp9DfIN8N06aSxvkc7DIevjFlvYUEfughelWWztnKcyJltaYPhamjTlvZZLEti678q6abK3DkTSFleQ/6RNzLfchSIk5Hhg==; 24:w3Jo7STd8w7yRvoW5LRlhuXIHyGEPD5SCmgFIing8T0rmqJ26ze3QL4DlkzEHJYMSAQ/EhFO0qu3YU2FoEJosdO22qZ/MdRHNWSMRpq+i78= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 7:+1NF7SoZ6A0YraVGhAkrrxRjR4ockt04yXTk5Yh4AxidjCdgG7Jva/pZTF/dPWpg2tlQdkwTJ/jRcDEWH+EEcYLtBBRAXcNMdp7T0lM/BLwA0U9v3eU+EZ0hWj7IAMl/UBPmYo3EvL1iD6FJm+VFxhS8/QnT4CWiEFFfzt6dsn88h9sTxrYPb9wlg1Us6oPGsfDdjh+Sx0rG4pPFZLhN3A10oNkhbMctuqY1PIQ2DpNiVZuDzx+KqVM61nPmrw9NaVzo3Ga5iAAD9rxvgqkYqXHprJE97GrRThwoRwrGbWlFuBtGP6+9DeG4TIesEU4WRaooW4g44snOQ/ESrP8edA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2017 11:07:47.3159 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2995 Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 11:07:53 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Sent: Wednesday, March 01, 2017 9:46 AM > On Wed, Mar 01, 2017 at 09:32:37AM +0100, Ladislav Lhotka wrote: > > > > > So are we going through all NETMOD/NETCONF documents now to replace > > > 'encoding' with 'representation', which also includes changing > > > document titles? I am not necessarily against that change but I think > > > it is good to understand the implications that go well beyond some > > > charter text. (I did do my own analysis how frequently we have used > > > encoding in our documents, I assume others have done this as well.) > > > > I don't think it is necessary to immediately update old RFCs with this new term. I do think though it is important to stop using "encoding". People have to realize that > > > > - different representations of conceptual data/resources cannot be automatically translated to each other as the term "encoding" might suggest > > I do not think that encoding implies that encoding A can be converted > to encoding B nor do I think representation does not imply that > representation A can be converted into representation B. I agree. I think that the real difference is between those working with networks and those operating at a higher level. Just because the terminology is suitable for HTTP, URI and such like does not make it appropriate for network configuration. I would stay with encoding. Tom Petch > > - it is important to think about what representation to use for a given use case (this may influence the choice of protocols and/or tools). > > The same has always been true before as well. > > > This terminology will also help app folks understand what we are dealing with in NETCONF/NETMOD. > > I am not against changing terminology but I think we should make sure > that there is agreement, ideally in NETMOD and NETCONF, to adopt this > new terminology. The worst result would be if documents end up being > inconsistent in their terminology for a long period of time. So it is > also useful to consider how long the transition to a new terminology > is realistically going to be, i.e., how many documents are affected > and how much and when it is likely that they can move to a new > terminology. > > In other words, if we make this change, we may consider to have this > explicitly mentioned in both charters. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 1 03:15:59 2017 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 30AE0129960; Wed, 1 Mar 2017 03:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 FIlQzopM5C2s; Wed, 1 Mar 2017 03:15:56 -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 AEA661294F9; Wed, 1 Mar 2017 03:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4043; q=dns/txt; s=iport; t=1488366955; x=1489576555; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=M6+Tf0JtHCvdVrFewHI60tn5KSjq+IYTymCCD1V+WJY=; b=IAKAVtNDkUmd8NXC43Uw09JRF5YP7NjglYCYApAsNxvqBRwjUArBjjyp ZuEW63WiS2H1+jSW6L+Y7eyY88mCxfwdmjk5MKQOawrnxQryuKSfeZvmw watZKNoQcvXNEZkIwrJ2snN1D2VEQ9DY9l3V73hs6S9QXrElC3gh5X9pv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoBAAirLZY/xbLJq1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQxAydfjWNzkFMflTWCDR8LhS5KAoJ0GAECAQEBAQEBAWIohHA?= =?us-ascii?q?BAQEDAQEBNjYLDgILEAguGwwwBgEMBgIBAYltCA6zYoslAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHQWGR4IFCIJihHUmhR4FnCiJVIhegXuIUYZQiD6CbYgJHziBASE?= =?us-ascii?q?UCBcVPoRPHYFhQDWJcgEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,225,1484006400"; d="scan'208";a="692618686" 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; 01 Mar 2017 11:15:53 +0000 Received: from [10.63.23.156] (dhcp-ensft1-uk-vla370-10-63-23-156.cisco.com [10.63.23.156]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v21BFrcI016715; Wed, 1 Mar 2017 11:15:53 GMT To: Ladislav Lhotka , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> <20170301094629.GA75542@elstar.local> From: Robert Wilton Message-ID: Date: Wed, 1 Mar 2017 11:15:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 11:15:58 -0000 Hi Lada, On 01/03/2017 10:45, Ladislav Lhotka wrote: >> On 1 Mar 2017, at 10:46, Juergen Schoenwaelder wrote: >> >> On Wed, Mar 01, 2017 at 09:32:37AM +0100, Ladislav Lhotka wrote: >>>> So are we going through all NETMOD/NETCONF documents now to replace >>>> 'encoding' with 'representation', which also includes changing >>>> document titles? I am not necessarily against that change but I think >>>> it is good to understand the implications that go well beyond some >>>> charter text. (I did do my own analysis how frequently we have used >>>> encoding in our documents, I assume others have done this as well.) >>>> >>> I don't think it is necessary to immediately update old RFCs with this new term. I do think though it is important to stop using "encoding". People have to realize that >>> >>> - different representations of conceptual data/resources cannot be automatically translated to each other as the term "encoding" might suggest >>> >> I do not think that encoding implies that encoding A can be converted > But, if my memory serves me well, you have always insisted on being able to do the roundtrip conversion between XML and JSON (without using the data model, or in anydata). > >> to encoding B nor do I think representation does not imply that >> representation A can be converted into representation B. >> >>> - it is important to think about what representation to use for a given use case (this may influence the choice of protocols and/or tools). >> The same has always been true before as well. > At one point, it looked like XML will be the mandatory "encoding" for RESTCONF, despite my fierce opposition, as if it was the the same as requiring everybody to support UTF-8. Fortunately this was eventually overturned. > >>> This terminology will also help app folks understand what we are dealing with in NETCONF/NETMOD. >> I am not against changing terminology but I think we should make sure >> that there is agreement, ideally in NETMOD and NETCONF, to adopt this >> new terminology. The worst result would be if documents end up being >> inconsistent in their terminology for a long period of time. So it is >> also useful to consider how long the transition to a new terminology >> is realistically going to be, i.e., how many documents are affected >> and how much and when it is likely that they can move to a new >> terminology. > Yes, "representation" should be one of the terms newly defined in 7950bis, and it can also be mentioned that "encoding" was used informally in the past. As far as I know, "encoding" has never been defined before in this context, so IMO no complicated transition is otherwise needed. And the fact that the term "representation" is used in this sense in related areas can only help. I'm not sure that I see that 'encoding' as the bad word for XML/JSON/CBOR etc. Possibly 'representation' might be better, but I think that saying that something is 'encoded in XML' is likely to be well understood. As I understand it, encoding doesn't just apply to characters, but is widely used in other places, such as audio, video, Ethernet (e.g. 64b/66b). Perhaps, where appropriate, the drafts should differentiate between the YANG encoding for a YANG datatree vs the underlying character encoding that is being used. Rob > >> In other words, if we make this change, we may consider to have this >> explicitly mentioned in both charters. > I don't mind although I don't think it is *that* important. > > Lada > >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Wed Mar 1 03:29:34 2017 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 CF74E129982; Wed, 1 Mar 2017 03:29:32 -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, RP_MATCHES_RCVD=-0.001, 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 YWny7Js_gVMM; Wed, 1 Mar 2017 03:29:31 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84041294F9; Wed, 1 Mar 2017 03:29:30 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:ddb5:e7d5:e3da:2a2d] (unknown [IPv6:2001:718:1a02:1:ddb5:e7d5:e3da:2a2d]) by mail.nic.cz (Postfix) with ESMTPSA id 0C7DD622FB; Wed, 1 Mar 2017 12:29:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1488367769; bh=2i6+D4VQXBk2T0mbpggOzgJou6TGHYxQkzUgrQHOueM=; h=From:Date:To; b=VjX/cdjc7Ay3dXdjLjAEQlNkk2FYB6J1EvdFgmU+gemG7+G/NTaXonaLtQHySkcc+ 0x95qdOCwA0In2Ekhcsku+nC6KV2cd15sS61H/B+TcrxUG9Gd04imNg2eAHmhAhPsT o7hDgK1t1BVn6c50be9FYrWst8gfA+42AqJIXZHY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <05eb01d2927b$a75d2da0$4001a8c0@gateway.2wire.net> Date: Wed, 1 Mar 2017 12:29:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <63B6599B-5295-4D88-AFA0-1A24890CF7C5@nic.cz> References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> <20170301094629.GA75542@elstar.local> <05eb01d2927b$a75d2da0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , netmod@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 11:29:33 -0000 > On 1 Mar 2017, at 11:53, t.petch wrote: >=20 > ----- Original Message ----- > From: "Juergen Schoenwaelder" > Sent: Wednesday, March 01, 2017 9:46 AM >=20 >> On Wed, Mar 01, 2017 at 09:32:37AM +0100, Ladislav Lhotka wrote: >>>=20 >>>> So are we going through all NETMOD/NETCONF documents now to > replace >>>> 'encoding' with 'representation', which also includes changing >>>> document titles? I am not necessarily against that change but I > think >>>> it is good to understand the implications that go well beyond some >>>> charter text. (I did do my own analysis how frequently we have > used >>>> encoding in our documents, I assume others have done this as > well.) >>>=20 >>> I don't think it is necessary to immediately update old RFCs with > this new term. I do think though it is important to stop using > "encoding". People have to realize that >>>=20 >>> - different representations of conceptual data/resources cannot be > automatically translated to each other as the term "encoding" might > suggest >>=20 >> I do not think that encoding implies that encoding A can be converted >> to encoding B nor do I think representation does not imply that >> representation A can be converted into representation B. >=20 > I agree. >=20 > I think that the real difference is between those working with = networks > and those operating at a higher level. Just because the terminology = is > suitable for HTTP, URI and such like does not make it appropriate for > network configuration. The resource/representation concepts come (I think) from Roy Fielding's = dissertation where it is explicitly mentioned that they are not specific = to HTTP. Also, in my view, NETCONF/RESTCONF is a higher level than HTTP. Lada >=20 > I would stay with encoding. >=20 > Tom Petch >=20 >>> - it is important to think about what representation to use for a > given use case (this may influence the choice of protocols and/or > tools). >>=20 >> The same has always been true before as well. >>=20 >>> This terminology will also help app folks understand what we are > dealing with in NETCONF/NETMOD. >>=20 >> I am not against changing terminology but I think we should make sure >> that there is agreement, ideally in NETMOD and NETCONF, to adopt this >> new terminology. The worst result would be if documents end up being >> inconsistent in their terminology for a long period of time. So it is >> also useful to consider how long the transition to a new terminology >> is realistically going to be, i.e., how many documents are affected >> and how much and when it is likely that they can move to a new >> terminology. >>=20 >> In other words, if we make this change, we may consider to have this >> explicitly mentioned in both charters. >>=20 >> /js >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 1 04:24:35 2017 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 0E15A129542 for ; Wed, 1 Mar 2017 04:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 jhq1S7r9jGCn for ; Wed, 1 Mar 2017 04:24:32 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0107.outbound.protection.outlook.com [104.47.1.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5A2128E19 for ; Wed, 1 Mar 2017 04:24:31 -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; bh=HFDO1F05HpeXKWFU4cUhQ10/y1DazCG1NrF4v6HZwR0=; b=fu7h94CVifSQ3gPf4nueKpiH0H4ktCdQ1SD3fRVJYdjRhig40s/plP0gEqT1WFeU+hfG5+jnUgHe3Mu2+s015NYhZJB/4TQ3CCp/iiK3DoUwcFUzojfRspwUE4wflez17UnVMAcgtTnwG801nx5aCa1E0uG+h4LB2zPqRwITIoA= Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.203.75) by DB6PR0701MB2997.eurprd07.prod.outlook.com (10.168.84.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Wed, 1 Mar 2017 12:24:28 +0000 Message-ID: <075901d29286$5def4300$4001a8c0@gateway.2wire.net> From: t.petch To: Alexander Clemm , Kent Watsen References: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> <1481689016940.22442@Aviatnet.com> <3F4C49C9-1A6A-4644-97C6-F9CDC2E4EB4B@cisco.com> <1CC274D2-72B9-4F79-A70F-3DF332C65A60@cisco.com> <44C50B18-8918-47E4-A9FE-F4A676E64AA1@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF818AA@SJCEML703-CHM.china.huawei.com> <02B9298C-631A-46F7-9FA9-19B1959327FE@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81C18@SJCEML703-CHM.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81CBA@SJCEML703-CHM.china.huawei.com> <033D3CA2-7297-48C8-A5BD-B723F7F1911B@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81CF7@SJCEML703-CHM.china.huawei.com> Date: Wed, 1 Mar 2017 12:20:05 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.203.75] X-ClientProxiedBy: DB6PR0202CA0048.eurprd02.prod.outlook.com (10.171.70.34) To DB6PR0701MB2997.eurprd07.prod.outlook.com (10.168.84.135) X-MS-Office365-Filtering-Correlation-Id: 20e80909-30fa-457c-503e-08d4609de864 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DB6PR0701MB2997; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 3:AGxqav4V/wI+Yn/MfPL+3PWNmJiJHQVl4hhiVUQtNQpplQkmT1wnFK9yX+JKzJpd5kgYmzkm40LZRPaf/JZCu2otxudrADDSElc7q7sAaABurxRGr8aq5H24YPpBZE7LRfHBVO/GK+Z6UZoGqnoj+MrQGAGK9YDYIOeXcyZsSILquAiVY/+XPqh/hX0Kjh+Wu83RybUdnZHrIAbH1l0lIy/hna7y+VoYWNnjmT8oa885lWWjAq9V/Tl8gTI+n6lsUx0ntiOv1RuT2EMcvG0tJA==; 25:yU7vz78msjpk+5kEqGbWRivqCXRTNKVkPrqoTOeeLpeVWHqpkKWH4MtPMfIfTTA9ozps3JEiPllOxrvoLEuPoCLiEsLfH63QEnUqIM5+m93EFaZLvwnAu46WPbDnxWGxTxN1SUs24rgXw7F+b5Q5dmjUEaT2O+4T/Hvezo7Kmzb1hp7gYxH6PiH/qt0ZAeeR5wziHbX6NDxX9c0d4NhrS97ldWeLWiJEjaQCnRWEcV9awB5bLIx1a1NKo7vSgm6VL264d1LI5Ucyr3H0mumFJfk7h6dfjbOu4d6tswd/jy8BxX+3npEetMXdeACClo6VJDAr/C4DxXOkLA+Q6Dq8KT8R36h4OZ/TPyLwBuVQ4/PP7I2My3G+qSaU6em0BUnyXtA+3gtTK4KaYEmECMrczgvAa95TrOyTQ5UAIcOtUQrso7VJDZc//VVGAzSa1ZO3pS18xQS/eKDe+t0eUg/Qdg== X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 31:a1LaaO/P3Izlz9yuJKIfpua4z7DpJqY7OIZBV5QT6sKI69wwgRL1NcQTfXlr3KHAQREmFLdkFMZLYAXwxpJF4RgLg23FU8bSZJt+420x0EjJ3cRSaBchGC2pi5vmn/icywkkpIztL/H+hCbb/P/EHXRDjLLz6xi3Ev74tgR6c7OaykWitHTTmPELAAFpL70oYI13qXCA3+oZ3uJ4XKYceI0B83CqZ1PZ8ij/Mxbq51YQb7X8WNb8WI1QxRBa3l83qBh9Rm5tlyd11f2P+lOhu1JGHOexemr+G/bk4gNkoHc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(50582790962513)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:DB6PR0701MB2997; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2997; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 4:HvvzQbWcyobgZgX24PLy/LCeiZ6YWRD1iLohpgArBghUE9zOMI4TX10bo3aib7eP2AAZ8OValpgz117I85o4GAXj9d9BhWolap0N8trYFgAGC8T36LmTsmgYjCsFul6tc5wLq/RdlVr6goRktJ/3PP7Zvyu1vYb2aM2Ri8KXV4sAywfha65ASYYA481gXclD5QOmloVhKeF4xQuW6Tk+LgLy1EnRzIN2e6Idgrtd1t1r92m8JTI2z+CaDFltyoWKTbnp/RznU+g4YhJFZgLjO76FdrQU9CG+qnrYcdoe/kr/pikAL5E7e4vpO3nHPXjNg5UKPcMdt2pJQLHqkjJkMb+FdZos92Vb7uqeM+heDw4yZG3cWndPCVVTmIYppfwYhjHg4Roo2tVXGHxNXawsU4Yr58YuU8cREVKiqH6GJl3DE6dhG95OXcRKDt8/tFx7uIBlSsd68lM25R062j0uptGitrRQvC+ahkAXywOtlsGNHTrFU0ExIX/FhA5VR9IzDwChBXtToq94saVYEvz9MaS0f3iaB+k49GMWZ7HhwLm8XLx6KVvswcYQkMMl96MyG0aBodifhCwxkN0O3Rg2AxLERyAr9YNBQ4eApPLAu4OvTYEtPgHmjIb72rH+I1fDhhnVAb3nB/YyWBskBAY1lerfMUEjlHD1KfN+M4gAz5kY0wqQj3UJrnoEsNZVuF/X X-Forefront-PRVS: 0233768B38 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(13464003)(51444003)(377454003)(81816999)(7736002)(50986999)(305945005)(1941001)(25786008)(6116002)(76176999)(81686999)(230700001)(9686003)(50466002)(3846002)(6496005)(4720700003)(14496001)(8676002)(81166006)(5820100001)(44716002)(47776003)(38730400002)(50226002)(62236002)(116806002)(84392002)(42186005)(61296003)(230783001)(1556002)(6666003)(8666007)(189998001)(5660300001)(66066001)(93886004)(23676002)(6486002)(33646002)(1456003)(86362001)(92566002)(2906002)(53936002)(44736005)(4326008)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2997; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjI5OTc7MjM6c0k0NCtyRmgwVFJSa2prSWZPWDNpaFVK?= =?utf-8?B?RHpUSUdEb3RmckdWOExUdjJ0anJhKzlUNVVSb05vNFQyYXQrMHFuNFFGL2w2?= =?utf-8?B?bWJSdVFTTGNKVzg3KzVkTlUycHRjOHRqN3lMeS9DQkl2R0lQSGJGRVpEUjFJ?= =?utf-8?B?MTJPeGFrQThMQmxTV1Mvc3NPeGthcW5XS3FnQlBCbVYzZm9LQjJrRVNBUEhT?= =?utf-8?B?bWdkamQrNzBvYjNhK2pTb01mdzZlUFlMNHhvZGJNcVFaTTZ0T1plMVdZMmFm?= =?utf-8?B?YWozZlorZnpkMm9EU0EyTE9rQU5NUXk0YUlXcjhmS0hQM0ExSkJYTkhaR2dF?= =?utf-8?B?TU51OGZlejBLbU41c3BKWGkxUWk2ZWZTQW1lYU1ybkR1eE9jeVlPWUpCNkJ3?= =?utf-8?B?NS9VbERhNUVCa0M2SS9QRklVVEhtRDBMbXE0ZE93Nk52cnUrdjBENVdLRExG?= =?utf-8?B?QkE0SkFtejdhV3lVUEJkVkF3ajdDOHhPYkNUMnZNZFU2M0d3TnRVd01MbmNR?= =?utf-8?B?dnJIeENUUERYK3hpanhqejhsa1U3TytoTkZrdElrdVFWcERVdktBK2d6YmUz?= =?utf-8?B?cDA0WlB4S3hIUWVNQXVMWStZZmxiVEZIdFg1RDFLUktnb0o5QXlJUUVTYzN6?= =?utf-8?B?ZW52aUMzNG5KdSt2K3VoWUZ1SFpoZTRib3d2bVlNZWtOMWFzM3NkWHVTR1Bu?= =?utf-8?B?MngrQmJvS1pJWTI2RDQ3bEoreUhVakhYeGdXOHRRNVN6TkZ3SEdFai82V1F5?= =?utf-8?B?WW51RkFkeUN1QTZDT0JMVXI2M21EcnI5MlZ4WWpRZjU5UEpqOWRIQ3BhVUhV?= =?utf-8?B?Vk9mdVpmMENXc0NjN25MWmVuVHVTOGprODJFVzZwVjUxSjF2QVBkZ0x2UUFI?= =?utf-8?B?S2hHNldubWVyM1Q0Mk5oRGhlRVR1Rk5tNW9hOGNtRytTSW1EaEYyNlN6VFgz?= =?utf-8?B?eXdFUm1ES0JMYndvTmNUQTBzS3FIWlJkYlRRV2dSUnkyOHBCWXFmVld2dnAw?= =?utf-8?B?YkkvYnQ3MWk2UTZ2VTl5ZHBaWFVGT1drVWhUSDljT1AzTmludHRYalB0TVhU?= =?utf-8?B?RGp3dkZKOVNoRGdrQVhxQUV6S08yYmp4b2tBMTJVV3ZUbHRaN2tCOVJuUk1P?= =?utf-8?B?VTZGTWpnVElBVnB5bUxmOVl6L1lZcTFoOG5mMlVvWkdSaUpGdWdUMlp1NUJ1?= =?utf-8?B?TDYzajgwdzFiMGltemNVSnJUSWtzeG56bjIxSStLQUpOOFNFUmNteEhoMWFH?= =?utf-8?B?NkRvQ2tSVE9xVm9jUXhCK2wwUXRsTmNEWWRNTFZFTXYraFA0aHp1cmdqQUM2?= =?utf-8?B?WnFac0VqKy9LVExhTTl3anhvNy9LcWdXUVUrckwrUFFWRC9CYVNtMmlrclY4?= =?utf-8?B?TXNzN2RicU14K3lFS0Q2TDZ4VUlJZGs3MU00WDlkc2Vxa1ZVbnh0eWRwSXlr?= =?utf-8?B?RW12b1ExQ3RnOWZ1NDlHQVFLd0RaUS91M3FpU0RuTGg0bHNIaW5NYS8yNDhX?= =?utf-8?B?R0NsK2sySlZuTnZaV1k2R1NaUHhKRi9LRXlpejUveXBYVFNOekFkVkYzSUha?= =?utf-8?B?a0xvcUkxTFVrV1Z5akorWVhMVzhrQTJ4VWI5TlM3K1pQVUpkeXVweEJxc3Ar?= =?utf-8?B?bVgxdU1vK3RXSWhtSVRUSVB3Q1lHbjNTbjZ2U2RLYzZLb1hsV05QbW0wMlBr?= =?utf-8?B?TnZtbkt5S21EeWVMYWx5V0VucWUyWmhWSitZNVNBcFRveTZRa1JxT1BoM1NM?= =?utf-8?Q?Nn9ETkt0AWDxM5QhQMDvO5FR3VAiBi8oh/dFnZw=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 6:kc+EMbG8dySAGnbE4YJqxn9MJ05GCgFZRD+XN6cGKFuzcNoAqPkNfRsQn+RiEnO+16a1cp5tAmY5Oa1+jVGPEn0bCCRsW55TEs1dchHrJ3/iOdQDR5tv0JsWH+a2iMicTR8in4tUixxDVrqOvvpo2v22oASd8y1pLpinsm6i3HkFsr1N5lBN5QRlgqZr6RaWS2xPKPs6ErW1utb9/Kf2MGbqxlcVI31uPHJlK38MhepzlS3/8mi9VzUtRS7BQpW5u23R6bdOcMs+HPTElFL1kEw4M88/sSn/onDtMNKAfz11EZCBPwiJa4tBoAdsWLey7Hcgs7+HC2D7HQgKT9bQA5YFB6rIF5btoTgD3VwH4U/MVJnhQZOmEpt3CgQzCFMKUbswOrTUjeMpu/yDv6DV5g==; 5:XoqbhuliYf+CQmLSa/pZL1TDF4jnW99/jPTKIdfpBfJOsAx7mp/7xIonNZfHbfIT7moXuZfnCnWge9PyQKj+M0kqJ3dP7RDpr2PZDNmyzLDbo0okENRAwBthiydNjdkpmvu9TDpvnjZHRVGUJSJWEg==; 24:Uho2cMyfP+FqexIqBihrNLoPLtNlExFIR+DGYUT6TE3/atSfdPrGvfX1ua5QRrbwjxrg+MwSbTaaz3/ef3Ccz0rjHLaeV3/GaV7ykQw1FF8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 7:L2ih73rP1EyHojY00fNIePFm0Pn/mCpCUNb30M+Q6tdRdbU35W1Oy/GLeuBUdUTQunviiD2Ejx2k+p0lkzB/rI1/h+42IwqvXfKti88IrHzhmFtRnf3aQ1VwWzYd2SfTODcpK8CoCXzVz8meT9Z1fgyiegR9TxxE+q/3FIJ2MST9qlkkl2Esbu4hog3zFF1GaH+QqUtzVj+SStokgxZW8sqYOobVYP/0ZZle+7buRlVW2Gk6dqDjNhl60EX8H03XbwFKPPs4J+G3W9A0ISiBx7RTmh6Oujzgn2o2DMMOQ0yRsYEmSCOY/WGRDnT4+4GenGnTvslFBUlhPw0T0DnZCg== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2017 12:24:28.8470 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2997 Archived-At: Cc: netmod@ietf.org Subject: [netmod] draft-ietf-netmod-syslog-model-12 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 12:24:34 -0000 The explanation of the YANG tree diagram is not that in RFC6087; I think that it should be (or else explain why not) I am confused by the variation in the references to RFC in the modules. I see RFC 5424 [RFC5426] RFC5424 I think the first correct Tom Petch ----- Original Message ----- From: "Alexander Clemm" To: "Kent Watsen" ; Cc: Sent: Friday, February 24, 2017 12:25 AM Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 From nobody Wed Mar 1 08:56:18 2017 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 3409E12960B; Wed, 1 Mar 2017 08:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 o5piYqHGHWY6; Wed, 1 Mar 2017 08:56:14 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0092.outbound.protection.outlook.com [104.47.34.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932011294EB; Wed, 1 Mar 2017 08:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=H6C6CFGE+KiWmJbX1qUP4xR6phYnuXFsQ9eMFoQJnCA=; b=T04F+xJ8kYLL+nkA5zPGt1puMGtDj9eJIUZ/ePqVgY7z/2X+jtR8vnOcaMpKHTFKTQBSrTXqWb7L5NNEiIODobM+Jsx4UzZGx7xRj+bIzZRPe5CU3vNTKtNqBnvhmnxyAY73gzN2TmKzGvajY477lPnqvWWs5w+TrrC4Q76Euek= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Wed, 1 Mar 2017 16:56:13 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0947.011; Wed, 1 Mar 2017 16:56:13 +0000 From: Kent Watsen To: Ladislav Lhotka , t.petch Thread-Topic: [netmod] draft netmod charter update proposal Thread-Index: AQHSjWtMgvd1I9y/IUSjVG5c54oSBqF9KfeA///YNICAAaCFAIAAJwsAgADg4ACAAAdRgIAAFKSAgAAWxDuAAAYCAIAAB3aA Date: Wed, 1 Mar 2017 16:56:12 +0000 Message-ID: <94364DAA-43B4-464C-B824-B46CF1BE499C@juniper.net> References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> <20170301094629.GA75542@elstar.local> <05eb01d2927b$a75d2da0$4001a8c0@gateway.2wire.net> <63B6599B-5295-4D88-AFA0-1A24890CF7C5@nic.cz> In-Reply-To: <63B6599B-5295-4D88-AFA0-1A24890CF7C5@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 1fbdad8a-9fec-4695-a9d1-08d460c3de48 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:zjqVKOe1WSpOq9zUODoCfGeU+bviAD7ly6i6j3SJCnFcW0SQ5fdy15y6B1aDnjDO9iuwFvF81NjtHtF4/Av+++xLHzeoLSBfxpD2+/09xuoD9UxPGnj+OBWteXd3nJOFWx3J5QK7TiHtqtsi40Usl2OfQA+epSyur/CfzkjyoEarZ1cvLqPuza2Sbmgn8A+32keTiKMBh4G9U6Si3XshvN+xPYAWE0JJNLx4dgmjqAxmqUlz7HGbBRUmdKS00xEvJjs2fK76TDrmf5MjzZ0ZmyuTgi4gYe7yAYOhE5DNSkq5keukppZlvs/TVacwd2pUGlHlsx7SK9/lZiH9dOLn6w== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39410400002)(39840400002)(39450400003)(38730400002)(6512007)(6306002)(3660700001)(189998001)(86362001)(106116001)(54906002)(50986999)(54356999)(53936002)(66066001)(8936002)(81166006)(5660300001)(229853002)(76176999)(8676002)(25786008)(82746002)(305945005)(2900100001)(7736002)(36756003)(6246003)(2906002)(93886004)(83506001)(92566002)(122556002)(99286003)(3280700002)(8666007)(77096006)(2950100002)(6116002)(6506006)(33656002)(6486002)(3846002)(102836003)(4326008)(83716003)(6436002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 01 Mar 2017 16:56:12.8400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: NetMod WG Chairs , "netmod@ietf.org" Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:56:16 -0000 SGkgTGFkYSwNCg0KSSB1bmRlcnN0YW5kIHlvdXIgaW50ZW50aW9uIGhlcmUsIGJ1dCBJJ20gaW5j bGluZWQgdG8gYWdyZWUgd2l0aCBvdGhlcnMNCnRoYXQgaXQncyBiZXR0ZXIgdG8gc3RpY2sgd2l0 aCB0aGUgdGVybSB3ZSdyZSB1c2luZyBpbiB0aGUgZG9jdW1lbnRzLg0KSSdtIG9wZW4gdG8gdGhl IGlkZWEgb2YgY2hhbmdpbmcgdGhlIHRlcm0gdXNlZCBpbiBvdXIgUkZDcywgYW5kIEkgYmVsaWV2 ZQ0KdGhhdCBzdWNoIGEgY2hhbmdlIHdvdWxkIGxpa2VseSBoYXZlIHRvIGJlZ2luIHdpdGggdGhl IFlBTkcgc3BlYywgZnJvbQ0Kd2hpY2ggaXQgY291bGQgZmxvdyBpbnRvIG90aGVyIGRyYWZ0cy4g IFdpdGggdGhpcyBpbiBtaW5kLCBJJ3ZlIGFkZGVkIGFuDQppdGVtIHRvIHRoZSB5YW5nLW5leHQg dHJhY2tlcjoNCg0KICBodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL3lhbmctbmV4dC9pc3N1 ZXMvMTcNCg0KYW5kIEkgcGxhbiB0byByZXZlcnQgdGhpcyBjaGFuZ2UgaW4gdGhlIGNoYXJ0ZXIg dGV4dC4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg== From nobody Wed Mar 1 12:39:27 2017 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 5F3861296F7; Wed, 1 Mar 2017 12:39:25 -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, RP_MATCHES_RCVD=-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 lrkwOgcXAMP0; Wed, 1 Mar 2017 12:39:23 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8CA1296BF; Wed, 1 Mar 2017 12:39:23 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 768EA138C; Wed, 1 Mar 2017 21:39:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oN1fOA-tfHvp; Wed, 1 Mar 2017 21:39:20 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Mar 2017 21:39:21 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24DDC200D0; Wed, 1 Mar 2017 21:39:21 +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 57Waa5WGL_z6; Wed, 1 Mar 2017 21:39:20 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB4C3200CD; Wed, 1 Mar 2017 21:39:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 759543E900AB; Wed, 1 Mar 2017 21:39:26 +0100 (CET) Date: Wed, 1 Mar 2017 21:39:26 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20170301203926.GA354@elstar.local> Mail-Followup-To: Ladislav Lhotka , Kent Watsen , "netmod-chairs@ietf.org" , "netmod@ietf.org" References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> <20170301094629.GA75542@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 20:39:25 -0000 On Wed, Mar 01, 2017 at 11:45:13AM +0100, Ladislav Lhotka wrote: > > But, if my memory serves me well, you have always insisted on being able to do the roundtrip conversion between XML and JSON (without using the data model, or in anydata). > I still think this was/is desirable but it does not matter whether the term is encoding or representation. > >> - it is important to think about what representation to use for a given use case (this may influence the choice of protocols and/or tools). > > > > The same has always been true before as well. > > At one point, it looked like XML will be the mandatory "encoding" for RESTCONF, despite my fierce opposition, as if it was the the same as requiring everybody to support UTF-8. Fortunately this was eventually overturned. > Again, whether something is mandatory or not does not depend on whether it is called encoding or representation. > > In other words, if we make this change, we may consider to have this > > explicitly mentioned in both charters. > > I don't mind although I don't think it is *that* important. For me, it is important that we have a plan to adopt a new terminology everywhere. If we do not have such a plan, I am strongly in favour to stick with terminology that so far we use consistently. /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 Mar 1 12:40:07 2017 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 D092B1298CE; Wed, 1 Mar 2017 12:40:05 -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, RP_MATCHES_RCVD=-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 mpZeuXMrVQKM; Wed, 1 Mar 2017 12:40:04 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D0012975C; Wed, 1 Mar 2017 12:40:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 422DA138B; Wed, 1 Mar 2017 21:40:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7-fff9M_gK9a; Wed, 1 Mar 2017 21:40:01 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Mar 2017 21:40:03 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB97A200D0; Wed, 1 Mar 2017 21:40:02 +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 YfLCe6m6O0fO; Wed, 1 Mar 2017 21:40:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FDF2200CD; Wed, 1 Mar 2017 21:40:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6033F3E900D4; Wed, 1 Mar 2017 21:40:08 +0100 (CET) Date: Wed, 1 Mar 2017 21:40:08 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20170301204008.GB354@elstar.local> Mail-Followup-To: Kent Watsen , Ladislav Lhotka , "t.petch" , NetMod WG Chairs , "netmod@ietf.org" References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> <20170301094629.GA75542@elstar.local> <05eb01d2927b$a75d2da0$4001a8c0@gateway.2wire.net> <63B6599B-5295-4D88-AFA0-1A24890CF7C5@nic.cz> <94364DAA-43B4-464C-B824-B46CF1BE499C@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94364DAA-43B4-464C-B824-B46CF1BE499C@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG Chairs , "netmod@ietf.org" Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 20:40:06 -0000 On Wed, Mar 01, 2017 at 04:56:12PM +0000, Kent Watsen wrote: > Hi Lada, > > I understand your intention here, but I'm inclined to agree with others > that it's better to stick with the term we're using in the documents. > I'm open to the idea of changing the term used in our RFCs, and I believe > that such a change would likely have to begin with the YANG spec, from > which it could flow into other drafts. With this in mind, I've added an > item to the yang-next tracker: > > https://github.com/netmod-wg/yang-next/issues/17 > > and I plan to revert this change in the charter text. Kent, there either is a decision and plan to change terminology everywhere or this proposal is in my view a no go. Right now, we seem to use consistent terminology everywhere - I do not want to loose this property lightly. /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 Thu Mar 2 05:47:49 2017 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 3007D12953C; Thu, 2 Mar 2017 05:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.021 X-Spam-Level: X-Spam-Status: No, score=-7.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 BBKpQy-w30a4; Thu, 2 Mar 2017 05:47:38 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522BA1298A6; Thu, 2 Mar 2017 05:47:38 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:141a:a9ee:9241:2ecb] (unknown [IPv6:2001:718:1a02:1:141a:a9ee:9241:2ecb]) by mail.nic.cz (Postfix) with ESMTPSA id B7E996221A; Thu, 2 Mar 2017 14:47:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1488462456; bh=2pe7x+aVhLIzZdmf5NTqZVXUhWGb9++NerGdOtbps84=; h=From:Date:To; b=vPpUgxunv41K5ccG8JLEi5Y1eE+QsfmdSZ9JJJR4t9umiOWAZl2lDenI967LrLVG6 MWbVxlLH31XNPcpkFjSZjKwXfk8hnbARg1kb6fL6E1+D+Gc8zgyUxiBBs6XMv+bGcz NnjqGuTU7CliJtPZ/mMvPJR6N02sHrDoMODVAi3c= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170301204008.GB354@elstar.local> Date: Thu, 2 Mar 2017 14:47:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> <20170301094629.GA75542@elstar.local> <05eb01d2927b$a75d2da0$4001a8c0@gateway.2wire.net> <63B6599B-5295-4D88-AFA0-1A24890CF7C5@nic.cz> <94364DAA-43B4-464C-B824-B46CF1BE499C@juniper.net> <20170301204008.GB354@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , "netmod@ietf.org" Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 13:47:40 -0000 > On 1 Mar 2017, at 21:40, Juergen Schoenwaelder = wrote: >=20 > On Wed, Mar 01, 2017 at 04:56:12PM +0000, Kent Watsen wrote: >> Hi Lada, >>=20 >> I understand your intention here, but I'm inclined to agree with = others >> that it's better to stick with the term we're using in the documents. >> I'm open to the idea of changing the term used in our RFCs, and I = believe >> that such a change would likely have to begin with the YANG spec, = from >> which it could flow into other drafts. With this in mind, I've added = an >> item to the yang-next tracker: >>=20 >> https://github.com/netmod-wg/yang-next/issues/17 >>=20 >> and I plan to revert this change in the charter text. >=20 > Kent, >=20 > there either is a decision and plan to change terminology everywhere > or this proposal is in my view a no go. Right now, we seem to use > consistent terminology everywhere - I do not want to loose this > property lightly. I agree. If nobody else wants this change, I can live with "encoding", = too. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Mar 2 07:17:23 2017 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 496D912968D for ; Thu, 2 Mar 2017 07:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXIr36DxcspS for ; Thu, 2 Mar 2017 07:17:19 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20101.outbound.protection.outlook.com [40.107.2.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32C312999D for ; Thu, 2 Mar 2017 07:17:18 -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; bh=AIVYHeJoUS/hwjKJABTscCyqri0q5LW9CJNoqrh8vI4=; b=p6cegw0DUjx++BqxvgyJyIi37W82QTObUM3GhmNUb80jaCw8Y5peMWXL5LnzkbFy6HClGD9uFac5rVwPWwpXlI7bmK0yWEKpMrPVWU/mKo5LERrXYydOV7gWei+AraX3U3ldeKmdn04EIWwF4ZVA78r6NtEVBJjKswI1ycsWbzg= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0628.eurprd07.prod.outlook.com (10.160.54.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Thu, 2 Mar 2017 15:17:16 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) with mapi id 15.01.0947.007; Thu, 2 Mar 2017 15:17:16 +0000 From: "Bogaert, Bart (Nokia - BE)" To: "netmod@ietf.org" Thread-Topic: Typo in ietf-hardware YANG model (draft-ietf-netmod-entity-02) Thread-Index: AdKTaAUJDO+X8CVGSASW1WFYDF50Fg== Date: Thu, 2 Mar 2017 15:17:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.240.248] x-ms-office365-filtering-correlation-id: 5592ac0c-0a52-4cb1-86b0-08d4617f361f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM2PR07MB0628; x-microsoft-exchange-diagnostics: 1; AM2PR07MB0628; 7:oPHh4+KGKrhRsyfWXtrpBKSV3qriAwyKAphvPFIX56wTokY9u7LWe8GBw99ONrqm7l1R4RxFNDukrTsrhaLpaKY3Hx4HwYQIpKuAfpaBFYxYzFwADGlSqFvxcVIji0aaHAHjY436eLr7fkKgbtfwJmiaQowuo4avFg3EDUsYs7t32sdk+dGTmJDEG9uW+l2MLcbgA9bFOzVQQIgFXQGUiMaMKtCa6oeQENkq8+kFy7pz49T0tWiz0KMxqZHcbhoqESvsRtADq9oZ8V3OPcbAtKfcVkVPz+bH11EHUxmRzev4KvYcxzcmBrHW3fn0lLWev9qJeGYDLoFI4Vry8s5T5A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:AM2PR07MB0628; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0628; x-forefront-prvs: 023495660C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39410400002)(39450400003)(39840400002)(39850400002)(66066001)(2501003)(6916009)(3660700001)(8936002)(3280700002)(122556002)(99286003)(25786008)(55016002)(50986999)(9326002)(33656002)(53936002)(2351001)(99936001)(7696004)(450100001)(5640700003)(54356999)(74316002)(81166006)(6436002)(2900100001)(9686003)(86362001)(6506006)(7736002)(5630700001)(102836003)(3846002)(110136004)(1730700003)(2906002)(92566002)(8676002)(6306002)(189998001)(38730400002)(558084003)(54896002)(230783001)(77096006)(6116002)(790700001)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0628; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0166_01D29370.71FFB790" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2017 15:17:15.9265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0628 Archived-At: Subject: [netmod] Typo in ietf-hardware YANG model (draft-ietf-netmod-entity-02) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 15:17:20 -0000 ------=_NextPart_000_0166_01D29370.71FFB790 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0167_01D29370.71FFB790" ------=_NextPart_001_0167_01D29370.71FFB790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Our people have detected a typo in the IETF hardware YANG model draft: the notification harwdare-state-change should be modified into hardware-state-change. Regards, Bart ------=_NextPart_001_0167_01D29370.71FFB790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Our people have detected a typo in the IETF hardware YANG = model draft: the notification harwdare-state-change should be modified = into hardware-state-change.

 

Regards, = Bart

------=_NextPart_001_0167_01D29370.71FFB790-- ------=_NextPart_000_0166_01D29370.71FFB790 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMDIxNTE3MTBaMCMGCSqGSIb3DQEJBDEWBBQQcLAz fN/MgFmT6zhTLgawx4INnjCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAARIPIWPEAOEWvFANwGUxcMC9r8oOX+d7jeNPHmNq9SzCCZTqrblkB6uvfJp vYGd/71+qCCKjJmX/Xg5a+PwEmnlBgSlluFyEmcKA3l1/iVL4jEtpupZO4R74Wqv6rV/0c89uWQR sr9ycOBRuog+vZ3SVp3m6Jt3lyaQIGsqJG4QQG3skTN1Q3Hqwr6Fs6HKW9Yhd5gELvz9xcjefTM4 +q5n8Y0zzkZUl0B+ANd0TSvt34n2AtOnenVzS8eOWdDUb56QoAhWoIpUrz/IBZWJbyVzYlYzhdhz llBffuQF/kivUyip1kP2jS1SpDXnA60DNAG5BPrRcJYsMteFvXE+xAMAAAAAAAA= ------=_NextPart_000_0166_01D29370.71FFB790-- From nobody Fri Mar 3 07:23:38 2017 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 A057E129458; Fri, 3 Mar 2017 07:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 s-7VjyjRf6mP; Fri, 3 Mar 2017 07:23:23 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0123.outbound.protection.outlook.com [104.47.36.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3581298AE; Fri, 3 Mar 2017 07:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kF4J92XbKcLHdNyau0WAOO2KeNSOx8Ag0UsM4tlwwew=; b=WY7v32aL8aALailL8nxsYEiKtXKQZMc+5kERY5tDy9ua0129cSjquqO4az8UervNWcmgAk3CH6G3D+l/jCafjKUfNnO/5QqI+S7MTfb78jrwAvfSHe0dgjGa7shHpiJ8OXPu6UQ5qohar0lz9oEXEZKaztXRdILJmwoTLecOTMg= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 3 Mar 2017 15:23:21 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0947.015; Fri, 3 Mar 2017 15:23:21 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] draft netmod charter update proposal Thread-Index: AQHSjWtMgvd1I9y/IUSjVG5c54oSBqF9KfeA///YNICAAaCFAIAAJwsAgAQrygA= Date: Fri, 3 Mar 2017 15:23:21 +0000 Message-ID: <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> In-Reply-To: <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: e8f5a021-3786-45ff-72c1-08d462493a47 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:aIJGtMqC8tO+4i6wlVM7KAz/ibC6iRr4tGNOA+TYLRSJ+0DXSuyRc6doc9YIpGd3xJ9mrqRDSuxiyf8Nw5VewlcPeMrAWuamTvrWaPo5uRZrfwArsLK/Zjr0dP4UBZ2vu1EugAAz4/AvfopQpJj/66N22bUgqJlBLP/9D/bgQZtp5HlhtVXwWngbdPAOlzC0kfgo7PbOr6+husBsKK47eoFkzibqIVyh3akDB1Tkr1tNe9m58a9coCY+tL2+gseNNXP9T0uepiYTLiDuYLpYYdsc2v47ZMkbKjw1Uzc4vYRA+9YclsBOhw2oCQX+ZbtnfytMYQbxGI2h55Bzn2E6Fg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35073007944872)(138986009662008)(95692535739014)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39850400002)(39840400002)(39450400003)(39410400002)(45074003)(229853002)(6116002)(8676002)(102836003)(66066001)(53936002)(1730700003)(3280700002)(38730400002)(3846002)(122556002)(110136004)(450100001)(8936002)(81166006)(6246003)(2906002)(189998001)(92566002)(3660700001)(5660300001)(33656002)(15650500001)(6512007)(36756003)(4001350100001)(2501003)(93886004)(4326008)(106116001)(2351001)(6436002)(2950100002)(6916009)(83716003)(6486002)(77096006)(5640700003)(305945005)(6506006)(99286003)(6306002)(2900100001)(7736002)(50986999)(25786008)(83506001)(82746002)(86362001)(54356999)(76176999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 03 Mar 2017 15:23:21.5196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netmod-chairs@ietf.org" Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 15:23:37 -0000 DQpIaSBORVRNT0QgV0csDQoNClBsZWFzZSBmaW5kIGJlbG93IGRyYWZ0LTMgaGF2aW5nIHRoZSBm b2xsb3dpbmcgY2hhbmdlczoNCg0KIC0gcy9yZXByZXNlbnRhdGlvbi9lbmNvZGluZy9nDQogLSBz LzIwMTYvMjAxNy8gaW4gTWlsZXN0b25lcw0KIC0gbW92ZWQgc3lzbG9nIGZyb20gTWFyIHRvIEFw cg0KIC0gbW92ZWQgZW50aXR5IGZyb20gTWFyIHRvIEFwcg0KDQpBbnkgb3RoZXIgY29tbWVudHM/ DQoNCktlbnQNCg0KDQoNCg0KTmV0d29yayBNb2RlbGluZyAoTkVUTU9EKSAgDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCkNoYXJ0ZXINCg0KQ3VycmVudCBTdGF0dXM6IEFjdGl2ZQ0KDQpD aGFpcnM6DQogICBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0Pg0KICAgS2VudCBXYXRzZW4g PGt3YXRzZW5AanVuaXBlci5uZXQ+DQoNCk9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQgQXJlYSBE aXJlY3RvcnM6DQogICBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4NCiAgIEpvZWwg SmFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT4NCg0KT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudCBB cmVhIEFkdmlzb3I6DQogICBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4NCg0KU2Vj cmV0YXJ5Og0KICAgWml0YW8gKE1pY2hhZWwpIFdhbmcgPHdhbmd6aXRhb0BodWF3ZWkuY29tPg0K DQpNYWlsaW5nIExpc3RzOg0KICAgR2VuZXJhbCBEaXNjdXNzaW9uOiBuZXRtb2RAaWV0Zi5vcmcN CiAgIFRvIFN1YnNjcmliZTogICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCiAgIEFyY2hpdmU6ICAgICAgICAgICAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL2Jyb3dzZS9uZXRtb2QvDQoNCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3Jv dXA6DQoNCiAgIFRoZSBOZXR3b3JrIE1vZGVsaW5nIChORVRNT0QpIHdvcmtpbmcgZ3JvdXAgaXMg cmVzcG9uc2libGUgZm9yIHRoZSBZQU5HDQogICBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlLCBhbmQg Z3VpZGVsaW5lcyBmb3IgZGV2ZWxvcGluZyBZQU5HIG1vZGVscy4gIFRoZQ0KICAgTkVUTU9EIHdv cmtpbmcgZ3JvdXAgYWRkcmVzc2VzIGdlbmVyYWwgdG9waWNzIHJlbGF0ZWQgdG8gdGhlIHVzZSBv ZiB0aGUNCiAgIFlBTkcgbGFuZ3VhZ2UgYW5kIFlBTkcgbW9kZWxzLCBmb3IgZXhhbXBsZSwgdGhl IG1hcHBpbmcgb2YgWUFORyBtb2RlbGVkDQogICBkYXRhIGludG8gdmFyaW91cyBlbmNvZGluZ3Mu ICBGaW5hbGx5LCB0aGUgTkVUTU9EIHdvcmtpbmcgZ3JvdXAgDQogICBhbHNvIGRlZmluZXMgY29y ZSBZQU5HIG1vZGVscyB1c2VkIGFzIGJhc2ljIFlBTkcgYnVpbGRpbmcgYmxvY2tzLCBhbmQgDQog ICBZQU5HIG1vZGVscyB0aGF0IGRvIG5vdCBvdGhlcndpc2UgZmFsbCB1bmRlciB0aGUgY2hhcnRl ciBvZiBhbnkgb3RoZXIgDQogICBJRVRGIHdvcmtpbmcgZ3JvdXAuDQogIA0KVGhlIE5FVE1PRCBX RyBpcyByZXNwb25zaWJsZSBmb3I6DQoNCiAgIGEpIE1haW50YWluaW5nIHRoZSBkYXRhIG1vZGVs aW5nIGxhbmd1YWdlIFlBTkcuICBUaGlzIGVmZm9ydCBlbnRhaWxzDQogICAgICBwZXJpb2RpY2Fs bHkgdXBkYXRpbmcgdGhlIHNwZWNpZmljYXRpb24gdG8gYWRkcmVzcyBuZXcgcmVxdWlyZW1lbnRz DQogICAgICBhcyB0aGV5IGFyaXNlLg0KDQogICBiKSBNYWludGFpbmluZyB0aGUgZ3VpZGVsaW5l cyBmb3IgZGV2ZWxvcGluZyBZQU5HIG1vZGVscy4gIFRoaXMgZWZmb3J0DQogICAgICBpcyBwcmlt YXJpbHkgZHJpdmVuIGJ5IHVwZGF0ZXMgbWFkZSB0byB0aGUgWUFORyBzcGVjaWZpY2F0aW9uLg0K DQogICBjKSBNYWludGFpbmluZyBhIGNvbmNlcHR1YWwgZnJhbWV3b3JrIGluIHdoaWNoIFlBTkcg bW9kZWxzIGFyZSB1c2VkLg0KICAgICAgVGhpcyBlZmZvcnQgZW50YWlscyBkZXNjcmliaW5nIHRo ZSBnZW5lcmljIGNvbnRleHQgdGhhdCBpbiBZQU5HDQogICAgICBleGlzdHMgYW5kIGhvdyBjZXJ0 YWluIFlBTkcgc3RhdGVtZW50cyBpbnRlcmFjdCBpbiB0aGF0IGNvbnRleHQuDQogICAgICBBbiBl eGFtcGxlIG9mIHRoaXMgaXMgWUFORydzIHJlbGF0aW9uc2hpcCB3aXRoIGRhdGFzdG9yZXMuDQoN CiAgIGQpIE1haW50YWluaW5nIGVuY29kaW5ncyBmb3IgWUFORyBtb2RlbGVkIGRhdGEuICBUaGlz IGVmZm9ydCBlbnRhaWxzDQogICAgICB1cGRhdGluZyBlbmNvZGluZ3MgYWxyZWFkeSBkZWZpbmVk IGJ5IHRoZSBORVRNT0Qgd29ya2luZyAoWE1MIGFuZA0KICAgICAgSlNPTikgdG8gYWNjb21tb2Rh dGUgY2hhbmdlcyB0byB0aGUgWUFORyBzcGVjaWZpY2F0aW9uLCBhbmQgZGVmaW5pbmcNCiAgICAg IG5ldyBlbmNvZGluZ3MgdGhhdCBhcmUgbmVlZGVkLCBhbmQgeWV0IGRvIG5vdCBmYWxsIHVuZGVy IHRoZSBjaGFydGVyDQogICAgICBvZiBhbnkgb3RoZXIgYWN0aXZlIElFVEYgd29ya2luZyBncm91 cC4NCg0KICAgZSkgTWFpbnRhaW5pbmcgWUFORyBtb2RlbHMgdXNlZCBhcyBiYXNpYyBZQU5HIGJ1 aWxkaW5nIGJsb2Nrcy4gIFRoaXMNCiAgICAgIGVmZm9ydCBlbnRhaWxzIHVwZGF0aW5nIGV4aXN0 aW5nIFlBTkcgbW9kZWxzIChpZXRmLXlhbmctdHlwZXMgYW5kDQogICAgICBpZXRmLWluZXQtdHlw ZXMpIGFzIG5lZWRlZCwgYXMgd2VsbCBhcyBkZWZpbmluZyBhZGRpdGlvbmFsIGNvcmUgWUFORw0K ICAgICAgZGF0YSBtb2RlbHMgd2hlbiBuZWNlc3NhcnkuDQoNCiAgIGYpIERlZmluaW5nIGFuZCBt YWludGFpbmluZyBZQU5HIG1vZGVscyB0aGF0IGRvIG5vdCBmYWxsIHVuZGVyIHRoZQ0KICAgICAg Y2hhcnRlciBvZiBhbnkgb3RoZXIgYWN0aXZlIElFVEYgd29ya2luZyBncm91cC4NCg0KICAgVGhl IE5FVE1PRCB3b3JraW5nIGdyb3VwIGNvbnN1bHRzIHdpdGggdGhlIE5FVENPTkYgd29ya2luZyBn cm91cCB0bw0KICAgZW5zdXJlIHRoYXQgbmV3IHJlcXVpcmVtZW50cyBhcmUgYW5kIHVuZGVyc3Rv b2QgYW5kIGNhbiBiZSBtZXQgYnkNCiAgIHRoZSBwcm90b2NvbHMgZGV2ZWxvcGVkIHdpdGhpbiB0 aGF0IHdvcmtpbmcgZ3JvdXAgKGUuZy4sIE5FVENPTkYNCiAgIGFuZCBSRVNUQ09ORikuICBUaGUg TkVUTU9EIHdvcmtpbmcgZ3JvdXAgY29vcmRpbmF0ZXMgd2l0aCBvdGhlcg0KICAgd29ya2luZyBn cm91cHMgb24gcG9zc2libGUgZXh0ZW5zaW9ucyB0byBZQU5HIHRvIGFkZHJlc3MgbmV3IG1vZGVs aW5nDQogICByZXF1aXJlbWVudHMgYW5kLCB3aGVuIG5lZWRlZCwgd2hpY2ggZ3JvdXAgd2lsbCBy dW4gdGhlIHByb2Nlc3Mgb24gYQ0KICAgc3BlY2lmaWMgbW9kZWwuDQoNCiAgIFRoZSBORVRNT0Qg d29ya2luZyBncm91cCBkb2VzIG5vdCBzZXJ2ZSBhcyBhIHJldmlldyB0ZWFtIGZvciBZQU5HDQog ICBtb2R1bGVzIGRldmVsb3BlZCBieSBvdGhlciB3b3JraW5nIGdyb3Vwcy4gSW5zdGVhZCwgdGhl IFlBTkcgZG9jdG9ycywNCiAgIGFzIG9yZ2FuaXplZCBieSB0aGUgT1BTIGFyZWEgZGlyZWN0b3Ig cmVzcG9uc2libGUgZm9yIG5ldHdvcmsNCiAgIG1hbmFnZW1lbnQsIHdpbGwgYWN0IGFzIGFkdmlz b3JzIGZvciBvdGhlciB3b3JraW5nIGdyb3VwcyBhbmQgcHJvdmlkZQ0KICAgWUFORyByZXZpZXdz IGZvciB0aGUgT1BTIGFyZWEgZGlyZWN0b3JzLg0KDQpNaWxlc3RvbmVzOg0KICANCiAgIERvbmUg ICAgIC0gU3VibWl0IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzYwODdiaXMgdG8gSUVTRyBmb3IgcHVi bGljYXRpb24NCiAgIE1hciAyMDE3IC0gU3VibWl0IGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctbW9k ZWwtY2xhc3NpZmljYXRpb24gdG8gSUVTRw0KICAgICAgICAgICAgICBmb3IgcHVibGljYXRpb24N CiAgIE1hciAyMDE3IC0gU3VibWl0IGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbCB0byBJRVNH IGZvciBwdWJsaWNhdGlvbg0KICAgQXByIDIwMTcgLSBTdWJtaXQgZHJhZnQtaWV0Zi1uZXRtb2Qt ZW50aXR5IHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uDQogICBBcHIgMjAxNyAtIFN1Ym1pdCBkcmFm dC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwgdG8gSUVTRyBmb3IgcHVibGljYXRpb24NCiAgIE9j dCAyMDE3IC0gU3VibWl0IGRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudCB0byBJRVNHIGZv ciBwdWJsaWNhdGlvbg0KICAgT2N0IDIwMTcgLSBTdWJtaXQgZHJhZnQtaWV0Zi1uZXRtb2QtcmV2 aXNlZC1kYXRhc3RvcmVzIHRvIElFU0cgZm9yDQogICAgICAgICAgICAgIHB1YmxpY2F0aW9uDQog ICBEZWMgMjAxNyAtIFN1Ym1pdCBkcmFmdC1pZXRmLW5ldG1vZC1pbnRmLWV4dC15YW5nIHRvIElF U0cgZm9yDQogICAgICAgICAgICAgIHB1YmxpY2F0aW9uDQogICBEZWMgMjAxNyAtIFN1Ym1pdCBk cmFmdC1pZXRmLW5ldG1vZC1zdWItaW50Zi12bGFuLXlhbmcgdG8gSUVTRyBmb3INCiAgICAgICAg ICAgICAgcHVibGljYXRpb24NCg0KDQoNCg0KDQoNCg0K From nobody Fri Mar 3 07:53:22 2017 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 BB8C5129468 for ; Fri, 3 Mar 2017 07:53:20 -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, RP_MATCHES_RCVD=-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 K6wsxP24mvFo for ; Fri, 3 Mar 2017 07:53:19 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A35A1293F3 for ; Fri, 3 Mar 2017 07:53:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 25D286D5 for ; Fri, 3 Mar 2017 16:53:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MqhhD28dk1yO for ; Fri, 3 Mar 2017 16:53:15 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 3 Mar 2017 16:53:16 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD63720033 for ; Fri, 3 Mar 2017 16:53:16 +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 j-vGbCtu7TtK; Fri, 3 Mar 2017 16:53:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A331C20031; Fri, 3 Mar 2017 16:53:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 48C453E94072; Fri, 3 Mar 2017 16:53:22 +0100 (CET) Date: Fri, 3 Mar 2017 16:53:22 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20170303155322.GA3345@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [netmod] yang canonical integer format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 15:53:20 -0000 Hi, the canonical format for integer types is the decimal representation. We do not seem to have a mechanism (other than a description statement) to declare that the canonical representation is lets say hexadecimal. For example, EtherType values are usually written in hexadecimal notation. If I use a plain uint16 to represent an EtherType, it comes out of a datastore rendered as a decimal number - and all I have is a description statement... Would be nice to say something like typedef ether-type { type uint16 { format "%x"; } } in plain YANG to make the hexadecimal format the canonical format. Who maintains ideas for the next YANG revision? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 3 08:30:31 2017 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 3C4D71294E8 for ; Fri, 3 Mar 2017 08:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 9X9dxAbToOKd for ; Fri, 3 Mar 2017 08:30:28 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0124.outbound.protection.outlook.com [104.47.34.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1BF129555 for ; Fri, 3 Mar 2017 08:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V75ZLpg96IpX6WGYBFcd3reBiOmyzgiw/QG/h0YPcI4=; b=FCwj6bw1dRzjgVGWV+pXNBDBo2OqDIXMP7nKj0ZypOXJcZr7bzcrE87VHrrzXY47awi0YvtS1Q+o2z1e6vt+bMzvaCOixHGB8Ba5ADO75MdxZIs+oyU2EjmGPVvw4+FzeUPJwU31rDNRNslxvC97K2em8rhRt0OdezAdta4Zr+o= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 3 Mar 2017 16:30:27 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0947.015; Fri, 3 Mar 2017 16:30:27 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: 6087bis update Thread-Index: AQHSlDt3/dLjm3esBUOakNnzuWWaLQ== Date: Fri, 3 Mar 2017 16:30:27 +0000 Message-ID: <16CDC6B4-17FA-4F52-979C-5A11949D2F05@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 6e5dceb5-93aa-4377-7ab5-08d462529a2f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:yr/uyg/B51VPf3KOrcZibAHfF1DCvy3SOroKaKC21ps68U+2/tEnt6Oq2naAxLRL4UK5uIHhS1sEXl7y3mQwvBljV+Lxw3/+YWaiMIdIRmfU5XmmUbXxh5dbSsCT5jR2L4yRtTPglEkdsFEMpBH/YK5DqTFSqh8m7vI5p20rRRTK8CXKQlU98sY8KdQ/v9QiezI4KW06Si74nUOAntWlvgglnKegPK/ZmU/uEPT2eHlWGQfHCt+IkJyWF4D8oUr8dIF7ZdhROyPnRSLSk3M91LcXRnOPj9E3C5NaIEI4dEeNm1Bui6BqBAy16qVngj7fxwiZHSNnr/cAFJ7nTTFJjQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39410400002)(39850400002)(39840400002)(83716003)(50986999)(82746002)(53936002)(305945005)(83506001)(106116001)(8676002)(54356999)(81166006)(189998001)(8936002)(7736002)(86362001)(3280700002)(3660700001)(5660300001)(2906002)(110136004)(4326008)(38730400002)(4001350100001)(6116002)(102836003)(3846002)(36756003)(2900100001)(6916009)(6436002)(77096006)(6486002)(99286003)(15650500001)(25786008)(6506006)(6512007)(92566002)(33656002)(66066001)(122556002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <256B4C2381FA794D93D2BB82B4408BA6@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 16:30:27.8631 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: "netmod@ietf.org" Subject: [netmod] 6087bis update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 16:30:30 -0000 SGkgQW5keSwNCg0KTG91IGFuZCBJIGp1c3Qgbm90aWNlZCB0aGF0IFNlY3Rpb24gMyAoWUFORyBU cmVlIERpYWdyYW1zKSBpcyBvdXQgb2YNCmRhdGUsIGFzIGl0IGlzIG1pc3Npbmcgbm90YXRpb24g ZGVzY3JpYmVkIGJ5IGBweWFuZyAtLXRyZWUtaGVscGAgKHNlZQ0KYmVsb3cpLiAgU2luY2UgdGhp cyBkcmFmdCBpcyBzdGlsbCBpbiBBRCBSZXZpZXcsIGNhbiB5b3UgcGxlYXNlIGJlDQpzdXJlIHRv IHVwZGF0ZSB0aGlzIHNlY3Rpb24sIGVpdGhlciBub3cgb3IgYWxvbmcgd2l0aCB0aGUgbmV4dCB1 cGRhdGU/DQoNClRoYW5rcywNCktlbnQgICAgLy8gc2hlcGhlcmQNCg0KDQoNCiMgcHlhbmcgLS10 cmVlLWhlbHANCg0KRWFjaCBub2RlIGlzIHByaW50ZWQgYXM6DQoNCjxzdGF0dXM+IDxmbGFncz4g PG5hbWU+IDxvcHRzPiA8dHlwZT4gPGlmLWZlYXR1cmVzPg0KDQogIDxzdGF0dXM+IGlzIG9uZSBv ZjoNCiAgICArICBmb3IgY3VycmVudA0KICAgIHggIGZvciBkZXByZWNhdGVkDQogICAgbyAgZm9y IG9ic29sZXRlDQoNCiAgPGZsYWdzPiBpcyBvbmUgb2Y6DQogICAgcncgIGZvciBjb25maWd1cmF0 aW9uIGRhdGENCiAgICBybyAgZm9yIG5vbi1jb25maWd1cmF0aW9uIGRhdGENCiAgICAteCAgZm9y IHJwY3MgYW5kIGFjdGlvbnMNCiAgICAtbiAgZm9yIG5vdGlmaWNhdGlvbnMNCg0KICA8bmFtZT4g aXMgdGhlIG5hbWUgb2YgdGhlIG5vZGUNCiAgICAoPG5hbWU+KSBtZWFucyB0aGF0IHRoZSBub2Rl IGlzIGEgY2hvaWNlIG5vZGUNCiAgIDooPG5hbWU+KSBtZWFucyB0aGF0IHRoZSBub2RlIGlzIGEg Y2FzZSBub2RlDQoNCiAgIElmIHRoZSBub2RlIGlzIGF1Z21lbnRlZCBpbnRvIHRoZSB0cmVlIGZy b20gYW5vdGhlciBtb2R1bGUsIGl0cw0KICAgbmFtZSBpcyBwcmludGVkIGFzIDxwcmVmaXg+Ojxu YW1lPi4NCg0KICA8b3B0cz4gaXMgb25lIG9mOg0KICAgID8gIGZvciBhbiBvcHRpb25hbCBsZWFm LCBjaG9pY2UsIGFueWRhdGEgb3IgYW55eG1sDQogICAgISAgZm9yIGEgcHJlc2VuY2UgY29udGFp bmVyDQogICAgKiAgZm9yIGEgbGVhZi1saXN0IG9yIGxpc3QNCiAgICBbPGtleXM+XSBmb3IgYSBs aXN0J3Mga2V5cw0KDQogIDx0eXBlPiBpcyB0aGUgbmFtZSBvZiB0aGUgdHlwZSBmb3IgbGVhZnMg YW5kIGxlYWYtbGlzdHMNCg0KICAgIElmIHRoZSB0eXBlIGlzIGEgbGVhZnJlZiwgdGhlIHR5cGUg aXMgcHJpbnRlZCBhcyAiLT4gVEFSR0VUIiwgd2hlcmUNCiAgICBUQVJHRVQgaXMgZWl0aGVyIHRo ZSBsZWFmcmVmIHBhdGgsIHdpdGggcHJlZml4ZWQgcmVtb3ZlZCBpZiBwb3NzaWJsZS4NCg0KICA8 aWYtZmVhdHVyZXM+IGlzIHRoZSBsaXN0IG9mIGZlYXR1cmVzIHRoaXMgbm9kZSBkZXBlbmRzIG9u LCBwcmludGVkDQogICAgd2l0aGluIGN1cmx5IGJyYWNrZXRzIGFuZCBhIHF1ZXN0aW9uIG1hcmsg InsuLi59PyINCg0KDQoNCg0K From nobody Fri Mar 3 08:41:50 2017 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 4902B1289C4 for ; Fri, 3 Mar 2017 08:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 7Zf6OOeDn_cC for ; Fri, 3 Mar 2017 08:41:48 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0123.outbound.protection.outlook.com [104.47.37.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04C61289B0 for ; Fri, 3 Mar 2017 08:41:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Cl52z9iUKGbx5h32PGqFqbEoYBBAZcw5R33rPa2fmoQ=; b=bbQBiIcyahqkQNrz4/pNJwJ0UH4y8Tvh5SSoo8duzcPyXdHXfr39kLAiUniX/s9HDwl+e3XiJRtW9uVv6aqUpHNVIOELSbpJB6Dga4KkMzlzpTBMvLdxw3Fx+owdIKJSAU6K7IjTN/staZMVkXahPognZTAnu5Bk2lqSkBIwtDk= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 3 Mar 2017 16:41:44 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0947.015; Fri, 3 Mar 2017 16:41:44 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: stable reference for tree diagram notation Thread-Index: AQHSlD0Kf+J5u9nqmEehA2iSQMJSUQ== Date: Fri, 3 Mar 2017 16:41:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 373a5ba0-6464-408b-e14b-08d462542d60 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:WDlHMaNaomA4kRZ7bvdoFWSTm1o68qCQ/sCTinSw2rsFP6ZcfDQpr+V8w+xsfq2vudtP7u5Sn1rcjjUPJiZvv0PvXRcEM9ckO91RTH/44jpz9jRZQWhnGfG4i90U8Oln70hKRrNx9B4NeKrLUGagb/XBC8FJ8Ld7t/fZfSjMHBlhxMGt2o1hd7+CF3nY8HlLM14NCf9VKCdZ8+EUlpCLn5pO046nsOWp1Vyz2YnL24Up3ZrF3+MjMv370HQj3fC54mndPcWrCTRQPG+t8MJ9wa1Y/wjAVWKg8B6OgWK8YH9kopOeLiX8qAM86D+I9+3KLU3eB1E7SXRx/t01/Ok5Qw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123558025)(20161123562025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39410400002)(39840400002)(39860400002)(39850400002)(2900100001)(36756003)(1730700003)(86362001)(66066001)(3660700001)(106116001)(8676002)(3280700002)(8936002)(2501003)(122556002)(81166006)(3846002)(6116002)(4001350100001)(102836003)(53936002)(54356999)(2351001)(305945005)(33656002)(50986999)(6512007)(92566002)(99286003)(77096006)(450100001)(189998001)(2906002)(7736002)(6916009)(83716003)(6436002)(38730400002)(25786008)(110136004)(5640700003)(83506001)(5660300001)(6486002)(82746002)(6506006)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 03 Mar 2017 16:41:44.2775 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 16:41:49 -0000 DQpBbGwsDQoNCkxvdSBhbmQgSSB3ZXJlIGRpc2N1c3NpbmcgaG93IGl0IHNlZW1zIHVubmVjZXNz YXJ5IHRoYXQgZXZlcnkgZHJhZnQNCmhhcyB0aGUgc2FtZSBib2lsZXJwbGF0ZSB0ZXh0IHJlZ2Fy ZGluZyBob3cgdG8gaW50ZXJwcmV0IHRyZWUgZGlhZ3JhbQ0Kbm90YXRpb25zLiAgSXQgd291bGQg YmUgbmljZSBpZiBkcmFmdHMgY291bGQgaW5zdGVhZCBqdXN0IHJlZmVyZW5jZQ0KYW5vdGhlciBk cmFmdCB0aGF0IGNvbnRhaW5zIHRoaXMgaW5mb3JtYXRpb24uICBEb2VzIHRoaXMgbWFrZSBzZW5z ZT8NCg0KQXNzdW1pbmcgd2UncmUgaW50ZXJlc3RlZCBpbiBoYXZpbmcgc3VjaCBhIHJlZmVyZW5j ZSwgd2UgY291bGQgZGVmaW5lDQphIG1pbmktUkZDIG9yLCBwZXJoYXBzLCBsZXZlcmFnZSBTZWN0 aW9uIDMgb2YgNjA4N2JpcyAoWUFORyBUcmVlIA0KRGlhZ3JhbXMpLiAgRWl0aGVyIHdheSwgd2Un ZCB3YW50L25lZWQgdG8gZW5zdXJlIHRoZSBpbmZvcm1hdGlvbg0KaXMgdXBkYXRlZCBpbiBhIHRp bWVseSBtYW5uZXIuDQoNClR3byByZWFzb25zIGZvciB3aHkgd2UgbWF5IG5vdCB3YW50IHRvIHB1 cnN1ZSB0aGlzIGFyZToNCiAgMSkgd2UgY2Fu4oCZdCB1cGRhdGUgdGhlIHJlZmVyZW5jZSBmYXN0 IGVub3VnaA0KICAyKSBkcmFmdHMgbWlnaHQgYWRkIHNvbWUgcHJvcHJpZXRhcnkgYW5ub3RhdGlv bnMNCg0KSXMgdGhpcyB3b3J0aCBwdXJzdWluZyBhdCBhbGw/DQoNClRoYW5rcywNCktlbnQNCg0K DQo= From nobody Fri Mar 3 08:52:25 2017 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 18AE812958B for ; Fri, 3 Mar 2017 08:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 Yp_yHvQ0azKm for ; Fri, 3 Mar 2017 08:52:22 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0107.outbound.protection.outlook.com [104.47.37.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260871294BC for ; Fri, 3 Mar 2017 08:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R+LrUZ25B03OxpGmM015LZoqXhzjULcqWl6fkA02mbU=; b=AfOHIrdZsco5bkHEUmSWzlq5QmXdWJwV9SRHfD0DLldliCvxxxuFLFz4ww3qYS99jey9JXzIc8EQpO5hyBae+CoIDq0tEWGOAZBCpxsZ6DrIrHRUrvBppsPtdB8yazz9/Jtn44mZr0uJ9xSL5AociZ9C7/74oFiORacITjjWj6Y= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 3 Mar 2017 16:52:20 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0947.015; Fri, 3 Mar 2017 16:52:20 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] yang canonical integer format Thread-Index: AQHSlDZMewvn5zHZ50+FdydX6eHLRqGDAMyA Date: Fri, 3 Mar 2017 16:52:19 +0000 Message-ID: <4B5054DF-3B5C-4727-9245-7F0150821C8D@juniper.net> References: <20170303155322.GA3345@elstar.local> In-Reply-To: <20170303155322.GA3345@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 7d7406da-17a6-49e9-2d91-08d46255a848 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1444; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:FMwn1OTnQoSuBCO7mAZiapIs0H/DNHJqgip8FYz1crfv6M8IwlzyKC3fzbhWyDqNRowO4+bG85uO02lsfezl/lrgajfAok0LsKjse1xcLRmYRsBVPSWg8mTtNf+ec0Dkq34BdEAZxre46FogWPjtjXwElBKos7mruKSq/Gk5pXgujBOvClbmrCSeNY9qWYF7oJddQSrrqGquT1IZfGgGLEnO4P8wXm7TfmItzEF0iin6jN5EGVKlwqUrYWxTuZfIFSjroweoqxpoBn9q7B8nunINSuV7bKgJ/Eot/iJpzG4DfGBFG0e7uQ9Nz82Y3CYQdOabZfKkrMjaQAZ9B2K0jg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39410400002)(39450400003)(39850400002)(3846002)(99286003)(92566002)(6246003)(2950100002)(6116002)(50986999)(36756003)(76176999)(3660700001)(229853002)(83716003)(2906002)(38730400002)(53936002)(102836003)(3280700002)(6512007)(6306002)(83506001)(106116001)(82746002)(66066001)(2900100001)(5660300001)(2501003)(4001350100001)(33656002)(189998001)(54356999)(8676002)(8936002)(122556002)(7736002)(305945005)(25786008)(77096006)(6486002)(86362001)(6506006)(6436002)(81166006)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6F198B69E4FE154E94B5D641E08FA29D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 16:52:19.9564 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: Re: [netmod] yang canonical integer format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 16:52:24 -0000 DQpIaSBKdWVyZ2VuLA0KDQo+IEhpLA0KPiANCj4gdGhlIGNhbm9uaWNhbCBmb3JtYXQgZm9yIGlu dGVnZXIgdHlwZXMgaXMgdGhlIGRlY2ltYWwgcmVwcmVzZW50YXRpb24uDQo+IFdlIGRvIG5vdCBz ZWVtIHRvIGhhdmUgYSBtZWNoYW5pc20gKG90aGVyIHRoYW4gYSBkZXNjcmlwdGlvbiBzdGF0ZW1l bnQpDQo+IHRvIGRlY2xhcmUgdGhhdCB0aGUgY2Fub25pY2FsIHJlcHJlc2VudGF0aW9uIGlzIGxl dHMgc2F5IGhleGFkZWNpbWFsLg0KPiBGb3IgZXhhbXBsZSwgRXRoZXJUeXBlIDxodHRwczovL2Vu Lndpa2lwZWRpYS5vcmcvd2lraS9FdGhlclR5cGU+IHZhbHVlcw0KPiBhcmUgdXN1YWxseSB3cml0 dGVuIGluIGhleGFkZWNpbWFsIG5vdGF0aW9uLiBJZiBJIHVzZSBhIHBsYWluIHVpbnQxNg0KPiB0 byByZXByZXNlbnQgYW4gRXRoZXJUeXBlLCBpdCBjb21lcyBvdXQgb2YgYSBkYXRhc3RvcmUgcmVu ZGVyZWQgYXMgYQ0KPiBkZWNpbWFsIG51bWJlciAtIGFuZCBhbGwgSSBoYXZlIGlzIGEgZGVzY3Jp cHRpb24gc3RhdGVtZW50Li4uIFdvdWxkDQo+IGJlIG5pY2UgdG8gc2F5IHNvbWV0aGluZyBsaWtl DQo+IA0KPiAgdHlwZWRlZiBldGhlci10eXBlIHsNCj4gICAgdHlwZSB1aW50MTYgeyBmb3JtYXQg IiV4IjsgfQ0KPiAgfQ0KPg0KPiBpbiBwbGFpbiBZQU5HIHRvIG1ha2UgdGhlIGhleGFkZWNpbWFs IGZvcm1hdCB0aGUgY2Fub25pY2FsIGZvcm1hdC4gV2hvDQo+IG1haW50YWlucyBpZGVhcyBmb3Ig dGhlIG5leHQgWUFORyByZXZpc2lvbj8NCj4NCj4gL2pzDQoNCg0KSWRlYXMgZm9yIHRoZSBuZXh0 IHJldmlzaW9uIG9mIFlBTkcgYXJlIGJlaW5nIGNhcHR1cmVkIGluIHRoaXMgdHJhY2tlcjoNCg0K ICBodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL3lhbmctbmV4dC9pc3N1ZXMNCg0KDQpLLg0K DQoNCg0K From nobody Fri Mar 3 09:02:33 2017 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 1ACBD129956 for ; Fri, 3 Mar 2017 09:02:33 -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, RP_MATCHES_RCVD=-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 kk0_4wweuqfl for ; Fri, 3 Mar 2017 09:02:30 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BAF129955 for ; Fri, 3 Mar 2017 09:02:29 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 811846BA; Fri, 3 Mar 2017 18:02:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NEI2IWDRKvzG; Fri, 3 Mar 2017 18:02:26 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 3 Mar 2017 18:02:28 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 22A4E20035; Fri, 3 Mar 2017 18:02:28 +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 oPJ_ehzHDZDC; Fri, 3 Mar 2017 18:02:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0F1220031; Fri, 3 Mar 2017 18:02:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 537D53E94231; Fri, 3 Mar 2017 18:02:33 +0100 (CET) Date: Fri, 3 Mar 2017 18:02:33 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20170303170233.GB3345@elstar.local> Mail-Followup-To: Kent Watsen , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 17:02:33 -0000 On Fri, Mar 03, 2017 at 04:41:44PM +0000, Kent Watsen wrote: > > All, > > Lou and I were discussing how it seems unnecessary that every draft > has the same boilerplate text regarding how to interpret tree diagram > notations. It would be nice if drafts could instead just reference > another draft that contains this information. Does this make sense? > > Assuming we're interested in having such a reference, we could define > a mini-RFC or, perhaps, leverage Section 3 of 6087bis (YANG Tree > Diagrams). Either way, we'd want/need to ensure the information > is updated in a timely manner. > > Two reasons for why we may not want to pursue this are: > 1) we can’t update the reference fast enough > 2) drafts might add some proprietary annotations > > Is this worth pursuing at all? This has been discussed before. The tree format that tools generate has evolved a bit over time and the current setup allows to have some evolution. The question is whether we have reached a state where the evolution has come to standstill and we can nail a common tree format down. If so, someone should write an I-D and then the format should in my opinion become a separate RFC that can be referenced. (I would not roll this into RFC 6087 so that the tree format can be revised without opening all of RFC 6087.) Others have argued in the past that the replication is not such a big deal and the replication has the advantage that people who do not read YANG everyday have an explanation right in place without having to lookup another RFC. For me personally, this is a low low priority item but if someone has spare cycles to spend, this is a good target. Such an RFC will get tons of references and you become famous. Oh, now I get interested... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 3 09:36:48 2017 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 4C6B4129957 for ; Fri, 3 Mar 2017 09:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 5UaKmC3GAwCs for ; Fri, 3 Mar 2017 09:36:42 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F6712994E for ; Fri, 3 Mar 2017 09:36:41 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id n11so20788814wma.1 for ; Fri, 03 Mar 2017 09:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7GNit4PEdZqBQg9iHNAwksGoZ9iV7JdhLV7lbfjFTFQ=; b=JZP8njeAFXYzE+TgM66b8mLi/t51MN1srDgluSzWlBBnogZ+pWdviJ7Z2bhIzXMxnU I/MI9IH+WbJby9mSV4+ELrCzr+8CE7z/xEOEka3aTCOy+5ocBAG/BTHHN2J6EVpx21C3 WdSELdSkrimFA7TuuVq26qk1VZ6gwTwQbdgavbfRaxb6aTlO4Nz78nhIZbErvSOvngRK x3/Y9my68JKH/BEUQOAoSUZ4r4/zQNK+LmIjlWcCCYp1g3ftMteCIcV6AJyWCIryZ6wA CVkvEto0GweJx+h4b4odZXaUtrhVhyVZBLUZ5JU9mibbCKOikWZtOzN9DtVmXSzIGbjf NjUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7GNit4PEdZqBQg9iHNAwksGoZ9iV7JdhLV7lbfjFTFQ=; b=dwwYWIhcJqcF98Gn3QQ1d04D5xRopqnThmRezW6DdaiPSas4Vzv3Ee7f56akcv3jH1 buP5bJvHdPVh1bigXo8hzwENk6vCcPb4G4IsOL1pyt+cN35xRMuGA52UUPi5NzHAecjx ZKp3Ct/SPx0M9DMVL3VXPV6qn4MUr7a+QOgEuc/nM2IbWWa5fIMO+JH5+oNV4jrTK2Vl XYuvnvQHAHroziLEQ3X8ZfahM55fWdYapm62gA/0z7+1PW9StlqmGEpz5t8A0/G0Wxb2 XkPyd7DGd8bssY3gxoW6b/C5QLKuAQksv13MeuCoVMi1dwIAD5L/uuv5C0MypkOwHQ6i IBLQ== X-Gm-Message-State: AMke39nZEvg0+vImRNEnF1P5Wxm1+1xTvfhJyN5V6JBkqE3l0LNorztxJCGdBLtKTWDvGH4tASgBSdoNNH4JEA== X-Received: by 10.28.46.213 with SMTP id u204mr1855606wmu.136.1488562600264; Fri, 03 Mar 2017 09:36:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Fri, 3 Mar 2017 09:36:39 -0800 (PST) In-Reply-To: <20170303170233.GB3345@elstar.local> References: <20170303170233.GB3345@elstar.local> From: Andy Bierman Date: Fri, 3 Mar 2017 09:36:39 -0800 Message-ID: To: Juergen Schoenwaelder , Kent Watsen , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11497ace03e7b40549d6fdb2 Archived-At: Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 17:36:44 -0000 --001a11497ace03e7b40549d6fdb2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Originally 6087bis had a guideline for each draft to have an informative reference to 6087bis tree diagram section. This got removed along the way (I can't find it in sec 4.9). It is important that documents use the exact same symbols as every other tree diagram, so the reader can learn to interpret a tree diagram without constantly checking the mapping guide. It is less important that all documents have to same set of identifiers in the diagram. E.g., if the module only exports groupings, then the groupings should be in the tree diagram. IMO the tree diagrams are too verbose now, mostly due to leafref and if-features. Andy Here is the output of pyang v1.7.1 --tree-help Each node is printed as: is one of: + for current x for deprecated o for obsolete is one of: rw for configuration data ro for non-configuration data -x for rpcs and actions -n for notifications is the name of the node () means that the node is a choice node :() means that the node is a case node If the node is augmented into the tree from another module, its name is printed as :. is one of: ? for an optional leaf, choice, anydata or anyxml ! for a presence container * for a leaf-list or list [] for a list's keys is the name of the type for leafs and leaf-lists If the type is a leafref, the type is printed as "-> TARGET", where TARGET is either the leafref path, with prefixed removed if possible. is the list of features this node depends on, printed within curly brackets and a question mark "{...}?" On Fri, Mar 3, 2017 at 9:02 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Mar 03, 2017 at 04:41:44PM +0000, Kent Watsen wrote: > > > > All, > > > > Lou and I were discussing how it seems unnecessary that every draft > > has the same boilerplate text regarding how to interpret tree diagram > > notations. It would be nice if drafts could instead just reference > > another draft that contains this information. Does this make sense? > > > > Assuming we're interested in having such a reference, we could define > > a mini-RFC or, perhaps, leverage Section 3 of 6087bis (YANG Tree > > Diagrams). Either way, we'd want/need to ensure the information > > is updated in a timely manner. > > > > Two reasons for why we may not want to pursue this are: > > 1) we can=E2=80=99t update the reference fast enough > > 2) drafts might add some proprietary annotations > > > > Is this worth pursuing at all? > > This has been discussed before. The tree format that tools generate > has evolved a bit over time and the current setup allows to have some > evolution. The question is whether we have reached a state where the > evolution has come to standstill and we can nail a common tree format > down. If so, someone should write an I-D and then the format should in > my opinion become a separate RFC that can be referenced. (I would not > roll this into RFC 6087 so that the tree format can be revised without > opening all of RFC 6087.) Others have argued in the past that the > replication is not such a big deal and the replication has the > advantage that people who do not read YANG everyday have an > explanation right in place without having to lookup another RFC. > > For me personally, this is a low low priority item but if someone has > spare cycles to spend, this is a good target. Such an RFC will get > tons of references and you become famous. Oh, now I get interested... > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11497ace03e7b40549d6fdb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Originally 6087bis had a guideline = for each draft to have an informative reference to=C2=A0
6087bis = tree diagram section.=C2=A0 This got removed along the way (I can't fin= d it in sec 4.9).

It is important that documents u= se the exact same symbols as every other
tree diagram, so the rea= der can learn to interpret a tree diagram without
constantly chec= king the mapping guide.

It is less important that = all documents have to same set of identifiers in the diagram.
E.g= ., if the module only exports groupings, then the groupings should be in th= e
tree diagram.

IMO the tree diagrams ar= e too verbose now, mostly due to leafref and if-features.

Andy


Here is the output of = pyang v1.7.1 --tree-help


Each = node is printed as:

<status> <flags> &= lt;name> <opts> <type> <if-features>

=C2=A0 <status> is one of:
=C2=A0 =C2=A0 + =C2=A0fo= r current
=C2=A0 =C2=A0 x =C2=A0for deprecated
=C2=A0 = =C2=A0 o =C2=A0for obsolete

=C2=A0 <flags> i= s one of:
=C2=A0 =C2=A0 rw =C2=A0for configuration data
=C2=A0 =C2=A0 ro =C2=A0for non-configuration data
=C2=A0 =C2=A0 = -x =C2=A0for rpcs and actions
=C2=A0 =C2=A0 -n =C2=A0for notifica= tions

=C2=A0 <name> is the name of the node<= /div>
=C2=A0 =C2=A0 (<name>) means that the node is a choice node=
=C2=A0 =C2=A0:(<name>) means that the node is a case node<= /div>

=C2=A0 =C2=A0If the node is augmented into the tre= e from another module, its
=C2=A0 =C2=A0name is printed as <pr= efix>:<name>.

=C2=A0 <opts> is one = of:
=C2=A0 =C2=A0 ? =C2=A0for an optional leaf, choice, anydata o= r anyxml
=C2=A0 =C2=A0 ! =C2=A0for a presence container
=C2=A0 =C2=A0 * =C2=A0for a leaf-list or list
=C2=A0 =C2=A0 [<= ;keys>] for a list's keys

=C2=A0 <type&g= t; is the name of the type for leafs and leaf-lists

=C2=A0 =C2=A0 If the type is a leafref, the type is printed as "->= ; TARGET", where
=C2=A0 =C2=A0 TARGET is either the leafref = path, with prefixed removed if possible.

=C2=A0 &l= t;if-features> is the list of features this node depends on, printed
=C2=A0 =C2=A0 within curly brackets and a question mark "{...}?= "


On Fri, Mar 3, 2017 at 9:02 AM, Juergen Schoenwaelder= <j.schoenwaelder@jacobs-university.de> w= rote:
On Fri, Mar 03, 2017 at 04:41:44PM = +0000, Kent Watsen wrote:
>
> All,
>
> Lou and I were discussing how it seems unnecessary that every draft > has the same boilerplate text regarding how to interpret tree diagram<= br> > notations.=C2=A0 It would be nice if drafts could instead just referen= ce
> another draft that contains this information.=C2=A0 Does this make sen= se?
>
> Assuming we're interested in having such a reference, we could def= ine
> a mini-RFC or, perhaps, leverage Section 3 of 6087bis (YANG Tree
> Diagrams).=C2=A0 Either way, we'd want/need to ensure the informat= ion
> is updated in a timely manner.
>
> Two reasons for why we may not want to pursue this are:
>=C2=A0 =C2=A01) we can=E2=80=99t update the reference fast enough
>=C2=A0 =C2=A02) drafts might add some proprietary annotations
>
> Is this worth pursuing at all?

This has been discussed before. The tree format that tools generate
has evolved a bit over time and the current setup allows to have some
evolution. The question is whether we have reached a state where the
evolution has come to standstill and we can nail a common tree format
down. If so, someone should write an I-D and then the format should in
my opinion become a separate RFC that can be referenced. (I would not
roll this into RFC 6087 so that the tree format can be revised without
opening all of RFC 6087.) Others have argued in the past that the
replication is not such a big deal and the replication has the
advantage that people who do not read YANG everyday have an
explanation right in place without having to lookup another RFC.

For me personally, this is a low low priority item but if someone has
spare cycles to spend, this is a good target. Such an RFC will get
tons of references and you become famous. Oh, now I get interested...

/js

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

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

--001a11497ace03e7b40549d6fdb2-- From nobody Fri Mar 3 11:13:47 2017 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 806D91295AF for ; Fri, 3 Mar 2017 11:13:46 -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, RP_MATCHES_RCVD=-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 suOhN_obgzLx for ; Fri, 3 Mar 2017 11:13:45 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4301204D9 for ; Fri, 3 Mar 2017 11:13:45 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1335572C for ; Fri, 3 Mar 2017 20:13:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0zz5eZC_xSnD for ; Fri, 3 Mar 2017 20:13:41 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 3 Mar 2017 20:13:43 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C041320033 for ; Fri, 3 Mar 2017 20:13:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WUwgqXCa0NGi; Fri, 3 Mar 2017 20:13:42 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E114920031; Fri, 3 Mar 2017 20:13:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7F2E33E944CA; Fri, 3 Mar 2017 20:13:48 +0100 (CET) Date: Fri, 3 Mar 2017 20:13:48 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20170303191348.GA3570@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [netmod] rfc 6087bis - stress importance of instance examples X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:13:46 -0000 Hi, my experience is that when writing YANG modules it is tremendously helpful to focus on the instance documents. I find it essential to write down example snippets of instance documents to see whether they look elegant or clumsy. This is often not easy to determine from just reading a YANG model, in particular if groupings are involved. Examples help so much - you can easily spot whether the usage of singular or plural is reasonable in your names, whether you have redundancy in your names, whether the overall organization is effective. Even better, we have tools that can validate the examples so we can even be sure the examples are correct. (And if you do not know whether you got your pattern statement right, well, one way is to write examples.) I think we should encourage authors to write examples. It will help them to create better models and it will help reviewers tremendously while reviewing models. Good examples will also help users to get started. /js (who apparently is doing some heavy YANG reviewing work today) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 3 12:09:23 2017 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 09AD9129543 for ; Fri, 3 Mar 2017 12:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 saPzhR19s27o for ; Fri, 3 Mar 2017 12:09:20 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0104.outbound.protection.outlook.com [104.47.32.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCA7126BF7 for ; Fri, 3 Mar 2017 12:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OA9MvsfaiRckf9a2NHgoAN70X2Muw3ykbhsKrTJ/vvA=; b=aw3RiRghMMEXD7B+IQNX6qvFuHTdA1TqNEVdTWEQtPECVUufL/fJG/Z9I6XpjUrx7pFBfa5H6/XRV1zcT7QJFh96S0av1/kxjJShmkQ1/sWadLpUPl+mTm8BJTw3+kqI2cENJ+7Gxw22Vz7qXdItlcb/zlULFpfDuUp/9+05oe0= Received: from CO2PR05CA044.namprd05.prod.outlook.com (10.141.241.172) by BY2PR0501MB2006.namprd05.prod.outlook.com (10.163.197.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 3 Mar 2017 20:09:18 +0000 Received: from BN1BFFO11OLC001.protection.gbl (2a01:111:f400:7c10::1:140) by CO2PR05CA044.outlook.office365.com (2a01:111:e400:1429::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.961.8 via Frontend Transport; Fri, 3 Mar 2017 20:09:18 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1BFFO11OLC001.mail.protection.outlook.com (10.58.145.12) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.947.7 via Frontend Transport; Fri, 3 Mar 2017 20:09:17 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 3 Mar 2017 12:09:16 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v23K9EY4030165; Fri, 3 Mar 2017 12:09:15 -0800 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v23K5AAe059307; Fri, 3 Mar 2017 15:05:11 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201703032005.v23K5AAe059307@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20170303191348.GA3570@elstar.local> Date: Fri, 3 Mar 2017 15:05:10 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(2980300002)(189002)(199003)(9170700003)(106466001)(105596002)(7696004)(189998001)(92566002)(86362001)(6916009)(2950100002)(5660300001)(4326008)(8936002)(6246003)(81166006)(8676002)(7126002)(2810700001)(53936002)(38730400002)(110136004)(5003940100001)(229853002)(356003)(626004)(2906002)(50466002)(48376002)(8276002)(305945005)(47776003)(6306002)(77096006)(53416004)(50986999)(54356999)(1076002)(76506005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB2006; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11OLC001; 1:kHn9nmKprePhC0azSvVXl7vcvWVcePTdVgNNnHgiUPtJULFxznHf3qOoH+3EFehIQDN+ZZBZs3+uwnvbdWyZwchjt037wxlUk84ZIytmuIx6MmJ4ztTil+VZD8tv5rQSkkWxxLJ8S9u2s3wfYiv02frn+GX209JGz+Pe96y7qhiVOHCagzt/X7frq5eYuEYRObiK8AQeIQJSYspq3Kig/7MmsofQCp49jsUV01mV687C28eGH5RudxGrx8wKLOswVyR9OhlFFUTNgFj7uF1CvwpNar0cWdnWd4u35UXFBhRx8iXaFrFOYFRulLiXUunyCqQSuQW1DB670vZ2bm226vdRFu1MvMdMna2fNahBMUIwm/iJCOKYpLyQAKIyiTxxsVyaxPwofiH+/jw2RRdQc/iu6ChAmOWzhTUFEVxqUAA0be+8w8xgbYdmH21MXnXkNGMJtFnJlX34nw5Y1C0GXuejMEfKWH5+JilMZqi3dySiQr9UC7Y5j/EZoazLzbjmK0GtMVg1VaHc6nsNOpaiajhqNEerW5avgT6z0/A+Nqx9hSaWN5VRvA8YUcmam1wEnsO7v/JIh2Qmj+1H7wmm+w== X-MS-Office365-Filtering-Correlation-Id: 4709dd97-890f-41f8-9eeb-08d462712bfd X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR0501MB2006; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2006; 3:GCemALFMrABhH8yijUbDrj7GjWEno+qXxspbcxEYticaDH8m4XAB3MjZ2jun1tlsMtd1MFA/OwA2yRfquhR8bVNkq3BL+qOwfZGNdP+E1WuTw0acLZ9EMhU2c3s+J2SAg1FWzKTd++W+yqy0JsEAjZEL0sxRzV0ZVyLMNJhzsOe2NGET/zVzpMykjn+GVqE0zr6FmM5cKt48BEH3xspUzXkuqH+VVlc7g8HY5jlbAMuN8cIAU7q1D0EB4CP2BOqy55ZvJWh4VZxlp5nR4Cu4MyO2EnB533bzjPP5cOF1VcZ0WumDOQX/rouOEN+vbf9rnXuX+8PjYbGLyLrU6zd1LEK8D8H0gQAoq+cHy3Qt1HuONVLfHAoQGpI24drGV5KD; 25:ofR+0MfnKx8oxBK478s29bgr13gRK9pnRDeQEn+cMFPnAoFlva4oyRq+FKCCo1qU+R5K4N4Tjia3D7iweH2VMhEXrD6gbWTKWJ0gKiTkKYtN9wGrExx8+7JTB3esg75guGdNr1Mfd2/42nwxrsAjYAkp5brimU2h96jRtvbAdA74trLPkEQtLksLOlNrYNoBd5HhubMLYqXTtb4czy1QrLWf1MfUMM1bFMQl3aoRc1vdXNuKUEnhn69qoKGL0ZlcJiSKxbVz+nI7BvY2d9PDrm+kijdk3tM1BvlDTpUB6iX6Ol5+uPelW+ehGOhAAH9aN+qn8MkBCtdy+lyDTZOoyZPGy9L4Tnjm9mUcWcBGQvspq45XIeH8ZGqD3xZubQq8SkqWquIAYGoLsIQ/yF4n7zl9B04MMxdky2lffjPnEwKopSh2qRKw11/PZuN6UK8rfSRKDGT3rj4+ynsHFOaClA== X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2006; 31:dWspVg8JMqdekKbqmhGzSOJghSJzZslWTt9UIR9otbFGdx0uoh/J/k/lavm1h7huFpzRk6RAbFUhEWNtwd6ZNNS2SjqU8ISU9zHo+36Gk/+NSnpqEwozRNYUhz0Bf5CtvrUmHPExzs0zVfE8C3JVarlEHXZPvcetizz5YgmWyXNNhGrpng6hhQapbLoClEpiMIWNB9c6pmhBt09eMtOU/qeW5YbRLRFyVBZstD5p0j1JYwu8rRB6oIIUAiLf75j3ds5cC7KliQqXgeNs1SR4Vw==; 20:3k9oCo7NkwOcxjoZ8iquqEq6FjsUg4sDBwepQIyuwhPERj12v0+KAzLw7w35lBPrBbXZvNvbWG7UqNVYA4HOEaxLjzgU8pA6My0zxoRO58/lXfYqWwKwKEi5uiPCb9e+04jHpSN/h7AQ80m20mQ0oaLDRWOU9AhiAhEuZKj0S6tiNqSoy9LIBfZPD+mvZ6PLGLl+k/H/W6PvMyS7fKj1+eOJEM9wqdVQ8HPh9CYvAj5e88AW5ftsED2NcfKdNonwcQENEpOnzwSv/emCn53gr5y3QIt3xz37kH6gg7/I/6G2yh8LlTt8qf5tudTFRgQJdLWT3NTYPsXQzq1ckX2Y/p9gvniRbGT0hU83EDk4TmOleJ4uPb06tSiRQryFTdBJlYTD7LRBEql+BLydhJwDqasKmW7L2sF/1v4Fut+GF3fHLdIlu3GXd3NGtXo/epuAAXyq9mBW13ABCsZ93iZlPKY0NBaU0uTFMuurxl20UwjPEgwZdJCZvTRFaXbEfsqq X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13017025)(13015025)(13023025)(13024025)(13018025)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BY2PR0501MB2006; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB2006; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2006; 4:Tp35wiKQ/VzkfJLwrmEyHfFdqQTutgaMxGxebRxeNYbJNZt6Yut+wINC/NmM/P20LEzcaWQosdaNbH0JFjt4/O+dgMfWN9DPcXMh63WjmLe4PFji4KpRUQOlDl2tSBmRXYuG160IAgXyDKCnJiA3IsndR+Cfa8+RbDkmdSa/r4reY8zaKTwHBMYQvbyfUcqKXqXkrYgH1SU9VOKVUHz0yNkDM/DNHyM0f+8uCTBRl+f54cgvTSMotMopKxSRhXcGm5tOj2w+r4yRUs+O3wq1xAbRjy6oXnWHCFQCFqvcW8jsU90hmGJ47YeMJcRq0VG/lCO2RnTMqFIh+ALN28a3kjNgu2EZlql7EHiYNJqcJx/R0gFPLA/6CEkemBBx1oq7hGKx7OdcpDet7Dp3ZEankkzvm5L18Pc7V0a9hVpbI/dP8+9+Ao1YXSl62keC3ZdeTWdQoN0mzJTdk87DhpnZ1Vj5zxQ/YGNt4pu+5NusEBF9MbfVO0r7nSkSv95XfFMh+Hy7ZatA3+Rao0Jej360HsXC96owHkKwlEdaV/PbZEO93TdT7AoATL5FxA5RBKytHVri8kyV/8TGm5PWqarYolyNPqml2RwgNYQOAPDjCWk/OHqQ8mBwkohKz8c2xoRmXc8ylxs0EpjJXxgZFvo0dCPrCnWlPDr75/0rb5DCRFv5mMRouLPcQpIK4rF66pQ2OHoAF4eipGe9f4/wUjVgOw== X-Forefront-PRVS: 0235CBE7D0 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR0501MB2006; 23:xtsVBuBeHaHKtLNcw+U4gCSyCsHD4YqMSETREMw?= =?us-ascii?Q?1K8UeQhqwA1BEQORLABNL+zuDGt7TQhcFWUUnHtmQd91rxp/g7PyqkOl7C5/?= =?us-ascii?Q?D1IEthtv4JyDu6Cm4wSU+bN47K171Q4Q6hNbnBw13fYYtAL1DjrYaAV2S9JZ?= =?us-ascii?Q?PbGEAypiPT9F+PRx01LCM3fUNh26XHYg8oIfo/48PAANvPg6VSKDH3EJg1yg?= =?us-ascii?Q?mfsY3oaaaVLAqeJYcc3uF6SgfMK79mbDPa+EGlB/Xq8j7jv5QQnn2U73t/aJ?= =?us-ascii?Q?k89FtvGd3YHzJLDyQ/cV5/iyBg+ymh2ebSlVFsw4VqXXdKbI56r+l8XBEECM?= =?us-ascii?Q?B7LOhYmJsMLLqrwfJZLPpFiIeRUmbjrOgowvopvnw3CA80rykC9/3HzMfmj7?= =?us-ascii?Q?28demOxSOLg2+hQ83ph0HI6qQmCaU2dT3Qar0Ss6GLyoGlVDoVCfD6yvSirT?= =?us-ascii?Q?bmGiyiwyq9DOLvgwB0+PH30uKBAV0m5zkaExx+hNaLbRorqJj8+JwUZJmDI8?= =?us-ascii?Q?ZUAXFTYPW2QaLlyc/eCHQ6qdr528BaUDx8vh9xrmMfrCGLXSW155n7c+pSZc?= =?us-ascii?Q?31ScXiDWarOlCdP5zc61Z2xBdQTgL/0A1AUcHaGG7ZY/FhUBYX+/cDVco6eE?= =?us-ascii?Q?L8iFVtZhI2RTSa6gJb3Rw1UdlDaQ1twO1Rig9GKpSlDhVPSxqvx7md5To28j?= =?us-ascii?Q?8dk++QYZYES2znww3s8YD5ENw5fH8lt/JNAqlsi90kOM+06cXH5uMTV6AHsO?= =?us-ascii?Q?ujGc/iu7kAhzUVjzLKfj1Fv7KijlOdac412/ui6dXRMZR7nmXNJcCpd2gqWy?= =?us-ascii?Q?SmmOj9HWjOTSMGUnKUQw/zF6/acUpCPG+a7xoxLx1hhFHhPcKt3GNqc/itDG?= =?us-ascii?Q?E+o9ErKqlXqlI0R97UOQqp9arcuYkt+yZpBHT0DoNnJuwrY8zrGIuLJVu4gg?= =?us-ascii?Q?/PtI+x3lG4IqKZatpEP3WXX5d4JY6xmFESgHcWRKn3WF0m1iaM/vuGNHQfHU?= =?us-ascii?Q?iIwYxT8Y8EOm+8C95yrAgs7XgyYjSfo1S6y6bdFo5abR80SDi4/Ga5vdVZCv?= =?us-ascii?Q?c/T/m1IeUCDiUUgwkw/nyGfFUmrOnyO2r7rSpDEXr4pFU3nvBM4i9Uacr64u?= =?us-ascii?Q?/MunMGr7HqUHcIEsdMC7uvGAyL10b08HArSDLQtv6BlV47ZlpNkG20Q=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2006; 6:JGOukzScC9B81wCH7+EHgKdHhkXJsSo6r0gF6EojPHONN6d4+0eIOzCABOdIfAURN0KRfUwe9SkA62dv0+41LSDLjMjSj0wCOS4dyNk569GOS4MMiC+44pNGvET5eIhKdfX5+pTupegSfOYo/oZUFQTmhW1Xy685Hb9GFX8TMHY5evgQ4/o6IzYqYzhKpGZOifqCEOhYgV4jdkp1ZdpYIZ43ago+hAQnHnsuP85MopWcd+dKSY6Z3TT6vA3HCwl8Z1miOKZpHIVR6esqfB2Kc4jpHLPdbc+deUM5WFwrLdMSu8seRx7pqepsqdIAmIpzhrxXFD636PrXO15jkiK2qVqLMOeALOSFYmFWQalexKUWPnr0VRu4p+g9LD12XUzKVPs/iJ/omfSc9fUhfcdVfUSaXeUgRimB4XGDLLo5ufU=; 5:zh+rD3YnRvt9n/O+b7jsfLUNqfO76iBAcuX3BYrHuRlTUjeoKlsUHb8fD85slpOBkFL63qRDo4+dRd10pfd16k/S5vNrY/sejJG3gCn81w+9gHNUeCwQw4MtWSLS1ki1oOUheXKI4vOfDencxbp+3w==; 24:N6Tf3edxgPHHaw96NDr2XLqAGdp6NeY0zucNmAtfOctfx+yT18WRh4mb2yxjzjw1loSsHl0Fi74+c/YTo7vrvqrhGvpmtSRT+UxQMiB7+Lo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2006; 7:xKMT7hAnEHkOuMBp+Y/RgzVv0U9rjqNjxXyrP8DQmwtbBE9oleneRTKaU+8R5B3aDIHyB1bsoEeI/c3TMbo6e+S4Lf0+F8Dzco1+vq4c/9jY6sf3NA4hlxwV5WWANFxZTttNG0t3ig3xVSKLQgaR6qFZCCmHFNAoBVCNr1r9z6htrxZWMpJtIEEBA7JCX3zhWKPy67Xu+/Lpq+0w+HQZOcmRUXGGxH6ZByekUzCR+EyBXD3GwVVAt6lAaQ5qs9hPosI/Yyj2kcIiftN1Eik7IZbRY83OItLPtIFXkOl0rIPQLAVgp5PWhtCdPb4GF0QkZL1U6oUBmYHKII9OF5Ed4A== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2017 20:09:17.1362 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB2006 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] rfc 6087bis - stress importance of instance examples X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 20:09:22 -0000 +1. As someone who does internal code review for Juniper changes, having an example is a huge help to the reviewer (me). It also helps to convince the module author (them) that what they are advocating will look horrible. Thanks, Phil Juergen Schoenwaelder writes: >Hi, > >my experience is that when writing YANG modules it is tremendously >helpful to focus on the instance documents. I find it essential to >write down example snippets of instance documents to see whether they >look elegant or clumsy. This is often not easy to determine from just >reading a YANG model, in particular if groupings are involved. Examples >help so much - you can easily spot whether the usage of singular or >plural is reasonable in your names, whether you have redundancy in >your names, whether the overall organization is effective. Even better, >we have tools that can validate the examples so we can even be sure >the examples are correct. (And if you do not know whether you got >your pattern statement right, well, one way is to write examples.) > >I think we should encourage authors to write examples. It will help >them to create better models and it will help reviewers tremendously >while reviewing models. Good examples will also help users to get >started. > >/js (who apparently is doing some heavy YANG reviewing work today) > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Mar 3 13:08:34 2017 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 A4BD412951B for ; Fri, 3 Mar 2017 13:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 P2xp4aAUYnz9 for ; Fri, 3 Mar 2017 13:08:30 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 993581295DC for ; Fri, 3 Mar 2017 13:08:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 510E6240972; Fri, 3 Mar 2017 13:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1488575310; bh=N8ucojYB/ep0CbBNetqVlGDYlIqHsVDlsEHX8qLpONk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jkW64L4ewDSTu2b1x9VlEvWyeEZzo8ivQvdK2lbn/QSeXKhfcgIdSg1T0+QG+tduv 2m20Pfbvnhz2zvce2/FAcvICQiW9iLZOAQ2XqYRJTcEO8zI0BLAnYwtTKawinUEu7A rSfC8r2g/1SoKagd2FWV5xfb6NLdJS4mInMeK/6o= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id C1CDA2408D9; Fri, 3 Mar 2017 13:08:29 -0800 (PST) To: Phil Shafer , Juergen Schoenwaelder References: <201703032005.v23K5AAe059307@idle.juniper.net> From: "Joel M. Halpern" Message-ID: <64e6926d-d884-e3df-cb11-a13714297d8f@joelhalpern.com> Date: Fri, 3 Mar 2017 16:08:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <201703032005.v23K5AAe059307@idle.juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] rfc 6087bis - stress importance of instance examples X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 21:08:32 -0000 I would have to agree that examples are very useful. they are useful for comprehensibility even in cases the YANG structure may be unwieldly. For example, if the XML / JSON is expected to be generated (as well as consumed) by programmatic processes. Yours, Joel On 3/3/17 3:05 PM, Phil Shafer wrote: > +1. > > As someone who does internal code review for Juniper changes, having > an example is a huge help to the reviewer (me). It also helps to > convince the module author (them) that what they are advocating > will look horrible. > > Thanks, > Phil > > > > Juergen Schoenwaelder writes: >> Hi, >> >> my experience is that when writing YANG modules it is tremendously >> helpful to focus on the instance documents. I find it essential to >> write down example snippets of instance documents to see whether they >> look elegant or clumsy. This is often not easy to determine from just >> reading a YANG model, in particular if groupings are involved. Examples >> help so much - you can easily spot whether the usage of singular or >> plural is reasonable in your names, whether you have redundancy in >> your names, whether the overall organization is effective. Even better, >> we have tools that can validate the examples so we can even be sure >> the examples are correct. (And if you do not know whether you got >> your pattern statement right, well, one way is to write examples.) >> >> I think we should encourage authors to write examples. It will help >> them to create better models and it will help reviewers tremendously >> while reviewing models. Good examples will also help users to get >> started. >> >> /js (who apparently is doing some heavy YANG reviewing work today) >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Mar 3 15:57:01 2017 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 7F2A412968C; Fri, 3 Mar 2017 15:55:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532251.15846.14220791094727273806.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:22 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] netmod - Requested sessions have been scheduled for IETF 98 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:22 -0000 Dear Lou Berger, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. netmod Session 1 (1:00:00) Thursday, Afternoon Session III 1740-1840 Room Name: Zurich D size: 250 --------------------------------------------- netmod Session 2 (2:30:00) Tuesday, Morning Session I 0900-1130 Room Name: Zurich G size: 115 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: NETCONF Data Modeling Language Area Name: Operations and Management Area Session Requester: Lou Berger Number of Sessions: 2 Length of Session(s): 1 Hour, 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: netconf rtgwg Second Priority: i2rs anima isis ospf Third Priority: saag People who must be present: Lou Berger Benoit Claise Kent Watsen Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Sun Mar 5 12:16:28 2017 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 D1B02129502; Sun, 5 Mar 2017 12:16:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148874498685.26194.9627099752257391009.idtracker@ietfa.amsl.com> Date: Sun, 05 Mar 2017 12:16:26 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 20:16:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author : Andy Bierman Filename : draft-ietf-netmod-rfc6087bis-11.txt Pages : 67 Date : 2017-03-05 Abstract: This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG data model modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-11 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 Sun Mar 5 12:21:38 2017 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 47CBC1294C3; Sun, 5 Mar 2017 12:21:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148874529728.26254.1520304847418407842.idtracker@ietfa.amsl.com> Date: Sun, 05 Mar 2017 12:21:37 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-12.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 20:21:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author : Andy Bierman Filename : draft-ietf-netmod-rfc6087bis-12.txt Pages : 67 Date : 2017-03-05 Abstract: This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG data model modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-12 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 Sun Mar 5 12:23:39 2017 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 6AFE11294A2 for ; Sun, 5 Mar 2017 12:23:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rVQ4xni7h9c for ; Sun, 5 Mar 2017 12:23:36 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 2A2DC1294C3 for ; Sun, 5 Mar 2017 12:23:36 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id n11so49828235wma.1 for ; Sun, 05 Mar 2017 12:23:36 -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=lE5re5SGp1Rek0hxEfGvsoFaQLWTYKCN8p20dKCwiU8=; b=Q7kwRozptX5V/KK44XefSN9+WsfwQTsx47Ndg13I8qr+Iy0erpwDvV4Vmr02nHTatz yGEDf3JvRUdBJci5ll92Mo++vqWdHeCioWGxhwlZ71NS/l7nXakagYqQfSyJScqUf/bw QrV3g12an7wHGnH21qaZWpP7BMG6KO3a9xsFkD33Xb4UIEufEMkOnOVQ39vt2IHwFm/o 6D6wFUibundABwy3USSpO9cqbP2oDZqex6PTkAiqNMfBZA8XEyAZllOJayDA9po9KB0g yMu+8zcbHYnZRxzg56LjeKe5cwz7ZXeePUz9QYCcgcuevSdbWHi8QAaKVqeEBskcIO7y QCYg== 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=lE5re5SGp1Rek0hxEfGvsoFaQLWTYKCN8p20dKCwiU8=; b=HKIiwL58Yvhf/zgJh//GjN8rkG2GG4l/lcp7cdyzdH9Ipw1pX8UzZrg3bT3c1Fg560 TEeE1zAxXsQcPiE+zYL8nEBmbKGK5Ude/7KEvMBO9BWd5Bs/lPRLnv5ZWUZQ0Ns18VeD AUMwis+zCKmMG4TXSY9DVy0OacpOqY8LPZROMiQ0NsdvypCv9LTRXpAA87lYU2rJQmjX rqfXeJm/4SD40jkPsT5u/iEWnr1vsIQqrOGGxoQ6bRS3uKi+6h5UUV3uvzmLUVhfbZKq oypJdNMJFRTrCc5UBp2sclwlRtuhtu5R86qzx6wKKAkyLi+qox022jCmoc0WS2gQpXKb zvvg== X-Gm-Message-State: AMke39krvdEg78YfzNGFgW2UdqOCQabn/iEa+3j+FocAa6SJwCG97R2ZXmduzguegGAHga26Emrr5rKg723hvw== X-Received: by 10.28.46.213 with SMTP id u204mr8464725wmu.136.1488745414513; Sun, 05 Mar 2017 12:23:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Sun, 5 Mar 2017 12:23:33 -0800 (PST) From: Andy Bierman Date: Sun, 5 Mar 2017 12:23:33 -0800 Message-ID: To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11497ace97e5e5054a018d15 Archived-At: Subject: [netmod] 6087bis update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 20:23:37 -0000 --001a11497ace97e5e5054a018d15 Content-Type: text/plain; charset=UTF-8 Hi, draft-11 is not correct (sorry). draft-12 has the requested updates - update YANG tree syntax section - add new sub-section on usage examples Andy --001a11497ace97e5e5054a018d15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

draft-11 is not correct (sorry).
draft-12 has the requested updates
=C2=A0 - update YANG t= ree syntax section
=C2=A0 - add new sub-section on usage examples=


Andy

--001a11497ace97e5e5054a018d15-- From nobody Sun Mar 5 13:16:55 2017 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 81C4B1294DB for ; Sun, 5 Mar 2017 13:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 Hx1KcjylU21W for ; Sun, 5 Mar 2017 13:16:53 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0094.outbound.protection.outlook.com [104.47.34.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B8A129488 for ; Sun, 5 Mar 2017 13:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FDK7Nuo8JOOSAuiLzjpU3bXYsjfKdX0L5t3PlpM2/xo=; b=VBa1tcTnBL+NHlWzVIauGQ6DRfQcqjpl9/0bkpKgKgw3WSRQUqrh3JqvfMDTkuD4AreI/zEIKfTUL9LuFLDprUWJMFSFqTmk4ZZ914kHmSv+u1YogSzYdk1iEpvQiQGQM3Xzhc1VfUnx60tMc1IQGnROSXVq0bS5jp7rRURXM44= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Sun, 5 Mar 2017 21:16:51 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0961.008; Sun, 5 Mar 2017 21:16:51 +0000 From: Kent Watsen To: Andy Bierman , "netmod@ietf.org" Thread-Topic: [netmod] 6087bis update Thread-Index: AQHSle5hSa0JfhFDXEekQkaWOjcTt6GGa+0A Date: Sun, 5 Mar 2017 21:16:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:8RgD/Nmk4IuaawPyz85SjkBO+trBfBUjBs/L/4qMfsgz8/4AspSj0PcXsEYJU3C7R1fgv+REEL/wKcV8d/bKydd7bj5fRCBcITKgh34xx0yUu13RPl9CnKN1rrYsKVj6/VIvJ51FBNLZyEicF/bkw1B3G3fVX1KZOcJ9B3eCI1dIilN9tI8pX4uMbXBNwGKCVrgycQ1kxg2iCbNxERGoUkeIixttCqm34eR4rcKBPjjyBa+wAG1uVByPuckN4xvDm7w1KvYmCSmDDm60/pM3DdkbCQDkScGWPc9mX0ZHRtDLFczlw2q2ilc2nX8hZw4oa2d6mhcis4s+qtJdVNU0Uw== x-ms-office365-filtering-correlation-id: cb068b80-d435-4f3c-7457-08d4640cf166 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 02379661A3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39850400002)(39860400002)(39410400002)(4001350100001)(8936002)(77096006)(81166006)(229853002)(8676002)(6116002)(3846002)(122556002)(86362001)(15650500001)(66066001)(6506006)(102836003)(6486002)(99286003)(53936002)(6512007)(92566002)(25786008)(54896002)(189998001)(6246003)(6436002)(7110500001)(6306002)(38730400002)(3660700001)(54356999)(76176999)(106116001)(82746002)(50986999)(2906002)(36756003)(2950100002)(5660300001)(10710500007)(2501003)(33656002)(83716003)(3280700002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FE6CD9F5FA264B37AB0E8FB58CC86F27junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2017 21:16:51.7866 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] 6087bis update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 21:16:54 -0000 --_000_FE6CD9F5FA264B37AB0E8FB58CC86F27junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEFuZHkhDQoNCiAgLSB1cGRhdGUgWUFORyB0cmVlIHN5bnRheCBzZWN0aW9uDQoNCkkg d2Fzbid0IGV4cGVjdGluZyBmb3IgdGhlIHB5YW5nIC0tdHJlZS1oZWxwIG91dHB1dCB0byBiZSB1 c2VkIHZlcmJhdGltLCBidXQNCmFtIG9rYXkgd2l0aCBpdCBhbHNvLiAgSXQncyBqdXN0IGRpZmZl cmVudCB0aGVuIHRoZSBsb25nLWZvcm0gd2UndmUgYmVlbiB1c2luZw0KdG8gZGF0ZS4uLg0KDQog IC0gYWRkIG5ldyBzdWItc2VjdGlvbiBvbiB1c2FnZSBleGFtcGxlcw0KDQpOaWNlIGFkZGl0aW9u LCBidXQgc2hvdWxkIGl0IHNheSBzb21ldGhpbmcgYWJvdXQgSlNPTiwgaW4gYWRkaXRpb24gdG8g WE1MPw0KUGVyaGFwcyB0aGF0LCB1bmxlc3MgdGhlcmUgaXMgYSByZWFzb24gdG8gb25seSBwaWNr IG9uZSBlbmNvZGluZywgZXhhbXBsZXMNCnNob3VsZCBiZSBzcGxpdCBiZXR3ZWVuIHRoZSB0d28/ ICAtIGp1c3QgdGhyb3dpbmcgaXQgb3V0IHRoZXJlIHRvIHNlZSBpZiB0aGlzIGlzDQpzb21ldGhp bmcgd2UgbWlnaHQgd2FudCB0byByZWNvbW1lbmQuLi50aG91Z2h0cz8NCg0KS2VudCAvLyBjb250 cmlidXRvcg0KDQoNCg0K --_000_FE6CD9F5FA264B37AB0E8FB58CC86F27junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <5239BFF0CC97794892A6A9D5300F270D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmtzIEFuZHkhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAtIHVwZGF0ZSBZQU5HIHRyZWUgc3ludGF4IHNlY3Rpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSB3YXNuJ3QgZXhwZWN0aW5nIGZvciB0aGUgcHlhbmcgLS10cmVlLWhlbHAgb3V0cHV0IHRv IGJlIHVzZWQgdmVyYmF0aW0sIGJ1dA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hbSBva2F5IHdpdGggaXQgYWxzby4mbmJzcDsgSXQncyBqdXN0IGRpZmZlcmVudCB0aGVu IHRoZSBsb25nLWZvcm0gd2UndmUgYmVlbiB1c2luZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+dG8gZGF0ZS4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgLSBh ZGQgbmV3IHN1Yi1zZWN0aW9uIG9uIHVzYWdlIGV4YW1wbGVzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk5pY2UgYWRkaXRpb24sIGJ1dCBzaG91bGQgaXQgc2F5IHNvbWV0aGluZyBhYm91dCBKU09O LCBpbiBhZGRpdGlvbiB0byBYTUw/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QZXJoYXBzIHRoYXQsIHVubGVzcyB0aGVyZSBpcyBhIHJlYXNvbiB0byBvbmx5IHBpY2sgb25l IGVuY29kaW5nLCBleGFtcGxlcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5zaG91bGQgYmUgc3BsaXQgYmV0d2VlbiB0aGUgdHdvPyAmbmJzcDstIGp1c3QgdGhyb3dpbmcg aXQgb3V0IHRoZXJlIHRvIHNlZSBpZiB0aGlzIGlzPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ c29tZXRoaW5nIHdlIG1pZ2h0IHdhbnQgdG8gcmVjb21tZW5kLi4udGhvdWdodHM/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPktlbnQgLy8gY29udHJpYnV0b3I8L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FE6CD9F5FA264B37AB0E8FB58CC86F27junipernet_-- From nobody Sun Mar 5 17:06:59 2017 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 303A2129410 for ; Sun, 5 Mar 2017 17:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 wrO8WthgE1fv for ; Sun, 5 Mar 2017 17:06:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAFE5124281 for ; Sun, 5 Mar 2017 17:06:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DII75915; Mon, 06 Mar 2017 01:06:53 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 6 Mar 2017 01:06:52 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.77]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0301.000; Mon, 6 Mar 2017 09:05:19 +0800 From: wangzitao To: "netmod@ietf.org" Thread-Topic: NETMOD presentation slot requests for IETF98 Thread-Index: AdKWFbhdO94QCwy1STG0O9CR6IzzYw== Date: Mon, 6 Mar 2017 01:05:19 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.198] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2AD92037DGGEMM506MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58BCB62E.0004, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.77, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bc6e76dcf655da60349ea8f7bdbe6839 Archived-At: Subject: [netmod] NETMOD presentation slot requests for IETF98 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 01:06:59 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EA2AD92037DGGEMM506MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Netmod, It's that time again! The preliminary agenda for IETF 98 has been published; you can find it at h= ttps://datatracker.ietf.org/meeting/98/agenda.html. NETMOD will be meeting: 09:00 - 11:30 on Tuesday and 17:40 - 18:40 on Thurs= day. If you'd like a slot to present a draft, please send a request to Chairs an= d I. Kindly reminder, the deadline for draft submission is UTC 23:59 on March 13= st. Best Regards! -Michael --_000_E6BC9BBCBCACC246846FC685F9FF41EA2AD92037DGGEMM506MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear= Netmod,

 

It's= that time again!

The = preliminary agenda for IETF 98 has been published; you can find it at https://dat= atracker.ietf.org/meeting/98/agenda.html.

NETM= OD will be meeting: 09:00 - 11:30 on Tuesday and 17:40 - 18:40 on Thursday.=

 

If y= ou'd like a slot to present a draft, please send a request to Chairs and I.=

Kind= ly reminder, the deadline for draft submission is UTC 23:59 on March 13st.<= o:p>

 

Best= Regards!

 

-Mic= hael

 

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2AD92037DGGEMM506MBSchi_-- From nobody Mon Mar 6 03:13:53 2017 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 86A5012963E for ; Mon, 6 Mar 2017 03:13:50 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiPbOt6rgxJv for ; Mon, 6 Mar 2017 03:13:48 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EFF012963D for ; Mon, 6 Mar 2017 03:13:48 -0800 (PST) Received: from [10.137.2.13] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id C6E8124008B; Mon, 6 Mar 2017 12:13:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1488798824; bh=0xu5uR/YLjmgCwWDAVX2dzlWX4UZvm/ySYtBhrfhtvE=; h=Subject:To:References:From:Date:In-Reply-To; b=qweXoGyJJ/RERfmKj0SAvWciBKmDSqSCNJaCzLxU2an2ZZY6SAKeGyzvCStMy0DNb t9gKeUoWJfLzclgPrTJA5zDNPxZ6P/ZsNoaUsAuTQVFRcts6hXe7xuX049NAkl5sn6 CPIGY1jStNK7XyDuYnTLu+/s3EvPJE5u82bk6/z0= To: Kent Watsen , Juergen Schoenwaelder , "netmod@ietf.org" References: <20170303155322.GA3345@elstar.local> <4B5054DF-3B5C-4727-9245-7F0150821C8D@juniper.net> From: Robert Varga Message-ID: Date: Mon, 6 Mar 2017 12:13:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <4B5054DF-3B5C-4727-9245-7F0150821C8D@juniper.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="o8sw4kkgDpajiuBcDtPb3skRtVJaRuccR" Archived-At: Subject: Re: [netmod] yang canonical integer format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 11:13:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o8sw4kkgDpajiuBcDtPb3skRtVJaRuccR Content-Type: multipart/mixed; boundary="Lgk3LauKS4agSpcXPFEV7hU0N7tA2DHoH"; protected-headers="v1" From: Robert Varga To: Kent Watsen , Juergen Schoenwaelder , "netmod@ietf.org" Message-ID: Subject: Re: [netmod] yang canonical integer format References: <20170303155322.GA3345@elstar.local> <4B5054DF-3B5C-4727-9245-7F0150821C8D@juniper.net> In-Reply-To: <4B5054DF-3B5C-4727-9245-7F0150821C8D@juniper.net> --Lgk3LauKS4agSpcXPFEV7hU0N7tA2DHoH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, On 03/03/2017 05:52 PM, Kent Watsen wrote: >> typedef ether-type { >> type uint16 { format "%x"; } >> } >> >> in plain YANG to make the hexadecimal format the canonical format. Who= >> maintains ideas for the next YANG revision? This is also useful for other types, for example inet-types:mac-address, where implementations could use an 'canonical-pattern' type of declaratio= n. I think this particular idea ties the transport-specific representation to a type definition -- I mean requiring binary transports to send uint16s as text is not efficient and they would end up not using the statement at all. This is also sticky if the transport places additional restrictions on what is and is not a valid string and reminds me of some of the 'anyxml' problems... >> >> /js >=20 > Ideas for the next revision of YANG are being captured in this tracker:= >=20 > https://github.com/netmod-wg/yang-next/issues >=20 given YANG is an extensible language, would it make sense to deliver these outside of YANG revisions? The main reason for doing so is that these, unlike YANG revisions: - do not change the meta model of the language - are not mandatory-to-implement It will also allow for faster delivery to end users. Regards, Robert --Lgk3LauKS4agSpcXPFEV7hU0N7tA2DHoH-- --o8sw4kkgDpajiuBcDtPb3skRtVJaRuccR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIoBAEBCgASBQJYvURmCxxuaXRlQGhxLnNrAAoJECsDwSqgzwDTKRIP/2BYd1rW 3KJGsYLprFklkR6vpZkr4PH4TikETpGvPhDA8wluwJd4BjugKrBIegrUNh8ScotP g7aTyPX4j6RIWzFH0thk7wg0LYG7ycl+4LlbGJ5Yb3yx0rGRsXvX43gw844GvAzB tsODBJhZdTUH+SKOVWKMDWXQujUoWU+kTc7pcAVOGBbBfHxHJw+3CPLryyYrIcgF 0gtBmGQNxn5mCqDdv7wVvyR9vQJ+MfWIJ8DLdOeLdjhFZOlIsC8j4wQRO3scUxgR /FLNeyu4/NWQn/ke+3sjcS00O9VQURspxf+PDX0DkIXcYfZfcEKyzXyZNHGVSn/8 iV5FMU3Eqg6OOzo6DBfTETnwN+njQGaS2TWIro50yBqoa4k+fWq+Ezv0ZsNg/Njr hunQ9l6NjOLMs/Fmq19XZSGO34IH66nE8GvavBd2npyHFUo7nV9pF9INaYnurCqP JNQTzFAKsWLCh7WwhPb8cpe++iZRU9k2lXFRggatjwhI3YRDO5VBIKLKCe8I62ab DRshI1wRQfFIbx4OPMZXGBJratjW7jV/fZqL1XdP3pjMOqCdtQ6yfBR3jb1r6Ot5 k+GzbWlpVXbl8CKKz6rhCVvJ+zcUBO7rSRbXyPdnOJ/3w1TV0NtIS+VGCbXUnWup DeOF5sbmHMSl/nJ3XnAXYXxyPuqm33ctKCM9 =l1lf -----END PGP SIGNATURE----- --o8sw4kkgDpajiuBcDtPb3skRtVJaRuccR-- From nobody Mon Mar 6 04:28:25 2017 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 E3D37129666 for ; Mon, 6 Mar 2017 04:28:23 -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 AJPZdujXP_wa for ; Mon, 6 Mar 2017 04:28:22 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 00F34129663 for ; Mon, 6 Mar 2017 04:28:21 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8280E1820044; Mon, 6 Mar 2017 13:29:04 +0100 (CET) From: Ladislav Lhotka To: Robert Varga , Kent Watsen , Juergen Schoenwaelder , "netmod\@ietf.org" In-Reply-To: References: <20170303155322.GA3345@elstar.local> <4B5054DF-3B5C-4727-9245-7F0150821C8D@juniper.net> Date: Mon, 06 Mar 2017 13:28:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] yang canonical integer format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 12:28:24 -0000 Robert Varga writes: > Hello, > > On 03/03/2017 05:52 PM, Kent Watsen wrote: >>> typedef ether-type { >>> type uint16 { format "%x"; } >>> } >>> >>> in plain YANG to make the hexadecimal format the canonical format. Who >>> maintains ideas for the next YANG revision? > > This is also useful for other types, for example inet-types:mac-address, > where implementations could use an 'canonical-pattern' type of > declaration. Perhaps even more common use case would be IP addresses - an IPv4 address is basically a uint32 represented as a dotted quad. > > I think this particular idea ties the transport-specific representation > to a type definition -- I mean requiring binary transports to send > uint16s as text is not efficient and they would end up not using the > statement at all. This is also sticky if the transport places additional > restrictions on what is and is not a valid string and reminds me of some > of the 'anyxml' problems... DSDL has "extensible datatypes" [1] that try to approach this problem from the other end: a type may provide a recipe (regular expression + XPath transformation) for parsing a string into the "internal" value. BTW, DSDL seems to be dead as dodo, even the dsdl.org domain now advertises some Danish online gambling. :-) This is sort of pity, they had quite a few interesting ideas. Lada [1] http://conferences.idealliance.org/extreme/html/2006/Tennison01/EML2006Tennison01.html > >>> >>> /js >> >> Ideas for the next revision of YANG are being captured in this tracker: >> >> https://github.com/netmod-wg/yang-next/issues >> > > given YANG is an extensible language, would it make sense to deliver > these outside of YANG revisions? > > The main reason for doing so is that these, unlike YANG revisions: > - do not change the meta model of the language > - are not mandatory-to-implement > > It will also allow for faster delivery to end users. > > Regards, > Robert > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Mar 6 04:36:55 2017 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 EEFA3129672; Mon, 6 Mar 2017 04:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 AzKJfVXFkCUq; Mon, 6 Mar 2017 04:36:48 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0122.outbound.protection.outlook.com [104.47.0.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D00129673; Mon, 6 Mar 2017 04:36:47 -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; bh=wELxszGJu/sv72Fp8gqfws5orqgcTvXmHhMqzpQSA64=; b=cG0kCbH7W+upCcnHhySpLR+VmpF/SYnb8KG0x7MkinIBXPa932KRgkb3kHCfk0uPz4bUruivZwtatR1ObBhoP66MhiVs3jdYCDs928Q3sKUoxyYd7mRv5VsALqoBh+U3a+y2+GsGyhLpEP5ht0x9yIiyWoZf1GJpNDFEGUoTI7U= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.203.75) by VI1PR0701MB3006.eurprd07.prod.outlook.com (10.173.72.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Mon, 6 Mar 2017 12:36:43 +0000 Message-ID: <020901d29676$244e8a40$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Ladislav Lhotka References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> <20170301094629.GA75542@elstar.local> <05eb01d2927b$a75d2da0$4001a8c0@gateway.2wire.net> <63B6599B-5295-4D88-AFA0-1A24890CF7C5@nic.cz> <94364DAA-43B4-464C-B824-B46CF1BE499C@juniper.net> Date: Mon, 6 Mar 2017 12:34:58 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.203.75] X-ClientProxiedBy: HE1PR0701CA0053.eurprd07.prod.outlook.com (10.168.191.21) To VI1PR0701MB3006.eurprd07.prod.outlook.com (10.173.72.148) X-MS-Office365-Filtering-Correlation-Id: a3ace7ab-a753-484b-25d1-08d4648d725f X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 3:v4sPVyaZ8N227+/+Qi5OtNpriDtFqwl1WjvyivStvZ81w3fPpqrmXdS9Dw5HZ15kRRetMoMCyJjxHRAbJb//CcGnTDdBz9O1elfYh6gdsguCYZxRE22nEXLgItmmjnnV9ghZvl2etvb+7st0NI9DT/Nb04XEcoiDU8eY4BO/RfaDNE914sBwxjPX1j7Qlc0QWcsDbHg4YI+S2cBlSqK/pSVjxAQHQS53cduBUBxPIY2QNPfCFedhlobr5tUFGKnFK5e/hjStMIXpDSF4kunqCA==; 25:ERkfyKpW/WbTQ35aqY8j+8gaaD0F0zUYKkNhFqSG7qWh7lfMsKUgd7UEQRrFEu1kkjlPToN6KlU+CYauG/gNEsUI67rGz7prk1o4RNo7YRqsjZH3eKIOIAetK/CLwZy2uHd7XUwmAldX595Y7YRfKEX+y7ps7krOvVEy5Wa8hWQSZmD5bidT60t99IzDs3Sx7ZclkLJBYFFvViuO6SJFyIC85QTXxdqOLFoGAZ+ffDA+DrU+wiC27jRLZqVezAH66kdJjnIJCDkU75peFYw3/PgBbOCzdaxqFqJlOQ8MJpqfpr9rf4P9BPCod9mfgtQDLCCNEkBZPPohFZnpEIC+5aE0HA3jtoo/wOYfUmeM7OWjekzCGj7Lh9L9DA6BSkJ/sNvh+rgWkMljuVUmiR7OPCe445AOvQK4l3B0jIHnyrFIUWfslktObO95y8FVwbIoOplFSRRp+QhjX11yopuvaw== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 31:e2dxdDBDiiHPN6p1+uj66U3nzYR6V0YmEduPBh5W+JpRvNc9r8mvAruQCN9Te6mDwQlsHg6G/6T4lJUQYaly716cP/BJCKEDUZMZzMJhBvB6AfAi07K3oJgazx7A5TlzY9cRPF3bYtXljwS0s38q7+8BED8eJiOZMOjqPTbSeE74oX933V6SqEJtPQXBemxQtDTMJd17X104y0dx/FrW6yieWLZUK3E8SdRy0uiwSqhyasARChxgaJVTLcqOHuxfkM8Bym2qSlbSmqFXBIpXUA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(166708455590820)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:VI1PR0701MB3006; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 4:3qCVfwlB7wgl22IRhv/499i603FeaniKxNmikRvwNZdpPkLcpF3ROlvFX90vBfbzhj4Y4UhdEomVhqq++g4uU9OgX000S/GMeJWxB+Mad59+bUw3oTTjqCEr4ZZokVsjGhSMEa8XVWvLVsq+fhDEXN2N48eX/3HBeA1gmjbcFGuk/BllVXATdlV61yPr7SZmpkiW9W3mR9uOzWpbMltn9gK+yUumzF377qVT4NE3UZpCmaalPuBUVUebyjxFL3lzdHQeoQw9/nDkfYJdzIoUtsGniWEi9VsDi/UG5JpYJZJ12FsJsjWLtgZ3Vc+j5WFV76k0hUj+/SAdXim5ISdvDIywpu3J4yM43rb8rhmeUeLwQ4lAIGWhyYBaoSArVFALeEhE4vMr72M2FXLU9J3xMKlq1DEZj4vZNMaB+ODlpx6oLxXAZE9vHEUy/DYMFobi5kiBQ9iQTpzZstRKNoGacel1QsHj0ZHSwd0TK4GcGdVlAF13ebwbB2rs1TX8K9T2ezGDc3QXtDgrok3cCPiwHIjacCSB1zrB+nnfFD/VFZP5qXnMw2/5OtOf3YbU8bEw8yjnTFazapVLRAGPezAQm7rxL9k1oAHoLoXSae5JzxM0uKWulcNGUxMymMP2IkwZ2L8x5rD8dJELqWh5Hu0468ox4uzdKpVVI/HJZTAPHCmhDJN+itC2yWqhzIFvwgilKuWZ5BdvcO495MjBJyq7uUQ2kQz4DdKtn+6unRFHqS4= X-Forefront-PRVS: 0238AEEDB0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(51444003)(377454003)(13464003)(50986999)(23676002)(81686999)(76176999)(97736004)(86362001)(93886004)(61296003)(50466002)(305945005)(7736002)(6116002)(116806002)(3846002)(15650500001)(1456003)(14496001)(33646002)(92566002)(561944003)(84392002)(38730400002)(6246003)(50226002)(2870700001)(42186005)(5820100001)(189998001)(81816999)(2906002)(4720700003)(229853002)(6496005)(44736005)(1941001)(54906002)(1556002)(8666007)(47776003)(25786008)(9686003)(6306002)(66066001)(4326008)(8676002)(44716002)(53936002)(62236002)(6666003)(5660300001)(6486002)(81166006)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3006; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3MDFNQjMwMDY7MjM6NXhOek1jK3pPM0FsWUpwTjgyV1AxTER6?= =?utf-8?B?USt3R29BbjNGVlZJTDBvMVl3UzJVKzhhd3FKOU5OR2FnVFBMemYwdlB5Q2lB?= =?utf-8?B?U1Y1Y3NhYkp1SERFMDNMZ3RlblNYV1Y2ZS94ZEp3OHo3eElsam5hYlFDempi?= =?utf-8?B?aDhyTDZ6dnZ1TTRyOTM2dXIvcnBLamNENE1ucGt2Q2Y3YnE3U1VzRnhxcU12?= =?utf-8?B?elprUkFnZnRKemprUEhEdG54ajN5THlHdGtkd1V6ZHpTek4xbWxJU1p6UEVh?= =?utf-8?B?eVRPakNUbytOd3RWelk0MXpiQUFZTlIrekRwbkVaczMxM25zNE5QNURlUVQ1?= =?utf-8?B?RWVLTkdwYW91clpranFrSHJCK0FkTUd5TnZTVWNkdzBibFBDZ1haQy9yZVQz?= =?utf-8?B?WW1MaVFvTWhiNGhJU1FDVXloUUxhanZ6NUJpVUxEV3BRL09xYjBxMDVmMHdq?= =?utf-8?B?Vm9VZEsvdTg0ejduWWF0Z3FyKzg2TFYzQkVzNVh0Q1hDd1dqUEwvSmI4MTNR?= =?utf-8?B?UDdBdUFNYlNYS1ZHUEV6N0J6UWlDVkdCYkNrTzhaS1hRSlZXT0xha3oyM2ZY?= =?utf-8?B?eUJRQUpMTkVaQXlsN3IxV25nKzllazdVZ2EyUW9QU2NKMDlvS25BNTlKQzZW?= =?utf-8?B?VHh2bjVQTTBRbnF0MWlMeCtZb2FUMDFZNmhlbXAwOGdYNTQ5S1ZtdGdtTTZi?= =?utf-8?B?MU0yVmozZjYxU0xMQ2lzck1kK0dLYkhDUGo3MTZnYm1RUVFhcXJBWFlIV1d6?= =?utf-8?B?cG9OVkJZQU5iVTlkUFYxNm8yb1g4b1F1YkVZZnoyeklqUkJxY1htL3NYc21S?= =?utf-8?B?K2JxRThDaUhFaUJwRXBhYzJKSXlnSHozaUxBVDBNeVJlSXNyZ1B0dTB1T0Vz?= =?utf-8?B?RHhOdys4Q3BBQUl3WU9rN3ZycHhhSVJtSm5aT0p0M1FBcncyNXBlcXZYM0dj?= =?utf-8?B?ZTI5RWZ2aTlIMUV6dEpTcnU2SERPeXVHM3Y5eEViOHJjNzVnWWphVjhNZG8x?= =?utf-8?B?dzl5b3lEUGNpM2F4V1ZxWXdCckh3UWFCSWlxdDBiRno1WUFCcXR1aWluSy9J?= =?utf-8?B?S01vMVZnNkVnQkdjeEJzVmxqR3ZFVU9tU2o4cWRYM0NHdENwd0g4L3VSQmhF?= =?utf-8?B?ZTdJamJCQ2tXQkIvQ0x5SUlXS1VubmR1MlIxaVpmYlVxYWVTMGRpNWh3Sk5V?= =?utf-8?B?UnRxZER0L0QyMGVZWmNqU0VVdlc3RVNyem5xUGFsd016RktybWNmdGtqcVpC?= =?utf-8?B?QnVFRlpnY3BHejFQR09PQ3g1STNraWJuZENpU3FnbTBuUFZtZWZNS2hPNGZL?= =?utf-8?B?ZzFNWkptNlByTXgzQmlYVlFqTnk2NTRSWmN0bGd2Yi9kTjVFaU5PbGdhQ0M3?= =?utf-8?B?Z3pGQXdQQVVSSW5YaHhsZHV3ejlLU1BCdC9wMW9zUTdkblljeVNIYmx5RVgx?= =?utf-8?B?Q25JaERxTGxZWkRmWU1DUGFkcjdQMDNla0JzdkM2NHJobVVvQy9URWJiWHJ5?= =?utf-8?B?MDBmN0ovMHhSMndveS8zdE9hd0ozbEw3Mmw4MlM1anlYV3o2dzFCQ2I0YTFw?= =?utf-8?B?QVJ5RWVyczE1VjZ0ZW1vcThUMzBzNzhNZXRXaVZldm9vZGxNNjY1OW9laUVD?= =?utf-8?B?cEF4UU5Jajk5bnlaOHhoNS9CWGVBQ21pcS9mVnJ4MnF4UzRaeEJaclBFcU5F?= =?utf-8?B?QTBlRWRhK01uODFKMkFkaWdJa3M3THJ5eXEyTVJVazNOMW8rREJ5KzN2c0d2?= =?utf-8?B?NUpRSXFOQnpuak43bVpDSXFteVFTSW1lYjFrbExKVklaMkl5b0xjOUUrTWVp?= =?utf-8?B?OHhMM2x2TDh4Z04yTmtGWVI4d2tLT2JzeFFnN1FlZ05IcWdXbHYwVDU3b3ll?= =?utf-8?B?MTl2ZFh0ZkY3TUFxeDJxTEsyQ2dMZUtoSXZ0SnZIdmFYY2RGWjIzV1NjS1Rm?= =?utf-8?Q?vzV3W+DVwFHPE/N0jWC6UR0OIy608nDY=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 6:1rqrL8UxZWAlFKnEzqqXQVxn9oQf2Qct6aVGPm2ou/ylVLrHnpWVEkbRZw7l0fQE/ux7QIkua76twOC1qFJB9s2qorqaIbLkXyH1P0rNYkVepyzysqnGQ9eO9yym4PZcBV0Sam65ucdzCze9TVTQRaBAkaBsNyxzZT42WF7iqAuD7jIRywsad/R6Aux0ShV8JGtdCjrQoKbMPA+yrezV1TAlMRVI7L9JgrVcvFv3BLh+vd9hmjV+VSfGxpqjB6enzBv+GDD6BtH1Vcp8R0gxfkaONtQw998cQygwYFZUKt39KKgh0Ctbx0SkMsd6Am8m7ltc/RlpfEkqEQXYQb/9Di7Y9oA18ikQ3uEsL8uBrmeXyOe1MA8hNX4W9bOkLmPkI0lWQPA3Jd0fHfxbeUbYzA==; 5:rdNYlQ5nkscrtwRom356JxRuAYoTvKmJ/+M6zgM9y44KlEVb8A1Oap9/anua19QhNq6OfzJdPHQKE7Sr7u8A439bTcnqPEW7stLpaBaTT3ACFLsNpiHUcbCheka8wLshI5jwddiNnLw2O8btVUZB7g==; 24:Ckc6U4f3CAZ7/RWlsMzqnZvWA3cwUX5JSHaVXQbmqpfSSl0OIoZciq8PbVlNufX4vUA1SA8d0IkLRkpYiuLW4vthuNOSpS4GkfHOvAm2jLY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 7:TTctERYCciYj7XZzKlnn3dC5uMIHyWOf982y4Zo6ZG1SefUXhI+9hlsHK+/6CJVyFJbLpUW4rVQWXuUPvI0M6HSzHIYQhrG0NPKtom2jHNvysn4Iy8jWp9jxH21iDxMPFvNSr6SOXrJcoeN5JLNC6PH2xJy+cVg0KhJI8hekc59H9vp8SVTtXViBDuqgRqgrGC8U32bs18wwkunT1NKV/XBzp6khmSfNt2h4YqyrC5gWEkZfqLDgxiPF1PK0tFhm1vqKwO5gr7jOr0yEM/rzXMrgokVEP1CDPXkaKR0YI1/lmB8w9u1BhWi7cCkytDK29ICPes9qB81M/vtJC8HFyg== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2017 12:36:43.0080 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3006 Archived-At: Cc: NetMod WG Chairs , netmod@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 12:36:54 -0000 The NETCONF list has also been discussing a charter update, as some of you will know, and part of that consists of taking into a NETCONF I-D parts of RFC7950. I see a joint agreement as to just which bits of RFC7950 will be elided as the starting point for this (followed by a revision of RFC7950). I am reminded that in the latter days of 6020bis the point was made that the terminology therein was inconsistent, sometimes using NETCONF XML and sometimes XML (an inconsistency which has been carried across to RFC7950). I see the references to NETCONF XML as something of an oxymoron, a bit like saying 'HTTP jpeg' or 'railroad cow'; they are different beasts. So I would /NETCONF XML/XML/ * * Having done that, I think that the XML should stay in 7950bis; it is like having a worked example (which is how many people learn languages:-) and would be clearer to those steeped in XML than the YANG is. Also, removing it generates problems for NETCONF, that the NETCONF I-D would then have to include XML, YANG, some explanation thereof, references therefrom and so on. The clean boundary is to keep the XML in 7950bis and have a NETCONF I-D just describe how that XML is then wrapped up in a transporting protocol, ditto for any other protocol although were it not to use XML, then it would also have to define the use of whatever it is using.. The sections such as 5.6.4. Announcing Conformance Information in NETCONF 7.5.8. NETCONF Operations go but I think that 7950bis still needs to talk about conceptual operations, such as create/delete/update/; else how can you discuss ordered-by user? YANG is not a DDL that describes a static, unchanging set of data but rather one that expects data to be updated so such operations are a part of the language. Likewise on errors, that 7950bis should still talk about the errors in generic terms, a consequence of talking about operations, but should leave the encoding to a transporting protocol. Section 8 is an interesting one. YANG defines itself as a language for defining RPC so something needs to be said about RPC but will operations always be performed by RPC? Well, not necessarily! 7950bis would still need urn ...netconf . Tom Petch ----- Original Message ----- From: "Kent Watsen" To: "Ladislav Lhotka" ; "t.petch" Cc: "Jürgen Schönwälder" ; "NetMod WG Chairs" ; Sent: Wednesday, March 01, 2017 4:56 PM Subject: Re: [netmod] draft netmod charter update proposal > Hi Lada, > > I understand your intention here, but I'm inclined to agree with others > that it's better to stick with the term we're using in the documents. > I'm open to the idea of changing the term used in our RFCs, and I believe > that such a change would likely have to begin with the YANG spec, from > which it could flow into other drafts. With this in mind, I've added an > item to the yang-next tracker: > > https://github.com/netmod-wg/yang-next/issues/17 > > and I plan to revert this change in the charter text. > > Thanks, > Kent > > > From nobody Mon Mar 6 06:01:45 2017 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 D28AA1296F3; Mon, 6 Mar 2017 06:01:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148880890385.15031.16710718938952733145.idtracker@ietfa.amsl.com> Date: Mon, 06 Mar 2017 06:01:43 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-schema-mount-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 14:01:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : YANG Schema Mount Authors : Martin Bjorklund Ladislav Lhotka Filename : draft-ietf-netmod-schema-mount-04.txt Pages : 32 Date : 2017-03-06 Abstract: This document defines a mechanism to combine YANG modules into the schema defined in other YANG modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-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 Mon Mar 6 06:35:24 2017 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 C08ED129632; Mon, 6 Mar 2017 06:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.021 X-Spam-Level: X-Spam-Status: No, score=-7.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 6JKTgEAYpa2R; Mon, 6 Mar 2017 06:35:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5861294A8; Mon, 6 Mar 2017 06:35:20 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:9dcf:3800:343d:42b0] (unknown [IPv6:2001:718:1a02:1:9dcf:3800:343d:42b0]) by mail.nic.cz (Postfix) with ESMTPSA id 97679607D6; Mon, 6 Mar 2017 15:35:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1488810918; bh=PkAaWzmh+R/sf+F6bLZbDDYsfcIrRLnIA6te40wD0yY=; h=From:Date:To; b=CiIeRTG2t80ntLCRC/HjlTjfjIar1pHxbGdd4yDs5CtRFjZp67tGBKksPQu8ndjS0 6VqFmjVUN36YCnFrrF5msFuBEQugjDSX3ezX2zIciiH4+CZ1dNJWOByoX9sCkmux28 04spooVWn7ABZBNFiMlAyHr4zitZu+Q/XvhMHnWE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <020901d29676$244e8a40$4001a8c0@gateway.2wire.net> Date: Mon, 6 Mar 2017 15:35:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2F9613F7-98FE-45AF-8BA4-F7404CF5CE8B@nic.cz> References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> <20170301094629.GA75542@elstar.local> <05eb01d2927b$a75d2da0$4001a8c0@gateway.2wire.net> <63B6599B-5295-4D88-AFA0-1A24890CF7C5@nic.cz> <94364DAA-43B4-464C-B824-B46CF1BE499C@juniper.net> <020901d29676$244e8a40$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG Chairs , netmod@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 14:35:23 -0000 > On 6 Mar 2017, at 13:34, t.petch wrote: >=20 > The NETCONF list has also been discussing a charter update, as some of > you will know, and part of that consists of taking into a NETCONF I-D > parts of RFC7950. >=20 > I see a joint agreement as to just which bits of RFC7950 will be = elided > as the starting point for this (followed by a revision of RFC7950). >=20 > I am reminded that in the latter days of 6020bis the point was made = that > the terminology therein was inconsistent, sometimes using NETCONF XML > and sometimes XML (an inconsistency which has been carried across to > RFC7950). I see the references to NETCONF XML as something of an > oxymoron, a bit like saying 'HTTP jpeg' or 'railroad cow'; they are > different beasts. So I would > /NETCONF XML/XML/ * * >=20 > Having done that, I think that the XML should stay in 7950bis; it is > like having a worked example (which is how many people learn > languages:-) and would be clearer to those steeped in XML than the = YANG Of course, examples of instance data are important but in most cases = JSON would be significantly easier to read. 7950bis could also contain = examples in both XML and JSON (as RFC 8040 does). > is. Also, removing it generates problems for NETCONF, that the = NETCONF > I-D would then have to include XML, YANG, some explanation thereof, > references therefrom and so on. The clean boundary is to keep the XML > in 7950bis and have a NETCONF I-D just describe how that XML is then > wrapped up in a transporting protocol, ditto for any other protocol > although were it not to use XML, then it would also have to define the > use of whatever it is using.. 7950bis should include a much more explicit definition of the conceptual = data tree, and specifications for particular encodings of the data tree = can be in separate documents. All these documents can IMO stay in NETMOD = because they are protocol independent. Each protocol would then choose = to support one or more of the encodings. >=20 > The sections such as >=20 > 5.6.4. Announcing Conformance Information in NETCONF >=20 Yes, but I think we need a *data modelling* formalism for specifying a = bundle of YANG modules (including schema mount). YANG has currently = almost no support for this, so tools often use hello or yang-library = data for this purpose. So I would like to have some standard metadata = like this, detached from protocols and devices. > 7.5.8. NETCONF Operations >=20 > go but I think that 7950bis still needs to talk about > conceptual operations, such as create/delete/update/; else how can you > discuss ordered-by user? YANG is not a DDL that describes a static, It simply means that the order of entries carries some semantics. In = fact, such a property might also be useful in state data. That said, some background context of CRUD and other operations can of = course remain. > unchanging set of data but rather one that expects data to be updated = so > such > operations are a part of the language. As a matter of fact, almost all formal rules in YANG are about static = data. Apart from "ordered-by", probably the only other exception is = "config true/false", which could be generalized to the "RW/RO" property.=20= >=20 > Likewise on errors, that 7950bis should still talk about the errors in > generic terms, a consequence of talking about operations, but should > leave the encoding to a transporting protocol. Yes, 7950bis can define appropriate error-app-tags. =20 >=20 > Section 8 is an interesting one. YANG defines itself as a language = for > defining RPC so something needs to be said about RPC but will = operations > always be performed by RPC? Well, not necessarily! The concept of operations/RPCs/actions and their signatures is = sufficiently general, it should IMO stay in some form. Lada >=20 > 7950bis would still need > urn ...netconf > . > Tom Petch >=20 > ----- Original Message ----- > From: "Kent Watsen" > To: "Ladislav Lhotka" ; "t.petch" > Cc: "J=C3=BCrgen Sch=C3=B6nw=C3=A4lder" = ; "NetMod > WG Chairs" ; > Sent: Wednesday, March 01, 2017 4:56 PM > Subject: Re: [netmod] draft netmod charter update proposal >=20 >=20 >> Hi Lada, >>=20 >> I understand your intention here, but I'm inclined to agree with > others >> that it's better to stick with the term we're using in the documents. >> I'm open to the idea of changing the term used in our RFCs, and I > believe >> that such a change would likely have to begin with the YANG spec, = from >> which it could flow into other drafts. With this in mind, I've added > an >> item to the yang-next tracker: >>=20 >> https://github.com/netmod-wg/yang-next/issues/17 >>=20 >> and I plan to revert this change in the charter text. >>=20 >> Thanks, >> Kent >>=20 >>=20 >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Mar 6 08:44:59 2017 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 D4BD7129464 for ; Mon, 6 Mar 2017 08:44:56 -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 5aFrlNiTa9BP for ; Mon, 6 Mar 2017 08:44:55 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B2312945A for ; Mon, 6 Mar 2017 08:44:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 697131E5664; Mon, 6 Mar 2017 08:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9IsWMenyczV9; Mon, 6 Mar 2017 08:44:17 -0800 (PST) Received: from [192.168.1.127] (host81-132-49-127.range81-132.btcentralplus.com [81.132.49.127]) by c8a.amsl.com (Postfix) with ESMTPSA id 6B5011E565B; Mon, 6 Mar 2017 08:44:16 -0800 (PST) From: William Lupton Content-Type: multipart/alternative; boundary="Apple-Mail=_80CB0879-CF53-43F6-8DAB-1B0E70FE497F" Message-Id: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Mon, 6 Mar 2017 16:44:52 +0000 To: netmod@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [netmod] yanglint and implemented versus imported YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:44:57 -0000 --Apple-Mail=_80CB0879-CF53-43F6-8DAB-1B0E70FE497F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, This message arose from a yang-multicast@ietf.org = =E2=80=9Cdraft-ietf-pim-igmp-mld-yang-02.= txt: YANG compilation isuse=E2=80=9D (sic) thread = initiated by Benoit. I thought it would be useful for NETMOD to see the part of the = discussion that relates to implemented versus imported YANG modules. Benoit Claise reported this warning: warn: Schema node "ietf-ip:ipv4" not found = (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:nam= e =3D current()]/ietf-ip:ipv4) Radek Krej=C4=8D=C3=AD replied: These warnings are printed because in yanglint, until explicitly stated, = the imported modules (such as ietf-interfaces and ietf-ip), are supposed = to be only imported, not implemented. The data nodes in imported schemas = are not available, which is the reason of these warnings. William Lupton (that=E2=80=99s me!) asked / commented: Why are the complaints only about ip:ipv4 (etc) and not about = if:interfaces (etc), which are also referenced in the must statements? This makes it hard for an automated tool (such as Benoit=E2=80=99s) = because it needs to know which other YANG files to process in addition = to the =E2=80=9Cfile of interest=E2=80=9D. Radek Krej=C4=8D=C3=AD replied: According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?], when an = implemented module augments another module (ietf-interfaces), the = augmented module MUST be also implemented. So libyang automatically = changes the augmented module from imported to the implemented. The same = rule applies also in case of referring a module in path (leafref) and by = deviating a module. But it does not apply when a module data is used in = must or when conditions. That's the reason why it complains just about = ietf-ip and not about ietf-interfaces. YANG actually does not provide a way to specify that a particular import = is also expected to be implemented. Therefore, libyang needs some help = with setting modules implemented - all the explicitly loaded modules are = supposed to be implemented, if the module is just implicitly loaded from = the search directory and user did not expressed that it is supposed to = be implemented, it is kept only imported to provide groupings or type = definitions Benoit Claise asked (referring to my reference to automated tools): Would it be possible to improve the warning (and the related test, by = testing implemented instead of import), basically telling that the = module itself is fine? I=E2=80=99m interested to know that NETMOD thinks about this distinction = between implemented versus imported (in the absence of any instance = documents). I guess my (maybe naive) view is that if all I=E2=80=99m = doing is checking for errors in my YANG model then I don=E2=80=99t care = about this. If my YANG is good I want to see no warnings or errors, and = if it=E2=80=99s bad then I want to be told this (and why). Thanks, William= --Apple-Mail=_80CB0879-CF53-43F6-8DAB-1B0E70FE497F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All,

This = message arose from a yang-multicast@ietf.org =E2=80=9Cdraft-ietf-pim-igmp-m= ld-yang-02.txt: YANG compilation isuse=E2=80=9D (sic) thread initiated by Benoit.

I thought it would be = useful for NETMOD to see the part of the discussion that relates to = implemented versus imported YANG modules.
  1. Benoit Claise reported this = warning:
    • warn: Schema node = "ietf-ip:ipv4" not found = (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:nam= e =3D current()]/ietf-ip:ipv4)
  2. Radek Krej=C4=8D=C3= =AD replied:
    • These warnings are = printed because in yanglint, until explicitly stated, the imported = modules (such as ietf-interfaces and ietf-ip), are supposed to be only = imported, not implemented. The data nodes in imported schemas are = not available, which is the reason of these warnings.
  3. William Lupton (that=E2=80=99s me!) asked / = commented:
    • Why are the complaints only = about ip:ipv4 (etc) and not about if:interfaces (etc), which are also = referenced in the must statements?
    • This makes it hard = for an automated tool (such as Benoit=E2=80=99s) because it needs to = know which other YANG files to process in addition to the =E2=80=9Cfile = of interest=E2=80=9D.
  4. Radek Krej=C4=8D=C3=AD = replied:
    • According to RFC 7950, sec = 5.6.6 (3rd paragraph) [ED: 5.6.5?], when an implemented module augments = another module (ietf-interfaces), the augmented module MUST be also = implemented. So libyang automatically changes the augmented module = from imported to the implemented. The same rule applies also in case of = referring a module in path (leafref) and by deviating a module. But = it does not apply when a module data is used in must or when conditions. = That's the reason why it complains just about ietf-ip and not about = ietf-interfaces.
    • YANG actually does not provide a way = to specify that a particular import is also expected to be implemented. = Therefore, libyang needs some help with setting modules = implemented - all the explicitly loaded modules are supposed to be = implemented, if the module is just implicitly loaded from the search = directory and user did not expressed that it is supposed to be = implemented, it is kept only imported to provide groupings or type = definitions
  5. Benoit Claise asked (referring to my = reference to automated tools):
    • Would = it be possible to improve the warning (and the related test, by testing = implemented instead of import), basically telling that the module itself = is fine?

I=E2=80=99m interested to know that NETMOD thinks about this = distinction between implemented versus imported (in the absence of any = instance documents). I guess my (maybe naive) view is that if all I=E2=80=99= m doing is checking for errors in my YANG model then I don=E2=80=99t = care about this. If my YANG is good I want to see no warnings or errors, = and if it=E2=80=99s bad then I want to be told this (and why).

Thanks,
William
= --Apple-Mail=_80CB0879-CF53-43F6-8DAB-1B0E70FE497F-- From nobody Mon Mar 6 08:59:44 2017 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 E569F129888 for ; Mon, 6 Mar 2017 08:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 dpIezwPRQBpV for ; Mon, 6 Mar 2017 08:59:41 -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 A6F051294FB for ; Mon, 6 Mar 2017 08:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10216; q=dns/txt; s=iport; t=1488819580; x=1490029180; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=seDCv4ZKZAD4K+frjmtBGWRes5YieTkSdnpZyrtTn0A=; b=Ts1sN6QX7cSM1xdcA6bYMhRS8taERRtNkMIER0yNX0q39qcu7x53/Oa6 t1SoC2YxEatqpfLwTlCwOeDl9AxbaQz4r71WGCSVCofhZxyZ+DmUTLjRu nQpTj7vHqmOpy3Gv1Mwh8izumifOf3xPGLSMvPCvvpdqOBmB/P0Oub/ZE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BvAwDolL1Y/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyeBCwOBB4Nfig1zkDMfkAuFLIINHwEMhSxKAoJhGAECAQEBAQE?= =?us-ascii?q?BAWsohRYBAQQBASFLGwkCDgonAwICJx8RBgEMBgIBAYl4DpINnVmCJiuKKgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFhk6CBQiCYoQ3AQGDIYJfBY9WjFaSM4pOhlG?= =?us-ascii?q?LMogJHziBAyIVCBcVP4RUHYFjQDUBhzkNFweCEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,254,1484006400"; d="scan'208,217";a="650208552" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2017 16:59:36 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v26Gxab3007980; Mon, 6 Mar 2017 16:59:36 GMT To: William Lupton , netmod@ietf.org References: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org> From: Robert Wilton Message-ID: <9ceda4b1-6297-bab4-7c4e-da29bbea6890@cisco.com> Date: Mon, 6 Mar 2017 16:59:36 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org> Content-Type: multipart/alternative; boundary="------------966026CFC5E77544B9DBE013" Archived-At: Subject: Re: [netmod] yanglint and implemented versus imported YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:59:43 -0000 This is a multi-part message in MIME format. --------------966026CFC5E77544B9DBE013 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi William, I think that what yanglint is doing here is sane, i.e. I think that its interpretation/split between imported vs implemented modules is supported by the YANG RFC. However, for validation purposes it seems that it would be useful if yanglint had an option to assume that all imported modules are implicitly implemented without requiring them to be explicitly specified. Thanks, Rob On 06/03/2017 16:44, William Lupton wrote: > All, > > This message arose from a yang-multicast@ietf.org > “draft-ietf-pim-igmp-mld-yang-02.txt: > YANG compilation isuse†(sic) thread > initiated > by Benoit. > > I thought it would be useful for NETMOD to see the part of the > discussion that relates to implemented versus imported YANG modules. > > 1. Benoit Claise reported this warning: > * warn: Schema node "ietf-ip:ipv4" not found > (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name > = current()]/ietf-ip:ipv4) > 2. Radek KrejÄí replied: > * These warnings are printed because in yanglint, until > explicitly stated, the imported modules (such as > ietf-interfaces and ietf-ip), are supposed to be only > imported, not implemented. The data nodes in imported schemas > are not available, which is the reason of these warnings. > 3. William Lupton (that’s me!) asked / commented: > * Why are the complaints only about ip:ipv4 (etc) and not about > if:interfaces (etc), which are also referenced in the must > statements? > * This makes it hard for an automated tool (such as Benoit’s) > because it needs to know which other YANG files to process in > addition to the “file of interestâ€. > 4. Radek KrejÄí replied: > * According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?], > when an implemented module augments another module > (ietf-interfaces), the augmented module MUST be also > implemented. So libyang automatically changes the augmented > module from imported to the implemented. The same rule applies > also in case of referring a module in path (leafref) and > by deviating a module. But it does not apply when a module > data is used in must or when conditions. That's the reason why > it complains just about ietf-ip and not about ietf-interfaces. > * YANG actually does not provide a way to specify that a > particular import is also expected to be implemented. > Therefore, libyang needs some help with setting modules > implemented - all the explicitly loaded modules are supposed > to be implemented, if the module is just implicitly loaded > from the search directory and user did not expressed that it > is supposed to be implemented, it is kept only imported to > provide groupings or type definitions > 5. Benoit Claise asked (referring to my reference to automated tools): > * Would it be possible to improve the warning (and the related > test, by testing implemented instead of import), basically > telling that the module itself is fine? > > > I’m interested to know that NETMOD thinks about this distinction > between implemented versus imported (in the absence of any instance > documents). I guess my (maybe naive) view is that if all I’m doing is > checking for errors in my YANG model then I don’t care about this. If > my YANG is good I want to see no warnings or errors, and if it’s bad > then I want to be told this (and why). > > Thanks, > William > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------966026CFC5E77544B9DBE013 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi William,

I think that what yanglint is doing here is sane, i.e. I think that its interpretation/split between imported vs implemented modules is supported by the YANG RFC.

However, for validation purposes it seems that it would be useful if yanglint had an option to assume that all imported modules are implicitly implemented without requiring them to be explicitly specified.

Thanks,
Rob


On 06/03/2017 16:44, William Lupton wrote:
All,

This message arose from a yang-multicast@ietf.org “draft-ietf-pim-igmp-mld-yang-02.txt: YANG compilation isuse†(sic) thread initiated by Benoit.

I thought it would be useful for NETMOD to see the part of the discussion that relates to implemented versus imported YANG modules.
  1. Benoit Claise reported this warning:
    • warn: Schema node "ietf-ip:ipv4" not found (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name = current()]/ietf-ip:ipv4)
  2. Radek KrejÄí replied:
    • These warnings are printed because in yanglint, until explicitly stated, the imported modules (such as ietf-interfaces and ietf-ip), are supposed to be only imported, not implemented. The data nodes in imported schemas are not available, which is the reason of these warnings.
  3. William Lupton (that’s me!) asked / commented:
    • Why are the complaints only about ip:ipv4 (etc) and not about if:interfaces (etc), which are also referenced in the must statements?
    • This makes it hard for an automated tool (such as Benoit’s) because it needs to know which other YANG files to process in addition to the “file of interestâ€.
  4. Radek KrejÄí replied:
    • According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?], when an implemented module augments another module (ietf-interfaces), the augmented module MUST be also implemented. So libyang automatically changes the augmented module from imported to the implemented. The same rule applies also in case of referring a module in path (leafref) and by deviating a module. But it does not apply when a module data is used in must or when conditions. That's the reason why it complains just about ietf-ip and not about ietf-interfaces.
    • YANG actually does not provide a way to specify that a particular import is also expected to be implemented. Therefore, libyang needs some help with setting modules implemented - all the explicitly loaded modules are supposed to be implemented, if the module is just implicitly loaded from the search directory and user did not expressed that it is supposed to be implemented, it is kept only imported to provide groupings or type definitions
  5. Benoit Claise asked (referring to my reference to automated tools):
    • Would it be possible to improve the warning (and the related test, by testing implemented instead of import), basically telling that the module itself is fine?

I’m interested to know that NETMOD thinks about this distinction between implemented versus imported (in the absence of any instance documents). I guess my (maybe naive) view is that if all I’m doing is checking for errors in my YANG model then I don’t care about this. If my YANG is good I want to see no warnings or errors, and if it’s bad then I want to be told this (and why).

Thanks,
William


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

--------------966026CFC5E77544B9DBE013-- From nobody Mon Mar 6 12:50:40 2017 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 8E6A6129A06 for ; Mon, 6 Mar 2017 12:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 rj4cSBl-HGDy for ; Mon, 6 Mar 2017 12:50:37 -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 E5E5A1294F7 for ; Mon, 6 Mar 2017 12:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=624; q=dns/txt; s=iport; t=1488833437; x=1490043037; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=rh0WeDjNlDJirjmc8bRawMiBO+pemPV8iQwl2NRcTNw=; b=K+lAIyKi+QggztDpxfobLmyOELznK9KGy0U5g8dSLrryiTs4QJW8+y8j FF2S6dz8FnEfKMhZGxgkhZ19cNuZWkUG3wC3eM+MiMLrrCEPbVcX/mvg8 SeDm2L6rmsp2gceUNgReOSFUykmaWaC1kT3iBxWttW1YXf77tY+1iwD5u 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7BQALy71Y/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIDgQeOXqYMgg0fC4UuSgKCZxcBAgEBAQEBAQFrKIUWAgQBATY?= =?us-ascii?q?2GwtGJzAGDQYCAQGJeA6yU4prAQEBAQEBAQMBAQEBAQEBIYZOggWCaoRHhXIBB?= =?us-ascii?q?JwshnaLPYFjGFOET4MxhReBOosyiAkhAjSBAyIVCBcVP4ZVPzUBhzmCOwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,255,1484006400"; d="scan'208";a="692776722" 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; 06 Mar 2017 20:50:34 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v26KoYIP032007 for ; Mon, 6 Mar 2017 20:50:34 GMT To: NETMOD Working Group References: From: Benoit Claise Message-ID: <3ca36636-a532-e3eb-a2eb-71ee4fd950b4@cisco.com> Date: Mon, 6 Mar 2017 21:50:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Toolchain upgraded to yangdump-pro 16.10-5 => 16.10-5.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 20:50:38 -0000 Dear all, yangdump-pro upgraded to 16.10-5.1 The stats look better: http://claise.be/IETFYANGPageCompilation.png See http://www.claise.be/IETFYANGPageCompilation.html for the remaining open issues on your YANG modules. Still a week to improve them. Regards, Benoit > Dear all, > > See http://www.claise.be/IETFYANGPageCompilation.html > At least two bugs related to the IETF YANG modules are fixed. > Please check your YANG modules. > > Regards, Benoit > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Mar 6 12:54:03 2017 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 B1DC91294F1 for ; Mon, 6 Mar 2017 12:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 MYcbSkV8HUpM for ; Mon, 6 Mar 2017 12:54:01 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 F18081204D9 for ; Mon, 6 Mar 2017 12:54:00 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-10v.sys.comcast.net with SMTP id kzbscVvBkILPAkzdoch8ox; Mon, 06 Mar 2017 20:54:00 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-10v.sys.comcast.net with SMTP id kzdmcR8nqrphjkzdncqgvM; Mon, 06 Mar 2017 20:54:00 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v26KrvNP001680; Mon, 6 Mar 2017 15:53:57 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v26KruW1001676; Mon, 6 Mar 2017 15:53:56 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Kent Watsen In-Reply-To: <033D3CA2-7297-48C8-A5BD-B723F7F1911B@juniper.net> (kwatsen@juniper.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 06 Mar 2017 15:53:56 -0500 Message-ID: <87k282cejf.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfPq1S9/o4Vnf1OU7QQ9Touj7nrfrDnabJyO1P7oJLeId8irvF8cPEeMAfvLTswvNsee9eJMnwpshNTc++YUS2ovYjDHE1YkNM4eHg0/luMUYq7Wm0RNy G1kX7bZMSakqg4X3zqijRZOoh4lHN3Pa5BLTpvgRhYMZ5drdHD3WKRHrPo1BBgSjqrrBuCqFYT3X829RSJqm4WXpVKJ2Tq2cFr4zOXdoUe7GtOq+I++w15xU iFeVmxuN0gjd3407Nl5lCkmgIq8X148Ai9SmTmOZO9ouWOgD5gWsVfMHAz7oJZsQ Archived-At: Cc: draft-ietf-netmod-syslog-model@ietf.org, netmod@ietf.org Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 20:54:02 -0000 (We seem to be well beyond the original LC date, but this is only an editorial comment...) The algorithm in section 3 isn't clear to me (possibly because I'm not very familiar with syslog in practice): Selector processing (input is syslog message): 1. Loop through facility-list a. Facility match processing - continue to the next entry in the list if no match b. Severity compare processing - continue to the next list entry if no match c. Match - proceed with the action and exit further processing 2. Process pattern match if specified and if a match proceed with the action If I understand correctly, a message is processed if it matches any one element of facility-list OR the regexp. In that case, I think you could it clearer by writing the pseudocode in a style that is more functional than imperative: A syslog message is processed if there is an element of facility-list (F, S) where the message facility matches F (if it is present) and the message severity matches S (if it is present) or the message text matches the pattern (if it is present) Dale From nobody Mon Mar 6 14:41:25 2017 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 0AC8D1294A6 for ; Mon, 6 Mar 2017 14:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 CfuTqda5OZxu for ; Mon, 6 Mar 2017 14:41:22 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0106.outbound.protection.outlook.com [104.47.42.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E686129493 for ; Mon, 6 Mar 2017 14:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nWe7aNljI2FJF8H01OV24WRkt0B8/i2KjvU1mjiwl+o=; b=OmHmfAhy4ReeVvQ/rMS7eAwaznsxv3AFecsWkWHZh9tlzzRv2juAE/wIFhRdtroaE99xCZkU6ovXYFw9GpfVVsqmbNem9Zpz2cJiXoDqJAvUCW9oBNwJ2x0elhRbk3Xb1KwNxwZmhHMrOa9fMwP/N8bUz/V9w4bv2V31C7txz5w= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Mon, 6 Mar 2017 22:41:21 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0961.012; Mon, 6 Mar 2017 22:41:21 +0000 From: Kent Watsen To: Benoit Claise , NETMOD Working Group Thread-Topic: [netmod] Toolchain upgraded to yangdump-pro 16.10-5 => 16.10-5.1 Thread-Index: AQHSlrtSoRQhVHdHJ0iRqMSLOzm2RaGIFEQA Date: Mon, 6 Mar 2017 22:41:21 +0000 Message-ID: References: <3ca36636-a532-e3eb-a2eb-71ee4fd950b4@cisco.com> In-Reply-To: <3ca36636-a532-e3eb-a2eb-71ee4fd950b4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:ia+2SxC7X+UwUahlfyJZPlTAsltT0dfXjRSrt84RJykdGoaskNjvNj9YgvHGZkFyFkqh2axMHTvUwO2Xu4zlAyM7B/q8EVNrMVUnEG38FyM3TjpxHpIcxV5o68LMAzEE5kHNeYfe9Z5SkKf/S91I5S/NMR+PuKxN9uuDwET/EErZmwuBYsBbE/yL37I3cYaRNSnyF8k7fvJMY4rgX1g8bZF9qmxb91eWeoZpDUpuemP/OJ/Zj6Mk7ZuxWALeVA6Xn8ht/d+75hkKF8VrCFbU0Y6SYAcsvVU+7+XVfkrI+kVFsKKuvEdd9sQfbmRSCpIg0UtdngUZrmOm5e7/CzbdUg== x-ms-office365-filtering-correlation-id: 781cdd33-475a-4052-772d-08d464e1e9c5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0238AEEDB0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39450400003)(39410400002)(39850400002)(6506006)(77096006)(86362001)(6486002)(102836003)(6436002)(25786008)(6512007)(122556002)(36756003)(6116002)(3846002)(106116001)(6306002)(2900100001)(8936002)(189998001)(81166006)(8676002)(5660300001)(66066001)(83716003)(2950100002)(53936002)(2906002)(6246003)(229853002)(33656002)(82746002)(83506001)(305945005)(53376002)(92566002)(3280700002)(966004)(38730400002)(50986999)(4001350100001)(7736002)(3660700001)(54356999)(76176999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <01222C6DCF19834686B5288542A1052B@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2017 22:41:21.7284 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] Toolchain upgraded to yangdump-pro 16.10-5 => 16.10-5.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 22:41:24 -0000 DQpIaSBCZW5vaXQsDQoNCllvdSBzZWVtIHRvIGtub3cgdGhlIGlucyBhbmQgb3V0cyBvZiBtYW55 IHRvb2xzIHRoZXNlIGRheXMsIG1heWJlIHlvdSBjYW4gcG9pbnQgbWUgaW4gdGhlIHJpZ2h0IGRp cmVjdGlvbi4uLndoaWNoIHRvb2wgaXMgYWJsZSB0byB2YWxpZGF0ZSBpbnN0YW5jZSBkb2N1bWVu dHMgYWdhaW5zdCBZQU5HIDEuMSBtb2R1bGVzPyAgDQoNCkkndmUgYWx3YXlzIHVzZWQgYHlhbmcy ZHNkbGAsIGJ1dCBjdXJyZW50bHkgaXQgb3V0cHV0cyAiRFNETCBwbHVnaW4gc3VwcG9ydHMgb25s eSBZQU5HIHZlcnNpb24gMSIuDQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0KDQoNCj4gRGVhciBh bGwsDQo+DQo+IHlhbmdkdW1wLXBybyB1cGdyYWRlZCB0byAxNi4xMC01LjENCj4gVGhlIHN0YXRz IGxvb2sgYmV0dGVyOiBodHRwOi8vY2xhaXNlLmJlL0lFVEZZQU5HUGFnZUNvbXBpbGF0aW9uLnBu Zw0KPiBTZWUgaHR0cDovL3d3dy5jbGFpc2UuYmUvSUVURllBTkdQYWdlQ29tcGlsYXRpb24uaHRt bCBmb3IgdGhlIHJlbWFpbmluZyANCj4gb3BlbiBpc3N1ZXMgb24geW91ciBZQU5HIG1vZHVsZXMu DQo+IFN0aWxsIGEgd2VlayB0byBpbXByb3ZlIHRoZW0uDQo+IA0KPiBSZWdhcmRzLCBCZW5vaXQN Cg0KDQo= From nobody Mon Mar 6 19:15:30 2017 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 5B97512948A for ; Mon, 6 Mar 2017 19:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 Xc-h5xSPHzBC for ; Mon, 6 Mar 2017 19:15:28 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 EDBAD129ABA for ; Mon, 6 Mar 2017 19:15:27 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id n11so80155030wma.0 for ; Mon, 06 Mar 2017 19:15: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=AHCcEdN3ZF7YC3mtSNRPH142FPhOWaRla3Ttdvs6UF0=; b=csibWLRS0PQg9PFWfpaCEW0k2aaiRDEccDa7JxSZd1JtwaquqthlbhaYcrIiPnllUr clNgYcQMJuwvMPIFy/a7hX3sSKipCtPBa9wl7O9MwEZOINBe//CE3uJzhrfHaSCbIkzT cplGAdW4ctC92WYov5EWl0O5EgqL00HfRnlUDIlMdR/C/2CjqBThv0W18fGhw27yHP0G BRZOWBA6AFpOkDfctVhJwcbX3OJdxutvJAcrzzMZd9nAKYRjeIp16o9H7d8kdVbYb6JW YB7ZTc5dCStDq0Tv83wuj77x/f4iz2TmOVennBACe8GuNVMlvRqnGM2z3xgcqCSY9Mjw azdQ== 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=AHCcEdN3ZF7YC3mtSNRPH142FPhOWaRla3Ttdvs6UF0=; b=kdOoRn6iCZqw3dDL3CtcZGZaa1JWKMDxfsbrZsnU9fhDkD6Af8J/wgfulc6lQJci3g i3BFQ0h+Lt5Jgn9/UsdW7wd2fmoKkNL9cEvHcheNnE6lrTEBucPl1buDlovFK60Re4so r4EBv4xp+bofBTwGZbGV+8+cV8HN5py2PbLALF0ZBQc6k9RuYv4p+utEW9B5vvG0VAZU CPp85d+iYrxhokYoJqm8VImG2CBKcI9CKMWGX8QElge9tFh17ZClrxCv4Mfw1Yk6bu8c dD3Li4f7KQhAUj8W109hLB+HhHiU6TE214OvJPioPe/c9AxlhA61K2UyC9P6WCFbMTbD IDaA== X-Gm-Message-State: AMke39m3nKtIW0Id4IkF5eCxP5+lTr3UqblnCInNN4NeMZOmzHXMyZXW432LXdsbaKBucacXh27+lgTQ1uj/Aw== X-Received: by 10.28.137.211 with SMTP id l202mr15576768wmd.118.1488856526185; Mon, 06 Mar 2017 19:15:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.86 with HTTP; Mon, 6 Mar 2017 19:15:25 -0800 (PST) From: Lyle Bertz Date: Mon, 6 Mar 2017 21:15:25 -0600 Message-ID: To: netmod@ietf.org Content-Type: multipart/alternative; boundary=001a114444965d6a8b054a1b6cff Archived-At: Subject: [netmod] New I-D Submission: draft-bertz-netmod-commonaugment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:15:29 -0000 --001a114444965d6a8b054a1b6cff Content-Type: text/plain; charset=UTF-8 All, This is a small submission that allows a single augment statement to be used to augment multiple schema locations or, at the very least, give the YANG to language generation tools a hint that the augment is similar to other augments in the module. It can be found at https://datatracker.ietf.org/doc/draft-bertz-netmod-commonaugment/ It is in direct response to issues that arose writing YANG for the IETF DMM FPC specification that can be found at https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ and also in response to issues found wrt yangtools (OpenDaylight) code generation of the FPC specification. Lyle --001a114444965d6a8b054a1b6cff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

This is a small subm= ission that allows a single augment statement to be used to augment multipl= e schema locations or, at the very least, give the YANG to language generat= ion tools a hint that the augment is similar to other augments in the modul= e.=C2=A0


It i= s in direct response to issues that arose writing YANG for the IETF DMM FPC= specification that can be found at
https://datatracker.ietf.org/doc/draft-ie= tf-dmm-fpc-cpdp/

and also in response to issues found wrt = yangtools (OpenDaylight) code generation of the FPC specification.

<= /div>Lyle
--001a114444965d6a8b054a1b6cff-- From nobody Tue Mar 7 00:44:00 2017 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 BF1C41293E4 for ; Tue, 7 Mar 2017 00:43:59 -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 H4NnFUdeqr2I for ; Tue, 7 Mar 2017 00:43:58 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EC3D112711D for ; Tue, 7 Mar 2017 00:43:57 -0800 (PST) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 303851820044; Tue, 7 Mar 2017 09:44:37 +0100 (CET) From: Ladislav Lhotka To: Lyle Bertz , netmod@ietf.org In-Reply-To: References: Date: Tue, 07 Mar 2017 09:43:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] New I-D Submission: draft-bertz-netmod-commonaugment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 08:44:00 -0000 Hi, while the use case is clear, I believe such rather fundamental changes to YANG cannot be done through extensions because otherwise the value of YANG as a standard will be lost. Lada Lyle Bertz writes: > All, > > This is a small submission that allows a single augment statement to be > used to augment multiple schema locations or, at the very least, give the > YANG to language generation tools a hint that the augment is similar to > other augments in the module. > > It can be found at > https://datatracker.ietf.org/doc/draft-bertz-netmod-commonaugment/ > > It is in direct response to issues that arose writing YANG for the IETF DMM > FPC specification that can be found at > https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ > > and also in response to issues found wrt yangtools (OpenDaylight) code > generation of the FPC specification. > > Lyle > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 7 01:00:14 2017 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 BD1C0129456 for ; Tue, 7 Mar 2017 01:00:08 -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 gM1dU_e-scBP for ; Tue, 7 Mar 2017 01:00:06 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F69E1293D8 for ; Tue, 7 Mar 2017 01:00:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 5581C1E5676; Tue, 7 Mar 2017 00:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vRJGaqW8xt7u; Tue, 7 Mar 2017 00:59:25 -0800 (PST) Received: from [192.168.1.127] (host81-132-49-127.range81-132.btcentralplus.com [81.132.49.127]) by c8a.amsl.com (Postfix) with ESMTPSA id 3F8EC1E5675; Tue, 7 Mar 2017 00:59:24 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_D93FA2F7-1D25-4F69-9D90-5092728D0055" From: William Lupton In-Reply-To: <9ceda4b1-6297-bab4-7c4e-da29bbea6890@cisco.com> Date: Tue, 7 Mar 2017 09:00:03 +0000 Message-Id: <1808B9E6-84DC-4615-B1F8-7063709A539D@broadband-forum.org> References: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org> <9ceda4b1-6297-bab4-7c4e-da29bbea6890@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3124) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yanglint and implemented versus imported YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 09:00:09 -0000 --Apple-Mail=_D93FA2F7-1D25-4F69-9D90-5092728D0055 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Could this be the default in the first of these two cases? Usage: yanglint [options] [-f { yang | yin | tree }] ... Validates the YANG module in , and all its dependencies. yanglint [options] [-f { xml | json }] ... ... Validates the YANG modeled data in according to the = . > On 6 Mar 2017, at 16:59, Robert Wilton wrote: >=20 > Hi William, >=20 > I think that what yanglint is doing here is sane, i.e. I think that = its interpretation/split between imported vs implemented modules is = supported by the YANG RFC. >=20 > However, for validation purposes it seems that it would be useful if = yanglint had an option to assume that all imported modules are = implicitly implemented without requiring them to be explicitly = specified. >=20 > Thanks, > Rob >=20 > On 06/03/2017 16:44, William Lupton wrote: >> All, >>=20 >> This message arose from a yang-multicast@ietf.org = =E2=80=9Cdraft-ietf-pim-igmp-mld-yang-02.= txt: YANG compilation isuse=E2=80=9D (sic) thread = initiated by Benoit. >>=20 >> I thought it would be useful for NETMOD to see the part of the = discussion that relates to implemented versus imported YANG modules. >> Benoit Claise reported this warning: >> warn: Schema node "ietf-ip:ipv4" not found = (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:nam= e =3D current()]/ietf-ip:ipv4) >> Radek Krej=C4=8D=C3=AD replied: >> These warnings are printed because in yanglint, until explicitly = stated, the imported modules (such as ietf-interfaces and ietf-ip), are = supposed to be only imported, not implemented. The data nodes in = imported schemas are not available, which is the reason of these = warnings. >> William Lupton (that=E2=80=99s me!) asked / commented: >> Why are the complaints only about ip:ipv4 (etc) and not about = if:interfaces (etc), which are also referenced in the must statements? >> This makes it hard for an automated tool (such as Benoit=E2=80=99s) = because it needs to know which other YANG files to process in addition = to the =E2=80=9Cfile of interest=E2=80=9D. >> Radek Krej=C4=8D=C3=AD replied: >> According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?], when = an implemented module augments another module (ietf-interfaces), the = augmented module MUST be also implemented. So libyang automatically = changes the augmented module from imported to the implemented. The same = rule applies also in case of referring a module in path (leafref) and by = deviating a module. But it does not apply when a module data is used in = must or when conditions. That's the reason why it complains just about = ietf-ip and not about ietf-interfaces. >> YANG actually does not provide a way to specify that a particular = import is also expected to be implemented. Therefore, libyang needs some = help with setting modules implemented - all the explicitly loaded = modules are supposed to be implemented, if the module is just implicitly = loaded from the search directory and user did not expressed that it is = supposed to be implemented, it is kept only imported to provide = groupings or type definitions >> Benoit Claise asked (referring to my reference to automated tools): >> Would it be possible to improve the warning (and the related test, by = testing implemented instead of import), basically telling that the = module itself is fine? >>=20 >> I=E2=80=99m interested to know that NETMOD thinks about this = distinction between implemented versus imported (in the absence of any = instance documents). I guess my (maybe naive) view is that if all I=E2=80=99= m doing is checking for errors in my YANG model then I don=E2=80=99t = care about this. If my YANG is good I want to see no warnings or errors, = and if it=E2=80=99s bad then I want to be told this (and why). >>=20 >> Thanks, >> William >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >=20 --Apple-Mail=_D93FA2F7-1D25-4F69-9D90-5092728D0055 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Could this be the default in the first of = these two cases?

Usage:
    yanglint [options] [-f { = yang | yin | tree }] <file>...
  =       Validates the YANG module in <file>, and all = its dependencies.

  =   yanglint [options] [-f { xml | json }] <schema>... = <file>...
        Validates = the YANG modeled data in <file> according to the = <schema>.

On 6 Mar 2017, at 16:59, Robert Wilton <rwilton@cisco.com> = wrote:

=20 =20

Hi = William,

I think that what yanglint is doing here is = sane, i.e. I think that its interpretation/split between imported vs implemented modules is supported by the YANG RFC.

However, = for validation purposes it seems that it would be useful if yanglint had an option to assume that all imported modules are implicitly implemented without requiring them to be explicitly specified.

Thanks,
Rob

On 06/03/2017 16:44, William Lupton wrote:
All,

This message arose from a yang-multicast@ietf.org =E2=80=9Cdraft-ietf-pim-igmp-m= ld-yang-02.txt: YANG compilation isuse=E2=80=9D (sic) thread initiated by Benoit.

I thought it would be useful for NETMOD to see the part of the discussion that relates to implemented versus imported YANG modules.
  1. Benoit Claise reported this warning:
    • warn: Schema node "ietf-ip:ipv4" not found = (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:nam= e =3D current()]/ietf-ip:ipv4)
  2. Radek Krej=C4=8D=C3=AD replied:
    • These warnings are printed because in = yanglint, until explicitly stated, the imported modules (such as ietf-interfaces and ietf-ip), are supposed to be only imported, not implemented. The data nodes in imported schemas are not available, which is the reason of these warnings.
  3. William Lupton (that=E2=80=99s me!) asked / = commented:
    • Why are the complaints only about ip:ipv4 = (etc) and not about if:interfaces (etc), which are also referenced in the must statements?
    • This makes it hard for an automated tool = (such as Benoit=E2=80=99s) because it needs to know which other = YANG files to process in addition to the =E2=80=9Cfile of = interest=E2=80=9D.
  4. Radek Krej=C4=8D=C3=AD replied:
    • According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?], when an implemented module augments another module (ietf-interfaces), the augmented module MUST be also implemented. So libyang = automatically changes the augmented module from imported to the implemented. The same rule applies also in case of referring a module in path (leafref) and by deviating = a module. But it does not apply when a module data is used in must or when conditions. That's the reason why it complains just about ietf-ip and not about ietf-interfaces.
    • YANG actually does not provide a way to = specify that a particular import is also expected to be implemented. Therefore, libyang needs some help with setting modules implemented - all the explicitly = loaded modules are supposed to be implemented, if the module is just implicitly loaded from the search directory and user did not expressed that it is supposed to be = implemented, it is kept only imported to provide groupings or type definitions
  5. Benoit Claise asked (referring to my reference = to automated tools):
    • Would it be possible to improve the warning (and the related test, by testing implemented instead of import), basically telling that the module itself is = fine?

I=E2=80=99m interested to know that NETMOD thinks = about this distinction between implemented versus imported (in the absence of any instance documents). I guess my (maybe naive) view is that if all I=E2=80=99m doing is checking for errors in my YANG = model then I don=E2=80=99t care about this. If my YANG is good I want = to see no warnings or errors, and if it=E2=80=99s bad then I want to be = told this (and why).

Thanks,
William


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


= --Apple-Mail=_D93FA2F7-1D25-4F69-9D90-5092728D0055-- From nobody Tue Mar 7 01:30:58 2017 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 3945A1293D8 for ; Tue, 7 Mar 2017 01:30:57 -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 Cb-L-FSuwoTa for ; Tue, 7 Mar 2017 01:30:55 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 663D51270B4 for ; Tue, 7 Mar 2017 01:30:54 -0800 (PST) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 8ACB21820044; Tue, 7 Mar 2017 10:31:33 +0100 (CET) From: Ladislav Lhotka To: Robert Wilton , William Lupton , netmod@ietf.org In-Reply-To: <9ceda4b1-6297-bab4-7c4e-da29bbea6890@cisco.com> References: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org> <9ceda4b1-6297-bab4-7c4e-da29bbea6890@cisco.com> Date: Tue, 07 Mar 2017 10:30:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] yanglint and implemented versus imported YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 09:30:57 -0000 Robert Wilton writes: > Hi William, > > I think that what yanglint is doing here is sane, i.e. I think that its=20 > interpretation/split between imported vs implemented modules is=20 > supported by the YANG RFC. > > However, for validation purposes it seems that it would be useful if=20 > yanglint had an option to assume that all imported modules are=20 > implicitly implemented without requiring them to be explicitly > specified. This will fail if a module just wants to use a grouping or typedef from an imported module but not data nodes that may also be there.=20 It is exactly the problem that I mentioned in the discussion about NETMOD charter: we need a way to specify a complete data model. In my YANG/I-D development environment [1], a hello XML file is used for this purpose. Lada [1] https://github.com/llhotka/YANG-I-D > > Thanks, > Rob > > > On 06/03/2017 16:44, William Lupton wrote: >> All, >> >> This message arose from a yang-multicast@ietf.org=20 >> =E2=80=9Cdraft-ietf-pim-igmp-mld-yang-0= 2.txt:=20 >> YANG compilation isuse=E2=80=9D (sic) thread=20 >> initiated=20 >> by Benoit. >> >> I thought it would be useful for NETMOD to see the part of the=20 >> discussion that relates to implemented versus imported YANG modules. >> >> 1. Benoit Claise reported this warning: >> * warn: Schema node "ietf-ip:ipv4" not found >> (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-inte= rfaces:name >> =3D current()]/ietf-ip:ipv4) >> 2. Radek Krej=C4=8D=C3=AD replied: >> * These warnings are printed because in yanglint, until >> explicitly stated, the imported modules (such as >> ietf-interfaces and ietf-ip), are supposed to be only >> imported, not implemented. The data nodes in imported schemas >> are not available, which is the reason of these warnings. >> 3. William Lupton (that=E2=80=99s me!) asked / commented: >> * Why are the complaints only about ip:ipv4 (etc) and not about >> if:interfaces (etc), which are also referenced in the must >> statements? >> * This makes it hard for an automated tool (such as Benoit=E2=80= =99s) >> because it needs to know which other YANG files to process in >> addition to the =E2=80=9Cfile of interest=E2=80=9D. >> 4. Radek Krej=C4=8D=C3=AD replied: >> * According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?], >> when an implemented module augments another module >> (ietf-interfaces), the augmented module MUST be also >> implemented. So libyang automatically changes the augmented >> module from imported to the implemented. The same rule applies >> also in case of referring a module in path (leafref) and >> by deviating a module. But it does not apply when a module >> data is used in must or when conditions. That's the reason why >> it complains just about ietf-ip and not about ietf-interfaces. >> * YANG actually does not provide a way to specify that a >> particular import is also expected to be implemented. >> Therefore, libyang needs some help with setting modules >> implemented - all the explicitly loaded modules are supposed >> to be implemented, if the module is just implicitly loaded >> from the search directory and user did not expressed that it >> is supposed to be implemented, it is kept only imported to >> provide groupings or type definitions >> 5. Benoit Claise asked (referring to my reference to automated tools): >> * Would it be possible to improve the warning (and the related >> test, by testing implemented instead of import), basically >> telling that the module itself is fine? >> >> >> I=E2=80=99m interested to know that NETMOD thinks about this distinction= =20 >> between implemented versus imported (in the absence of any instance=20 >> documents). I guess my (maybe naive) view is that if all I=E2=80=99m doi= ng is=20 >> checking for errors in my YANG model then I don=E2=80=99t care about thi= s. If=20 >> my YANG is good I want to see no warnings or errors, and if it=E2=80=99s= bad=20 >> then I want to be told this (and why). >> >> Thanks, >> William >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 7 01:49:42 2017 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 8969812945F for ; Tue, 7 Mar 2017 01:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LsIUi2A2NSX for ; Tue, 7 Mar 2017 01:49:39 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08CA129434 for ; Tue, 7 Mar 2017 01:49:38 -0800 (PST) Received: from [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360] (unknown [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id F243A200DF; Tue, 7 Mar 2017 10:49:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1488880176; bh=fdoHrOXerVacTMrpqzJuiTxwB+1iJqulpriHqS92u9U=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=YWiMYO49I9fw03H0hedu+jm+NO/Kk5Hnoo2jZH5kGCm6za+Bbr+nVDNzjJ4Q5wzM2 0DKEWVVUY6xEvO5SYRyeFP45PGM/sQu+v/LuJfmhjjwjHRaeK95ZIrldN4uxwPVlot eMTy9bnsnnaIEZiqQlhSbQnBosNMO1NCQ6sY7rec= To: William Lupton , Robert Wilton References: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org> <9ceda4b1-6297-bab4-7c4e-da29bbea6890@cisco.com> <1808B9E6-84DC-4615-B1F8-7063709A539D@broadband-forum.org> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Message-ID: <0e932dec-7b45-1707-76c4-9c4f9010547e@cesnet.cz> Date: Tue, 7 Mar 2017 10:49:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <1808B9E6-84DC-4615-B1F8-7063709A539D@broadband-forum.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yanglint and implemented versus imported YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 09:49:41 -0000 Hi, I think that the default approach should be to expect that, until explici= tly stated, the imported module is just imported, not implemented. But it= is fine to me to add an option to force the implemented flag on all the = modules. Benoit can then use the flag in his scripts. However, I checked RFC 7950 again, and I would like to have a feedback fr= om the NETMOD group to the section 7.1.5, that states that "the importing module may: =2E.. o use any node in the imported module's schema tree in "must", "path", and "when" statements, or as the target node in "augment" and "deviation" statements." I'm interested in "must" and "when". I'm not sure why it is mentioned her= e, because, in contrast to "path", "augment" and "deviation", "when" and "must" contain XPath expression, so actually even not defined = schema node can be used in it (and this is the reason why yanglint does n= ot complain with error, but just with warning). Of course, the result is = then always false (ok, depending on the rest of the expression, but it si= mply does not depend on the data presence). And this is the reason to hav= e it at least as warning, because it is usually not the original intentio= n of the author. Regards, Radek Dne 7.3.2017 v 10:00 William Lupton napsal(a): > Could this be the default in the first of these two cases? > > Usage: > yanglint [options] [-f { yang | yin | tree }] ... > Validates the YANG module in , and all its dependencies. > > yanglint [options] [-f { xml | json }] ... ... > Validates the YANG modeled data in according to the . > >> On 6 Mar 2017, at 16:59, Robert Wilton > wrote: >> >> Hi William, >> >> I think that what yanglint is doing here is sane, i.e. I think that it= s interpretation/split between imported vs implemented modules is support= ed by the YANG RFC. >> >> However, for validation purposes it seems that it would be useful if y= anglint had an option to assume that all imported modules are implicitly = implemented without requiring them to be explicitly specified. >> >> Thanks, >> Rob >> >> On 06/03/2017 16:44, William Lupton wrote: >>> All, >>> >>> This message arose from a yang-multicast@ietf.org =E2=80=9Cdraft-ietf-pim-igmp-mld-yang-02.txt: YANG compilat= ion isuse=E2=80=9D (sic) thread initiated by Benoit. >>> >>> I thought it would be useful for NETMOD to see the part of the discus= sion that relates to implemented versus imported YANG modules. >>> >>> 1. Benoit Claise reported this warning: >>> * warn: Schema node "ietf-ip:ipv4" not found (/ietf-interfaces:= interfaces/ietf-interfaces:interface[ietf-interfaces:name =3D current()]/= ietf-ip:ipv4) >>> 2. Radek Krej=C4=8D=C3=AD replied: >>> * These warnings are printed because in yanglint, until explici= tly stated, the imported modules (such as ietf-interfaces and ietf-ip), a= re supposed to be only imported, not implemented. The data nodes in impor= ted schemas are not available, which is the reason of these warnings. >>> 3. William Lupton (that=E2=80=99s me!) asked / commented: >>> * Why are the complaints only about ip:ipv4 (etc) and not about= if:interfaces (etc), which are also referenced in the must statements? >>> * This makes it hard for an automated tool (such as Benoit=E2=80= =99s) because it needs to know which other YANG files to process in addit= ion to the =E2=80=9Cfile of interest=E2=80=9D. >>> 4. Radek Krej=C4=8D=C3=AD replied: >>> * According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?]= , when an implemented module augments another module (ietf-interfaces), t= he augmented module MUST be also implemented. So libyang automatically ch= anges the augmented module from imported to the implemented. The same rul= e applies also in case of referring a module in path (leafref) and by dev= iating a module. But it does not apply when a module data is used in must= or when conditions. That's the reason why it complains just about ietf-i= p and not about ietf-interfaces. >>> * YANG actually does not provide a way to specify that a partic= ular import is also expected to be implemented. Therefore, libyang needs = some help with setting modules implemented - all the explicitly loaded mo= dules are supposed to be implemented, if the module is just implicitly lo= aded from the search directory and user did not expressed that it is supp= osed to be implemented, it is kept only imported to provide groupings or = type definitions >>> 5. Benoit Claise asked (referring to my reference to automated tools= ): >>> * Would it be possible to improve the warning (and the related = test, by testing implemented instead of import), basically telling that t= he module itself is fine? >>> >>> >>> I=E2=80=99m interested to know that NETMOD thinks about this distinct= ion between implemented versus imported (in the absence of any instance d= ocuments). I guess my (maybe naive) view is that if all I=E2=80=99m doing= is checking for errors in my YANG model then I don=E2=80=99t care about = this. If my YANG is good I want to see no warnings or errors, and if it=E2= =80=99s bad then I want to be told this (and why). >>> >>> Thanks, >>> William >>> >>> >>> _______________________________________________ >>> 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 Tue Mar 7 01:55:00 2017 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 F0F20129579 for ; Tue, 7 Mar 2017 01:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60jmvFwxYJYz for ; Tue, 7 Mar 2017 01:54:57 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4A012947C for ; Tue, 7 Mar 2017 01:54:57 -0800 (PST) Received: from [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360] (unknown [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id A645120088; Tue, 7 Mar 2017 10:54:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1488880495; bh=rMi9lAoDj2OD2qdPzZ5DEo1ySdad6KRgo/CUdKKhHMk=; h=Subject:To:References:From:Date:In-Reply-To; b=GrBS5uF09XuTAfoyr+F4kL5XsG9eDlaKi+8PzqYXDJx+0NnD2Qdx6h1boATQJxdpy ECFkMVbjvQR/HuYKpClC9zntk+UlxDOTNVX3oZfxTkJx2BWaS54dMGR12VEp9KT162 rL+mQkQYIh1ny9kzry/EoYp4doAKU9p+ckui5WFc= To: Ladislav Lhotka , Robert Wilton , William Lupton , netmod@ietf.org References: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org> <9ceda4b1-6297-bab4-7c4e-da29bbea6890@cisco.com> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Message-ID: Date: Tue, 7 Mar 2017 10:54:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] yanglint and implemented versus imported YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 09:54:59 -0000 Hi Lada, Dne 7.3.2017 v 10:30 Ladislav Lhotka napsal(a): > Robert Wilton writes: > >> Hi William, >> >> I think that what yanglint is doing here is sane, i.e. I think that it= s=20 >> interpretation/split between imported vs implemented modules is=20 >> supported by the YANG RFC. >> >> However, for validation purposes it seems that it would be useful if=20 >> yanglint had an option to assume that all imported modules are=20 >> implicitly implemented without requiring them to be explicitly >> specified. > This will fail if a module just wants to use a grouping or typedef from= > an imported module but not data nodes that may also be there.=20 but does it affect the validation of the module? > It is exactly the problem that I mentioned in the discussion about > NETMOD charter: we need a way to specify a complete data model. In my > YANG/I-D development environment [1], a hello XML file is used for this= > purpose. > > Lada > > [1] https://github.com/llhotka/YANG-I-D we have this feature in TODO for yanglint, but I'm afraid that it does no= t solve the issue - even now the script can read some additional file wit= h the specification which modules are expected to be loaded before the mo= dule being validated (i.e. which imported module is supposed to be implem= ented). The root of the issue is that this information is not part of the= importing module itself. Radek > >> Thanks, >> Rob >> >> >> On 06/03/2017 16:44, William Lupton wrote: >>> All, >>> >>> This message arose from a yang-multicast@ietf.org=20 >>> =E2=80=9Cdraft-ietf-pim-igmp-mld-yan= g-02.txt:=20 >>> YANG compilation isuse=E2=80=9D (sic) thread=20 >>> initiated=20 >>> by Benoit. >>> >>> I thought it would be useful for NETMOD to see the part of the=20 >>> discussion that relates to implemented versus imported YANG modules. >>> >>> 1. Benoit Claise reported this warning: >>> * warn: Schema node "ietf-ip:ipv4" not found >>> (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-i= nterfaces:name >>> =3D current()]/ietf-ip:ipv4) >>> 2. Radek Krej=C4=8D=C3=AD replied: >>> * These warnings are printed because in yanglint, until >>> explicitly stated, the imported modules (such as >>> ietf-interfaces and ietf-ip), are supposed to be only >>> imported, not implemented. The data nodes in imported schemas= >>> are not available, which is the reason of these warnings. >>> 3. William Lupton (that=E2=80=99s me!) asked / commented: >>> * Why are the complaints only about ip:ipv4 (etc) and not about= >>> if:interfaces (etc), which are also referenced in the must >>> statements? >>> * This makes it hard for an automated tool (such as Benoit=E2=80= =99s) >>> because it needs to know which other YANG files to process in= >>> addition to the =E2=80=9Cfile of interest=E2=80=9D. >>> 4. Radek Krej=C4=8D=C3=AD replied: >>> * According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?]= , >>> when an implemented module augments another module >>> (ietf-interfaces), the augmented module MUST be also >>> implemented. So libyang automatically changes the augmented >>> module from imported to the implemented. The same rule applie= s >>> also in case of referring a module in path (leafref) and >>> by deviating a module. But it does not apply when a module >>> data is used in must or when conditions. That's the reason wh= y >>> it complains just about ietf-ip and not about ietf-interfaces= =2E >>> * YANG actually does not provide a way to specify that a >>> particular import is also expected to be implemented. >>> Therefore, libyang needs some help with setting modules >>> implemented - all the explicitly loaded modules are supposed >>> to be implemented, if the module is just implicitly loaded >>> from the search directory and user did not expressed that it >>> is supposed to be implemented, it is kept only imported to >>> provide groupings or type definitions >>> 5. Benoit Claise asked (referring to my reference to automated tools= ): >>> * Would it be possible to improve the warning (and the related >>> test, by testing implemented instead of import), basically >>> telling that the module itself is fine? >>> >>> >>> I=E2=80=99m interested to know that NETMOD thinks about this distinct= ion=20 >>> between implemented versus imported (in the absence of any instance=20 >>> documents). I guess my (maybe naive) view is that if all I=E2=80=99m = doing is=20 >>> checking for errors in my YANG model then I don=E2=80=99t care about = this. If=20 >>> my YANG is good I want to see no warnings or errors, and if it=E2=80=99= s bad=20 >>> then I want to be told this (and why). >>> >>> Thanks, >>> William >>> >>> >>> _______________________________________________ >>> 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 Tue Mar 7 02:03:05 2017 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 C738C129455 for ; Tue, 7 Mar 2017 02:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 bVvAfYInKlB8 for ; Tue, 7 Mar 2017 02:03:02 -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 83B78129434 for ; Tue, 7 Mar 2017 02:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7314; q=dns/txt; s=iport; t=1488880981; x=1490090581; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=bvjCITg+b2dLdTyKD07DpNRPn3UnGVf0byfaxJwAynE=; b=biSZUEOfxFnbv2hBB8ZaHWdmWhIOzEY0cohUJEgYsD30u/whn80tKHdq rnL62gAsFcyjPymBw0WFdJzpNpVi0DBzA0lpZCiNUT6U3TozydCP74v3l uHSZ/Mp3/tBx2AI30oBJvbuuBx0XlYeWEtAqLiVtAAZ8HyFFu7boerkqK I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAgC3hL5Y/xbLJq1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuOYELAydgjWtzkFeQC4Usgg0fAQqFLkoCgmQYAQIBAQEBAQE?= =?us-ascii?q?Bax0LhRYBAQQBAWwbCxguJzAGDQYCAQGJeA6xRCuKUgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARgFhk6CBYJqgTyCcRGFewWcMIZ2i0CKToZRizKICR84gQMiFQgXFT+?= =?us-ascii?q?EYYFzQDWKEwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,258,1484006400"; d="scan'208,217";a="651250744" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2017 10:02:59 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v27A2xVX008718 for ; Tue, 7 Mar 2017 10:02:59 GMT To: "netmod@ietf.org" References: From: Robert Wilton Message-ID: Date: Tue, 7 Mar 2017 10:02:59 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------70982D8F6773CF924CA79B5D" Archived-At: Subject: Re: [netmod] RFC 7950 - Import without revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 10:03:04 -0000 This is a multi-part message in MIME format. --------------70982D8F6773CF924CA79B5D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Another place in the draft that appears to be inconsistent with the section 5.6.5 text below is in 7.1.5, last sentence of this paragraph: When the optional "revision-date" substatement is present, any typedef, grouping, extension, feature, and identity referenced by definitions in the local module are taken from the specified revision of the imported module. It is an error if the specified revision of the imported module does not exist.*If no "revision-date" substatement is present, it is undefined from which revision of the module they are taken.* I think that section 5.6.5 does define which revision is used (as the text below). I.e. it is the most recent revision out of all the module revisions that are imported or implemented. Rob On 27/02/2017 11:15, Robert Wilton wrote: > > in RFC 7950, The last paragraph, section 5.1.1 "Import and Include by > Revision" states: > > "If a module is not imported with a specific revision, it is > undefined which revision is used." > > But I was wondering if the above text is misleading, since section > 5.6.5: "Implementing a Module" has the following two paragraphs: > > If a server implements a module A that imports a module C without > specifying the revision date of module C and the server does not > implement C (e.g., if C only defines some typedefs), the server MUST > list module C in the "/modules-state/module" list from > "ietf-yang-library" [RFC7895 ], and it MUST set the leaf > "conformance-type" to "import" for this module. > > If a server lists a module C in the "/modules-state/module" list from > "ietf-yang-library" and there are other modules Ms listed that import > C without specifying the revision date of module C, the server MUST > use the definitions from the most recent revision of C listed for > modules Ms. > > The reason for these rules is that clients need to be able to know > the specific data model structure and types of all leafs and > leaf-lists implemented in a server. > > This seems to imply that import without specifying the revision would > mean that the latest revision listed in ietf-yang-library must be the > one that is imported. Is that correct, or am I misinterpreting the > text? Hence, should the last paragraph of section 5.1.1 be deleted? > > Thanks, > Rob > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------70982D8F6773CF924CA79B5D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Another place in the draft that appears to be inconsistent with the section 5.6.5 text below is in 7.1.5, last sentence of this paragraph: 

   When the optional "revision-date" substatement is present, any
   typedef, grouping, extension, feature, and identity referenced by
   definitions in the local module are taken from the specified revision
   of the imported module.  It is an error if the specified revision of
   the imported module does not exist.  If no "revision-date"
   substatement is present, it is undefined from which revision of the
   module they are taken.

I think that section 5.6.5 does define which revision is used (as the text below). I.e. it is the most recent revision out of all the module revisions that are imported or implemented.

Rob


On 27/02/2017 11:15, Robert Wilton wrote:

in RFC 7950, The last paragraph, section 5.1.1 "Import and Include by Revision" states:

"If a module is not imported with a specific revision, it is undefined
 which revision is used."

But I was wondering if the above text is misleading, since section 5.6.5: "Implementing a Module" has the following two paragraphs:

   If a server implements a module A that imports a module C without
   specifying the revision date of module C and the server does not
   implement C (e.g., if C only defines some typedefs), the server MUST
   list module C in the "/modules-state/module" list from
   "ietf-yang-library" [RFC7895], and it MUST set the leaf
   "conformance-type" to "import" for this module.

   If a server lists a module C in the "/modules-state/module" list from
   "ietf-yang-library" and there are other modules Ms listed that import
   C without specifying the revision date of module C, the server MUST
   use the definitions from the most recent revision of C listed for
   modules Ms.

   The reason for these rules is that clients need to be able to know
   the specific data model structure and types of all leafs and
   leaf-lists implemented in a server.
This seems to imply that import without specifying the revision would mean that the latest revision listed in ietf-yang-library must be the one that is imported.  Is that correct, or am I misinterpreting the text?  Hence, should the last paragraph of section 5.1.1 be deleted?

Thanks,
Rob


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

--------------70982D8F6773CF924CA79B5D-- From nobody Tue Mar 7 02:05:58 2017 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 C8F2112945F for ; Tue, 7 Mar 2017 02:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lAsM_nWT5yT for ; Tue, 7 Mar 2017 02:05:55 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1577129455 for ; Tue, 7 Mar 2017 02:05:55 -0800 (PST) Received: from [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360] (unknown [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 1C1C820088; Tue, 7 Mar 2017 11:05:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1488881154; bh=pSaozwpGcwM5k2FzjP4ucWVBK3T2ywuj9dfAtwhL7hg=; h=Subject:To:References:From:Date:In-Reply-To; b=gaaPRfZjQH+njIcTFPawdZgavvcMUT+reOHYyBUUDS6yps2cY/1+GFITxkDaYQ8/X FIbVeJAA4KP9T4zoEF9m4bMbKODVT/Vhk7ysEFFXtkKY+YvXTWKJX+ieubOAWgcTbN wis6B0FThzf8znNe0Ynlg9FSjfP6dqpYqbNv0jmg= To: Kent Watsen , Benoit Claise , NETMOD Working Group References: <3ca36636-a532-e3eb-a2eb-71ee4fd950b4@cisco.com> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Message-ID: Date: Tue, 7 Mar 2017 11:05:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Toolchain upgraded to yangdump-pro 16.10-5 => 16.10-5.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 10:05:58 -0000 Hi Kent, yanglint should be able to do it for you. Preferably, use the current devel branch (it should be merged into master within a few days). https://github.com/CESNET/libyang Regards, Radek Dne 6.3.2017 v 23:41 Kent Watsen napsal(a): > Hi Benoit, > > You seem to know the ins and outs of many tools these days, maybe you can point me in the right direction...which tool is able to validate instance documents against YANG 1.1 modules? > > I've always used `yang2dsdl`, but currently it outputs "DSDL plugin supports only YANG version 1". > > Kent // contributor > > > >> Dear all, >> >> yangdump-pro upgraded to 16.10-5.1 >> The stats look better: http://claise.be/IETFYANGPageCompilation.png >> See http://www.claise.be/IETFYANGPageCompilation.html for the remaining >> open issues on your YANG modules. >> Still a week to improve them. >> >> Regards, Benoit > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 7 03:53:47 2017 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 1106D129624 for ; Tue, 7 Mar 2017 03:53:46 -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 r88aJahgB3QU for ; Tue, 7 Mar 2017 03:53:44 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C13AB1295D0 for ; Tue, 7 Mar 2017 03:53:43 -0800 (PST) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id B95041820044; Tue, 7 Mar 2017 12:54:21 +0100 (CET) From: Ladislav Lhotka To: Radek =?utf-8?B?S3JlasSNw60=?= , Robert Wilton , William Lupton , netmod@ietf.org In-Reply-To: References: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org> <9ceda4b1-6297-bab4-7c4e-da29bbea6890@cisco.com> Date: Tue, 07 Mar 2017 12:53:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] yanglint and implemented versus imported YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 11:53:46 -0000 Radek Krej=C4=8D=C3=AD writes: > Hi Lada, > > Dne 7.3.2017 v 10:30 Ladislav Lhotka napsal(a): >> Robert Wilton writes: >> >>> Hi William, >>> >>> I think that what yanglint is doing here is sane, i.e. I think that its= =20 >>> interpretation/split between imported vs implemented modules is=20 >>> supported by the YANG RFC. >>> >>> However, for validation purposes it seems that it would be useful if=20 >>> yanglint had an option to assume that all imported modules are=20 >>> implicitly implemented without requiring them to be explicitly >>> specified. >> This will fail if a module just wants to use a grouping or typedef from >> an imported module but not data nodes that may also be there.=20 > > but does it affect the validation of the module? Potentially it could - for example, the imported module may have some default content with "must" statements. Practically, it shouldn't be a problem most of the time. > >> It is exactly the problem that I mentioned in the discussion about >> NETMOD charter: we need a way to specify a complete data model. In my >> YANG/I-D development environment [1], a hello XML file is used for this >> purpose. >> >> Lada >> >> [1] https://github.com/llhotka/YANG-I-D > > we have this feature in TODO for yanglint, but I'm afraid that it does Now it's better to use yang-library, as Yangson does (but maybe this is your plan, right?). > not solve the issue - even now the script can read some additional > file with the specification which modules are expected to be loaded > before the module being validated (i.e. which imported module is > supposed to be implemented). The root of the issue is that this > information is not part of the importing module itself. This would be one option, otherwise this information can also be included in the document separately as metadata - validation instructions. This could BTW also solve the issue of what modules are supposed to be validated. Lada > > Radek > >> >>> Thanks, >>> Rob >>> >>> >>> On 06/03/2017 16:44, William Lupton wrote: >>>> All, >>>> >>>> This message arose from a yang-multicast@ietf.org=20 >>>> =E2=80=9Cdraft-ietf-pim-igmp-mld-yang= -02.txt:=20 >>>> YANG compilation isuse=E2=80=9D (sic) thread=20 >>>> initiated=20 >>>> by Benoit. >>>> >>>> I thought it would be useful for NETMOD to see the part of the=20 >>>> discussion that relates to implemented versus imported YANG modules. >>>> >>>> 1. Benoit Claise reported this warning: >>>> * warn: Schema node "ietf-ip:ipv4" not found >>>> (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-in= terfaces:name >>>> =3D current()]/ietf-ip:ipv4) >>>> 2. Radek Krej=C4=8D=C3=AD replied: >>>> * These warnings are printed because in yanglint, until >>>> explicitly stated, the imported modules (such as >>>> ietf-interfaces and ietf-ip), are supposed to be only >>>> imported, not implemented. The data nodes in imported schemas >>>> are not available, which is the reason of these warnings. >>>> 3. William Lupton (that=E2=80=99s me!) asked / commented: >>>> * Why are the complaints only about ip:ipv4 (etc) and not about >>>> if:interfaces (etc), which are also referenced in the must >>>> statements? >>>> * This makes it hard for an automated tool (such as Benoit=E2=80= =99s) >>>> because it needs to know which other YANG files to process in >>>> addition to the =E2=80=9Cfile of interest=E2=80=9D. >>>> 4. Radek Krej=C4=8D=C3=AD replied: >>>> * According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?], >>>> when an implemented module augments another module >>>> (ietf-interfaces), the augmented module MUST be also >>>> implemented. So libyang automatically changes the augmented >>>> module from imported to the implemented. The same rule applies >>>> also in case of referring a module in path (leafref) and >>>> by deviating a module. But it does not apply when a module >>>> data is used in must or when conditions. That's the reason why >>>> it complains just about ietf-ip and not about ietf-interfaces. >>>> * YANG actually does not provide a way to specify that a >>>> particular import is also expected to be implemented. >>>> Therefore, libyang needs some help with setting modules >>>> implemented - all the explicitly loaded modules are supposed >>>> to be implemented, if the module is just implicitly loaded >>>> from the search directory and user did not expressed that it >>>> is supposed to be implemented, it is kept only imported to >>>> provide groupings or type definitions >>>> 5. Benoit Claise asked (referring to my reference to automated tools): >>>> * Would it be possible to improve the warning (and the related >>>> test, by testing implemented instead of import), basically >>>> telling that the module itself is fine? >>>> >>>> >>>> I=E2=80=99m interested to know that NETMOD thinks about this distincti= on=20 >>>> between implemented versus imported (in the absence of any instance=20 >>>> documents). I guess my (maybe naive) view is that if all I=E2=80=99m d= oing is=20 >>>> checking for errors in my YANG model then I don=E2=80=99t care about t= his. If=20 >>>> my YANG is good I want to see no warnings or errors, and if it=E2=80= =99s bad=20 >>>> then I want to be told this (and why). >>>> >>>> Thanks, >>>> William >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 7 04:05:23 2017 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 46CB8129432 for ; Tue, 7 Mar 2017 04:05:22 -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 pJrSUggboL7m for ; Tue, 7 Mar 2017 04:05:20 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB021293E9 for ; Tue, 7 Mar 2017 04:05:20 -0800 (PST) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 276311820044; Tue, 7 Mar 2017 13:06:00 +0100 (CET) From: Ladislav Lhotka To: Radek =?utf-8?B?S3JlasSNw60=?= , William Lupton , Robert Wilton In-Reply-To: <0e932dec-7b45-1707-76c4-9c4f9010547e@cesnet.cz> References: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org> <9ceda4b1-6297-bab4-7c4e-da29bbea6890@cisco.com> <1808B9E6-84DC-4615-B1F8-7063709A539D@broadband-forum.org> <0e932dec-7b45-1707-76c4-9c4f9010547e@cesnet.cz> Date: Tue, 07 Mar 2017 13:05:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yanglint and implemented versus imported YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 12:05:22 -0000 Radek Krej=C4=8D=C3=AD writes: > Hi, > I think that the default approach should be to expect that, until explici= tly stated, the imported module is just imported, not implemented. But it i= s fine to me to add an option to force the implemented flag on all the modu= les. Benoit can then use the flag in his scripts. > > However, I checked RFC 7950 again, and I would like to have a feedback fr= om the NETMOD group to the section 7.1.5, that states that > "the importing module may: > ... > o use any node in the imported module's schema tree in "must", > "path", and "when" statements, or as the target node in "augment" > and "deviation" statements." Strictly speaking, this is incorrect. XPath expressions do not refer to schema nodes but rather to nodes/nodesets in an instance data tree. > > I'm interested in "must" and "when". I'm not sure why it is mentioned > here, because, in contrast to "path", "augment" and "deviation", Actually, the argument of "path" is also a (simplified) XPath expression. > "when" and "must" contain XPath expression, so actually even not > defined schema node can be used in it (and this is the reason why > yanglint does not complain with error, but just with warning). Of > course, the result is then always false (ok, depending on the rest of > the expression, but it simply does not depend on the data > presence). And this is the reason to have it at least as warning, > because it is usually not the original intention of the author. Agreed, Lada > > Regards, > Radek > > > Dne 7.3.2017 v 10:00 William Lupton napsal(a): >> Could this be the default in the first of these two cases? >> >> Usage: >> yanglint [options] [-f { yang | yin | tree }] ... >> Validates the YANG module in , and all its dependencies. >> >> yanglint [options] [-f { xml | json }] ... ... >> Validates the YANG modeled data in according to the . >> >>> On 6 Mar 2017, at 16:59, Robert Wilton > wrote: >>> >>> Hi William, >>> >>> I think that what yanglint is doing here is sane, i.e. I think that its= interpretation/split between imported vs implemented modules is supported = by the YANG RFC. >>> >>> However, for validation purposes it seems that it would be useful if ya= nglint had an option to assume that all imported modules are implicitly imp= lemented without requiring them to be explicitly specified. >>> >>> Thanks, >>> Rob >>> >>> On 06/03/2017 16:44, William Lupton wrote: >>>> All, >>>> >>>> This message arose from a yang-multicast@ietf.org =E2=80=9Cdraft-ietf-pim-igmp-mld-yang-02.txt: YANG compilation= isuse=E2=80=9D (sic) thread initiated by Benoit. >>>> >>>> I thought it would be useful for NETMOD to see the part of the discuss= ion that relates to implemented versus imported YANG modules. >>>> >>>> 1. Benoit Claise reported this warning: >>>> * warn: Schema node "ietf-ip:ipv4" not found (/ietf-interfaces:i= nterfaces/ietf-interfaces:interface[ietf-interfaces:name =3D current()]/iet= f-ip:ipv4) >>>> 2. Radek Krej=C4=8D=C3=AD replied: >>>> * These warnings are printed because in yanglint, until explicit= ly stated, the imported modules (such as ietf-interfaces and ietf-ip), are = supposed to be only imported, not implemented. The data nodes in imported s= chemas are not available, which is the reason of these warnings. >>>> 3. William Lupton (that=E2=80=99s me!) asked / commented: >>>> * Why are the complaints only about ip:ipv4 (etc) and not about = if:interfaces (etc), which are also referenced in the must statements? >>>> * This makes it hard for an automated tool (such as Benoit=E2=80= =99s) because it needs to know which other YANG files to process in additio= n to the =E2=80=9Cfile of interest=E2=80=9D. >>>> 4. Radek Krej=C4=8D=C3=AD replied: >>>> * According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?],= when an implemented module augments another module (ietf-interfaces), the = augmented module MUST be also implemented. So libyang automatically changes= the augmented module from imported to the implemented. The same rule appli= es also in case of referring a module in path (leafref) and by deviating a = module. But it does not apply when a module data is used in must or when co= nditions. That's the reason why it complains just about ietf-ip and not abo= ut ietf-interfaces. >>>> * YANG actually does not provide a way to specify that a particu= lar import is also expected to be implemented. Therefore, libyang needs som= e help with setting modules implemented - all the explicitly loaded modules= are supposed to be implemented, if the module is just implicitly loaded fr= om the search directory and user did not expressed that it is supposed to b= e implemented, it is kept only imported to provide groupings or type defini= tions >>>> 5. Benoit Claise asked (referring to my reference to automated tools): >>>> * Would it be possible to improve the warning (and the related t= est, by testing implemented instead of import), basically telling that the = module itself is fine? >>>> >>>> >>>> I=E2=80=99m interested to know that NETMOD thinks about this distincti= on between implemented versus imported (in the absence of any instance docu= ments). I guess my (maybe naive) view is that if all I=E2=80=99m doing is c= hecking for errors in my YANG model then I don=E2=80=99t care about this. I= f my YANG is good I want to see no warnings or errors, and if it=E2=80=99s = bad then I want to be told this (and why). >>>> >>>> Thanks, >>>> William >>>> >>>> >>>> _______________________________________________ >>>> 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 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 7 04:42:18 2017 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 68456129472 for ; Tue, 7 Mar 2017 04:42:17 -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 vG5uure5SMsg for ; Tue, 7 Mar 2017 04:42:16 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C4D8D129460 for ; Tue, 7 Mar 2017 04:42:15 -0800 (PST) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 6A5F11820044; Tue, 7 Mar 2017 13:42:53 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , Benoit Claise , NETMOD Working Group In-Reply-To: References: <3ca36636-a532-e3eb-a2eb-71ee4fd950b4@cisco.com> Date: Tue, 07 Mar 2017 13:42:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Toolchain upgraded to yangdump-pro 16.10-5 => 16.10-5.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 12:42:17 -0000 Kent Watsen writes: > Hi Benoit, > > You seem to know the ins and outs of many tools these days, maybe you > can point me in the right direction...which tool is able to validate > instance documents against YANG 1.1 modules? Yangson can validate JSON documents: https://github.com/CZ-NIC/yangson > > I've always used `yang2dsdl`, but currently it outputs "DSDL plugin > supports only YANG version 1". I considered updating the DSDL plugin to 1.1 but it turned up to be immensely difficult - it would basically require a complete rewrite. And even then, the Schematron implementation that is included in pyang distribution won't support the new XPath functions. Lada > > Kent // contributor > > > >> Dear all, >> >> yangdump-pro upgraded to 16.10-5.1 >> The stats look better: http://claise.be/IETFYANGPageCompilation.png >> See http://www.claise.be/IETFYANGPageCompilation.html for the remaining >> open issues on your YANG modules. >> Still a week to improve them. >> >> Regards, Benoit > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 7 07:42:38 2017 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 281381294FF; Tue, 7 Mar 2017 06:39:06 -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, 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 M8etuNTGaMlf; Tue, 7 Mar 2017 06:38:48 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440DB12952B; Tue, 7 Mar 2017 06:33:48 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id g10so2668959wrg.2; Tue, 07 Mar 2017 06:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=fvJrpgh8TPVxVwRCRaS8LTjVWQUxgvc7KY4wFZI9V+M=; b=ae5T2JENwyzO3UzneY3WsIi/d2U1WnZwabQIjVWjtUoXgSve55D/B4oQdyaY1ns1HN HJ4UYEal92EqYnxkMMO6qFN69IRhBFK59S+fpNYXUr38J5c+uu87/vyjBJt0Z0UdqXSt +HBxxdKFtbJs5M6bkzPg5ycLRsQy9PIbZfxk/1VBpu1A5j1ydNenx1GK1yS2lLY8OWJH cilFJ4v83wyo31K+UXpkqy4hLZeeEu36tZ7EYbt8gJv7/W2XQieSq49vvBX8GwegnIaA 6OHIfXT5ZVQwNBv9YoGuRjvYXP0vj+8aoTqdUghKHDrt6pVbJ4ikMsYoKBexjmvpvGba Ii7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=fvJrpgh8TPVxVwRCRaS8LTjVWQUxgvc7KY4wFZI9V+M=; b=j36Vc/Eb9cg+Ysjg8Vtm3tf5VZBWqe/JnsTahYJJzYioYbG0NBAzbGsskTgyff4QXu hMhaL3AeZgXpdAd+rrhSGqOQ8noL0MPjdfJDfODOBGDKms9QNaWHzTmeeEouDouEbH7O iYJz7zWV9ZfRpk19WS6afGUug2pVMMZKog0nah8RprBNb/Xq+eYPVNtE6UphResBDLqv 3CniqhAHUaHzIFRSWjzdMjR7OoY0O+Mdy2bL1h5bWVcwHfu/1qFfyXum60J4BRcK4pNa 2MyqeO1VhjqrjYYXisKV5Y8EbAcgE/0/34slGzmDbojv4CYokb/mKTKt+Q2XRqrF30yc YwNg== X-Gm-Message-State: AMke39lJ3g2OzYJbVoixw5j8oAvdxfa0l1ibu0HL04PHYy7+c47O6Oujlj5DT9h964U6QA== X-Received: by 10.223.139.196 with SMTP id w4mr570136wra.172.1488897226722; Tue, 07 Mar 2017 06:33:46 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B341B45.dip0.t-ipconnect.de. [91.52.27.69]) by smtp.gmail.com with ESMTPSA id e16sm230482wra.36.2017.03.07.06.33.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 06:33:46 -0800 (PST) From: "Mehmet Ersue" To: "'Kent Watsen'" , References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> In-Reply-To: <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> Date: Tue, 7 Mar 2017 15:33:47 +0100 Message-ID: <00f501d2974f$d4e08460$7ea18d20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBag26D4AA== Content-Language: de X-AVK-Virus-Check: AVA 25.10928;F984776D X-AVK-Spam-Check: 1; str=0001.0A0C0205.58BEC4C9.02BC,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 14:39:06 -0000 Hi Kent, I am missing two aspects in the charter. One is the short description of planned WG items setting the target. The other point is the intended status of the WG items. To me without such definition it looks kind of incomplete. Mehmet > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Friday, March 3, 2017 4:23 PM > To: netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: Re: [netmod] draft netmod charter update proposal > > > Hi NETMOD WG, > > Please find below draft-3 having the following changes: > > - s/representation/encoding/g > - s/2016/2017/ in Milestones > - moved syslog from Mar to Apr > - moved entity from Mar to Apr > > Any other comments? > > Kent > > > > > Network Modeling (NETMOD) > ------------------------- > > Charter > > Current Status: Active > > Chairs: > Lou Berger > Kent Watsen > > Operations and Management Area Directors: > Benoit Claise > Joel Jaeggli > > Operations and Management Area Advisor: > Benoit Claise > > Secretary: > Zitao (Michael) Wang > > Mailing Lists: > General Discussion: netmod@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netmod > Archive: https://mailarchive.ietf.org/arch/browse/netmod/ > > Description of Working Group: > > The Network Modeling (NETMOD) working group is responsible for the > YANG > data modeling language, and guidelines for developing YANG models. The > NETMOD working group addresses general topics related to the use of the > YANG language and YANG models, for example, the mapping of YANG > modeled > data into various encodings. Finally, the NETMOD working group > also defines core YANG models used as basic YANG building blocks, and > YANG models that do not otherwise fall under the charter of any other > IETF working group. > > The NETMOD WG is responsible for: > > a) Maintaining the data modeling language YANG. This effort entails > periodically updating the specification to address new requirements > as they arise. > > b) Maintaining the guidelines for developing YANG models. This effort > is primarily driven by updates made to the YANG specification. > > c) Maintaining a conceptual framework in which YANG models are used. > This effort entails describing the generic context that in YANG > exists and how certain YANG statements interact in that context. > An example of this is YANG's relationship with datastores. > > d) Maintaining encodings for YANG modeled data. This effort entails > updating encodings already defined by the NETMOD working (XML and > JSON) to accommodate changes to the YANG specification, and defining > new encodings that are needed, and yet do not fall under the charter > of any other active IETF working group. > > e) Maintaining YANG models used as basic YANG building blocks. This > effort entails updating existing YANG models (ietf-yang-types and > ietf-inet-types) as needed, as well as defining additional core YANG > data models when necessary. > > f) Defining and maintaining YANG models that do not fall under the > charter of any other active IETF working group. > > The NETMOD working group consults with the NETCONF working group to > ensure that new requirements are and understood and can be met by > the protocols developed within that working group (e.g., NETCONF > and RESTCONF). The NETMOD working group coordinates with other > working groups on possible extensions to YANG to address new modeling > requirements and, when needed, which group will run the process on a > specific model. > > The NETMOD working group does not serve as a review team for YANG > modules developed by other working groups. Instead, the YANG doctors, > as organized by the OPS area director responsible for network > management, will act as advisors for other working groups and provide > YANG reviews for the OPS area directors. > > Milestones: > > Done - Submit draft-ietf-netmod-rfc6087bis to IESG for publication > Mar 2017 - Submit draft-ietf-netmod-yang-model-classification to IESG > for publication > Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for publication > Apr 2017 - Submit draft-ietf-netmod-entity to IESG for publication > Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG for publication > Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for publication > Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for > publication > Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > publication > Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for > publication > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 7 07:42:58 2017 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 1B0A912966F for ; Tue, 7 Mar 2017 06:40:35 -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 cGlmSD_M2w9t for ; Tue, 7 Mar 2017 06:40:16 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A721294B8 for ; Tue, 7 Mar 2017 06:35:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 860091E5679; Tue, 7 Mar 2017 06:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id reljcTug-LnJ; Tue, 7 Mar 2017 06:35:07 -0800 (PST) Received: from [192.168.1.127] (host81-132-49-127.range81-132.btcentralplus.com [81.132.49.127]) by c8a.amsl.com (Postfix) with ESMTPSA id EA7D11E5678; Tue, 7 Mar 2017 06:35:04 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: William Lupton In-Reply-To: <0e932dec-7b45-1707-76c4-9c4f9010547e@cesnet.cz> Date: Tue, 7 Mar 2017 14:35:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <51594866-5230-4E15-A31D-DD026AC659A2@broadband-forum.org> References: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org> <9ceda4b1-6297-bab4-7c4e-da29bbea6890@cisco.com> <1808B9E6-84DC-4615-B1F8-7063709A539D@broadband-forum.org> <0e932dec-7b45-1707-76c4-9c4f9010547e@cesnet.cz> To: =?utf-8?Q?Radek_Krej=C4=8D=C3=AD?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yanglint and implemented versus imported YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 14:40:35 -0000 Inline. Thanks, W. > On 7 Mar 2017, at 09:49, Radek Krej=C4=8D=C3=AD = wrote: >=20 > Hi, > I think that the default approach should be to expect that, until = explicitly stated, the imported module is just imported, not = implemented. But it is fine to me to add an option to force the = implemented flag on all the modules. Benoit can then use the flag in his = scripts. >=20 > However, I checked RFC 7950 again, and I would like to have a feedback = from the NETMOD group to the section 7.1.5, that states that > "the importing module may: > ... > o use any node in the imported module's schema tree in "must", > "path", and "when" statements, or as the target node in "augment" > and "deviation" statements.=E2=80=9D So this was the situation in the original message, right? This warning = was being output: * warn: Schema node "ietf-ip:ipv4" not found = (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:nam= e =3D current()]/ietf-ip:ipv4) =E2=80=A6not because "ietf-ip:ipv4=E2=80=9D doesn=E2=80=99t exist, but = because the ietf-ip module was imported rather than implemented. I think you are saying that (per RFC 7950 section 7.1.5) = =E2=80=9Cietf-ip:ipv4=E2=80=9D should have been found, in which case = there wouldn=E2=80=99t have been a warning. Is that correct? > I'm interested in "must" and "when". I'm not sure why it is mentioned = here, because, in contrast to "path", "augment" and "deviation", > "when" and "must" contain XPath expression, so actually even not = defined schema node can be used in it (and this is the reason why = yanglint does not complain with error, but just with warning). Of = course, the result is then always false (ok, depending on the rest of = the expression, but it simply does not depend on the data presence). And = this is the reason to have it at least as warning, because it is usually = not the original intention of the author. >=20 > Regards, > Radek >=20 > Dne 7.3.2017 v 10:00 William Lupton napsal(a): >> Could this be the default in the first of these two cases? >>=20 >> Usage: >> yanglint [options] [-f { yang | yin | tree }] ... >> Validates the YANG module in , and all its dependencies. >>=20 >> yanglint [options] [-f { xml | json }] ... ... >> Validates the YANG modeled data in according to the = . >>=20 >>> On 6 Mar 2017, at 16:59, Robert Wilton > wrote: >>>=20 >>> Hi William, >>>=20 >>> I think that what yanglint is doing here is sane, i.e. I think that = its interpretation/split between imported vs implemented modules is = supported by the YANG RFC. >>>=20 >>> However, for validation purposes it seems that it would be useful if = yanglint had an option to assume that all imported modules are = implicitly implemented without requiring them to be explicitly = specified. >>>=20 >>> Thanks, >>> Rob >>>=20 >>> On 06/03/2017 16:44, William Lupton wrote: >>>> All, >>>>=20 >>>> This message arose from a yang-multicast@ietf.org = =E2=80=9Cdraft-ietf-pim-igmp-mld-yang-02.= txt: YANG compilation isuse=E2=80=9D (sic) thread = initiated by Benoit. >>>>=20 >>>> I thought it would be useful for NETMOD to see the part of the = discussion that relates to implemented versus imported YANG modules. >>>>=20 >>>> 1. Benoit Claise reported this warning: >>>> * warn: Schema node "ietf-ip:ipv4" not found = (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:nam= e =3D current()]/ietf-ip:ipv4) >>>> 2. Radek Krej=C4=8D=C3=AD replied: >>>> * These warnings are printed because in yanglint, until = explicitly stated, the imported modules (such as ietf-interfaces and = ietf-ip), are supposed to be only imported, not implemented. The data = nodes in imported schemas are not available, which is the reason of = these warnings. >>>> 3. William Lupton (that=E2=80=99s me!) asked / commented: >>>> * Why are the complaints only about ip:ipv4 (etc) and not = about if:interfaces (etc), which are also referenced in the must = statements? >>>> * This makes it hard for an automated tool (such as = Benoit=E2=80=99s) because it needs to know which other YANG files to = process in addition to the =E2=80=9Cfile of interest=E2=80=9D. >>>> 4. Radek Krej=C4=8D=C3=AD replied: >>>> * According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: = 5.6.5?], when an implemented module augments another module = (ietf-interfaces), the augmented module MUST be also implemented. So = libyang automatically changes the augmented module from imported to the = implemented. The same rule applies also in case of referring a module in = path (leafref) and by deviating a module. But it does not apply when a = module data is used in must or when conditions. That's the reason why it = complains just about ietf-ip and not about ietf-interfaces. >>>> * YANG actually does not provide a way to specify that a = particular import is also expected to be implemented. Therefore, libyang = needs some help with setting modules implemented - all the explicitly = loaded modules are supposed to be implemented, if the module is just = implicitly loaded from the search directory and user did not expressed = that it is supposed to be implemented, it is kept only imported to = provide groupings or type definitions >>>> 5. Benoit Claise asked (referring to my reference to automated = tools): >>>> * Would it be possible to improve the warning (and the related = test, by testing implemented instead of import), basically telling that = the module itself is fine? >>>>=20 >>>>=20 >>>> I=E2=80=99m interested to know that NETMOD thinks about this = distinction between implemented versus imported (in the absence of any = instance documents). I guess my (maybe naive) view is that if all I=E2=80=99= m doing is checking for errors in my YANG model then I don=E2=80=99t = care about this. If my YANG is good I want to see no warnings or errors, = and if it=E2=80=99s bad then I want to be told this (and why). >>>>=20 >>>> Thanks, >>>> William From rkrejci@cesnet.cz Tue Mar 7 07:14:49 2017 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 F34811294B8 for ; Tue, 7 Mar 2017 07:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afgU1Q2mRvsd for ; Tue, 7 Mar 2017 07:14:31 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D814129595 for ; Tue, 7 Mar 2017 07:13:00 -0800 (PST) Received: from [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360] (unknown [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 2076F200DF; Tue, 7 Mar 2017 16:12:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1488899578; bh=JGoFGNGlbk1Wxw1HgkdOPJmu2IlKugHMx4DKY8VwS58=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=b48HDll+ZbryyRRjnfnt98awtZ9NSiWYujHm+DgOaeRZMZJGY26LKg+3LZHVaDWNJ UWdAq4Y0ZtrCJn/Mlmoo5Y+bgjZzFuCEP5eRZcGmh14sdZZuFxSEejFBp88Rg6m4QW JqhNOCJ332xklOn5Nla2tWCZxCwbVZ5vycUdN384= To: William Lupton References: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org> <9ceda4b1-6297-bab4-7c4e-da29bbea6890@cisco.com> <1808B9E6-84DC-4615-B1F8-7063709A539D@broadband-forum.org> <0e932dec-7b45-1707-76c4-9c4f9010547e@cesnet.cz> <51594866-5230-4E15-A31D-DD026AC659A2@broadband-forum.org> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Message-ID: <29a06647-fb90-c3af-37ba-32b65f69119b@cesnet.cz> Date: Tue, 7 Mar 2017 16:12:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <51594866-5230-4E15-A31D-DD026AC659A2@broadband-forum.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] yanglint and implemented versus imported YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 15:14:49 -0000 Dne 7.3.2017 v 15:35 William Lupton napsal(a): > Inline. Thanks, W. > >> On 7 Mar 2017, at 09:49, Radek Krej=C4=8D=C3=AD wr= ote: >> >> Hi, >> I think that the default approach should be to expect that, until expl= icitly stated, the imported module is just imported, not implemented. But= it is fine to me to add an option to force the implemented flag on all t= he modules. Benoit can then use the flag in his scripts. >> >> However, I checked RFC 7950 again, and I would like to have a feedback= from the NETMOD group to the section 7.1.5, that states that >> "the importing module may: >> ... >> o use any node in the imported module's schema tree in "must", >> "path", and "when" statements, or as the target node in "augment"= >> and "deviation" statements.=E2=80=9D > So this was the situation in the original message, right? This warning = was being output: > * warn: Schema node "ietf-ip:ipv4" not found (/ietf-interfaces:interfac= es/ietf-interfaces:interface[ietf-interfaces:name =3D current()]/ietf-ip:= ipv4) > > =E2=80=A6not because "ietf-ip:ipv4=E2=80=9D doesn=E2=80=99t exist, but = because the ietf-ip module was imported rather than implemented. > > I think you are saying that (per RFC 7950 section 7.1.5) =E2=80=9Cietf-= ip:ipv4=E2=80=9D should have been found, in which case there wouldn=E2=80= =99t have been a warning. Is that correct? I'm saying that I don't understand why the "must" and "when" are mentione= d in 7.1.5, because they actually can refer to even undefined nodes - it = is not supposed to be an error. However, there will be a warning as yangl= int's hint to the user that something is weird - not necessarily with the= module itself, but maybe with a way it is used in server. yanglint's war= nings are not printed as YANG specification warnings (I don't know what s= hould be such warnings - specification just says that something is valid = or not), warnings are printed because there can be a serious issue with u= sing the module for the data instances - when/must condition will always = result to false and it's probably not what you expect. BTW, yanglint (in devel branch) is already able to make all the imported = modules implemented (option -i). But that does not help much. Respectivel= y, it helps in case of ietf-igmp-mld module. But there are other IETF mod= ules/drafts that fail with this option because they need to import multip= le revisions of the same module (not directly, but because some of the im= ported modules imports different revision of some module). And this is no= t possible in case you want all the revisions/imports to be implemented -= only single revision of a module can be implemented. Regards, Radek > >> I'm interested in "must" and "when". I'm not sure why it is mentioned = here, because, in contrast to "path", "augment" and "deviation", >> "when" and "must" contain XPath expression, so actually even not defin= ed schema node can be used in it (and this is the reason why yanglint doe= s not complain with error, but just with warning). Of course, the result = is then always false (ok, depending on the rest of the expression, but it= simply does not depend on the data presence). And this is the reason to = have it at least as warning, because it is usually not the original inten= tion of the author. >> >> Regards, >> Radek >> >> Dne 7.3.2017 v 10:00 William Lupton napsal(a): >>> Could this be the default in the first of these two cases? >>> >>> Usage: >>> yanglint [options] [-f { yang | yin | tree }] ... >>> Validates the YANG module in , and all its dependencies.= >>> >>> yanglint [options] [-f { xml | json }] ... ... >>> Validates the YANG modeled data in according to the . >>> >>>> On 6 Mar 2017, at 16:59, Robert Wilton > wrote: >>>> >>>> Hi William, >>>> >>>> I think that what yanglint is doing here is sane, i.e. I think that = its interpretation/split between imported vs implemented modules is suppo= rted by the YANG RFC. >>>> >>>> However, for validation purposes it seems that it would be useful if= yanglint had an option to assume that all imported modules are implicitl= y implemented without requiring them to be explicitly specified. >>>> >>>> Thanks, >>>> Rob >>>> >>>> On 06/03/2017 16:44, William Lupton wrote: >>>>> All, >>>>> >>>>> This message arose from a yang-multicast@ietf.org =E2=80=9Cdraft-ietf-pim-igmp-mld-yang-02.txt: YANG compil= ation isuse=E2=80=9D (sic) thread initiated by Benoit. >>>>> >>>>> I thought it would be useful for NETMOD to see the part of the disc= ussion that relates to implemented versus imported YANG modules. >>>>> >>>>> 1. Benoit Claise reported this warning: >>>>> * warn: Schema node "ietf-ip:ipv4" not found (/ietf-interfaces= :interfaces/ietf-interfaces:interface[ietf-interfaces:name =3D current()]= /ietf-ip:ipv4) >>>>> 2. Radek Krej=C4=8D=C3=AD replied: >>>>> * These warnings are printed because in yanglint, until explic= itly stated, the imported modules (such as ietf-interfaces and ietf-ip), = are supposed to be only imported, not implemented. The data nodes in impo= rted schemas are not available, which is the reason of these warnings. >>>>> 3. William Lupton (that=E2=80=99s me!) asked / commented: >>>>> * Why are the complaints only about ip:ipv4 (etc) and not abou= t if:interfaces (etc), which are also referenced in the must statements? >>>>> * This makes it hard for an automated tool (such as Benoit=E2=80= =99s) because it needs to know which other YANG files to process in addit= ion to the =E2=80=9Cfile of interest=E2=80=9D. >>>>> 4. Radek Krej=C4=8D=C3=AD replied: >>>>> * According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?= ], when an implemented module augments another module (ietf-interfaces), = the augmented module MUST be also implemented. So libyang automatically c= hanges the augmented module from imported to the implemented. The same ru= le applies also in case of referring a module in path (leafref) and by de= viating a module. But it does not apply when a module data is used in mus= t or when conditions. That's the reason why it complains just about ietf-= ip and not about ietf-interfaces. >>>>> * YANG actually does not provide a way to specify that a parti= cular import is also expected to be implemented. Therefore, libyang needs= some help with setting modules implemented - all the explicitly loaded m= odules are supposed to be implemented, if the module is just implicitly l= oaded from the search directory and user did not expressed that it is sup= posed to be implemented, it is kept only imported to provide groupings or= type definitions >>>>> 5. Benoit Claise asked (referring to my reference to automated tool= s): >>>>> * Would it be possible to improve the warning (and the related= test, by testing implemented instead of import), basically telling that = the module itself is fine? >>>>> >>>>> >>>>> I=E2=80=99m interested to know that NETMOD thinks about this distin= ction between implemented versus imported (in the absence of any instance= documents). I guess my (maybe naive) view is that if all I=E2=80=99m doi= ng is checking for errors in my YANG model then I don=E2=80=99t care abou= t this. If my YANG is good I want to see no warnings or errors, and if it= =E2=80=99s bad then I want to be told this (and why). >>>>> >>>>> Thanks, >>>>> William From nobody Tue Mar 7 08:19:03 2017 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 22E5D1295C1; Tue, 7 Mar 2017 07:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no 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 iNCz4y4YBg2m; Tue, 7 Mar 2017 07:37:29 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 EADDC12959D; Tue, 7 Mar 2017 07:35:07 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Kent Watsen'" , References: In-Reply-To: Date: Tue, 7 Mar 2017 10:30:07 -0500 Message-ID: <01a101d29757$b405beb0$1c113c10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7qE3WwCA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 15:37:31 -0000 Kent and Lou: Clarifying questions: Does c) and d) include additions to include I2RS ephemeral state as part of an I2RS control plane protocol? If not, which WG works on the I2RS ephemeral additions to Yang for control plane data stores? Sue -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Wednesday, February 22, 2017 7:25 PM To: netmod@ietf.org Cc: netmod-chairs@ietf.org Subject: [netmod] draft netmod charter update proposal Hi NETMOD WG, Please find below the draft charter update which we provided to our AD for review. Comments are welcomed. Authors, please note the milestone dates. Kent (and Lou) Network Modeling (NETMOD) ------------------------- Charter Current Status: Active Chairs: Lou Berger Kent Watsen Operations and Management Area Directors: Benoit Claise Joel Jaeggli Operations and Management Area Advisor: Benoit Claise Secretary: Zitao (Michael) Wang Mailing Lists: General Discussion: netmod@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netmod Archive: https://mailarchive.ietf.org/arch/browse/netmod/ Description of Working Group: The Network Modeling (NETMOD) working group is responsible for the YANG data modeling language, and guidelines for developing YANG models. The NETMOD working group addresses general topics related to the use of the YANG language and YANG models, for example, the mapping of YANG modeled data into various encodings. Finally, the NETMOD working group also defines core YANG models used as basic YANG building blocks, and YANG models that do not otherwise fall under the charter of any other IETF working group. The NETMOD WG is responsible for: a) Maintaining the data modeling language YANG. This effort entails periodically updating the specification to address new requirements as they arise. b) Maintaining the guidelines for developing YANG models. This effort is primarily driven by updates made to the YANG specification. c) Maintaining a conceptual framework in which YANG models are used. This effort entails describing the context that network management protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, and how certain YANG statements interact in that context. d) Maintaining encodings for YANG modeled data. This effort entails updating encodings already defined by the NETMOD working (XML and JSON) to accommodate changes to the YANG specification, and defining new encodings that are needed and yet do not fall under the charter of any other active IETF working group. e) Maintaining YANG models used as basic YANG building blocks. This effort entails updating existing YANG models (ietf-yang-types and ietf-inet-types) as needed, as well as defining additional core YANG data models when necessary. f) Defining and maintaining YANG models that do not fall under the charter of any other active IETF working group. The NETMOD working group consults with the NETCONF working group to ensure that new requirements are and understood and can be met by the protocols developed within that working group (e.g., NETCONF and RESTCONF). The NETMOD working group coordinates with other working groups on possible extensions to YANG to address new modeling requirements and, when needed, which group will run the process on a specific model. The NETMOD working group does not serve as a review team for YANG modules developed by other working groups. Instead, the YANG doctors, as organized by the OPS area director responsible for network management, will act as advisors for other working groups and provide YANG reviews for the OPS area directors. Milestones: Done - Submit draft-ietf-netmod-rfc6087bis to IESG for publication Mar 2016 - Submit draft-ietf-netmod-yang-model-classification to IESG for publication Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for publication Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for publication Mar 2017 - Submit draft-ietf-netmod-entity to IESG for publication Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for publication Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for publication Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for publication Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for publication _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 7 09:21:33 2017 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 4D5ED12953E; Tue, 7 Mar 2017 09:21:32 -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 S_ZtLw31K0_2; Tue, 7 Mar 2017 09:21:30 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 606A2129534; Tue, 7 Mar 2017 09:21:30 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id l37so6295426wrc.1; Tue, 07 Mar 2017 09:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=ELWRsjNPJXHYx1NMoUzCs/G0Ei6VRecyJYR+Cs0V410=; b=AEsm9wU4qDNvhNAan5BT0gkkHCZsFAzujtdBA9zRbFvx3hBQeUAAG+t9jgv1USaMhV ep90xNzMalKeqt2caY/8hZeKhaUz8ZBlvuJCyYr5H8k/tLoKQzctIoTY2dAFhWorS4R2 QPOx09F7ETRlr5lyTrRsQBeegCJj9d5SK9zWNvdMtGCIhp581v36X5Ae3sCPvewKsu2Z po4UmwfI70Zs5Ty6ua7rlrGDmdyan3MRDg/YYKvpCjsc5/q/IARjLJO6eKt0s9pCts6o O0tfbSDLF/er6n3UoiVSWY7T/iVgzwfxyMW+PmUgHVTXsR7mBkeCr05PgQdLFpEa8gFL gO+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=ELWRsjNPJXHYx1NMoUzCs/G0Ei6VRecyJYR+Cs0V410=; b=II0IpNAeNyakhP5nCoUKtfBScQyY84iF1zoS5UPHLAi7dD0BGV0f/SOljBh0BevPzM lDR6d4QJ5+u40Sm094V7/0vDwU5637EtyOGK5legYLPWa4LmqAxvHcfVDzqe+Dappabd L700XEkRe9WahCzFDiLJzBqK/v6XiWLJQHrBEpAWyhy6IIegO+KZVtLLq2+UrsBUX5h3 sztl63UqkmkJRYbGuB8nBN+2YNaUJ4xoCt03lSpsYkfxRhK3rL2aG3sv8kOxapTxKJYH xt6ukQwbuMyTmyKN0y2wjLBEz2hfu064vU5szp3zUSq5zkpSdyqQ7gILD2pUOVTWdZhG Xwlw== X-Gm-Message-State: AMke39kdF3GOsNCYK8YbHlBTT3MV+Df5nvNCltnzjlDNE+BAhOO3xNZi5AIIW236bU+OnQ== X-Received: by 10.223.160.101 with SMTP id l34mr1214792wrl.73.1488907288809; Tue, 07 Mar 2017 09:21:28 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B341B45.dip0.t-ipconnect.de. [91.52.27.69]) by smtp.gmail.com with ESMTPSA id u41sm790471wrc.24.2017.03.07.09.21.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 09:21:28 -0800 (PST) From: "Mehmet Ersue" To: "'Susan Hares'" , "'Kent Watsen'" , References: <01a101d29757$b405beb0$1c113c10$@ndzh.com> In-Reply-To: <01a101d29757$b405beb0$1c113c10$@ndzh.com> Date: Tue, 7 Mar 2017 18:21:27 +0100 Message-ID: <017401d29767$41970e50$c4c52af0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gIsUOtUoSYlAiA= Content-Language: de X-AVK-Virus-Check: AVA 25.10928;F984776D X-AVK-Spam-Check: 1; str=0001.0A0C0201.58BEEC18.0025,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:21:32 -0000 Hi Sue, AFAICS your question kind of mixes between "I2RS control plane protocol" and "ephemeral additions to Yang". I believe different WGs are responsible for the part they own. E.g. protocol-specific part should be done in the WG owning the protocol. Can you please differentiate in your question between the aspects below (my assumption in [ ]? a) informational concept for the DS handling [netmod] b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF) to enable the usage of DS [protocol WGs, e.g. I2RS] c) generic extensions to YANG language usable by many protocols [netmod] d) any specific YANG modules necessary for the use of DS [protocols WGs] BR, Mehmet > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Tuesday, March 7, 2017 4:30 PM > To: 'Kent Watsen' ; netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: Re: [netmod] draft netmod charter update proposal > > Kent and Lou: > > Clarifying questions: > > Does c) and d) include additions to include I2RS ephemeral state as part of > an I2RS control plane protocol? If not, which WG works on the I2RS > ephemeral additions to Yang for control plane data stores? > > Sue > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Wednesday, February 22, 2017 7:25 PM > To: netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: [netmod] draft netmod charter update proposal > > > Hi NETMOD WG, > > Please find below the draft charter update which we provided to our AD for > review. Comments are welcomed. Authors, please note the milestone > dates. > > Kent (and Lou) > > > > > Network Modeling (NETMOD) > ------------------------- > > Charter > > Current Status: Active > > Chairs: > Lou Berger > Kent Watsen > > Operations and Management Area Directors: > Benoit Claise > Joel Jaeggli > > Operations and Management Area Advisor: > Benoit Claise > > Secretary: > Zitao (Michael) Wang > > Mailing Lists: > General Discussion: netmod@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netmod > Archive: https://mailarchive.ietf.org/arch/browse/netmod/ > > Description of Working Group: > > The Network Modeling (NETMOD) working group is responsible for the > YANG > data modeling language, and guidelines for developing YANG models. The > NETMOD working group addresses general topics related to the use of the > YANG language and YANG models, for example, the mapping of YANG > modeled > data into various encodings. Finally, the NETMOD working group also > defines core YANG models used as basic YANG building blocks, and YANG > models that do not otherwise fall under the charter of any other IETF > working group. > > The NETMOD WG is responsible for: > > a) Maintaining the data modeling language YANG. This effort entails > periodically updating the specification to address new requirements > as they arise. > > b) Maintaining the guidelines for developing YANG models. This effort > is primarily driven by updates made to the YANG specification. > > c) Maintaining a conceptual framework in which YANG models are used. > This effort entails describing the context that network management > protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, and > how certain YANG statements interact in that context. > > d) Maintaining encodings for YANG modeled data. This effort entails > updating encodings already defined by the NETMOD working (XML and > JSON) to accommodate changes to the YANG specification, and defining > new encodings that are needed and yet do not fall under the charter > of any other active IETF working group. > > e) Maintaining YANG models used as basic YANG building blocks. This > effort entails updating existing YANG models (ietf-yang-types and > ietf-inet-types) as needed, as well as defining additional core YANG > data models when necessary. > > f) Defining and maintaining YANG models that do not fall under the > charter of any other active IETF working group. > > The NETMOD working group consults with the NETCONF working group to > ensure that new requirements are and understood and can be met by > the protocols developed within that working group (e.g., NETCONF > and RESTCONF). The NETMOD working group coordinates with other > working groups on possible extensions to YANG to address new modeling > requirements and, when needed, which group will run the process on a > specific model. > > The NETMOD working group does not serve as a review team for YANG > modules developed by other working groups. Instead, the YANG doctors, > as organized by the OPS area director responsible for network > management, will act as advisors for other working groups and provide > YANG reviews for the OPS area directors. > > Milestones: > > Done - Submit draft-ietf-netmod-rfc6087bis to IESG for publication > Mar 2016 - Submit draft-ietf-netmod-yang-model-classification to IESG > for publication > Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for publication > Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for publication > Mar 2017 - Submit draft-ietf-netmod-entity to IESG for publication > Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > publication > Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for publication > Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for > publication > Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for > publication > > > > _______________________________________________ > 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 Tue Mar 7 10:32:32 2017 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 4762A12956E; Tue, 7 Mar 2017 10:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no 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 g4gq8Ar9VrbQ; Tue, 7 Mar 2017 10:32:29 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 D58E8129551; Tue, 7 Mar 2017 10:32:28 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.20.38; From: "Susan Hares" To: "'Mehmet Ersue'" , "'Kent Watsen'" , References: <01a101d29757$b405beb0$1c113c10$@ndzh.com> <017401d29767$41970e50$c4c52af0$@gmail.com> In-Reply-To: <017401d29767$41970e50$c4c52af0$@gmail.com> Date: Tue, 7 Mar 2017 13:27:28 -0500 Message-ID: <00f801d29770$7a42dfa0$6ec89ee0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gIsUOtUAnaIwyihEnlqwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:32:30 -0000 Mehmet: Thank you for the excellent question clarifying my questions. My questions (b) - related to protocol extension for I2RS for RESTCONF, NETCONF or CoAP. I have removed that one. I restate my question below, and the [xx] indicates my understanding. Does c and d state the following are handled: 1) informational concepts for the DS handling - [Netmod] 2) generic extensions to Yang to describe control plane datastore yang modules - [netmod] 3) generic extensions to Yang to describe the ephemeral state in control plane yang modules - [I2RS] 4) I2RS specific extensions to support the I2RS control plane datastore's validation - [I2RS] 5) Any I2RS Yang modules- [I2RS] To provide precision on this point, I will give examples of work related to each question: 1) draft-ietf-netmod-revised-datastores-00.txt [netmod] 2) extensions to describe control plane data store yang modules: a) control plane data store definitions added to draft-ietf-netmod-yang-model-classification [netmod] b) extensions to the Yang 1.1 - to provide a syntax to describe datastores in which a module exists datastore should include syntax to identify identity and prioritization config data store. [netmod] c) extension to describe the merged tree in applied datastore and opstate datastore [netmod] d) mount extensions that allow mounting modules in different datastores 3) generic extensions to describe ephemeral state the I2RS control plane datastore [I2RS] a) extensions can define validation specific to I2RS control plane datastore. b) rpc can be used for validation of modules that seek to mounted in either the I2RS control plane datastore or the configuration data store. 4) I2RS specific extensions to support I2RS features in the I2RS control plane data store. My earlier: - is a question for NETCONF/RESTCONF, or CoAP. b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF) to enable the usage of DS - [protocol group or WG] Sue -----Original Message----- From: Mehmet Ersue [mailto:mersue@gmail.com] Sent: Tuesday, March 7, 2017 12:21 PM To: 'Susan Hares'; 'Kent Watsen'; netmod@ietf.org Cc: netmod-chairs@ietf.org Subject: RE: [netmod] draft netmod charter update proposal Hi Sue, AFAICS your question kind of mixes between "I2RS control plane protocol" and "ephemeral additions to Yang". I believe different WGs are responsible for the part they own. E.g. protocol-specific part should be done in the WG owning the protocol. Can you please differentiate in your question between the aspects below (my assumption in [ ]? a) informational concept for the DS handling [netmod] b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF) to enable the usage of DS [protocol WGs, e.g. I2RS] c) generic extensions to YANG language usable by many protocols [netmod] d) any specific YANG modules necessary for the use of DS [protocols WGs] BR, Mehmet > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Tuesday, March 7, 2017 4:30 PM > To: 'Kent Watsen' ; netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: Re: [netmod] draft netmod charter update proposal > > Kent and Lou: > > Clarifying questions: > > Does c) and d) include additions to include I2RS ephemeral state as > part of > an I2RS control plane protocol? If not, which WG works on the I2RS > ephemeral additions to Yang for control plane data stores? > > Sue > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Wednesday, February 22, 2017 7:25 PM > To: netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: [netmod] draft netmod charter update proposal > > > Hi NETMOD WG, > > Please find below the draft charter update which we provided to our AD > for review. Comments are welcomed. Authors, please note the > milestone dates. > > Kent (and Lou) > > > > > Network Modeling (NETMOD) > ------------------------- > > Charter > > Current Status: Active > > Chairs: > Lou Berger > Kent Watsen > > Operations and Management Area Directors: > Benoit Claise > Joel Jaeggli > > Operations and Management Area Advisor: > Benoit Claise > > Secretary: > Zitao (Michael) Wang > > Mailing Lists: > General Discussion: netmod@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netmod > Archive: https://mailarchive.ietf.org/arch/browse/netmod/ > > Description of Working Group: > > The Network Modeling (NETMOD) working group is responsible for the > YANG > data modeling language, and guidelines for developing YANG models. The > NETMOD working group addresses general topics related to the use of the > YANG language and YANG models, for example, the mapping of YANG > modeled > data into various encodings. Finally, the NETMOD working group also > defines core YANG models used as basic YANG building blocks, and YANG > models that do not otherwise fall under the charter of any other IETF > working group. > > The NETMOD WG is responsible for: > > a) Maintaining the data modeling language YANG. This effort entails > periodically updating the specification to address new requirements > as they arise. > > b) Maintaining the guidelines for developing YANG models. This effort > is primarily driven by updates made to the YANG specification. > > c) Maintaining a conceptual framework in which YANG models are used. > This effort entails describing the context that network management > protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, and > how certain YANG statements interact in that context. > > d) Maintaining encodings for YANG modeled data. This effort entails > updating encodings already defined by the NETMOD working (XML and > JSON) to accommodate changes to the YANG specification, and defining > new encodings that are needed and yet do not fall under the charter > of any other active IETF working group. > > e) Maintaining YANG models used as basic YANG building blocks. This > effort entails updating existing YANG models (ietf-yang-types and > ietf-inet-types) as needed, as well as defining additional core YANG > data models when necessary. > > f) Defining and maintaining YANG models that do not fall under the > charter of any other active IETF working group. > > The NETMOD working group consults with the NETCONF working group to > ensure that new requirements are and understood and can be met by > the protocols developed within that working group (e.g., NETCONF > and RESTCONF). The NETMOD working group coordinates with other > working groups on possible extensions to YANG to address new modeling > requirements and, when needed, which group will run the process on a > specific model. > > The NETMOD working group does not serve as a review team for YANG > modules developed by other working groups. Instead, the YANG doctors, > as organized by the OPS area director responsible for network > management, will act as advisors for other working groups and provide > YANG reviews for the OPS area directors. > > Milestones: > > Done - Submit draft-ietf-netmod-rfc6087bis to IESG for publication > Mar 2016 - Submit draft-ietf-netmod-yang-model-classification to IESG > for publication > Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for publication > Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for publication > Mar 2017 - Submit draft-ietf-netmod-entity to IESG for publication > Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > publication > Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for publication > Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for > publication > Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for > publication > > > > _______________________________________________ > 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 Tue Mar 7 12:26:51 2017 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 EC779129495; Tue, 7 Mar 2017 12:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 QbURCkWU2knQ; Tue, 7 Mar 2017 12:26:48 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6594129457; Tue, 7 Mar 2017 12:26:47 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id n11so14959412wma.0; Tue, 07 Mar 2017 12:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=lZ7A2/EPU5tVriFupkoSfMzxDgK3l0ggqFPSrqA3I/4=; b=Gi5Mn3x/oBdDlsT6DQGm4Vpf5Ys/f48ZH9rYsw0PZ9aChm3km3jYxiwjQN5A58ECU1 VlLTSt3Duit5YS7v4YKNRcaFUUJfx6q1ez+xwIe0lL73/YlYgxjQHAyb/T++bbmjDF3J lKDYGXDAcAA4SbITxr2YaauGXn/f/AGti1GiqNtYY5xX6XKhVe0d8dG2azsK58V/WFg+ 8uqsjWkynJnJLwwRUQUAAFC2sxzwJYwA7wlUAxcR3fCojWvY1wlbn0eSQJloRdR/VyPY GYpIxEuBvxHbE1lqAJvY6qoz8xMIfR4mjzQZhwcPMNQTnqM2uEgGI5FXLuRt9GuMIdJj 22zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=lZ7A2/EPU5tVriFupkoSfMzxDgK3l0ggqFPSrqA3I/4=; b=c/DRQusfvrc/hyM84GS1MKJmNFeYMKdJbMvWdlXEgJbNlCXia96JGOVip+0cAwSmCC Dp4W2z96RhDiG66nScdLsPLMgvECM3UTv8Stxh1G4f/ns3O8XKZZO0UCw3p0gTBkb/9U X0kHNtQ3XwFaRt73K3YBvaxrhW9dFaZDmK2oepf1ayuvUK7FigrvMZKlQCvKaKyieq4S 5WP1t2OiRLA6zL6xRqyA0+W9UTucDROzlGXg8rnxSKtzyUD6w6kbAG38ZPSdZvCDat4c dC9mVn/cPXisEQryEsTOhQB1EYKfClaGGi1YukDC8GuI8GJzrMCv4QqrZnQbBVLC5kfq xMPA== X-Gm-Message-State: AMke39muc2adFKnZ/7CUnYspQegnQoMCM0hmI5LvPtxIBCoEgyFtryL1sE0lTLxdMqciWA== X-Received: by 10.28.20.70 with SMTP id 67mr12288450wmu.86.1488918406227; Tue, 07 Mar 2017 12:26:46 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B341B45.dip0.t-ipconnect.de. [91.52.27.69]) by smtp.gmail.com with ESMTPSA id u184sm1853690wmb.29.2017.03.07.12.26.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 12:26:45 -0800 (PST) From: "Mehmet Ersue" To: "'Susan Hares'" , "'Kent Watsen'" , References: <01a101d29757$b405beb0$1c113c10$@ndzh.com> <017401d29767$41970e50$c4c52af0$@gmail.com> <00f801d29770$7a42dfa0$6ec89ee0$@ndzh.com> In-Reply-To: <00f801d29770$7a42dfa0$6ec89ee0$@ndzh.com> Date: Tue, 7 Mar 2017 21:26:46 +0100 Message-ID: <027a01d29781$24d32b40$6e7981c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gIsUOtUAnaIwygB1AGueqEEBpQA Content-Language: de X-AVK-Virus-Check: AVA 25.10928;F984776D X-AVK-Spam-Check: 1; str=0001.0A0C0206.58BF1785.008B,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 20:26:50 -0000 Sounds good as a first approximation. Though we need to discuss the details and agree. It might be useful to plan a joint session on Tue or Wed in Chicago. Cheers, Mehmet > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Tuesday, March 7, 2017 7:27 PM > To: 'Mehmet Ersue' ; 'Kent Watsen' > ; netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: RE: [netmod] draft netmod charter update proposal > > Mehmet: > > Thank you for the excellent question clarifying my questions. My questions > (b) - related to protocol extension for I2RS for RESTCONF, NETCONF or CoAP. > I have removed that one. > > I restate my question below, and the [xx] indicates my understanding. > > Does c and d state the following are handled: > 1) informational concepts for the DS handling - [Netmod] > 2) generic extensions to Yang to describe control plane datastore yang > modules - [netmod] > 3) generic extensions to Yang to describe the ephemeral state in control > plane yang modules - [I2RS] > 4) I2RS specific extensions to support the I2RS control plane datastore's > validation - [I2RS] > 5) Any I2RS Yang modules- [I2RS] > > To provide precision on this point, I will give examples of work related to > each question: > 1) draft-ietf-netmod-revised-datastores-00.txt [netmod] > 2) extensions to describe control plane data store yang modules: > a) control plane data store definitions added to draft-ietf-netmod-yang- > model-classification [netmod] > b) extensions to the Yang 1.1 - to provide a syntax to describe datastores in > which a module exists > datastore should include syntax to identify identity and prioritization > config data store. [netmod] > c) extension to describe the merged tree in applied datastore and opstate > datastore [netmod] > d) mount extensions that allow mounting modules in different datastores > > 3) generic extensions to describe ephemeral state the I2RS control plane > datastore [I2RS] > a) extensions can define validation specific to I2RS control plane > datastore. > b) rpc can be used for validation of modules > that seek to mounted in either the I2RS control plane datastore or the > configuration data store. > > 4) I2RS specific extensions to support I2RS features in the I2RS control plane > data store. > > My earlier: - is a question for NETCONF/RESTCONF, or CoAP. > b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF) > to enable the usage of DS - [protocol group or WG] > > > Sue > > > -----Original Message----- > From: Mehmet Ersue [mailto:mersue@gmail.com] > Sent: Tuesday, March 7, 2017 12:21 PM > To: 'Susan Hares'; 'Kent Watsen'; netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: RE: [netmod] draft netmod charter update proposal > > Hi Sue, > > AFAICS your question kind of mixes between "I2RS control plane protocol" > and "ephemeral additions to Yang". > I believe different WGs are responsible for the part they own. > E.g. protocol-specific part should be done in the WG owning the protocol. > > Can you please differentiate in your question between the aspects below > (my assumption in [ ]? > a) informational concept for the DS handling [netmod] > b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF) to > enable the usage of DS [protocol WGs, e.g. I2RS] > c) generic extensions to YANG language usable by many protocols [netmod] > d) any specific YANG modules necessary for the use of DS [protocols WGs] > > BR, > Mehmet > > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan > Hares > > Sent: Tuesday, March 7, 2017 4:30 PM > > To: 'Kent Watsen' ; netmod@ietf.org > > Cc: netmod-chairs@ietf.org > > Subject: Re: [netmod] draft netmod charter update proposal > > > > Kent and Lou: > > > > Clarifying questions: > > > > Does c) and d) include additions to include I2RS ephemeral state as > > part > of > > an I2RS control plane protocol? If not, which WG works on the I2RS > > ephemeral additions to Yang for control plane data stores? > > > > Sue > > > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent > Watsen > > Sent: Wednesday, February 22, 2017 7:25 PM > > To: netmod@ietf.org > > Cc: netmod-chairs@ietf.org > > Subject: [netmod] draft netmod charter update proposal > > > > > > Hi NETMOD WG, > > > > Please find below the draft charter update which we provided to our AD > > for review. Comments are welcomed. Authors, please note the > > milestone dates. > > > > Kent (and Lou) > > > > > > > > > > Network Modeling (NETMOD) > > ------------------------- > > > > Charter > > > > Current Status: Active > > > > Chairs: > > Lou Berger > > Kent Watsen > > > > Operations and Management Area Directors: > > Benoit Claise > > Joel Jaeggli > > > > Operations and Management Area Advisor: > > Benoit Claise > > > > Secretary: > > Zitao (Michael) Wang > > > > Mailing Lists: > > General Discussion: netmod@ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/netmod > > Archive: https://mailarchive.ietf.org/arch/browse/netmod/ > > > > Description of Working Group: > > > > The Network Modeling (NETMOD) working group is responsible for the > > YANG > > data modeling language, and guidelines for developing YANG models. > The > > NETMOD working group addresses general topics related to the use of > the > > YANG language and YANG models, for example, the mapping of YANG > > modeled > > data into various encodings. Finally, the NETMOD working group also > > defines core YANG models used as basic YANG building blocks, and YANG > > models that do not otherwise fall under the charter of any other IETF > > working group. > > > > The NETMOD WG is responsible for: > > > > a) Maintaining the data modeling language YANG. This effort entails > > periodically updating the specification to address new requirements > > as they arise. > > > > b) Maintaining the guidelines for developing YANG models. This effort > > is primarily driven by updates made to the YANG specification. > > > > c) Maintaining a conceptual framework in which YANG models are used. > > This effort entails describing the context that network management > > protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, and > > how certain YANG statements interact in that context. > > > > d) Maintaining encodings for YANG modeled data. This effort entails > > updating encodings already defined by the NETMOD working (XML and > > JSON) to accommodate changes to the YANG specification, and defining > > new encodings that are needed and yet do not fall under the charter > > of any other active IETF working group. > > > > e) Maintaining YANG models used as basic YANG building blocks. This > > effort entails updating existing YANG models (ietf-yang-types and > > ietf-inet-types) as needed, as well as defining additional core YANG > > data models when necessary. > > > > f) Defining and maintaining YANG models that do not fall under the > > charter of any other active IETF working group. > > > > The NETMOD working group consults with the NETCONF working group to > > ensure that new requirements are and understood and can be met by > > the protocols developed within that working group (e.g., NETCONF > > and RESTCONF). The NETMOD working group coordinates with other > > working groups on possible extensions to YANG to address new modeling > > requirements and, when needed, which group will run the process on a > > specific model. > > > > The NETMOD working group does not serve as a review team for YANG > > modules developed by other working groups. Instead, the YANG doctors, > > as organized by the OPS area director responsible for network > > management, will act as advisors for other working groups and provide > > YANG reviews for the OPS area directors. > > > > Milestones: > > > > Done - Submit draft-ietf-netmod-rfc6087bis to IESG for publication > > Mar 2016 - Submit draft-ietf-netmod-yang-model-classification to IESG > > for publication > > Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for > publication > > Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for publication > > Mar 2017 - Submit draft-ietf-netmod-entity to IESG for publication > > Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > > publication > > Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for > publication > > Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for > > publication > > Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for > > publication > > > > > > > > _______________________________________________ > > 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 Tue Mar 7 16:51:32 2017 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 B8580129471; Tue, 7 Mar 2017 16:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 q1QML7GcSkVS; Tue, 7 Mar 2017 16:51:28 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0099.outbound.protection.outlook.com [104.47.42.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEBF126579; Tue, 7 Mar 2017 16:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ggs4RJCs0IDCVR9Tq719Nl5YgUdhu3U6qBca2zhFBEY=; b=Z9jCwk2FUYHD+TetpZjhvvF+CtY8B8fiUKOzQYxH2qMkzwuyag9b13gWXv84xjJ3xPnjQE2cz5a4u4ISNWcceq9cVn5angzbXDCiB8aFLTAEL2aodvksfhsWL2mHF4gghs6QbsrezFQfHzdTT9U1cbesbdZwarYmUaNilVJi6ts= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Wed, 8 Mar 2017 00:51:25 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0961.012; Wed, 8 Mar 2017 00:51:26 +0000 From: Kent Watsen To: Mehmet Ersue , 'Susan Hares' , "netmod@ietf.org" Thread-Topic: [netmod] draft netmod charter update proposal Thread-Index: AQHSjWtMgvd1I9y/IUSjVG5c54oSBqGJlI+AgAAfG4CAABJyAIAAIVUA///2HwA= Date: Wed, 8 Mar 2017 00:51:25 +0000 Message-ID: <24CF7954-A7B3-4550-AFF7-9898EE175FA2@juniper.net> References: <01a101d29757$b405beb0$1c113c10$@ndzh.com> <017401d29767$41970e50$c4c52af0$@gmail.com> <00f801d29770$7a42dfa0$6ec89ee0$@ndzh.com> <027a01d29781$24d32b40$6e7981c0$@gmail.com> In-Reply-To: <027a01d29781$24d32b40$6e7981c0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:PGduqYjfB6hL2WOOoHiiYcUeXWZdpEwnPF15I2RmWBb8LyM1CVT+iDkv1RlOISgJvRpLPDmt23Tnltq43bJl5g54qMPQnepPWBMd3iWA/bfsYcoEu0utkVv9EnSVjSA5kmV/CTTj9S88NQtn8cYUvwbQtyN5KeA3zRRDqaJ16mCzTbX3fxV9aMkQwSTjM3qRWH6nwaNPv32xMom1RD140enwWFi56Q89yTss3YwRse7c/DFQ32SIFOoYZ8JixsiUlMo7NKRJVHFc23AK21sOd5ktycoc+SzHkI59DG+L9F6A74WLx59MWFac/wN3dOQsHaIxQBhZGc03WO6Bmz3HJA== x-ms-office365-filtering-correlation-id: 27483886-7ce3-4f2a-58c8-08d465bd3fe0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35073007944872)(138986009662008)(95692535739014)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(51444003)(377454003)(13464003)(45074003)(305945005)(6116002)(8936002)(81166006)(8676002)(102836003)(93886004)(122556002)(3660700001)(54356999)(106116001)(50986999)(3846002)(3280700002)(76176999)(2501003)(86362001)(4001350100001)(5660300001)(66066001)(345774005)(2906002)(189998001)(36756003)(7736002)(83716003)(77096006)(33656002)(6246003)(6306002)(4326008)(53546006)(82746002)(53936002)(229853002)(99286003)(25786008)(2900100001)(15650500001)(6506006)(6436002)(39060400002)(6512007)(561944003)(2950100002)(83506001)(6486002)(38730400002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5004217CBC2623459565796936D805DB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 00:51:25.9255 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netmod-chairs@ietf.org" Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 00:51:31 -0000 SGkgU3VlLA0KDQpGaXJzdCwgcGxlYXNlIGJlIGF3YXJlIHRoYXQgdGhlIG5leHQgdmVyc2lvbiBv ZiByZXZpc2VkLWRhdGFzdG9yZXMNCmRyYWZ0IGZ1cnRoZXIgZGVmaW5lcyB0aGUgY29udHJvbC1w bGFuZSBkYXRhc3RvcmUgY29uY2VwdC4gIFRoaXMNCmluY2x1ZGVzIHByb3ZpZGluZyBndWlkZWxp bmVzIHRoYXQgb3RoZXIgV0dzIGNhbiBmb2xsb3cgdG8gZGVmaW5lDQp0aGVpciBvd24gY29udHJv bC1wbGFuZSBkYXRhc3RvcmVzLCBhbmQgaW5jbHVkZXMgYW4gQXBwZW5kaXggc2VjdGlvbg0Kb3V0 bGluaW5nIHRoZSBjcmVhdGlvbiBvZiBhbiAiZXBoZW1lcmFsIiBkYXRhc3RvcmUuICBUaGUgaWRl YSBpcw0KdG8gZ2l2ZSB0aGUgSTJSUyBXRyB0aGUgYWJpbGl0eSB0byBkZWZpbmUgZGF0YXN0b3Jl KHMpIGFzIG5lZWRlZCANCihyZWFkOiBmdXR1cmUgSTJSUyBXRyBkcmFmdHMpLg0KDQpSZWdhcmRp bmc6DQoNCj4gRG9lcyBjKSBhbmQgZCkgaW5jbHVkZSBhZGRpdGlvbnMgdG8gaW5jbHVkZSBJMlJT IGVwaGVtZXJhbCBzdGF0ZQ0KPiBhcyBwYXJ0IG9mIGFuIEkyUlMgY29udHJvbCBwbGFuZSBwcm90 b2NvbD8gICBJZiBub3QsIHdoaWNoIFdHDQo+IHdvcmtzIG9uIHRoZSBJMlJTIGVwaGVtZXJhbCBh ZGRpdGlvbnMgdG8gWWFuZyBmb3IgY29udHJvbCBwbGFuZQ0KPiBkYXRhIHN0b3Jlcz8NCg0KSSBk b24ndCBmdWxseSB1bmRlcnN0YW5kIHRoZSBxdWVzdGlvbiwgYnV0IGJlbGlldmUgdGhhdCB0aGUg TkVUTU9EDQphY3Rpdml0aWVzIG5lZWRlZCB0byBzdXBwb3J0IEkyUlMgYXJlIGFsbCBjb3ZlcmVk IGJ5IGEpLCBiKSwgYW5kIGMpLg0KVGhpbmdzIHRoYXQgYmVsb25nIHRvIE5FVENPTkYgV0cgd2ls bCBpbmNsdWRlIGFueSBuZWVkZWQgY2hhbmdlcyB0bw0KcHJvdG9jb2wsIFlBTkctTGlicmFyeSwg b3IgYW55IG90aGVyIGRyYWZ0IG1haW50YWluZWQgYnkgdGhhdCBXRy4NCkV2ZXJ5dGhpbmcgZWxz ZSBnb2VzIHRvIEkyUlMuDQoNCkknbSBub3Qgc3VyZSB3aGF0IE1laG1ldCBtZWFucyBieSBhICJq b2ludCBzZXNzaW9uIiwgYnV0IEkgdGhpbmsNCnRoYXQgaXQncyB0b28gbGF0ZSB0byBhZGQgc3Vj aCBhIHNlc3Npb24gdG8gdGhlIElFVEYgQWdlbmRhIGF0IA0KdGhpcyBwb2ludC4gIFRoYXQgc2Fp ZCwgSSBwbGFuIGEgc2NoZWR1bGUgYW5vdGhlciBkYXRhc3RvcmUgDQpicmVha291dCBzZXNzaW9u IChsaWtlbHkgb24gV2VkIG1vcm5pbmcpIHRoYXQgY291bGQgYmUgdXNlZCB0bw0KZGlzY3VzcyBJ MlJTIHNvbWUsIGFuZCBJIGFsc28gcGxhbiBvbiBhdHRlbmRpbmcgdGhlIEkyUlMgbWVldGluZw0K V2VkIGFmdGVybm9vbi4gIA0KDQpLZW50DQoNCg0KLS0tLS1PUklHSU5BTCBNRVNTQUdFLS0tLS0N Cg0KU291bmRzIGdvb2QgYXMgYSBmaXJzdCBhcHByb3hpbWF0aW9uLiBUaG91Z2ggd2UgbmVlZCB0 byBkaXNjdXNzIHRoZSBkZXRhaWxzDQphbmQgYWdyZWUuDQpJdCBtaWdodCBiZSB1c2VmdWwgdG8g cGxhbiBhIGpvaW50IHNlc3Npb24gb24gVHVlIG9yIFdlZCBpbiBDaGljYWdvLg0KDQpDaGVlcnMs DQpNZWhtZXQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdXNhbiBI YXJlcyBbbWFpbHRvOnNoYXJlc0BuZHpoLmNvbV0NCj4gU2VudDogVHVlc2RheSwgTWFyY2ggNywg MjAxNyA3OjI3IFBNDQo+IFRvOiAnTWVobWV0IEVyc3VlJyA8bWVyc3VlQGdtYWlsLmNvbT47ICdL ZW50IFdhdHNlbicNCj4gPGt3YXRzZW5AanVuaXBlci5uZXQ+OyBuZXRtb2RAaWV0Zi5vcmcNCj4g Q2M6IG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtuZXRtb2RdIGRyYWZ0 IG5ldG1vZCBjaGFydGVyIHVwZGF0ZSBwcm9wb3NhbA0KPiANCj4gTWVobWV0Og0KPiANCj4gVGhh bmsgeW91IGZvciB0aGUgZXhjZWxsZW50IHF1ZXN0aW9uIGNsYXJpZnlpbmcgbXkgcXVlc3Rpb25z LiAgTXkNCnF1ZXN0aW9ucw0KPiAoYikgLSByZWxhdGVkIHRvIHByb3RvY29sIGV4dGVuc2lvbiBm b3IgSTJSUyBmb3IgUkVTVENPTkYsIE5FVENPTkYgb3INCkNvQVAuDQo+IEkgaGF2ZSByZW1vdmVk IHRoYXQgb25lLg0KPiANCj4gSSByZXN0YXRlIG15IHF1ZXN0aW9uIGJlbG93LCBhbmQgdGhlIFt4 eF0gaW5kaWNhdGVzIG15IHVuZGVyc3RhbmRpbmcuDQo+IA0KPiBEb2VzIGMgYW5kIGQgc3RhdGUg dGhlIGZvbGxvd2luZyBhcmUgaGFuZGxlZDoNCj4gMSkgaW5mb3JtYXRpb25hbCBjb25jZXB0cyBm b3IgdGhlIERTIGhhbmRsaW5nIC0gW05ldG1vZF0NCj4gMikgZ2VuZXJpYyBleHRlbnNpb25zIHRv IFlhbmcgdG8gZGVzY3JpYmUgY29udHJvbCBwbGFuZSBkYXRhc3RvcmUgeWFuZw0KPiBtb2R1bGVz IC0gW25ldG1vZF0NCj4gMykgZ2VuZXJpYyBleHRlbnNpb25zIHRvIFlhbmcgdG8gZGVzY3JpYmUg dGhlIGVwaGVtZXJhbCBzdGF0ZSBpbiBjb250cm9sDQo+IHBsYW5lIHlhbmcgbW9kdWxlcyAtIFtJ MlJTXQ0KPiA0KSBJMlJTIHNwZWNpZmljIGV4dGVuc2lvbnMgdG8gc3VwcG9ydCB0aGUgSTJSUyBj b250cm9sIHBsYW5lIGRhdGFzdG9yZSdzDQo+IHZhbGlkYXRpb24gLSBbSTJSU10NCj4gNSkgQW55 IEkyUlMgWWFuZyBtb2R1bGVzLSBbSTJSU10NCj4gDQo+IFRvIHByb3ZpZGUgcHJlY2lzaW9uIG9u IHRoaXMgcG9pbnQsIEkgd2lsbCBnaXZlIGV4YW1wbGVzIG9mIHdvcmsgcmVsYXRlZA0KdG8NCj4g ZWFjaCBxdWVzdGlvbjoNCj4gMSkgIGRyYWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jl cy0wMC50eHQgICBbbmV0bW9kXQ0KPiAyKSBleHRlbnNpb25zIHRvIGRlc2NyaWJlIGNvbnRyb2wg cGxhbmUgZGF0YSBzdG9yZSB5YW5nIG1vZHVsZXM6DQo+ICAgIGEpIGNvbnRyb2wgcGxhbmUgZGF0 YSBzdG9yZSBkZWZpbml0aW9ucyBhZGRlZCB0bw0KZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy0NCj4g bW9kZWwtY2xhc3NpZmljYXRpb24gW25ldG1vZF0NCj4gICAgYikgZXh0ZW5zaW9ucyB0byB0aGUg WWFuZyAxLjEgLSB0byBwcm92aWRlIGEgc3ludGF4IHRvIGRlc2NyaWJlDQpkYXRhc3RvcmVzIGlu DQo+IHdoaWNoIGEgbW9kdWxlIGV4aXN0cw0KPiAgICAgICAgZGF0YXN0b3JlIHNob3VsZCBpbmNs dWRlIHN5bnRheCB0byBpZGVudGlmeSBpZGVudGl0eSBhbmQNCnByaW9yaXRpemF0aW9uDQo+IGNv bmZpZyBkYXRhIHN0b3JlLiBbbmV0bW9kXQ0KPiAgICBjKSBleHRlbnNpb24gdG8gZGVzY3JpYmUg dGhlIG1lcmdlZCB0cmVlIGluIGFwcGxpZWQgZGF0YXN0b3JlIGFuZA0Kb3BzdGF0ZQ0KPiBkYXRh c3RvcmUgIFtuZXRtb2RdDQo+ICAgIGQpIG1vdW50IGV4dGVuc2lvbnMgdGhhdCBhbGxvdyBtb3Vu dGluZyBtb2R1bGVzIGluIGRpZmZlcmVudCBkYXRhc3RvcmVzDQo+IA0KPiAzKSBnZW5lcmljIGV4 dGVuc2lvbnMgdG8gZGVzY3JpYmUgZXBoZW1lcmFsIHN0YXRlIHRoZSBJMlJTIGNvbnRyb2wgcGxh bmUNCj4gZGF0YXN0b3JlICBbSTJSU10NCj4gICAgICBhKSBleHRlbnNpb25zIGNhbiBkZWZpbmUg dmFsaWRhdGlvbiBzcGVjaWZpYyB0byBJMlJTIGNvbnRyb2wgcGxhbmUNCj4gZGF0YXN0b3JlLg0K PiAgICAgIGIpIHJwYyBjYW4gYmUgdXNlZCBmb3IgdmFsaWRhdGlvbiBvZiBtb2R1bGVzDQo+ICAg ICAgICAgdGhhdCBzZWVrIHRvIG1vdW50ZWQgaW4gZWl0aGVyIHRoZSBJMlJTIGNvbnRyb2wgcGxh bmUgZGF0YXN0b3JlIG9yDQp0aGUNCj4gY29uZmlndXJhdGlvbiBkYXRhIHN0b3JlLg0KPiANCj4g NCkgSTJSUyBzcGVjaWZpYyBleHRlbnNpb25zIHRvIHN1cHBvcnQgSTJSUyBmZWF0dXJlcyBpbiB0 aGUgSTJSUyBjb250cm9sDQpwbGFuZQ0KPiBkYXRhIHN0b3JlLg0KPiANCj4gTXkgZWFybGllcjog LSBpcyBhIHF1ZXN0aW9uIGZvciBORVRDT05GL1JFU1RDT05GLCBvciBDb0FQLg0KPiBiKSBzdGFu ZGFyZCBleHRlbnNpb25zIHRvIHRoZSBwcm90b2NvbCAoZS5nLiBJMlJTIG9yIE5FVENPTkYvUkVT VENPTkYpDQo+ICAgIHRvIGVuYWJsZSB0aGUgdXNhZ2Ugb2YgRFMgLSBbcHJvdG9jb2wgZ3JvdXAg b3IgV0ddDQo+IA0KPiANCj4gU3VlDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogTWVobWV0IEVyc3VlIFttYWlsdG86bWVyc3VlQGdtYWlsLmNvbV0NCj4gU2Vu dDogVHVlc2RheSwgTWFyY2ggNywgMjAxNyAxMjoyMSBQTQ0KPiBUbzogJ1N1c2FuIEhhcmVzJzsg J0tlbnQgV2F0c2VuJzsgbmV0bW9kQGlldGYub3JnDQo+IENjOiBuZXRtb2QtY2hhaXJzQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJFOiBbbmV0bW9kXSBkcmFmdCBuZXRtb2QgY2hhcnRlciB1cGRhdGUg cHJvcG9zYWwNCj4gDQo+IEhpIFN1ZSwNCj4gDQo+IEFGQUlDUyB5b3VyIHF1ZXN0aW9uIGtpbmQg b2YgbWl4ZXMgYmV0d2VlbiAiSTJSUyBjb250cm9sIHBsYW5lIHByb3RvY29sIg0KPiBhbmQgImVw aGVtZXJhbCBhZGRpdGlvbnMgdG8gWWFuZyIuDQo+IEkgYmVsaWV2ZSBkaWZmZXJlbnQgV0dzIGFy ZSByZXNwb25zaWJsZSBmb3IgdGhlIHBhcnQgdGhleSBvd24uDQo+IEUuZy4gcHJvdG9jb2wtc3Bl Y2lmaWMgcGFydCBzaG91bGQgYmUgZG9uZSBpbiB0aGUgV0cgb3duaW5nIHRoZSBwcm90b2NvbC4N Cj4gDQo+IENhbiB5b3UgcGxlYXNlIGRpZmZlcmVudGlhdGUgaW4geW91ciBxdWVzdGlvbiBiZXR3 ZWVuIHRoZSBhc3BlY3RzIGJlbG93DQo+IChteSBhc3N1bXB0aW9uIGluIFsgXT8NCj4gYSkgaW5m b3JtYXRpb25hbCBjb25jZXB0IGZvciB0aGUgRFMgaGFuZGxpbmcgW25ldG1vZF0NCj4gYikgc3Rh bmRhcmQgZXh0ZW5zaW9ucyB0byB0aGUgcHJvdG9jb2wgKGUuZy4gSTJSUyBvciBORVRDT05GL1JF U1RDT05GKSB0bw0KPiBlbmFibGUgdGhlIHVzYWdlIG9mIERTIFtwcm90b2NvbCBXR3MsIGUuZy4g STJSU10NCj4gYykgZ2VuZXJpYyBleHRlbnNpb25zIHRvIFlBTkcgbGFuZ3VhZ2UgdXNhYmxlIGJ5 IG1hbnkgcHJvdG9jb2xzIFtuZXRtb2RdDQo+IGQpIGFueSBzcGVjaWZpYyBZQU5HIG1vZHVsZXMg bmVjZXNzYXJ5IGZvciB0aGUgdXNlIG9mIERTIFtwcm90b2NvbHMgV0dzXQ0KPiANCj4gQlIsDQo+ IE1laG1ldA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG5l dG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3VzYW4N Cj4gSGFyZXMNCj4gPiBTZW50OiBUdWVzZGF5LCBNYXJjaCA3LCAyMDE3IDQ6MzAgUE0NCj4gPiBU bzogJ0tlbnQgV2F0c2VuJyA8a3dhdHNlbkBqdW5pcGVyLm5ldD47IG5ldG1vZEBpZXRmLm9yZw0K PiA+IENjOiBuZXRtb2QtY2hhaXJzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtuZXRtb2Rd IGRyYWZ0IG5ldG1vZCBjaGFydGVyIHVwZGF0ZSBwcm9wb3NhbA0KPiA+DQo+ID4gS2VudCBhbmQg TG91Og0KPiA+DQo+ID4gQ2xhcmlmeWluZyBxdWVzdGlvbnM6DQo+ID4NCj4gPiBEb2VzIGMpIGFu ZCBkKSBpbmNsdWRlIGFkZGl0aW9ucyB0byBpbmNsdWRlIEkyUlMgZXBoZW1lcmFsIHN0YXRlIGFz DQo+ID4gcGFydA0KPiBvZg0KPiA+IGFuIEkyUlMgY29udHJvbCBwbGFuZSBwcm90b2NvbD8gICAg ICBJZiBub3QsIHdoaWNoIFdHIHdvcmtzIG9uIHRoZSBJMlJTDQo+ID4gZXBoZW1lcmFsIGFkZGl0 aW9ucyB0byBZYW5nIGZvciBjb250cm9sIHBsYW5lIGRhdGEgc3RvcmVzPw0KPiA+DQo+ID4gU3Vl DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG5ldG1vZCBb bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2VudA0KPiBXYXRz ZW4NCj4gPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDIyLCAyMDE3IDc6MjUgUE0NCj4gPiBU bzogbmV0bW9kQGlldGYub3JnDQo+ID4gQ2M6IG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmcNCj4gPiBT dWJqZWN0OiBbbmV0bW9kXSBkcmFmdCBuZXRtb2QgY2hhcnRlciB1cGRhdGUgcHJvcG9zYWwNCj4g Pg0KPiA+DQo+ID4gSGkgTkVUTU9EIFdHLA0KPiA+DQo+ID4gUGxlYXNlIGZpbmQgYmVsb3cgdGhl IGRyYWZ0IGNoYXJ0ZXIgdXBkYXRlIHdoaWNoIHdlIHByb3ZpZGVkIHRvIG91ciBBRA0KPiA+IGZv ciByZXZpZXcuICBDb21tZW50cyBhcmUgd2VsY29tZWQuICBBdXRob3JzLCBwbGVhc2Ugbm90ZSB0 aGUNCj4gPiBtaWxlc3RvbmUgZGF0ZXMuDQo+ID4NCj4gPiBLZW50IChhbmQgTG91KQ0KPiA+DQo+ ID4NCj4gPg0KPiA+DQo+ID4gTmV0d29yayBNb2RlbGluZyAoTkVUTU9EKQ0KPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+IENoYXJ0ZXINCj4gPg0KPiA+IEN1cnJlbnQgU3Rh dHVzOiBBY3RpdmUNCj4gPg0KPiA+IENoYWlyczoNCj4gPiAgICBMb3UgQmVyZ2VyIDxsYmVyZ2Vy QGxhYm4ubmV0Pg0KPiA+ICAgIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0Pg0KPiA+ DQo+ID4gT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudCBBcmVhIERpcmVjdG9yczoNCj4gPiAgICBC ZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4NCj4gPiAgICBKb2VsIEphZWdnbGkgPGpv ZWxqYUBib2d1cy5jb20+DQo+ID4NCj4gPiBPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50IEFyZWEg QWR2aXNvcjoNCj4gPiAgICBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4NCj4gPg0K PiA+IFNlY3JldGFyeToNCj4gPiAgICBaaXRhbyAoTWljaGFlbCkgV2FuZyA8d2FuZ3ppdGFvQGh1 YXdlaS5jb20+DQo+ID4NCj4gPiBNYWlsaW5nIExpc3RzOg0KPiA+ICAgIEdlbmVyYWwgRGlzY3Vz c2lvbjogbmV0bW9kQGlldGYub3JnDQo+ID4gICAgVG8gU3Vic2NyaWJlOiAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+ICAgIEFyY2hpdmU6ICAg ICAgICAgICAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9uZXRtb2Qv DQo+ID4NCj4gPiBEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwOg0KPiA+DQo+ID4gICAgVGhl IE5ldHdvcmsgTW9kZWxpbmcgKE5FVE1PRCkgd29ya2luZyBncm91cCBpcyByZXNwb25zaWJsZSBm b3IgdGhlDQo+ID4gWUFORw0KPiA+ICAgIGRhdGEgbW9kZWxpbmcgbGFuZ3VhZ2UsIGFuZCBndWlk ZWxpbmVzIGZvciBkZXZlbG9waW5nIFlBTkcgbW9kZWxzLg0KPiBUaGUNCj4gPiAgICBORVRNT0Qg d29ya2luZyBncm91cCBhZGRyZXNzZXMgZ2VuZXJhbCB0b3BpY3MgcmVsYXRlZCB0byB0aGUgdXNl IG9mDQo+IHRoZQ0KPiA+ICAgIFlBTkcgbGFuZ3VhZ2UgYW5kIFlBTkcgbW9kZWxzLCBmb3IgZXhh bXBsZSwgdGhlIG1hcHBpbmcgb2YgWUFORw0KPiA+IG1vZGVsZWQNCj4gPiAgICBkYXRhIGludG8g dmFyaW91cyBlbmNvZGluZ3MuICBGaW5hbGx5LCB0aGUgTkVUTU9EIHdvcmtpbmcgZ3JvdXAgYWxz bw0KPiA+ICAgIGRlZmluZXMgY29yZSBZQU5HIG1vZGVscyB1c2VkIGFzIGJhc2ljIFlBTkcgYnVp bGRpbmcgYmxvY2tzLCBhbmQgWUFORw0KPiA+ICAgIG1vZGVscyB0aGF0IGRvIG5vdCBvdGhlcndp c2UgZmFsbCB1bmRlciB0aGUgY2hhcnRlciBvZiBhbnkgb3RoZXIgSUVURg0KPiA+ICAgIHdvcmtp bmcgZ3JvdXAuDQo+ID4NCj4gPiBUaGUgTkVUTU9EIFdHIGlzIHJlc3BvbnNpYmxlIGZvcjoNCj4g Pg0KPiA+ICAgIGEpIE1haW50YWluaW5nIHRoZSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIFlBTkcu ICBUaGlzIGVmZm9ydCBlbnRhaWxzDQo+ID4gICAgICAgcGVyaW9kaWNhbGx5IHVwZGF0aW5nIHRo ZSBzcGVjaWZpY2F0aW9uIHRvIGFkZHJlc3MgbmV3DQpyZXF1aXJlbWVudHMNCj4gPiAgICAgICBh cyB0aGV5IGFyaXNlLg0KPiA+DQo+ID4gICAgYikgTWFpbnRhaW5pbmcgdGhlIGd1aWRlbGluZXMg Zm9yIGRldmVsb3BpbmcgWUFORyBtb2RlbHMuICBUaGlzDQplZmZvcnQNCj4gPiAgICAgICBpcyBw cmltYXJpbHkgZHJpdmVuIGJ5IHVwZGF0ZXMgbWFkZSB0byB0aGUgWUFORyBzcGVjaWZpY2F0aW9u Lg0KPiA+DQo+ID4gICAgYykgTWFpbnRhaW5pbmcgYSBjb25jZXB0dWFsIGZyYW1ld29yayBpbiB3 aGljaCBZQU5HIG1vZGVscyBhcmUgdXNlZC4NCj4gPiAgICAgICBUaGlzIGVmZm9ydCBlbnRhaWxz IGRlc2NyaWJpbmcgdGhlIGNvbnRleHQgdGhhdCBuZXR3b3JrIG1hbmFnZW1lbnQNCj4gPiAgICAg ICBwcm90b2NvbHMgKGUuZy4sIE5FVENPTkYsIFJFU1RDT05GLCBDb0FQLCBldGMuKSBvcGVyYXRl IGluLCBhbmQNCj4gPiAgICAgICBob3cgY2VydGFpbiBZQU5HIHN0YXRlbWVudHMgaW50ZXJhY3Qg aW4gdGhhdCBjb250ZXh0Lg0KPiA+DQo+ID4gICAgZCkgTWFpbnRhaW5pbmcgZW5jb2RpbmdzIGZv ciBZQU5HIG1vZGVsZWQgZGF0YS4gIFRoaXMgZWZmb3J0IGVudGFpbHMNCj4gPiAgICAgICB1cGRh dGluZyBlbmNvZGluZ3MgYWxyZWFkeSBkZWZpbmVkIGJ5IHRoZSBORVRNT0Qgd29ya2luZyAoWE1M IGFuZA0KPiA+ICAgICAgIEpTT04pIHRvIGFjY29tbW9kYXRlIGNoYW5nZXMgdG8gdGhlIFlBTkcg c3BlY2lmaWNhdGlvbiwgYW5kDQpkZWZpbmluZw0KPiA+ICAgICAgIG5ldyBlbmNvZGluZ3MgdGhh dCBhcmUgbmVlZGVkIGFuZCB5ZXQgZG8gbm90IGZhbGwgdW5kZXIgdGhlDQpjaGFydGVyDQo+ID4g ICAgICAgb2YgYW55IG90aGVyIGFjdGl2ZSBJRVRGIHdvcmtpbmcgZ3JvdXAuDQo+ID4NCj4gPiAg ICBlKSBNYWludGFpbmluZyBZQU5HIG1vZGVscyB1c2VkIGFzIGJhc2ljIFlBTkcgYnVpbGRpbmcg YmxvY2tzLiAgVGhpcw0KPiA+ICAgICAgIGVmZm9ydCBlbnRhaWxzIHVwZGF0aW5nIGV4aXN0aW5n IFlBTkcgbW9kZWxzIChpZXRmLXlhbmctdHlwZXMgYW5kDQo+ID4gICAgICAgaWV0Zi1pbmV0LXR5 cGVzKSBhcyBuZWVkZWQsIGFzIHdlbGwgYXMgZGVmaW5pbmcgYWRkaXRpb25hbCBjb3JlDQpZQU5H DQo+ID4gICAgICAgZGF0YSBtb2RlbHMgd2hlbiBuZWNlc3NhcnkuDQo+ID4NCj4gPiAgICBmKSBE ZWZpbmluZyBhbmQgbWFpbnRhaW5pbmcgWUFORyBtb2RlbHMgdGhhdCBkbyBub3QgZmFsbCB1bmRl ciB0aGUNCj4gPiAgICAgICBjaGFydGVyIG9mIGFueSBvdGhlciBhY3RpdmUgSUVURiB3b3JraW5n IGdyb3VwLg0KPiA+DQo+ID4gICAgVGhlIE5FVE1PRCB3b3JraW5nIGdyb3VwIGNvbnN1bHRzIHdp dGggdGhlIE5FVENPTkYgd29ya2luZyBncm91cCB0bw0KPiA+ICAgIGVuc3VyZSB0aGF0IG5ldyBy ZXF1aXJlbWVudHMgYXJlIGFuZCB1bmRlcnN0b29kIGFuZCBjYW4gYmUgbWV0IGJ5DQo+ID4gICAg dGhlIHByb3RvY29scyBkZXZlbG9wZWQgd2l0aGluIHRoYXQgd29ya2luZyBncm91cCAoZS5nLiwg TkVUQ09ORg0KPiA+ICAgIGFuZCBSRVNUQ09ORikuICBUaGUgTkVUTU9EIHdvcmtpbmcgZ3JvdXAg Y29vcmRpbmF0ZXMgd2l0aCBvdGhlcg0KPiA+ICAgIHdvcmtpbmcgZ3JvdXBzIG9uIHBvc3NpYmxl IGV4dGVuc2lvbnMgdG8gWUFORyB0byBhZGRyZXNzIG5ldyBtb2RlbGluZw0KPiA+ICAgIHJlcXVp cmVtZW50cyBhbmQsIHdoZW4gbmVlZGVkLCB3aGljaCBncm91cCB3aWxsIHJ1biB0aGUgcHJvY2Vz cyBvbiBhDQo+ID4gICAgc3BlY2lmaWMgbW9kZWwuDQo+ID4NCj4gPiAgICBUaGUgTkVUTU9EIHdv cmtpbmcgZ3JvdXAgZG9lcyBub3Qgc2VydmUgYXMgYSByZXZpZXcgdGVhbSBmb3IgWUFORw0KPiA+ ICAgIG1vZHVsZXMgZGV2ZWxvcGVkIGJ5IG90aGVyIHdvcmtpbmcgZ3JvdXBzLiBJbnN0ZWFkLCB0 aGUgWUFORyBkb2N0b3JzLA0KPiA+ICAgIGFzIG9yZ2FuaXplZCBieSB0aGUgT1BTIGFyZWEgZGly ZWN0b3IgcmVzcG9uc2libGUgZm9yIG5ldHdvcmsNCj4gPiAgICBtYW5hZ2VtZW50LCB3aWxsIGFj dCBhcyBhZHZpc29ycyBmb3Igb3RoZXIgd29ya2luZyBncm91cHMgYW5kIHByb3ZpZGUNCj4gPiAg ICBZQU5HIHJldmlld3MgZm9yIHRoZSBPUFMgYXJlYSBkaXJlY3RvcnMuDQo+ID4NCj4gPiBNaWxl c3RvbmVzOg0KPiA+DQo+ID4gICAgRG9uZSAgICAgLSBTdWJtaXQgZHJhZnQtaWV0Zi1uZXRtb2Qt cmZjNjA4N2JpcyB0byBJRVNHIGZvcg0KcHVibGljYXRpb24NCj4gPiAgICBNYXIgMjAxNiAtIFN1 Ym1pdCBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLW1vZGVsLWNsYXNzaWZpY2F0aW9uIHRvIElFU0cN Cj4gPiAgICAgICAgICAgICAgIGZvciBwdWJsaWNhdGlvbg0KPiA+ICAgIE1hciAyMDE2IC0gU3Vi bWl0IGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbCB0byBJRVNHIGZvcg0KPiBwdWJsaWNh dGlvbg0KPiA+ICAgIE1hciAyMDE2IC0gU3VibWl0IGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2Rl bCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbg0KPiA+ICAgIE1hciAyMDE3IC0gU3VibWl0IGRyYWZ0 LWlldGYtbmV0bW9kLWVudGl0eSB0byBJRVNHIGZvciBwdWJsaWNhdGlvbg0KPiA+ICAgIE9jdCAy MDE3IC0gU3VibWl0IGRyYWZ0LWlldGYtbmV0bW9kLWludGYtZXh0LXlhbmcgdG8gSUVTRyBmb3IN Cj4gPiAgICAgICAgICAgICAgIHB1YmxpY2F0aW9uDQo+ID4gICAgT2N0IDIwMTcgLSBTdWJtaXQg ZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50IHRvIElFU0cgZm9yDQo+IHB1YmxpY2F0aW9u DQo+ID4gICAgT2N0IDIwMTcgLSBTdWJtaXQgZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRh c3RvcmVzIHRvIElFU0cgZm9yDQo+ID4gICAgICAgICAgICAgICBwdWJsaWNhdGlvbg0KPiA+ICAg IERlYyAyMDE3IC0gU3VibWl0IGRyYWZ0LWlldGYtbmV0bW9kLXN1Yi1pbnRmLXZsYW4teWFuZyB0 byBJRVNHIGZvcg0KPiA+ICAgICAgICAgICAgICAgcHVibGljYXRpb24NCj4gPg0KPiA+DQo+ID4N Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+DQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGluZyBs aXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCj4gDQoNCg0KDQoNCg== From nobody Tue Mar 7 16:58:25 2017 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 A21F81294BB for ; Tue, 7 Mar 2017 16:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 vk3mCNMTGJWH for ; Tue, 7 Mar 2017 16:58:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 39C501294B6 for ; Tue, 7 Mar 2017 16:58:22 -0800 (PST) Received: from localhost (unknown [50.225.114.198]) by mail.tail-f.com (Postfix) with ESMTPSA id AE6301AE0332; Wed, 8 Mar 2017 01:58:20 +0100 (CET) Date: Tue, 07 Mar 2017 18:03:33 +0100 (CET) Message-Id: <20170307.180333.800041089281624577.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] RFC 7950 - Import without revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 00:58:23 -0000 Robert Wilton wrote: > in RFC 7950, The last paragraph, section 5.1.1 "Import and Include by > Revision" states: > > "If a module is not imported with a specific revision, it is undefined > which revision is used." > > But I was wondering if the above text is misleading, since section > 5.6.5: "Implementing a Module" has the following two paragraphs: > > If a server implements a module A that imports a module C without > specifying the revision date of module C and the server does not > implement C (e.g., if C only defines some typedefs), the server MUST > list module C in the "/modules-state/module" list from > "ietf-yang-library" [RFC7895 ], > and it MUST set the leaf > "conformance-type" to "import" for this module. > > If a server lists a module C in the "/modules-state/module" list from > "ietf-yang-library" and there are other modules Ms listed that import > C without specifying the revision date of module C, the server MUST > use the definitions from the most recent revision of C listed for > modules Ms. > > The reason for these rules is that clients need to be able to know > the specific data model structure and types of all leafs and > leaf-lists implemented in a server. > > This seems to imply that import without specifying the revision would > mean that the latest revision listed in ietf-yang-library must be the > one that is imported. Is that correct, or am I misinterpreting the > text? This is correct. > Hence, should the last paragraph of section 5.1.1 be deleted? No I don't think it should. From the perspective of a given module that imports another module w/o revision, it is undefined which revision is used - however in any given server the revision used is deterministic. /martin From nobody Tue Mar 7 17:07:51 2017 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 85D311294C0 for ; Tue, 7 Mar 2017 17:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 7fCOTPc_saLr for ; Tue, 7 Mar 2017 17:07:49 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B13A4129470 for ; Tue, 7 Mar 2017 17:07:49 -0800 (PST) Received: from localhost (unknown [50.225.114.198]) by mail.tail-f.com (Postfix) with ESMTPSA id DE1001AE0351; Wed, 8 Mar 2017 01:58:25 +0100 (CET) Date: Tue, 07 Mar 2017 18:56:37 +0100 (CET) Message-Id: <20170307.185637.67261051570590747.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20170303170233.GB3345@elstar.local> References: <20170303170233.GB3345@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 01:07:50 -0000 SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU+IHdyb3RlOg0KPiBPbiBGcmksIE1hciAwMywgMjAxNyBhdCAwNDo0MTo0NFBNICswMDAwLCBL ZW50IFdhdHNlbiB3cm90ZToNCj4gPiANCj4gPiBBbGwsDQo+ID4gDQo+ID4gTG91IGFuZCBJIHdl cmUgZGlzY3Vzc2luZyBob3cgaXQgc2VlbXMgdW5uZWNlc3NhcnkgdGhhdCBldmVyeSBkcmFmdA0K PiA+IGhhcyB0aGUgc2FtZSBib2lsZXJwbGF0ZSB0ZXh0IHJlZ2FyZGluZyBob3cgdG8gaW50ZXJw cmV0IHRyZWUgZGlhZ3JhbQ0KPiA+IG5vdGF0aW9ucy4gIEl0IHdvdWxkIGJlIG5pY2UgaWYgZHJh ZnRzIGNvdWxkIGluc3RlYWQganVzdCByZWZlcmVuY2UNCj4gPiBhbm90aGVyIGRyYWZ0IHRoYXQg Y29udGFpbnMgdGhpcyBpbmZvcm1hdGlvbi4gIERvZXMgdGhpcyBtYWtlIHNlbnNlPw0KPiA+IA0K PiA+IEFzc3VtaW5nIHdlJ3JlIGludGVyZXN0ZWQgaW4gaGF2aW5nIHN1Y2ggYSByZWZlcmVuY2Us IHdlIGNvdWxkIGRlZmluZQ0KPiA+IGEgbWluaS1SRkMgb3IsIHBlcmhhcHMsIGxldmVyYWdlIFNl Y3Rpb24gMyBvZiA2MDg3YmlzIChZQU5HIFRyZWUgDQo+ID4gRGlhZ3JhbXMpLiAgRWl0aGVyIHdh eSwgd2UnZCB3YW50L25lZWQgdG8gZW5zdXJlIHRoZSBpbmZvcm1hdGlvbg0KPiA+IGlzIHVwZGF0 ZWQgaW4gYSB0aW1lbHkgbWFubmVyLg0KPiA+IA0KPiA+IFR3byByZWFzb25zIGZvciB3aHkgd2Ug bWF5IG5vdCB3YW50IHRvIHB1cnN1ZSB0aGlzIGFyZToNCj4gPiAgIDEpIHdlIGNhbuKAmXQgdXBk YXRlIHRoZSByZWZlcmVuY2UgZmFzdCBlbm91Z2gNCj4gPiAgIDIpIGRyYWZ0cyBtaWdodCBhZGQg c29tZSBwcm9wcmlldGFyeSBhbm5vdGF0aW9ucw0KPiA+IA0KPiA+IElzIHRoaXMgd29ydGggcHVy c3VpbmcgYXQgYWxsPw0KPiANCj4gVGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgYmVmb3JlLiBUaGUg dHJlZSBmb3JtYXQgdGhhdCB0b29scyBnZW5lcmF0ZQ0KPiBoYXMgZXZvbHZlZCBhIGJpdCBvdmVy IHRpbWUgYW5kIHRoZSBjdXJyZW50IHNldHVwIGFsbG93cyB0byBoYXZlIHNvbWUNCj4gZXZvbHV0 aW9uLiBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBoYXZlIHJlYWNoZWQgYSBzdGF0ZSB3aGVy ZSB0aGUNCj4gZXZvbHV0aW9uIGhhcyBjb21lIHRvIHN0YW5kc3RpbGwgYW5kIHdlIGNhbiBuYWls IGEgY29tbW9uIHRyZWUgZm9ybWF0DQo+IGRvd24uDQoNCkkgZG9uJ3QgdGhpbmsgc28uICBGb3Ig ZXhhbXBsZSwgaXQgd2FzIHJlY2VudGx5IHN1Z2dlc3RlZCB0aGF0IGENCm5vdGlvbiBmb3IgIm1v dW50LXBvaW50cyIgc2hvdWxkIGJlIGRlZmluZWQuDQoNCkkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBh IGJpZyBwcm9ibGVtLg0KDQoNCi9tYXJ0aW4NCg== From nobody Tue Mar 7 17:07:55 2017 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 C254F129470 for ; Tue, 7 Mar 2017 17:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 PUR60yGzCMTG for ; Tue, 7 Mar 2017 17:07:49 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B59A71294AE for ; Tue, 7 Mar 2017 17:07:49 -0800 (PST) Received: from localhost (unknown [50.225.114.198]) by mail.tail-f.com (Postfix) with ESMTPSA id 968671AE0493; Wed, 8 Mar 2017 01:58:27 +0100 (CET) Date: Tue, 07 Mar 2017 18:59:11 +0100 (CET) Message-Id: <20170307.185911.779366639761395028.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20170303191348.GA3570@elstar.local> References: <20170303191348.GA3570@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] rfc 6087bis - stress importance of instance examples X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 01:07:51 -0000 Juergen Schoenwaelder wrote: > Hi, > > my experience is that when writing YANG modules it is tremendously > helpful to focus on the instance documents. I find it essential to > write down example snippets of instance documents to see whether they > look elegant or clumsy. This is often not easy to determine from just > reading a YANG model, in particular if groupings are involved. Examples > help so much - you can easily spot whether the usage of singular or > plural is reasonable in your names, whether you have redundancy in > your names, whether the overall organization is effective. Even better, > we have tools that can validate the examples so we can even be sure > the examples are correct. (And if you do not know whether you got > your pattern statement right, well, one way is to write examples.) > > I think we should encourage authors to write examples. +1 And also encourage authors to validate the examples using their favorite YANG instance validation tool. /martin > It will help > them to create better models and it will help reviewers tremendously > while reviewing models. Good examples will also help users to get > started. > > /js (who apparently is doing some heavy YANG reviewing work today) > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Mar 7 17:17:53 2017 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 4D5041294BB for ; Tue, 7 Mar 2017 17:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 BdXmlBoRPZlK for ; Tue, 7 Mar 2017 17:17:50 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 41EEC129470 for ; Tue, 7 Mar 2017 17:17:50 -0800 (PST) Received: from localhost (unknown [50.225.114.198]) by mail.tail-f.com (Postfix) with ESMTPSA id C2E371AE0332; Wed, 8 Mar 2017 01:58:28 +0100 (CET) Date: Tue, 07 Mar 2017 19:41:47 +0100 (CET) Message-Id: <20170307.194147.1826195488124124099.mbj@tail-f.com> To: bart.bogaert@nokia.com From: Martin Bjorklund In-Reply-To: References: <20170124.113703.2074026980970865406.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 01:17:51 -0000 "Bogaert, Bart (Nokia - BE)" wrote: > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: 24 January 2017 11:37 > To: Bogaert, Bart (Nokia - BE) > Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt > > "Bogaert, Bart (Nokia - BE)" wrote: > > One more comment: > > > > The BBF proposal defines 'contained-in' as a leafref, the current > > version of the hardware model has defined 'parent' as a string. In > > the state container parent is defined as a leafref. Parent type > > should be the same in both config and state container. > > The reason for the 'string' in the config tree is that when it is > pre-configured, it doesn't really refer to a component in the state tree. > If it eventually matches a real component, the server will instantiate an > entry in the state tree, and at this point the parent > *is* a proper reference to another component. > > Note that the underlying type is the same in both cases. > [Bart Bogaert] Having it as leafref allows to verify that the parent being > configured is actually existing in the entity model (or defined in the same > transaction). Why would we remove the modelling capability to check this > consistency? Do you mean a leafref to /hardware/component/name or /hardware-state/component/name? If we pick the former, it will not be possible to configure a component with a system controlled parent (unless you also add the system controlled parent to the configuration). If we pick the latter you will not get any validation (since it has to be require-instance false). It is fine w/ me to change the type string to a leafref of the former type. /martin From nobody Wed Mar 8 02:18:14 2017 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 5BF5F129477 for ; Wed, 8 Mar 2017 02:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWePnr7HKYxC for ; Wed, 8 Mar 2017 02:18:11 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10113.outbound.protection.outlook.com [40.107.1.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD971293D8 for ; Wed, 8 Mar 2017 02:18:10 -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; bh=5qmXMqtR8xgL9ywBZ4vcaZp2w4LRuutwWcIVk6Zd7wI=; b=Q5gx565tBlQe+ca/qkKzeBrhfjT9V+tZDHduOpgICRp6XW7SrRRUzhnnA6rvEYO4lQZM3QJPDm0DRhT1OGsqNnTrt/rK+tZAVGwidcVL8VZbAYiWPJy17COLU9oQXUaJ/b5pYjGpufIvDSGw9EsY/Bg9sQkFsqOxcyzOXNTjHSo= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0626.eurprd07.prod.outlook.com (10.160.54.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Wed, 8 Mar 2017 10:18:08 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) with mapi id 15.01.0947.020; Wed, 8 Mar 2017 10:18:08 +0000 From: "Bogaert, Bart (Nokia - BE)" To: Martin Bjorklund Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt Thread-Index: AQHSl6caLbof61hN1kCkZer1IzW2RaGKudKA Date: Wed, 8 Mar 2017 10:18:07 +0000 Message-ID: References: <20170124.113703.2074026980970865406.mbj@tail-f.com> <20170307.194147.1826195488124124099.mbj@tail-f.com> In-Reply-To: <20170307.194147.1826195488124124099.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: tail-f.com; dkim=none (message not signed) header.d=none;tail-f.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [178.117.39.114] x-ms-office365-filtering-correlation-id: 55569cde-d9fc-48a3-490c-08d4660c6a9b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM2PR07MB0626; x-microsoft-exchange-diagnostics: 1; AM2PR07MB0626; 7:D7l0ADiwUk1FyfW/5v4RHzHfMGR0MRHsThsEbOciSuPR1ldyhECy9xPU1O4LVAJcZTOKGaJhdBRTgRBaQU+HpjXGhQhIhQGRs6YNZgNAzhGDdQa2ZH8h8zY+xvuTO8CuVvlOll/S6k8PK86glCrQeiek4qRC7pFKe6v8eMmPPPu0UKw1qtpRG3fDB9qHWCiOeql2ugDTdKy8jVgw215SHns8vf0rXQJFL4pNs2ZYKHPXeoN7nrT8W2qtBE6/Kw0Aoki8IB0EJgDuiK3IZSrFj85eo8dRWJMtwLS7djlBaYvK3CFOHL2B6UMlxnnvRo1e2Qn8memzy2IWFpCV+aRJTA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:AM2PR07MB0626; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0626; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39450400003)(39410400002)(39850400002)(24454002)(229853002)(110136004)(53936002)(55016002)(99286003)(2906002)(54906002)(551934003)(561944003)(3280700002)(106116001)(3660700001)(38730400002)(2900100001)(3846002)(102836003)(9686003)(6246003)(6116002)(86362001)(230783001)(99936001)(77096006)(8676002)(74316002)(7696004)(81166006)(7736002)(6916009)(189998001)(6436002)(50986999)(54356999)(5660300001)(4326008)(76176999)(25786008)(122556002)(2950100002)(66066001)(6506006)(8936002)(33656002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0626; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0386_01D297FD.A8529470" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 10:18:07.8566 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0626 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 10:18:13 -0000 ------=_NextPart_000_0386_01D297FD.A8529470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Martin, > "Bogaert, Bart (Nokia - BE)" wrote: > > One more comment: > > > > The BBF proposal defines 'contained-in' as a leafref, the current > > version of the hardware model has defined 'parent' as a string. In > > the state container parent is defined as a leafref. Parent type > > should be the same in both config and state container. > > The reason for the 'string' in the config tree is that when it is > pre-configured, it doesn't really refer to a component in the state tree. > If it eventually matches a real component, the server will instantiate > an entry in the state tree, and at this point the parent > *is* a proper reference to another component. > > Note that the underlying type is the same in both cases. > [Bart Bogaert] Having it as leafref allows to verify that the parent > being configured is actually existing in the entity model (or defined > in the same transaction). Why would we remove the modelling > capability to check this consistency? Do you mean a leafref to /hardware/component/name or /hardware-state/component/name? [Bart Bogaert] I was referring to /hardware/component, so parent is a leafref to /hardware/component/name. In /hardware-state it is a leafref to /hardware-state/component/name If we pick the former, it will not be possible to configure a component with a system controlled parent (unless you also add the system controlled parent to the configuration). [Bart Bogaert] Is there a reason to only have this parent in the state tree and not in the config tree? If we pick the latter you will not get any validation (since it has to be require-instance false). It is fine w/ me to change the type string to a leafref of the former type. [Bart Bogaert] If we leave it as a string it would mean that an external application would have to check whether the value of the string actually corresponds to a component that should exist (in the case of a non-system-controlled parent)? Regards, Bart /martin ------=_NextPart_000_0386_01D297FD.A8529470 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMDgxMDE4MDVaMCMGCSqGSIb3DQEJBDEWBBRgmwSw IGyYOi+2D9dfS8mGZQvMOTCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBABA8/lkHGpIpvVNXiAd26B67jZ65fs+jXwy8YCuxTIFcH53Sy7iJAHHlJ1st k2teqRxrB5ySSpwXj7v6P84hVc8O8he7EWaWhyAWfI+QJtG+zYSb23AuW9tkj4NsVcadrzaLrXAx 3s6gwH8LWNmGKdbiU3AgkEsMzvlm6HElomS2Ij52kvZBZLrP4RcRyUvHCpzHR2iJWk1JwX2xvWZY H8pc79rerx015jAzg9C5wbkPtqjrHF/M6dXM9nd+vKHCifezaX48zgkzx5DIshHwGTBTuCKNWqoG JqEr7JHcyh84ROtyaomdLC+HwVznFHzNu/TMlVC/038wZ7QfT2PkKNMAAAAAAAA= ------=_NextPart_000_0386_01D297FD.A8529470-- From nobody Wed Mar 8 02:29:00 2017 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 DCB0E1270B4 for ; Wed, 8 Mar 2017 02:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Z5CRWsK8g6e5 for ; Wed, 8 Mar 2017 02:28:57 -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 914E2127071 for ; Wed, 8 Mar 2017 02:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2574; q=dns/txt; s=iport; t=1488968936; x=1490178536; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Q69NBlEjnDIk2qxPfCLMCSt9nWo54qy8djn7n/gWpPw=; b=gbiArozjedW79Sa4VdmyLp/SkL90suwUZ3d3LvAoM0n6+qf7KXijIhMt 5h/kvKVTIZcjODAELlRK9gvVPlAOqVhEYQDgwZ0SFxJI2PFEyCjQg32N1 GqzbRBTOO7r4DVKARE2bMsmhSIkxQkPl/TzSMIMk2SIoVT4QwPRZlcfA4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgBABQ3L9Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIDJ2CNbHOQWJU4gg0mhXwCgnQYAQIBAQEBAQEBayiFFgEFOEE?= =?us-ascii?q?QCw4KLlcGDQYCAQGJew6yMYp+AQEBAQEBAQEBAQEBAQEBAQEBAQEZBYZOggWCa?= =?us-ascii?q?oE8gwKFewWcM4Z2i0KKToZRizKICx84gQMiFQgXFT+EYYFzQDWKEwEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,262,1486425600"; d="scan'208";a="653104183" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2017 10:28:54 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v28ASsPa029729; Wed, 8 Mar 2017 10:28:54 GMT To: Martin Bjorklund References: <20170307.180333.800041089281624577.mbj@tail-f.com> From: Robert Wilton Message-ID: <78a2d806-d975-55aa-6c3e-48b29a3cdd3f@cisco.com> Date: Wed, 8 Mar 2017 10:28:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170307.180333.800041089281624577.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] RFC 7950 - Import without revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 10:28:59 -0000 On 07/03/2017 17:03, Martin Bjorklund wrote: > Robert Wilton wrote: >> in RFC 7950, The last paragraph, section 5.1.1 "Import and Include by >> Revision" states: >> >> "If a module is not imported with a specific revision, it is undefined >> which revision is used." >> >> But I was wondering if the above text is misleading, since section >> 5.6.5: "Implementing a Module" has the following two paragraphs: >> >> If a server implements a module A that imports a module C without >> specifying the revision date of module C and the server does not >> implement C (e.g., if C only defines some typedefs), the server MUST >> list module C in the "/modules-state/module" list from >> "ietf-yang-library" [RFC7895 ], >> and it MUST set the leaf >> "conformance-type" to "import" for this module. >> >> If a server lists a module C in the "/modules-state/module" list from >> "ietf-yang-library" and there are other modules Ms listed that import >> C without specifying the revision date of module C, the server MUST >> use the definitions from the most recent revision of C listed for >> modules Ms. >> >> The reason for these rules is that clients need to be able to know >> the specific data model structure and types of all leafs and >> leaf-lists implemented in a server. >> >> This seems to imply that import without specifying the revision would >> mean that the latest revision listed in ietf-yang-library must be the >> one that is imported. Is that correct, or am I misinterpreting the >> text? > This is correct. > >> Hence, should the last paragraph of section 5.1.1 be deleted? > No I don't think it should. From the perspective of a given module > that imports another module w/o revision, it is undefined which > revision is used - however in any given server the revision used is > deterministic. I'm not sure what it really means for a YANG module to import another module outside the context of a client/server, it seems somewhat abstract. I still think that the text is misleading (similarly for 7.1.5). I think that the draft would be clearer if these sentences were removed. I don't think that it helps to say that something is undefined when that is the implicit default of having no text there, and in all normal scenarios, the version that would be imported is actually well defined. So, I found the text to be misleading and unhelpful. Rob > > > /martin > . > From nobody Wed Mar 8 05:07:38 2017 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 E82C3129671 for ; Wed, 8 Mar 2017 05:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 VsMdr0IE-0PJ for ; Wed, 8 Mar 2017 05:07:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 789D4129670 for ; Wed, 8 Mar 2017 05:07:35 -0800 (PST) Received: from localhost (unknown [50.225.114.198]) by mail.tail-f.com (Postfix) with ESMTPSA id 121241AE030D; Wed, 8 Mar 2017 14:07:31 +0100 (CET) Date: Wed, 08 Mar 2017 14:07:30 +0100 (CET) Message-Id: <20170308.140730.165843214949076575.mbj@tail-f.com> To: bart.bogaert@nokia.com From: Martin Bjorklund In-Reply-To: References: <20170307.194147.1826195488124124099.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 13:07:37 -0000 "Bogaert, Bart (Nokia - BE)" wrote: > Hi Martin, > > > "Bogaert, Bart (Nokia - BE)" wrote: > > > One more comment: > > > > > > The BBF proposal defines 'contained-in' as a leafref, the current > > > version of the hardware model has defined 'parent' as a string. In > > > the state container parent is defined as a leafref. Parent type > > > should be the same in both config and state container. > > > > The reason for the 'string' in the config tree is that when it is > > pre-configured, it doesn't really refer to a component in the state tree. > > If it eventually matches a real component, the server will instantiate > > an entry in the state tree, and at this point the parent > > *is* a proper reference to another component. > > > > Note that the underlying type is the same in both cases. > > [Bart Bogaert] Having it as leafref allows to verify that the parent > > being configured is actually existing in the entity model (or defined > > in the same transaction). Why would we remove the modelling > > capability to check this consistency? > > Do you mean a leafref to /hardware/component/name or > /hardware-state/component/name? > [Bart Bogaert] I was referring to /hardware/component, so parent is a > leafref to /hardware/component/name. In /hardware-state it is a leafref to > /hardware-state/component/name Ok. > If we pick the former, it will not be possible to configure a component with > a system controlled parent (unless you also add the system controlled parent > to the configuration). > [Bart Bogaert] Is there a reason to only have this parent in the state tree > and not in the config tree? I am not sure I understand the question. Suppose the config tree is empty, and the system boots and populates the state tree with all detected harwdare. Next, a client would like to pre-provision a module in a chassis that exists in state. If the leafref is to the config tree, the client would have to create both the chassis and the module in the config tree, since the leafef would otherwise fail to validate. > If we pick the latter you will not get any validation (since it has to be > require-instance false). > > It is fine w/ me to change the type string to a leafref of the former type. Correction: I am fine with changing the string to a leafref to state. > [Bart Bogaert] If we leave it as a string it would mean that an external > application would have to check whether the value of the string actually > corresponds to a component that should exist (in the case of a > non-system-controlled parent)? So are you ok with a leafref to state? /martin From nobody Wed Mar 8 06:06:29 2017 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 E13911295E5 for ; Wed, 8 Mar 2017 06:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 ZWn91dncjhhi for ; Wed, 8 Mar 2017 06:06:26 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0133.outbound.protection.outlook.com [104.47.36.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B7C12941D for ; Wed, 8 Mar 2017 06:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j+khKxqV3eON/BoaswM9/JrifNroOYxi1yJA/ZFQXPY=; b=PdEyPqv5LtmHYMvWTLdikqHhEEay+ZINbk6CTpoHahWARyZv+ni/2+WII/yxaHxKMbJ6UdYMRMiAZzf5rNKwKz8IN96kWzOORwrKBKaRj3uxIGuwA+AlhTSpO0Be7kh/1/QUdQmVD+thKey84kFDZcXDbh9zv0QmJS5XtSX/Q3M= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Wed, 8 Mar 2017 14:06:25 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0961.012; Wed, 8 Mar 2017 14:06:25 +0000 From: Kent Watsen To: Martin Bjorklund , "bart.bogaert@nokia.com" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt Thread-Index: AQHSdVe2myZjLkxL00qutsYEnuL9EKFFz1wAgAAVRICAAYXIAIAABoKAgAABC4CAQohOgIABBZyAgAAvUwD//7ykAA== Date: Wed, 8 Mar 2017 14:06:25 +0000 Message-ID: <620E45FE-90AA-4BF4-8C22-A128D1748205@juniper.net> References: <20170307.194147.1826195488124124099.mbj@tail-f.com> <20170308.140730.165843214949076575.mbj@tail-f.com> In-Reply-To: <20170308.140730.165843214949076575.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: tail-f.com; dkim=none (message not signed) header.d=none;tail-f.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:6W/mE/H5zkKW+mdzDYSdwvHCZzJGoNo1n7LAEHWIqN8WwK9gAlc2LlqntaUJp8QIGW3qRKLRPoJoRaae93J2gtSsSYpAaMl94JDpk6Dj4H8uCow6NMpvHX0kR+FJ6nEK8MKyaxL3xdxttBCBB8KVfqvSpMlWwRRzTlmv+t6buFZFw/AOCkrHE3dkXYfMSaCFSOE0l60jsa48sQjG1703UoEpDCFu0pl/3RSrBZN0RnSCGH5mF7XhWOM2HrjEA0kOMtTPYWwBtZHY7tWbc6yCdnXJncpsvpLq73FK/rLV50Ad3q5B/M2Xj/eJpNv6RUzFpWRBzHZg/Mg14tOZAC3BPQ== x-ms-office365-filtering-correlation-id: fa5c16a0-c098-4d3c-8d4a-08d4662c4ef9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123558025)(20161123564025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39840400002)(39410400002)(39850400002)(305945005)(6116002)(102836003)(8676002)(122556002)(93886004)(8936002)(81166006)(54356999)(50986999)(106116001)(3846002)(3280700002)(33656002)(76176999)(2501003)(86362001)(5660300001)(4001350100001)(3660700001)(66066001)(2906002)(230783001)(83716003)(36756003)(7736002)(6246003)(189998001)(77096006)(53936002)(229853002)(99286003)(4326008)(82746002)(25786008)(6512007)(6436002)(2950100002)(6506006)(6486002)(83506001)(38730400002)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <509352C10FFA3942AA4A797DAE4E11FE@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 14:06:25.4560 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 14:06:28 -0000 DQoNCj4+IElmIHdlIHBpY2sgdGhlIGZvcm1lciwgaXQgd2lsbCBub3QgYmUgcG9zc2libGUgdG8g Y29uZmlndXJlIGEgY29tcG9uZW50IHdpdGgNCj4+IGEgc3lzdGVtIGNvbnRyb2xsZWQgcGFyZW50 ICh1bmxlc3MgeW91IGFsc28gYWRkIHRoZSBzeXN0ZW0gY29udHJvbGxlZCBwYXJlbnQNCj4+IHRv IHRoZSBjb25maWd1cmF0aW9uKS4NCj4+IFtCYXJ0IEJvZ2FlcnRdIElzIHRoZXJlIGEgcmVhc29u IHRvIG9ubHkgaGF2ZSB0aGlzIHBhcmVudCBpbiB0aGUgc3RhdGUgdHJlZQ0KPj4gYW5kIG5vdCBp biB0aGUgY29uZmlnIHRyZWU/DQo+DQo+IEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBx dWVzdGlvbi4gIFN1cHBvc2UgdGhlIGNvbmZpZyB0cmVlIGlzDQo+IGVtcHR5LCBhbmQgdGhlIHN5 c3RlbSBib290cyBhbmQgcG9wdWxhdGVzIHRoZSBzdGF0ZSB0cmVlIHdpdGggYWxsDQo+IGRldGVj dGVkIGhhcndkYXJlLiAgTmV4dCwgYSBjbGllbnQgd291bGQgbGlrZSB0byBwcmUtcHJvdmlzaW9u IGENCj4gbW9kdWxlIGluIGEgY2hhc3NpcyB0aGF0IGV4aXN0cyBpbiBzdGF0ZS4gIElmIHRoZSBs ZWFmcmVmIGlzIHRvIHRoZQ0KPiBjb25maWcgdHJlZSwgdGhlIGNsaWVudCB3b3VsZCBoYXZlIHRv IGNyZWF0ZSBib3RoIHRoZSBjaGFzc2lzIGFuZCB0aGUNCj4gbW9kdWxlIGluIHRoZSBjb25maWcg dHJlZSwgc2luY2UgdGhlIGxlYWZlZiB3b3VsZCBvdGhlcndpc2UgZmFpbCB0bw0KPiB2YWxpZGF0 ZS4NCj4NCj4+IElmIHdlIHBpY2sgdGhlIGxhdHRlciB5b3Ugd2lsbCBub3QgZ2V0IGFueSB2YWxp ZGF0aW9uIChzaW5jZSBpdCBoYXMgdG8gYmUNCj4+IHJlcXVpcmUtaW5zdGFuY2UgZmFsc2UpLg0K Pj4gDQo+PiBJdCBpcyBmaW5lIHcvIG1lIHRvIGNoYW5nZSB0aGUgdHlwZSBzdHJpbmcgdG8gYSBs ZWFmcmVmIG9mIHRoZSBmb3JtZXIgdHlwZS4NCj4NCj4gQ29ycmVjdGlvbjogSSBhbSBmaW5lIHdp dGggY2hhbmdpbmcgdGhlIHN0cmluZyB0byBhIGxlYWZyZWYgdG8gc3RhdGUuDQoNClRoaXMgY29u dmVyc2F0aW9uIHNlZW1zIHRvIG1pcnJvcnMgdGhlIHdlIGhhZCByZWdhcmRpbmcgdGhlIGkycnMg DQp0b3BvbG9nb3kgbW9kZWwsIHdoZXJlIHdlIGxhbmRlZCBvbiBhIGxlYWZyZWYgaW4gJ3J1bm5p bmcnIGNvdWxkDQpwb2ludCB0byBhIGNvbmZpZyB0cnVlIG5vZGUgaW4gJ29wZXJhdGlvbmFsLXN0 YXRlJywgYXMgdG8gYXBwbHkgDQpjb25maWd1cmF0aW9uIHRvLCBmb3IgaW5zdGFuY2UsIHN5c3Rl bS1kaXNjb3ZlcmVkIHVuZGVybGF5cy4uLm9yDQpkbyBJIG1pc3VuZGVyc3RhbmQsIGlzIHRoZSBp bnRlbnRpb24gaGVyZSBmb3IgdGhlIGxlYWZyZWYgdG8gcG9pbnQNCnRvIGEgY29uZmlnIGZhbHNl IG5vZGU/DQoNCktlbnQgIC8vIGNvbnRyaWJ1dG9yDQoNCg0KDQoNCg== From nobody Wed Mar 8 06:12:53 2017 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 E9C24129698 for ; Wed, 8 Mar 2017 06:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 xdo_sjfmVkXV for ; Wed, 8 Mar 2017 06:12:50 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5DD129472 for ; Wed, 8 Mar 2017 06:12:50 -0800 (PST) Received: from localhost (unknown [50.225.114.198]) by mail.tail-f.com (Postfix) with ESMTPSA id 400C81AE046D; Wed, 8 Mar 2017 15:12:46 +0100 (CET) Date: Wed, 08 Mar 2017 15:12:37 +0100 (CET) Message-Id: <20170308.151237.472853610844348877.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <620E45FE-90AA-4BF4-8C22-A128D1748205@juniper.net> References: <20170308.140730.165843214949076575.mbj@tail-f.com> <620E45FE-90AA-4BF4-8C22-A128D1748205@juniper.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 14:12:52 -0000 Kent Watsen wrote: > > > >> If we pick the former, it will not be possible to configure a component with > >> a system controlled parent (unless you also add the system controlled parent > >> to the configuration). > >> [Bart Bogaert] Is there a reason to only have this parent in the state tree > >> and not in the config tree? > > > > I am not sure I understand the question. Suppose the config tree is > > empty, and the system boots and populates the state tree with all > > detected harwdare. Next, a client would like to pre-provision a > > module in a chassis that exists in state. If the leafref is to the > > config tree, the client would have to create both the chassis and the > > module in the config tree, since the leafef would otherwise fail to > > validate. > > > >> If we pick the latter you will not get any validation (since it has to be > >> require-instance false). > >> > >> It is fine w/ me to change the type string to a leafref of the former type. > > > > Correction: I am fine with changing the string to a leafref to state. > > This conversation seems to mirrors the we had regarding the i2rs > topologoy model Yes. >, where we landed on a leafref in 'running' could > point to a config true node in 'operational-state' With 'require-instance false'? That doesn't really mean that it points to anything in operational state. > as to apply > configuration to, for instance, system-discovered underlays...or > do I misunderstand, is the intention here for the leafref to point > to a config false node? Yes. If we had revised datastores, this model would probably look different. /martin From nobody Wed Mar 8 06:48:21 2017 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 8730B1296B8 for ; Wed, 8 Mar 2017 06:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-_evK_eF2lT for ; Wed, 8 Mar 2017 06:48:18 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00138.outbound.protection.outlook.com [40.107.0.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D174712965E for ; Wed, 8 Mar 2017 06:48:17 -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; bh=M5+yWSkWHeLMPdAAGxjtMTLi2XtRFuFbhwi/1gYt3XU=; b=nfJiT3/ngGA5nT0VSDACmJOOO1N71OpCtEfFaHJN8YA3cG6zkdYvCfp3mMz7Y6TUkBhtQ1Khb7qmJp63zey/DQ0iHJ7g/iQA98sEIedJERN1pu1VXzQvOSCxsmKiRrARIS289i1KztkeDMr7o3h7Ea+NO7buZ96sxMvAoHDpEr4= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0628.eurprd07.prod.outlook.com (10.160.54.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Wed, 8 Mar 2017 14:48:15 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) with mapi id 15.01.0947.020; Wed, 8 Mar 2017 14:48:15 +0000 From: "Bogaert, Bart (Nokia - BE)" To: Martin Bjorklund Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt Thread-Index: AQHSl6caLbof61hN1kCkZer1IzW2RaGKudKAgAAwwgCAAAUDYA== Date: Wed, 8 Mar 2017 14:48:15 +0000 Message-ID: References: <20170307.194147.1826195488124124099.mbj@tail-f.com> <20170308.140730.165843214949076575.mbj@tail-f.com> In-Reply-To: <20170308.140730.165843214949076575.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: tail-f.com; dkim=none (message not signed) header.d=none;tail-f.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [178.117.39.114] x-ms-office365-filtering-correlation-id: 39eaa508-0676-48e5-b9c1-08d466322738 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM2PR07MB0628; x-microsoft-exchange-diagnostics: 1; AM2PR07MB0628; 7:OuG8RbPiUKB5IEMpmH3Bz1B95HYI4r3u/vMfNaOUEaHaZxi9VI4GTVChEkk9LoKNy1OYrMosEPeX0zP6jBeEFqlCdeC6gSnJfB16xbPaLUjIiswaImjWmuhV0DVTgqIRB+K5Vq0NdxWetfcXz/lFJElGIR0yX23n0br35OodDzd7y8iVH4Zbvzhyhc9+QaQ4KWasJTQKrQYuoGY9lA3ZGqcWwIh8vjEbVoLd8BlVtkcItLiY+pPDhxs+5yFE020wpBboChs/Cf+EDSz5xIWC7X9vhKibqHGdq8dkAD2SykGu96Xi+TkU20N56nmMxXWwNkyiS6wVFm0gyZ6gasR1pA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:AM2PR07MB0628; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0628; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39850400002)(39450400003)(39410400002)(86362001)(8936002)(106116001)(2950100002)(2906002)(6506006)(74316002)(3660700001)(77096006)(99936001)(33656002)(50986999)(7736002)(6436002)(229853002)(102836003)(3846002)(66066001)(6116002)(81166006)(55016002)(25786008)(8676002)(54906002)(54356999)(9686003)(38730400002)(5660300001)(76176999)(3280700002)(230783001)(99286003)(2900100001)(4326008)(189998001)(7696004)(122556002)(53936002)(110136004)(93886004)(6246003)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0628; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_048B_01D29823.6523D490" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 14:48:15.7259 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0628 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 14:48:19 -0000 ------=_NextPart_000_048B_01D29823.6523D490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, > If we pick the former, it will not be possible to configure a > component with a system controlled parent (unless you also add the > system controlled parent to the configuration). > [Bart Bogaert] Is there a reason to only have this parent in the state > tree and not in the config tree? I am not sure I understand the question. Suppose the config tree is empty, and the system boots and populates the state tree with all detected harwdare. Next, a client would like to pre-provision a module in a chassis that exists in state. If the leafref is to the config tree, the client would have to create both the chassis and the module in the config tree, since the leafef would otherwise fail to validate. [Bart Bogaert] Ok, so you are looking for a solution that refers to an entry in the state tree. I always thought that one could not refer from config to state but it seems I misunderstood this since this is exactly what you are proposing. > If we pick the latter you will not get any validation (since it has to > be require-instance false). > > It is fine w/ me to change the type string to a leafref of the former type. Correction: I am fine with changing the string to a leafref to state. > [Bart Bogaert] If we leave it as a string it would mean that an > external application would have to check whether the value of the > string actually corresponds to a component that should exist (in the > case of a non-system-controlled parent)? So are you ok with a leafref to state? [Bart Bogaert] Since that seems possible this would solve the problem. I'm checking this with our people. Regards, Bart /martin ------=_NextPart_000_048B_01D29823.6523D490 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMDgxNDQ4MTNaMCMGCSqGSIb3DQEJBDEWBBTwARNg 45sASXo9le4yUCopKcCtGTCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAGoqudNddjbfO/8ZhF0v+O5mXeWGqscaPHcU4V21UhoA9WiFo6SfF3P3ctYa suq0m1w8tcR8GNuScUH01LFTXipYk/YV6gV62YUVU5TIayP6E55opUt+X30KNbgw+ysdh6minjkC PCOoGz320Ai9YMIkEj7Pi7tzvk1HnEJM6IhCvicfJ2c3IU1ZfCrQFu7FJqdOlTgEFjFsxc6eYFxn USN0+ntqB1FM8Srw9dPG/3lPh4N88FDtWP41Dk6Zd4zAPsfqFMN68k1dNC+U2Lb0iA4n8Q1rWu9k fotXyfwHAW4tKw8sOxoUYDHISBzx0pfcjvLQtL0IcsyJBL0aqVGc6ucAAAAAAAA= ------=_NextPart_000_048B_01D29823.6523D490-- From nobody Wed Mar 8 06:51:34 2017 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 DAA80129416 for ; Wed, 8 Mar 2017 06:51:32 -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, RP_MATCHES_RCVD=-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 YJtXar9LMMBW for ; Wed, 8 Mar 2017 06:51:30 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5F3129496 for ; Wed, 8 Mar 2017 06:51:30 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DCA8A16AA; Wed, 8 Mar 2017 15:51:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yUNyPYSCuQz0; Wed, 8 Mar 2017 15:51:28 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Mar 2017 15:51:28 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72AF120039; Wed, 8 Mar 2017 15:51:28 +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 92HJ6XWK8Qz4; Wed, 8 Mar 2017 15:51:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDABE2002C; Wed, 8 Mar 2017 15:51:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6EE123E9BD89; Wed, 8 Mar 2017 15:51:33 +0100 (CET) Date: Wed, 8 Mar 2017 15:51:33 +0100 From: Juergen Schoenwaelder To: "Bogaert, Bart (Nokia - BE)" Message-ID: <20170308145133.GC9814@elstar.local> Mail-Followup-To: "Bogaert, Bart (Nokia - BE)" , Martin Bjorklund , "netmod@ietf.org" References: <20170307.194147.1826195488124124099.mbj@tail-f.com> <20170308.140730.165843214949076575.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 14:51:33 -0000 On Wed, Mar 08, 2017 at 02:48:15PM +0000, Bogaert, Bart (Nokia - BE) wrote: > Hi, > > > If we pick the former, it will not be possible to configure a > > component with a system controlled parent (unless you also add the > > system controlled parent to the configuration). > > [Bart Bogaert] Is there a reason to only have this parent in the state > > tree and not in the config tree? > > I am not sure I understand the question. Suppose the config tree is empty, > and the system boots and populates the state tree with all detected > harwdare. Next, a client would like to pre-provision a module in a chassis > that exists in state. If the leafref is to the config tree, the client > would have to create both the chassis and the module in the config tree, > since the leafef would otherwise fail to validate. > > [Bart Bogaert] Ok, so you are looking for a solution that refers to an entry > in the state tree. I always thought that one could not refer from config to > state but it seems I misunderstood this since this is exactly what you are > proposing. > > > If we pick the latter you will not get any validation (since it has to > > be require-instance false). > > > > It is fine w/ me to change the type string to a leafref of the former > type. > > Correction: I am fine with changing the string to a leafref to state. > > > [Bart Bogaert] If we leave it as a string it would mean that an > > external application would have to check whether the value of the > > string actually corresponds to a component that should exist (in the > > case of a non-system-controlled parent)? > > So are you ok with a leafref to state? > > [Bart Bogaert] Since that seems possible this would solve the problem. I'm > checking this with our people. Are you discussing leafref to a config false node with require instance false? I am not sure this is valid YANG. /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 Mar 8 07:00:12 2017 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 95AF51294B9 for ; Wed, 8 Mar 2017 07:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYjRsr5LJZ7I for ; Wed, 8 Mar 2017 07:00:10 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40096.outbound.protection.outlook.com [40.107.4.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825B0129496 for ; Wed, 8 Mar 2017 07:00:09 -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; bh=f6nmLGMXQM4+XrbOQdKD4Hd3fndwq4Bcho8SzML9Wx4=; b=TeD6tadxouB9LJdU1fpAZCiMmBqd1zSDMJ+oe/kIIey9tcaYqYa7U9PYIJSN9BC6zlh3sgW1yGuJ1cVrzRB33RaHGcD1XPT2XOJTzE60SFp4scJw4m9jjDjaX1jyHY8GCcExx4dE4oSZguoCp5im6JFM1sKcqi3nUnsAh3t7m2U= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0626.eurprd07.prod.outlook.com (10.160.54.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Wed, 8 Mar 2017 15:00:07 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) with mapi id 15.01.0947.020; Wed, 8 Mar 2017 15:00:07 +0000 From: "Bogaert, Bart (Nokia - BE)" To: Juergen Schoenwaelder Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt Thread-Index: AQHSl6caLbof61hN1kCkZer1IzW2RaGKudKAgAAwwgCAAAUDYIAAGA+AgAACGVA= Date: Wed, 8 Mar 2017 15:00:07 +0000 Message-ID: References: <20170307.194147.1826195488124124099.mbj@tail-f.com> <20170308.140730.165843214949076575.mbj@tail-f.com> <20170308145133.GC9814@elstar.local> In-Reply-To: <20170308145133.GC9814@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=nokia.com; x-originating-ip: [178.117.39.114] x-ms-office365-filtering-correlation-id: 2ab7e25c-6700-44f6-7360-08d46633cf44 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM2PR07MB0626; x-microsoft-exchange-diagnostics: 1; AM2PR07MB0626; 7:O+4KwLmL8GZ69cK8FJviSJlI/HYZKm/481zfr3CialZlZEPWmumqj6TZSYHWIrht7zSCMbficKK4Q5LGMY3piKz5+6NYsZwCrcON8n/SgvnxH3yljkL2J2EbaduVM/xWt7U4me23Sei4fe7XlF3UJwxCpHdsb/ZMpLDOCSXP6dy9uD6EZOufcq0Qgmi4jychi1FpLixIks2BCEH/BsfsngRHCjSEo3GAW3FeH346I9kCfOMGob54+sLRdGW3UvIR8IHA+Az51bqc0QnKkzQmogrrKrewPLk3DlXedR6vy3UGQTJ4axqEzL2px3WBsodFP39iC+zAQ5ClVKOw+0Yygw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:AM2PR07MB0626; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0626; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39850400002)(39860400002)(39840400002)(24454002)(74316002)(7736002)(81166006)(7696004)(99936001)(230783001)(8676002)(77096006)(8936002)(93886004)(6506006)(33656002)(305945005)(189998001)(50986999)(2950100002)(122556002)(25786008)(66066001)(6436002)(5660300001)(76176999)(54356999)(4326008)(54906002)(2906002)(53936002)(55016002)(229853002)(110136004)(99286003)(3846002)(102836003)(6306002)(6246003)(6116002)(86362001)(9686003)(3280700002)(106116001)(3660700001)(2900100001)(38730400002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0626; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0490_01D29825.0C02FCE0" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 15:00:07.0786 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0626 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:00:11 -0000 ------=_NextPart_000_0490_01D29825.0C02FCE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Mar 08, 2017 at 02:48:15PM +0000, Bogaert, Bart (Nokia - BE) wrote: > Hi, > > > If we pick the former, it will not be possible to configure a > > component with a system controlled parent (unless you also add the > > system controlled parent to the configuration). > > [Bart Bogaert] Is there a reason to only have this parent in the > > state tree and not in the config tree? > > I am not sure I understand the question. Suppose the config tree is > empty, and the system boots and populates the state tree with all > detected harwdare. Next, a client would like to pre-provision a > module in a chassis that exists in state. If the leafref is to the > config tree, the client would have to create both the chassis and the > module in the config tree, since the leafef would otherwise fail to validate. > > [Bart Bogaert] Ok, so you are looking for a solution that refers to an > entry in the state tree. I always thought that one could not refer > from config to state but it seems I misunderstood this since this is > exactly what you are proposing. > > > If we pick the latter you will not get any validation (since it has > > to be require-instance false). > > > > It is fine w/ me to change the type string to a leafref of the > > former > type. > > Correction: I am fine with changing the string to a leafref to state. > > > [Bart Bogaert] If we leave it as a string it would mean that an > > external application would have to check whether the value of the > > string actually corresponds to a component that should exist (in the > > case of a non-system-controlled parent)? > > So are you ok with a leafref to state? > > [Bart Bogaert] Since that seems possible this would solve the problem. > I'm checking this with our people. Are you discussing leafref to a config false node with require instance false? I am not sure this is valid YANG. [Bart Bogaert] Well this is what I was thinking too but this was suggested by Martin. Regards, Bart /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 ------=_NextPart_000_0490_01D29825.0C02FCE0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMDgxNTAwMDJaMCMGCSqGSIb3DQEJBDEWBBTX9CYd bEDkehaVxfWje5h2yGZ0DTCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBACwvMbm8askN04yODj1rhbZmVZc1pZMJysJMEgwFB0ZZSwIW41oVPeD7SrvA vZYiYGnWF4KJ3HCrf7TzlXJxUyVab+yRUNFQtehTjzWWS2Pu4jmdWaPllrqR9uA1WG8AQO7MMeE8 wwKNiDqBontD4a8noS2ToalWX26E3+oN3NVdEr8k8/BPiUAHiIMJ+xwLJ5GnrZteJf7MHNDUtWW9 qHV0sOtslX+pW03ENx/CVkRWE3oz/I8hDMFfiQ3RCMVu5NwnyyOV8iORwEUWB0aiLbk+tJM1gMbH I7nopHZwq9dugOQ4u+FG4wWWXx/pEF0xZzY8D4nqtI0ds6YhNQ1EUtEAAAAAAAA= ------=_NextPart_000_0490_01D29825.0C02FCE0-- From nobody Wed Mar 8 07:05:13 2017 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 62506129401 for ; Wed, 8 Mar 2017 07:05:12 -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 KKgt661WJuoI for ; Wed, 8 Mar 2017 07:05:10 -0800 (PST) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A351294B9 for ; Wed, 8 Mar 2017 07:05:10 -0800 (PST) Received: from [::1] (port=56996) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1cld9J-0002uD-Ra; Wed, 08 Mar 2017 18:05:09 +0300 From: Lou Berger To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> Message-ID: <82703e36-26f9-d459-c36a-c274861c5386@labn.net> Date: Wed, 8 Mar 2017 10:05:07 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170307.185637.67261051570590747.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:05:12 -0000 Martin, Juergen, On March 7, 2017 8:08:26 PM Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Fri, Mar 03, 2017 at 04:41:44PM +0000, Kent Watsen wrote: >> > >> > All, >> > >> > Lou and I were discussing how it seems unnecessary that every draft >> > has the same boilerplate text regarding how to interpret tree diagram >> > notations. It would be nice if drafts could instead just reference >> > another draft that contains this information. Does this make sense? >> > >> > Assuming we're interested in having such a reference, we could define >> > a mini-RFC or, perhaps, leverage Section 3 of 6087bis (YANG Tree >> > Diagrams). Either way, we'd want/need to ensure the information >> > is updated in a timely manner. >> > >> > Two reasons for why we may not want to pursue this are: >> > 1) we can’t update the reference fast enough >> > 2) drafts might add some proprietary annotations >> > >> > Is this worth pursuing at all? >> >> This has been discussed before. The tree format that tools generate >> has evolved a bit over time and the current setup allows to have some >> evolution. The question is whether we have reached a state where the >> evolution has come to standstill and we can nail a common tree format >> down. I don't see that as the question at all - the issue for me is needing to parse each document to see if and how it differs from the norm and then figuring out if the differences are (a) a bug, (b) limited to the specific document, (c) something that is a basic change that should impact tools (i.e., pyang) and other documents. > > I don't think so. For example, it was recently suggested that a > notion for "mount-points" should be defined. > Yes, and it is our (Martin, Lada and my) conversation in that context that prompted this discussion. > I don't think this is a big problem. Again, I do see this as an issue worth solving and am appreciative that 6087bis is available to easily provide a stable reference until such time as an update/replacement is needed. Lou > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 8 07:25:53 2017 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 71A8E1296E7 for ; Wed, 8 Mar 2017 07:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 omzBrx_Q-XOm for ; Wed, 8 Mar 2017 07:25:50 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E510612966B for ; Wed, 8 Mar 2017 07:25:49 -0800 (PST) Received: from localhost (unknown [128.107.241.170]) by mail.tail-f.com (Postfix) with ESMTPSA id BE2671AE046D; Wed, 8 Mar 2017 16:25:47 +0100 (CET) Date: Wed, 08 Mar 2017 16:25:42 +0100 (CET) Message-Id: <20170308.162542.2034349701486649544.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20170308145133.GC9814@elstar.local> References: <20170308.140730.165843214949076575.mbj@tail-f.com> <20170308145133.GC9814@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:25:51 -0000 Juergen Schoenwaelder wrote: > On Wed, Mar 08, 2017 at 02:48:15PM +0000, Bogaert, Bart (Nokia - BE) wrote: > > Hi, > > > > > If we pick the former, it will not be possible to configure a > > > component with a system controlled parent (unless you also add the > > > system controlled parent to the configuration). > > > [Bart Bogaert] Is there a reason to only have this parent in the state > > > tree and not in the config tree? > > > > I am not sure I understand the question. Suppose the config tree is empty, > > and the system boots and populates the state tree with all detected > > harwdare. Next, a client would like to pre-provision a module in a chassis > > that exists in state. If the leafref is to the config tree, the client > > would have to create both the chassis and the module in the config tree, > > since the leafef would otherwise fail to validate. > > > > [Bart Bogaert] Ok, so you are looking for a solution that refers to an entry > > in the state tree. I always thought that one could not refer from config to > > state but it seems I misunderstood this since this is exactly what you are > > proposing. > > > > > If we pick the latter you will not get any validation (since it has to > > > be require-instance false). > > > > > > It is fine w/ me to change the type string to a leafref of the former > > type. > > > > Correction: I am fine with changing the string to a leafref to state. > > > > > [Bart Bogaert] If we leave it as a string it would mean that an > > > external application would have to check whether the value of the > > > string actually corresponds to a component that should exist (in the > > > case of a non-system-controlled parent)? > > > > So are you ok with a leafref to state? > > > > [Bart Bogaert] Since that seems possible this would solve the problem. I'm > > checking this with our people. > > Are you discussing leafref to a config false node with require > instance false? Yes. > I am not sure this is valid YANG. It is valid, section 9.9 on leafref says: If the referring node represents configuration data and the "require-instance" property (Section 9.9.3) is "true", the referred node MUST also represent configuration. /martin From nobody Wed Mar 8 07:28:25 2017 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 9F6C71296E8 for ; Wed, 8 Mar 2017 07:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 Kqyp0LtkxlJG for ; Wed, 8 Mar 2017 07:28:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 084161296E7 for ; Wed, 8 Mar 2017 07:28:22 -0800 (PST) Received: from localhost (unknown [128.107.241.170]) by mail.tail-f.com (Postfix) with ESMTPSA id C679C1AE046D; Wed, 8 Mar 2017 16:28:20 +0100 (CET) Date: Wed, 08 Mar 2017 16:28:19 +0100 (CET) Message-Id: <20170308.162819.1904846774500859732.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <78a2d806-d975-55aa-6c3e-48b29a3cdd3f@cisco.com> References: <20170307.180333.800041089281624577.mbj@tail-f.com> <78a2d806-d975-55aa-6c3e-48b29a3cdd3f@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] RFC 7950 - Import without revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:28:23 -0000 Robert Wilton wrote: > > > On 07/03/2017 17:03, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> in RFC 7950, The last paragraph, section 5.1.1 "Import and Include by > >> Revision" states: > >> > >> "If a module is not imported with a specific revision, it is undefined > >> which revision is used." > >> > >> But I was wondering if the above text is misleading, since section > >> 5.6.5: "Implementing a Module" has the following two paragraphs: > >> > >> If a server implements a module A that imports a module C without > >> specifying the revision date of module C and the server does not > >> implement C (e.g., if C only defines some typedefs), the server MUST > >> list module C in the "/modules-state/module" list from > >> "ietf-yang-library" [RFC7895 ], > >> and it MUST set the leaf > >> "conformance-type" to "import" for this module. > >> > >> If a server lists a module C in the "/modules-state/module" list from > >> "ietf-yang-library" and there are other modules Ms listed that import > >> C without specifying the revision date of module C, the server MUST > >> use the definitions from the most recent revision of C listed for > >> modules Ms. > >> > >> The reason for these rules is that clients need to be able to know > >> the specific data model structure and types of all leafs and > >> leaf-lists implemented in a server. > >> > >> This seems to imply that import without specifying the revision would > >> mean that the latest revision listed in ietf-yang-library must be the > >> one that is imported. Is that correct, or am I misinterpreting the > >> text? > > This is correct. > > > >> Hence, should the last paragraph of section 5.1.1 be deleted? > > No I don't think it should. From the perspective of a given module > > that imports another module w/o revision, it is undefined which > > revision is used - however in any given server the revision used is > > deterministic. > I'm not sure what it really means for a YANG module to import another > module outside the context of a client/server, it seems somewhat > abstract. It just means that the importing module has access to defintions in the imported module. /martin From nobody Wed Mar 8 07:32:36 2017 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 7C8B9129535; Wed, 8 Mar 2017 07:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 7kGaqtoXh45l; Wed, 8 Mar 2017 07:32:33 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 ECFD21296FA; Wed, 8 Mar 2017 07:32:19 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Kent Watsen'" , "'Mehmet Ersue'" , References: <01a101d29757$b405beb0$1c113c10$@ndzh.com> <017401d29767$41970e50$c4c52af0$@gmail.com> <00f801d29770$7a42dfa0$6ec89ee0$@ndzh.com> <027a01d29781$24d32b40$6e7981c0$@gmail.com> <24CF7954-A7B3-4550-AFF7-9898EE175FA2@juniper.net> In-Reply-To: <24CF7954-A7B3-4550-AFF7-9898EE175FA2@juniper.net> Date: Wed, 8 Mar 2017 10:27:05 -0500 Message-ID: <012301d29820$76fcf370$64f6da50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gIsUOtUAnaIwygB1AGuegIZIUmAAZiY54ug57cuAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 15:32:35 -0000 Kent:=20 Would it be possible to publish a version of this draft by Thursday so = that the I2RS drafts with changes can align with this new version of the = revised-datastores draft?=20 Sue=20 -----Original Message----- From: Kent Watsen [mailto:kwatsen@juniper.net]=20 Sent: Tuesday, March 7, 2017 7:51 PM To: Mehmet Ersue; 'Susan Hares'; netmod@ietf.org Cc: netmod-chairs@ietf.org Subject: Re: [netmod] draft netmod charter update proposal Hi Sue, First, please be aware that the next version of revised-datastores draft = further defines the control-plane datastore concept. This includes = providing guidelines that other WGs can follow to define their own = control-plane datastores, and includes an Appendix section outlining the = creation of an "ephemeral" datastore. The idea is to give the I2RS WG = the ability to define datastore(s) as needed (read: future I2RS WG drafts). Regarding: > Does c) and d) include additions to include I2RS ephemeral state > as part of an I2RS control plane protocol? If not, which WG > works on the I2RS ephemeral additions to Yang for control plane data=20 > stores? I don't fully understand the question, but believe that the NETMOD = activities needed to support I2RS are all covered by a), b), and c). Things that belong to NETCONF WG will include any needed changes to = protocol, YANG-Library, or any other draft maintained by that WG. Everything else goes to I2RS. I'm not sure what Mehmet means by a "joint session", but I think that = it's too late to add such a session to the IETF Agenda at this point. = That said, I plan a schedule another datastore breakout session (likely = on Wed morning) that could be used to discuss I2RS some, and I also plan = on attending the I2RS meeting Wed afternoon. =20 Kent -----ORIGINAL MESSAGE----- Sounds good as a first approximation. Though we need to discuss the = details and agree. It might be useful to plan a joint session on Tue or Wed in Chicago. Cheers, Mehmet > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Tuesday, March 7, 2017 7:27 PM > To: 'Mehmet Ersue' ; 'Kent Watsen' > ; netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: RE: [netmod] draft netmod charter update proposal >=20 > Mehmet: >=20 > Thank you for the excellent question clarifying my questions. My questions > (b) - related to protocol extension for I2RS for RESTCONF, NETCONF or CoAP. > I have removed that one. >=20 > I restate my question below, and the [xx] indicates my understanding. >=20 > Does c and d state the following are handled: > 1) informational concepts for the DS handling - [Netmod] > 2) generic extensions to Yang to describe control plane datastore yang = > modules - [netmod] > 3) generic extensions to Yang to describe the ephemeral state in=20 > control plane yang modules - [I2RS] > 4) I2RS specific extensions to support the I2RS control plane=20 > datastore's validation - [I2RS] > 5) Any I2RS Yang modules- [I2RS] >=20 > To provide precision on this point, I will give examples of work=20 > related to > each question: > 1) draft-ietf-netmod-revised-datastores-00.txt [netmod] > 2) extensions to describe control plane data store yang modules: > a) control plane data store definitions added to draft-ietf-netmod-yang- > model-classification [netmod] > b) extensions to the Yang 1.1 - to provide a syntax to describe datastores in > which a module exists > datastore should include syntax to identify identity and prioritization > config data store. [netmod] > c) extension to describe the merged tree in applied datastore and opstate > datastore [netmod] > d) mount extensions that allow mounting modules in different=20 > datastores >=20 > 3) generic extensions to describe ephemeral state the I2RS control=20 > plane datastore [I2RS] > a) extensions can define validation specific to I2RS control=20 > plane datastore. > b) rpc can be used for validation of modules > that seek to mounted in either the I2RS control plane=20 > datastore or the > configuration data store. >=20 > 4) I2RS specific extensions to support I2RS features in the I2RS=20 > control plane > data store. >=20 > My earlier: - is a question for NETCONF/RESTCONF, or CoAP. > b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF) > to enable the usage of DS - [protocol group or WG] >=20 >=20 > Sue >=20 >=20 > -----Original Message----- > From: Mehmet Ersue [mailto:mersue@gmail.com] > Sent: Tuesday, March 7, 2017 12:21 PM > To: 'Susan Hares'; 'Kent Watsen'; netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: RE: [netmod] draft netmod charter update proposal >=20 > Hi Sue, >=20 > AFAICS your question kind of mixes between "I2RS control plane = protocol" > and "ephemeral additions to Yang". > I believe different WGs are responsible for the part they own. > E.g. protocol-specific part should be done in the WG owning the = protocol. >=20 > Can you please differentiate in your question between the aspects=20 > below (my assumption in [ ]? > a) informational concept for the DS handling [netmod] > b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF) = > to enable the usage of DS [protocol WGs, e.g. I2RS] > c) generic extensions to YANG language usable by many protocols=20 > [netmod] > d) any specific YANG modules necessary for the use of DS [protocols=20 > WGs] >=20 > BR, > Mehmet >=20 > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan > Hares > > Sent: Tuesday, March 7, 2017 4:30 PM > > To: 'Kent Watsen' ; netmod@ietf.org > > Cc: netmod-chairs@ietf.org > > Subject: Re: [netmod] draft netmod charter update proposal > > > > Kent and Lou: > > > > Clarifying questions: > > > > Does c) and d) include additions to include I2RS ephemeral state as=20 > > part > of > > an I2RS control plane protocol? If not, which WG works on the = I2RS > > ephemeral additions to Yang for control plane data stores? > > > > Sue > > > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent > Watsen > > Sent: Wednesday, February 22, 2017 7:25 PM > > To: netmod@ietf.org > > Cc: netmod-chairs@ietf.org > > Subject: [netmod] draft netmod charter update proposal > > > > > > Hi NETMOD WG, > > > > Please find below the draft charter update which we provided to our=20 > > AD for review. Comments are welcomed. Authors, please note the=20 > > milestone dates. > > > > Kent (and Lou) > > > > > > > > > > Network Modeling (NETMOD) > > ------------------------- > > > > Charter > > > > Current Status: Active > > > > Chairs: > > Lou Berger > > Kent Watsen > > > > Operations and Management Area Directors: > > Benoit Claise > > Joel Jaeggli > > > > Operations and Management Area Advisor: > > Benoit Claise > > > > Secretary: > > Zitao (Michael) Wang > > > > Mailing Lists: > > General Discussion: netmod@ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/netmod > > Archive: = https://mailarchive.ietf.org/arch/browse/netmod/ > > > > Description of Working Group: > > > > The Network Modeling (NETMOD) working group is responsible for=20 > > the YANG > > data modeling language, and guidelines for developing YANG = models. > The > > NETMOD working group addresses general topics related to the use=20 > > of > the > > YANG language and YANG models, for example, the mapping of YANG=20 > > modeled > > data into various encodings. Finally, the NETMOD working group = also > > defines core YANG models used as basic YANG building blocks, and = YANG > > models that do not otherwise fall under the charter of any other = IETF > > working group. > > > > The NETMOD WG is responsible for: > > > > a) Maintaining the data modeling language YANG. This effort = entails > > periodically updating the specification to address new requirements > > as they arise. > > > > b) Maintaining the guidelines for developing YANG models. This effort > > is primarily driven by updates made to the YANG specification. > > > > c) Maintaining a conceptual framework in which YANG models are = used. > > This effort entails describing the context that network = management > > protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, = and > > how certain YANG statements interact in that context. > > > > d) Maintaining encodings for YANG modeled data. This effort = entails > > updating encodings already defined by the NETMOD working (XML = and > > JSON) to accommodate changes to the YANG specification, and defining > > new encodings that are needed and yet do not fall under the charter > > of any other active IETF working group. > > > > e) Maintaining YANG models used as basic YANG building blocks. = This > > effort entails updating existing YANG models (ietf-yang-types = and > > ietf-inet-types) as needed, as well as defining additional=20 > > core YANG > > data models when necessary. > > > > f) Defining and maintaining YANG models that do not fall under = the > > charter of any other active IETF working group. > > > > The NETMOD working group consults with the NETCONF working group = to > > ensure that new requirements are and understood and can be met by > > the protocols developed within that working group (e.g., NETCONF > > and RESTCONF). The NETMOD working group coordinates with other > > working groups on possible extensions to YANG to address new = modeling > > requirements and, when needed, which group will run the process = on a > > specific model. > > > > The NETMOD working group does not serve as a review team for YANG > > modules developed by other working groups. Instead, the YANG = doctors, > > as organized by the OPS area director responsible for network > > management, will act as advisors for other working groups and = provide > > YANG reviews for the OPS area directors. > > > > Milestones: > > > > Done - Submit draft-ietf-netmod-rfc6087bis to IESG for publication > > Mar 2016 - Submit draft-ietf-netmod-yang-model-classification to = IESG > > for publication > > Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for > publication > > Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for = publication > > Mar 2017 - Submit draft-ietf-netmod-entity to IESG for = publication > > Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > > publication > > Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for > publication > > Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG = for > > publication > > Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG = for > > publication > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Wed Mar 8 08:00:52 2017 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 2885E129451; Wed, 8 Mar 2017 08:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hKArw5WhIqr; Wed, 8 Mar 2017 08:00:48 -0800 (PST) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 1BAD9126CD8; Wed, 8 Mar 2017 08:00:48 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id u108so26437740wrb.3; Wed, 08 Mar 2017 08:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=mRdwMfC6Qg/HBxBzjBrGSpW0GYjQ6xrnsZgcVoMwS8w=; b=oWMGfD7lnVBLebWttXquiFGj66v5d4E93B9mJFdKxa94OcTTNXr8eOdFGQ7Q3FgC+v 9AiqKCvSWipdVP8HGl4WKi2zFW3p/bhnP6zgX6fsGJIE5a9Ples/VEj4/Mi8US7dUn1P aiCrhEHKIFs3IYj+t0cmK06TTApgkjdYW15rO3ZvCx7TAf7wBh+KbNTL0fCM6KvhPhOb vYaLbs9WJop+CIWfHwwbP6K/3kfha8HmRCWbcEV47LMzdi3w93UYBsPsJ7Zgj83MZItF sRNN6dMrayRsN1JwBD4EflFxMb5/dn25qjJciwI5ZxQzT6EYSdfvTLD0Yy6quMRrvi9Q 68aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=mRdwMfC6Qg/HBxBzjBrGSpW0GYjQ6xrnsZgcVoMwS8w=; b=TKbfLi9ur6xbL1LO1LjOtW6ORaPDlVy8AdgXAHtWKLaDPn2BKFF7ynjAzLmk5lyAj7 1BITdJCYBRzNeBNcgYQibpHMgx9SYJp80OHhujkDYEN4MN4qggY0y7heXbHHQQ+c0plL JtugMl72wpi/zO4qLbg+Kp3d1as2PC3vWvoZdv0JqQVx4lfC88g48pSkdvFOi6dg4DIC F0A/Y35XRnTJ4SVdVX+lmIcJ+JshvQ/3FS6UocgHPQlIvdgdunbBYFc67a7obM/ZbUSp Hq/LAQ5MHooA4QwTP1bem1kxIo/OpDcFnRGWbBzFi7M0hIMUQ/W/j4DT2/bL/j/ccMH+ cEXQ== X-Gm-Message-State: AMke39lRNmohIOXyjy79PcfJXCNMhacLAZ/Lq59mad2ACZvFp9yz8MCKLbtlz1lbpphLHw== X-Received: by 10.223.135.85 with SMTP id 21mr6028433wrz.93.1488988846406; Wed, 08 Mar 2017 08:00:46 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B34156F.dip0.t-ipconnect.de. [91.52.21.111]) by smtp.gmail.com with ESMTPSA id 36sm4724085wrz.8.2017.03.08.08.00.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Mar 2017 08:00:45 -0800 (PST) From: "Mehmet Ersue" To: "'Kent Watsen'" , "'Susan Hares'" , References: <01a101d29757$b405beb0$1c113c10$@ndzh.com> <017401d29767$41970e50$c4c52af0$@gmail.com> <00f801d29770$7a42dfa0$6ec89ee0$@ndzh.com> <027a01d29781$24d32b40$6e7981c0$@gmail.com> <24CF7954-A7B3-4550-AFF7-9898EE175FA2@juniper.net> In-Reply-To: <24CF7954-A7B3-4550-AFF7-9898EE175FA2@juniper.net> Date: Wed, 8 Mar 2017 17:00:46 +0100 Message-ID: <013901d29825$264ae4a0$72e0ade0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gIsUOtUAnaIwygB1AGuegIZIUmAAZiY54ug58BO0A== Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0208.58C02AAD.0164,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 16:00:51 -0000 What I meant with joint session can be achieved with a (e.g. 20-30min) = time-slot in NETMOD or NETCONF session on Tuesday where we invite I2RS = people to attend. We can discuss the charter details and agree "all = together" on the plan and work split. Does this make sense? Mehmet > -----Original Message----- > From: Kent Watsen [mailto:kwatsen@juniper.net] > Sent: Wednesday, March 8, 2017 1:51 AM > To: Mehmet Ersue ; 'Susan Hares' > ; netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: Re: [netmod] draft netmod charter update proposal >=20 > Hi Sue, >=20 > First, please be aware that the next version of revised-datastores = draft > further defines the control-plane datastore concept. This includes = providing > guidelines that other WGs can follow to define their own control-plane > datastores, and includes an Appendix section outlining the creation of = an > "ephemeral" datastore. The idea is to give the I2RS WG the ability to = define > datastore(s) as needed > (read: future I2RS WG drafts). >=20 > Regarding: >=20 > > Does c) and d) include additions to include I2RS ephemeral state > > as part of an I2RS control plane protocol? If not, which WG > > works on the I2RS ephemeral additions to Yang for control plane data > > stores? >=20 > I don't fully understand the question, but believe that the NETMOD = activities > needed to support I2RS are all covered by a), b), and c). > Things that belong to NETCONF WG will include any needed changes to > protocol, YANG-Library, or any other draft maintained by that WG. > Everything else goes to I2RS. >=20 > I'm not sure what Mehmet means by a "joint session", but I think that = it's too > late to add such a session to the IETF Agenda at this point. That = said, I plan a > schedule another datastore breakout session (likely on Wed morning) = that > could be used to discuss I2RS some, and I also plan on attending the = I2RS > meeting Wed afternoon. >=20 > Kent >=20 >=20 > -----ORIGINAL MESSAGE----- >=20 > Sounds good as a first approximation. Though we need to discuss the = details > and agree. > It might be useful to plan a joint session on Tue or Wed in Chicago. >=20 > Cheers, > Mehmet >=20 > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com] > > Sent: Tuesday, March 7, 2017 7:27 PM > > To: 'Mehmet Ersue' ; 'Kent Watsen' > > ; netmod@ietf.org > > Cc: netmod-chairs@ietf.org > > Subject: RE: [netmod] draft netmod charter update proposal > > > > Mehmet: > > > > Thank you for the excellent question clarifying my questions. My > questions > > (b) - related to protocol extension for I2RS for RESTCONF, NETCONF = or > CoAP. > > I have removed that one. > > > > I restate my question below, and the [xx] indicates my = understanding. > > > > Does c and d state the following are handled: > > 1) informational concepts for the DS handling - [Netmod] > > 2) generic extensions to Yang to describe control plane datastore = yang > > modules - [netmod] > > 3) generic extensions to Yang to describe the ephemeral state in > > control plane yang modules - [I2RS] > > 4) I2RS specific extensions to support the I2RS control plane > > datastore's validation - [I2RS] > > 5) Any I2RS Yang modules- [I2RS] > > > > To provide precision on this point, I will give examples of work > > related > to > > each question: > > 1) draft-ietf-netmod-revised-datastores-00.txt [netmod] > > 2) extensions to describe control plane data store yang modules: > > a) control plane data store definitions added to > draft-ietf-netmod-yang- > > model-classification [netmod] > > b) extensions to the Yang 1.1 - to provide a syntax to describe > datastores in > > which a module exists > > datastore should include syntax to identify identity and > prioritization > > config data store. [netmod] > > c) extension to describe the merged tree in applied datastore and > opstate > > datastore [netmod] > > d) mount extensions that allow mounting modules in different > > datastores > > > > 3) generic extensions to describe ephemeral state the I2RS control > > plane datastore [I2RS] > > a) extensions can define validation specific to I2RS control > > plane datastore. > > b) rpc can be used for validation of modules > > that seek to mounted in either the I2RS control plane > > datastore or > the > > configuration data store. > > > > 4) I2RS specific extensions to support I2RS features in the I2RS > > control > plane > > data store. > > > > My earlier: - is a question for NETCONF/RESTCONF, or CoAP. > > b) standard extensions to the protocol (e.g. I2RS or = NETCONF/RESTCONF) > > to enable the usage of DS - [protocol group or WG] > > > > > > Sue > > > > > > -----Original Message----- > > From: Mehmet Ersue [mailto:mersue@gmail.com] > > Sent: Tuesday, March 7, 2017 12:21 PM > > To: 'Susan Hares'; 'Kent Watsen'; netmod@ietf.org > > Cc: netmod-chairs@ietf.org > > Subject: RE: [netmod] draft netmod charter update proposal > > > > Hi Sue, > > > > AFAICS your question kind of mixes between "I2RS control plane = protocol" > > and "ephemeral additions to Yang". > > I believe different WGs are responsible for the part they own. > > E.g. protocol-specific part should be done in the WG owning the = protocol. > > > > Can you please differentiate in your question between the aspects > > below (my assumption in [ ]? > > a) informational concept for the DS handling [netmod] > > b) standard extensions to the protocol (e.g. I2RS or = NETCONF/RESTCONF) > > to enable the usage of DS [protocol WGs, e.g. I2RS] > > c) generic extensions to YANG language usable by many protocols > > [netmod] > > d) any specific YANG modules necessary for the use of DS [protocols > > WGs] > > > > BR, > > Mehmet > > > > > -----Original Message----- > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan > > Hares > > > Sent: Tuesday, March 7, 2017 4:30 PM > > > To: 'Kent Watsen' ; netmod@ietf.org > > > Cc: netmod-chairs@ietf.org > > > Subject: Re: [netmod] draft netmod charter update proposal > > > > > > Kent and Lou: > > > > > > Clarifying questions: > > > > > > Does c) and d) include additions to include I2RS ephemeral state = as > > > part > > of > > > an I2RS control plane protocol? If not, which WG works on the = I2RS > > > ephemeral additions to Yang for control plane data stores? > > > > > > Sue > > > > > > -----Original Message----- > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent > > Watsen > > > Sent: Wednesday, February 22, 2017 7:25 PM > > > To: netmod@ietf.org > > > Cc: netmod-chairs@ietf.org > > > Subject: [netmod] draft netmod charter update proposal > > > > > > > > > Hi NETMOD WG, > > > > > > Please find below the draft charter update which we provided to = our > > > AD for review. Comments are welcomed. Authors, please note the > > > milestone dates. > > > > > > Kent (and Lou) > > > > > > > > > > > > > > > Network Modeling (NETMOD) > > > ------------------------- > > > > > > Charter > > > > > > Current Status: Active > > > > > > Chairs: > > > Lou Berger > > > Kent Watsen > > > > > > Operations and Management Area Directors: > > > Benoit Claise > > > Joel Jaeggli > > > > > > Operations and Management Area Advisor: > > > Benoit Claise > > > > > > Secretary: > > > Zitao (Michael) Wang > > > > > > Mailing Lists: > > > General Discussion: netmod@ietf.org > > > To Subscribe: = https://www.ietf.org/mailman/listinfo/netmod > > > Archive: = https://mailarchive.ietf.org/arch/browse/netmod/ > > > > > > Description of Working Group: > > > > > > The Network Modeling (NETMOD) working group is responsible for > > > the YANG > > > data modeling language, and guidelines for developing YANG = models. > > The > > > NETMOD working group addresses general topics related to the = use > > > of > > the > > > YANG language and YANG models, for example, the mapping of YANG > > > modeled > > > data into various encodings. Finally, the NETMOD working group = also > > > defines core YANG models used as basic YANG building blocks, = and > YANG > > > models that do not otherwise fall under the charter of any = other IETF > > > working group. > > > > > > The NETMOD WG is responsible for: > > > > > > a) Maintaining the data modeling language YANG. This effort = entails > > > periodically updating the specification to address new > requirements > > > as they arise. > > > > > > b) Maintaining the guidelines for developing YANG models. This > effort > > > is primarily driven by updates made to the YANG = specification. > > > > > > c) Maintaining a conceptual framework in which YANG models are = used. > > > This effort entails describing the context that network = management > > > protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, = and > > > how certain YANG statements interact in that context. > > > > > > d) Maintaining encodings for YANG modeled data. This effort = entails > > > updating encodings already defined by the NETMOD working = (XML > and > > > JSON) to accommodate changes to the YANG specification, and > defining > > > new encodings that are needed and yet do not fall under the > charter > > > of any other active IETF working group. > > > > > > e) Maintaining YANG models used as basic YANG building blocks. = This > > > effort entails updating existing YANG models = (ietf-yang-types and > > > ietf-inet-types) as needed, as well as defining additional > > > core > YANG > > > data models when necessary. > > > > > > f) Defining and maintaining YANG models that do not fall under = the > > > charter of any other active IETF working group. > > > > > > The NETMOD working group consults with the NETCONF working = group > to > > > ensure that new requirements are and understood and can be met = by > > > the protocols developed within that working group (e.g., = NETCONF > > > and RESTCONF). The NETMOD working group coordinates with other > > > working groups on possible extensions to YANG to address new > modeling > > > requirements and, when needed, which group will run the process = on a > > > specific model. > > > > > > The NETMOD working group does not serve as a review team for = YANG > > > modules developed by other working groups. Instead, the YANG > doctors, > > > as organized by the OPS area director responsible for network > > > management, will act as advisors for other working groups and = provide > > > YANG reviews for the OPS area directors. > > > > > > Milestones: > > > > > > Done - Submit draft-ietf-netmod-rfc6087bis to IESG for > publication > > > Mar 2016 - Submit draft-ietf-netmod-yang-model-classification = to IESG > > > for publication > > > Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for > > publication > > > Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for = publication > > > Mar 2017 - Submit draft-ietf-netmod-entity to IESG for = publication > > > Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > > > publication > > > Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for > > publication > > > Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG = for > > > publication > > > Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG = for > > > publication > > > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > >=20 >=20 >=20 From nobody Wed Mar 8 08:08:18 2017 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 82EFB1295DA; Wed, 8 Mar 2017 08:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 LShwQgnBImDV; Wed, 8 Mar 2017 08:08:14 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 A437F1294C6; Wed, 8 Mar 2017 08:08:14 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.29; From: "Susan Hares" To: "'Mehmet Ersue'" , "'Kent Watsen'" , References: <01a101d29757$b405beb0$1c113c10$@ndzh.com> <017401d29767$41970e50$c4c52af0$@gmail.com> <00f801d29770$7a42dfa0$6ec89ee0$@ndzh.com> <027a01d29781$24d32b40$6e7981c0$@gmail.com> <24CF7954-A7B3-4550-AFF7-9898EE175FA2@juniper.net> <013901d29825$264ae4a0$72e0ade0$@gmail.com> In-Reply-To: <013901d29825$264ae4a0$72e0ade0$@gmail.com> Date: Wed, 8 Mar 2017 11:03:11 -0500 Message-ID: <017a01d29825$7cb87140$762953c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gIsUOtUAnaIwygB1AGuegIZIUmAAZiY54sB+xxj76DX6Q7g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 16:08:16 -0000 Sounds like a great idea! Sue=20 -----Original Message----- From: Mehmet Ersue [mailto:mersue@gmail.com]=20 Sent: Wednesday, March 8, 2017 11:01 AM To: 'Kent Watsen'; 'Susan Hares'; netmod@ietf.org Cc: netmod-chairs@ietf.org Subject: RE: [netmod] draft netmod charter update proposal What I meant with joint session can be achieved with a (e.g. 20-30min) = time-slot in NETMOD or NETCONF session on Tuesday where we invite I2RS = people to attend. We can discuss the charter details and agree "all = together" on the plan and work split. Does this make sense? Mehmet > -----Original Message----- > From: Kent Watsen [mailto:kwatsen@juniper.net] > Sent: Wednesday, March 8, 2017 1:51 AM > To: Mehmet Ersue ; 'Susan Hares' > ; netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: Re: [netmod] draft netmod charter update proposal >=20 > Hi Sue, >=20 > First, please be aware that the next version of revised-datastores=20 > draft further defines the control-plane datastore concept. This=20 > includes providing guidelines that other WGs can follow to define=20 > their own control-plane datastores, and includes an Appendix section=20 > outlining the creation of an "ephemeral" datastore. The idea is to=20 > give the I2RS WG the ability to define > datastore(s) as needed > (read: future I2RS WG drafts). >=20 > Regarding: >=20 > > Does c) and d) include additions to include I2RS ephemeral state > > as part of an I2RS control plane protocol? If not, which WG > > works on the I2RS ephemeral additions to Yang for control plane data = > > stores? >=20 > I don't fully understand the question, but believe that the NETMOD=20 > activities needed to support I2RS are all covered by a), b), and c). > Things that belong to NETCONF WG will include any needed changes to=20 > protocol, YANG-Library, or any other draft maintained by that WG. > Everything else goes to I2RS. >=20 > I'm not sure what Mehmet means by a "joint session", but I think that=20 > it's too late to add such a session to the IETF Agenda at this point. = > That said, I plan a schedule another datastore breakout session=20 > (likely on Wed morning) that could be used to discuss I2RS some, and I = > also plan on attending the I2RS meeting Wed afternoon. >=20 > Kent >=20 >=20 > -----ORIGINAL MESSAGE----- >=20 > Sounds good as a first approximation. Though we need to discuss the=20 > details and agree. > It might be useful to plan a joint session on Tue or Wed in Chicago. >=20 > Cheers, > Mehmet >=20 > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com] > > Sent: Tuesday, March 7, 2017 7:27 PM > > To: 'Mehmet Ersue' ; 'Kent Watsen' > > ; netmod@ietf.org > > Cc: netmod-chairs@ietf.org > > Subject: RE: [netmod] draft netmod charter update proposal > > > > Mehmet: > > > > Thank you for the excellent question clarifying my questions. My > questions > > (b) - related to protocol extension for I2RS for RESTCONF, NETCONF=20 > > or > CoAP. > > I have removed that one. > > > > I restate my question below, and the [xx] indicates my = understanding. > > > > Does c and d state the following are handled: > > 1) informational concepts for the DS handling - [Netmod] > > 2) generic extensions to Yang to describe control plane datastore=20 > > yang modules - [netmod] > > 3) generic extensions to Yang to describe the ephemeral state in=20 > > control plane yang modules - [I2RS] > > 4) I2RS specific extensions to support the I2RS control plane=20 > > datastore's validation - [I2RS] > > 5) Any I2RS Yang modules- [I2RS] > > > > To provide precision on this point, I will give examples of work=20 > > related > to > > each question: > > 1) draft-ietf-netmod-revised-datastores-00.txt [netmod] > > 2) extensions to describe control plane data store yang modules: > > a) control plane data store definitions added to > draft-ietf-netmod-yang- > > model-classification [netmod] > > b) extensions to the Yang 1.1 - to provide a syntax to describe > datastores in > > which a module exists > > datastore should include syntax to identify identity and > prioritization > > config data store. [netmod] > > c) extension to describe the merged tree in applied datastore and > opstate > > datastore [netmod] > > d) mount extensions that allow mounting modules in different=20 > > datastores > > > > 3) generic extensions to describe ephemeral state the I2RS control=20 > > plane datastore [I2RS] > > a) extensions can define validation specific to I2RS control=20 > > plane datastore. > > b) rpc can be used for validation of modules > > that seek to mounted in either the I2RS control plane=20 > > datastore or > the > > configuration data store. > > > > 4) I2RS specific extensions to support I2RS features in the I2RS=20 > > control > plane > > data store. > > > > My earlier: - is a question for NETCONF/RESTCONF, or CoAP. > > b) standard extensions to the protocol (e.g. I2RS or = NETCONF/RESTCONF) > > to enable the usage of DS - [protocol group or WG] > > > > > > Sue > > > > > > -----Original Message----- > > From: Mehmet Ersue [mailto:mersue@gmail.com] > > Sent: Tuesday, March 7, 2017 12:21 PM > > To: 'Susan Hares'; 'Kent Watsen'; netmod@ietf.org > > Cc: netmod-chairs@ietf.org > > Subject: RE: [netmod] draft netmod charter update proposal > > > > Hi Sue, > > > > AFAICS your question kind of mixes between "I2RS control plane = protocol" > > and "ephemeral additions to Yang". > > I believe different WGs are responsible for the part they own. > > E.g. protocol-specific part should be done in the WG owning the = protocol. > > > > Can you please differentiate in your question between the aspects=20 > > below (my assumption in [ ]? > > a) informational concept for the DS handling [netmod] > > b) standard extensions to the protocol (e.g. I2RS or=20 > > NETCONF/RESTCONF) to enable the usage of DS [protocol WGs, e.g.=20 > > I2RS] > > c) generic extensions to YANG language usable by many protocols=20 > > [netmod] > > d) any specific YANG modules necessary for the use of DS [protocols=20 > > WGs] > > > > BR, > > Mehmet > > > > > -----Original Message----- > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan > > Hares > > > Sent: Tuesday, March 7, 2017 4:30 PM > > > To: 'Kent Watsen' ; netmod@ietf.org > > > Cc: netmod-chairs@ietf.org > > > Subject: Re: [netmod] draft netmod charter update proposal > > > > > > Kent and Lou: > > > > > > Clarifying questions: > > > > > > Does c) and d) include additions to include I2RS ephemeral state=20 > > > as part > > of > > > an I2RS control plane protocol? If not, which WG works on the = I2RS > > > ephemeral additions to Yang for control plane data stores? > > > > > > Sue > > > > > > -----Original Message----- > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent > > Watsen > > > Sent: Wednesday, February 22, 2017 7:25 PM > > > To: netmod@ietf.org > > > Cc: netmod-chairs@ietf.org > > > Subject: [netmod] draft netmod charter update proposal > > > > > > > > > Hi NETMOD WG, > > > > > > Please find below the draft charter update which we provided to=20 > > > our AD for review. Comments are welcomed. Authors, please note=20 > > > the milestone dates. > > > > > > Kent (and Lou) > > > > > > > > > > > > > > > Network Modeling (NETMOD) > > > ------------------------- > > > > > > Charter > > > > > > Current Status: Active > > > > > > Chairs: > > > Lou Berger > > > Kent Watsen > > > > > > Operations and Management Area Directors: > > > Benoit Claise > > > Joel Jaeggli > > > > > > Operations and Management Area Advisor: > > > Benoit Claise > > > > > > Secretary: > > > Zitao (Michael) Wang > > > > > > Mailing Lists: > > > General Discussion: netmod@ietf.org > > > To Subscribe: = https://www.ietf.org/mailman/listinfo/netmod > > > Archive: = https://mailarchive.ietf.org/arch/browse/netmod/ > > > > > > Description of Working Group: > > > > > > The Network Modeling (NETMOD) working group is responsible for=20 > > > the YANG > > > data modeling language, and guidelines for developing YANG = models. > > The > > > NETMOD working group addresses general topics related to the=20 > > > use of > > the > > > YANG language and YANG models, for example, the mapping of YANG = > > > modeled > > > data into various encodings. Finally, the NETMOD working group = also > > > defines core YANG models used as basic YANG building blocks,=20 > > > and > YANG > > > models that do not otherwise fall under the charter of any = other IETF > > > working group. > > > > > > The NETMOD WG is responsible for: > > > > > > a) Maintaining the data modeling language YANG. This effort = entails > > > periodically updating the specification to address new > requirements > > > as they arise. > > > > > > b) Maintaining the guidelines for developing YANG models. This > effort > > > is primarily driven by updates made to the YANG = specification. > > > > > > c) Maintaining a conceptual framework in which YANG models are = used. > > > This effort entails describing the context that network = management > > > protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, = and > > > how certain YANG statements interact in that context. > > > > > > d) Maintaining encodings for YANG modeled data. This effort = entails > > > updating encodings already defined by the NETMOD working=20 > > > (XML > and > > > JSON) to accommodate changes to the YANG specification, and > defining > > > new encodings that are needed and yet do not fall under the > charter > > > of any other active IETF working group. > > > > > > e) Maintaining YANG models used as basic YANG building blocks. = This > > > effort entails updating existing YANG models = (ietf-yang-types and > > > ietf-inet-types) as needed, as well as defining additional=20 > > > core > YANG > > > data models when necessary. > > > > > > f) Defining and maintaining YANG models that do not fall under = the > > > charter of any other active IETF working group. > > > > > > The NETMOD working group consults with the NETCONF working=20 > > > group > to > > > ensure that new requirements are and understood and can be met = by > > > the protocols developed within that working group (e.g., = NETCONF > > > and RESTCONF). The NETMOD working group coordinates with other > > > working groups on possible extensions to YANG to address new > modeling > > > requirements and, when needed, which group will run the process = on a > > > specific model. > > > > > > The NETMOD working group does not serve as a review team for = YANG > > > modules developed by other working groups. Instead, the YANG > doctors, > > > as organized by the OPS area director responsible for network > > > management, will act as advisors for other working groups and = provide > > > YANG reviews for the OPS area directors. > > > > > > Milestones: > > > > > > Done - Submit draft-ietf-netmod-rfc6087bis to IESG for > publication > > > Mar 2016 - Submit draft-ietf-netmod-yang-model-classification = to IESG > > > for publication > > > Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for > > publication > > > Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for = publication > > > Mar 2017 - Submit draft-ietf-netmod-entity to IESG for = publication > > > Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > > > publication > > > Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for > > publication > > > Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG = for > > > publication > > > Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG = for > > > publication > > > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > >=20 >=20 >=20 From nobody Wed Mar 8 08:40:17 2017 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 9D0BC12963E for ; Wed, 8 Mar 2017 08:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.021 X-Spam-Level: X-Spam-Status: No, score=-7.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 FTduI5hAwT0d for ; Wed, 8 Mar 2017 08:40:14 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589D1129609 for ; Wed, 8 Mar 2017 08:40:14 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:78b6:acea:91b3:9c19] (unknown [IPv6:2001:718:1a02:1:78b6:acea:91b3:9c19]) by mail.nic.cz (Postfix) with ESMTPSA id 9844561330; Wed, 8 Mar 2017 17:40:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1488991212; bh=oqv7oI3av4FzEEmTfTJn0XmqKfHYMsCFhsvaTDiIS0g=; h=From:Date:To; b=jFNdkQrlakkgljHVnOrYcBOHgKWdU2zDNKumeQ2GZ4NQtQftAAdofWK7rq9o8nlvO pD6KNjG3P4Xg4S1rilRpdNlA4/pFcBGD32FOrKnTuRrWwgum8Jy+d82FuqVn+xIA49 YUSpx0MnSzdSAF4ejYAAdOUMgcMWwALKnL5Uy894= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <82703e36-26f9-d459-c36a-c274861c5386@labn.net> Date: Wed, 8 Mar 2017 17:40:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> <82703e36-26f9-d459-c36a-c274861c5386@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 16:40:16 -0000 > On 8 Mar 2017, at 16:05, Lou Berger wrote: >=20 > Martin, Juergen, >=20 >=20 > On March 7, 2017 8:08:26 PM Martin Bjorklund wrote: >=20 >> Juergen Schoenwaelder wrote: >>> On Fri, Mar 03, 2017 at 04:41:44PM +0000, Kent Watsen wrote: >>>>=20 >>>> All, >>>>=20 >>>> Lou and I were discussing how it seems unnecessary that every draft >>>> has the same boilerplate text regarding how to interpret tree = diagram >>>> notations. It would be nice if drafts could instead just reference >>>> another draft that contains this information. Does this make = sense? >>>>=20 >>>> Assuming we're interested in having such a reference, we could = define >>>> a mini-RFC or, perhaps, leverage Section 3 of 6087bis (YANG Tree >>>> Diagrams). Either way, we'd want/need to ensure the information >>>> is updated in a timely manner. >>>>=20 >>>> Two reasons for why we may not want to pursue this are: >>>> 1) we can=E2=80=99t update the reference fast enough >>>> 2) drafts might add some proprietary annotations >>>>=20 >>>> Is this worth pursuing at all? >>>=20 >>> This has been discussed before. The tree format that tools generate >>> has evolved a bit over time and the current setup allows to have = some >>> evolution. The question is whether we have reached a state where the >>> evolution has come to standstill and we can nail a common tree = format >>> down. >=20 > I don't see that as the question at all - the issue for me is needing = to > parse each document to see if and how it differs from the norm and = then > figuring out if the differences are (a) a bug, (b) limited to the > specific document, (c) something that is a basic change that should > impact tools (i.e., pyang) and other documents. >=20 >>=20 >> I don't think so. For example, it was recently suggested that a >> notion for "mount-points" should be defined. >>=20 >=20 > Yes, and it is our (Martin, Lada and my) conversation in that context > that prompted this discussion. >=20 >> I don't think this is a big problem. >=20 > Again, I do see this as an issue worth solving and am appreciative = that > 6087bis is available to easily provide a stable reference until such > time as an update/replacement is needed. If the format itself isn't stable, how can 6087bis (after it becomes an = RFC) provide a stable reference? I agree with Juergen and Martin and don't mind having the section about = tree symbols in each document that needs it. Lada >=20 > Lou >=20 >>=20 >>=20 >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 8 09:15:55 2017 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 9B956129440 for ; Wed, 8 Mar 2017 09:15:53 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIb8s6-Abmsq for ; Wed, 8 Mar 2017 09:15:51 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 0CF9612940D for ; Wed, 8 Mar 2017 09:15:51 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id t189so36421676wmt.1 for ; Wed, 08 Mar 2017 09:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HHaUZuDvox9T949gKZueX0RdjN3WyhpiPhYpUoL9EME=; b=1PBJMcgzmbcwdeXNqB9omvrZ+BacDGO/9qg7SSW32c1/E73Fcp7FVRjEYxCkxpPeqI 1wJzaRtL/caT1IEiRzxJEbtDcTiCqos3Hn57Y9bkpAI2OzcZyJmbWl2wuSBxM5uskfz7 lR9UWcuvVFH8E32pQkwzzYJDyVFjqxNEb/zTvQNTGjacYEldktBzangNmRs6+2r2+An2 ZH1JoFD7+dBdnbE0sIklpATl0UuXtapGPstb0NJSsc6zjzcEmY0N8Fh+w6eZ4zizUR9g 2EWv1sRqmn/jL/jytZYXGZU/aleXS8JTQakrmpbzUQ77GLYGfHX1zL/rIpw4tmoM0rRM RAnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HHaUZuDvox9T949gKZueX0RdjN3WyhpiPhYpUoL9EME=; b=txqCWEUE52NXQIAyQRTRUilT34WF7E4eJ/mxJd8jIbcKOxCEDuGFiKjNT8Bw7raV2f +hPPsh0PMrICD2Xa9j5RaVXu2IQW+sxX39dj3atOSv6hw8pjIJLUcenKrciQvYyuolk1 WbRqrlML0RV1iuI5InnN/jE2bMkFgFkwcO5ReeCuzfhfU5OBeo7ig6poBcV159+53k1J Nxh9FA3HdSwcqqxUH9vy0bC5bLONFC6zYQfo38nZU8lOfiVzJQuRMjDnZwPTkGOY6Bjf Qsitl9qxtjhQT7wZnhKd9L9FVATHSueDItV+BX+S0OXzO+ADRTq6/DtDaefmrRvyxfh/ Z/LQ== X-Gm-Message-State: AMke39n4y5lWm2ommczDbeLtCuDCuvKf+kq0/9T7kVK+lHXhFX/WzOJJsz/5ttsUHJxJmDf0fzGkYp2WV3f2YQ== X-Received: by 10.28.234.206 with SMTP id g75mr6480039wmi.54.1488993349398; Wed, 08 Mar 2017 09:15:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Wed, 8 Mar 2017 09:15:48 -0800 (PST) In-Reply-To: <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> <82703e36-26f9-d459-c36a-c274861c5386@labn.net> <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> From: Andy Bierman Date: Wed, 8 Mar 2017 09:15:48 -0800 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11472b9eaa1624054a3b47a1 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 17:15:53 -0000 --001a11472b9eaa1624054a3b47a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 8, 2017 at 8:40 AM, Ladislav Lhotka wrote: > > > On 8 Mar 2017, at 16:05, Lou Berger wrote: > > > > Martin, Juergen, > > > > > > On March 7, 2017 8:08:26 PM Martin Bjorklund wrote: > > > >> Juergen Schoenwaelder wrote: > >>> On Fri, Mar 03, 2017 at 04:41:44PM +0000, Kent Watsen wrote: > >>>> > >>>> All, > >>>> > >>>> Lou and I were discussing how it seems unnecessary that every draft > >>>> has the same boilerplate text regarding how to interpret tree diagra= m > >>>> notations. It would be nice if drafts could instead just reference > >>>> another draft that contains this information. Does this make sense? > >>>> > >>>> Assuming we're interested in having such a reference, we could defin= e > >>>> a mini-RFC or, perhaps, leverage Section 3 of 6087bis (YANG Tree > >>>> Diagrams). Either way, we'd want/need to ensure the information > >>>> is updated in a timely manner. > >>>> > >>>> Two reasons for why we may not want to pursue this are: > >>>> 1) we can=E2=80=99t update the reference fast enough > >>>> 2) drafts might add some proprietary annotations > >>>> > >>>> Is this worth pursuing at all? > >>> > >>> This has been discussed before. The tree format that tools generate > >>> has evolved a bit over time and the current setup allows to have some > >>> evolution. The question is whether we have reached a state where the > >>> evolution has come to standstill and we can nail a common tree format > >>> down. > > > > I don't see that as the question at all - the issue for me is needing t= o > > parse each document to see if and how it differs from the norm and then > > figuring out if the differences are (a) a bug, (b) limited to the > > specific document, (c) something that is a basic change that should > > impact tools (i.e., pyang) and other documents. > > > >> > >> I don't think so. For example, it was recently suggested that a > >> notion for "mount-points" should be defined. > >> > > > > Yes, and it is our (Martin, Lada and my) conversation in that context > > that prompted this discussion. > > > >> I don't think this is a big problem. > > > > Again, I do see this as an issue worth solving and am appreciative that > > 6087bis is available to easily provide a stable reference until such > > time as an update/replacement is needed. > > If the format itself isn't stable, how can 6087bis (after it becomes an > RFC) provide a stable reference? > > I agree with Juergen and Martin and don't mind having the section about > tree symbols in each document that needs it. > > The text in question is in section 4.3: If YANG tree diagrams are used, then a sub-section explaining the YANG tree diagram syntax MUST be present, containing the following text: A simplified graphical representation of the data model is used in this document. *The meaning of the symbols in these diagrams is defined in [RFCXXXX].* -- RFC Editor: Replace XXXX with RFC number and remove note Given that work on YANG 1.2 is likely to begin just after YANG 1.1 was published, it is hard to pretend that this is a stable language. So I agree this text should be replaced with new text that reflects the lack of a stable reference. Suggested Text: OLD: If YANG tree diagrams are used, then a sub-section explaining the YANG tree diagram syntax MUST be present, containing the following text: A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is defined in [RFCXXXX]. NEW: If YANG tree diagrams are used, then a sub-section explaining the YANG tree diagram syntax MUST be present, explaining the symbols in the diagram. The actual text will depend on the version of the YANG tree diagram syntax used in the document. Lada Andy > > > > Lou > > > >> > >> > >> /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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11472b9eaa1624054a3b47a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 8, 2017 at 8:40 AM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:

> On 8 Mar 2017, at 16:05, Lou Berger <lberger@labn.net> wrote:
>
> Martin, Juergen,
>
>
> On March 7, 2017 8:08:26 PM Martin Bjorklund <mbj@tail-f.com> wrote:
>
>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>> On Fri, Mar 03, 2017 at 04:41:44PM +0000, Kent Watsen wrote: >>>>
>>>> All,
>>>>
>>>> Lou and I were discussing how it seems unnecessary that ev= ery draft
>>>> has the same boilerplate text regarding how to interpret t= ree diagram
>>>> notations.=C2=A0 It would be nice if drafts could instead = just reference
>>>> another draft that contains this information.=C2=A0 Does t= his make sense?
>>>>
>>>> Assuming we're interested in having such a reference, = we could define
>>>> a mini-RFC or, perhaps, leverage Section 3 of 6087bis (YAN= G Tree
>>>> Diagrams).=C2=A0 Either way, we'd want/need to ensure = the information
>>>> is updated in a timely manner.
>>>>
>>>> Two reasons for why we may not want to pursue this are: >>>>=C2=A0 1) we can=E2=80=99t update the reference fast enough=
>>>>=C2=A0 2) drafts might add some proprietary annotations
>>>>
>>>> Is this worth pursuing at all?
>>>
>>> This has been discussed before. The tree format that tools gen= erate
>>> has evolved a bit over time and the current setup allows to ha= ve some
>>> evolution. The question is whether we have reached a state whe= re the
>>> evolution has come to standstill and we can nail a common tree= format
>>> down.
>
> I don't see that as the question at all - the issue for me is need= ing to
> parse each document to see if and how it differs from the norm and the= n
> figuring out if the differences are (a) a bug, (b) limited to the
> specific document, (c) something that is a basic change that should > impact tools (i.e., pyang) and other documents.
>
>>
>> I don't think so.=C2=A0 For example, it was recently suggested= that a
>> notion for "mount-points" should be defined.
>>
>
> Yes, and it is our (Martin, Lada and my) conversation in that context<= br> > that prompted this discussion.
>
>> I don't think this is a big problem.
>
> Again, I do see this as an issue worth solving and am appreciative tha= t
> 6087bis is available to easily provide a stable reference until such > time as an update/replacement is needed.

If the format itself isn't stable, how can 6087bis (after it becomes an= RFC) provide a stable reference?

I agree with Juergen and Martin and don't mind having the section about= tree symbols in each document that needs it.


The text in question is in section 4.3= :

   If YANG tre=
e diagrams are used, then a sub-section explaining the
   YANG tree diagram syntax MUST be present, containing the following
   text:

     A simplified graphical representation of the data model is used in
     this document.  The meaning of the symbols in these diagrams is
     defined in [RFCXXXX].

     -- RFC Editor: Replace XXXX with RFC number and remove note



Given that wo= rk on YANG 1.2 is likely to begin just after YANG 1.1 was published,
<= div>it is hard to pretend that this is a stable language.=C2=A0 So I agree = this text should be
replaced with new text that reflects the lack= of a stable reference.=C2=A0

Suggested Text:

OLD:

   If YANG tree diagrams are used, then a sub-section explaining =
the
   YANG tree diagram syntax MUST be present, containing the following
   text:

     A simplified graphical representation of t=
he data model is used in
     this document.  The meaning of the symbols in these diagrams is
     defined in [RFCXXXX].


NEW:

   If YANG tree diagrams are use=
d, then a sub-section explaining the
   YANG tree diagram syntax MUST be present, explaining the symbols
   in the diagram.  The actual text wil=
l depend on the version of
   the YA=
NG tree diagram syntax used in the document.


<= /div>

Lada

=C2=A0
Andy

--001a11472b9eaa1624054a3b47a1-- From nobody Wed Mar 8 09:26:19 2017 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 382CD12963E for ; Wed, 8 Mar 2017 09:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dG485XNUSXWM for ; Wed, 8 Mar 2017 09:26:16 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 3F4BE12943E for ; Wed, 8 Mar 2017 09:26:16 -0800 (PST) Received: (qmail 16187 invoked by uid 0); 8 Mar 2017 17:26:13 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 8 Mar 2017 17:26:13 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id tVS91u00h2SSUrH01VSC9d; Wed, 08 Mar 2017 10:26:13 -0700 X-Authority-Analysis: v=2.1 cv=H5NInYoi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=wU2YTnxGAAAA:8 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=oujoVVCqLW8QpQbOr74A:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=SkebfZ6J2Mmvk2rLHZle:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=V8+GK1NY9WR/MyxhgLLHb8RbF7FiMyPkYV2NiIAGlpM=; b=OOn5v4RqIEXANZGaGv2/WWefsI kNQZQHcaxkShK4qgUjyh1KWvaCD1CPQA2IQ430iEBHP3/7p2Sa7i3nl2wRDrvTB4atvjv1HNhup4I os9slPtkpuLPVdE4DLvDAehk6; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:55018 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1clfLl-0004JW-Iz; Wed, 08 Mar 2017 10:26:09 -0700 To: Ladislav Lhotka References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> <82703e36-26f9-d459-c36a-c274861c5386@labn.net> <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> From: Lou Berger Message-ID: <51c79871-1671-e3ae-1417-389c3311b4b4@labn.net> Date: Wed, 8 Mar 2017 12:26:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1clfLl-0004JW-Iz X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:55018 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 17:26:18 -0000 Lada, On 3/8/2017 11:40 AM, Ladislav Lhotka wrote: >> On 8 Mar 2017, at 16:05, Lou Berger wrote: >> >> Martin, Juergen, >> >> >> On March 7, 2017 8:08:26 PM Martin Bjorklund wrote: >> >>> Juergen Schoenwaelder wrote: >>>> On Fri, Mar 03, 2017 at 04:41:44PM +0000, Kent Watsen wrote: >>>>> All, >>>>> >>>>> Lou and I were discussing how it seems unnecessary that every draft >>>>> has the same boilerplate text regarding how to interpret tree diagram >>>>> notations. It would be nice if drafts could instead just reference >>>>> another draft that contains this information. Does this make sense? >>>>> >>>>> Assuming we're interested in having such a reference, we could define >>>>> a mini-RFC or, perhaps, leverage Section 3 of 6087bis (YANG Tree >>>>> Diagrams). Either way, we'd want/need to ensure the information >>>>> is updated in a timely manner. >>>>> >>>>> Two reasons for why we may not want to pursue this are: >>>>> 1) we can’t update the reference fast enough >>>>> 2) drafts might add some proprietary annotations >>>>> >>>>> Is this worth pursuing at all? >>>> This has been discussed before. The tree format that tools generate >>>> has evolved a bit over time and the current setup allows to have some >>>> evolution. The question is whether we have reached a state where the >>>> evolution has come to standstill and we can nail a common tree format >>>> down. >> I don't see that as the question at all - the issue for me is needing to >> parse each document to see if and how it differs from the norm and then >> figuring out if the differences are (a) a bug, (b) limited to the >> specific document, (c) something that is a basic change that should >> impact tools (i.e., pyang) and other documents. >> >>> I don't think so. For example, it was recently suggested that a >>> notion for "mount-points" should be defined. >>> >> Yes, and it is our (Martin, Lada and my) conversation in that context >> that prompted this discussion. >> >>> I don't think this is a big problem. >> Again, I do see this as an issue worth solving and am appreciative that >> 6087bis is available to easily provide a stable reference until such >> time as an update/replacement is needed. > If the format itself isn't stable, how can 6087bis (after it becomes an RFC) provide a stable reference? huh? - any RFC can be updated per normal process whenever appropriate. > I agree with Juergen and Martin and don't mind having the section about tree symbols in each document that needs it. I completely disagree - it means we constantly need to do diffs. There's a good reason to reference prior work when *not* changing something which shows up, in this case in potentially 10s if not 100s of drafts. This allows *everyone* to immediately notice when something new or unique is done. (I'll have to find it, but I really loved the RFC that used a well known term, but then redefined it for that one and only document -- why do we want to allow this???) What benefit comes from defining tree syntax by reference? BTW if you/the WG prefers for the definition to be in its own document, that would work too. Lou > Lada > >> Lou >> >>> >>> /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 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > From nobody Wed Mar 8 09:40:50 2017 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 1119812942F for ; Wed, 8 Mar 2017 09:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 dF8ubrHBTM3u for ; Wed, 8 Mar 2017 09:40:46 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0091.outbound.protection.outlook.com [104.47.37.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F091270B4 for ; Wed, 8 Mar 2017 09:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vuoHeOy9PuN2+AFEvQccCobMo2YsSnvCRMigp9cRMyg=; b=W18bd4ZgJup3jSLfccLbUNvdVyQ3qh8xD/YrRZtNAeSQ8opuO47WZ/Nud+6Dud3LfngBtN6Wq7RPC2Xaljy1Wa3v386jJm8J7AsM/3167EdfwJbcEzKb3tgXFlKYDkJpZ8JO9UVXmzOfIgdF7MAAHb7kSayfcM6hRWeYFCAerkI= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Wed, 8 Mar 2017 17:40:45 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0961.012; Wed, 8 Mar 2017 17:40:45 +0000 From: Kent Watsen To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [netmod] rfc 6087bis - stress importance of instance examples Thread-Index: AQHSlFJL0qY+3T3n+ESw47YUZTv45KGJsGeAgAE5W4A= Date: Wed, 8 Mar 2017 17:40:44 +0000 Message-ID: References: <20170303191348.GA3570@elstar.local> <20170307.185911.779366639761395028.mbj@tail-f.com> In-Reply-To: <20170307.185911.779366639761395028.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: tail-f.com; dkim=none (message not signed) header.d=none;tail-f.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:RKQdmnHB+Q3IW8wA1X6L9crN7D5f6aYb+rWFOQ5W8NE+7gkiIUc//SztNVEyhMiWAqBk9ZTxf/ByRqn3bRd4Zt9Y7cBMdBBOAOeVGf78Lgu6Au/0LtQr5nXEqviiTEIh+w6qHugdIWhN1qVi5wRiI58UieIBO3Aj/XlRrXQDX+wK9S0cIRTbJiuJ8NmWOZQiO129G3Rv6O8ceQ6n/0t92jmdESiJHr28WdjKm8IbmkzO7qTXDHGwwrwasTKuyShRwyZJMOss9t/9/K6bgwO9WVGiGXAkrSvYMDtMa7ELs4hw8yRXojjfFdrg1nZb9vol/AHSfRBSakXsXZGTc3Rj5Q== x-ms-office365-filtering-correlation-id: 95e76717-9d33-4186-e21d-08d4664a3fd7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39450400003)(39410400002)(39850400002)(102836003)(77096006)(6506006)(86362001)(6436002)(6486002)(25786008)(6512007)(3846002)(106116001)(122556002)(305945005)(2900100001)(8936002)(81166006)(36756003)(6116002)(8676002)(189998001)(66066001)(99286003)(6306002)(53936002)(2950100002)(83716003)(5660300001)(82746002)(6246003)(83506001)(229853002)(3280700002)(38730400002)(2906002)(54356999)(50986999)(7736002)(4326008)(4001350100001)(3660700001)(76176999)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <43E73C95617AA240A6E268B4D80B8379@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 17:40:44.9245 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] rfc 6087bis - stress importance of instance examples X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 17:40:48 -0000 DQoNCj4+IEkgdGhpbmsgd2Ugc2hvdWxkIGVuY291cmFnZSBhdXRob3JzIHRvIHdyaXRlIGV4YW1w bGVzLg0KPg0KPiArMSAgQW5kIGFsc28gZW5jb3VyYWdlIGF1dGhvcnMgdG8gdmFsaWRhdGUgdGhl IGV4YW1wbGVzIA0KPiB1c2luZyB0aGVpciBmYXZvcml0ZSBZQU5HIGluc3RhbmNlIHZhbGlkYXRp b24gdG9vbC4NCg0KDQpQbGVhc2Ugbm90ZSB0aGlzIGZyb20gdGhlIGxhdGVzdCA2MDg3YmlzIHVw ZGF0ZToNCg0KICAgNC4xMi4gIE1vZHVsZSBVc2FnZSBFeGFtcGxlcw0KDQogICBFYWNoIHNwZWNp ZmljYXRpb24gdGhhdCBkZWZpbmVzIG9uZSBvciBtb3JlIG1vZHVsZXMgU0hPVUxEIGNvbnRhaW4N CiAgIHVzYWdlIGV4YW1wbGVzLCBlaXRoZXIgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgb3IgaW4g YW4gYXBwZW5kaXguDQogICBUaGlzIGluY2x1ZGVzIGV4YW1wbGUgWE1MIGluc3RhbmNlIGRvY3Vt ZW50IHNuaXBwZXRzIHRvIGRlbW9uc3RyYXRlDQogICB0aGUgaW50ZW5kZWQgdXNhZ2Ugb2YgdGhl IFlBTkcgbW9kdWxlKHMpLg0KDQphbmQgSSBhbHJlYWR5IHdyb3RlIHRoaXM6DQoNCiAgTmljZSBh ZGRpdGlvbiwgYnV0IHNob3VsZCBpdCBzYXkgc29tZXRoaW5nIGFib3V0IEpTT04sIGluIGFkZGl0 aW9uIHRvIFhNTD8NCiAgUGVyaGFwcyB0aGF0LCB1bmxlc3MgdGhlcmUgaXMgYSByZWFzb24gdG8g b25seSBwaWNrIG9uZSBlbmNvZGluZywgZXhhbXBsZXMNCiAgc2hvdWxkIGJlIHNwbGl0IGJldHdl ZW4gdGhlIHR3bz8gIC0ganVzdCB0aHJvd2luZyBpdCBvdXQgdGhlcmUgdG8gc2VlIGlmIHRoaXMg aXMNCiAgc29tZXRoaW5nIHdlIG1pZ2h0IHdhbnQgdG8gcmVjb21tZW5kLi4udGhvdWdodHM/DQoN CiAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRtb2QvZE9wU1l6TV9K MDVTZG1ndC1NeVltcUpJVXowDQoNCg0KSy4NCg0KDQo= From nobody Wed Mar 8 10:02:12 2017 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 7132B12944E for ; Wed, 8 Mar 2017 10:02:10 -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, RP_MATCHES_RCVD=-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 A3HZQNvgPabn for ; Wed, 8 Mar 2017 10:02:08 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EFE41270B4 for ; Wed, 8 Mar 2017 10:02:08 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 396547D9; Wed, 8 Mar 2017 19:02:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ashqt4xjgWTn; Wed, 8 Mar 2017 19:02:06 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Mar 2017 19:02:06 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8770020035; Wed, 8 Mar 2017 19:02:06 +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 XyVDV0Lf-aE0; Wed, 8 Mar 2017 19:02:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A98520039; Wed, 8 Mar 2017 19:02:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6C90E3E9C16B; Wed, 8 Mar 2017 19:02:11 +0100 (CET) Date: Wed, 8 Mar 2017 19:02:11 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20170308180211.GA9937@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> <82703e36-26f9-d459-c36a-c274861c5386@labn.net> <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 18:02:10 -0000 On Wed, Mar 08, 2017 at 09:15:48AM -0800, Andy Bierman wrote: > Suggested Text: > > OLD: > > If YANG tree diagrams are used, then a sub-section explaining the > YANG tree diagram syntax MUST be present, containing the following > text: > > A simplified graphical representation of the data model is used in > this document. The meaning of the symbols in these diagrams is > defined in [RFCXXXX]. > > NEW: > > If YANG tree diagrams are used, then a sub-section explaining the > YANG tree diagram syntax MUST be present, explaining the symbols > in the diagram. The actual text will depend on the version of > the YANG tree diagram syntax used in the document. > I think we can allow both and leave it to the document author. Either the author uses a well known tree format and refers to its definition or the author usees a not yet well known tree format and then it has to be defined inline: If YANG tree diagrams are used, then a sub-section explaining the YANG tree diagram syntax MUST be present, explaining the symbols used in the tree diagram. This sub-section can either explain the tree diagram format inline or it can refer to an external specification of the tree diagram format that is used. A specification using the tree diagram format defined in this document may simply state: The meaning of the symbols in these diagrams is defined in [RFCXXXX]. The way bigger issue I think is how to make sure that the text in this sub-section is actually inline with the tree diagram itself since it is easy for this to get out of sync (I admit that I generally do not read the tree diagram blurb and I would not be surprised if people cut'n'paste tree diagram blurbs). In other words, what we may want is a short label _in_ the tree format itself that uniquely identifies the format and is generated by the tool producing the tree format. pyang -f tree --tree-RFCWXYZ foo.yang format: RFCWXYZ module: foo .... I personally would trust such an inline label way more than any tree diagram sections because the label is likely created by the tool that created the diagram. We have seen I-Ds where the tree diagram is out of sync with the YANG definitions. Perhaps the idea to have tools for checking tree diagrams is not that far fetched. (Even though I first thought the idea of checking tree diagrams is somewhat ridiculous.) /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 Mar 8 10:18:20 2017 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 58DEC12944C for ; Wed, 8 Mar 2017 10:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPmftGxtgCVs for ; Wed, 8 Mar 2017 10:18:17 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 2BD9E128AB0 for ; Wed, 8 Mar 2017 10:18:17 -0800 (PST) Received: (qmail 25595 invoked by uid 0); 8 Mar 2017 18:18:16 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy3.mail.unifiedlayer.com with SMTP; 8 Mar 2017 18:18:16 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id tWJD1u00F2SSUrH01WJGrU; Wed, 08 Mar 2017 11:18:16 -0700 X-Authority-Analysis: v=2.1 cv=WOnsABcR c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=OUXY8nFuAAAA:8 a=pGLkceISAAAA:8 a=1sjgXBK7AAAA:8 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=AUd_NHdVAAAA:8 a=xcTfSnc4AAAA:8 a=i0EeH86SAAAA:8 a=hG65hZWSRgg8bd4gG7wA:9 a=hqDST611Nu-XHLzO:21 a=WM2xJLEhjOoErsJ6:21 a=QEXdDO2ut3YA:10 a=cAcMbU7R10T-QSRYIcO_:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=qowbMnUzjQcM5iyYROrS:22 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=TSZmLRzkpGLBZRr3r8m8:22 a=AlSe2FwLBhvzWS46gZ1m:22 a=02toJ7V-nxh73JlV0Smw:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qWqGJe7I0GwW2/0amstZW64MOVDfcUAzo1r7JJLq9tU=; b=UXOi4aetJ8fW8G/OTzqR6Z0NYx u8PFczyiXCfGRdux88ZWaCtRVul+BDDsp5CI4X7KeAH8jb/rcJC0qy1S2D1YIHBNOv3t0mPmiBKUU +b4KZt4AJbXQQLkfr1D1D8SUV; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:55396 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1clgA9-0005L7-0g; Wed, 08 Mar 2017 11:18:13 -0700 To: Mehmet Ersue , 'Kent Watsen' , 'Susan Hares' , netmod@ietf.org References: <01a101d29757$b405beb0$1c113c10$@ndzh.com> <017401d29767$41970e50$c4c52af0$@gmail.com> <00f801d29770$7a42dfa0$6ec89ee0$@ndzh.com> <027a01d29781$24d32b40$6e7981c0$@gmail.com> <24CF7954-A7B3-4550-AFF7-9898EE175FA2@juniper.net> <013901d29825$264ae4a0$72e0ade0$@gmail.com> From: Lou Berger Message-ID: <4986ca5e-712a-291b-2fe0-3db4b820dda2@labn.net> Date: Wed, 8 Mar 2017 13:18:10 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <013901d29825$264ae4a0$72e0ade0$@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1clgA9-0005L7-0g X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:55396 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 18:18:19 -0000 Hi Mehmet/Sue, Our (NETMOD chair's) plan is to have had sufficient on-list discussion so that we can submit the updated charter to the IESG *before* the Chicago meeting, and then to review the changes in Chicago. We want to ensure that we have full participation and input on the list as this *is* official process and we want to be sensitive to those who may not be able to travel to this meeting. Lou On 3/8/2017 11:00 AM, Mehmet Ersue wrote: > What I meant with joint session can be achieved with a (e.g. 20-30min) time-slot in NETMOD or NETCONF session on Tuesday where we invite I2RS people to attend. We can discuss the charter details and agree "all together" on the plan and work split. > > Does this make sense? > > Mehmet > >> -----Original Message----- >> From: Kent Watsen [mailto:kwatsen@juniper.net] >> Sent: Wednesday, March 8, 2017 1:51 AM >> To: Mehmet Ersue ; 'Susan Hares' >> ; netmod@ietf.org >> Cc: netmod-chairs@ietf.org >> Subject: Re: [netmod] draft netmod charter update proposal >> >> Hi Sue, >> >> First, please be aware that the next version of revised-datastores draft >> further defines the control-plane datastore concept. This includes providing >> guidelines that other WGs can follow to define their own control-plane >> datastores, and includes an Appendix section outlining the creation of an >> "ephemeral" datastore. The idea is to give the I2RS WG the ability to define >> datastore(s) as needed >> (read: future I2RS WG drafts). >> >> Regarding: >> >>> Does c) and d) include additions to include I2RS ephemeral state >>> as part of an I2RS control plane protocol? If not, which WG >>> works on the I2RS ephemeral additions to Yang for control plane data >>> stores? >> I don't fully understand the question, but believe that the NETMOD activities >> needed to support I2RS are all covered by a), b), and c). >> Things that belong to NETCONF WG will include any needed changes to >> protocol, YANG-Library, or any other draft maintained by that WG. >> Everything else goes to I2RS. >> >> I'm not sure what Mehmet means by a "joint session", but I think that it's too >> late to add such a session to the IETF Agenda at this point. That said, I plan a >> schedule another datastore breakout session (likely on Wed morning) that >> could be used to discuss I2RS some, and I also plan on attending the I2RS >> meeting Wed afternoon. >> >> Kent >> >> >> -----ORIGINAL MESSAGE----- >> >> Sounds good as a first approximation. Though we need to discuss the details >> and agree. >> It might be useful to plan a joint session on Tue or Wed in Chicago. >> >> Cheers, >> Mehmet >> >>> -----Original Message----- >>> From: Susan Hares [mailto:shares@ndzh.com] >>> Sent: Tuesday, March 7, 2017 7:27 PM >>> To: 'Mehmet Ersue' ; 'Kent Watsen' >>> ; netmod@ietf.org >>> Cc: netmod-chairs@ietf.org >>> Subject: RE: [netmod] draft netmod charter update proposal >>> >>> Mehmet: >>> >>> Thank you for the excellent question clarifying my questions. My >> questions >>> (b) - related to protocol extension for I2RS for RESTCONF, NETCONF or >> CoAP. >>> I have removed that one. >>> >>> I restate my question below, and the [xx] indicates my understanding. >>> >>> Does c and d state the following are handled: >>> 1) informational concepts for the DS handling - [Netmod] >>> 2) generic extensions to Yang to describe control plane datastore yang >>> modules - [netmod] >>> 3) generic extensions to Yang to describe the ephemeral state in >>> control plane yang modules - [I2RS] >>> 4) I2RS specific extensions to support the I2RS control plane >>> datastore's validation - [I2RS] >>> 5) Any I2RS Yang modules- [I2RS] >>> >>> To provide precision on this point, I will give examples of work >>> related >> to >>> each question: >>> 1) draft-ietf-netmod-revised-datastores-00.txt [netmod] >>> 2) extensions to describe control plane data store yang modules: >>> a) control plane data store definitions added to >> draft-ietf-netmod-yang- >>> model-classification [netmod] >>> b) extensions to the Yang 1.1 - to provide a syntax to describe >> datastores in >>> which a module exists >>> datastore should include syntax to identify identity and >> prioritization >>> config data store. [netmod] >>> c) extension to describe the merged tree in applied datastore and >> opstate >>> datastore [netmod] >>> d) mount extensions that allow mounting modules in different >>> datastores >>> >>> 3) generic extensions to describe ephemeral state the I2RS control >>> plane datastore [I2RS] >>> a) extensions can define validation specific to I2RS control >>> plane datastore. >>> b) rpc can be used for validation of modules >>> that seek to mounted in either the I2RS control plane >>> datastore or >> the >>> configuration data store. >>> >>> 4) I2RS specific extensions to support I2RS features in the I2RS >>> control >> plane >>> data store. >>> >>> My earlier: - is a question for NETCONF/RESTCONF, or CoAP. >>> b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF) >>> to enable the usage of DS - [protocol group or WG] >>> >>> >>> Sue >>> >>> >>> -----Original Message----- >>> From: Mehmet Ersue [mailto:mersue@gmail.com] >>> Sent: Tuesday, March 7, 2017 12:21 PM >>> To: 'Susan Hares'; 'Kent Watsen'; netmod@ietf.org >>> Cc: netmod-chairs@ietf.org >>> Subject: RE: [netmod] draft netmod charter update proposal >>> >>> Hi Sue, >>> >>> AFAICS your question kind of mixes between "I2RS control plane protocol" >>> and "ephemeral additions to Yang". >>> I believe different WGs are responsible for the part they own. >>> E.g. protocol-specific part should be done in the WG owning the protocol. >>> >>> Can you please differentiate in your question between the aspects >>> below (my assumption in [ ]? >>> a) informational concept for the DS handling [netmod] >>> b) standard extensions to the protocol (e.g. I2RS or NETCONF/RESTCONF) >>> to enable the usage of DS [protocol WGs, e.g. I2RS] >>> c) generic extensions to YANG language usable by many protocols >>> [netmod] >>> d) any specific YANG modules necessary for the use of DS [protocols >>> WGs] >>> >>> BR, >>> Mehmet >>> >>>> -----Original Message----- >>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan >>> Hares >>>> Sent: Tuesday, March 7, 2017 4:30 PM >>>> To: 'Kent Watsen' ; netmod@ietf.org >>>> Cc: netmod-chairs@ietf.org >>>> Subject: Re: [netmod] draft netmod charter update proposal >>>> >>>> Kent and Lou: >>>> >>>> Clarifying questions: >>>> >>>> Does c) and d) include additions to include I2RS ephemeral state as >>>> part >>> of >>>> an I2RS control plane protocol? If not, which WG works on the I2RS >>>> ephemeral additions to Yang for control plane data stores? >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent >>> Watsen >>>> Sent: Wednesday, February 22, 2017 7:25 PM >>>> To: netmod@ietf.org >>>> Cc: netmod-chairs@ietf.org >>>> Subject: [netmod] draft netmod charter update proposal >>>> >>>> >>>> Hi NETMOD WG, >>>> >>>> Please find below the draft charter update which we provided to our >>>> AD for review. Comments are welcomed. Authors, please note the >>>> milestone dates. >>>> >>>> Kent (and Lou) >>>> >>>> >>>> >>>> >>>> Network Modeling (NETMOD) >>>> ------------------------- >>>> >>>> Charter >>>> >>>> Current Status: Active >>>> >>>> Chairs: >>>> Lou Berger >>>> Kent Watsen >>>> >>>> Operations and Management Area Directors: >>>> Benoit Claise >>>> Joel Jaeggli >>>> >>>> Operations and Management Area Advisor: >>>> Benoit Claise >>>> >>>> Secretary: >>>> Zitao (Michael) Wang >>>> >>>> Mailing Lists: >>>> General Discussion: netmod@ietf.org >>>> To Subscribe: https://www.ietf.org/mailman/listinfo/netmod >>>> Archive: https://mailarchive.ietf.org/arch/browse/netmod/ >>>> >>>> Description of Working Group: >>>> >>>> The Network Modeling (NETMOD) working group is responsible for >>>> the YANG >>>> data modeling language, and guidelines for developing YANG models. >>> The >>>> NETMOD working group addresses general topics related to the use >>>> of >>> the >>>> YANG language and YANG models, for example, the mapping of YANG >>>> modeled >>>> data into various encodings. Finally, the NETMOD working group also >>>> defines core YANG models used as basic YANG building blocks, and >> YANG >>>> models that do not otherwise fall under the charter of any other IETF >>>> working group. >>>> >>>> The NETMOD WG is responsible for: >>>> >>>> a) Maintaining the data modeling language YANG. This effort entails >>>> periodically updating the specification to address new >> requirements >>>> as they arise. >>>> >>>> b) Maintaining the guidelines for developing YANG models. This >> effort >>>> is primarily driven by updates made to the YANG specification. >>>> >>>> c) Maintaining a conceptual framework in which YANG models are used. >>>> This effort entails describing the context that network management >>>> protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, and >>>> how certain YANG statements interact in that context. >>>> >>>> d) Maintaining encodings for YANG modeled data. This effort entails >>>> updating encodings already defined by the NETMOD working (XML >> and >>>> JSON) to accommodate changes to the YANG specification, and >> defining >>>> new encodings that are needed and yet do not fall under the >> charter >>>> of any other active IETF working group. >>>> >>>> e) Maintaining YANG models used as basic YANG building blocks. This >>>> effort entails updating existing YANG models (ietf-yang-types and >>>> ietf-inet-types) as needed, as well as defining additional >>>> core >> YANG >>>> data models when necessary. >>>> >>>> f) Defining and maintaining YANG models that do not fall under the >>>> charter of any other active IETF working group. >>>> >>>> The NETMOD working group consults with the NETCONF working group >> to >>>> ensure that new requirements are and understood and can be met by >>>> the protocols developed within that working group (e.g., NETCONF >>>> and RESTCONF). The NETMOD working group coordinates with other >>>> working groups on possible extensions to YANG to address new >> modeling >>>> requirements and, when needed, which group will run the process on a >>>> specific model. >>>> >>>> The NETMOD working group does not serve as a review team for YANG >>>> modules developed by other working groups. Instead, the YANG >> doctors, >>>> as organized by the OPS area director responsible for network >>>> management, will act as advisors for other working groups and provide >>>> YANG reviews for the OPS area directors. >>>> >>>> Milestones: >>>> >>>> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for >> publication >>>> Mar 2016 - Submit draft-ietf-netmod-yang-model-classification to IESG >>>> for publication >>>> Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for >>> publication >>>> Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for publication >>>> Mar 2017 - Submit draft-ietf-netmod-entity to IESG for publication >>>> Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for >>>> publication >>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for >>> publication >>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for >>>> publication >>>> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for >>>> publication >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> >> > > From nobody Wed Mar 8 10:44:40 2017 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 209B1129442; Wed, 8 Mar 2017 10:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 l2jM5KKN2346; Wed, 8 Mar 2017 10:44:37 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0130.outbound.protection.outlook.com [104.47.32.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D60312944E; Wed, 8 Mar 2017 10:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GjZEcpqSYyHFvrG0NaoUiZjXbW+zTnpvkwx9eFox7Bo=; b=af2slWrXzhLRzm1dLllvMY5xcgHXfGuaJ2puIf2KqbXYgylyryrJlQ70Li2gF1Eu+PB6UDI+O5mKeYEqSJPcmw6cRSOY3DtXer/pKJTFeDxmYNDe6Dapk19tKgOUScCagMjZ6xeGowGt28z2pmWXICNNEGyF5jLyP8gNZKPaXfI= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Wed, 8 Mar 2017 18:44:35 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0961.012; Wed, 8 Mar 2017 18:44:35 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] draft netmod charter update proposal Thread-Index: AQHSjWtMgvd1I9y/IUSjVG5c54oSBqF9KfeA///YNICAAaCFAIAAJwsAgAQrygCACBPhAA== Date: Wed, 8 Mar 2017 18:44:35 +0000 Message-ID: References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> In-Reply-To: <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:hxX27evgddiD/gUX0E/b+h8lepYQ/oP0luPj3MoodqbAXiqrQMNePoleZ+znN0e1gad0UzBu64WyXYdmDJchvH3T2/koYzLFyPfKuXStXANgaYUJMWcm49WOQZkWvKI8TowSANaAuJKwGgePOoqFq5lzzlPIr8hyGvkfuObzUczq2an+jDAY0Lxtn84qsCGO+GyeZ3F5lsIfh6QLK18uZb1n99ArS0mMZy7PgDsvzq26KGTmKCovhZ2T08HRc7BA8+Uhm+KT3zouhBj4y3s5aohF2MqqOYkwp/mfg50dHNWUdBK3+/jCyOgRQ25QY17HRAtbT/IA/vB8t6E/B8tEFw== x-ms-office365-filtering-correlation-id: 89eca4ff-2e24-4e83-3bbe-08d466532ae8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35073007944872)(138986009662008)(95692535739014)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123558025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(45074003)(6512007)(2900100001)(6306002)(25786008)(1730700003)(86362001)(5640700003)(6486002)(561944003)(36756003)(8936002)(5660300001)(6436002)(8676002)(3660700001)(4001350100001)(50986999)(229853002)(6506006)(54356999)(122556002)(77096006)(305945005)(76176999)(189998001)(2950100002)(99286003)(93886004)(2351001)(15650500001)(81166006)(66066001)(33656002)(106116001)(3846002)(102836003)(83506001)(4326008)(38730400002)(110136004)(83716003)(53936002)(6246003)(6116002)(450100002)(3280700002)(7736002)(82746002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 08 Mar 2017 18:44:35.3326 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Cc: "netmod-chairs@ietf.org" Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 18:44:39 -0000 DQoNCg0KSGkgTkVUTU9EIFdHLA0KDQpQbGVhc2UgZmluZCBiZWxvdyBkcmFmdC00IGhhdmluZyB0 aGUgZm9sbG93aW5nIGNoYW5nZToNCg0KIC0gYWRkZWQgIihlLmcuLCBJMlJTLCBSVEdXRykiIHRv IGEgc2VudGVuY2UuDQoNCkhpIFN1ZSwgTG91IGFuZCBJIGxvb2tlZCBhdCB0aGUgcHJvcG9zZWQg Y2hhcnRlciBhbmQgZm91bmQgYSBzZW50ZW5jZQ0KdGhhdCBuaWNlbHkgZGVzY3JpYmVzIG91ciBX RydzIGludGVudCB0byB3b3JrIHdpdGggYW5kIHN1cHBvcnQgb3RoZXINCldHcyAoYmV5b25kIE5F VENPTkYpLCBidXQgd2UgZmVsdCB0aGF0IHRoZSB0ZXh0IGNvdWxkIGJlIG1hZGUgbW9yZSANCmNs ZWFyIGJ5IGFkZGluZyBpbiB0aGUgYWJvdmUtbWVudGlvbmVkIGNoYW5nZS4gIEJleW9uZCB0aGlz LCBhbmQgdGhlDQpleGlzdGluZyBhKSwgYiksIGFuZCBjKSwgd2UgYmVsaWV2ZSB0aGF0IHRoZSBj aGFydGVyIHByb3Bvc2FsIGNvdmVycw0Kb3VyIHN1cHBvcnQgZm9yIEkyUlMsIGRvIHlvdSBhZ3Jl ZT8NCg0KSGkgTWVobWV0LCByZWdhcmRpbmcgcHV0dGluZyBhIHNob3J0IGRlc2NyaXB0aW9uIGFu ZCB0aGUgaW50ZW5kZWQgc3RhdHVzIA0KZm9yIGVhY2ggZHJhZnQgaW50byB0aGUgY2hhcnRlciwg d2UgdW5kZXJzdGFuZCB0aGF0IHRoaXMgaXMgaG93IE5FVENPTkYNCmNoYXJ0ZXJzIGFyZSBzdHJ1 Y3R1cmVkLCBidXQgaXQgaXMgbm90IG91ciBwcmFjdGljZSwgYXMgdGhlIGluZm9ybWF0aW9uDQpp cyBhdmFpbGFibGUgYXQgdGhlIHRvcCBvZiBlYWNoIGRyYWZ0LCBhbmQgYWxzbyBiZWNhdXNlIHRo aXMgaW5mb3JtYXRpb24NCm5lZWQgbm90IGJlIGZpeGVkIHdoZW4gdGhlIG1pbGVzdG9uZSBpcyBh ZGRlZC4NCg0KQWxsLCBBbnkgb3RoZXIgY29tbWVudHM/DQoNCktlbnQNCg0KDQoNCg0KTmV0d29y ayBNb2RlbGluZyAoTkVUTU9EKSAgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkNoYXJ0 ZXINCg0KQ3VycmVudCBTdGF0dXM6IEFjdGl2ZQ0KDQpDaGFpcnM6DQogICBMb3UgQmVyZ2VyIDxs YmVyZ2VyQGxhYm4ubmV0Pg0KICAgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+DQoN Ck9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQgQXJlYSBEaXJlY3RvcnM6DQogICBCZW5vaXQgQ2xh aXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4NCiAgIEpvZWwgSmFlZ2dsaSA8am9lbGphQGJvZ3VzLmNv bT4NCg0KT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudCBBcmVhIEFkdmlzb3I6DQogICBCZW5vaXQg Q2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4NCg0KU2VjcmV0YXJ5Og0KICAgWml0YW8gKE1pY2hh ZWwpIFdhbmcgPHdhbmd6aXRhb0BodWF3ZWkuY29tPg0KDQpNYWlsaW5nIExpc3RzOg0KICAgR2Vu ZXJhbCBEaXNjdXNzaW9uOiBuZXRtb2RAaWV0Zi5vcmcNCiAgIFRvIFN1YnNjcmliZTogICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgIEFyY2hpdmU6 ICAgICAgICAgICAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9uZXRt b2QvDQoNCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6DQoNCiAgIFRoZSBOZXR3b3JrIE1v ZGVsaW5nIChORVRNT0QpIHdvcmtpbmcgZ3JvdXAgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBZQU5H DQogICBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlLCBhbmQgZ3VpZGVsaW5lcyBmb3IgZGV2ZWxvcGlu ZyBZQU5HIG1vZGVscy4gIFRoZQ0KICAgTkVUTU9EIHdvcmtpbmcgZ3JvdXAgYWRkcmVzc2VzIGdl bmVyYWwgdG9waWNzIHJlbGF0ZWQgdG8gdGhlIHVzZSBvZiB0aGUNCiAgIFlBTkcgbGFuZ3VhZ2Ug YW5kIFlBTkcgbW9kZWxzLCBmb3IgZXhhbXBsZSwgdGhlIG1hcHBpbmcgb2YgWUFORyBtb2RlbGVk DQogICBkYXRhIGludG8gdmFyaW91cyBlbmNvZGluZ3MuICBGaW5hbGx5LCB0aGUgTkVUTU9EIHdv cmtpbmcgZ3JvdXAgDQogICBhbHNvIGRlZmluZXMgY29yZSBZQU5HIG1vZGVscyB1c2VkIGFzIGJh c2ljIFlBTkcgYnVpbGRpbmcgYmxvY2tzLCBhbmQgDQogICBZQU5HIG1vZGVscyB0aGF0IGRvIG5v dCBvdGhlcndpc2UgZmFsbCB1bmRlciB0aGUgY2hhcnRlciBvZiBhbnkgb3RoZXIgDQogICBJRVRG IHdvcmtpbmcgZ3JvdXAuDQogIA0KVGhlIE5FVE1PRCBXRyBpcyByZXNwb25zaWJsZSBmb3I6DQoN CiAgIGEpIE1haW50YWluaW5nIHRoZSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIFlBTkcuICBUaGlz IGVmZm9ydCBlbnRhaWxzDQogICAgICBwZXJpb2RpY2FsbHkgdXBkYXRpbmcgdGhlIHNwZWNpZmlj YXRpb24gdG8gYWRkcmVzcyBuZXcgcmVxdWlyZW1lbnRzDQogICAgICBhcyB0aGV5IGFyaXNlLg0K DQogICBiKSBNYWludGFpbmluZyB0aGUgZ3VpZGVsaW5lcyBmb3IgZGV2ZWxvcGluZyBZQU5HIG1v ZGVscy4gIFRoaXMgZWZmb3J0DQogICAgICBpcyBwcmltYXJpbHkgZHJpdmVuIGJ5IHVwZGF0ZXMg bWFkZSB0byB0aGUgWUFORyBzcGVjaWZpY2F0aW9uLg0KDQogICBjKSBNYWludGFpbmluZyBhIGNv bmNlcHR1YWwgZnJhbWV3b3JrIGluIHdoaWNoIFlBTkcgbW9kZWxzIGFyZSB1c2VkLg0KICAgICAg VGhpcyBlZmZvcnQgZW50YWlscyBkZXNjcmliaW5nIHRoZSBnZW5lcmljIGNvbnRleHQgdGhhdCBp biBZQU5HDQogICAgICBleGlzdHMgYW5kIGhvdyBjZXJ0YWluIFlBTkcgc3RhdGVtZW50cyBpbnRl cmFjdCBpbiB0aGF0IGNvbnRleHQuDQogICAgICBBbiBleGFtcGxlIG9mIHRoaXMgaXMgWUFORydz IHJlbGF0aW9uc2hpcCB3aXRoIGRhdGFzdG9yZXMuDQoNCiAgIGQpIE1haW50YWluaW5nIGVuY29k aW5ncyBmb3IgWUFORyBtb2RlbGVkIGRhdGEuICBUaGlzIGVmZm9ydCBlbnRhaWxzDQogICAgICB1 cGRhdGluZyBlbmNvZGluZ3MgYWxyZWFkeSBkZWZpbmVkIGJ5IHRoZSBORVRNT0Qgd29ya2luZyAo WE1MIGFuZA0KICAgICAgSlNPTikgdG8gYWNjb21tb2RhdGUgY2hhbmdlcyB0byB0aGUgWUFORyBz cGVjaWZpY2F0aW9uLCBhbmQgZGVmaW5pbmcNCiAgICAgIG5ldyBlbmNvZGluZ3MgdGhhdCBhcmUg bmVlZGVkLCBhbmQgeWV0IGRvIG5vdCBmYWxsIHVuZGVyIHRoZSBjaGFydGVyDQogICAgICBvZiBh bnkgb3RoZXIgYWN0aXZlIElFVEYgd29ya2luZyBncm91cC4NCg0KICAgZSkgTWFpbnRhaW5pbmcg WUFORyBtb2RlbHMgdXNlZCBhcyBiYXNpYyBZQU5HIGJ1aWxkaW5nIGJsb2Nrcy4gIFRoaXMNCiAg ICAgIGVmZm9ydCBlbnRhaWxzIHVwZGF0aW5nIGV4aXN0aW5nIFlBTkcgbW9kZWxzIChpZXRmLXlh bmctdHlwZXMgYW5kDQogICAgICBpZXRmLWluZXQtdHlwZXMpIGFzIG5lZWRlZCwgYXMgd2VsbCBh cyBkZWZpbmluZyBhZGRpdGlvbmFsIGNvcmUgWUFORw0KICAgICAgZGF0YSBtb2RlbHMgd2hlbiBu ZWNlc3NhcnkuDQoNCiAgIGYpIERlZmluaW5nIGFuZCBtYWludGFpbmluZyBZQU5HIG1vZGVscyB0 aGF0IGRvIG5vdCBmYWxsIHVuZGVyIHRoZQ0KICAgICAgY2hhcnRlciBvZiBhbnkgb3RoZXIgYWN0 aXZlIElFVEYgd29ya2luZyBncm91cC4NCg0KICAgVGhlIE5FVE1PRCB3b3JraW5nIGdyb3VwIGNv bnN1bHRzIHdpdGggdGhlIE5FVENPTkYgd29ya2luZyBncm91cCB0bw0KICAgZW5zdXJlIHRoYXQg bmV3IHJlcXVpcmVtZW50cyBhcmUgdW5kZXJzdG9vZCBhbmQgY2FuIGJlIG1ldCBieSB0aGUNCiAg IHByb3RvY29scyAoZS5nLiwgTkVUQ09ORiBhbmQgUkVTVENPTkYpIGRldmVsb3BlZCB3aXRoaW4g dGhhdCB3b3JraW5nDQogICBncm91cC4gIFRoZSBORVRNT0Qgd29ya2luZyBncm91cCBjb29yZGlu YXRlcyB3aXRoIG90aGVyIHdvcmtpbmcgZ3JvdXBzDQogICAoZS5nLiwgSTJSUywgUlRHV0cpIG9u IHBvc3NpYmxlIGV4dGVuc2lvbnMgdG8gWUFORyB0byBhZGRyZXNzIG5ldw0KICAgbW9kZWxpbmcg cmVxdWlyZW1lbnRzIGFuZCwgd2hlbiBuZWVkZWQsIHdoaWNoIGdyb3VwIHdpbGwgcnVuIHRoZQ0K ICAgcHJvY2VzcyBvbiBhIHNwZWNpZmljIG1vZGVsLg0KDQogICBUaGUgTkVUTU9EIHdvcmtpbmcg Z3JvdXAgZG9lcyBub3Qgc2VydmUgYXMgYSByZXZpZXcgdGVhbSBmb3IgWUFORw0KICAgbW9kdWxl cyBkZXZlbG9wZWQgYnkgb3RoZXIgd29ya2luZyBncm91cHMuIEluc3RlYWQsIHRoZSBZQU5HIGRv Y3RvcnMsDQogICBhcyBvcmdhbml6ZWQgYnkgdGhlIE9QUyBhcmVhIGRpcmVjdG9yIHJlc3BvbnNp YmxlIGZvciBuZXR3b3JrDQogICBtYW5hZ2VtZW50LCB3aWxsIGFjdCBhcyBhZHZpc29ycyBmb3Ig b3RoZXIgd29ya2luZyBncm91cHMgYW5kIHByb3ZpZGUNCiAgIFlBTkcgcmV2aWV3cyBmb3IgdGhl IE9QUyBhcmVhIGRpcmVjdG9ycy4NCg0KTWlsZXN0b25lczoNCiAgDQogICBEb25lICAgICAtIFN1 Ym1pdCBkcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9u DQogICBNYXIgMjAxNyAtIFN1Ym1pdCBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLW1vZGVsLWNsYXNz aWZpY2F0aW9uIHRvIElFU0cNCiAgICAgICAgICAgICAgZm9yIHB1YmxpY2F0aW9uDQogICBNYXIg MjAxNyAtIFN1Ym1pdCBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwgdG8gSUVTRyBmb3IgcHVi bGljYXRpb24NCiAgIEFwciAyMDE3IC0gU3VibWl0IGRyYWZ0LWlldGYtbmV0bW9kLWVudGl0eSB0 byBJRVNHIGZvciBwdWJsaWNhdGlvbg0KICAgQXByIDIwMTcgLSBTdWJtaXQgZHJhZnQtaWV0Zi1u ZXRtb2Qtc3lzbG9nLW1vZGVsIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uDQogICBPY3QgMjAxNyAt IFN1Ym1pdCBkcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQgdG8gSUVTRyBmb3IgcHVibGlj YXRpb24NCiAgIE9jdCAyMDE3IC0gU3VibWl0IGRyYWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0 YXN0b3JlcyB0byBJRVNHIGZvcg0KICAgICAgICAgICAgICBwdWJsaWNhdGlvbg0KICAgRGVjIDIw MTcgLSBTdWJtaXQgZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZyB0byBJRVNHIGZvcg0K ICAgICAgICAgICAgICBwdWJsaWNhdGlvbg0KICAgRGVjIDIwMTcgLSBTdWJtaXQgZHJhZnQtaWV0 Zi1uZXRtb2Qtc3ViLWludGYtdmxhbi15YW5nIHRvIElFU0cgZm9yDQogICAgICAgICAgICAgIHB1 YmxpY2F0aW9uDQoNCg0KDQoNCg0KDQoNCg0KDQo= From nobody Wed Mar 8 10:56:25 2017 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 6A7D6129487 for ; Wed, 8 Mar 2017 10:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 5FsHmG4N4-jd for ; Wed, 8 Mar 2017 10:56:22 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0105.outbound.protection.outlook.com [104.47.42.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E257E128AB0 for ; Wed, 8 Mar 2017 10:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rnNQeZOU0xpdu3RJT1Ep0lfiamHsaLAWAtawkvZS+xQ=; b=NOi7gvXV+YqAOEoZPpS8UEAllRoCo/4N7+U6dKiXBhGw4b7JhepqUieo2EfUxHOYmEfaieiB4KqfG7n4hmuxDC5D990lbNWUTPIwoOt49B/GJJexOUo/Rqiziabl8IsmPnmAY1aWocbHsivKLyUcTuP+t22XyBpNQ04zkMAH3K8= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Wed, 8 Mar 2017 18:56:20 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0961.012; Wed, 8 Mar 2017 18:56:20 +0000 From: Kent Watsen To: Juergen Schoenwaelder , Andy Bierman Thread-Topic: [netmod] stable reference for tree diagram notation Thread-Index: AQHSlD0Kf+J5u9nqmEehA2iSQMJSUaGDV2yAgAZYboCAAWJqgIAAGpCAgAAJ9ACAAAz1gP//u06A Date: Wed, 8 Mar 2017 18:56:20 +0000 Message-ID: <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> <82703e36-26f9-d459-c36a-c274861c5386@labn.net> <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> <20170308180211.GA9937@elstar.local> In-Reply-To: <20170308180211.GA9937@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:4e9dvWtGde0/Yn6IGmbqU87A386L+FL2Se8Gr9KTOnNyjqpxbuMz2+IRysb48VIeypfAp3nRro3bzQid+l+Kx7flrJHXtYR8xMDvMLjUlRJxYfAZPt7FomMxoHGjnT4hy+MBdUG0Tnyiwp8mfjrYxNbZJyZm574p4JK5XvqwXosO2ZJSS+dVR6pqXA2TKv3kG7XEXgXk+PPCmDfQqei/6MUAsbDibkWWTxBly5KcF6pqEeu79Ec/HG08yvUxpU6XcblczvrvrTc2DDoMRHxOG9a9sFF1YZqthj0eSjjbNDlK8HqTXOCbbK939BoZUCzrQVv8/bixlmI/e+yNdmQujg== x-ms-office365-filtering-correlation-id: d81b417d-954c-4cd6-ed92-08d46654cf6f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39850400002)(39410400002)(39840400002)(39860400002)(76104003)(38730400002)(3280700002)(2906002)(54356999)(6246003)(82746002)(229853002)(83506001)(3660700001)(33656002)(76176999)(4326008)(7736002)(50986999)(106116001)(3846002)(122556002)(305945005)(6506006)(6436002)(86362001)(77096006)(102836003)(6512007)(25786008)(53936002)(99286003)(5660300001)(83716003)(66066001)(93886004)(2950100002)(36756003)(6486002)(8936002)(81166006)(2900100001)(8676002)(189998001)(6116002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <99091CC31519FB43B70705641BE090CD@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 18:56:20.8337 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 18:56:23 -0000 DQoNCg0KPiBJIHRoaW5rIHdlIGNhbiBhbGxvdyBib3RoIGFuZCBsZWF2ZSBpdCB0byB0aGUgZG9j dW1lbnQgYXV0aG9yLiBFaXRoZXINCj4gdGhlIGF1dGhvciB1c2VzIGEgd2VsbCBrbm93biB0cmVl IGZvcm1hdCBhbmQgcmVmZXJzIHRvIGl0cyBkZWZpbml0aW9uDQo+IG9yIHRoZSBhdXRob3IgdXNl cyBhIG5vdCB5ZXQgd2VsbCBrbm93biB0cmVlIGZvcm1hdCBhbmQgdGhlbiBpdCBoYXMNCj4gdG8g YmUgZGVmaW5lZCBpbmxpbmU6DQoNCk5pY2UgY29tcHJvbWlzZSwgYnV0IGV2ZW4gdGhlbiBpdCB3 b3VsZCBiZSBoZWxwZnVsIGlmIGEgZHJhZnQgdGhhdCB3YW50cw0KdG8gdXNlIHNvbWUgY3VzdG9t LWFubm90YXRpb25zIGRvIHNvIG9uIHRvcCBvZiBhIHN0YW5kYXJkIHRyZWUtZGlhZ3JhbS4NClNv LCBmb3IgaW5zdGFuY2UsIHRoZSBkcmFmdCBtaWdodCBzYXkgc29tZXRoaW5nIGxpa2U6DQoNCiAg VHJlZSBkaWFncmFtcyB1c2VkIGluIHRoaXMgZHJhZnQgdXNlIG5vdGF0aW9uIGRlc2NyaWJlZCBp bg0KICBbUkZDWFhYWF0gd2l0aCB0aGUgZm9sbG93aW5nIGFkZGl0aW9uYWwgYW5ub3RhdGlvbnM6 DQoNCiAgICAgQCAtIG1lYW5zIC4uLg0KICAgICAjIC0gbWVhbnMgLi4uDQogICAgIGV0Yy4NCg0K VGhpcyB3YXksIHJlYWRlciBjYW4gZm9jdXMgbW9yZSBxdWlja2x5IG9uIHRoZSBkaWZmcywgYnV0 IGFsc28gdGhpcw0KbGlrZWx5IG1pbWljcyB3aGF0IGhhcHBlbmVkIGluIHJlYWxpdHkgKHN0YXJ0 IHdpdGggYHB5YW5nIC1mIHRyZWVgDQphbmQgdGhlbiBtYW51YWxseSBlZGl0IGZyb20gdGhlcmUp LiAgV2hhdCBkbyB5b3UgdGhpbms/DQoNCksuDQoNCg0K From nobody Wed Mar 8 11:15:01 2017 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 1F553129464 for ; Wed, 8 Mar 2017 11:15:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQx5EO97E-Iz for ; Wed, 8 Mar 2017 11:14:59 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9FBE1294B1 for ; Wed, 8 Mar 2017 11:14:58 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id n11so39075944wma.0 for ; Wed, 08 Mar 2017 11:14:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/oyGEeP2ubwoSYmSW6DnLafpD+eVd+ZkXTST6ZSMTcY=; b=rK2MlHtyP2V9AFeGEawUxexkJpFfTfnktsDFfXe46lCfmJYkfv1kXYElW+Bj6ddIVB xIBQi1NWWFdXyvY4S+mX6HPbY9jpy28Xf+F0KZGgHFD0R8/4zB+UGRApaCdYY/if8uVQ zQZd+5WcKUrFpnA0nhE91ScXal4L4ICWEVO5o3IJb+3SW0ix4Pwa/EoCusF15zXhyKaD CiG8KEJTGKbaYgmiibbyh6Gg281YzZdeY6bmWesHOG7wwMR6fjMv1fypFEAEqF7DZ4Y5 pAaa79nbl5gB5grxaLR24WRMJzZcv0ffRUVDBq8gjzIkzUoMde33P656cd6GR6Nh8Fug 7XNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/oyGEeP2ubwoSYmSW6DnLafpD+eVd+ZkXTST6ZSMTcY=; b=S71FCf1S9TgeClSvS3uDkJZGWWzp6euPtrI9lODh6YFPcU7on87EN0aA4UFaZ94dy3 p5mT3eFhQnFHOF9z8GaBjjBruGd6TG1gdJuxOPdZ6UHjE8LLniBACqsxbGjEOYvfCzxp /QVQUMaCUrk4dagEbZuaPopXdtzHm6cBFE0+0Ty9NAPLYmQV2hRSmznbZqfxkOV/oZO+ uQTtDxf5mrBeSmbvUvKODUJm98TevPl02RkZ6wJNkHJxqa90WzRNgkCbNS7YOdTcgTDO KEiT2rOvzwiFeWixk1O1BB1+Ah6k/VfdDWaV0rw8r6GkleIVQtiomFGL3RZrHTbl4Sy0 L+bw== X-Gm-Message-State: AMke39n4QPzhIlBD29cENe1FuYXtyuL2Rhxoq7NiaVyGp3wU3pYvSU2/hsNA5XIS6/eu2i9UtPY02wHEUqGapA== X-Received: by 10.28.103.3 with SMTP id b3mr23141763wmc.99.1489000497404; Wed, 08 Mar 2017 11:14:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Wed, 8 Mar 2017 11:14:56 -0800 (PST) In-Reply-To: <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> <82703e36-26f9-d459-c36a-c274861c5386@labn.net> <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> <20170308180211.GA9937@elstar.local> <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> From: Andy Bierman Date: Wed, 8 Mar 2017 11:14:56 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a114a91b2b7fcf8054a3cf191 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 19:15:00 -0000 --001a114a91b2b7fcf8054a3cf191 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 8, 2017 at 10:56 AM, Kent Watsen wrote: > > > > > I think we can allow both and leave it to the document author. Either > > the author uses a well known tree format and refers to its definition > > or the author uses a not yet well known tree format and then it has > > to be defined inline: > > Nice compromise, but even then it would be helpful if a draft that wants > to use some custom-annotations do so on top of a standard tree-diagram. > So, for instance, the draft might say something like: > > Tree diagrams used in this draft use notation described in > [RFCXXXX] with the following additional annotations: > > @ - means ... > # - means ... > etc. > > This way, reader can focus more quickly on the diffs, but also this > likely mimics what happened in reality (start with `pyang -f tree` > and then manually edit from there). What do you think? > > YANG is supposed to be prioritized for readers, writers, and then tool-makers. As a reader of YANG modules, I do not want people creating their own tree diagram syntax. I prefer all tree diagrams use the same syntax. > K. > > > Andy --001a114a91b2b7fcf8054a3cf191 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 8, 2017 at 10:56 AM, Kent Watsen <kwatsen@juniper.net> wrote:



> I think we can allow both and leave it to the document author. Either<= br> > the author uses a well known tree format and refers to its definition<= br> > or the author uses a not yet well known tree format and then it has > to be defined inline:

Nice compromise, but even then it would be helpful if a draft that wants to use some custom-annotations do so on top of a standard tree-diagram.
So, for instance, the draft might say something like:

=C2=A0 Tree diagrams used in this draft use notation described in
=C2=A0 [RFCXXXX] with the following additional annotations:

=C2=A0 =C2=A0 =C2=A0@ - means ...
=C2=A0 =C2=A0 =C2=A0# - means ...
=C2=A0 =C2=A0 =C2=A0etc.

This way, reader can focus more quickly on the diffs, but also this
likely mimics what happened in reality (start with `pyang -f tree`
and then manually edit from there).=C2=A0 What do you think?



YANG is supposed to be prioritized fo= r readers, writers, and then tool-makers.
As a reader of YANG mod= ules, I do not want people creating their own
tree diagram syntax= .=C2=A0 I prefer all tree diagrams use the same syntax.

=C2=A0
K.




Andy
=C2=A0

--001a114a91b2b7fcf8054a3cf191-- From nobody Wed Mar 8 11:34:33 2017 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 AE8EC129551 for ; Wed, 8 Mar 2017 11:34:32 -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, RP_MATCHES_RCVD=-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 qrvPvoIWpI8H for ; Wed, 8 Mar 2017 11:34:31 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5C41293FF for ; Wed, 8 Mar 2017 11:34:31 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4D4EB15D3; Wed, 8 Mar 2017 20:34:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xVvmqFLn_i1Q; Wed, 8 Mar 2017 20:34:29 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Mar 2017 20:34:30 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F0CD20039; Wed, 8 Mar 2017 20:34:30 +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 Auhv6fQNsPz9; Wed, 8 Mar 2017 20:34:29 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9D5420035; Wed, 8 Mar 2017 20:34:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 146A83E9C3DF; Wed, 8 Mar 2017 20:34:34 +0100 (CET) Date: Wed, 8 Mar 2017 20:34:34 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20170308193434.GA10080@elstar.local> Mail-Followup-To: Kent Watsen , Andy Bierman , "netmod@ietf.org" References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> <82703e36-26f9-d459-c36a-c274861c5386@labn.net> <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> <20170308180211.GA9937@elstar.local> <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 19:34:32 -0000 On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrote: > > This way, reader can focus more quickly on the diffs, but also this > likely mimics what happened in reality (start with `pyang -f tree` > and then manually edit from there). What do you think? > Manually edited tree diagrams? I hope not. Perhaps we should have text saying that tree diagrams are expected to be generated by tools and that they are expected to be consistent with the model (and hence they need to be updated with every change, hence usage of tools is a damn good idea). [I thought this is obvious but perhaps this is not.] /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 8 11:47:56 2017 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 C800812946E for ; Wed, 8 Mar 2017 11:47:54 -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, RP_MATCHES_RCVD=-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 FBW90LCtpuWb for ; Wed, 8 Mar 2017 11:47:53 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56249120725 for ; Wed, 8 Mar 2017 11:47:53 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 24FBF15CF; Wed, 8 Mar 2017 20:47:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7yDsDzIcm02t; Wed, 8 Mar 2017 20:47:51 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Mar 2017 20:47:51 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B82A920039; Wed, 8 Mar 2017 20:47:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BFXOsA0e4heI; Wed, 8 Mar 2017 20:47:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A4AB420035; Wed, 8 Mar 2017 20:47:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 20B963E9C434; Wed, 8 Mar 2017 20:47:56 +0100 (CET) Date: Wed, 8 Mar 2017 20:47:56 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20170308194756.GB10080@elstar.local> Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netmod@ietf.org" References: <20170303191348.GA3570@elstar.local> <20170307.185911.779366639761395028.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] rfc 6087bis - stress importance of instance examples X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 19:47:54 -0000 On Wed, Mar 08, 2017 at 05:40:44PM +0000, Kent Watsen wrote: > > > >> I think we should encourage authors to write examples. > > > > +1 And also encourage authors to validate the examples > > using their favorite YANG instance validation tool. > > > Please note this from the latest 6087bis update: > > 4.12. Module Usage Examples > > Each specification that defines one or more modules SHOULD contain > usage examples, either throughout the document or in an appendix. > This includes example XML instance document snippets to demonstrate > the intended usage of the YANG module(s). > > and I already wrote this: > > Nice addition, but should it say something about JSON, in addition to XML? > Perhaps that, unless there is a reason to only pick one encoding, examples > should be split between the two? - just throwing it out there to see if this is > something we might want to recommend...thoughts? > > https://mailarchive.ietf.org/arch/msg/netmod/dOpSYzM_J05Sdmgt-MyYmqJIUz0 > I think the purpose of section 4.12 is to encourage people to check that their definitions lead to reasonable instance documents. It is easy to choose identifiers in the schema that look reasonable in the schema but horrible in instance documents. The purpose of the examples should in general not be to showcase that YANG can have different instance representation formats. I would leave it to the WG to decide whether they prefer examples in JSON or XML. In LMAP, I once had examples in both XML and JSON and that was not useful (lots of additional pages with no real added value). All that said, you likely end up naming things slightly different depending on whether you look primarily at a JSON encoded instance document or an XML encoded instance document. But I do not care much as long as identifiers are reasonably consistent. /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 Mar 8 12:58:01 2017 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 A2D85129426 for ; Wed, 8 Mar 2017 12:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 vXjpxWdUiIED for ; Wed, 8 Mar 2017 12:57:59 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0113.outbound.protection.outlook.com [104.47.36.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B729129404 for ; Wed, 8 Mar 2017 12:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=va16I/yjjOVuALX6hv6nHQLsmpZGDl2KZcwXDGlOV6s=; b=gLHx3N4K7deILXuOyu0hcdjmQCtlEvKKfDJaO+DTAnuKjEwL/KT924+ylpav5DN6bJngAJjDm4SxuO4QytAwlpaGwUevenZOjytgdmozcQcMrFSfb7TUOZbJq7hu+veSMSkXrqAtg8Jlxz5BQcIj2ejEe3wW9k0DXgjg05oNeJo= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Wed, 8 Mar 2017 20:57:58 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0961.012; Wed, 8 Mar 2017 20:57:58 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [netmod] stable reference for tree diagram notation Thread-Index: AQHSlD0Kf+J5u9nqmEehA2iSQMJSUaGDV2yAgAZYboCAAWJqgIAAGpCAgAAJ9ACAAAz1gP//u06AgABeggD//8N6gA== Date: Wed, 8 Mar 2017 20:57:58 +0000 Message-ID: References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> <82703e36-26f9-d459-c36a-c274861c5386@labn.net> <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> <20170308180211.GA9937@elstar.local> <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> <20170308193434.GA10080@elstar.local> In-Reply-To: <20170308193434.GA10080@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:bJqNY3lj2c0caOBeIU6YK4Qsf7Mmq3ys3A8X0YqHnxensImNrL7O2h4GsuqwaDLS18JzrJCNoQEaeJTbaV/Q7C06l5eZSiTC8TiWGqJYvEZQbrChXkcTI4mzqqRM1f8Nhj6jA08zfy+CPtgRJIlT77UHOOnBrdZl6/cH0sApDXjXtF31QlrjQPkjOdXwQqMj5iatInZSgUe6lai7ufnGV0Q1Fa8kuIk5MHgPIeSh0pL/e6KJklrox7vHp2YU/mI7SF0fORQ0j630UNQc2yeEIXi9aBpwXpTmKuXQ7Ehycy+orM3A92NdBz/qr2dVZv4a1x7wzEvFknoAWmmoAC9fvg== x-ms-office365-filtering-correlation-id: c0b5aa20-6d8e-44c3-5a65-08d46665cd29 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(76104003)(305945005)(6116002)(8676002)(102836003)(8936002)(93886004)(122556002)(81166006)(106116001)(50986999)(54356999)(33656002)(3846002)(3280700002)(76176999)(86362001)(5660300001)(77096006)(189998001)(3660700001)(6916009)(2906002)(66066001)(7736002)(110136004)(36756003)(83716003)(6246003)(4326008)(53936002)(82746002)(99286003)(25786008)(229853002)(6506006)(6436002)(83506001)(6486002)(54906002)(38730400002)(2900100001)(2950100002)(6512007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 08 Mar 2017 20:57:58.4445 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 20:58:00 -0000 DQoNCg0KPj4gVGhpcyB3YXksIHJlYWRlciBjYW4gZm9jdXMgbW9yZSBxdWlja2x5IG9uIHRoZSBk aWZmcywgYnV0IGFsc28gdGhpcw0KPj4gbGlrZWx5IG1pbWljcyB3aGF0IGhhcHBlbmVkIGluIHJl YWxpdHkgKHN0YXJ0IHdpdGggYHB5YW5nIC1mIHRyZWVgDQo+PiBhbmQgdGhlbiBtYW51YWxseSBl ZGl0IGZyb20gdGhlcmUpLiAgV2hhdCBkbyB5b3UgdGhpbms/DQo+PiANCj4NCj4gTWFudWFsbHkg ZWRpdGVkIHRyZWUgZGlhZ3JhbXM/IEkgaG9wZSBub3QuIFBlcmhhcHMgd2Ugc2hvdWxkIGhhdmUg dGV4dA0KPiBzYXlpbmcgdGhhdCB0cmVlIGRpYWdyYW1zIGFyZSBleHBlY3RlZCB0byBiZSBnZW5l cmF0ZWQgYnkgdG9vbHMgYW5kDQo+IHRoYXQgdGhleSBhcmUgZXhwZWN0ZWQgdG8gYmUgY29uc2lz dGVudCB3aXRoIHRoZSBtb2RlbCAoYW5kIGhlbmNlIHRoZXkNCj4gbmVlZCB0byBiZSB1cGRhdGVk IHdpdGggZXZlcnkgY2hhbmdlLCBoZW5jZSB1c2FnZSBvZiB0b29scyBpcyBhIGRhbW4NCj4gZ29v ZCBpZGVhKS4NCj4gDQo+IFtJIHRob3VnaHQgdGhpcyBpcyBvYnZpb3VzIGJ1dCBwZXJoYXBzIHRo aXMgaXMgbm90Ll0NCg0KDQpSaWdodCwgYnV0IHdoYXQgaGFwcGVucyB3aGVuIHRoZSBkcmFmdCBw cmVjZWRlcyB0aGUgdG9vbCBiZWluZw0KdXBkYXRlZCAoZS5nLiwgc2NoZW1hLW1vdW50KT8gIEl0 J3MgYSByYXJlIGNhc2UgYW5kIHlvdSBhbHJlYWR5DQpzYWlkIGF1dGhvcnMgY2FuIGFkZHJlc3Mg aXQgb24gYSBjYXNlLWJ5LWNhc2UgYmFzaXMsIHNvIEkgdGhpbmsNCndlJ3JlIGNvdmVyZWQgZWl0 aGVyIHdheS4NCg0KSy4NCg0KDQo= From nobody Wed Mar 8 13:25:08 2017 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 ABCA21294D7; Wed, 8 Mar 2017 13:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 X02kWsEnEeds; Wed, 8 Mar 2017 13:25:03 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 D8968129555; Wed, 8 Mar 2017 13:25:02 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id v186so125162218wmd.0; Wed, 08 Mar 2017 13:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=KSox2xaXDZJUqHQsuPmJad5QGc1d2x/Dmj+OHtvgbJY=; b=fvztafFhFYLW2XGrRkiTXI+Qfa/bAr6V4PJK/B8yj85r+3YJ9KMNiXv6lixlgxdHsX MZ/qBg7RVFRhAAAozFVypuTNuH0yidObIxa9fR1hk/ky9YWdds12lJZJeI6cldDU6Lfx eSvG6527L23juOIOqMQDyR7ItF+hO/xLDjnqwyjx0F0I8k1x0JyrAeEGLC4UvgHbXWGi 3IFj07h4DUC45XzPusgppdGlssENO3LVZ8f2ANfhJF3/gJBlXO6wJLxQESkv5DSMkUi4 wEh1aCLIAGKgqkDZB7Rm23tkr30x2NqjXm0XHcKDZRg3sIOGYu3jHAqzXwoUSLOtWx5l gXtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=KSox2xaXDZJUqHQsuPmJad5QGc1d2x/Dmj+OHtvgbJY=; b=JGZ7EH4HVQWid4GFG4hwLB9+jD5vZnytJGq5NOkGuO27pHAli4zaXep8P8suNbOVvx 4ddX6BZQjllebIcWbk5zsI4/N67wRMvqhPzCSnA+I1sJI0dblzULhIRcj/ajzErhjtPV WLsKp92T/8c2mCjWwq1SyKLCEozfahTszEUISfzTzUOJ9pjXrgsXY+qZQmVECZnjTNOD 5Tjyc6Vr0bhec5IPHmSUtjx4+oGlDRKydVp0XAqUKjK0rF6IvB34Y9O2hDSifF9HW5OR e0ub7Hsw+G0A/oKJCmCvLcmiJ/8e86O+U+fsSfD8Pi2q8U0PeLdQBPE/JwKX98VPa2/P lXnQ== X-Gm-Message-State: AMke39l7RJlYXUW4TG1QyezqNPJpWgnW1r2C8MgB65MP8/z6xJ/YjJEkSliePFnWUet/LQ== X-Received: by 10.28.175.138 with SMTP id y132mr7787415wme.86.1489008301250; Wed, 08 Mar 2017 13:25:01 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B34156F.dip0.t-ipconnect.de. [91.52.21.111]) by smtp.gmail.com with ESMTPSA id t103sm5687483wrc.43.2017.03.08.13.24.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Mar 2017 13:25:00 -0800 (PST) From: "Mehmet Ersue" To: "'Lou Berger'" , "'Kent Watsen'" , "'Susan Hares'" , References: <01a101d29757$b405beb0$1c113c10$@ndzh.com> <017401d29767$41970e50$c4c52af0$@gmail.com> <00f801d29770$7a42dfa0$6ec89ee0$@ndzh.com> <027a01d29781$24d32b40$6e7981c0$@gmail.com> <24CF7954-A7B3-4550-AFF7-9898EE175FA2@juniper.net> <013901d29825$264ae4a0$72e0ade0$@gmail.com> <4986ca5e-712a-291b-2fe0-3db4b820dda2@labn.net> In-Reply-To: <4986ca5e-712a-291b-2fe0-3db4b820dda2@labn.net> Date: Wed, 8 Mar 2017 22:25:00 +0100 Message-ID: <01c001d29852$722b5b70$56821250$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gIsUOtUAnaIwygB1AGuegIZIUmAAZiY54sB+xxj7wGVJR/EoMuY8aA= Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0201.58C076AC.0030,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 21:25:07 -0000 Lou, I don't understand the plan change. We were discussing to have time for a joint charter discussion in = Chicago. Any decision/agreement in a physical WG session will be verified on the = maillist. In any case once we are finished on the maillist, Benoit will review = both together. The two charters from NETCONF/NETMOD have to go hand in hand and one = cannot be approved by IESG before the other. Mehmet > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, March 8, 2017 7:18 PM > To: Mehmet Ersue ; 'Kent Watsen' > ; 'Susan Hares' ; > netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: Re: [netmod] draft netmod charter update proposal >=20 > Hi Mehmet/Sue, >=20 > Our (NETMOD chair's) plan is to have had sufficient on-list discussion = so that > we can submit the updated charter to the IESG *before* the Chicago > meeting, and then to review the changes in Chicago. We want to ensure = that > we have full participation and input on the list as this > *is* official process and we want to be sensitive to those who may not = be > able to travel to this meeting. >=20 > Lou >=20 >=20 > On 3/8/2017 11:00 AM, Mehmet Ersue wrote: > > What I meant with joint session can be achieved with a (e.g. = 20-30min) > time-slot in NETMOD or NETCONF session on Tuesday where we invite I2RS > people to attend. We can discuss the charter details and agree "all = together" > on the plan and work split. > > > > Does this make sense? > > > > Mehmet > > > >> -----Original Message----- > >> From: Kent Watsen [mailto:kwatsen@juniper.net] > >> Sent: Wednesday, March 8, 2017 1:51 AM > >> To: Mehmet Ersue ; 'Susan Hares' > >> ; netmod@ietf.org > >> Cc: netmod-chairs@ietf.org > >> Subject: Re: [netmod] draft netmod charter update proposal > >> > >> Hi Sue, > >> > >> First, please be aware that the next version of revised-datastores > >> draft further defines the control-plane datastore concept. This > >> includes providing guidelines that other WGs can follow to define > >> their own control-plane datastores, and includes an Appendix = section > >> outlining the creation of an "ephemeral" datastore. The idea is to > >> give the I2RS WG the ability to define > >> datastore(s) as needed > >> (read: future I2RS WG drafts). > >> > >> Regarding: > >> > >>> Does c) and d) include additions to include I2RS ephemeral state > >>> as part of an I2RS control plane protocol? If not, which WG > >>> works on the I2RS ephemeral additions to Yang for control plane = data > >>> stores? > >> I don't fully understand the question, but believe that the NETMOD > >> activities needed to support I2RS are all covered by a), b), and = c). > >> Things that belong to NETCONF WG will include any needed changes to > >> protocol, YANG-Library, or any other draft maintained by that WG. > >> Everything else goes to I2RS. > >> > >> I'm not sure what Mehmet means by a "joint session", but I think = that > >> it's too late to add such a session to the IETF Agenda at this = point. > >> That said, I plan a schedule another datastore breakout session > >> (likely on Wed morning) that could be used to discuss I2RS some, = and > >> I also plan on attending the I2RS meeting Wed afternoon. > >> > >> Kent > >> > >> > >> -----ORIGINAL MESSAGE----- > >> > >> Sounds good as a first approximation. Though we need to discuss the > >> details and agree. > >> It might be useful to plan a joint session on Tue or Wed in = Chicago. > >> > >> Cheers, > >> Mehmet > >> > >>> -----Original Message----- > >>> From: Susan Hares [mailto:shares@ndzh.com] > >>> Sent: Tuesday, March 7, 2017 7:27 PM > >>> To: 'Mehmet Ersue' ; 'Kent Watsen' > >>> ; netmod@ietf.org > >>> Cc: netmod-chairs@ietf.org > >>> Subject: RE: [netmod] draft netmod charter update proposal > >>> > >>> Mehmet: > >>> > >>> Thank you for the excellent question clarifying my questions. My > >> questions > >>> (b) - related to protocol extension for I2RS for RESTCONF, NETCONF > >>> or > >> CoAP. > >>> I have removed that one. > >>> > >>> I restate my question below, and the [xx] indicates my = understanding. > >>> > >>> Does c and d state the following are handled: > >>> 1) informational concepts for the DS handling - [Netmod] > >>> 2) generic extensions to Yang to describe control plane datastore > >>> yang modules - [netmod] > >>> 3) generic extensions to Yang to describe the ephemeral state in > >>> control plane yang modules - [I2RS] > >>> 4) I2RS specific extensions to support the I2RS control plane > >>> datastore's validation - [I2RS] > >>> 5) Any I2RS Yang modules- [I2RS] > >>> > >>> To provide precision on this point, I will give examples of work > >>> related > >> to > >>> each question: > >>> 1) draft-ietf-netmod-revised-datastores-00.txt [netmod] > >>> 2) extensions to describe control plane data store yang modules: > >>> a) control plane data store definitions added to > >> draft-ietf-netmod-yang- > >>> model-classification [netmod] > >>> b) extensions to the Yang 1.1 - to provide a syntax to describe > >> datastores in > >>> which a module exists > >>> datastore should include syntax to identify identity and > >> prioritization > >>> config data store. [netmod] > >>> c) extension to describe the merged tree in applied datastore = and > >> opstate > >>> datastore [netmod] > >>> d) mount extensions that allow mounting modules in different > >>> datastores > >>> > >>> 3) generic extensions to describe ephemeral state the I2RS control > >>> plane datastore [I2RS] > >>> a) extensions can define validation specific to I2RS control > >>> plane datastore. > >>> b) rpc can be used for validation of modules > >>> that seek to mounted in either the I2RS control plane > >>> datastore or > >> the > >>> configuration data store. > >>> > >>> 4) I2RS specific extensions to support I2RS features in the I2RS > >>> control > >> plane > >>> data store. > >>> > >>> My earlier: - is a question for NETCONF/RESTCONF, or CoAP. > >>> b) standard extensions to the protocol (e.g. I2RS or > NETCONF/RESTCONF) > >>> to enable the usage of DS - [protocol group or WG] > >>> > >>> > >>> Sue > >>> > >>> > >>> -----Original Message----- > >>> From: Mehmet Ersue [mailto:mersue@gmail.com] > >>> Sent: Tuesday, March 7, 2017 12:21 PM > >>> To: 'Susan Hares'; 'Kent Watsen'; netmod@ietf.org > >>> Cc: netmod-chairs@ietf.org > >>> Subject: RE: [netmod] draft netmod charter update proposal > >>> > >>> Hi Sue, > >>> > >>> AFAICS your question kind of mixes between "I2RS control plane > protocol" > >>> and "ephemeral additions to Yang". > >>> I believe different WGs are responsible for the part they own. > >>> E.g. protocol-specific part should be done in the WG owning the > protocol. > >>> > >>> Can you please differentiate in your question between the aspects > >>> below (my assumption in [ ]? > >>> a) informational concept for the DS handling [netmod] > >>> b) standard extensions to the protocol (e.g. I2RS or > >>> NETCONF/RESTCONF) to enable the usage of DS [protocol WGs, e.g. > >>> I2RS] > >>> c) generic extensions to YANG language usable by many protocols > >>> [netmod] > >>> d) any specific YANG modules necessary for the use of DS = [protocols > >>> WGs] > >>> > >>> BR, > >>> Mehmet > >>> > >>>> -----Original Message----- > >>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan > >>> Hares > >>>> Sent: Tuesday, March 7, 2017 4:30 PM > >>>> To: 'Kent Watsen' ; netmod@ietf.org > >>>> Cc: netmod-chairs@ietf.org > >>>> Subject: Re: [netmod] draft netmod charter update proposal > >>>> > >>>> Kent and Lou: > >>>> > >>>> Clarifying questions: > >>>> > >>>> Does c) and d) include additions to include I2RS ephemeral state = as > >>>> part > >>> of > >>>> an I2RS control plane protocol? If not, which WG works on = the I2RS > >>>> ephemeral additions to Yang for control plane data stores? > >>>> > >>>> Sue > >>>> > >>>> -----Original Message----- > >>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent > >>> Watsen > >>>> Sent: Wednesday, February 22, 2017 7:25 PM > >>>> To: netmod@ietf.org > >>>> Cc: netmod-chairs@ietf.org > >>>> Subject: [netmod] draft netmod charter update proposal > >>>> > >>>> > >>>> Hi NETMOD WG, > >>>> > >>>> Please find below the draft charter update which we provided to = our > >>>> AD for review. Comments are welcomed. Authors, please note the > >>>> milestone dates. > >>>> > >>>> Kent (and Lou) > >>>> > >>>> > >>>> > >>>> > >>>> Network Modeling (NETMOD) > >>>> ------------------------- > >>>> > >>>> Charter > >>>> > >>>> Current Status: Active > >>>> > >>>> Chairs: > >>>> Lou Berger > >>>> Kent Watsen > >>>> > >>>> Operations and Management Area Directors: > >>>> Benoit Claise > >>>> Joel Jaeggli > >>>> > >>>> Operations and Management Area Advisor: > >>>> Benoit Claise > >>>> > >>>> Secretary: > >>>> Zitao (Michael) Wang > >>>> > >>>> Mailing Lists: > >>>> General Discussion: netmod@ietf.org > >>>> To Subscribe: = https://www.ietf.org/mailman/listinfo/netmod > >>>> Archive: = https://mailarchive.ietf.org/arch/browse/netmod/ > >>>> > >>>> Description of Working Group: > >>>> > >>>> The Network Modeling (NETMOD) working group is responsible for > >>>> the YANG > >>>> data modeling language, and guidelines for developing YANG = models. > >>> The > >>>> NETMOD working group addresses general topics related to the = use > >>>> of > >>> the > >>>> YANG language and YANG models, for example, the mapping of > YANG > >>>> modeled > >>>> data into various encodings. Finally, the NETMOD working = group also > >>>> defines core YANG models used as basic YANG building blocks, = and > >> YANG > >>>> models that do not otherwise fall under the charter of any = other IETF > >>>> working group. > >>>> > >>>> The NETMOD WG is responsible for: > >>>> > >>>> a) Maintaining the data modeling language YANG. This effort = entails > >>>> periodically updating the specification to address new > >> requirements > >>>> as they arise. > >>>> > >>>> b) Maintaining the guidelines for developing YANG models. = This > >> effort > >>>> is primarily driven by updates made to the YANG = specification. > >>>> > >>>> c) Maintaining a conceptual framework in which YANG models are > used. > >>>> This effort entails describing the context that network = management > >>>> protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, = and > >>>> how certain YANG statements interact in that context. > >>>> > >>>> d) Maintaining encodings for YANG modeled data. This effort = entails > >>>> updating encodings already defined by the NETMOD working = (XML > >> and > >>>> JSON) to accommodate changes to the YANG specification, and > >> defining > >>>> new encodings that are needed and yet do not fall under the > >> charter > >>>> of any other active IETF working group. > >>>> > >>>> e) Maintaining YANG models used as basic YANG building blocks. = This > >>>> effort entails updating existing YANG models = (ietf-yang-types and > >>>> ietf-inet-types) as needed, as well as defining additional > >>>> core > >> YANG > >>>> data models when necessary. > >>>> > >>>> f) Defining and maintaining YANG models that do not fall under = the > >>>> charter of any other active IETF working group. > >>>> > >>>> The NETMOD working group consults with the NETCONF working > group > >> to > >>>> ensure that new requirements are and understood and can be met > by > >>>> the protocols developed within that working group (e.g., = NETCONF > >>>> and RESTCONF). The NETMOD working group coordinates with = other > >>>> working groups on possible extensions to YANG to address new > >> modeling > >>>> requirements and, when needed, which group will run the = process on > a > >>>> specific model. > >>>> > >>>> The NETMOD working group does not serve as a review team for > YANG > >>>> modules developed by other working groups. Instead, the YANG > >> doctors, > >>>> as organized by the OPS area director responsible for network > >>>> management, will act as advisors for other working groups and > provide > >>>> YANG reviews for the OPS area directors. > >>>> > >>>> Milestones: > >>>> > >>>> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for > >> publication > >>>> Mar 2016 - Submit draft-ietf-netmod-yang-model-classification = to > IESG > >>>> for publication > >>>> Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for > >>> publication > >>>> Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for = publication > >>>> Mar 2017 - Submit draft-ietf-netmod-entity to IESG for = publication > >>>> Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > >>>> publication > >>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for > >>> publication > >>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG = for > >>>> publication > >>>> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG = for > >>>> publication > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> netmod mailing list > >>>> netmod@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netmod > >>>> > >>>> _______________________________________________ > >>>> netmod mailing list > >>>> netmod@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netmod > >> > >> > > > > From nobody Wed Mar 8 13:47:38 2017 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 51BCD1295F5 for ; Wed, 8 Mar 2017 13:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 96c4dLwIo6hp for ; Wed, 8 Mar 2017 13:47:29 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 3346B1295D2 for ; Wed, 8 Mar 2017 13:47:29 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id n11so41917304wma.0 for ; Wed, 08 Mar 2017 13:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=CYvOyGevRjMcHp+yikFuzPjkhT6WPEsOM9mQL8rQ0Hs=; b=a1pzxHKgZdr4gNhlTnVfeNOVctVIg5PdafO1WEJ8PsK0SrOCr9W+ZeYIK02baOyOiH d79UrSvQ7iPPOBGQgdj74baNRgMTRsIh9Bsn7IlrVURPCaBJBzoyRcqIjE8vgq3msrfr MaA0QlaHG+51y/fkLNs2wOBJGQoPjMxACi6umq8yIetIMXSS42rP7cg45vSBKNUCT5Cv 3j8fq8IdgYhVauUNE/ls9pLo7JUibcVrFXcL1dHkBGv49Z5nOKBbxPlgYhD8a3glwjeR XXvgdiy9jxicWbU9U4KyMrtJEylQm/4Mznj3i2nspvEvZ7u1DQ8WrPpmFlnk21+lQ+Fc 2vMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=CYvOyGevRjMcHp+yikFuzPjkhT6WPEsOM9mQL8rQ0Hs=; b=Akp+nBglrDyNGCt9U6h6NYEsm2XmCVQ23V+4ueiPw8VhEqqnMj821mXcsgSpZdVTRU 5YMxWjP88DZBdiQxqx/GlQEP9JFIXtQNTUuQqZo4/q5mXX/4zizlThV2zmdu5JOp4ZMu Hj+qLfYVBwYUm8cXoIic0ejLybYp5GzbmzN5P4ttgmrkmI5HGatzj8n5XqUwZ8D53hW4 51BQBbO/Z92OzlyA065GIPWKMgdimBd/70hWA6KJ2sOcCzcdANvYqdyKOZWX+bfJa6/0 x2i9r6PHmAMDcLW2tv2UG8giqekAtYYCi7hkC+yqhLcN/fkHe/xBtW1t8Q7l625TU/iv h66Q== X-Gm-Message-State: AMke39m03lDuGYNFKqoU16RquQ7Cbs0pHZj1Z4o0NaoMqZy83LLkT/WoJ57v9xn9EemilQ== X-Received: by 10.28.68.69 with SMTP id r66mr24054882wma.115.1489009647491; Wed, 08 Mar 2017 13:47:27 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B34156F.dip0.t-ipconnect.de. [91.52.21.111]) by smtp.gmail.com with ESMTPSA id t63sm23032533wme.16.2017.03.08.13.47.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Mar 2017 13:47:26 -0800 (PST) From: "Mehmet Ersue" To: "'Kent Watsen'" , References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> In-Reply-To: Date: Wed, 8 Mar 2017 22:47:27 +0100 Message-ID: <01c601d29855$94b70470$be250d50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5nqDRVrgw Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0205.58C07BEE.00CF,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 21:47:31 -0000 Kent, > we understand that this is how NETCONF charters are structured, but it is not our practice, AFAIK it was the NETMOD practice for the charters until today. I did not ask more than written in the current charter. It would be good to bring the high-level topics in relation to the WG items. > as the information is available at the top of each draft, and also because this information need not be fixed when the milestone is added. I believe a WG charter should be self-sufficient covering the target definition and intended status of the WG items. Otherwise one can change the target for a WG item by simply editing the draft abstract anytime. BTW: We agreed in diverse discussions that the DS concept is Informational in nature. I think this should be corrected in the draft. Mehmet > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Wednesday, March 8, 2017 7:45 PM > To: netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: Re: [netmod] draft netmod charter update proposal > > > > > Hi NETMOD WG, > > Please find below draft-4 having the following change: > > - added "(e.g., I2RS, RTGWG)" to a sentence. > > Hi Sue, Lou and I looked at the proposed charter and found a sentence that > nicely describes our WG's intent to work with and support other WGs > (beyond NETCONF), but we felt that the text could be made more clear by > adding in the above-mentioned change. Beyond this, and the existing a), b), > and c), we believe that the charter proposal covers our support for I2RS, do > you agree? > > Hi Mehmet, regarding putting a short description and the intended status for > each draft into the charter, we understand that this is how NETCONF charters > are structured, but it is not our practice, as the information is available at the > top of each draft, and also because this information need not be fixed when > the milestone is added. > > All, Any other comments? > > Kent > > > > > Network Modeling (NETMOD) > ------------------------- > > Charter > > Current Status: Active > > Chairs: > Lou Berger > Kent Watsen > > Operations and Management Area Directors: > Benoit Claise > Joel Jaeggli > > Operations and Management Area Advisor: > Benoit Claise > > Secretary: > Zitao (Michael) Wang > > Mailing Lists: > General Discussion: netmod@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netmod > Archive: https://mailarchive.ietf.org/arch/browse/netmod/ > > Description of Working Group: > > The Network Modeling (NETMOD) working group is responsible for the > YANG > data modeling language, and guidelines for developing YANG models. The > NETMOD working group addresses general topics related to the use of the > YANG language and YANG models, for example, the mapping of YANG > modeled > data into various encodings. Finally, the NETMOD working group > also defines core YANG models used as basic YANG building blocks, and > YANG models that do not otherwise fall under the charter of any other > IETF working group. > > The NETMOD WG is responsible for: > > a) Maintaining the data modeling language YANG. This effort entails > periodically updating the specification to address new requirements > as they arise. > > b) Maintaining the guidelines for developing YANG models. This effort > is primarily driven by updates made to the YANG specification. > > c) Maintaining a conceptual framework in which YANG models are used. > This effort entails describing the generic context that in YANG > exists and how certain YANG statements interact in that context. > An example of this is YANG's relationship with datastores. > > d) Maintaining encodings for YANG modeled data. This effort entails > updating encodings already defined by the NETMOD working (XML and > JSON) to accommodate changes to the YANG specification, and defining > new encodings that are needed, and yet do not fall under the charter > of any other active IETF working group. > > e) Maintaining YANG models used as basic YANG building blocks. This > effort entails updating existing YANG models (ietf-yang-types and > ietf-inet-types) as needed, as well as defining additional core YANG > data models when necessary. > > f) Defining and maintaining YANG models that do not fall under the > charter of any other active IETF working group. > > The NETMOD working group consults with the NETCONF working group to > ensure that new requirements are understood and can be met by the > protocols (e.g., NETCONF and RESTCONF) developed within that working > group. The NETMOD working group coordinates with other working groups > (e.g., I2RS, RTGWG) on possible extensions to YANG to address new > modeling requirements and, when needed, which group will run the > process on a specific model. > > The NETMOD working group does not serve as a review team for YANG > modules developed by other working groups. Instead, the YANG doctors, > as organized by the OPS area director responsible for network > management, will act as advisors for other working groups and provide > YANG reviews for the OPS area directors. > > Milestones: > > Done - Submit draft-ietf-netmod-rfc6087bis to IESG for publication > Mar 2017 - Submit draft-ietf-netmod-yang-model-classification to IESG > for publication > Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for publication > Apr 2017 - Submit draft-ietf-netmod-entity to IESG for publication > Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG for publication > Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for publication > Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for > publication > Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > publication > Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for > publication > > > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 8 13:50:02 2017 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 C97401295D2 for ; Wed, 8 Mar 2017 13:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGz4GGLx30hw for ; Wed, 8 Mar 2017 13:49:59 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id A2D801296C1 for ; Wed, 8 Mar 2017 13:49:55 -0800 (PST) Received: (qmail 20059 invoked by uid 0); 8 Mar 2017 21:49:53 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 8 Mar 2017 21:49:53 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id tZpp1u00k2SSUrH01Zps08; Wed, 08 Mar 2017 14:49:53 -0700 X-Authority-Analysis: v=2.1 cv=Ath9goNP c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=wU2YTnxGAAAA:8 a=pGLkceISAAAA:8 a=OUXY8nFuAAAA:8 a=1sjgXBK7AAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=xcTfSnc4AAAA:8 a=i0EeH86SAAAA:8 a=Mid7uOFioIGf9qp2waYA:9 a=IIfK_ZjLVQAnQeC1:21 a=yaPVd5zGZaPh6TdA:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=cAcMbU7R10T-QSRYIcO_:22 a=qowbMnUzjQcM5iyYROrS:22 a=w1C3t2QeGrPiZgrLijVG:22 a=TSZmLRzkpGLBZRr3r8m8:22 a=AlSe2FwLBhvzWS46gZ1m:22 a=02toJ7V-nxh73JlV0Smw:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZFM2o7U5RwU0pmQRv/orXbWJ9RqcXxoNlmrsurs06ac=; b=URqPgg5ROQloDegzXi1tzdiz69 IcfFB6HXUa98veIyblkd6y3iWdW6M/ITekhpOKWyv4SAvBBGlATvWSLrreck2WHG0xqvNmwjoTk7I rHfYlOyuyV79HYbY4M/twv1wR; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:59568 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cljSv-0005HB-Js; Wed, 08 Mar 2017 14:49:49 -0700 To: Mehmet Ersue , 'Kent Watsen' , 'Susan Hares' , netmod@ietf.org References: <01a101d29757$b405beb0$1c113c10$@ndzh.com> <017401d29767$41970e50$c4c52af0$@gmail.com> <00f801d29770$7a42dfa0$6ec89ee0$@ndzh.com> <027a01d29781$24d32b40$6e7981c0$@gmail.com> <24CF7954-A7B3-4550-AFF7-9898EE175FA2@juniper.net> <013901d29825$264ae4a0$72e0ade0$@gmail.com> <4986ca5e-712a-291b-2fe0-3db4b820dda2@labn.net> <01c001d29852$722b5b70$56821250$@gmail.com> From: Lou Berger Message-ID: <47e9fcd0-f03d-ef2a-21e2-3903c193caed@labn.net> Date: Wed, 8 Mar 2017 16:49:47 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <01c001d29852$722b5b70$56821250$@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cljSv-0005HB-Js X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:59568 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 21:50:01 -0000 Mehmet, I'm sorry if we somehow got out of sync. I certainly agree that we've agreed to having the chairs only coordination meeting you suggested, but I (and I suspect Kent) never thought this gated work on the NetMod charter but was more to ensure smooth cooperation between the groups. I also thought we made it clear that we expected to have per-WG charter discussions in our respective session s on Tuesday rather than in a joint session. It was always our hope that the NetMod WG charter would be finalized before Chicago -- I'm sorry if we didn't state this explicitly. We expect to have a lot to discuss in the NetMod WG sessions and wanted to allocate time to focus on technical progress vs process, as well as ensure that all in the WG had equal opportunity to provide input via the list. Certainly Benoit and the IESG will need to approve both Charters, but the timing of this is up to them. I personally see that NetMod and NetConf efforts are largely deconflicted at this point so I don't have reservations with them progressing separately. Lou On 3/8/2017 4:25 PM, Mehmet Ersue wrote: > Lou, > > I don't understand the plan change. > We were discussing to have time for a joint charter discussion in Chicago. > > Any decision/agreement in a physical WG session will be verified on the maillist. > In any case once we are finished on the maillist, Benoit will review both together. > The two charters from NETCONF/NETMOD have to go hand in hand and one cannot be approved by IESG before the other. > > Mehmet > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, March 8, 2017 7:18 PM >> To: Mehmet Ersue ; 'Kent Watsen' >> ; 'Susan Hares' ; >> netmod@ietf.org >> Cc: netmod-chairs@ietf.org >> Subject: Re: [netmod] draft netmod charter update proposal >> >> Hi Mehmet/Sue, >> >> Our (NETMOD chair's) plan is to have had sufficient on-list discussion so that >> we can submit the updated charter to the IESG *before* the Chicago >> meeting, and then to review the changes in Chicago. We want to ensure that >> we have full participation and input on the list as this >> *is* official process and we want to be sensitive to those who may not be >> able to travel to this meeting. >> >> Lou >> >> >> On 3/8/2017 11:00 AM, Mehmet Ersue wrote: >>> What I meant with joint session can be achieved with a (e.g. 20-30min) >> time-slot in NETMOD or NETCONF session on Tuesday where we invite I2RS >> people to attend. We can discuss the charter details and agree "all together" >> on the plan and work split. >>> Does this make sense? >>> >>> Mehmet >>> >>>> -----Original Message----- >>>> From: Kent Watsen [mailto:kwatsen@juniper.net] >>>> Sent: Wednesday, March 8, 2017 1:51 AM >>>> To: Mehmet Ersue ; 'Susan Hares' >>>> ; netmod@ietf.org >>>> Cc: netmod-chairs@ietf.org >>>> Subject: Re: [netmod] draft netmod charter update proposal >>>> >>>> Hi Sue, >>>> >>>> First, please be aware that the next version of revised-datastores >>>> draft further defines the control-plane datastore concept. This >>>> includes providing guidelines that other WGs can follow to define >>>> their own control-plane datastores, and includes an Appendix section >>>> outlining the creation of an "ephemeral" datastore. The idea is to >>>> give the I2RS WG the ability to define >>>> datastore(s) as needed >>>> (read: future I2RS WG drafts). >>>> >>>> Regarding: >>>> >>>>> Does c) and d) include additions to include I2RS ephemeral state >>>>> as part of an I2RS control plane protocol? If not, which WG >>>>> works on the I2RS ephemeral additions to Yang for control plane data >>>>> stores? >>>> I don't fully understand the question, but believe that the NETMOD >>>> activities needed to support I2RS are all covered by a), b), and c). >>>> Things that belong to NETCONF WG will include any needed changes to >>>> protocol, YANG-Library, or any other draft maintained by that WG. >>>> Everything else goes to I2RS. >>>> >>>> I'm not sure what Mehmet means by a "joint session", but I think that >>>> it's too late to add such a session to the IETF Agenda at this point. >>>> That said, I plan a schedule another datastore breakout session >>>> (likely on Wed morning) that could be used to discuss I2RS some, and >>>> I also plan on attending the I2RS meeting Wed afternoon. >>>> >>>> Kent >>>> >>>> >>>> -----ORIGINAL MESSAGE----- >>>> >>>> Sounds good as a first approximation. Though we need to discuss the >>>> details and agree. >>>> It might be useful to plan a joint session on Tue or Wed in Chicago. >>>> >>>> Cheers, >>>> Mehmet >>>> >>>>> -----Original Message----- >>>>> From: Susan Hares [mailto:shares@ndzh.com] >>>>> Sent: Tuesday, March 7, 2017 7:27 PM >>>>> To: 'Mehmet Ersue' ; 'Kent Watsen' >>>>> ; netmod@ietf.org >>>>> Cc: netmod-chairs@ietf.org >>>>> Subject: RE: [netmod] draft netmod charter update proposal >>>>> >>>>> Mehmet: >>>>> >>>>> Thank you for the excellent question clarifying my questions. My >>>> questions >>>>> (b) - related to protocol extension for I2RS for RESTCONF, NETCONF >>>>> or >>>> CoAP. >>>>> I have removed that one. >>>>> >>>>> I restate my question below, and the [xx] indicates my understanding. >>>>> >>>>> Does c and d state the following are handled: >>>>> 1) informational concepts for the DS handling - [Netmod] >>>>> 2) generic extensions to Yang to describe control plane datastore >>>>> yang modules - [netmod] >>>>> 3) generic extensions to Yang to describe the ephemeral state in >>>>> control plane yang modules - [I2RS] >>>>> 4) I2RS specific extensions to support the I2RS control plane >>>>> datastore's validation - [I2RS] >>>>> 5) Any I2RS Yang modules- [I2RS] >>>>> >>>>> To provide precision on this point, I will give examples of work >>>>> related >>>> to >>>>> each question: >>>>> 1) draft-ietf-netmod-revised-datastores-00.txt [netmod] >>>>> 2) extensions to describe control plane data store yang modules: >>>>> a) control plane data store definitions added to >>>> draft-ietf-netmod-yang- >>>>> model-classification [netmod] >>>>> b) extensions to the Yang 1.1 - to provide a syntax to describe >>>> datastores in >>>>> which a module exists >>>>> datastore should include syntax to identify identity and >>>> prioritization >>>>> config data store. [netmod] >>>>> c) extension to describe the merged tree in applied datastore and >>>> opstate >>>>> datastore [netmod] >>>>> d) mount extensions that allow mounting modules in different >>>>> datastores >>>>> >>>>> 3) generic extensions to describe ephemeral state the I2RS control >>>>> plane datastore [I2RS] >>>>> a) extensions can define validation specific to I2RS control >>>>> plane datastore. >>>>> b) rpc can be used for validation of modules >>>>> that seek to mounted in either the I2RS control plane >>>>> datastore or >>>> the >>>>> configuration data store. >>>>> >>>>> 4) I2RS specific extensions to support I2RS features in the I2RS >>>>> control >>>> plane >>>>> data store. >>>>> >>>>> My earlier: - is a question for NETCONF/RESTCONF, or CoAP. >>>>> b) standard extensions to the protocol (e.g. I2RS or >> NETCONF/RESTCONF) >>>>> to enable the usage of DS - [protocol group or WG] >>>>> >>>>> >>>>> Sue >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Mehmet Ersue [mailto:mersue@gmail.com] >>>>> Sent: Tuesday, March 7, 2017 12:21 PM >>>>> To: 'Susan Hares'; 'Kent Watsen'; netmod@ietf.org >>>>> Cc: netmod-chairs@ietf.org >>>>> Subject: RE: [netmod] draft netmod charter update proposal >>>>> >>>>> Hi Sue, >>>>> >>>>> AFAICS your question kind of mixes between "I2RS control plane >> protocol" >>>>> and "ephemeral additions to Yang". >>>>> I believe different WGs are responsible for the part they own. >>>>> E.g. protocol-specific part should be done in the WG owning the >> protocol. >>>>> Can you please differentiate in your question between the aspects >>>>> below (my assumption in [ ]? >>>>> a) informational concept for the DS handling [netmod] >>>>> b) standard extensions to the protocol (e.g. I2RS or >>>>> NETCONF/RESTCONF) to enable the usage of DS [protocol WGs, e.g. >>>>> I2RS] >>>>> c) generic extensions to YANG language usable by many protocols >>>>> [netmod] >>>>> d) any specific YANG modules necessary for the use of DS [protocols >>>>> WGs] >>>>> >>>>> BR, >>>>> Mehmet >>>>> >>>>>> -----Original Message----- >>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan >>>>> Hares >>>>>> Sent: Tuesday, March 7, 2017 4:30 PM >>>>>> To: 'Kent Watsen' ; netmod@ietf.org >>>>>> Cc: netmod-chairs@ietf.org >>>>>> Subject: Re: [netmod] draft netmod charter update proposal >>>>>> >>>>>> Kent and Lou: >>>>>> >>>>>> Clarifying questions: >>>>>> >>>>>> Does c) and d) include additions to include I2RS ephemeral state as >>>>>> part >>>>> of >>>>>> an I2RS control plane protocol? If not, which WG works on the I2RS >>>>>> ephemeral additions to Yang for control plane data stores? >>>>>> >>>>>> Sue >>>>>> >>>>>> -----Original Message----- >>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent >>>>> Watsen >>>>>> Sent: Wednesday, February 22, 2017 7:25 PM >>>>>> To: netmod@ietf.org >>>>>> Cc: netmod-chairs@ietf.org >>>>>> Subject: [netmod] draft netmod charter update proposal >>>>>> >>>>>> >>>>>> Hi NETMOD WG, >>>>>> >>>>>> Please find below the draft charter update which we provided to our >>>>>> AD for review. Comments are welcomed. Authors, please note the >>>>>> milestone dates. >>>>>> >>>>>> Kent (and Lou) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Network Modeling (NETMOD) >>>>>> ------------------------- >>>>>> >>>>>> Charter >>>>>> >>>>>> Current Status: Active >>>>>> >>>>>> Chairs: >>>>>> Lou Berger >>>>>> Kent Watsen >>>>>> >>>>>> Operations and Management Area Directors: >>>>>> Benoit Claise >>>>>> Joel Jaeggli >>>>>> >>>>>> Operations and Management Area Advisor: >>>>>> Benoit Claise >>>>>> >>>>>> Secretary: >>>>>> Zitao (Michael) Wang >>>>>> >>>>>> Mailing Lists: >>>>>> General Discussion: netmod@ietf.org >>>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/netmod >>>>>> Archive: https://mailarchive.ietf.org/arch/browse/netmod/ >>>>>> >>>>>> Description of Working Group: >>>>>> >>>>>> The Network Modeling (NETMOD) working group is responsible for >>>>>> the YANG >>>>>> data modeling language, and guidelines for developing YANG models. >>>>> The >>>>>> NETMOD working group addresses general topics related to the use >>>>>> of >>>>> the >>>>>> YANG language and YANG models, for example, the mapping of >> YANG >>>>>> modeled >>>>>> data into various encodings. Finally, the NETMOD working group also >>>>>> defines core YANG models used as basic YANG building blocks, and >>>> YANG >>>>>> models that do not otherwise fall under the charter of any other IETF >>>>>> working group. >>>>>> >>>>>> The NETMOD WG is responsible for: >>>>>> >>>>>> a) Maintaining the data modeling language YANG. This effort entails >>>>>> periodically updating the specification to address new >>>> requirements >>>>>> as they arise. >>>>>> >>>>>> b) Maintaining the guidelines for developing YANG models. This >>>> effort >>>>>> is primarily driven by updates made to the YANG specification. >>>>>> >>>>>> c) Maintaining a conceptual framework in which YANG models are >> used. >>>>>> This effort entails describing the context that network management >>>>>> protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, and >>>>>> how certain YANG statements interact in that context. >>>>>> >>>>>> d) Maintaining encodings for YANG modeled data. This effort entails >>>>>> updating encodings already defined by the NETMOD working (XML >>>> and >>>>>> JSON) to accommodate changes to the YANG specification, and >>>> defining >>>>>> new encodings that are needed and yet do not fall under the >>>> charter >>>>>> of any other active IETF working group. >>>>>> >>>>>> e) Maintaining YANG models used as basic YANG building blocks. This >>>>>> effort entails updating existing YANG models (ietf-yang-types and >>>>>> ietf-inet-types) as needed, as well as defining additional >>>>>> core >>>> YANG >>>>>> data models when necessary. >>>>>> >>>>>> f) Defining and maintaining YANG models that do not fall under the >>>>>> charter of any other active IETF working group. >>>>>> >>>>>> The NETMOD working group consults with the NETCONF working >> group >>>> to >>>>>> ensure that new requirements are and understood and can be met >> by >>>>>> the protocols developed within that working group (e.g., NETCONF >>>>>> and RESTCONF). The NETMOD working group coordinates with other >>>>>> working groups on possible extensions to YANG to address new >>>> modeling >>>>>> requirements and, when needed, which group will run the process on >> a >>>>>> specific model. >>>>>> >>>>>> The NETMOD working group does not serve as a review team for >> YANG >>>>>> modules developed by other working groups. Instead, the YANG >>>> doctors, >>>>>> as organized by the OPS area director responsible for network >>>>>> management, will act as advisors for other working groups and >> provide >>>>>> YANG reviews for the OPS area directors. >>>>>> >>>>>> Milestones: >>>>>> >>>>>> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for >>>> publication >>>>>> Mar 2016 - Submit draft-ietf-netmod-yang-model-classification to >> IESG >>>>>> for publication >>>>>> Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for >>>>> publication >>>>>> Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for publication >>>>>> Mar 2017 - Submit draft-ietf-netmod-entity to IESG for publication >>>>>> Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for >>>>>> publication >>>>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for >>>>> publication >>>>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for >>>>>> publication >>>>>> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for >>>>>> publication >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>> > > From nobody Wed Mar 8 23:41:40 2017 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 DD8F9128E18 for ; Wed, 8 Mar 2017 23:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.02 X-Spam-Level: X-Spam-Status: No, score=-7.02 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 B2PnpGzVpQuA for ; Wed, 8 Mar 2017 23:41:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A0C1204D9 for ; Wed, 8 Mar 2017 23:41:36 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:b460:39eb:a41b:3316] (unknown [IPv6:2001:718:1a02:1:b460:39eb:a41b:3316]) by mail.nic.cz (Postfix) with ESMTPSA id 0E1D760950; Thu, 9 Mar 2017 08:41:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1489045295; bh=MSLmOLVhKVgke/CSxuHQjfHRPgUg5o/QxJjNXax8n3Y=; h=From:Date:To; b=nHNfvu9XuiUMx/RGuxFt5gP8niAxooz3RSBHt7NJhWrW0Ez8sqNDPwJCwpXk81bUR xTRKL5AvYb/7X0TMQ7J0lZ0Q/fT65AL0WGXGSQ4eCsT2+W5dxpU/ZGAA9RCISDAAGb +EtSuzLWEGnSCcvZycXBxvo0LQgzZ3IKky+Scxj0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 9 Mar 2017 08:41:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <25DABE48-94C2-46B5-9DCB-B6F01E8C3BAB@nic.cz> References: <20170303191348.GA3570@elstar.local> <20170307.185911.779366639761395028.mbj@tail-f.com> To: Kent Watsen X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] rfc 6087bis - stress importance of instance examples X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 07:41:39 -0000 > On 8 Mar 2017, at 18:40, Kent Watsen wrote: >=20 >=20 >=20 >>> I think we should encourage authors to write examples. >>=20 >> +1 And also encourage authors to validate the examples=20 >> using their favorite YANG instance validation tool. >=20 >=20 > Please note this from the latest 6087bis update: >=20 > 4.12. Module Usage Examples >=20 > Each specification that defines one or more modules SHOULD contain > usage examples, either throughout the document or in an appendix. > This includes example XML instance document snippets to demonstrate > the intended usage of the YANG module(s). >=20 > and I already wrote this: >=20 > Nice addition, but should it say something about JSON, in addition to = XML? I'd suggest: "This includes example instance documents or snippets in an appropriate = encoding to demonstrate the intended usage of the YANG module(s)." Lada > Perhaps that, unless there is a reason to only pick one encoding, = examples > should be split between the two? - just throwing it out there to see = if this is > something we might want to recommend...thoughts? >=20 > = https://mailarchive.ietf.org/arch/msg/netmod/dOpSYzM_J05Sdmgt-MyYmqJIUz0 >=20 >=20 > K. >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Mar 9 03:07:30 2017 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 DDDAD12950B for ; Thu, 9 Mar 2017 03:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 IpmXP4gtUgBv for ; Thu, 9 Mar 2017 03:07:27 -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 28D17129521 for ; Thu, 9 Mar 2017 03:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1522; q=dns/txt; s=iport; t=1489057644; x=1490267244; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=r333lA3312ChGvrlmhu1ETSEQ1RiiEtpm2+5r30F+3U=; b=EA1BQFP+RsNLhpgzXDK+TRHiPNxU+TzuFOJ9ge2q+tSe3F0MNyGJiEE6 UiuTG3bAWfevkf6mQuQZbEYsU1qDsScnbEa5Iaif7zeITR767hlvrxlVG p/97fyMcSeYQb9W2EWDvdXP8lUVG0Pms8qUACkUcdUQ1GZbhVs2KbB4SC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AAD9NcFY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDKBCo1sc5BblTiCDh8LhS5KAoMLGAECAQEBAQEBAWsohRUBAQE?= =?us-ascii?q?BAgEBATY2EAsLDgouJzAGAQwGAgEBiXQIDrJXim8BAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGgWGToIFgmqKOQEEnDmSOIF7iFSGUYhEgm+IDB84gQMiFQgXFT+EVB2BY0A?= =?us-ascii?q?1iisBAQE?= X-IronPort-AV: E=Sophos;i="5.36,268,1486425600"; d="scan'208";a="653136195" 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; 09 Mar 2017 11:07:22 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v29B7Maw027862; Thu, 9 Mar 2017 11:07:22 GMT To: Kent Watsen , Juergen Schoenwaelder , "netmod@ietf.org" References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> <82703e36-26f9-d459-c36a-c274861c5386@labn.net> <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> <20170308180211.GA9937@elstar.local> <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> <20170308193434.GA10080@elstar.local> From: Robert Wilton Message-ID: Date: Thu, 9 Mar 2017 11:07:22 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:07:29 -0000 On 08/03/2017 20:57, Kent Watsen wrote: > > >>> This way, reader can focus more quickly on the diffs, but also this >>> likely mimics what happened in reality (start with `pyang -f tree` >>> and then manually edit from there). What do you think? >>> >> Manually edited tree diagrams? I hope not. Perhaps we should have text >> saying that tree diagrams are expected to be generated by tools and >> that they are expected to be consistent with the model (and hence they >> need to be updated with every change, hence usage of tools is a damn >> good idea). >> >> [I thought this is obvious but perhaps this is not.] > > Right, but what happens when the draft precedes the tool being > updated (e.g., schema-mount)? Or the output has been generated by someone without the latest revision of the tool installed (which has happened to me previously). > It's a rare case and you already > said authors can address it on a case-by-case basis, so I think > we're covered either way. Having the key inline in the documents is generally slightly more convenient for readers, but not at the expense of it being a hassle during review, or having people define custom formats. So, I support the idea of putting the table key into its own draft. Not 6087bis because we need it to be quick/easy to update when required. Rob > > K. > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Thu Mar 9 03:42:08 2017 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 977C5129547 for ; Thu, 9 Mar 2017 03:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.02 X-Spam-Level: X-Spam-Status: No, score=-7.02 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 3rTKB-9GygmM for ; Thu, 9 Mar 2017 03:42:04 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD55129437 for ; Thu, 9 Mar 2017 03:42:04 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:b460:39eb:a41b:3316] (unknown [IPv6:2001:718:1a02:1:b460:39eb:a41b:3316]) by mail.nic.cz (Postfix) with ESMTPSA id 3E4C360190; Thu, 9 Mar 2017 12:42:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1489059722; bh=IRq5f8E4GUNogkgByi7vC0uZcOGZTA/OopwVnemnrnw=; h=From:Date:To; b=gxmexjE8SJ2G6/ZCuYEOxvSqMvMCrdjcIx9TmxQxj1iC8lrzuP3EGL2r2NangckaT 7UxwXcvd4QWrsSaHnLRVC2GSrDyGFbgh+bXOXE6b0kSfi3R3QvEpYZ1aVX67isEmvT BUDioNq2nwEOwgnBOSxJ6GWeIdZ7J4pB3uHI+elI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170308193434.GA10080@elstar.local> Date: Thu, 9 Mar 2017 12:42:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D5AAE1E-AC3B-4A6D-B33D-356052B08C64@nic.cz> References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> <82703e36-26f9-d459-c36a-c274861c5386@labn.net> <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> <20170308180211.GA9937@elstar.local> <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> <20170308193434.GA10080@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:42:06 -0000 > On 8 Mar 2017, at 20:34, Juergen Schoenwaelder = wrote: >=20 > On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrote: >>=20 >> This way, reader can focus more quickly on the diffs, but also this >> likely mimics what happened in reality (start with `pyang -f tree` >> and then manually edit from there). What do you think? >>=20 >=20 > Manually edited tree diagrams? I hope not. Perhaps we should have text > saying that tree diagrams are expected to be generated by tools and > that they are expected to be consistent with the model (and hence they > need to be updated with every change, hence usage of tools is a damn > good idea). Tools typically have options so even with their use the output needn't = always be the same (for example, types and leafref pointers may be = present or not). Lada >=20 > [I thought this is obvious but perhaps this is not.] >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Mar 9 03:46:46 2017 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 599B0129562 for ; Thu, 9 Mar 2017 03:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 KZdaEyjXUfsA for ; Thu, 9 Mar 2017 03:46:43 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0124.outbound.protection.outlook.com [104.47.0.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60FF12954C for ; Thu, 9 Mar 2017 03:46:42 -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; bh=yxcAtYFr5P2Iu1zAUTtxLOyrOFl1F+pJe3lNtGhO0nc=; b=k8+giSx5EL0UA7pI9mgN2Toi30ZoA+o/GoIf9nanUCoqjCEBt1HJiKkoHlxwX713vSXgqhyJ7Q3SsNRHaoHM5f06FQEgwJdcfYjUZc/dgcwA44l0luzolF0AD6wY/tprKOK+PlNpD9H1EBajrZqU3zysdwLz/9egY+80JJSlZDI= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Thu, 9 Mar 2017 11:46:40 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) with mapi id 15.01.0947.022; Thu, 9 Mar 2017 11:46:40 +0000 From: "Bogaert, Bart (Nokia - BE)" To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt Thread-Index: AQHSl6caLbof61hN1kCkZer1IzW2RaGKudKAgAAwwgCAAAUDYIAAIaRggAFUqMA= Date: Thu, 9 Mar 2017 11:46:40 +0000 Message-ID: References: <20170308.140730.165843214949076575.mbj@tail-f.com> <20170308145133.GC9814@elstar.local> <20170308.162542.2034349701486649544.mbj@tail-f.com> In-Reply-To: <20170308.162542.2034349701486649544.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: tail-f.com; dkim=none (message not signed) header.d=none;tail-f.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.240.248] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0627; 7:rupj9JsSwQsGUdgJaC77+ubRRvBfrlUqDu5hjW9C3povhR3qM1u8VKbkA2BoJKTW8acQ/c4an7bIuux39/1MClpBgSAi82ikfVZc1RSSO3r1W+keNcUhaBEzj8JCM81dUDMZ0YhVB5xZxHhHfM7AIRePewLVMMGNqaAnZpiBOkzDpXZmYgUdAdio94BsNQlRkiwqGpzWaB7o8LeQ3fadrSXrLiGaGtab29T5ksg+U53EqLEvKGyLK7zk0IqgrkBwWt84ODygDNMtL5Ev+JaRDYdp+J4nYHGwepRFmQgyV5j8huHuleCNG8fO4mW4A1pfKA7hLVunZK9wG664CuRzWA== x-ms-office365-filtering-correlation-id: 8c228c1a-97c9-41d6-1fe3-08d466e1f354 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM2PR07MB0627; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:AM2PR07MB0627; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0627; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39410400002)(39850400002)(39840400002)(39450400003)(24454002)(5660300001)(7696004)(2950100002)(77096006)(2900100001)(106116001)(229853002)(189998001)(6246003)(102836003)(3846002)(3280700002)(6116002)(53936002)(2906002)(3660700001)(305945005)(7736002)(38730400002)(74316002)(4326008)(93886004)(230783001)(8676002)(9686003)(6506006)(25786008)(50986999)(76176999)(54356999)(55016002)(81166006)(99936001)(99286003)(8936002)(6436002)(122556002)(2501003)(33656002)(66066001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0627; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04F7_01D298D3.315A0430" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 11:46:40.1040 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0627 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:46:45 -0000 ------=_NextPart_000_04F7_01D298D3.315A0430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So; to make this work the YANG property of the parent leaf in the config data tree should be set to false to allow a reference to hardware-state, correct? Regards, Bart Juergen Schoenwaelder wrote: > On Wed, Mar 08, 2017 at 02:48:15PM +0000, Bogaert, Bart (Nokia - BE) wrote: > > Hi, > > > > > If we pick the former, it will not be possible to configure a > > > component with a system controlled parent (unless you also add the > > > system controlled parent to the configuration). > > > [Bart Bogaert] Is there a reason to only have this parent in the > > > state tree and not in the config tree? > > > > I am not sure I understand the question. Suppose the config tree is > > empty, and the system boots and populates the state tree with all > > detected harwdare. Next, a client would like to pre-provision a > > module in a chassis that exists in state. If the leafref is to the > > config tree, the client would have to create both the chassis and > > the module in the config tree, since the leafef would otherwise fail to validate. > > > > [Bart Bogaert] Ok, so you are looking for a solution that refers to > > an entry in the state tree. I always thought that one could not > > refer from config to state but it seems I misunderstood this since > > this is exactly what you are proposing. > > > > > If we pick the latter you will not get any validation (since it > > > has to be require-instance false). > > > > > > It is fine w/ me to change the type string to a leafref of the > > > former > > type. > > > > Correction: I am fine with changing the string to a leafref to state. > > > > > [Bart Bogaert] If we leave it as a string it would mean that an > > > external application would have to check whether the value of the > > > string actually corresponds to a component that should exist (in > > > the case of a non-system-controlled parent)? > > > > So are you ok with a leafref to state? > > > > [Bart Bogaert] Since that seems possible this would solve the > > problem. I'm checking this with our people. > > Are you discussing leafref to a config false node with require > instance false? Yes. > I am not sure this is valid YANG. It is valid, section 9.9 on leafref says: If the referring node represents configuration data and the "require-instance" property (Section 9.9.3) is "true", the referred node MUST also represent configuration. /martin ------=_NextPart_000_04F7_01D298D3.315A0430 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMDkxMTQ2MzhaMCMGCSqGSIb3DQEJBDEWBBSpHxsz w4iWt5Rt9dvkMe9PHRzsVjCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBACtfq/iQBDYeKIszX7ei7uiLgeEakYd60rdPzk4b7dvTI9AFGot8FGRTRZml lWr8n+vjOazbQLAFvLaSsf2PoURiKUo+eobgXjFlhTQa0atLXDx8Qbhpt+8Q/iH93hwpSb5pMiuf 0Bc5ECh9GL74YZUk/cFTBQMOvD+XEXGyxb3Ji2dujwHN5ZKExvBvfkR0K7HO4UeNUaBxDgOZOJPZ qjnNgaYyRhcaIgjysN4jk8Yogu2hhrm59BmNB7djiGbI22O1MB36fIa6VX3Y7uA818jMcnEYhScP achrgdSdNOzC5LbDP9gttJfyrZDb9NjSe+8ywCs6+mUUST4ckoyVrF4AAAAAAAA= ------=_NextPart_000_04F7_01D298D3.315A0430-- From nobody Thu Mar 9 04:21:21 2017 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 696691295AA for ; Thu, 9 Mar 2017 04:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 H9ZZU9pcCDPV for ; Thu, 9 Mar 2017 04:21:18 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0119.outbound.protection.outlook.com [104.47.1.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8110B129458 for ; Thu, 9 Mar 2017 04:21:18 -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; bh=k8kO5Vs+xYvurl2xUQeWHyeMbtl/JLcI5ngfpkznlcU=; b=Bto5DusC1oS1HtdJyoS/fOvHKdvw88SItcKO1x3NNd+/QAJSZ3chASqE5NKUSR7kQSRmz/EGDulpuj53Fqm44AAEuSbogSvMDNQwsemkYqapuod94baeVfN+xyhT5LYlSiEsHCTsoenMLT/NXQH4OTYWBpiV6p+YzKV0QM2ZU5U= Authentication-Results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.203.75) by HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Thu, 9 Mar 2017 12:21:15 +0000 Message-ID: <09a301d298cf$781d3d00$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , Kent Watsen References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> <82703e36-26f9-d459-c36a-c274861c5386@labn.net> <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> <20170308180211.GA9937@elstar.local> <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> Date: Thu, 9 Mar 2017 12:19:07 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.203.75] X-ClientProxiedBy: DB6PR0202CA0042.eurprd02.prod.outlook.com (10.171.70.28) To HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) X-MS-Office365-Filtering-Correlation-Id: b21cba49-e513-47c9-c092-08d466e6c886 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:bKxMOtuIvGtBzqDlCmyNoKlFZCBKStuGd6fg8ld4cCl5jZgt40RXNlgFmPXZSCaapcl/2agPwxIEye6/2de/iWAhOPdXIy6SpjmiOLCY+o+7BSTHe1xBvA7vV0Ni2hWwA2EvDwOs0wFmbEtMieaBRciytorG9Xoas/k6ORX0EHw4by4oGlWgwWI1Kw38q+VuAYyC+QCBXvrNm2YoT9yP04PKPl+vTGDF2/+QQvM/7ZnTb55HnKNl9Gtf8BggBt1ujF6DxXhiPIYqe7Um9hY4Tg==; 25:qpKBbGe4DbcoVeSk+jXGLoCdl+oSP/szeosssIU/Wp68dC2wctoE4ZXwY9mIVMc/Un39sKQsJ/OgjuSDgSRWawZ4mZegsvKVqf1M1dpp9StjKxYLYRQdhKS4qjQYhw76grAlm7HzHH02u50+zR2JUW75ylZtAHcYCfDlL4eHm5qh5roOG4tDIHcwmnrYo2Ugcrs4ptS7OwrU1ipoW4JYdFtohSb+eGTvqha5b8+p3Xd/zPzNjX6kxRP76aORxLN4RZAwe3btAOnPtS1pvixxHgSQibm4aSTnZ3ZNwM1CFQkZPO7tKBgF7Sp10gqflSGYYxNfdnj6b43qpXQDGczVlJWGPyy7ou4CTr2zPs8YTlOrczlaacYGexCDry+QPUpTcyhSC/1MC2ihj3p2xHuoquU37VJQA6RySEpTD2EDW4xM4PBt2kHklzweVewJPAzsOVTw+m1O886P5oEM5akxSw== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 31:uQjq9UJv6Ruy6GMahteXa+u7mmoejpkE2xPHBWVDM2FPJBglwDDjCw1E345VY+XX9XwlLXCgtJsZmHL/gFp2c54l2sZZ3wznROnU6O6hsJOHiC09uLkH4lgllRpqGFuO9DnML1KmRjzS6cTxj+r83Mh9jvKCfaVnwng26eE6wSZp4QYACRIaJ9gJF1lEti4GNhEnruZ9cHZIu8tgcqUJj3R/v9kuL1hy5cKnJQmIeF4tOUdKQvNSjuCay1puyU83FmFpXUtqocMEahRfiZhmow== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123558025)(20161123555025)(6072148); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 4:6NEYtWj/p7Zpqu3M3NCPIy4DDGRI/8jUeWN2yEXeHUfvYsWp2wICqKl2Exfb+kCvX3ORvsavcs4lnDpGrmCzL6fJGvN3QDcNxtaADQD4PUhKZ6xzLt2twnkPvTbHwDCa+H1fZgjMitRxLc010s3j8F0rf6ELbs97KFjF1r/7adbhHprXq8bF9Bag9Q9dhuWLnwRcahwJr8k25hyeiNq7Lpp1BuxVOOTIyzXq/ePpnEn/HgifDphtCKWvjLHpUG9chHl08YtPfWbU2YiX/6BxAeYesritQEfm+PHEnZ9bBShtM9fsIaOnTPIy2Cwo6BHJL1PXLRPz/PngBQ+v+JntwJsPiOg/15fhPtYJ70RQl6CLBPntEu4aFRQSwvILExEjf52b0buO9ok/7l6qbTgcLad4ghE+yWkaUGyDe0gpdBKdKVWriaIjlDFFpxa13qsyRxpXGPX0ECwqwf8H09NkRX1DdXVAa+5mb+Do/47esv7Gg8KlT3LyXGgNrzc7bI/k3OCtve3NmcYqJYWoGAUIRuT5nI9r9R55OMxItyKkUAx4jjzeq4j6GopRzZohl3oIy1vrAwU5o5zFP7tz0tALNoSxCeej+0b7xfJZtW7o6T9kIC8dQXWjJCikI0tzTLVvptH8eVXthGd0NNwWLfHnqQ== X-Forefront-PRVS: 0241D5F98C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39450400003)(13464003)(76104003)(377454003)(24454002)(66066001)(33646002)(44716002)(189998001)(8676002)(1941001)(230700001)(6666003)(305945005)(61296003)(81816999)(9686003)(50466002)(76176999)(47776003)(7736002)(3846002)(62236002)(81686999)(42186005)(6116002)(5820100001)(81166006)(1456003)(4720700003)(44736005)(23676002)(5660300001)(14496001)(38730400002)(50986999)(2906002)(6246003)(50226002)(93886004)(4326008)(25786008)(86362001)(6496005)(53546006)(1556002)(53936002)(6486002)(229853002)(8666007)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDI7MjM6d3hGRm16M0tMRkRhaldFU1VQSGRueTNh?= =?utf-8?B?aDNWR3FmeW1pSTRuVUR0K1kzOWxGQ0ViQXljSlA0Z0FQVmJtbnY5WERqWTVZ?= =?utf-8?B?K1NLN2ZZejFnR3NnQ1k5M3FuS0ZudWNTVVFRanVVaVNVQS9xVGJTeUZhM3Fm?= =?utf-8?B?VzhIaE40ZXRNY3dicWUvUjFsVkFSNjAvYnNZRk5zSjMwZVovUFg1VHdCMjNU?= =?utf-8?B?d1hBZzA5Szl3MGRON2JvUERsK0EwN2o5cGg2T0xuZG8vbmliUldQcmVUMUR6?= =?utf-8?B?L2hyTW1GRHh6LzZGcVBuTmtmWVlWdjlFWkorcHRZY1lOQlF3elZNSTdXSmVr?= =?utf-8?B?MGNTa2tCUUlFSXI3MS9pMDB2ek1Ba1J0OHFxaTI1M2pTWE8vVzNsMVRxY3V0?= =?utf-8?B?Sm1zK3NNdVpsLzBZMlJ3Rlo1R25wYm5NdGxsUGdQbVFyWFh3MGFOUVlJZE5U?= =?utf-8?B?NW9HSWVJZkJmYWhaSEszdjJBb2J6UkZpcmQ2Z1JIQjZndkV6dTBveFNGZ25F?= =?utf-8?B?SzIvbWlpWTJIMXVyUEtMcFUxdmMrNnJwMHg0ZjlTVU52aGs1QWxtRkhaMmxt?= =?utf-8?B?MU1VOXNMWDhMbE5OajY3bkcvb2dIMUxOcmdaa3NaTVBqNkkzRldpNjF6bk1G?= =?utf-8?B?Ui9ON3MwZ1JNZDZWdnJSZjBWejBwbDFXL0pmRFBCb3d6aVYzMDZ3dmJwR0Iw?= =?utf-8?B?NGY3M3BPb1JJaVJDSWwvTWR1ekFpOFVpMmFFZHlxZDVGV3k3cWpOeHB3TkJT?= =?utf-8?B?N0hjSmMyeUFneTNiK3hBZkJ0SDZscFcrWkJTVERkaGVhS3lLQzRFZ2lidTc2?= =?utf-8?B?MGtNYVlHMU5qaGtENEE0ZFUyczQ2dzBRRXZ5U08yQ1BjZE5rTHlMRE5udk9h?= =?utf-8?B?Qmlwd0N0aUNnSUwyZ3FyVmlWSUgweG16VTdFK2pwNThhTzZHbWU0ajJrOTc5?= =?utf-8?B?dzdnNDBHUG00dm8vS2toVXM0bDR1TGFBRW5qQThSbTNYQ1lBK05JYzFXRisr?= =?utf-8?B?U2V0NVczYlZUcll5R2hGeFBRMjZMbGV0dEhEUXZiNWExRkQyS0VNK0dHeGlu?= =?utf-8?B?aWdSMFcwbjZySGhnK0ZMZWQzSTFnWU4yTFhVR2x6bm9mUE5OTk01Qi9aNk5w?= =?utf-8?B?V0daY3RuNEhITnpvZVlVUUFFYXBOWVprMjBwblVjZEREcXlrbUFvbklEVWty?= =?utf-8?B?bzY0Q3VsbWFXMFdzd1g0Wms3QlFnTzhkRjdUaEMxM1YrdFNvRSs1MVJZRnRr?= =?utf-8?B?ZUpicWVSNU1ZVFJCWDFwcDZJUFhRSWpUV0hrSFIrME9xaUZRYXRVZnZQYllG?= =?utf-8?B?dzhXQjk3Wm5VM0l3eXUxWkg3a3lPWWVPRVZWZXhwaVBFUGhUcHludTdCQlZt?= =?utf-8?B?Qy93ZEZyY201SithOUcvQWYzTm9LZk1PbVloN3Q3azZMSTBsVDhZUyt4QUxS?= =?utf-8?B?cGZhWjNFNFZzdk1LTzV6VkpZNUJYdDRqVTgzMjRGaVJIS0hGWENRTWNzYWVO?= =?utf-8?B?aGgrbGQwVnNyVElnNjVjdVcxcjQwS3lPSXUxUHVrSXJySm5aL3p4SC96cGhn?= =?utf-8?B?RzJTMmlhUXhQTUhZWitic1pFS04rVVROU0J2TmpUVFhSeHJsMnBVRjRyaEdh?= =?utf-8?B?UGpmK0N2WVZkY0F3c1NydDJLeWhLckJXVUNFV3RLTWZRcnJLQVNidUhETENT?= =?utf-8?B?OGN4WnBHTkN5dHJTSDZZQU1iYkx6NVAxZlRmSE5GNHhFbTM0K3h6OG1yTXpu?= =?utf-8?B?UUZXTFVSaGhWejVObk1mOWdBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:defRC/pJj3sN0oosAMUDDfrWUGHQji72ozB143xcdCmvbb1ttBDJqVAdYb8O0bCeDQYvyimhLiHNlbS67qQG9HUL3xioaOv4dzjkdTsAJZkhHymcAUw/NGBIvpr0P8rOhDBZU53/S3U8PF06Q9uVr/e5ysR/YIqp3jXnbpu3TsgkjZ3lw2UFDpaBYMMBvihfp+5q1IsNwmOyqcBUeBkUACx5X/ycICYGaTBVmuYG6KPRn/XOEqtj3YCN/f8z87Ea21bDUCzz2U6CjyznMmTP+Y6ly6XL7JvP8+zOgbOLShqsHNnQXVmzYiY6Ojk+EB5ri8LMrV6TlO/s2U1sy1WkifPhcMk6SITzL398+10r0gEmxMnhR02tJ+lzHKKfk0ywTU3btKK5+B/7tk+aMV3dmw==; 5:BIcFtoZjuaUsPYgLuJKMdya3jPM1/+uheporYZuKJZ/2bsTeyfYwyYP4Wg4NISHYIvuYY3C8q4QP6NcocqxNzxbTlzEGYAqsNIhqGXOwiqNAxA47C/jzZBcLqKT71PNTBL3i6RNuqVpg1K/ADFXcEi6XRKf6ZiZB/HCDjkWfZ7M=; 24:xD6n2SiypOxLZhSm8q/PvEV8CbwHS8E0O5Zme0OfPci6UmHSDG/k7Nd8FLjhdMy6oQl+CciWV2TDsjEXXmrl8TTrjy724zrj0q/J9eXW8Qk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 7:RI9DLWkW7vHRbI0TSPZhB4mCqR8RdBW/lC7WfOeKy5X0Zf7uSYxcY9Xmrik/LlBhTsxVpfv8LhhG40FBgj0J4+wM/qqCxW07kKC9Yp7OFOhlkRz25AU5ECKTxXRezRC/1GJtevg2MMl68M/LoST3fIUpvz9XD/im+Rp0LNBewIkGWxt3vwNPXvCGmZfAdMXcE8L+LEORlTa1KZJxfT0IaqYMK0wkYFx7HT6bii4P9173FANElIk65XjC4AaOs9BJ1Ba38on8700kKwn0wOJvPKxkPaOiUvGswe5wL9u9Q+byw6nO51tPBTEQFyB0fp7rPxgqjFaD8aKTI47tuMVWVA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2017 12:21:15.3763 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 12:21:20 -0000 ---- Original Message ----- From: "Andy Bierman" To: "Kent Watsen" Cc: Sent: Wednesday, March 08, 2017 7:14 PM > On Wed, Mar 8, 2017 at 10:56 AM, Kent Watsen wrote: > > > > I think we can allow both and leave it to the document author. Either > > > the author uses a well known tree format and refers to its definition > > > or the author uses a not yet well known tree format and then it has > > > to be defined inline: > > > > Nice compromise, but even then it would be helpful if a draft that wants > > to use some custom-annotations do so on top of a standard tree-diagram. > > So, for instance, the draft might say something like: > > > > Tree diagrams used in this draft use notation described in > > [RFCXXXX] with the following additional annotations: > > > > @ - means ... > > # - means ... > > etc. > > > > This way, reader can focus more quickly on the diffs, but also this > > likely mimics what happened in reality (start with `pyang -f tree` > > and then manually edit from there). What do you think? > > > YANG is supposed to be prioritized for readers, writers, and then > tool-makers. > As a reader of YANG modules, I do not want people creating their own > tree diagram syntax. I prefer all tree diagrams use the same syntax. Spot on. I was about to say that this thread is YANG experts discussing what is best for YANG experts and ignoring the needs of the other 90-something percent of those involved with YANG but Andy expressed it much better than I I want not just the tree diagram to be unchanging (except when something big like schema mount comes along) but I struggle when the explanation of the diagram changes. Why does netmod-syslog-model have a completely different explanation to most other models? Is there a functional difference I need to know? I cannot look at netmod-syslog-model and recognise whether there is or not without doing a compare and contrast with a 'proper' explanation, such as netmod-entity or 6087bis-09; and I don't want to spend time on that. Tom Petch > > K. > > > > > > > > Andy > From nobody Thu Mar 9 05:31:43 2017 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 62A2A129591 for ; Thu, 9 Mar 2017 05:31:41 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObA-9l7xYd8h for ; Thu, 9 Mar 2017 05:31:40 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F0C5412945F for ; Thu, 9 Mar 2017 05:31:39 -0800 (PST) Received: from localhost (unknown [50.225.114.198]) by mail.tail-f.com (Postfix) with ESMTPSA id 841071AE02A7; Thu, 9 Mar 2017 14:31:36 +0100 (CET) Date: Thu, 09 Mar 2017 14:31:35 +0100 (CET) Message-Id: <20170309.143135.262966763364971166.mbj@tail-f.com> To: bart.bogaert@nokia.com From: Martin Bjorklund In-Reply-To: References: <20170308145133.GC9814@elstar.local> <20170308.162542.2034349701486649544.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 13:31:41 -0000 "Bogaert, Bart (Nokia - BE)" wrote: > So; to make this work the YANG property of the parent leaf in the config > data tree should be set to false to allow a reference to hardware-state, > correct? It would be: leaf parent { type leafref { path "/hardware-state/component/name"; require-instance false; } /martin > > Regards, Bart > > Juergen Schoenwaelder wrote: > > On Wed, Mar 08, 2017 at 02:48:15PM +0000, Bogaert, Bart (Nokia - BE) > wrote: > > > Hi, > > > > > > > If we pick the former, it will not be possible to configure a > > > > component with a system controlled parent (unless you also add the > > > > system controlled parent to the configuration). > > > > [Bart Bogaert] Is there a reason to only have this parent in the > > > > state tree and not in the config tree? > > > > > > I am not sure I understand the question. Suppose the config tree is > > > empty, and the system boots and populates the state tree with all > > > detected harwdare. Next, a client would like to pre-provision a > > > module in a chassis that exists in state. If the leafref is to the > > > config tree, the client would have to create both the chassis and > > > the module in the config tree, since the leafef would otherwise fail to > validate. > > > > > > [Bart Bogaert] Ok, so you are looking for a solution that refers to > > > an entry in the state tree. I always thought that one could not > > > refer from config to state but it seems I misunderstood this since > > > this is exactly what you are proposing. > > > > > > > If we pick the latter you will not get any validation (since it > > > > has to be require-instance false). > > > > > > > > It is fine w/ me to change the type string to a leafref of the > > > > former > > > type. > > > > > > Correction: I am fine with changing the string to a leafref to state. > > > > > > > [Bart Bogaert] If we leave it as a string it would mean that an > > > > external application would have to check whether the value of the > > > > string actually corresponds to a component that should exist (in > > > > the case of a non-system-controlled parent)? > > > > > > So are you ok with a leafref to state? > > > > > > [Bart Bogaert] Since that seems possible this would solve the > > > problem. I'm checking this with our people. > > > > Are you discussing leafref to a config false node with require > > instance false? > > Yes. > > > I am not sure this is valid YANG. > > It is valid, section 9.9 on leafref says: > > If the referring node represents configuration data and the > "require-instance" property (Section 9.9.3) is "true", the referred > node MUST also represent configuration. > > > > /martin From nobody Thu Mar 9 08:34:02 2017 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 345D41296B1 for ; Thu, 9 Mar 2017 08:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16juPbteCIaf for ; Thu, 9 Mar 2017 08:33:52 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 77BB21296B0 for ; Thu, 9 Mar 2017 08:33:52 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id u108so48625525wrb.3 for ; Thu, 09 Mar 2017 08:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WBYo8xdbhisEo27EyQL3ZVvz9a98cv2E4piyy77/KW8=; b=brJla3K5nGDra9OfJD4GmxceTorTlwzbOGihE1z8TtC0Psx/RaDTSATa1mgzu3FmHQ EpePJWjz4OvabeoanV2kjdwZKazTQyXMEitrL8GZjOa9cIrFqEfqjs3w8XuvISEcs8Iv SlkHISYELPAxS0laL+TnNG2OkHNctwwkXbQkh6HTktETzyyJCzkitgC/53F85AHz5h2s GHq+GhuAkmUFaks7SrOGRUumgZjJWnReuao03fjxKXKXCdBK+vkJ2YzptSwLdUfC0bdx 34lHhh5/9ckL89a/2tqXVCTQMI9BL7Pu6wj0dmzIuUA2lL/0Wp+PYCYfX0K8L7jYDa5M sJmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WBYo8xdbhisEo27EyQL3ZVvz9a98cv2E4piyy77/KW8=; b=fzKfY0bHQXp+v1f3tv7JyUYkHHGDYx0107IP4rH3Wx0kWSaTU+hSQb0c3qYGKlgOkr lYJTqXvENdXe/6MuJ3mfZlMuB3wKQuR7iKyc5vbLucFgrKXeEWREr0NvaGjqLY107cXe 3T4I85Nh/duuaRvy/M+9PUGW2eKPeTNni7Gc81U3aUyCIffN+5UK/OC1yeF0lV4rPb/x 5q4j/JiJSyEfz5UOn13uyWf/b3Plb+Q1LwHL+Ns18lBTDBlVck/a3sicQPXiXS8jwhf2 uumX+0hy/k1BcZ8eaSowKrK3HzLuMlEvflZ389IprXCte7FOEWLlwMOy482Nx9gL3S6H eC+Q== X-Gm-Message-State: AMke39ltEFumVno6DZbQB5UF3eD6kZj3omRUo6pdibcSVR8kw8z9To6ZtgcPBDS5UeafdNQaMrOfMqbba+q64Q== X-Received: by 10.223.138.252 with SMTP id z57mr11265665wrz.110.1489077231000; Thu, 09 Mar 2017 08:33:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.86 with HTTP; Thu, 9 Mar 2017 08:33:50 -0800 (PST) In-Reply-To: References: From: Lyle Bertz Date: Thu, 9 Mar 2017 10:33:50 -0600 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113c523865a4a1054a4ecff6 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] New I-D Submission: draft-bertz-netmod-commonaugment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:33:54 -0000 --001a113c523865a4a1054a4ecff6 Content-Type: text/plain; charset=UTF-8 Understood. Let's discuss at the meeting though. This was a significant issue in the development of the IETF DMM FPC yang files and our open source project. I am open to this going in the proper direction wherever that is but wanted to bring the issue and a possible solution to the table. Lyle On Tue, Mar 7, 2017 at 2:43 AM, Ladislav Lhotka wrote: > Hi, > > while the use case is clear, I believe such rather fundamental changes > to YANG cannot be done through extensions because otherwise the value of > YANG as a standard will be lost. > > Lada > > Lyle Bertz writes: > > > All, > > > > This is a small submission that allows a single augment statement to be > > used to augment multiple schema locations or, at the very least, give the > > YANG to language generation tools a hint that the augment is similar to > > other augments in the module. > > > > It can be found at > > https://datatracker.ietf.org/doc/draft-bertz-netmod-commonaugment/ > > > > It is in direct response to issues that arose writing YANG for the IETF > DMM > > FPC specification that can be found at > > https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ > > > > and also in response to issues found wrt yangtools (OpenDaylight) code > > generation of the FPC specification. > > > > Lyle > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > --001a113c523865a4a1054a4ecff6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Understood.

Let's discuss at th= e meeting though.=C2=A0 This was a significant issue in the development of = the IETF DMM FPC yang files and our open source project.=C2=A0=C2=A0 I am o= pen to this going in the proper direction wherever that is but wanted to br= ing the issue and a possible solution to the table.

Lyle


On Tue, Mar 7, 2017 at 2:43 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,

while the use case is clear, I believe such rather fundamental changes
to YANG cannot be done through extensions because otherwise the value of YANG as a standard will be lost.

Lada

Lyle Bertz <lyleb551144@gmail.c= om> writes:

> All,
>
> This is a small submission that allows a single augment statement to b= e
> used to augment multiple schema locations or, at the very least, give = the
> YANG to language generation tools a hint that the augment is similar t= o
> other augments in the module.
>
> It can be found at
> https://datatracker.ietf.org/= doc/draft-bertz-netmod-commonaugment/
>
> It is in direct response to issues that arose writing YANG for the IET= F DMM
> FPC specification that can be found at
> https://datatracker.ietf.org/doc/= draft-ietf-dmm-fpc-cpdp/
>
> and also in response to issues found wrt yangtools (OpenDaylight) code=
> generation of the FPC specification.
>
> Lyle
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

--001a113c523865a4a1054a4ecff6-- From nobody Thu Mar 9 10:33:38 2017 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 47113129795 for ; Thu, 9 Mar 2017 10:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 4HnpUDmnqAE1 for ; Thu, 9 Mar 2017 10:33:34 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 D0564129705 for ; Thu, 9 Mar 2017 10:33:33 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id t189so62916270wmt.1 for ; Thu, 09 Mar 2017 10:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=gNLPoXxdS+1vsKebEZdjFgrROj4z85/M+iefZlgyeF8=; b=Ob+eGTwK9A+rUPdwTg+46iiXQjVBuA8PyUUtX/tUbk/CH0zHjL7UQzoqE+TmywMZa4 pUoLiO3dtrB5yh5V1JefdZ7r1yA3HFZ3zedIaXnsLrNni9vZccOFXoT9QpI4mWZo3JfX t5OSaQWLHUkG0aBbHl4Za65qONb+yAc8IEq4I/D6dZniiAgIxjC6jYvzeEevyGWyKmgc jdnW7k/qUsY6o3dcGLFTYh0YlqKXe25TBRkbdjWUinV/1taRMtp5r+48/944NZiqoqtZ Cf0AdAHWEMCyrDvcCCShFrI1/nGsVRnQPxN9yuDCX1JFibxT5yV1saRVt915hfbvVuDm 8xPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=gNLPoXxdS+1vsKebEZdjFgrROj4z85/M+iefZlgyeF8=; b=UIqQSt3RZTVo8Ufr/hWkMHxabTy1pBdo6Ee98PjVtGyHGZfktTNY5ki8o+/1atvYan 8twJJyLiUZzOQxA0C1Ugbk0XTh2jOh8rk64GY+MAgXWFtnwI+xJImxEDtgNMKxZhdOFK ZaUIbQoGriVzg6Z6nYFrkMJ2mm8etdBo36lcJNb5KpH5rxZCZpRDF/pXzCxwIxcwr6B6 CuBQ8aBYwqzQi/NVUC8dl9Xxch9ahXj8slzFMQ5ubs8Lj9Oe3r6E7OpbOUEOdMhcBl+t gjKa4MsbDEb9G/5FKte00Q/fbs6yDm/SslF7COHr2eslPLzuhL0jpxvBtQ6VI0+jTSFX ScNA== X-Gm-Message-State: AMke39n+e2eSKx8+uFIwzZSx5SAANiReA4CkGhHjbDOp36KSQWlHWC5yMtTO9pEVijlZ4g== X-Received: by 10.28.54.89 with SMTP id d86mr28138852wma.137.1489084412211; Thu, 09 Mar 2017 10:33:32 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B34199C.dip0.t-ipconnect.de. [91.52.25.156]) by smtp.gmail.com with ESMTPSA id e16sm9235609wra.36.2017.03.09.10.33.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 10:33:31 -0800 (PST) From: "Mehmet Ersue" To: "'Lou Berger'" , "'Kent Watsen'" , "'Susan Hares'" References: <01a101d29757$b405beb0$1c113c10$@ndzh.com> <017401d29767$41970e50$c4c52af0$@gmail.com> <00f801d29770$7a42dfa0$6ec89ee0$@ndzh.com> <027a01d29781$24d32b40$6e7981c0$@gmail.com> <24CF7954-A7B3-4550-AFF7-9898EE175FA2@juniper.net> <013901d29825$264ae4a0$72e0ade0$@gmail.com> <4986ca5e-712a-291b-2fe0-3db4b820dda2@labn.net> <01c001d29852$722b5b70$56821250$@gmail.com> <47e9fcd0-f03d-ef2a-21e2-3903c193caed@labn.net> In-Reply-To: <47e9fcd0-f03d-ef2a-21e2-3903c193caed@labn.net> Date: Thu, 9 Mar 2017 19:33:30 +0100 Message-ID: <02b501d29903$a6cfe600$f46fb200$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gIsUOtUAnaIwygB1AGuegIZIUmAAZiY54sB+xxj7wGVJR/EAjtZgDACdrDAS6CmI29Q Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0204.58C19FFB.00A6,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: 'NetMod WG' Subject: [netmod] FW: draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:33:37 -0000 Hi Lou, no issue at all, we can get in sync again. As I see in exchanged mails = we discussed to not hurry and to plan a joint session. AFAIK the timing between 7950bis and NETCONF documents as well as the = content split is still subject to finalize. It is not clear yet how and where to address = draft-voit-netmod-yang-notifications2. Eric Voit's proposal is to do it = in NETMOD WG. Kent was asking for a discussion in NETCONF WG on to how we can address = NETCONF extensions going to be proposed in the new DS concept draft. I would like to suggest to continue the discussion on the maillist but = give WG members in IETF 98 some room to comment before calling it final = and giving to Benoit. This I believe is necessary because of the dependent work we have on the = two charters. Thanks, Mehmet -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Wednesday, March 8, 2017 10:50 PM To: Mehmet Ersue ; 'Kent Watsen' = ; 'Susan Hares' ; netmod@ietf.org Cc: netmod-chairs@ietf.org; 'Benoit Claise' ; 'Mahesh = Jethanandani' Subject: Re: [netmod] draft netmod charter update proposal Mehmet, I'm sorry if we somehow got out of sync. I certainly agree that we've = agreed to having the chairs only coordination meeting you suggested, but = I (and I suspect Kent) never thought this gated work on the NetMod = charter but was more to ensure smooth cooperation between the groups. I = also thought we made it clear that we expected to have per-WG charter = discussions in our respective session s on Tuesday rather than in a = joint session. It was always our hope that the NetMod WG charter would = be finalized before Chicago -- I'm sorry if we didn't state this = explicitly. We expect to have a lot to discuss in the NetMod WG = sessions and wanted to allocate time to focus on technical progress vs = process, as well as ensure that all in the WG had equal opportunity to = provide input via the list. Certainly Benoit and the IESG will need to approve both Charters, but = the timing of this is up to them. I personally see that NetMod and = NetConf efforts are largely deconflicted at this point so I don't have = reservations with them progressing separately. Lou On 3/8/2017 4:25 PM, Mehmet Ersue wrote: > Lou, > > I don't understand the plan change. > We were discussing to have time for a joint charter discussion in = Chicago. > > Any decision/agreement in a physical WG session will be verified on = the maillist. > In any case once we are finished on the maillist, Benoit will review = both together. > The two charters from NETCONF/NETMOD have to go hand in hand and one = cannot be approved by IESG before the other. > > Mehmet > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, March 8, 2017 7:18 PM >> To: Mehmet Ersue ; 'Kent Watsen' >> ; 'Susan Hares' ;=20 >> netmod@ietf.org >> Cc: netmod-chairs@ietf.org >> Subject: Re: [netmod] draft netmod charter update proposal >> >> Hi Mehmet/Sue, >> >> Our (NETMOD chair's) plan is to have had sufficient on-list=20 >> discussion so that we can submit the updated charter to the IESG=20 >> *before* the Chicago meeting, and then to review the changes in=20 >> Chicago. We want to ensure that we have full participation and input = >> on the list as this >> *is* official process and we want to be sensitive to those who may=20 >> not be able to travel to this meeting. >> >> Lou >> >> >> On 3/8/2017 11:00 AM, Mehmet Ersue wrote: >>> What I meant with joint session can be achieved with a (e.g.=20 >>> 20-30min) >> time-slot in NETMOD or NETCONF session on Tuesday where we invite=20 >> I2RS people to attend. We can discuss the charter details and agree = "all together" >> on the plan and work split. >>> Does this make sense? >>> >>> Mehmet >>> >>>> -----Original Message----- >>>> From: Kent Watsen [mailto:kwatsen@juniper.net] >>>> Sent: Wednesday, March 8, 2017 1:51 AM >>>> To: Mehmet Ersue ; 'Susan Hares' >>>> ; netmod@ietf.org >>>> Cc: netmod-chairs@ietf.org >>>> Subject: Re: [netmod] draft netmod charter update proposal >>>> >>>> Hi Sue, >>>> >>>> First, please be aware that the next version of revised-datastores=20 >>>> draft further defines the control-plane datastore concept. This=20 >>>> includes providing guidelines that other WGs can follow to define=20 >>>> their own control-plane datastores, and includes an Appendix=20 >>>> section outlining the creation of an "ephemeral" datastore. The=20 >>>> idea is to give the I2RS WG the ability to define >>>> datastore(s) as needed >>>> (read: future I2RS WG drafts). >>>> >>>> Regarding: >>>> >>>>> Does c) and d) include additions to include I2RS ephemeral state >>>>> as part of an I2RS control plane protocol? If not, which WG >>>>> works on the I2RS ephemeral additions to Yang for control plane=20 >>>>> data stores? >>>> I don't fully understand the question, but believe that the NETMOD=20 >>>> activities needed to support I2RS are all covered by a), b), and = c). >>>> Things that belong to NETCONF WG will include any needed changes to = >>>> protocol, YANG-Library, or any other draft maintained by that WG. >>>> Everything else goes to I2RS. >>>> >>>> I'm not sure what Mehmet means by a "joint session", but I think=20 >>>> that it's too late to add such a session to the IETF Agenda at this = point. >>>> That said, I plan a schedule another datastore breakout session=20 >>>> (likely on Wed morning) that could be used to discuss I2RS some,=20 >>>> and I also plan on attending the I2RS meeting Wed afternoon. >>>> >>>> Kent >>>> >>>> >>>> -----ORIGINAL MESSAGE----- >>>> >>>> Sounds good as a first approximation. Though we need to discuss the = >>>> details and agree. >>>> It might be useful to plan a joint session on Tue or Wed in = Chicago. >>>> >>>> Cheers, >>>> Mehmet >>>> >>>>> -----Original Message----- >>>>> From: Susan Hares [mailto:shares@ndzh.com] >>>>> Sent: Tuesday, March 7, 2017 7:27 PM >>>>> To: 'Mehmet Ersue' ; 'Kent Watsen' >>>>> ; netmod@ietf.org >>>>> Cc: netmod-chairs@ietf.org >>>>> Subject: RE: [netmod] draft netmod charter update proposal >>>>> >>>>> Mehmet: >>>>> >>>>> Thank you for the excellent question clarifying my questions. My >>>> questions >>>>> (b) - related to protocol extension for I2RS for RESTCONF, NETCONF = >>>>> or >>>> CoAP. >>>>> I have removed that one. >>>>> >>>>> I restate my question below, and the [xx] indicates my = understanding. >>>>> >>>>> Does c and d state the following are handled: >>>>> 1) informational concepts for the DS handling - [Netmod] >>>>> 2) generic extensions to Yang to describe control plane datastore=20 >>>>> yang modules - [netmod] >>>>> 3) generic extensions to Yang to describe the ephemeral state in=20 >>>>> control plane yang modules - [I2RS] >>>>> 4) I2RS specific extensions to support the I2RS control plane=20 >>>>> datastore's validation - [I2RS] >>>>> 5) Any I2RS Yang modules- [I2RS] >>>>> >>>>> To provide precision on this point, I will give examples of work=20 >>>>> related >>>> to >>>>> each question: >>>>> 1) draft-ietf-netmod-revised-datastores-00.txt [netmod] >>>>> 2) extensions to describe control plane data store yang modules: >>>>> a) control plane data store definitions added to >>>> draft-ietf-netmod-yang- >>>>> model-classification [netmod] >>>>> b) extensions to the Yang 1.1 - to provide a syntax to describe >>>> datastores in >>>>> which a module exists >>>>> datastore should include syntax to identify identity and >>>> prioritization >>>>> config data store. [netmod] >>>>> c) extension to describe the merged tree in applied datastore=20 >>>>> and >>>> opstate >>>>> datastore [netmod] >>>>> d) mount extensions that allow mounting modules in different=20 >>>>> datastores >>>>> >>>>> 3) generic extensions to describe ephemeral state the I2RS control = >>>>> plane datastore [I2RS] >>>>> a) extensions can define validation specific to I2RS control=20 >>>>> plane datastore. >>>>> b) rpc can be used for validation of modules >>>>> that seek to mounted in either the I2RS control plane=20 >>>>> datastore or >>>> the >>>>> configuration data store. >>>>> >>>>> 4) I2RS specific extensions to support I2RS features in the I2RS=20 >>>>> control >>>> plane >>>>> data store. >>>>> >>>>> My earlier: - is a question for NETCONF/RESTCONF, or CoAP. >>>>> b) standard extensions to the protocol (e.g. I2RS or >> NETCONF/RESTCONF) >>>>> to enable the usage of DS - [protocol group or WG] >>>>> >>>>> >>>>> Sue >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Mehmet Ersue [mailto:mersue@gmail.com] >>>>> Sent: Tuesday, March 7, 2017 12:21 PM >>>>> To: 'Susan Hares'; 'Kent Watsen'; netmod@ietf.org >>>>> Cc: netmod-chairs@ietf.org >>>>> Subject: RE: [netmod] draft netmod charter update proposal >>>>> >>>>> Hi Sue, >>>>> >>>>> AFAICS your question kind of mixes between "I2RS control plane >> protocol" >>>>> and "ephemeral additions to Yang". >>>>> I believe different WGs are responsible for the part they own. >>>>> E.g. protocol-specific part should be done in the WG owning the >> protocol. >>>>> Can you please differentiate in your question between the aspects=20 >>>>> below (my assumption in [ ]? >>>>> a) informational concept for the DS handling [netmod] >>>>> b) standard extensions to the protocol (e.g. I2RS or >>>>> NETCONF/RESTCONF) to enable the usage of DS [protocol WGs, e.g. >>>>> I2RS] >>>>> c) generic extensions to YANG language usable by many protocols=20 >>>>> [netmod] >>>>> d) any specific YANG modules necessary for the use of DS=20 >>>>> [protocols WGs] >>>>> >>>>> BR, >>>>> Mehmet >>>>> >>>>>> -----Original Message----- >>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan >>>>> Hares >>>>>> Sent: Tuesday, March 7, 2017 4:30 PM >>>>>> To: 'Kent Watsen' ; netmod@ietf.org >>>>>> Cc: netmod-chairs@ietf.org >>>>>> Subject: Re: [netmod] draft netmod charter update proposal >>>>>> >>>>>> Kent and Lou: >>>>>> >>>>>> Clarifying questions: >>>>>> >>>>>> Does c) and d) include additions to include I2RS ephemeral state=20 >>>>>> as part >>>>> of >>>>>> an I2RS control plane protocol? If not, which WG works on = the I2RS >>>>>> ephemeral additions to Yang for control plane data stores? >>>>>> >>>>>> Sue >>>>>> >>>>>> -----Original Message----- >>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent >>>>> Watsen >>>>>> Sent: Wednesday, February 22, 2017 7:25 PM >>>>>> To: netmod@ietf.org >>>>>> Cc: netmod-chairs@ietf.org >>>>>> Subject: [netmod] draft netmod charter update proposal >>>>>> >>>>>> >>>>>> Hi NETMOD WG, >>>>>> >>>>>> Please find below the draft charter update which we provided to=20 >>>>>> our AD for review. Comments are welcomed. Authors, please note=20 >>>>>> the milestone dates. >>>>>> >>>>>> Kent (and Lou) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Network Modeling (NETMOD) >>>>>> ------------------------- >>>>>> >>>>>> Charter >>>>>> >>>>>> Current Status: Active >>>>>> >>>>>> Chairs: >>>>>> Lou Berger >>>>>> Kent Watsen >>>>>> >>>>>> Operations and Management Area Directors: >>>>>> Benoit Claise >>>>>> Joel Jaeggli >>>>>> >>>>>> Operations and Management Area Advisor: >>>>>> Benoit Claise >>>>>> >>>>>> Secretary: >>>>>> Zitao (Michael) Wang >>>>>> >>>>>> Mailing Lists: >>>>>> General Discussion: netmod@ietf.org >>>>>> To Subscribe: = https://www.ietf.org/mailman/listinfo/netmod >>>>>> Archive: = https://mailarchive.ietf.org/arch/browse/netmod/ >>>>>> >>>>>> Description of Working Group: >>>>>> >>>>>> The Network Modeling (NETMOD) working group is responsible for = >>>>>> the YANG >>>>>> data modeling language, and guidelines for developing YANG = models. >>>>> The >>>>>> NETMOD working group addresses general topics related to the=20 >>>>>> use of >>>>> the >>>>>> YANG language and YANG models, for example, the mapping of >> YANG >>>>>> modeled >>>>>> data into various encodings. Finally, the NETMOD working = group also >>>>>> defines core YANG models used as basic YANG building blocks,=20 >>>>>> and >>>> YANG >>>>>> models that do not otherwise fall under the charter of any = other IETF >>>>>> working group. >>>>>> >>>>>> The NETMOD WG is responsible for: >>>>>> >>>>>> a) Maintaining the data modeling language YANG. This effort = entails >>>>>> periodically updating the specification to address new >>>> requirements >>>>>> as they arise. >>>>>> >>>>>> b) Maintaining the guidelines for developing YANG models. =20 >>>>>> This >>>> effort >>>>>> is primarily driven by updates made to the YANG = specification. >>>>>> >>>>>> c) Maintaining a conceptual framework in which YANG models are >> used. >>>>>> This effort entails describing the context that network = management >>>>>> protocols (e.g., NETCONF, RESTCONF, CoAP, etc.) operate in, = and >>>>>> how certain YANG statements interact in that context. >>>>>> >>>>>> d) Maintaining encodings for YANG modeled data. This effort = entails >>>>>> updating encodings already defined by the NETMOD working=20 >>>>>> (XML >>>> and >>>>>> JSON) to accommodate changes to the YANG specification, and >>>> defining >>>>>> new encodings that are needed and yet do not fall under the >>>> charter >>>>>> of any other active IETF working group. >>>>>> >>>>>> e) Maintaining YANG models used as basic YANG building blocks. = This >>>>>> effort entails updating existing YANG models = (ietf-yang-types and >>>>>> ietf-inet-types) as needed, as well as defining additional=20 >>>>>> core >>>> YANG >>>>>> data models when necessary. >>>>>> >>>>>> f) Defining and maintaining YANG models that do not fall under = the >>>>>> charter of any other active IETF working group. >>>>>> >>>>>> The NETMOD working group consults with the NETCONF working >> group >>>> to >>>>>> ensure that new requirements are and understood and can be met >> by >>>>>> the protocols developed within that working group (e.g., = NETCONF >>>>>> and RESTCONF). The NETMOD working group coordinates with = other >>>>>> working groups on possible extensions to YANG to address new >>>> modeling >>>>>> requirements and, when needed, which group will run the=20 >>>>>> process on >> a >>>>>> specific model. >>>>>> >>>>>> The NETMOD working group does not serve as a review team for >> YANG >>>>>> modules developed by other working groups. Instead, the YANG >>>> doctors, >>>>>> as organized by the OPS area director responsible for network >>>>>> management, will act as advisors for other working groups and >> provide >>>>>> YANG reviews for the OPS area directors. >>>>>> >>>>>> Milestones: >>>>>> >>>>>> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for >>>> publication >>>>>> Mar 2016 - Submit draft-ietf-netmod-yang-model-classification=20 >>>>>> to >> IESG >>>>>> for publication >>>>>> Mar 2016 - Submit draft-ietf-netmod-syslog-model to IESG for >>>>> publication >>>>>> Mar 2016 - Submit draft-ietf-netmod-acl-model to IESG for = publication >>>>>> Mar 2017 - Submit draft-ietf-netmod-entity to IESG for = publication >>>>>> Oct 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for >>>>>> publication >>>>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for >>>>> publication >>>>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG = for >>>>>> publication >>>>>> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG = for >>>>>> publication >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Mar 9 10:36:18 2017 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 9192F12979D for ; Thu, 9 Mar 2017 10:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 jUlG4cosl_TR for ; Thu, 9 Mar 2017 10:36:14 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2B31296C3 for ; Thu, 9 Mar 2017 10:36:13 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id t189so62967181wmt.1 for ; Thu, 09 Mar 2017 10:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=8GfRqU7IBy2galaWLAzaklNySAASQgs/kINt/FKU39M=; b=Vj4x6FP/m4rdIgHpfcfvkYTPV0OuWp5cxfVzyBugkurHhuqjW95WYQr+tyFAMFzNwR XQsknkCYcJNtl6jw3C4l+CJFEd2aiMfMMh7GPjdX9C5SJXsLEwMoV0E4QLL1gMB/b4Hw nWzHRmr9aNkSimjHoo2d4qASJSyhiVbhUY5/V5mi0ALHXCkEg0Y0hldocMeRg5mKFkYc AFpd6RJtropqRW+DGC7xcgP1hCvIihKk/hTbfdObtlh9CsfTU0izGOHwhtyhi7+GaBmX LqXxE8HEUjqFW5tLO4org8thRlIh6bk7FcgZnRAM8+jZM/xciPxPj/bfJcsOGBCU2gTp uzEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=8GfRqU7IBy2galaWLAzaklNySAASQgs/kINt/FKU39M=; b=bun4UTSVfj+rmRwQ+TXHhetqHfRGwLc1HMTiM8YoiYIVVXqQapeZgFpy+pT6rHlP8l RzwFcvX04v6roRzvlQvz3V+atDaccTSCFsRqbiVYEw1GnJXwJ0Z6nylxd+GtB3qDXjkw 1nKI5jqG3Nu6fl4LYTscxaFb8bEKCfVGZ5wi7FW1rwE9tenijvkYs0Yn0KWL/T9rIG9Z PogQ54/8W9wa6EyHll+r8hYYL/I9wC4c0G4YWyuNot0W7wXVupsk3mGz0v3ZoOv03gZB +3o2rdJ9q/HUxPsqq5ABhnJ6llPfmFTvjt+djs1y9GsRHZuF5s9RMICPe9PX3ukcfvgQ DU7w== X-Gm-Message-State: AMke39lO0ceEWOalXinWPMihU//ebb93pX4oi8/FT4WHwpldMSLihqwU92fkoonT2Z6Tng== X-Received: by 10.28.186.195 with SMTP id k186mr20790281wmf.1.1489084572132; Thu, 09 Mar 2017 10:36:12 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B34199C.dip0.t-ipconnect.de. [91.52.25.156]) by smtp.gmail.com with ESMTPSA id f48sm9176377wrf.17.2017.03.09.10.36.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 10:36:11 -0800 (PST) From: "Mehmet Ersue" To: "'Lou Berger'" , "'Kent Watsen'" , References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> In-Reply-To: Date: Thu, 9 Mar 2017 19:36:08 +0100 Message-ID: <02b701d29904$054c6fa0$0fe54ee0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUoqgvM/28A== Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0202.58C1A09B.0050,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:36:16 -0000 Hi Lou, > The charters from the last couple of years don't have the intended status -- at least the ones we checked. > I actually feel pretty strongly about this (which of course can be easily overruled by our AD). It's my experience that premature discussions on intended status, i.e., > before a document is sufficiently mature, leads to process-focused arguments that detracts from making technical progress. While once a document is mature and > core direction/content is fixed, it is generally obvious what status is appropriate. The charters from the last couple of years have a short WG item definition, which would be IMO sufficient. You are right the intended status is not available since a few years, but IMO it is part of the target definition and would be very useful for the draft authors and WG members to regard. > > It would be good to bring the high-level topics in relation to the WG items. > I'm sorry, I don't understand this last sentence can you rephrase it? What I meant is that the high-level topics a)-f) might be good as WG focus description but are not sufficient as draft target definition. If you think the high-level topic description is more or less the WG item definition, then we could simply write "this is achieved with WG item XY". If not, we could keep the high-level focus text but set additionally the borders of the WG item with some concrete words. > > BTW: We agreed in diverse discussions that the DS concept is Informational in nature. > > I think this should be corrected in the draft. > > So this sounds like an objection to a specific document. This is a fair point to > raise, but in our opinion it is not a charter impacting point or discussion. If this > is in fact the issue you'd like to raise and discuss, lets do so under a document > specific thread, e.g., "Subject: intended status of revised-datastore". I am actually raising this point since November meeting. There are different threads where I explained why it is appropriate as Informational. The last thread I remember is at: https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH11xcY The recent position of NETCONF co-chairs is in https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd8qr5k Thank you for your consideration. Regards, Mehmet > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, March 8, 2017 11:28 PM > To: Mehmet Ersue ; 'Kent Watsen' > ; netmod@ietf.org > Subject: Re: [netmod] draft netmod charter update proposal > > Hi Mehmet, > > On 3/8/2017 4:47 PM, Mehmet Ersue wrote: > > Kent, > > > >> we understand that this is how NETCONF charters are structured, but > >> it is not our practice, > > AFAIK it was the NETMOD practice for the charters until today. > > The charters from the last couple of years don't have the intended status -- > at least the ones we checked. > > I actually feel pretty strongly about this (which of course can be easily > overruled by our AD). It's my experience that premature discussions on > intended status, i.e., before a document is sufficiently mature, leads to > process-focused arguments that detracts from making technical progress. > While once a document is mature and core direction/content is fixed, it is > generally obvious what status is appropriate. > > > > I did not ask > > more than written in the current charter. > > It would be good to bring the high-level topics in relation to the WG items. > I'm sorry, I don't understand this last sentence can you rephrase it? > > >> as the information is available at the top of each draft, and also because > this information need not be fixed when the milestone is added. > > > I believe a WG charter should be self-sufficient covering the target > > definition and intended status of the WG items. > > Otherwise one can change the target for a WG item by simply editing > > the draft abstract anytime. > > Per IETF process, all it ever takes to make a change in document status is WG > consensus, and then IESG and IETF buy-in as part of the publication process. > > > BTW: We agreed in diverse discussions that the DS concept is > > Informational in nature. > > I think this should be corrected in the draft. > > So this sounds like an objection to a specific document. This is a fair point to > raise, but in our opinion it is not a charter impacting point or discussion. If this > is in fact the issue you'd like to raise and discuss, lets do so under a document > specific thread, e.g., "Subject: > intended status of revised-datastore". > > Thanks, > Lou > > > > > Mehmet > > > >> -----Original Message----- > >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent > >> Watsen > >> Sent: Wednesday, March 8, 2017 7:45 PM > >> To: netmod@ietf.org > >> Cc: netmod-chairs@ietf.org > >> Subject: Re: [netmod] draft netmod charter update proposal > >> > >> > >> > >> > >> Hi NETMOD WG, > >> > >> Please find below draft-4 having the following change: > >> > >> - added "(e.g., I2RS, RTGWG)" to a sentence. > >> > >> Hi Sue, Lou and I looked at the proposed charter and found a sentence > >> that nicely describes our WG's intent to work with and support other > >> WGs (beyond NETCONF), but we felt that the text could be made more > >> clear by adding in the above-mentioned change. Beyond this, and the > >> existing a), > > b), > >> and c), we believe that the charter proposal covers our support for > >> I2RS, > > do > >> you agree? > >> > >> Hi Mehmet, regarding putting a short description and the intended > >> status > > for > >> each draft into the charter, we understand that this is how NETCONF > > charters > >> are structured, but it is not our practice, as the information is > > available at the > >> top of each draft, and also because this information need not be > >> fixed > > when > >> the milestone is added. > >> > >> All, Any other comments? > >> > >> Kent > >> > >> > >> > >> > >> Network Modeling (NETMOD) > >> ------------------------- > >> > >> Charter > >> > >> Current Status: Active > >> > >> Chairs: > >> Lou Berger > >> Kent Watsen > >> > >> Operations and Management Area Directors: > >> Benoit Claise > >> Joel Jaeggli > >> > >> Operations and Management Area Advisor: > >> Benoit Claise > >> > >> Secretary: > >> Zitao (Michael) Wang > >> > >> Mailing Lists: > >> General Discussion: netmod@ietf.org > >> To Subscribe: https://www.ietf.org/mailman/listinfo/netmod > >> Archive: https://mailarchive.ietf.org/arch/browse/netmod/ > >> > >> Description of Working Group: > >> > >> The Network Modeling (NETMOD) working group is responsible for the > >> YANG > >> data modeling language, and guidelines for developing YANG models. > The > >> NETMOD working group addresses general topics related to the use of > the > >> YANG language and YANG models, for example, the mapping of YANG > >> modeled > >> data into various encodings. Finally, the NETMOD working group > >> also defines core YANG models used as basic YANG building blocks, and > >> YANG models that do not otherwise fall under the charter of any other > >> IETF working group. > >> > >> The NETMOD WG is responsible for: > >> > >> a) Maintaining the data modeling language YANG. This effort entails > >> periodically updating the specification to address new requirements > >> as they arise. > >> > >> b) Maintaining the guidelines for developing YANG models. This effort > >> is primarily driven by updates made to the YANG specification. > >> > >> c) Maintaining a conceptual framework in which YANG models are used. > >> This effort entails describing the generic context that in YANG > >> exists and how certain YANG statements interact in that context. > >> An example of this is YANG's relationship with datastores. > >> > >> d) Maintaining encodings for YANG modeled data. This effort entails > >> updating encodings already defined by the NETMOD working (XML and > >> JSON) to accommodate changes to the YANG specification, and > defining > >> new encodings that are needed, and yet do not fall under the charter > >> of any other active IETF working group. > >> > >> e) Maintaining YANG models used as basic YANG building blocks. This > >> effort entails updating existing YANG models (ietf-yang-types and > >> ietf-inet-types) as needed, as well as defining additional core YANG > >> data models when necessary. > >> > >> f) Defining and maintaining YANG models that do not fall under the > >> charter of any other active IETF working group. > >> > >> The NETMOD working group consults with the NETCONF working group > to > >> ensure that new requirements are understood and can be met by the > >> protocols (e.g., NETCONF and RESTCONF) developed within that working > >> group. The NETMOD working group coordinates with other working > groups > >> (e.g., I2RS, RTGWG) on possible extensions to YANG to address new > >> modeling requirements and, when needed, which group will run the > >> process on a specific model. > >> > >> The NETMOD working group does not serve as a review team for YANG > >> modules developed by other working groups. Instead, the YANG > doctors, > >> as organized by the OPS area director responsible for network > >> management, will act as advisors for other working groups and provide > >> YANG reviews for the OPS area directors. > >> > >> Milestones: > >> > >> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for publication > >> Mar 2017 - Submit draft-ietf-netmod-yang-model-classification to IESG > >> for publication > >> Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for publication > >> Apr 2017 - Submit draft-ietf-netmod-entity to IESG for publication > >> Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG for > > publication > >> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for > > publication > >> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for > >> publication > >> Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > >> publication > >> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for > >> publication > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 Mar 9 11:13:59 2017 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 E8B91128824 for ; Thu, 9 Mar 2017 11:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvBIpbOahh6G for ; Thu, 9 Mar 2017 11:13:57 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 98242129463 for ; Thu, 9 Mar 2017 11:13:56 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id l37so51558566wrc.1 for ; Thu, 09 Mar 2017 11:13:56 -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=9JNi1PtvCEa5HyHwq5VXmZPVz3fG3SI+xSHdbjcXOb0=; b=CEtsFSlv6//B/gGhL61nWjY4znoklmsn2iCSi8q0H1LTjGKv8xZWmlfJekV2WgCm9P ICe+2w400oqhLBIES2SSS+S3JhearJ3Z/spwpqD4Km7TDT6rFVuDLGYp/KvLwz6ARUz/ +vxMvqAMuU6PBJhMIT4kQi4D+5yAz7BG2u5g8UXzPuV28g5DPUlxfIUawjmUwJ2E6Z1Q 9f0mnVgCcXPb9lXWiIqSo84QgrCymGJW4oX8gVoikVZ/5OwCVeafS8grAwactC7fxrZH 6jTsJMWVZnrujLe12RxE77CmaPrlgwvcGh6oheK+EYvOnopVRXAcq2mHRclT/qSYOlaW 7bQA== 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=9JNi1PtvCEa5HyHwq5VXmZPVz3fG3SI+xSHdbjcXOb0=; b=Mblx3Tef/J5oOgsgva4UT+zGex58Q32Y2ndlGm7D6cMxal7CWzFe/fjkrMgqaYVQRh sJFFLMmZSBmSTudKpDmTioUE2RIOdgadmCe+bcYsA89bBpXH58yilbsGQAvquvoEIG9d G83ULi3U/IdEaaF8QZwH04Jnz88AC4izt5KMJ6xE76p33X202L1RpJUH72OlxyRPCDj4 yxb+mCzXQmhzRPKKWsKFv6/DsbNDqfWVUMZRlkwOetWIj/XxEXUT5qugYe9GrfrRjHyB qT+OzbAzkpzwfapEqnYXLkst0x85tOes5v2ZbieQtovJ7LZKAM/w9jJFBpzhRW2/qDAs 07tg== X-Gm-Message-State: AMke39lMkF60If5IGxBG/trTZ2u6tXvD8GYBC0Va6bNu3A9idKZx2VoThPVx3tXICA82P2C9PLzfb+/zjzoK4A== X-Received: by 10.223.138.252 with SMTP id z57mr11873111wrz.110.1489086834993; Thu, 09 Mar 2017 11:13:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.86 with HTTP; Thu, 9 Mar 2017 11:13:54 -0800 (PST) From: Lyle Bertz Date: Thu, 9 Mar 2017 13:13:54 -0600 Message-ID: To: netmod@ietf.org Content-Type: multipart/alternative; boundary=001a113c5238d70386054a510b5f Archived-At: Subject: [netmod] New Version Notification for draft-bertz-netmod-commonaugment-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:13:58 -0000 --001a113c5238d70386054a510b5f Content-Type: text/plain; charset=UTF-8 All, This updates some compilation errors (in the examples) found in 00 Lyle A new version of I-D, draft-bertz-netmod-commonaugment-01.txt has been successfully submitted by Lyle Bertz and posted to the IETF repository. Name: draft-bertz-netmod-commonaugment Revision: 01 Title: YANG extension for Common Augmentations Document date: 2017-03-09 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-bertz-netmod- commonaugment-01.txt Status: https://datatracker.ietf.org/doc/draft-bertz-netmod- commonaugment/ Htmlized: https://tools.ietf.org/html/draft-bertz-netmod- commonaugment-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-bertz-netmod- commonaugment-01 Abstract: This document defines a YANG extension to convey common schema augmentations. --001a113c5238d70386054a510b5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

This updates some compilation = errors (in the examples) found in 00

Lyle

A new ve= rsion of I-D, draft-bertz-netmod-commonaugment-01.txt
has been successfully submitted by Lyle Bertz and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bertz-netmod-commo= naugment
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 YANG extension for Common Augmenta= tions
Document date:=C2=A0 2017-03-09
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-bertz= -netmod-commonaugment-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-bertz-netmod-common= augment/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://tools.ietf.org/html/draft-bertz-netmod-commonaugment-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-bertz-netmo= d-commonaugment-01

Abstract:
=C2=A0 =C2=A0This document defines a YANG extension to convey common schema=
=C2=A0 =C2=A0augmentations.
--001a113c5238d70386054a510b5f-- From nobody Fri Mar 10 03:59:25 2017 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 C659C12955B for ; Fri, 10 Mar 2017 03:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 rXaz0fL6SLL5 for ; Fri, 10 Mar 2017 03:59:22 -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 0642E12954A for ; Fri, 10 Mar 2017 03:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3754; q=dns/txt; s=iport; t=1489147162; x=1490356762; h=to:from:subject:message-id:date:mime-version; bh=KBsKCdfwu16yidmDCrAEEAwVJ3HKyVRe7ey8uxaAc5U=; b=DPIgYXZ0hHWO8YUUrrL2BvsrWfq6rdWnYwnBAq+8xAb04H2PTWHKIE9p HCQa5lS0xbdM04lOWr62YOTWQ3ipa1kubyLJLRrNGDvLm6ZiO+HnxDmqK Bt2uhQdp+ejO75//fJMmtEg8fRChq/qPIBDUDzcZtbP5DKcXQewcOclTa U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZBACllMJY/xbLJq1dHAEBBAEBCgEBh?= =?us-ascii?q?DIqYINgig5zoGiFLYIOKoIdgxGDRBgBAgEBAQEBAQFrKIU/dT4CXw0IAQGJfA6?= =?us-ascii?q?hCZAGgiYrij4BAQEBBgEBAQEBI4ZOggWHMYMTgl8FnDqBUoUki0KCT4gChlGLM?= =?us-ascii?q?4gNHziBAyIWCBcVhxU/NQGHXoI7AQEB?= X-IronPort-AV: E=Sophos;i="5.36,140,1486425600"; d="scan'208,217";a="653168510" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2017 11:59:17 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2ABxHig012548 for ; Fri, 10 Mar 2017 11:59:17 GMT To: NETMOD Working Group From: Benoit Claise Message-ID: <4ede1dcd-901d-cc9d-765c-7900a14e28f4@cisco.com> Date: Fri, 10 Mar 2017 12:59:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F5A33FEF87E5D0900D687A1A" Archived-At: Subject: [netmod] Toolchain upgraded to yanglint 0.12.116 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 11:59:24 -0000 This is a multi-part message in MIME format. --------------F5A33FEF87E5D0900D687A1A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Radek released a new version of libyang and yanglint. See https://github.com/CESNET/libyang/releases/tag/v0.12-r1 The main features of this release are: * various bugfixes * support for YANG extensions (libyang's schema tree structures changed) * ietf-metadata implemented - support for annotations represented in data as data nodes' attributes * added possibility to set all the imported modules as implemented * YANG parser's error messages extended by the path of the invalid node * nodes, used in |must| and |when| XPath expressions, which are not found in schema are reported as warnings, not errors - refering non-exiting nodes is generally allowed despite it is useless The major enhancement is the YANG extension support. In the past, yanglint would generate a warning: warn: Not supported "mount-point" extension statement found, ignoring. All these warnings are now gone, and this makes a difference . Also, a couple of false positives have been fixed in this version. See http://www.claise.be/IETFYANGPageCompilation.html, and check your YANG modules. FYI, the toolchain is composed of: pyang 1.7.1, confdc 6.3 , yangdump-pro 16.10-5, yanglint 0.12.116 Regards, Benoit --------------F5A33FEF87E5D0900D687A1A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

Radek released a new version of libyang and yanglint. See https://github.com/CESNET/libyang/releases/tag/v0.12-r1

The main features of this release are:

  • various bugfixes
  • support for YANG extensions (libyang's schema tree structures changed)
  • ietf-metadata implemented - support for annotations represented in data as data nodes' attributes
  • added possibility to set all the imported modules as implemented
  • YANG parser's error messages extended by the path of the invalid node
  • nodes, used in must and when XPath expressions, which are not found in schema are reported as warnings, not errors - refering non-exiting nodes is generally allowed despite it is useless
The major enhancement is the YANG extension support. In the past, yanglint would generate a warning:
warn: Not supported "mount-point" extension statement found, ignoring.
All these warnings are now gone, and this makes a difference.

Also, a couple of false positives have been fixed in this version.
See http://www.claise.be/IETFYANGPageCompilation.html, and check your YANG modules.

FYI, the toolchain is composed of:
    pyang 1.7.1,
    confdc 6.3 ,
    yangdump-pro 16.10-5,
    yanglint 0.12.116

Regards, Benoit --------------F5A33FEF87E5D0900D687A1A-- From nobody Fri Mar 10 04:00:58 2017 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 78D4012954A for ; Fri, 10 Mar 2017 04:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 t8qlPMqqDtdu for ; Fri, 10 Mar 2017 04:00:55 -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 68BB8129545 for ; Fri, 10 Mar 2017 04:00:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7363; q=dns/txt; s=iport; t=1489147254; x=1490356854; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=tGUkMY64mSTst9tqrLC6k84VVDr75TXWiO7K40ZPBGw=; b=MCqL6N5+kwRNThA5Bfx0xrd+0JKQzzRM8VYnJ5YSgrEIbY+CoxSuRVei wrSqpgv+3pdKqv+retij8xY5iJOaPYcPKAfJ3gA+vN126eLj53GUq1FkD IPXGwOakawrYw9hapsKVCy3ya70aXpjRGvikzrKZGLguNnT72p6t0xax4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAwCllMJY/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhFyEQIoOc5BdlTiCDoYiAoJ4GAECAQEBAQEBAWsohRUBAQEBAgEjDwE?= =?us-ascii?q?FUQsYAgImAgJXBgEMCAEBiXQIsR2CJoppAQEBAQEBBAEBAQEBAQEhgQuFQ4IFg?= =?us-ascii?q?WGBCYdagl8Fj1iMYpI4ilGGUYszg2yEIR84gQMiFggXFT+GVUCKTwEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,140,1486425600"; d="scan'208";a="653168566" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2017 12:00:50 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2AC0nFh012985; Fri, 10 Mar 2017 12:00:49 GMT To: Ladislav Lhotka , netmod@ietf.org References: <33d0132e-750b-97ed-8bdb-0befeb1b81c3@cisco.com> From: Robert Wilton Message-ID: <0400d1cb-30ce-e074-b707-202026161ebb@cisco.com> Date: Fri, 10 Mar 2017 12:00:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <33d0132e-750b-97ed-8bdb-0befeb1b81c3@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 12:00:56 -0000 Hi Lada, To pick up an old thread, I'm updating the interface model per your comments below, and I had a few questions that you might have an opinion on. On 22/12/2016 14:32, Robert Wilton wrote: > Hi Lada, > > Thanks for the review and comments. > > > On 21/12/2016 13:08, Ladislav Lhotka wrote: >> Hi, >> >> I think this is a very useful addition to ietf-interfaces. In general, >> the document is clearly written and YANG modules nicely designed. Here >> are my comments: >> >> *** Sec. 1 >> - "This document defines two YANG RFC 7950 [RFC7950] modules …" >> looks weird. I'd suggest "… YANG 1.1 [RFC7950] …" instead. > OK. Fixed. >> *** Sec. 2 >> - first line: s/of of/of/ Fixed. >> *** Sec. 3.1 >> - If the "bandwidth" parameter is only used for tuning routing >> algorithms and has nothing to do with real bandwidth on the >> interface, I would suggest to use a different name >> (metric?). Perhaps it may indeed be better to leave this to >> routing protocol modules because they can also specify how >> exactly such a parameter is used. > Yes, possibility it would be better to define this as part of the > routing models. The idea here is that the bandwidth would span across > the routing protocols rather than be tied to a specific protocol. I think that we need a better name than just "bandwidth" since this leaf doesn't affect the actual bandwidth on the of the link, just the bandwidth that is reported to routing protocols to implicitly adjust their link metrics. Hence, I was considering renaming this to "reported-bandwidth"? I also think that it would be good to follow up with the routing folks to see if this leaf would be better covered in a general routing model. Where do you think is the best place that I raise this, the routing area yang design team? > >> *** Sec. 3.6 >> - The "l3-mtu" parameter is probably the same as "mtu" defined in >> ietf-ip. Again, I would suggest to leave the definition of MTU >> to each L3 protocol because there may be specific aspects and >> constraints. > The MTU being defined here is an "l2-mtu" parameter. I.e. the maximum > size of the L2 frames that can be sent/received. For some devices > this value is independent of a protocol specific L3 MTU that only > affects that particular protocol instance. I've updated the text to make it clear that it is only a L2 MTU configuration leaf, and if not configured, the system will automatically decide on the L2 MTU. > > >> *** Sec. 3.8 >> - I think that "transport-layer" is not a good name because in the >> ISO OSI model it denotes a particular layer (L4). How about >> "iso-osi-layer"? I agree that "transport-layer" is somewhat ambiguous. I was wondering whether "service-layer" or "service-type" would work? Or perhaps it could be called "forwarding-mode"? >> - The type of "transport-layer" has three enums, namely >> "layer-[123]". I would suggest to use descriptive names >> ("physical-layer" etc.), include the remaining layers of the ISO >> OSI model, and maybe also define it as a typedef - or does this >> belong to ietf-inet-types? I'm not sure that defining the higher layers of the OSI model helps. Perhaps using identities would be a better choice? Perhaps: "physical-layer" "data-link-layer" "network-layer" But I prefer "layer-2" over "data-link-layer" since I think that term is much more widespread. I'm also not quite sure whether "physical-layer" is actually the right term, I think that is probably really "below-layer-2" >> - Is a leaf sufficient? I think some interfaces can be in multiple >> layers at the same time (e.g. an ATM interface is L3 but can >> also be L2 for Classical IP over ATM). Or is the idea that such >> an interface will be split into two entries of the "interface" >> list? > This needs some further thought/work. I think that using sub-interfaces is the cleanest way of doing this, so each sub-interface can be offering a service at a different layer. > > The main idea here was to be able to label sub-interfaces as > supporting only L2 services or L3 services, since on some platforms > different types of interfaces get instantiated internally. > >> *** YANG modules >> - Descriptions are not consistently formatted. I think that the >> current BCP is to start description text on the same line as the >> "description" keyword only if it all fits on one line. >> - I don't have a strong opinion on this but it might increase >> readability if the number of augments is reduced. Perhaps at >> least augments that contain only one node could be made into one >> (and the "feature" and "when" statements moved to the nodes' >> definitions. > Yes, I'll fix these, probably using Martin's suggested approach. I've fixed the descriptions, and merged all the augments except for the sub-interface one (which is an if-feature conditional augment of a mandatory node). I also have a question about the "encapsulation" container that is currently defined as: /* * Various types of interfaces support a configurable layer 2 * encapsulation, any that are supported by YANG should be * listed here. * * Different encapsulations can hook into the common encaps-type * choice statement. */ container encapsulation { when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or derived-from-or-self(if:type, 'ianaift:pos') or derived-from-or-self(if:type, 'ianaift:atmSubInterface') or derived-from-or-self(if:type, 'ethSubInterface')" { description "All interface types that can have a configurable L2 encapsulation"; /* * TODO - Should we introduce an abstract type to make this * extensible to new interface types, or vendor * specific interface types? */ } description "Holds the OSI layer 2 encapsulation associated with an interface"; choice encaps-type { description "Extensible choice of L2 encapsulations"; } } I was considering removing the when statement to generalize this, since the case statements can be constricted to suitable interface types using when statements anyway. E.g. I'm proposing to changing it to something like this: /* * Various types of interfaces support a configurable * encapsulation. * * Different encapsulations (often layer 2) can hook into the * common encaps-type choice statement. */ container encapsulation { description "Holds the encapsulation (often layer 2) associated with an interface"; choice encaps-type { description "Extensible choice of encapsulations"; } } Do you have a view on this? Thanks, Rob > > Thanks again, > Rob > >> >> Lada >> > From nobody Fri Mar 10 06:09:46 2017 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 7011B12945F for ; Fri, 10 Mar 2017 06:09:45 -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 GYBQieTydh0X for ; Fri, 10 Mar 2017 06:09:43 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E77CD12941A for ; Fri, 10 Mar 2017 06:09:42 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 5E95A1820044; Fri, 10 Mar 2017 15:10:01 +0100 (CET) From: Ladislav Lhotka To: Robert Wilton , netmod@ietf.org In-Reply-To: <0400d1cb-30ce-e074-b707-202026161ebb@cisco.com> References: <33d0132e-750b-97ed-8bdb-0befeb1b81c3@cisco.com> <0400d1cb-30ce-e074-b707-202026161ebb@cisco.com> Date: Fri, 10 Mar 2017 15:09:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 14:09:45 -0000 Hi Rob, please see inline. Robert Wilton writes: > Hi Lada, > > To pick up an old thread, I'm updating the interface model per your=20 > comments below, and I had a few questions that you might have an opinion = on. > > On 22/12/2016 14:32, Robert Wilton wrote: >> Hi Lada, >> >> Thanks for the review and comments. >> >> >> On 21/12/2016 13:08, Ladislav Lhotka wrote: >>> Hi, >>> >>> I think this is a very useful addition to ietf-interfaces. In general, >>> the document is clearly written and YANG modules nicely designed. Here >>> are my comments: >>> >>> *** Sec. 1 >>> - "This document defines two YANG RFC 7950 [RFC7950] modules =E2= =80=A6" >>> looks weird. I'd suggest "=E2=80=A6 YANG 1.1 [RFC7950] =E2=80=A6= " instead. >> OK. > Fixed. >>> *** Sec. 2 >>> - first line: s/of of/of/ > Fixed. > >>> *** Sec. 3.1 >>> - If the "bandwidth" parameter is only used for tuning routing >>> algorithms and has nothing to do with real bandwidth on the >>> interface, I would suggest to use a different name >>> (metric?). Perhaps it may indeed be better to leave this to >>> routing protocol modules because they can also specify how >>> exactly such a parameter is used. >> Yes, possibility it would be better to define this as part of the=20 >> routing models. The idea here is that the bandwidth would span across=20 >> the routing protocols rather than be tied to a specific protocol. > > I think that we need a better name than just "bandwidth" since this leaf= =20 > doesn't affect the actual bandwidth on the of the link, just the=20 > bandwidth that is reported to routing protocols to implicitly adjust=20 > their link metrics. Hence, I was considering renaming this to=20 > "reported-bandwidth"? This looks like something for routing people to decide. > > I also think that it would be good to follow up with the routing folks=20 > to see if this leaf would be better covered in a general routing model.= =20=20 > Where do you think is the best place that I raise this, the routing area= =20 > yang design team? Maybe, or RTGWG? > > >> >>> *** Sec. 3.6 >>> - The "l3-mtu" parameter is probably the same as "mtu" defined in >>> ietf-ip. Again, I would suggest to leave the definition of MTU >>> to each L3 protocol because there may be specific aspects and >>> constraints. >> The MTU being defined here is an "l2-mtu" parameter. I.e. the maximum=20 >> size of the L2 frames that can be sent/received. For some devices=20 >> this value is independent of a protocol specific L3 MTU that only=20 >> affects that particular protocol instance. > I've updated the text to make it clear that it is only a L2 MTU=20 > configuration leaf, and if not configured, the system will automatically= =20 > decide on the L2 MTU. Shouldn't it have a "when" substatement to make it available only for "layer-2" interfaces? > >> >> >>> *** Sec. 3.8 >>> - I think that "transport-layer" is not a good name because in the >>> ISO OSI model it denotes a particular layer (L4). How about >>> "iso-osi-layer"? > I agree that "transport-layer" is somewhat ambiguous. > > I was wondering whether "service-layer" or "service-type" would work? This looks more like a business term, "iso-osi-layer" or just "osi-layer" seems better to me, even if you include only layers 1-3. Actually, the OSI model calls these three "media layers", but this term isn't commonly used. > > Or perhaps it could be called "forwarding-mode"? IMO, the layers are not only about forwarding. > >>> - The type of "transport-layer" has three enums, namely >>> "layer-[123]". I would suggest to use descriptive names >>> ("physical-layer" etc.), include the remaining layers of the ISO >>> OSI model, and maybe also define it as a typedef - or does this >>> belong to ietf-inet-types? > I'm not sure that defining the higher layers of the OSI model helps.=20=20 > Perhaps using identities would be a better choice? > > Perhaps: > "physical-layer" > "data-link-layer" > "network-layer" > > But I prefer "layer-2" over "data-link-layer" since I think that term > is much more widespread. I'm also not quite sure whether OK. > "physical-layer" is actually the right term, I think that is probably > really "below-layer-2" > In terms of the OSI model, there is only layer 1 (physical) below layer 2. Or do you mean things like Ethernet-over-MPLS? I don't know how the layer classification works in such convoluted cases. > >>> - Is a leaf sufficient? I think some interfaces can be in multiple >>> layers at the same time (e.g. an ATM interface is L3 but can >>> also be L2 for Classical IP over ATM). Or is the idea that such >>> an interface will be split into two entries of the "interface" >>> list? >> This needs some further thought/work. > I think that using sub-interfaces is the cleanest way of doing this, so=20 > each sub-interface can be offering a service at a different layer. > > >> >> The main idea here was to be able to label sub-interfaces as=20 >> supporting only L2 services or L3 services, since on some platforms=20 >> different types of interfaces get instantiated internally. OK, I don't dare to give any suggestions here. >> >>> *** YANG modules >>> - Descriptions are not consistently formatted. I think that the >>> current BCP is to start description text on the same line as the >>> "description" keyword only if it all fits on one line. >>> - I don't have a strong opinion on this but it might increase >>> readability if the number of augments is reduced. Perhaps at >>> least augments that contain only one node could be made into one >>> (and the "feature" and "when" statements moved to the nodes' >>> definitions. >> Yes, I'll fix these, probably using Martin's suggested approach. > I've fixed the descriptions, and merged all the augments except for the=20 > sub-interface one (which is an if-feature conditional augment of a=20 > mandatory node). Good. > > I also have a question about the "encapsulation" container that is=20 > currently defined as: > > /* > * Various types of interfaces support a configurable layer 2 > * encapsulation, any that are supported by YANG should be > * listed here. > * > * Different encapsulations can hook into the common encaps-type > * choice statement. > */ > container encapsulation { > when > "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or > derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or > derived-from-or-self(if:type, 'ianaift:pos') or > derived-from-or-self(if:type, 'ianaift:atmSubInterface') or > derived-from-or-self(if:type, 'ethSubInterface')" { > > description > "All interface types that can have a configurable L2 > encapsulation"; > /* > * TODO - Should we introduce an abstract type to make this > * extensible to new interface types, or vendor > * specific interface types? > */ > } > > description > "Holds the OSI layer 2 encapsulation associated with an > interface"; > choice encaps-type { > description "Extensible choice of L2 encapsulations"; > } > } > > I was considering removing the when statement to generalize this, since=20 > the case statements can be constricted to suitable interface types using= =20 > when statements anyway. E.g. I'm proposing to changing it to something=20 > like this: > > /* > * Various types of interfaces support a configurable > * encapsulation. > * > * Different encapsulations (often layer 2) can hook into the > * common encaps-type choice statement. > */ > container encapsulation { > description > "Holds the encapsulation (often layer 2) associated with an > interface"; > choice encaps-type { > description > "Extensible choice of encapsulations"; > } > } > > Do you have a view on this? This demonstrates that the IANA interface types are not very useful for restricting the data model. As you indicate, multiple levels of the interface hierarchy (abstract interface types) might be better, perhaps you could also make use of multiple inheritance of identities, hence allowing for arbitrary mixes of interface properties encoded in the type.=20 Cheers, Lada > > Thanks, > Rob > > >> >> Thanks again, >> Rob >> >>> >>> Lada >>> >> > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 10 06:17:58 2017 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 C2C8C1295B0 for ; Fri, 10 Mar 2017 06:17:56 -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 QNiNyb1-W6qf for ; Fri, 10 Mar 2017 06:17:55 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4667B1295AC for ; Fri, 10 Mar 2017 06:17:55 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 6D91E1820044; Fri, 10 Mar 2017 15:18:16 +0100 (CET) From: Ladislav Lhotka To: Lyle Bertz In-Reply-To: References: Date: Fri, 10 Mar 2017 15:17:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] New I-D Submission: draft-bertz-netmod-commonaugment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 14:17:56 -0000 Lyle Bertz writes: > Understood. > > Let's discuss at the meeting though. This was a significant issue in the > development of the IETF DMM FPC yang files and our open source project. I > am open to this going in the proper direction wherever that is but wanted > to bring the issue and a possible solution to the table. Yes, that's fine. One way to alleviate this problem is to define a grouping and then have multiple augments that use this grouping. We used this approach in RFC 8022. Would this work for your use cases? Lada > > Lyle > > > On Tue, Mar 7, 2017 at 2:43 AM, Ladislav Lhotka wrote: > >> Hi, >> >> while the use case is clear, I believe such rather fundamental changes >> to YANG cannot be done through extensions because otherwise the value of >> YANG as a standard will be lost. >> >> Lada >> >> Lyle Bertz writes: >> >> > All, >> > >> > This is a small submission that allows a single augment statement to be >> > used to augment multiple schema locations or, at the very least, give the >> > YANG to language generation tools a hint that the augment is similar to >> > other augments in the module. >> > >> > It can be found at >> > https://datatracker.ietf.org/doc/draft-bertz-netmod-commonaugment/ >> > >> > It is in direct response to issues that arose writing YANG for the IETF >> DMM >> > FPC specification that can be found at >> > https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ >> > >> > and also in response to issues found wrt yangtools (OpenDaylight) code >> > generation of the FPC specification. >> > >> > Lyle >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 10 06:46:59 2017 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 AC8A312960C for ; Fri, 10 Mar 2017 06:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 LqmuAzfyVv3Y for ; Fri, 10 Mar 2017 06:46:56 -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 A6AF9129484 for ; Fri, 10 Mar 2017 06:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11098; q=dns/txt; s=iport; t=1489157215; x=1490366815; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=p0qVGLYXYXe1adg1OjbgUiI+iheciLV8kupgGtGfkfA=; b=C8s5cgkEFdfzNRCUZ8iiNpdNo3uQSP1L7LpURFpEN6J9w3RAB+CZUT5K k1m8EUM6sdnAy7sSCIi49ayF0ce0zjdzkBDrF+kLL/Ycaxq17ju1wRrWQ CqX8CsBF8JLS0wO+AAvGTjLtv7bv+zb8bgL/aLncc4Wf3GEEG+tAlPdDm Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmBABGu8JY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhFxgg2CKDnOQPh+QBoUygg6CbIM2AoJ7GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEjDwEFLyILGAICJgICVwYBDAYCAQGJdAixRYImimoBAQEBAQUBAQEBA?= =?us-ascii?q?QEBIYELhUOCBQiBWYEJhCYRAYMigl8Fj1iMYog8iXyBe4UlgzGGUYhEgm+DbIQ?= =?us-ascii?q?hHzh7CCIWCBcVP4ZVQDWHbIIuAQEB?= X-IronPort-AV: E=Sophos;i="5.36,141,1486425600"; d="scan'208";a="650330078" 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; 10 Mar 2017 14:46:53 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2AEkqRn018124; Fri, 10 Mar 2017 14:46:52 GMT To: Ladislav Lhotka , netmod@ietf.org References: <33d0132e-750b-97ed-8bdb-0befeb1b81c3@cisco.com> <0400d1cb-30ce-e074-b707-202026161ebb@cisco.com> From: Robert Wilton Message-ID: <12f97503-9801-56f5-650f-8accdab68e4c@cisco.com> Date: Fri, 10 Mar 2017 14:46:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 14:46:57 -0000 Lada, Thanks for the comments, some further comments inline ... On 10/03/2017 14:09, Ladislav Lhotka wrote: > Hi Rob, > > please see inline. > > Robert Wilton writes: > >> Hi Lada, >> >> To pick up an old thread, I'm updating the interface model per your >> comments below, and I had a few questions that you might have an opinion on. >> >> On 22/12/2016 14:32, Robert Wilton wrote: >>> Hi Lada, >>> >>> Thanks for the review and comments. >>> >>> >>> On 21/12/2016 13:08, Ladislav Lhotka wrote: >>>> Hi, >>>> >>>> I think this is a very useful addition to ietf-interfaces. In general, >>>> the document is clearly written and YANG modules nicely designed. Here >>>> are my comments: >>>> >>>> *** Sec. 1 >>>> - "This document defines two YANG RFC 7950 [RFC7950] modules …" >>>> looks weird. I'd suggest "… YANG 1.1 [RFC7950] …" instead. >>> OK. >> Fixed. >>>> *** Sec. 2 >>>> - first line: s/of of/of/ >> Fixed. >> >>>> *** Sec. 3.1 >>>> - If the "bandwidth" parameter is only used for tuning routing >>>> algorithms and has nothing to do with real bandwidth on the >>>> interface, I would suggest to use a different name >>>> (metric?). Perhaps it may indeed be better to leave this to >>>> routing protocol modules because they can also specify how >>>> exactly such a parameter is used. >>> Yes, possibility it would be better to define this as part of the >>> routing models. The idea here is that the bandwidth would span across >>> the routing protocols rather than be tied to a specific protocol. >> I think that we need a better name than just "bandwidth" since this leaf >> doesn't affect the actual bandwidth on the of the link, just the >> bandwidth that is reported to routing protocols to implicitly adjust >> their link metrics. Hence, I was considering renaming this to >> "reported-bandwidth"? > This looks like something for routing people to decide. > >> I also think that it would be good to follow up with the routing folks >> to see if this leaf would be better covered in a general routing model. >> Where do you think is the best place that I raise this, the routing area >> yang design team? > Maybe, or RTGWG? OK. I'll send an email that way, after I've published this next revision. > >> >>>> *** Sec. 3.6 >>>> - The "l3-mtu" parameter is probably the same as "mtu" defined in >>>> ietf-ip. Again, I would suggest to leave the definition of MTU >>>> to each L3 protocol because there may be specific aspects and >>>> constraints. >>> The MTU being defined here is an "l2-mtu" parameter. I.e. the maximum >>> size of the L2 frames that can be sent/received. For some devices >>> this value is independent of a protocol specific L3 MTU that only >>> affects that particular protocol instance. >> I've updated the text to make it clear that it is only a L2 MTU >> configuration leaf, and if not configured, the system will automatically >> decide on the L2 MTU. > Shouldn't it have a "when" substatement to make it available only for > "layer-2" interfaces? It can apply to all interfaces that use a layer 2 encapsulation, i.e. most interfaces. The only interfaces that it wouldn't apply to are: - interfaces that are performing optical switching - but then I think that they are probably not really interfaces at all. - software interfaces that represent a tunnel endpoint that carriers L3 frames with no L2 encapsulation. Although in this case you could just regard them as having a 0 byte layer 2 overhead. > >>> >>>> *** Sec. 3.8 >>>> - I think that "transport-layer" is not a good name because in the >>>> ISO OSI model it denotes a particular layer (L4). How about >>>> "iso-osi-layer"? >> I agree that "transport-layer" is somewhat ambiguous. >> >> I was wondering whether "service-layer" or "service-type" would work? > This looks more like a business term, "iso-osi-layer" or just > "osi-layer" seems better to me, even if you include only layers > 1-3. Actually, the OSI model calls these three "media layers", but this > term isn't commonly used. The problem with osi-layer is that I don't think that the name really indicates what it means. > >> Or perhaps it could be called "forwarding-mode"? > IMO, the layers are not only about forwarding. Agreed, but this configuration is to provide a constraint as to what services and forwarding paradigm can be enabled. E.g. an "l2 transport/service" would be connected to an L2VPN instance but not IP. An ACL applied to a "L2 transport/service" would filter on MAC addresses/VLAN Ids rather than IP header fields. > >>>> - The type of "transport-layer" has three enums, namely >>>> "layer-[123]". I would suggest to use descriptive names >>>> ("physical-layer" etc.), include the remaining layers of the ISO >>>> OSI model, and maybe also define it as a typedef - or does this >>>> belong to ietf-inet-types? >> I'm not sure that defining the higher layers of the OSI model helps. >> Perhaps using identities would be a better choice? >> >> Perhaps: >> "physical-layer" >> "data-link-layer" >> "network-layer" >> >> But I prefer "layer-2" over "data-link-layer" since I think that term >> is much more widespread. I'm also not quite sure whether > OK. > >> "physical-layer" is actually the right term, I think that is probably >> really "below-layer-2" >> > In terms of the OSI model, there is only layer 1 (physical) below layer > 2. Or do you mean things like Ethernet-over-MPLS? I don't know how the > layer classification works in such convoluted cases. For layer-2, I think of carrying L2 frames over another service (e.g. IP, MPLS, or MAC-in-MAC). For layer-1, I was thinking of things like optical switching or OTN switching. But again it does come back to whether those are represented as interfaces. Although, even in the optical switching cases, I think that devices sometimes snoop the layer 2 frame statistics. > >>>> - Is a leaf sufficient? I think some interfaces can be in multiple >>>> layers at the same time (e.g. an ATM interface is L3 but can >>>> also be L2 for Classical IP over ATM). Or is the idea that such >>>> an interface will be split into two entries of the "interface" >>>> list? >>> This needs some further thought/work. >> I think that using sub-interfaces is the cleanest way of doing this, so >> each sub-interface can be offering a service at a different layer. >> >> >>> The main idea here was to be able to label sub-interfaces as >>> supporting only L2 services or L3 services, since on some platforms >>> different types of interfaces get instantiated internally. > OK, I don't dare to give any suggestions here. > >>>> *** YANG modules >>>> - Descriptions are not consistently formatted. I think that the >>>> current BCP is to start description text on the same line as the >>>> "description" keyword only if it all fits on one line. >>>> - I don't have a strong opinion on this but it might increase >>>> readability if the number of augments is reduced. Perhaps at >>>> least augments that contain only one node could be made into one >>>> (and the "feature" and "when" statements moved to the nodes' >>>> definitions. >>> Yes, I'll fix these, probably using Martin's suggested approach. >> I've fixed the descriptions, and merged all the augments except for the >> sub-interface one (which is an if-feature conditional augment of a >> mandatory node). > Good. > >> I also have a question about the "encapsulation" container that is >> currently defined as: >> >> /* >> * Various types of interfaces support a configurable layer 2 >> * encapsulation, any that are supported by YANG should be >> * listed here. >> * >> * Different encapsulations can hook into the common encaps-type >> * choice statement. >> */ >> container encapsulation { >> when >> "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or >> derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or >> derived-from-or-self(if:type, 'ianaift:pos') or >> derived-from-or-self(if:type, 'ianaift:atmSubInterface') or >> derived-from-or-self(if:type, 'ethSubInterface')" { >> >> description >> "All interface types that can have a configurable L2 >> encapsulation"; >> /* >> * TODO - Should we introduce an abstract type to make this >> * extensible to new interface types, or vendor >> * specific interface types? >> */ >> } >> >> description >> "Holds the OSI layer 2 encapsulation associated with an >> interface"; >> choice encaps-type { >> description "Extensible choice of L2 encapsulations"; >> } >> } >> >> I was considering removing the when statement to generalize this, since >> the case statements can be constricted to suitable interface types using >> when statements anyway. E.g. I'm proposing to changing it to something >> like this: >> >> /* >> * Various types of interfaces support a configurable >> * encapsulation. >> * >> * Different encapsulations (often layer 2) can hook into the >> * common encaps-type choice statement. >> */ >> container encapsulation { >> description >> "Holds the encapsulation (often layer 2) associated with an >> interface"; >> choice encaps-type { >> description >> "Extensible choice of encapsulations"; >> } >> } >> >> Do you have a view on this? > This demonstrates that the IANA interface types are not very useful for > restricting the data model. As you indicate, multiple levels of the > interface hierarchy (abstract interface types) might be better, perhaps > you could also make use of multiple inheritance of identities, hence > allowing for arbitrary mixes of interface properties encoded in the type. Yes, I think that the IANA interface types are a problem. Previously I was planning on writing up a draft with abstract types deriving from the IANA types, but I'm not sure whether this helps in the general case. It might be that we need to define a set of abstract types (e.g. physical interfaces, ethernet-like, sub-interface, logical interface, etc) and then update the type identities in iana-if-type.yang to derive from those base types (which I believe would be an allowed backwards compatible change). Thanks, Rob > > Cheers, Lada > >> Thanks, >> Rob >> >> >>> Thanks again, >>> Rob >>> >>>> Lada >>>> From nobody Fri Mar 10 09:08:52 2017 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 D10981296A5 for ; Fri, 10 Mar 2017 09:08:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fa-73FnHrmqy for ; Fri, 10 Mar 2017 09:08:48 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 A07601295FD for ; Fri, 10 Mar 2017 09:08:47 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id t189so53408wmt.1 for ; Fri, 10 Mar 2017 09:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q1CohUj5h9GWyvYQEDX5bjUa4pd28jsSzOEqAxcVN2o=; b=Na9eT3pD6yQUt/xLVp+qlPSeSx3q+RU0KgsWbeJy7gvXsB/s8Mf33J4dZYb4+lneG7 69ooc4g1aGe3d9aE623uDKtU9u62sBFm2pNGZrzw8W7ZugEN4FXSLa8CHqtYs9Utk/Xu btSzCP7eI7jrcoX9K/xQ0MgHzV2lKXYhEVhm4EBmy7a/5bvXBuS6ScgrJaJC3alcLVRM tFw7555N9AiqME/KtQpM834xyzDOU8/D2p6yRxLOUidGoEE3FsPfKOD1Ct8QavHP0BM2 h+2gHafsF3wKy7qX0xfnHIrUI3wgN1pLHSG4k8u1VL1YTN9fuqxtGVylJ2MV3Jl0XqFx dLZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q1CohUj5h9GWyvYQEDX5bjUa4pd28jsSzOEqAxcVN2o=; b=ld64ZwNQUQy+50Nwd1qAyxfw7hK0k4ZlmpE4HNXWdBH+QGzQx3kGxJTsr2UGYJ/BF/ vc7sLKF8ZP+gdUJu+E7SjN7aY3afzwiVePgfcm7WwaRh9fFQzVcUGc5t8XSMxvaXvEER rAz3MRRypuLqbH2DbTIU5ZPBiXpAkqLDTdfuyw5ftqwNsQWTjg2tSAjMe0wPyRZ12AVy +pATjWKotHTVIpvcaS/4SayffFJKC07HbIxd4EL68PbQvcM1ZnHHqACsdKBGMyY5/mua erMVwpsH+5qGjl4Nv+1REKGu1cjqgPftrHUpB1fbX33+bX3a2cHl/1Fw+DL22wDbqDJH R9WA== X-Gm-Message-State: AFeK/H2iyQ5npuhDLf2L3yBv9RuvL5rIhJMmmgCRN5vffw3+X2Nc8t89ZnV9NY/yLzKHQedkNbynA4jkCkrBWQ== X-Received: by 10.28.46.213 with SMTP id u204mr4386wmu.136.1489165726208; Fri, 10 Mar 2017 09:08:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Fri, 10 Mar 2017 09:08:45 -0800 (PST) In-Reply-To: References: From: Andy Bierman Date: Fri, 10 Mar 2017 09:08:45 -0800 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11497ace1f891b054a636a8f Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] New I-D Submission: draft-bertz-netmod-commonaugment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:08:50 -0000 --001a11497ace1f891b054a636a8f Content-Type: text/plain; charset=UTF-8 On Fri, Mar 10, 2017 at 6:17 AM, Ladislav Lhotka wrote: > Lyle Bertz writes: > > > Understood. > > > > Let's discuss at the meeting though. This was a significant issue in the > > development of the IETF DMM FPC yang files and our open source project. > I > > am open to this going in the proper direction wherever that is but wanted > > to bring the issue and a possible solution to the table. > > Yes, that's fine. One way to alleviate this problem is to define a > grouping and then have multiple augments that use this grouping. We used > this approach in RFC 8022. Would this work for your use cases? > > I agree with Martin that this YANG extension replaces augment-stmt and therefore will break tools that conform to RFC 7950. The extension saves 1 line of YANG for each "extra augment" so the benefit for readers and writers seems minimal. > Lada > Andy > > > > > Lyle > > > > > > On Tue, Mar 7, 2017 at 2:43 AM, Ladislav Lhotka wrote: > > > >> Hi, > >> > >> while the use case is clear, I believe such rather fundamental changes > >> to YANG cannot be done through extensions because otherwise the value of > >> YANG as a standard will be lost. > >> > >> Lada > >> > >> Lyle Bertz writes: > >> > >> > All, > >> > > >> > This is a small submission that allows a single augment statement to > be > >> > used to augment multiple schema locations or, at the very least, give > the > >> > YANG to language generation tools a hint that the augment is similar > to > >> > other augments in the module. > >> > > >> > It can be found at > >> > https://datatracker.ietf.org/doc/draft-bertz-netmod-commonaugment/ > >> > > >> > It is in direct response to issues that arose writing YANG for the > IETF > >> DMM > >> > FPC specification that can be found at > >> > https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ > >> > > >> > and also in response to issues found wrt yangtools (OpenDaylight) code > >> > generation of the FPC specification. > >> > > >> > Lyle > >> > _______________________________________________ > >> > netmod mailing list > >> > netmod@ietf.org > >> > https://www.ietf.org/mailman/listinfo/netmod > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: 0xB8F92B08A9F76C67 > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11497ace1f891b054a636a8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 10, 2017 at 6:17 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Lyle Bertz <lyleb551144@gmail.com> writes:

> Understood.
>
> Let's discuss at the meeting though.=C2=A0 This was a significant = issue in the
> development of the IETF DMM FPC yang files and our open source project= .=C2=A0 =C2=A0I
> am open to this going in the proper direction wherever that is but wan= ted
> to bring the issue and a possible solution to the table.

Yes, that's fine. One way to alleviate this problem is to define a
grouping and then have multiple augments that use this grouping. We used this approach in RFC 8022. Would this work for your use cases?


I agree with Martin that this YANG ext= ension replaces augment-stmt and therefore will
break tools that = conform to RFC 7950.=C2=A0 The extension saves 1 line of YANG for each
"extra augment" so the benefit for readers and writers seem= s minimal.

=C2=A0
Lada

Andy
=C2=A0

>
> Lyle
>
>
> On Tue, Mar 7, 2017 at 2:43 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Hi,
>>
>> while the use case is clear, I believe such rather fundamental cha= nges
>> to YANG cannot be done through extensions because otherwise the va= lue of
>> YANG as a standard will be lost.
>>
>> Lada
>>
>> Lyle Bertz <lyleb55114= 4@gmail.com> writes:
>>
>> > All,
>> >
>> > This is a small submission that allows a single augment state= ment to be
>> > used to augment multiple schema locations or, at the very lea= st, give the
>> > YANG to language generation tools a hint that the augment is = similar to
>> > other augments in the module.
>> >
>> > It can be found at
>> > https://datatracker.= ietf.org/doc/draft-bertz-netmod-commonaugment/
>> >
>> > It is in direct response to issues that arose writing YANG fo= r the IETF
>> DMM
>> > FPC specification that can be found at
>> > https://datatracker.ietf.org/= doc/draft-ietf-dmm-fpc-cpdp/
>> >
>> > and also in response to issues found wrt yangtools (OpenDayli= ght) code
>> > generation of the FPC specification.
>> >
>> > Lyle
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinf= o/netmod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>

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

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

--001a11497ace1f891b054a636a8f-- From nobody Fri Mar 10 09:41:21 2017 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 0715312706D for ; Fri, 10 Mar 2017 09:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 S3frFe1Uavr2 for ; Fri, 10 Mar 2017 09:41:15 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3DA127077 for ; Fri, 10 Mar 2017 09:41:14 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id n11so652942wma.1 for ; Fri, 10 Mar 2017 09:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5werkdan7lNzTWRRBeDH89QFXGxb4hwCHDtQ8Gko90w=; b=PFEL2Ea0rF7TTVYlyU9dnPIBnSjYEHcKvIN9APmiRkjHdBacrC4012NM/Um3BHN6y4 Qz1xEbxeu5ekVZ2BKL1o3KwZ81lrqmAIwYS3TUENqTkt+sgote+JDoTiXVusuUZOokQn dFzfoJXgBYZEQbZ7NlX8kSs0UINqCC4qSdzlPLL3PQFz+n69V4QPNOsf/K8a5YSG1OG2 3dCjmHWTSuHoqBXwXlOiFLb8e/FarToiBEtHz0FcstE9LOc6NAux4aM+HBJ7xR9TDFXE MLQuTUqirsAeSjvpQSPoDO1L9PE0cat/ixnn6gP0JMaeFF1bYjxHljx4mwW2SGTzVChu fl7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5werkdan7lNzTWRRBeDH89QFXGxb4hwCHDtQ8Gko90w=; b=J1nOwEyc8c+gGBaPsIWgM7kA53DtOkm6RDAwpt+CkWaQ1UbaAgGTRqAhr+B5pXERgT 7hLs8Kq83eFVX9keUh5v1SmGkva2JQ6lBKa28MwEaR4A9puVnVGhCFk+69j9UGYGv4Mu 8MzxBuG7gdAD84THsVM5jJaTNz2ni01jyUAp5SeZ50BckZnem6r5VWC2SxnPTw48sN1G ypzYwqg6n5UF4FhOmmI6ZGiJu9dEbsw1akLVC2DFdFpLjao5XsE61GR5vshc/4IEPmuR /RJmpiAUOtKEqsRWf2iKS04zPzQugFndRb985X0znrJcHVndwduZ5u6CzsKHcSflwoOF 6AzQ== X-Gm-Message-State: AFeK/H2h+Bg/PQnslPdjWyM2y9egAWbN4xGYI31nzPwSSYm1IIB7QBA+0TyaHPy1COUw8F3vz/Ibdg9mKpT0Jg== X-Received: by 10.28.191.24 with SMTP id p24mr132300wmf.118.1489167673049; Fri, 10 Mar 2017 09:41:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.86 with HTTP; Fri, 10 Mar 2017 09:41:12 -0800 (PST) In-Reply-To: References: From: Lyle Bertz Date: Fri, 10 Mar 2017 11:41:12 -0600 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a114d53ae29c903054a63dec0 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] New I-D Submission: draft-bertz-netmod-commonaugment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:41:17 -0000 --001a114d53ae29c903054a63dec0 Content-Type: text/plain; charset=UTF-8 We did that. Unfortunately, underlying YANG to object oriented code generators treated the wrapping class as only inheriting the interface. This seems fine until you attempt to translate from one of these classes to another and the real work is much larger than expected. Part of this is the schema context carried in one object to another - copying is not just copying as we began to discover. The proposal's end result is the same as you propose - a grouping with multiple augments and this is sufficient from a standards level as it achieves the correct structures. However, it appears to as separate, independent modifications to the schema tree. Thus, the intent of the author (for it to be the same augment / addition in multiple locations) is lost. We then thought, "okay, modify the compiler to just assume equivalence" which only works a) if that is true and b) if the signature is exactly the same. We could not guarantee a) and b) become problematic when computing "exactly the same"; especially across modules (which is another subject entirely). The final issue is one of space. If you only support the extension you have the intent of the author and a smaller amount of YANG. However, we keep the proposal backwards compatible assuming that we will not just dump old YANG files for slightly better ones. A final point, this should not be an issue in the main information tree as it implies you have an object "everywhere" which begs several questions regarding design. It is however a common problem when you have several rpcs that send data in the request and response. It was in the rpc definitions that we really took a hit when implementing the DMM FPC drafts. Lyle On Fri, Mar 10, 2017 at 8:17 AM, Ladislav Lhotka wrote: > Lyle Bertz writes: > > > Understood. > > > > Let's discuss at the meeting though. This was a significant issue in the > > development of the IETF DMM FPC yang files and our open source project. > I > > am open to this going in the proper direction wherever that is but wanted > > to bring the issue and a possible solution to the table. > > Yes, that's fine. One way to alleviate this problem is to define a > grouping and then have multiple augments that use this grouping. We used > this approach in RFC 8022. Would this work for your use cases? > > Lada > > > > > Lyle > > > > > > On Tue, Mar 7, 2017 at 2:43 AM, Ladislav Lhotka wrote: > > > >> Hi, > >> > >> while the use case is clear, I believe such rather fundamental changes > >> to YANG cannot be done through extensions because otherwise the value of > >> YANG as a standard will be lost. > >> > >> Lada > >> > >> Lyle Bertz writes: > >> > >> > All, > >> > > >> > This is a small submission that allows a single augment statement to > be > >> > used to augment multiple schema locations or, at the very least, give > the > >> > YANG to language generation tools a hint that the augment is similar > to > >> > other augments in the module. > >> > > >> > It can be found at > >> > https://datatracker.ietf.org/doc/draft-bertz-netmod-commonaugment/ > >> > > >> > It is in direct response to issues that arose writing YANG for the > IETF > >> DMM > >> > FPC specification that can be found at > >> > https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ > >> > > >> > and also in response to issues found wrt yangtools (OpenDaylight) code > >> > generation of the FPC specification. > >> > > >> > Lyle > >> > _______________________________________________ > >> > netmod mailing list > >> > netmod@ietf.org > >> > https://www.ietf.org/mailman/listinfo/netmod > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: 0xB8F92B08A9F76C67 > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > --001a114d53ae29c903054a63dec0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We did that.=C2=A0 Unfortunately, unde= rlying YANG to object oriented code generators treated the wrapping class a= s only inheriting the interface.=C2=A0 This seems fine until you attempt to= translate from one of these classes to another and the real work is much l= arger than expected.=C2=A0 Part of this is the schema context carried in on= e object to another - copying is not just copying as we began to discover.= =C2=A0=C2=A0

The proposal's end result is the same as you= propose - a grouping with multiple augments and this is sufficient from a = standards level as it achieves the correct structures.=C2=A0 However, it ap= pears to as separate, independent modifications to the schema tree.=C2=A0= =C2=A0 Thus, the intent of the author (for it to be the same augment / addi= tion in multiple locations) is lost.=C2=A0

We then thought, &= quot;okay, modify the compiler to just assume equivalence" which only = works a) if that is true and b) if the signature is exactly the same.=C2=A0= We could not guarantee a) and b) become problematic when computing "e= xactly the same"; especially across modules (which is another subject = entirely).

The final issue is one of space.=C2=A0 If you only = support the extension you have the intent of the author and a smaller amoun= t of YANG.=C2=A0 However, we keep the proposal backwards compatible assumin= g that we will not just dump old YANG files for slightly better ones.
A final point, this should not be an issue in the main information = tree as it implies you have an object "everywhere" which begs sev= eral questions regarding design.=C2=A0 It is however a common problem when = you have several rpcs that send data in the request and response.=C2=A0 It = was in the rpc definitions that we really took a hit when implementing the = DMM FPC drafts.

Lyle


On Fri, Mar 10, 2017 at 8:17 AM, Ladis= lav Lhotka <lhotka@nic.cz> wrote:
Lyle Bertz <lyleb551144@gmail.com> writes:

> Understood.
>
> Let's discuss at the meeting though.=C2=A0 This was a significant = issue in the
> development of the IETF DMM FPC yang files and our open source project= .=C2=A0 =C2=A0I
> am open to this going in the proper direction wherever that is but wan= ted
> to bring the issue and a possible solution to the table.

Yes, that's fine. One way to alleviate this problem is to define= a
grouping and then have multiple augments that use this grouping. We used this approach in RFC 8022. Would this work for your use cases?

Lada

>
> Lyle
>
>
> On Tue, Mar 7, 2017 at 2:43 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Hi,
>>
>> while the use case is clear, I believe such rather fundamental cha= nges
>> to YANG cannot be done through extensions because otherwise the va= lue of
>> YANG as a standard will be lost.
>>
>> Lada
>>
>> Lyle Bertz <lyleb55114= 4@gmail.com> writes:
>>
>> > All,
>> >
>> > This is a small submission that allows a single augment state= ment to be
>> > used to augment multiple schema locations or, at the very lea= st, give the
>> > YANG to language generation tools a hint that the augment is = similar to
>> > other augments in the module.
>> >
>> > It can be found at
>> > https://datatracker.= ietf.org/doc/draft-bertz-netmod-commonaugment/
>> >
>> > It is in direct response to issues that arose writing YANG fo= r the IETF
>> DMM
>> > FPC specification that can be found at
>> > https://datatracker.ietf.org/= doc/draft-ietf-dmm-fpc-cpdp/
>> >
>> > and also in response to issues found wrt yangtools (OpenDayli= ght) code
>> > generation of the FPC specification.
>> >
>> > Lyle
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinf= o/netmod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>

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

--001a114d53ae29c903054a63dec0-- From nobody Sat Mar 11 13:25:47 2017 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 AC1A31295D7 for ; Sat, 11 Mar 2017 13:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 9e6aC6CBYoNl for ; Sat, 11 Mar 2017 13:25:44 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2CD1295D4 for ; Sat, 11 Mar 2017 13:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1385; q=dns/txt; s=iport; t=1489267544; x=1490477144; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dk/oTRFF/C6tRxt1nUCMt8rSBPbZWt5vaD6amAD4zUw=; b=IHn+Prjx46cQpTkTMUjPUoXMLy3mbkBsZyrYeJ05GxIXQKlQIXdoL9iY HJeHBjtINbnqDhsrJwHOILYoyatc/zodISzHthlBf9UiN3MWz8UXBN+sl X68JrdN8F3lB72RAAX0MHeSSjabGL0K11eusQbKStQquusWowaqW9xJAf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQAOa8RY/5JdJa1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNRYYEKB41nkU+VO4IOHwuFLkoCgkE/GAECAQEBAQEBAWsohRY?= =?us-ascii?q?BAQEDAQFsCw4CAgEIDgIILhsMCyUCBAENBYoADrQAilkBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdBYs4hFQhJoUeBZAcjCUBkjiRJZNCAR84gQRYFUGGV3WIbIENAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.36,148,1486425600"; d="scan'208";a="393735521" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2017 21:25:43 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v2BLPgAC003099 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 11 Mar 2017 21:25:43 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 11 Mar 2017 16:25:42 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Sat, 11 Mar 2017 16:25:42 -0500 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder , Kent Watsen Thread-Topic: [netmod] stable reference for tree diagram notation Thread-Index: AQHSlD0Kf+J5u9nqmEehA2iSQMJSUaGDqz2AgAZYb4CAAWJqgIAAGpCAgAAJ8wCAAAz2gIAADyEAgAAKrwCABII0AA== Date: Sat, 11 Mar 2017 21:25:41 +0000 Message-ID: References: <20170303170233.GB3345@elstar.local> <20170307.185637.67261051570590747.mbj@tail-f.com> <82703e36-26f9-d459-c36a-c274861c5386@labn.net> <84583EEA-C7FE-4BB0-8D16-744E3768AB5C@nic.cz> <20170308180211.GA9937@elstar.local> <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> <20170308193434.GA10080@elstar.local> In-Reply-To: <20170308193434.GA10080@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.92.9] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 21:25:45 -0000 Hi Juergen,=20 On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder" wrote: >On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrote: >>=20 >> This way, reader can focus more quickly on the diffs, but also this >> likely mimics what happened in reality (start with `pyang -f tree` >> and then manually edit from there). What do you think? >>=20 > >Manually edited tree diagrams? I hope not. I frequently have to manually edit the pyang-generated trees to get them to fit in the xml2rfc output. Is there a work around for this that I don=B9= t know about?=20 Thanks, Acee >Perhaps we should have text >saying that tree diagrams are expected to be generated by tools and >that they are expected to be consistent with the model (and hence they >need to be updated with every change, hence usage of tools is a damn >good idea). > >[I thought this is obvious but perhaps this is not.] > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Sat Mar 11 13:49:55 2017 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 308BB1295DB for ; Sat, 11 Mar 2017 13:49:53 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfW41Rtj8vz5 for ; Sat, 11 Mar 2017 13:49:52 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 15B6212896F for ; Sat, 11 Mar 2017 13:49:52 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 1DACC1AE030D; Sat, 11 Mar 2017 22:49:51 +0100 (CET) Date: Sat, 11 Mar 2017 22:49:51 +0100 (CET) Message-Id: <20170311.224951.2245774412799352894.mbj@tail-f.com> To: acee@cisco.com From: Martin Bjorklund In-Reply-To: References: <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> <20170308193434.GA10080@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 21:49:53 -0000 "Acee Lindem (acee)" wrote: > Hi Juergen, = > = > On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder" > j.schoenwaelder@jacobs-university.de> wrote: > = > >On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrote: > >> = > >> This way, reader can focus more quickly on the diffs, but also thi= s > >> likely mimics what happened in reality (start with `pyang -f tree`= > >> and then manually edit from there). What do you think? > >> = > > > >Manually edited tree diagrams? I hope not. > = > I frequently have to manually edit the pyang-generated trees to get t= hem > to fit in the xml2rfc output. Is there a work around for this that I = don=B9t > know about? = In the latest pyang, I have added --tree-line-length. Use: pyang -f -tree --tree-line-length 69 ... to fit RFCs. /martin From nobody Sat Mar 11 14:32:31 2017 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 18A761294AA for ; Sat, 11 Mar 2017 14:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 ulxnK3bHpKVH for ; Sat, 11 Mar 2017 14:32:28 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A043A129413 for ; Sat, 11 Mar 2017 14:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1388; q=dns/txt; s=iport; t=1489271548; x=1490481148; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AZlwWDifOPc1AoIPGIOuBZW7050kXq/KB5e+Jqe+ifo=; b=lPsIA91J6rUTly9yBPFRts5j0yuU1cKzwgvJc3BCdqhsuWhJsCjrnoDo FCKASlhuDpLCY6OjXXZGUWg0diDCr6zYyIg6l3OG0vXcxhn+udWxYICJH RgbhlUKQIt3gywcuNXF9ai9OEVsb0ibanKEqvr6etv79SrTPxcAi9J/g1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AQB+esRY/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBaweDWYoOkU+VO4IOhiICGoInPxgBAgEBAQEBAQFrKIUWAQU?= =?us-ascii?q?0RRACAQgOAggEKAICMCUCBA4FigCUEZ1TBoIoilgBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBH4EFijiEVIMAgmUBBJxBAZI4kSWTQgEfOIEEWBWHGHWIbIENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,148,1486425600"; d="scan'208";a="393813888" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2017 22:30:30 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v2BMU0Rl018722 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 11 Mar 2017 22:30:01 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 11 Mar 2017 17:30:00 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Sat, 11 Mar 2017 17:30:00 -0500 From: "Acee Lindem (acee)" To: Martin Bjorklund Thread-Topic: [netmod] stable reference for tree diagram notation Thread-Index: AQHSlD0Kf+J5u9nqmEehA2iSQMJSUaGDqz2AgAZYb4CAAWJqgIAAGpCAgAAJ8wCAAAz2gIAADyEAgAAKrwCABII0AIAAWpaA//+3XoA= Date: Sat, 11 Mar 2017 22:29:59 +0000 Message-ID: References: <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> <20170308193434.GA10080@elstar.local> <20170311.224951.2245774412799352894.mbj@tail-f.com> In-Reply-To: <20170311.224951.2245774412799352894.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.72.151] Content-Type: text/plain; charset="euc-kr" Content-ID: <16DB9E1EEB27204DBF06D08C8A892A4F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 22:32:30 -0000 RXhjZWxsZW50ISEgDQoNClRoYW5rcywNCkFjZWUNCg0KT24gMy8xMS8xNywgNDo0OSBQTSwgIk1h cnRpbiBCam9ya2x1bmQiIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQoNCj4iQWNlZSBMaW5kZW0g KGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gSGkgSnVlcmdlbiwgDQo+PiANCj4+ IE9uIDMvOC8xNywgMjozNCBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgSnVlcmdlbiBTY2hvZW53 YWVsZGVyIg0KPj4gPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZg0KPj4gai5z Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4+IA0KPj4gPk9uIFdl ZCwgTWFyIDA4LCAyMDE3IGF0IDA2OjU2OjIwUE0gKzAwMDAsIEtlbnQgV2F0c2VuIHdyb3RlOg0K Pj4gPj4gDQo+PiA+PiBUaGlzIHdheSwgcmVhZGVyIGNhbiBmb2N1cyBtb3JlIHF1aWNrbHkgb24g dGhlIGRpZmZzLCBidXQgYWxzbyB0aGlzDQo+PiA+PiBsaWtlbHkgbWltaWNzIHdoYXQgaGFwcGVu ZWQgaW4gcmVhbGl0eSAoc3RhcnQgd2l0aCBgcHlhbmcgLWYgdHJlZWANCj4+ID4+IGFuZCB0aGVu IG1hbnVhbGx5IGVkaXQgZnJvbSB0aGVyZSkuICBXaGF0IGRvIHlvdSB0aGluaz8NCj4+ID4+IA0K Pj4gPg0KPj4gPk1hbnVhbGx5IGVkaXRlZCB0cmVlIGRpYWdyYW1zPyBJIGhvcGUgbm90Lg0KPj4g DQo+PiBJIGZyZXF1ZW50bHkgaGF2ZSB0byBtYW51YWxseSBlZGl0IHRoZSBweWFuZy1nZW5lcmF0 ZWQgdHJlZXMgdG8gZ2V0IHRoZW0NCj4+IHRvIGZpdCBpbiB0aGUgeG1sMnJmYyBvdXRwdXQuIElz IHRoZXJlIGEgd29yayBhcm91bmQgZm9yIHRoaXMgdGhhdCBJDQo+PmRvbqn2dA0KPj4ga25vdyBh Ym91dD8gDQo+DQo+SW4gdGhlIGxhdGVzdCBweWFuZywgSSBoYXZlIGFkZGVkIC0tdHJlZS1saW5l LWxlbmd0aC4gIFVzZToNCj4NCj4gIHB5YW5nIC1mIC10cmVlIC0tdHJlZS1saW5lLWxlbmd0aCA2 OSAuLi4NCj4NCj50byBmaXQgUkZDcy4NCj4NCj4NCj4vbWFydGluDQoNCg== From nobody Mon Mar 13 00:43:55 2017 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 B22BA129548; Mon, 13 Mar 2017 00:43:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148939103369.17026.5784133761974804877@ietfa.amsl.com> Date: Mon, 13 Mar 2017 00:43:53 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 07:43:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : A YANG Data Model for Hardware Management Authors : Andy Bierman Martin Bjorklund Jie Dong Dan Romascanu Filename : draft-ietf-netmod-entity-03.txt Pages : 40 Date : 2017-03-13 Abstract: This document defines a YANG data model for the management of hardware on a single server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-entity-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 00:46:49 2017 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 ACC38129545 for ; Mon, 13 Mar 2017 00:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIztsYRzakG7 for ; Mon, 13 Mar 2017 00:46:47 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3B78D129502 for ; Mon, 13 Mar 2017 00:46:47 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 3FF1D1AE0332 for ; Mon, 13 Mar 2017 08:46:46 +0100 (CET) Date: Mon, 13 Mar 2017 08:46:51 +0100 (CET) Message-Id: <20170313.084651.1144668331995785992.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <148939103369.17026.5784133761974804877@ietfa.amsl.com> References: <148939103369.17026.5784133761974804877@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 07:46:48 -0000 Hi, This version addresses the comments from Bart and Juergen. I think that this document is now ready for WGLC. /martin internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language of the IETF. > > Title : A YANG Data Model for Hardware Management > Authors : Andy Bierman > Martin Bjorklund > Jie Dong > Dan Romascanu > Filename : draft-ietf-netmod-entity-03.txt > Pages : 40 > Date : 2017-03-13 > > Abstract: > This document defines a YANG data model for the management of > hardware on a single server. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-netmod-entity-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Mar 13 02:26:46 2017 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 B6B84129400 for ; Mon, 13 Mar 2017 02:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 I45Zr-fBXd1N for ; Mon, 13 Mar 2017 02:26:43 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06B6127076 for ; Mon, 13 Mar 2017 02:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1924; q=dns/txt; s=iport; t=1489397202; x=1490606802; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=xttIwLbAxPjA/aQWY+v1mt5j/bWTMP3ttGX4JgDvi2E=; b=b6TWHDcOLp6P93vI8HhyEPPzkIW2C86lXp7qnfYsidYxQ2Bbxyxkjyyo x0wTRhzSPWWbCT9ckPp6Rtt4Vi8l+ffOs+fWvInFBL4a5S2Xmc5FIS5ry z7QR6J5s0oTeE53KWXOIb/2CIemBKkmOU7X1hAk2RLtIu0BUhH+jxJ26A M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAQBSZMZY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqYI1uc5BdlTuCDh8LhS5KAoMIGAECAQEBAQEBAWsohRYBAQE?= =?us-ascii?q?DAQE2NhsLDgouJzAGAQwGAgEBiXwOsU2KVgEBAQEBAQEBAQEBAQEBAQEBAQEfh?= =?us-ascii?q?k6CBQiCYoMXgSeFewWcQYZ2i0OBe1SEUYMyhlOLNYgOHziBBCMWCBcVGCmGWD8?= =?us-ascii?q?1AYcXK4IQAQEB?= X-IronPort-AV: E=Sophos;i="5.36,158,1486425600"; d="scan'208";a="650388427" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2017 09:26:40 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2D9Qegb009987; Mon, 13 Mar 2017 09:26:40 GMT To: Martin Bjorklund , netmod@ietf.org References: <148939103369.17026.5784133761974804877@ietfa.amsl.com> <20170313.084651.1144668331995785992.mbj@tail-f.com> From: Benoit Claise Message-ID: <95eed2ce-5541-cf8c-146e-21a73e30cd00@cisco.com> Date: Mon, 13 Mar 2017 10:26:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170313.084651.1144668331995785992.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 09:26:45 -0000 Hi Martin, ietf-hardware@2017-03-07.yang fails yanglint validation. See http://www.claise.be/IETFYANGPageCompilation.html Regards, Benoit > Hi, > > This version addresses the comments from Bart and Juergen. > > I think that this document is now ready for WGLC. > > > /martin > > > internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the NETCONF Data Modeling Language of the IETF. >> >> Title : A YANG Data Model for Hardware Management >> Authors : Andy Bierman >> Martin Bjorklund >> Jie Dong >> Dan Romascanu >> Filename : draft-ietf-netmod-entity-03.txt >> Pages : 40 >> Date : 2017-03-13 >> >> Abstract: >> This document defines a YANG data model for the management of >> hardware on a single server. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-netmod-entity-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-03 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Mar 13 02:43:35 2017 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 1CEA312955D for ; Mon, 13 Mar 2017 02:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jPvV9VI6gF4 for ; Mon, 13 Mar 2017 02:43:32 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 79B7C129400 for ; Mon, 13 Mar 2017 02:43:32 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 3F40E1AE0332; Mon, 13 Mar 2017 10:43:31 +0100 (CET) Date: Mon, 13 Mar 2017 10:43:36 +0100 (CET) Message-Id: <20170313.104336.828020082602112914.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <95eed2ce-5541-cf8c-146e-21a73e30cd00@cisco.com> References: <148939103369.17026.5784133761974804877@ietfa.amsl.com> <20170313.084651.1144668331995785992.mbj@tail-f.com> <95eed2ce-5541-cf8c-146e-21a73e30cd00@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 09:43:34 -0000 Benoit Claise wrote: > Hi Martin, > > ietf-hardware@2017-03-07.yang fails yanglint validation. > See http://www.claise.be/IETFYANGPageCompilation.html This is a bug in yanglint. The leafref is marked as 'require-instance false', which means it can refer to a non-config leaf. /martin > > Regards, Benoit > > Hi, > > > > This version addresses the comments from Bart and Juergen. > > > > I think that this document is now ready for WGLC. > > > > > > /martin > > > > > > internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the NETCONF Data Modeling Language of the > >> IETF. > >> > >> Title : A YANG Data Model for Hardware Management > >> Authors : Andy Bierman > >> Martin Bjorklund > >> Jie Dong > >> Dan Romascanu > >> Filename : draft-ietf-netmod-entity-03.txt > >> Pages : 40 > >> Date : 2017-03-13 > >> > >> Abstract: > >> This document defines a YANG data model for the management of > >> hardware on a single server. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ > >> > >> There's also a htmlized version available at: > >> https://tools.ietf.org/html/draft-ietf-netmod-entity-03 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-03 > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > From nobody Mon Mar 13 02:52:42 2017 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 45F1C129561; Mon, 13 Mar 2017 02:52:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148939875827.17039.12523968136177749449@ietfa.amsl.com> Date: Mon, 13 Mar 2017 02:52:38 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 09:52:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : Network Access Control List (ACL) YANG Data Model Authors : Dean Bogdanovic Kiran Agrahara Sreenivasa Lisa Huang Dana Blair Filename : draft-ietf-netmod-acl-model-10.txt Pages : 32 Date : 2017-03-13 Abstract: This document describes a data model of Access Control List (ACL) basic building blocks. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. Please note that no other RFC Editor instructions are specified anywhere else in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements o "XXXX" --> the assigned RFC value for this draft. o Revision date in model (Oct 12, 2016) needs to get updated with the date the draft gets approved. The date also needs to get reflected on the line with . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 02:57:19 2017 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 B7C011294E1 for ; Mon, 13 Mar 2017 02:57:17 -0700 (PDT) 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 Q9nVfxJ1hGml for ; Mon, 13 Mar 2017 02:57:16 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30140129400 for ; Mon, 13 Mar 2017 02:57:16 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id j5so67486271pfb.2 for ; Mon, 13 Mar 2017 02:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=VbtZE7eGpfj+9BntqrviYTV1MmwzsdhL9GBDdRWTOXM=; b=npq1ovr/3rSMPLzTSl4fuveDiC/V9oicZ1Zpm2S/p+KNTVtEok3PkR6wu6Zc5rLe0w FR9qruS9OQgaDgCZAIdtdpyA1g9oD5wAKfBJdqmoLryIQtxO+0iSkonLAc+90eN8zOcx Gv3hS9U/k5w9ZjBvBsWLgw94nFvVdBXO6Qv8t6zbSIs7oqOYRAd7/AvA4Ff9w8mXlEIK whAh7C4U/IFh9iKPMdB21wWcBPOQvxZh0YVhZk1vmoOHaz3iabewso5TUI9Wvis7PpaO kCLGWhIEp0MzE/8IqY9vGvfO7lzMcpSgDbcUmrqVI0p32+LD1jbkk369WIn8nXsGsY20 cpCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=VbtZE7eGpfj+9BntqrviYTV1MmwzsdhL9GBDdRWTOXM=; b=Qm/GyHRNc2sTHssUqzu4qnes0vwL6JXnnaiQdd3ahh9dDjNkiVfQChAfjN1NyE9lNo dTbEB2lF707E3P2RcHqbiZJ3GpkiUAMY11WVjC/90z5OifIVYkqLhvO7frJM+qV4MLGz 8PGazTorIHkyH8B1nqxaNIe5NPKyv30WG57IA+4tcfVbMNA7Xw+uznsiDbx7h7sipOM7 oqX8wBaoXFSCDaTiX/U8GpyCrNCIlOSk9+ULgBeD4h4VlMhbIm6N7s19Dkd1CaWGh8Jr VVCbR3TXb505Gp7C9w4/fUrcOLNuDNT7Gxqnwztmdx0tPU4pBfFmTukZZ8x+GKM6HUgw y5Sw== X-Gm-Message-State: AMke39mEHF9nFc89pWMIUMxNP7346olz0N0REZtFP3ZAUubsPVD+6lSjqCY8ZVsz59yRqA== X-Received: by 10.98.66.155 with SMTP id h27mr35930750pfd.182.1489399035486; Mon, 13 Mar 2017 02:57:15 -0700 (PDT) Received: from [192.168.122.113] ([61.115.201.105]) by smtp.gmail.com with ESMTPSA id c124sm31088075pga.63.2017.03.13.02.57.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 02:57:15 -0700 (PDT) From: Dean Bogdanovic Content-Type: multipart/alternative; boundary="Apple-Mail=_AAC3F853-3081-4E48-A9D5-9065A266CBD5" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: References: <148939875845.17039.4017763838166134753.idtracker@ietfa.amsl.com> To: NetMod WG Date: Mon, 13 Mar 2017 10:57:12 +0100 X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 09:57:17 -0000 --Apple-Mail=_AAC3F853-3081-4E48-A9D5-9065A266CBD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here is the new version of the ACL draft. Since December and some = additional comments about the ACL model, I spoke with many operators and = how they use ACLs. I have also received lot of detailed ACL = configurations. In most cases, the model is easily adapted to the = current use cases in operations. But to answer the comments, the authors = have added a detailed example in the addendum section how the model can = be extended and how this model can be used. Cheers, Dean > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-netmod-acl-model-10.txt > Date: March 13, 2017 at 10:52:38 AM GMT+1 > To: , "Kiran Koushik" , = "Lisa Huang" , "Dean Bogdanovic" = , "Dana Blair" , "Kiran Agrahara = Sreenivasa" >=20 >=20 > A new version of I-D, draft-ietf-netmod-acl-model-10.txt > has been successfully submitted by Dean Bogdanovic and posted to the > IETF repository. >=20 > Name: draft-ietf-netmod-acl-model > Revision: 10 > Title: Network Access Control List (ACL) YANG Data = Model > Document date: 2017-03-13 > Group: netmod > Pages: 32 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-netmod-acl-model-10.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-netmod-acl-model-10 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model-10 >=20 > Abstract: > This document describes a data model of Access Control List (ACL) > basic building blocks. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > This draft contains many placeholder values that need to be replaced > with finalized values at the time of publication. This note > summarizes all of the substitutions that are needed. Please note > that no other RFC Editor instructions are specified anywhere else in > this document. >=20 > Artwork in this document contains shorthand references to drafts in > progress. Please apply the following replacements >=20 > o "XXXX" --> the assigned RFC value for this draft. >=20 > o Revision date in model (Oct 12, 2016) needs to get updated with > the date the draft gets approved. The date also needs to get > reflected on the line with . >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_AAC3F853-3081-4E48-A9D5-9065A266CBD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Here is the new version of the ACL draft. Since December and = some additional comments about the ACL model, I spoke with many = operators and how they use ACLs. I have also received lot of detailed = ACL configurations. In most cases, the model is easily adapted to the = current use cases in operations. But to answer the comments, the authors = have added a detailed example in the addendum section how the model can = be extended and how this model can be used.

Cheers,

Dean


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-ietf-netmod-acl-model-10.txt
Date: = March 13, 2017 at 10:52:38 AM = GMT+1
To: = <netmod-chairs@ietf.org>, "Kiran Koushik" <kkoushik@cisco.com>, = "Lisa Huang" <lyihuang16@gmail.com>, "Dean Bogdanovic" <ivandean@gmail.com>, = "Dana Blair" <dblair@cisco.com>, "Kiran Agrahara Sreenivasa" <kkoushik@cisco.com>


A new version = of I-D, draft-ietf-netmod-acl-model-10.txt
has been = successfully submitted by Dean Bogdanovic and posted to the
IETF repository.

Name: = draft-ietf-netmod-acl-model
Revision: 10
Title:= = Network Access Control List (ACL) YANG Data Model
Document date: 2017-03-13
Group:= = netmod
Pages: 32
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-netmod-acl-mode= l-10.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
Htmlized:       https://tools.ietf.org/html/draft-ietf-netmod-acl-model-10<= br class=3D"">Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model= -10

Abstract:
=   This document describes a data model of Access Control List = (ACL)
  basic building blocks.

  Editorial Note (To be removed by RFC Editor)

  This draft contains many = placeholder values that need to be replaced
=   with finalized values at the time of publication.  This = note
  summarizes all of the substitutions that = are needed.  Please note
  that no other = RFC Editor instructions are specified anywhere else in
=   this document.

=   Artwork in this document contains shorthand references to = drafts in
  progress.  Please apply the = following replacements

  o =  "XXXX" --> the assigned RFC value for this draft.

  o  Revision date in model = (Oct 12, 2016) needs to get updated with
=      the date the draft gets approved. =  The date also needs to get
=      reflected on the line with <CODE = BEGINS>.



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.

The IETF = Secretariat


= --Apple-Mail=_AAC3F853-3081-4E48-A9D5-9065A266CBD5-- From nobody Mon Mar 13 08:15:48 2017 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 D7E1A129702; Mon, 13 Mar 2017 08:15:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148941813386.17035.9935479181243960908@ietfa.amsl.com> Date: Mon, 13 Mar 2017 08:15:33 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-intf-ext-yang-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 15:15:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : Common Interface Extension YANG Data Models Authors : Robert Wilton David Ball Tapraj Singh Selvakumar Sivaraj Filename : draft-ietf-netmod-intf-ext-yang-04.txt Pages : 26 Date : 2017-03-13 Abstract: This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. These properties are common to many types of interfaces on network routers and switches and are implemented by multiple network equipment vendors with similar semantics, even though some of the features are not formally defined in any published standard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-intf-ext-yang-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 Mon Mar 13 08:47:59 2017 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 AA9A812962E for ; Mon, 13 Mar 2017 08:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=voltanet-io.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 HpAIdLpw21tv for ; Mon, 13 Mar 2017 08:47:56 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 92ACD12941A for ; Mon, 13 Mar 2017 08:47:56 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id o126so70860082pfb.3 for ; Mon, 13 Mar 2017 08:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voltanet-io.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sLPD3x8pQKcuoy1Aixku9mpfC86OvsJEp2yW+i1xRpE=; b=tQZYrgL/tI0Pw/xxKeTjS6maZUjV5/Srv4oOINKxdLBpCXtTHqHodiPFrD4I1vFZdV J9u01clcfuEQ24pf6QvnY9SdLnoswfP7gqSHHX7xDvCui8k4Ook1ruG6WMLek7vw7JkO RtuPHVe5xoLVnxrO3yCP4G/GOZXZbWEEdn0LgZ+Y/sBkLbIZ0FHtRZnHz0uJekF34ssm 6zHmDQF76lqHGEF5n5WEpkxJ45GOu9YcwjL053NkwEzTVd4V1266lnjJr2SaAP6gIYYP TbMJr+S4BAVhIS8ga546E2UKE+GZ6lcwek2OdISUr+CLFhCIOy+bCgWrp5fLv3sbch7p DFrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sLPD3x8pQKcuoy1Aixku9mpfC86OvsJEp2yW+i1xRpE=; b=Ud7DdJdcsqGgt9uhPnDqEC+FBW4nvOtfsXhl7Cg8iO/csR3/ecjJTN/jfQOIHlhub0 D66BSaGtiMQBOcZIKJSclC0GD6UdzLTSAMqeuAwaHBh/ravd0idr7OkqTWCkIjZM+zWV HrddWP52VqXRDvzKgIh3VvK3QD59VLY+e+7asRAnNSyVAiXoLQsSHx1iP92KRNRvIU+H 2S8VUA6sezYdd03WCT7N7+o+AEaO4MAwcTgPeNpZ6N/T43rTia/Ti8VdfuEmp88XxG+b LYSAYsh0wxq2Evp8SjMgGFRKc8aDuyikDMtZLP9o3H1LKaep1CIPMfsN0tXOkcygejof RAsA== X-Gm-Message-State: AMke39ny2NICy7WhwuPhN0RgycsKJMcGFn+6OAuo56vnlrlpdb737z6BHN/sDJ0yZEb3XA== X-Received: by 10.98.156.23 with SMTP id f23mr37795449pfe.3.1489420075949; Mon, 13 Mar 2017 08:47:55 -0700 (PDT) Received: from [172.20.1.78] ([61.115.201.97]) by smtp.gmail.com with ESMTPSA id b83sm33606614pfe.12.2017.03.13.08.47.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 08:47:55 -0700 (PDT) From: Dean Bogdanovic Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9A9BCE17-44E5-42A3-8B59-2492AC4A8FE0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Mar 2017 16:47:51 +0100 In-Reply-To: <032301d286ac$73fad140$5bf073c0$@olddog.co.uk> To: adrian@olddog.co.uk References: <067201d27270$a08cc790$e1a656b0$@olddog.co.uk> <4248688C-E0AC-4302-A281-0622D824FA4D@voltanet.io> <06fa01d28225$05a25050$10e6f0f0$@olddog.co.uk> <8DACB5AE-56FE-4CB1-BCBE-8D2BD214FFC0@cisco.com> <032301d286ac$73fad140$5bf073c0$@olddog.co.uk> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: opsawg@ietf.org, draft-ietf-netmod-yang-model-classification@ietf.org, netmod@ietf.org Subject: Re: [netmod] Question on draft-ietf-netmod-yang-model-classification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 15:47:58 -0000 --Apple-Mail=_9A9BCE17-44E5-42A3-8B59-2492AC4A8FE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adrian, I just want to clarify one issue on BSS. Order management is part of the = BSS and when external customer is ordering a new service, it talks to = the order management system (either through a sales person or directly = via self ordering application). The BSS then sends request to the = provisioning system to create the service, essentially the service = orchestrator. So I would argue that BSS is exposed to the external = consumers of the service, but those systems are developed by internal = teams. I will update the draft according to some of your comments, but will = leave this for the moment in the draft and we can have a discussion on = this at the WG session or offline before or after. Dean > On Feb 14, 2017, at 11:23 AM, Adrian Farrel = wrote: >=20 > Hi Tianran, >=20 > Nice summary. >=20 > I think some of the confusion may be that = draft-ietf-netmod-yang-model-classification shows "Network Service YANG = Modules" on the interface between OSS/BSS and the network. But the = "customer service model" is at a different place in the hierarchy as = shown in Figure 4 of draft-wu-opsawg-service-model-explained. >=20 > To attend to your specific questions: >> 1. Whether it's necessary to further classify the "Network Service = YANG >> Module"? >=20 > I'm not particularly interested in doing that except so far as is = necessary to avoid conflict between the two I-Ds. In = draft-wu-opsawg-service-model-explained we introduced "customer service = module" and "service delivery module" because it seemed (to us) that = there were two different groups of people using the term "service model" = to describe very different modules. >=20 >> 2. What's the well definition of "Network Service YANG Module", = "customer >> service module", "service delivery module"? >=20 > Since draft-wu-opsawg-service-model-explained introduces the terms = "customer service module" and "service delivery module" I am going to = say that I am happy with the definitions in that document. I can say = that "customer service module" is used consistently with the L3SM and = L2SM work and so it is probably a stable definition. "Service delivery = module" is a term we invented to match the definition in = draft-wu-opsawg-service-model-explained: I don't think the term is used = anywhere else, so maybe a better question is "is this a = useful/meaningful term?" >=20 > If the answer to Q1 is that draft-wu-opsawg-service-model-explained = should not try to resolve any overlap with = draft-ietf-netmod-yang-model-classification, then I think the definition = of "Network Service YANG Module" in = draft-ietf-netmod-yang-model-classification is fine (with the few tweaks = Dean and I discussed on the list). >=20 >> 3. What's the well position of the above terms in the management = architecture? >=20 > Ah, I like that question. But it makes me ask: where should I look for = the definitive, state-of-the art management architecture? >=20 > Thanks for continuing to drive this issue. >=20 > Adrian >=20 >> -----Original Message----- >> From: Tianran Zhou [mailto:zhoutianran@huawei.com] >> Sent: 14 February 2017 09:54 >> To: Carl Moberg (camoberg); adrian@olddog.co.uk >> Cc: opsawg@ietf.org; = draft-ietf-netmod-yang-model-classification@ietf.org; >> netmod@ietf.org; Dean Bogdanovic >> Subject: RE: Question on draft-ietf-netmod-yang-model-classification >>=20 >> Hi, >>=20 >> Based on the discussion, here I try to clean up the confusion of the = two I-Ds. >>=20 >> [draft-ietf-netmod-yang-model-classification] classifies the yang = modules into >> "Network Service YANG Module" and the "Network Element YANG Module". >> And usually, it uses "service module" to imply the "Network Service = YANG >> Module", i.e., "Network" here only want to limit the scope to network = related >> modules. One example of "Network Service YANG Module" is = [draft-ietf-l3sm- >> l3vpn-service-model]. >> The authors do not want to further classify the service module into = more layers, >> until more operational practice comes. >>=20 >> [draft-wu-opsawg-service-model-explained] further classifies the = service module >> into "customer service module" and the "service delivery module". I = think this is >> based on the chair work on L3SM and L2SM WG and discussion with = operators. >> But the document think the "Network Service YANG Module" defined in = [draft- >> ietf-netmod-yang-model-classification] is "service delivery module" = not include >> the "customer service module". The = [draft-ietf-l3sm-l3vpn-service-model] is >> actually the "customer service module". >>=20 >> Here comes the question: >> 1. Whether it's necessary to further classify the "Network Service = YANG >> Module"? >> 2. What's the well definition of "Network Service YANG Module", = "customer >> service module", "service delivery module"? >> 3. What's the well position of the above terms in the management = architecture? >>=20 >> Good to see if we can solve the conflicts, these two I-Ds can = complement each >> other. >>=20 >> Best, >> Tianran >>=20 >>> -----Original Message----- >>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Carl = Moberg >>> (camoberg) >>> Sent: Thursday, February 09, 2017 12:48 AM >>> To: adrian@olddog.co.uk >>> Cc: opsawg@ietf.org; >>> draft-ietf-netmod-yang-model-classification@ietf.org; = netmod@ietf.org; >>> Dean Bogdanovic >>> Subject: Re: [netmod] Question on >>> draft-ietf-netmod-yang-model-classification >>>=20 >>> Team, >>>=20 >>> Inline below. >>>=20 >>>> On Feb 8, 2017, at 8:04 AM, Adrian Farrel = wrote: >>>>=20 >>>> Hi Dean, >>>>=20 >>>> I've been processing your response and the continuing thread with = you >>> and Tianran. >>>>=20 >>>>>> We've been trying to ensure that >>>>>> draft-wu-opsawg-service-model-explained is consistent with the >>>>>> latest version of draft-ietf-netmod-yang-model-classification. In >>>>>> discussions with Tianran a question has come up. >>>>>>=20 >>>>>> In section 2 you have a nice definition of Network Service YANG >>>>>> Modules and this definition maps nicely to our definition of = "service >>> delivery models". >>>>>> Furthermore, your figure 1 shows Network Service YANG Modules on = the >>>>>> interface between OSS/BSS and the various network services. >>>>>>=20 >>>>>> We have further defined "customer service models" at a higher = layer >>>>>> still. That is, on the interface to the customer. This (of = course?) >>>>>> assumes that the OSS/BSS is not customer code :-) >>>>>>=20 >>>>>> However, your discussion of Network Service YANG Modules in = section >>>>>> 2.1 seems slightly at odds, although this may be just ambiguity. >>>>>>=20 >>>>>> For example, when you say, "Network Service YANG Modules describe >>>>>> the characteristics of a service, as agreed upon with consumers = of that >>> service," >>>>>> this is not the same as, "This model is used in the discussion >>>>>> between a customer and a service provide to describe the = characteristics >>> of a service." >>>>>> That is, the former case could be arrived at after processing = based >>>>>> on the latter case - processing that we have called "service >>>>>> orchestration" but might (of course) be what leads to the = operator poking >>> the OSS/BSS. >>>>>=20 >>>>> Adrian, I can see the ambiguity. The point of service module is to = be >>>>> consumed by the customer and there can be some modifications of = the >>>>> service module to adapt to the customer specifics. >>>>=20 >>>> So far I agree with your email and therefore not with your = document. The >>> OSS/BSS is not, IMHO, a tool used by the customer. >>>>=20 >>>> Please see Figure 3 in = draft-wu-opsawg-service-model-explained-05.txt >>> that shows the customer distinct from the OSS/BSS. >>>=20 >>> IMHO figure 3 in the draft is what it says, an _example_ of a set of >>> relationships between the constituent parts of a = provisioning/activation >>> system. >>>=20 >>> In all real-world applications, customers are several layers above = the >>> =E2=80=9Cservice orchestrator=E2=80=9D and adjacent systems. But the = YANG model nevertheless >>> serves the purpose of describing the structure of the service for = customer >>> (outside the SP) or other consuming parties (e.g. the OSS/BSS = teams). >>>=20 >>>>>> This might all be fine and good, but later in the same section = you >>>>>> say "Network Service YANG Modules define service models to be >>>>>> consumed by external systems. >>>>>> These modules are commonly designed, developed and deployed by >>>>>> network infrastructure teams." And there you introduce two terms >>>>>> that are previously undefined and only server to add ambiguity. >>>>>> Specifically "external to what?" I could make and argument that = the >>>>>> OSS is developed and deployed by network infrastructure teams, ad = also >>> that the OSS is external to the network itself. >>>>>=20 >>>>> Agree that external systems are not defined and this text has to = be >>>>> clarified. The external systems can be OSS and BSS. >>>>=20 >>>> If we relabelled our "Service Delivery Model" as "Network Service = Model" >>> would that be consistent? >>>>=20 >>>> That is, in any case, to say that the OSS/BSS does not talk = directly to >>> the devices. >>>=20 >>> I think that would help. And yes, the intent of =E2=80=9Cexternal=E2=80= =9D was to say =E2=80=9Cother >>> than=E2=80=9D, rather than =E2=80=9Coutside of the company=E2=80=9D = (or something like that). >>>=20 >>>>>> And, in between these two quoted pieces of text, you have... >>>>>>=20 >>>>>> As an example, the Network Service YANG Module defined in >>>>>> [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract >>>>>> model for Layer 3 IP VPN service configuration. >>>>>=20 >>>>> My question is where do you see the L3SM model above or below OSS? >>>>=20 >>>> Well, look at the figure in section 5 of >>>> draft-ietf-l3sm-l3vpn-service-model-19.txt >>>>=20 >>>> It is logically higher, but OSS/BSS are not "in the flow" as they = are >>> legacy components in a softwarized world. >>>> However, per our pictures, OSS/BSS should use the same set of >> models/modules >>> as used by the "service orchestrator=E2=80=9D. >>>=20 >>> This is a little different in different SPs. Many of them consider = the >>> RFS-style service definition as laid out in L3SM as something that = is owned >>> by the infratrstucture and ordered through the OSS/BSS layer (the = order >>> manager to be more precise). >>>=20 >>>>> Because there are some nuances in the service module, but at the = end >>>>> we decided not to do sub classification >>>>=20 >>>> Mutter, mutter. >>>> In the document, you talk about "network service modules" not = "service >>> modules" and only trim to "service module" in the text implying that = you >>> always actually mean "network service module=E2=80=9D. >>>=20 >>> We always mean =E2=80=9Cnetwork service models=E2=80=9D, there are = many =E2=80=9Cservice models=E2=80=9D >>> out there that have little or nothing to do with the network. And I = would >>> like to not go there :-) >>>=20 >>>>> one is the business and one technical service. >>>>>=20 >>>>> When i read the YANG-Data-Model-for-L3VPN-service-delivery, it = looked >>>>> to me much more like a technical model, then the business model, = as >>>>> didn=E2=80=99t see SLA definitions to track the business = parameters of the service >>> use. >>>>=20 >>>> It is certainly not a business model and does not include SLAs. = Other >>> people have far more experience working on these things (TMF, MEF, = ...) >>> and it is not an IETF core competence. Our intention is that our = module >>> can be augmented or accompanied by other modules in order to create = a >> business >>> model, acknowledging that commercial details (even including SLAs) = will >>> vary from one operator to another, but that the core technical = description >>> of the service can be (and, it turns out, is) common across multiple >>> providers. >>>>=20 >>>> We even wrote text in Section 5 of draft-wu-opsawg-service-model- >> explained >>> to help with this. >>>>=20 >>>>>> Per my other email, this reference needs to be fixed. But I = struggle >>>>>> to see the L3SM module as consistent with your figure. It may or = may >>>>>> not be consistent with your text dependent on the interpretation. >>>>>=20 >>>>> Sure, we can fix that reference, but the authors of L3SM module >>>>> should do their own module classification, as they are the only = ones >>>>> that know the intent of the module. >>>>=20 >>>> That is fine. They can classify it, and they can use your >>>> classification system, but only if it can be understood, is >>>> meaningful, and fits what they are trying to achieve :-) >>>>=20 >>>> Your text currently says >>>> As an example, the Network Service YANG Module defined in >>>> [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract >>>> model for Layer 3 IP VPN service configuration. >>>>=20 >>>> Your text and figures show "Network Service YANG Module" as being >> something >>> that the OSS/BSS talks (presumably toward a network orchestrator?). = Thus >>> the L3SM module does not fit here. And that is why we wrote >>> draft-wu-opsawg-service-model-explained and included Figure 4 to = augment >>> your figure. >>>=20 >>> Figure 4 also seems like an _example_ of how one could structure the = layers. >>> Personally I have never seen an implementation of a clear split = between >>> "Network Service YANG Modules=E2=80=9D and "Service YANG Modules=E2=80= =9D. That=E2=80=99s why we >>> wanted to stay clear of that discussion until there is experience = telling >>> us that this is indeed best practice. >>>=20 >>>> And *finally*, Tianran is concerned that there may be confusion = arising >>> from whether the module we reference are "Network service modules", >> "service >>> delivery modules", "network configuration modules", "network element >>> modules", or "device configuration modules". So many terms, but = presumably >>> these modules don't fit into all of the categories! The list is: >>>>=20 >>>> [I-D.dhjain-bess-bgp-l3vpn-yang] >>>=20 >>> =E2=80=9C=E2=80=9D" >>> There are two parts of the BGP L3VPN yang data model. The first = part >>> of the model defines VRF specific parameters for L3VPN by = augmenting >>> the routing-instance container defined in the routing model [I- >>> D.ietf-netmod-routing-cfg] and the second part of the model = defines >>> BGP specific parameters for the L3VPN by augmenting the base BGP = data >>> model defined in [I-D.shaikh-idr-bgp-model]. >>> =E2=80=9C=E2=80=9D=E2=80=9D >>>=20 >>> and it=E2=80=99s importing ietf-routing, ietf-interfaces, = ietf-interfaces >>> augmenting /rt:routing/ and /if:interfaces/. >>>=20 >>> =46rom draft-ietf-netmod-yang-model-classification: >>>=20 >>> =E2=80=9C=E2=80=9D=E2=80=9D >>> Network Element YANG Modules describe the characteristics of a >>> network device as defined by the vendor of that device. The = modules >>> are commonly structured around features of the device, e.g. = interface >>> configuration [RFC7223], OSPF configuration [=E2=80=A6] =E2=80=9C=E2= =80=9D" >>>=20 >>> I would say that ietf-bgp-l3vpn@2016-02-22.yang is a network element = YANG >>> module. >>>=20 >>>> [I-D.ietf-bess-l2vpn-yang] >>>=20 >>> =E2=80=9C=E2=80=9D=E2=80=9D >>> In this version of the document, one single container, l2vpn, is >>> defined. Within the l2vpn container, endpoint-a, endpoint-z and a >>> list of endpoints are defined. [=E2=80=A6] >>> =E2=80=9C=E2=80=9D" >>>=20 >>> =46rom draft-ietf-netmod-yang-model-classification: >>>=20 >>> =E2=80=9C=E2=80=9D=E2=80=9D >>> That is, a >>> service module does not expose the detailed configuration = parameters >>> of all participating network elements and features, but describes = an >>> abstract model that allows instances of the service to be = decomposed >>> into instance data according to the Network Element YANG Modules = of >>> the participating network elements. >>> =E2=80=9C=E2=80=9D=E2=80=9D >>>=20 >>> I would say that ietf-l2vpn@2016-10-24.yang is a network service = YANG >>> module. >>>=20 >>>> [I-D.ietf-bess-evpn-yang] >>>=20 >>>=20 >>> This draft contains two modules: >>> - ietf-ethernet-segment@2016-07-08.yang >>> - ietf-evpn@2016-07-08.yang >>>=20 >>> Reading the first paragraph of section 3.1 =E2=80=9COverview=E2=80=9D >>>=20 >>> =E2=80=9C=E2=80=9D=E2=80=9D >>> Two top level module, Ethernet-Segment and EVPN, are defined. = The >>> Ethernet-Segment contains a list of interface to which any = Ethernet- >>> Segment attributes are configured/applied. >>> =E2=80=9C=E2=80=9D=E2=80=9D >>>=20 >>> =E2=80=A6and understanding that the list of interfaces can be = located on different >>> network elements, makes me think that these two modules are both = examples >>> of network device YANG modules. >>>=20 >>>> I wonder what type of module you think these are. >>>>=20 >>>> Cheers, >>>> Adrian >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_9A9BCE17-44E5-42A3-8B59-2492AC4A8FE0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYxr8oAAoJEOPDsSt0S41TSScP+wXoAr4aKM/2C0vsGMcP/KkP 5LX5Had9z0Oehj+6EC7+n47f8tsQ2JJPb/dxm6SHL4G1Comy0n1W2v+QjSS+fm/G YSOkQeIn/orDEayoxNyKpJNP0MgoHgMgxSmzAVXQ6WPdMQkOv4+QKJmsFcVcrDzH mrhsCFPLNmEzgE+7F+SYbMH6BRXHwoMHzqSJAR+SQzup1I875qakj8OGd7CpXqn0 Mvzexl36xAwWPUK2+Sih2vgAfOb7p1rf6TVyJNbeT6k1rxZyOqFK5NCZrbgGM8+l p8PH7TSYR7X0Co2TES993+DW5e1/PZNt1qSStAyO/0phFXIGNylBWV8vb1AXjR35 84l3q1oVbwHYyU2FgzbT1tGP3MMrMvsgigRMOPShg15v8L2Uzyfb3u0NkP61TFSs +fD0p+S6TbB6ljzGe80bC7YN7yW05BT3T99MjAx2VotcDpIqYIwqll+rfSlOnSu3 7faZFVkua8+v8BoEbjVvinTBrLJbt66Kgpa32i0WX/YERjEubsSktDd0sJ+efTCi ZE39fA9/kxzja5/kzwe3fTpaWZB1Jr77v9fmeYkrBHTXut1Txfhzwlz4582FoHjH NM8ROkAnS6xxZJbNTAmq8RwTXzfLsoTKCSkGBwbgCsPiAEspy7KgnJLSW0GDBVNU B1k4afF9llqoHNV7XuBo =aSk5 -----END PGP SIGNATURE----- --Apple-Mail=_9A9BCE17-44E5-42A3-8B59-2492AC4A8FE0-- From nobody Mon Mar 13 09:05:08 2017 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 1E48F1297FE; Mon, 13 Mar 2017 09:05:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942110210.17001.752720248746306527@ietfa.amsl.com> Date: Mon, 13 Mar 2017 09:05:02 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-model-classification-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:05:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : YANG Module Classification Authors : Dean Bogdanovic Benoit Claise Carl Moberg Filename : draft-ietf-netmod-yang-model-classification-05.txt Pages : 11 Date : 2017-03-13 Abstract: The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards-defining organizations (SDOs), open source software projects, vendors and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules. A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-model-classification-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 11:11:29 2017 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 4F93F12999E for ; Mon, 13 Mar 2017 11:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 lZciNqZfL9-5 for ; Mon, 13 Mar 2017 11:11:27 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7771299B5 for ; Mon, 13 Mar 2017 11:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2140; q=dns/txt; s=iport; t=1489428686; x=1490638286; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3FTS02MR45M37hdaFMEP8vv0QiLAMTKNzi1Nf85/nsM=; b=iJmoQ7gB6LsNuyyb1c5s32XH0cotrfCAsax0l4LYnpn2eEygAiix2k8o vPDj8bhk3nCY12UC+wE9toCMv0dNzYCSVi9GIWwNzvDiuHNZe4KFtGZqZ dDp5u1GxUDO6mplNE043T5KhKJvwGSQKj2GZ6/y0XVDJIjYeCvMeHzdg9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgCk38ZY/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1mKDpExH5U7gg4fC4UuSgIagkg/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAwEBGwYROgsMBAIBCBEEAQEDAiYCAgIlCxUICAIEDgWKAA6uLYImi?= =?us-ascii?q?lQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUOCBQiCYoRUF4JvLoIxBZYAhkE?= =?us-ascii?q?BkjiRJZNCAR84gQRYFUERAYZFdYhVAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.36,160,1486425600"; d="scan'208";a="395609967" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Mar 2017 18:11:26 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v2DIBPXr017917 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Mar 2017 18:11:26 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Mar 2017 13:11:25 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Mon, 13 Mar 2017 13:11:25 -0500 From: "Clyde Wildes (cwildes)" To: "t.petch" Thread-Topic: [netmod] draft-ietf-netmod-syslog-model-12 Thread-Index: AQHSkobQ/9SfvUTqzk20DVCcI8lG36GTA94A Date: Mon, 13 Mar 2017 18:11:25 +0000 Message-ID: <63894410-D14B-4F3D-B72C-898CE30B5104@cisco.com> References: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> <1481689016940.22442@Aviatnet.com> <3F4C49C9-1A6A-4644-97C6-F9CDC2E4EB4B@cisco.com> <1CC274D2-72B9-4F79-A70F-3DF332C65A60@cisco.com> <44C50B18-8918-47E4-A9FE-F4A676E64AA1@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF818AA@SJCEML703-CHM.china.huawei.com> <02B9298C-631A-46F7-9FA9-19B1959327FE@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81C18@SJCEML703-CHM.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81CBA@SJCEML703-CHM.china.huawei.com> <033D3CA2-7297-48C8-A5BD-B723F7F1911B@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81CF7@SJCEML703-CHM.china.huawei.com> <075901d29286$5def4300$4001a8c0@gateway.2wire.net> In-Reply-To: <075901d29286$5def4300$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.146.253] Content-Type: text/plain; charset="utf-8" Content-ID: <13A0874664669747BD346ACA6CC5ABD5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-syslog-model-12 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:11:28 -0000 VG9tLA0KDQpUaGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9n LW1vZGVsIGluY2x1ZGVzIGEgY2hhbmdlIHRvIHRoZSBZYW5nIHRyZWUgZGlhZ3JhbSBleHBsYW5h dGlvbiB0byBpbmNsdWRlIHRoZSB0ZXh0IGZyb20gUkZDNjA4N2Jpcy4NCg0KUkZDNTQyNiBpcyBy ZWZlcmVuY2VkIGluIHRoZSBtb2RlbCB3aGVyZSAiVHJhbnNtaXNzaW9uIG9mIFN5c2xvZyBNZXNz YWdlcyBvdmVyIFVEUOKAnSBvY2N1cnM6DQoNCiAgICAgICAgICAgICAgY2FzZSB1ZHAgew0KICAg ICAgICAgICAgICAgICBjb250YWluZXIgdWRwIHsNCiAgICAgICAgICAgICAgICAgICBkZXNjcmlw dGlvbg0KICAgICAgICAgICAgICAgICAgICAgIlRoaXMgY29udGFpbmVyIGRlc2NyaWJlcyB0aGUg VURQIHRyYW5zcG9ydA0KICAgICAgICAgICAgICAgICAgICAgIG9wdGlvbnMuIjsNCiAgICAgICAg ICAgICAgICAgICByZWZlcmVuY2UNCiAgICAgICAgICAgICAgICAgICAgICJSRkMgNTQyNjogVHJh bnNtaXNzaW9uIG9mIFN5c2xvZyBNZXNzYWdlcyBvdmVyIFVEUCI7DQoNClRoaXMgaXMgYSBjb3Jy ZWN0IHJlZmVyZW5jZS4NCiAgDQpUaGFua3MsDQoNCkNseWRlDQoNCk9uIDMvMS8xNywgNDoyMCBB TSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgdC5wZXRjaCIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiBpZXRmY0BidGNvbm5lY3QuY29tPiB3cm90ZToNCg0KICAgIFRoZSBleHBs YW5hdGlvbiBvZiB0aGUgWUFORyB0cmVlIGRpYWdyYW0gaXMgbm90IHRoYXQgaW4gUkZDNjA4Nzsg SSB0aGluaw0KICAgIHRoYXQgaXQgc2hvdWxkIGJlIChvciBlbHNlIGV4cGxhaW4gd2h5IG5vdCkN CiAgICANCiAgICBJIGFtIGNvbmZ1c2VkIGJ5IHRoZSB2YXJpYXRpb24gaW4gdGhlIHJlZmVyZW5j ZXMgdG8gUkZDIGluIHRoZSBtb2R1bGVzLg0KICAgIA0KICAgIEkgc2VlDQogICAgUkZDIDU0MjQN CiAgICBbUkZDNTQyNl0NCiAgICBSRkM1NDI0DQogICAgDQogICAgSSB0aGluayB0aGUgZmlyc3Qg Y29ycmVjdA0KICAgIA0KICAgIFRvbSBQZXRjaA0KICAgIA0KICAgIC0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCiAgICBGcm9tOiAiQWxleGFuZGVyIENsZW1tIiA8YWxleGFuZGVyLmNsZW1t QGh1YXdlaS5jb20+DQogICAgVG86ICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+ Ow0KICAgIDxkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWxAaWV0Zi5vcmc+DQogICAgQ2M6 IDxuZXRtb2RAaWV0Zi5vcmc+DQogICAgU2VudDogRnJpZGF5LCBGZWJydWFyeSAyNCwgMjAxNyAx MjoyNSBBTQ0KICAgIFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0 LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0xMQ0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbmV0bW9kIG1haWxpbmcgbGlzdA0K ICAgIG5ldG1vZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kDQogICAgDQoNCg== From nobody Mon Mar 13 11:20:33 2017 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 D43EE1299FA for ; Mon, 13 Mar 2017 11:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 EgfKgv7Ty2Xo for ; Mon, 13 Mar 2017 11:20:19 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B351299F4 for ; Mon, 13 Mar 2017 11:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1228; q=dns/txt; s=iport; t=1489429218; x=1490638818; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=g13v2cLsy+E4ZroXmYSpFQccakTMwv/ip6rJ+MMAfMc=; b=O5tIejqyV1YMQTZ1DGpGQ+IV4IBKvIKrmzbmHTS2UUZhvVA2Ea59REkA dwK1sazBuNFncoNXq4QC/r/SsFTFsOjY75AiykbrOA4yY6k2TrA4SiuE3 E4pyBlxfbke0KkP8OkqcrBbfJywYwQIB4Cjc5/2GYPmyELqAZj3zSLRXS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAQAo4sZY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqYI1uc5BdlTuCDh8LhS5KAoMhGAECAQEBAQEBAWsohRYBAQE?= =?us-ascii?q?DAQEwAQU2CxALEAguJzAGAQwGAgEBiXwOsGKKUwEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFhk6CBYJqijkBBJxBkjmBe4hXhlOIRYJwiA4fOIEEIxYIFxVBhldANYl?= =?us-ascii?q?iAQEB?= X-IronPort-AV: E=Sophos;i="5.36,160,1486425600"; d="scan'208";a="650402031" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2017 18:20:16 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2DIKGdq012164; Mon, 13 Mar 2017 18:20:16 GMT To: netmod@ietf.org, Andy Bierman References: <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> <20170308193434.GA10080@elstar.local> <20170311.224951.2245774412799352894.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Mon, 13 Mar 2017 18:20:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170311.224951.2245774412799352894.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:20:25 -0000 Hi Andy, Would it make sense to update 6087bis section 4.4 to reference this new pyang option for generated tree diagrams? Thanks, Rob On 11/03/2017 21:49, Martin Bjorklund wrote: > "Acee Lindem (acee)" wrote: >> Hi Juergen, >> >> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder" >> > j.schoenwaelder@jacobs-university.de> wrote: >> >>> On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrote: >>>> This way, reader can focus more quickly on the diffs, but also this >>>> likely mimics what happened in reality (start with `pyang -f tree` >>>> and then manually edit from there). What do you think? >>>> >>> Manually edited tree diagrams? I hope not. >> I frequently have to manually edit the pyang-generated trees to get them >> to fit in the xml2rfc output. Is there a work around for this that I don¹t >> know about? > In the latest pyang, I have added --tree-line-length. Use: > > pyang -f -tree --tree-line-length 69 ... > > to fit RFCs. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Mar 13 11:22:01 2017 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 751D21299F2 for ; Mon, 13 Mar 2017 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 mZ16yEqTTb94 for ; Mon, 13 Mar 2017 11:21:54 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DAF01299C5 for ; Mon, 13 Mar 2017 11:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2124; q=dns/txt; s=iport; t=1489429313; x=1490638913; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aiRLkbwvf6Eq+8Q6RlIA61CObZRYZvFJcC+ZI42jE1Q=; b=FK9CAiEQh65kwjJl1gA0EnvxZKU5IKrC8OCtwIS2qSoYRZS7USZVGBhx +9kAxos3upxescX1hLF/EpwS4RomQwViRcIHhLOMcpV1dUW2lZogTYX1w RpChxZhNcSpYAZvFBlQ8Abdog7QzJPN1l3+MHQPPL4KYQr8vjYTKVUSIT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAQAo4sZY/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBaweDWYoOpwuCDoYiAhqCSD8YAQIBAQEBAQEBayiFFgYdBhF?= =?us-ascii?q?FEAIBCBoCJgICAjAVEAIEDgWKAK5KgiaKUwEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R2BC4VDggWCaoRUgwYugjEBBJxBAZI4kSWTQgEfOIEEWBVBEQGGRXWIVQGBDAE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.36,160,1486425600"; d="scan'208";a="394422671" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2017 18:21:52 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v2DILqEj004638 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Mar 2017 18:21:52 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Mar 2017 13:21:52 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Mon, 13 Mar 2017 13:21:52 -0500 From: "Clyde Wildes (cwildes)" To: "Dale R. Worley" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 Thread-Index: AQHSlrvK2BfURE7sa0q90Jr392ctJqGS/mEA Date: Mon, 13 Mar 2017 18:21:52 +0000 Message-ID: References: <033D3CA2-7297-48C8-A5BD-B723F7F1911B@juniper.net> <87k282cejf.fsf@hobgoblin.ariadne.com> In-Reply-To: <87k282cejf.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.146.253] Content-Type: text/plain; charset="utf-8" Content-ID: <96C7E423C5E1C74295E5A9BB921E0D42@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:21:56 -0000 RGFsZSwNCg0KVGhhbmtzIGZvciB0aGUgc2ltcGxpZmljYXRpb24uIEkgaGF2ZSBpbmNvcnBvcmF0 ZWQgdGhpcyBpbiB0aGUgbmV4dCBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwgcmV2aXNp b24uDQoNClJlZ2FyZHMsDQoNCkNseWRlDQoNCg0KT24gMy82LzE3LCAxMjo1MyBQTSwgIkRhbGUg Ui4gV29ybGV5IiA8d29ybGV5QGFyaWFkbmUuY29tPiB3cm90ZToNCg0KICAgIChXZSBzZWVtIHRv IGJlIHdlbGwgYmV5b25kIHRoZSBvcmlnaW5hbCBMQyBkYXRlLCBidXQgdGhpcyBpcyBvbmx5IGFu DQogICAgZWRpdG9yaWFsIGNvbW1lbnQuLi4pDQogICAgDQogICAgVGhlIGFsZ29yaXRobSBpbiBz ZWN0aW9uIDMgaXNuJ3QgY2xlYXIgdG8gbWUgKHBvc3NpYmx5IGJlY2F1c2UgSSdtIG5vdA0KICAg IHZlcnkgZmFtaWxpYXIgd2l0aCBzeXNsb2cgaW4gcHJhY3RpY2UpOg0KICAgIA0KICAgICAgIFNl bGVjdG9yIHByb2Nlc3NpbmcgKGlucHV0IGlzIHN5c2xvZyBtZXNzYWdlKToNCiAgICANCiAgICAg ICAgICAgMS4gTG9vcCB0aHJvdWdoIGZhY2lsaXR5LWxpc3QNCiAgICAgICAgICAgICAgYS4gRmFj aWxpdHkgbWF0Y2ggcHJvY2Vzc2luZyAtIGNvbnRpbnVlIHRvIHRoZSBuZXh0IGVudHJ5IGluDQog ICAgICAgICAgICAgICAgIHRoZSBsaXN0IGlmIG5vIG1hdGNoDQogICAgICAgICAgICAgIGIuIFNl dmVyaXR5IGNvbXBhcmUgcHJvY2Vzc2luZyAtIGNvbnRpbnVlIHRvIHRoZSBuZXh0IGxpc3QNCiAg ICAgICAgICAgICAgICAgZW50cnkgaWYgbm8gbWF0Y2gNCiAgICAgICAgICAgICAgYy4gTWF0Y2gg LSBwcm9jZWVkIHdpdGggdGhlIGFjdGlvbiBhbmQgZXhpdCBmdXJ0aGVyIHByb2Nlc3NpbmcNCiAg ICAgICAgICAgMi4gUHJvY2VzcyBwYXR0ZXJuIG1hdGNoIGlmIHNwZWNpZmllZCBhbmQgaWYgYSBt YXRjaCBwcm9jZWVkIHdpdGgNCiAgICAgICAgICAgICAgdGhlIGFjdGlvbg0KICAgIA0KICAgIElm IEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIGEgbWVzc2FnZSBpcyBwcm9jZXNzZWQgaWYgaXQgbWF0 Y2hlcyBhbnkgb25lDQogICAgZWxlbWVudCBvZiBmYWNpbGl0eS1saXN0IE9SIHRoZSByZWdleHAu ICBJbiB0aGF0IGNhc2UsIEkgdGhpbmsgeW91IGNvdWxkDQogICAgaXQgY2xlYXJlciBieSB3cml0 aW5nIHRoZSBwc2V1ZG9jb2RlIGluIGEgc3R5bGUgdGhhdCBpcyBtb3JlIGZ1bmN0aW9uYWwNCiAg ICB0aGFuIGltcGVyYXRpdmU6DQogICAgDQogICAgICAgQSBzeXNsb2cgbWVzc2FnZSBpcyBwcm9j ZXNzZWQgaWYNCiAgICAgICAgICAgdGhlcmUgaXMgYW4gZWxlbWVudCBvZiBmYWNpbGl0eS1saXN0 IChGLCBTKSB3aGVyZQ0KICAgICAgICAgICAgICAgdGhlIG1lc3NhZ2UgZmFjaWxpdHkgbWF0Y2hl cyBGIChpZiBpdCBpcyBwcmVzZW50KQ0KICAgIAkgICBhbmQgdGhlIG1lc3NhZ2Ugc2V2ZXJpdHkg bWF0Y2hlcyBTIChpZiBpdCBpcyBwcmVzZW50KQ0KICAgICAgICAgICBvciB0aGUgbWVzc2FnZSB0 ZXh0IG1hdGNoZXMgdGhlIHBhdHRlcm4gKGlmIGl0IGlzIHByZXNlbnQpDQogICAgDQogICAgRGFs ZQ0KICAgIA0KDQo= From nobody Mon Mar 13 11:24:08 2017 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 4252F1299E2 for ; Mon, 13 Mar 2017 11:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 3Nd9hOnkYhs7 for ; Mon, 13 Mar 2017 11:24:04 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565921294ED for ; Mon, 13 Mar 2017 11:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1623; q=dns/txt; s=iport; t=1489429444; x=1490639044; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=JXsU5NbJNU1p/HEXKO8U5ZJKvVWuXzT5q0YBZZettP4=; b=m8s4P6M2DPVrpmHf8o6YdILlGiNLhHh7gjQW2sPagLTRqfVrI3OgGiYe 4Xa+GD1B5Eg6BYNCpo1fEkIUZyz1WHD80NdH7MszKFaFWBsnEH+UMdzgc FWz+0/gNqoJzK1Pi/nFeEjdC7KF7BSWV2gszUhh91o60MOZvC/Feu3o87 c=; X-IronPort-AV: E=Sophos;i="5.36,160,1486425600"; d="scan'208";a="692965700" 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; 13 Mar 2017 18:24:02 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2DIO2ru012018; Mon, 13 Mar 2017 18:24:02 GMT To: Martin Bjorklund , acee@cisco.com References: <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> <20170308193434.GA10080@elstar.local> <20170311.224951.2245774412799352894.mbj@tail-f.com> From: Robert Wilton Message-ID: <46dc5cf5-87bc-c77c-0aaa-3b7fb73b7f30@cisco.com> Date: Mon, 13 Mar 2017 18:24:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170311.224951.2245774412799352894.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:24:06 -0000 Hi Martin, It looks like it needs a further tweak to also wrap augments. I just tried (with the latest master off github) and hasn't wrapped the augment line. E.g. module: ietf-if-l3-vlan augment /if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type: +--:(vlan) +--rw vlan +--rw tag* [index] +--rw index uint8 +--rw dot1q-tag +--rw tag-type dot1q-tag-type +--rw vlan-id ieee:vlanid Thanks, Rob On 11/03/2017 21:49, Martin Bjorklund wrote: > "Acee Lindem (acee)" wrote: >> Hi Juergen, >> >> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder" >> > j.schoenwaelder@jacobs-university.de> wrote: >> >>> On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrote: >>>> This way, reader can focus more quickly on the diffs, but also this >>>> likely mimics what happened in reality (start with `pyang -f tree` >>>> and then manually edit from there). What do you think? >>>> >>> Manually edited tree diagrams? I hope not. >> I frequently have to manually edit the pyang-generated trees to get them >> to fit in the xml2rfc output. Is there a work around for this that I don¹t >> know about? > In the latest pyang, I have added --tree-line-length. Use: > > pyang -f -tree --tree-line-length 69 ... > > to fit RFCs. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Mar 13 11:26:26 2017 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 886CD1297E1 for ; Mon, 13 Mar 2017 11:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 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, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DneY39HFdJP for ; Mon, 13 Mar 2017 11:26:23 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 01F95129985 for ; Mon, 13 Mar 2017 11:26:21 -0700 (PDT) Received: (qmail 13321 invoked by uid 0); 13 Mar 2017 18:26:20 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 13 Mar 2017 18:26:20 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id vWSG1u01c2SSUrH01WSKxT; Mon, 13 Mar 2017 12:26:19 -0600 X-Authority-Analysis: v=2.1 cv=Ath9goNP c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=n82M--yd7VDAzOGejUoA:9 a=k5fpyHSxNWXC41-H:21 a=aliCRkFdxawbIyYt:21 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=TSZmLRzkpGLBZRr3r8m8:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6ECGzMWUlhEfLdS9HuI//NdWCoOq7gnmHFNxmOuaelI=; b=ZTZL9H4gIeQb6MWJKG1mdC1AG9 4QfOqjbEUHwTQukBbbAGFIZ4jDwEUAKXMmIq1zOGH3YcQ698A+ESK+31pzkbqkJmyS7T439C5tkeW iffT0Z704AcIR5Vy0LYm18O7e; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:39062 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cnUfg-0003Jh-O0; Mon, 13 Mar 2017 12:26:16 -0600 To: Robert Wilton , netmod@ietf.org, Andy Bierman References: <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> <20170308193434.GA10080@elstar.local> <20170311.224951.2245774412799352894.mbj@tail-f.com> From: Lou Berger Message-ID: <6fe6a732-ccda-a93d-f005-63ec25cebf60@labn.net> Date: Mon, 13 Mar 2017 14:26:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cnUfg-0003Jh-O0 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:39062 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:26:24 -0000 FYI - just slapped together and published: https://tools.ietf.org/html/draft-bjorklund-netmod-yang-tree-diagrams-00 Lou (as contributor) PS I'm happy with the definition being in 6780bis or in a standalone doc (as above), but really think we as a WG need to decide ASAP so as not to hold up 6780bis any further... On 3/13/2017 2:20 PM, Robert Wilton wrote: > Hi Andy, > > Would it make sense to update 6087bis section 4.4 to reference this new > pyang option for generated tree diagrams? > > Thanks, > Rob > > > On 11/03/2017 21:49, Martin Bjorklund wrote: >> "Acee Lindem (acee)" wrote: >>> Hi Juergen, >>> >>> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder" >>> >> j.schoenwaelder@jacobs-university.de> wrote: >>> >>>> On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrote: >>>>> This way, reader can focus more quickly on the diffs, but also this >>>>> likely mimics what happened in reality (start with `pyang -f tree` >>>>> and then manually edit from there). What do you think? >>>>> >>>> Manually edited tree diagrams? I hope not. >>> I frequently have to manually edit the pyang-generated trees to get them >>> to fit in the xml2rfc output. Is there a work around for this that I don¹t >>> know about? >> In the latest pyang, I have added --tree-line-length. Use: >> >> pyang -f -tree --tree-line-length 69 ... >> >> to fit RFCs. >> >> >> /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 Mon Mar 13 11:49:36 2017 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 59A0D129A5B; Mon, 13 Mar 2017 11:49:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943097133.20354.3396712442953752263@ietfa.amsl.com> Date: Mon, 13 Mar 2017 11:49:31 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:49:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : A YANG Data Model for Syslog Configuration Authors : Clyde Wildes Kiran Koushik Filename : draft-ietf-netmod-syslog-model-13.txt Pages : 27 Date : 2017-03-13 Abstract: This document describes a data model for the configuration of syslog. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 11:59:32 2017 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 B90AA129A63 for ; Mon, 13 Mar 2017 11:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cUCwaPeRdpM for ; Mon, 13 Mar 2017 11:59:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 339AC129478 for ; Mon, 13 Mar 2017 11:59:24 -0700 (PDT) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 499761AE0476; Mon, 13 Mar 2017 19:59:23 +0100 (CET) Date: Mon, 13 Mar 2017 19:59:23 +0100 (CET) Message-Id: <20170313.195923.307435181550548168.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <46dc5cf5-87bc-c77c-0aaa-3b7fb73b7f30@cisco.com> References: <20170311.224951.2245774412799352894.mbj@tail-f.com> <46dc5cf5-87bc-c77c-0aaa-3b7fb73b7f30@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:59:26 -0000 Robert Wilton wrote: > Hi Martin, > = > It looks like it needs a further tweak to also wrap augments. I just= > tried (with the latest master off github) and hasn't wrapped the > augment line. Ok. In general, it will not be possible to cover all cases. An example would be if you have a deeply nested module and some long leaf names in the end. In such cases it might be better to split the diagram into many smaller diagrams, using --tree-path and maybe --tree-depth. But this particular case should be possible to handle. I'll have a look. Meanwhile you'll have to tweak this manually. /martin > = > E.g. > = > module: ietf-if-l3-vlan > augment > /if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type= : > +--:(vlan) > +--rw vlan > +--rw tag* [index] > +--rw index uint8 > +--rw dot1q-tag > +--rw tag-type dot1q-tag-type > +--rw vlan-id ieee:vlanid > = > Thanks, > Rob > = > = > On 11/03/2017 21:49, Martin Bjorklund wrote: > > "Acee Lindem (acee)" wrote: > >> Hi Juergen, > >> > >> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder" > >> >> j.schoenwaelder@jacobs-university.de> wrote: > >> > >>> On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrote: > >>>> This way, reader can focus more quickly on the diffs, but also t= his > >>>> likely mimics what happened in reality (start with `pyang -f tre= e` > >>>> and then manually edit from there). What do you think? > >>>> > >>> Manually edited tree diagrams? I hope not. > >> I frequently have to manually edit the pyang-generated trees to ge= t > >> them > >> to fit in the xml2rfc output. Is there a work around for this that= I > >> don=B9t > >> know about? > > In the latest pyang, I have added --tree-line-length. Use: > > > > pyang -f -tree --tree-line-length 69 ... > > > > to fit RFCs. > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > = From nobody Mon Mar 13 12:07:16 2017 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 EA2181299B3 for ; Mon, 13 Mar 2017 12:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 WX4dK_TVDMcc for ; Mon, 13 Mar 2017 12:07:12 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 655F612945C for ; Mon, 13 Mar 2017 12:07:12 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id n11so47740322wma.0 for ; Mon, 13 Mar 2017 12:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IVcC29eVCCAcdZPKN0vWPde3Pb4Ynl4StWkgDO+76Tw=; b=onJBg7b6ygpcKdpU+QZSK/0ERxrP0bDef22r+IVuqBsrH3RADj16uInri+iwbyq1D+ TTByYA4nh5bhrJ9J9gQqWdKVQ+vnvBKl34DsV4AEdRnuS6Ju5Ytu43QYs4STxZm7pzP7 cDxDapuLzez8A0SHO0uIq+RjNYr+22H0Zn62fj0i7MVjpT3B7chQYvXEHARp2GKaHlCc HmRFAPg0sO0NTbQUpvGjHKSBGS8A9SQ4awkmwUQIyOdukefZO31UTzGAS8oLhOD7wGcf CGkHnn2JAGScMglKCrme9GZ/JhUS39BeJVo4b0+9026T7cbLcfRn1TEcR9lDK91Ie8Ii krbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IVcC29eVCCAcdZPKN0vWPde3Pb4Ynl4StWkgDO+76Tw=; b=r2Zv3cTFrGFBiQ7Y+mQox8onrqws+100KbtiOEhewsC2kcv37wAyBv+/rrjuwgsqEy W7mQIxT71F8ynoNPT5poUkBwXr4gEIeAFtVTkgqMRxTK4f2+K++MpJLlKa55eqvB4cXK YeoeMCwTj2xrTxIX6qCQSDDq6KOrfEBpNutLElyYSeR7IStKD+s1/VMSNKg3nhbVPZVW acyRRBNnLGMe6K7r9TSRIM7IFB+fdQh8oZzLWc/WFPJLQXvFiqu6uCKVRGsBWeXqk+B6 fywLYRvX7bPILg7cpjGcPG4I4L67RoNPOUZMJcjxerfoN6f1vtucMyj9pKrTo7iK2O6U 5+0g== X-Gm-Message-State: AFeK/H33au3d821nYsCI6ElmR9o4DML17G3kDTDUMeGsD0DT+6GSJ8HcIaswojTTFIBomQarS6USzHNS9Yg0dQ== X-Received: by 10.28.46.213 with SMTP id u204mr10734068wmu.136.1489432030902; Mon, 13 Mar 2017 12:07:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.166.37 with HTTP; Mon, 13 Mar 2017 12:07:10 -0700 (PDT) In-Reply-To: <6fe6a732-ccda-a93d-f005-63ec25cebf60@labn.net> References: <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> <20170308193434.GA10080@elstar.local> <20170311.224951.2245774412799352894.mbj@tail-f.com> <6fe6a732-ccda-a93d-f005-63ec25cebf60@labn.net> From: Andy Bierman Date: Mon, 13 Mar 2017 12:07:10 -0700 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a11497ace1e92e7054aa16b39 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:07:15 -0000 --001a11497ace1e92e7054aa16b39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 13, 2017 at 11:26 AM, Lou Berger wrote: > FYI - just slapped together and published: > > https://tools.ietf.org/html/draft-bjorklund-netmod-yang-tree-diagrams-00 > > Lou > > (as contributor) > > PS I'm happy with the definition being in 6780bis or in a standalone doc > (as above), but really think we as a WG need to decide ASAP so as not to > hold up 6780bis any further... > > > standalone doc is fine. does this mean the contents of the tree diagram and the syntax for the tree diagram are subject to WG consensus? Andy > On 3/13/2017 2:20 PM, Robert Wilton wrote: > > Hi Andy, > > > > Would it make sense to update 6087bis section 4.4 to reference this new > > pyang option for generated tree diagrams? > > > > Thanks, > > Rob > > > > > > On 11/03/2017 21:49, Martin Bjorklund wrote: > >> "Acee Lindem (acee)" wrote: > >>> Hi Juergen, > >>> > >>> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder" > >>> >>> j.schoenwaelder@jacobs-university.de> wrote: > >>> > >>>> On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrote: > >>>>> This way, reader can focus more quickly on the diffs, but also this > >>>>> likely mimics what happened in reality (start with `pyang -f tree` > >>>>> and then manually edit from there). What do you think? > >>>>> > >>>> Manually edited tree diagrams? I hope not. > >>> I frequently have to manually edit the pyang-generated trees to get > them > >>> to fit in the xml2rfc output. Is there a work around for this that I > don=C2=B9t > >>> know about? > >> In the latest pyang, I have added --tree-line-length. Use: > >> > >> pyang -f -tree --tree-line-length 69 ... > >> > >> to fit RFCs. > >> > >> > >> /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 > > > > --001a11497ace1e92e7054aa16b39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 13, 2017 at 11:26 AM, Lou Berger <lberger@labn.net><= /span> wrote:
FYI - just slapped together= and published:

https://tools.ietf.org/html/= draft-bjorklund-netmod-yang-tree-diagrams-00

Lou

(as contributor)

PS I'm happy with the definition being in 6780bis or in a standalone do= c
(as above), but really think we as a WG need to decide ASAP so as not to hold up 6780bis any further...




standalone doc is fine.=

does this mean the contents of the tree diagram a= nd the syntax for the
tree diagram are subject to WG consensus?


Andy
=C2=A0
On 3/13/2017 2:20 PM, Robert Wilton wrote:
> Hi Andy,
>
> Would it make sense to update 6087bis section 4.4 to reference this ne= w
> pyang option for generated tree diagrams?
>
> Thanks,
> Rob
>
>
> On 11/03/2017 21:49, Martin Bjorklund wrote:
>> "Acee Lindem (acee)" <acee@cisco.com> wrote:
>>> Hi Juergen,
>>>
>>> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwa= elder"
>>> <netmod-bounces@= ietf.org on behalf of
>>> j.scho= enwaelder@jacobs-university.de> wrote:
>>>
>>>> On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrot= e:
>>>>> This way, reader can focus more quickly on the diffs, = but also this
>>>>> likely mimics what happened in reality (start with `py= ang -f tree`
>>>>> and then manually edit from there).=C2=A0 What do you = think?
>>>>>
>>>> Manually edited tree diagrams? I hope not.
>>> I frequently have to manually edit the pyang-generated trees t= o get them
>>> to fit in the xml2rfc output. Is there a work around for this = that I don=C2=B9t
>>> know about?
>> In the latest pyang, I have added --tree-line-length.=C2=A0 Use: >>
>>=C2=A0 =C2=A0 pyang -f -tree --tree-line-length 69 ...
>>
>> to fit RFCs.
>>
>>
>> /martin
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netm= od
>> .
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


--001a11497ace1e92e7054aa16b39-- From nobody Mon Mar 13 12:10:56 2017 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 5408D129AC2 for ; Mon, 13 Mar 2017 12:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 KzvgfkeDsKjZ for ; Mon, 13 Mar 2017 12:10:44 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF01912945C for ; Mon, 13 Mar 2017 12:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9818; q=dns/txt; s=iport; t=1489432243; x=1490641843; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=wIy1jGZ80akkrCksiZUSMruLv2KTq8bZB4lyoCMGUyM=; b=jbdqJTf8oqsRah0aDH6VaIXdfe/E8n/GU33FVYx9OWyNlUzFqWdD48Yw 1LuLTYFrRAJy4bsvvKqQpR+tB6r6uY+LKzleTVdPquAtu84ItbW222JQa Gi8wT8EapcaE7J6Zvqwa2jsbEQn3qWMn415gYnFiXtzOjWo39mWdBiIYd U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AgDy7cZY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqYINgig5zkD8fkA6FLYIOHwEMhSxKAoMhGAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEBASFLCxALEAgnAwICJx8RBgEMBgIBAYl0CA6uDYImK4otAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWGToIFCIJih1qCXwWWAIZBhnaLQ4F7iFeGU4h?= =?us-ascii?q?FgnCIDh84gQQjFggXFUGEHoI5QDWJYgEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,160,1486425600"; d="scan'208,217";a="651424789" 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; 13 Mar 2017 19:10:40 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2DJAeVO022917; Mon, 13 Mar 2017 19:10:40 GMT To: Andy Bierman , Lou Berger References: <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> <20170308193434.GA10080@elstar.local> <20170311.224951.2245774412799352894.mbj@tail-f.com> <6fe6a732-ccda-a93d-f005-63ec25cebf60@labn.net> From: Robert Wilton Message-ID: <461f2c01-9324-7d4f-6774-374e9fb09851@cisco.com> Date: Mon, 13 Mar 2017 19:10:40 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E79E67D9D5E770098BE22047" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:10:46 -0000 This is a multi-part message in MIME format. --------------E79E67D9D5E770098BE22047 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 13/03/2017 19:07, Andy Bierman wrote: > > > On Mon, Mar 13, 2017 at 11:26 AM, Lou Berger > wrote: > > FYI - just slapped together and published: > > https://tools.ietf.org/html/draft-bjorklund-netmod-yang-tree-diagrams-00 > > > Lou > > (as contributor) > > PS I'm happy with the definition being in 6780bis or in a > standalone doc > (as above), but really think we as a WG need to decide ASAP so as > not to > hold up 6780bis any further... > > > > > standalone doc is fine. > > does this mean the contents of the tree diagram and the syntax for the > tree diagram are subject to WG consensus? That would seem to make sense, given that they are used in all drafts describing YANG models. Rob > > > Andy > > On 3/13/2017 2:20 PM, Robert Wilton wrote: > > Hi Andy, > > > > Would it make sense to update 6087bis section 4.4 to reference > this new > > pyang option for generated tree diagrams? > > > > Thanks, > > Rob > > > > > > On 11/03/2017 21:49, Martin Bjorklund wrote: > >> "Acee Lindem (acee)" > > wrote: > >>> Hi Juergen, > >>> > >>> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder" > >>> on > behalf of > >>> j.schoenwaelder@jacobs-university.de > > wrote: > >>> > >>>> On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrote: > >>>>> This way, reader can focus more quickly on the diffs, but > also this > >>>>> likely mimics what happened in reality (start with `pyang -f > tree` > >>>>> and then manually edit from there). What do you think? > >>>>> > >>>> Manually edited tree diagrams? I hope not. > >>> I frequently have to manually edit the pyang-generated trees > to get them > >>> to fit in the xml2rfc output. Is there a work around for this > that I don¹t > >>> know about? > >> In the latest pyang, I have added --tree-line-length. Use: > >> > >> pyang -f -tree --tree-line-length 69 ... > >> > >> to fit RFCs. > >> > >> > >> /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 > > > > > --------------E79E67D9D5E770098BE22047 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 13/03/2017 19:07, Andy Bierman wrote:


On Mon, Mar 13, 2017 at 11:26 AM, Lou Berger <lberger@labn.net> wrote:
FYI - just slapped together and published:

https://tools.ietf.org/html/draft-bjorklund-netmod-yang-tree-diagrams-00

Lou

(as contributor)

PS I'm happy with the definition being in 6780bis or in a standalone doc
(as above), but really think we as a WG need to decide ASAP so as not to
hold up 6780bis any further...




standalone doc is fine.

does this mean the contents of the tree diagram and the syntax for the
tree diagram are subject to WG consensus?
That would seem to make sense, given that they are used in all drafts describing YANG models.

Rob




Andy
 
On 3/13/2017 2:20 PM, Robert Wilton wrote:
> Hi Andy,
>
> Would it make sense to update 6087bis section 4.4 to reference this new
> pyang option for generated tree diagrams?
>
> Thanks,
> Rob
>
>
> On 11/03/2017 21:49, Martin Bjorklund wrote:
>> "Acee Lindem (acee)" <acee@cisco.com> wrote:
>>> Hi Juergen,
>>>
>>> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder"
>>> <netmod-bounces@ietf.org on behalf of
>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>
>>>> On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrote:
>>>>> This way, reader can focus more quickly on the diffs, but also this
>>>>> likely mimics what happened in reality (start with `pyang -f tree`
>>>>> and then manually edit from there).  What do you think?
>>>>>
>>>> Manually edited tree diagrams? I hope not.
>>> I frequently have to manually edit the pyang-generated trees to get them
>>> to fit in the xml2rfc output. Is there a work around for this that I don¹t
>>> know about?
>> In the latest pyang, I have added --tree-line-length.  Use:
>>
>>    pyang -f -tree --tree-line-length 69 ...
>>
>> to fit RFCs.
>>
>>
>> /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
>



--------------E79E67D9D5E770098BE22047-- From nobody Mon Mar 13 12:27:43 2017 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 7A03F129481 for ; Mon, 13 Mar 2017 12:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 3hwsT6oZJp6C for ; Mon, 13 Mar 2017 12:27:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD2F1299F3 for ; Mon, 13 Mar 2017 12:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3042; q=dns/txt; s=iport; t=1489433259; x=1490642859; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=E/j+8i0xDMh3uiCYKwdGElDiNPe4REzX6RsYd5Fgkmc=; b=dWSO82ENvL/NnPxFduM0gXVW9Jd++NSOZ1Rv2x3eKYtz6niKvK8NjWba dQCD8K1wOTUbCWTVN9X2Uk/6MsbtTKDWRC6RXbT0IIwLXIZ74NOJWb9Jz PIBgWUrL3kpduvTcrrFfOKsIw/57c5mFl2zaLLohR6RGmvVjub6x4hHup g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQDi8cZY/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1mKDqcMgg4fC4UuSgIagkg/GAECAQEBAQEBAWsdC4U?= =?us-ascii?q?WAgEDAQEhETobAgEIGgImAgICJQsVEAIEE4oADq4SgiaKWQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2BC4VDggWCaoMXgT2DBi6CMQWcQQGGdYtDgXtUhFGKBYhFin0?= =?us-ascii?q?BHzg+RlgVGCkRAYZFdYhVAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.36,160,1486425600"; d="scan'208";a="219826138" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2017 19:27:38 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v2DJRc8X019375 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Mar 2017 19:27:38 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Mar 2017 14:27:37 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Mon, 13 Mar 2017 14:27:37 -0500 From: "Clyde Wildes (cwildes)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-13.txt Thread-Index: AQHSnCqeWQ/imeMZWkiuCy3SJLlnlKGTBeKA Date: Mon, 13 Mar 2017 19:27:37 +0000 Message-ID: <1638B372-79F0-4AF4-A4B0-0D2008BCC81D@cisco.com> References: <148943097133.20354.3396712442953752263@ietfa.amsl.com> In-Reply-To: <148943097133.20354.3396712442953752263@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.146.253] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:27:40 -0000 SGksDQoNCkluIHRoaXMgcmV2aXNpb24gb2YgdGhlIGRyYWZ0IHB1Ymxpc2hlZCB0b2RheToNCg0K MS4gVXBkYXRlIEtpcmFu4oCZcyBjb250YWN0IGluZm8uDQoyLiBJbmNvcnBvcmF0ZSBBbmR54oCZ cyBmZWVkYmFjayBmcm9tIDIvMjEvMTc6IG1pbm9yIGNoYW5nZXMuDQozLiBJbmNvcnBvcmF0ZSBL ZW504oCZcyBmZWVkYmFjayBmcm9tIDIvMjIvMTc6IG1pbm9yIGNoYW5nZXM7IGNoYW5nZSBmcm9t IHR3byBtb2RlbHMgdG8gb25lIG1vZGVsLg0KNC4gSW5jb3Jwb3JhdGUgQWxleOKAmXMgZmVlZGJh Y2sgZnJvbSAyLzIzLzE3OiBwcmVmaXhpbmcgbWF4LWRlbGF5LCBudW1iZXItcmVzZW5kcywgcmVz ZW5kLWRlbGF5LCBhbmQgcmVzZW5kLWNvdW50IHdpdGjigJxzaWct4oCcLiANCjUuIEluY29ycG9y YXRlIFRvbSBQZXRjaOKAmXMgZmVlZGJhY2sgZnJvbSAzLzEvMTc6IHRoZSBleHBsYW5hdGlvbiBv ZiB0aGUgWUFORyB0cmVlIGRpYWdyYW0gaXMgbm90IHRoYXQgaW4gUkZDNjA4N2JpczsgY29uZnVz aW9uIG9uIHRoZSB2YXJpYXRpb24gaW4gdGhlIHJlZmVyZW5jZXMgdG8gUkZDIGluIHRoZSBtb2R1 bGVzLg0KNi4gSW5jb3Jwb3JhdGUgRGFsZeKAmXMgZmVlZGJhY2sgZnJvbSAzLzYvMTc6IHN1Z2dl c3Rpb24gcmVnYXJkaW5nIHBzZXVkb2NvZGUuDQoNClRoYW5rcywNCg0KQ2x5ZGUNCg0KT24gMy8x My8xNywgMTE6NDkgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0K ICAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5FVENPTkYgRGF0YSBNb2RlbGlu ZyBMYW5ndWFnZSBvZiB0aGUgSUVURi4NCiAgICANCiAgICAgICAgICAgIFRpdGxlICAgICAgICAg ICA6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBTeXNsb2cgQ29uZmlndXJhdGlvbg0KICAgICAgICAg ICAgQXV0aG9ycyAgICAgICAgIDogQ2x5ZGUgV2lsZGVzDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBLaXJhbiBLb3VzaGlrDQogICAgCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYt bmV0bW9kLXN5c2xvZy1tb2RlbC0xMy50eHQNCiAgICAJUGFnZXMgICAgICAgICAgIDogMjcNCiAg ICAJRGF0ZSAgICAgICAgICAgIDogMjAxNy0wMy0xMw0KICAgIA0KICAgIEFic3RyYWN0Og0KICAg ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgZGF0YSBtb2RlbCBmb3IgdGhlIGNvbmZpZ3Vy YXRpb24gb2Ygc3lzbG9nLg0KICAgIA0KICAgIA0KICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0 YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC8NCiAgICANCiAgICBUaGVy ZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTEzDQogICAg DQogICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldG1vZC1z eXNsb2ctbW9kZWwtMTMNCiAgICANCiAgICANCiAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAg dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCiAgICANCiAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICAgIG5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICBuZXRtb2RAaWV0Zi5vcmcNCiAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgIA0KDQo= From nobody Mon Mar 13 12:38:34 2017 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 673B0129ACF; Mon, 13 Mar 2017 12:38:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943391240.20421.7015046968650807465@ietfa.amsl.com> Date: Mon, 13 Mar 2017 12:38:32 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:38:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : Sub-interface VLAN YANG Data Models Authors : Robert Wilton David Ball Tapraj Singh Selvakumar Sivaraj Filename : draft-ietf-netmod-sub-intf-vlan-model-01.txt Pages : 27 Date : 2017-03-13 Abstract: This document defines YANG modules to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. These modules allow configuration of Layer 3 and Layer 2 sub-interfaces (e.g. attachment circuits) that can interoperate with IETF based forwarding protocols; such as IP and L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The sub-interfaces also interoperate with VLAN tagged traffic orginating from an IEEE 802.1Q compliant bridge. Primarily the classification is based on VLAN identifiers in the 802.1Q VLAN tags, but the model also has support for matching on some other layer 2 frame header fields and is designed to be extensible to match on other arbitrary header fields. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of an 802.1Q VLAN bridge. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-sub-intf-vlan-model-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 12:45:48 2017 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 5125B129481 for ; Mon, 13 Mar 2017 12:45:47 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrP18zyhGe-S for ; Mon, 13 Mar 2017 12:45:45 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id D8B33129406 for ; Mon, 13 Mar 2017 12:45:45 -0700 (PDT) Received: (qmail 29729 invoked by uid 0); 13 Mar 2017 19:45:42 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 13 Mar 2017 19:45:42 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id vXle1u00G2SSUrH01XlhFZ; Mon, 13 Mar 2017 13:45:41 -0600 X-Authority-Analysis: v=2.1 cv=R4+QR7hX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=TtM8FXedt-gQiNVzpRsA:9 a=TAPHHp55TXsM_zhz:21 a=fzss5xWRLZ4kHxM5:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=TSZmLRzkpGLBZRr3r8m8:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2UYQAm6nwaMUawC5eb0Kt6NRejDDe+j0lM+mhUzYI6Y=; b=g42Ht5Pee6bomdR76tLaRvgght l2wP8sPg0dQvmuXX5lCZsPaks8isaN9aCJUlbv2R8fF2Fz4VQPXC98UfoqP/73D8971b/A4sljELj XpIM+v/TmsTFZYCRkPZZ8IuDQ; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:40332 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cnVuU-00005W-0v; Mon, 13 Mar 2017 13:45:38 -0600 To: Andy Bierman References: <271CED23-8655-45A8-8E05-3ABD460871BD@juniper.net> <20170308193434.GA10080@elstar.local> <20170311.224951.2245774412799352894.mbj@tail-f.com> <6fe6a732-ccda-a93d-f005-63ec25cebf60@labn.net> From: Lou Berger Message-ID: <55b700f1-576c-1544-7e9c-56799a08dcb3@labn.net> Date: Mon, 13 Mar 2017 15:45:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cnVuU-00005W-0v X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:40332 X-Source-Auth: lberger@labn.net X-Email-Count: 8 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] stable reference for tree diagram notation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:45:47 -0000 Andy, On 3/13/2017 3:07 PM, Andy Bierman wrote: > > > On Mon, Mar 13, 2017 at 11:26 AM, Lou Berger > wrote: > > FYI - just slapped together and published: > > https://tools.ietf.org/html/draft-bjorklund-netmod-yang-tree-diagrams-00 > > > Lou > > (as contributor) > > PS I'm happy with the definition being in 6780bis or in a > standalone doc > (as above), but really think we as a WG need to decide ASAP so as > not to > hold up 6780bis any further... > > > > > standalone doc is fine. > > does this mean the contents of the tree diagram and the syntax for the > tree diagram are subject to WG consensus? > As contained in RFCs - I would think so. As available from tools -- This is for the tools author IMO. Lou > > Andy > > > On 3/13/2017 2:20 PM, Robert Wilton wrote: > > Hi Andy, > > > > Would it make sense to update 6087bis section 4.4 to reference > this new > > pyang option for generated tree diagrams? > > > > Thanks, > > Rob > > > > > > On 11/03/2017 21:49, Martin Bjorklund wrote: > >> "Acee Lindem (acee)" > > wrote: > >>> Hi Juergen, > >>> > >>> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder" > >>> on > behalf of > >>> j.schoenwaelder@jacobs-university.de > > wrote: > >>> > >>>> On Wed, Mar 08, 2017 at 06:56:20PM +0000, Kent Watsen wrote: > >>>>> This way, reader can focus more quickly on the diffs, but > also this > >>>>> likely mimics what happened in reality (start with `pyang -f > tree` > >>>>> and then manually edit from there). What do you think? > >>>>> > >>>> Manually edited tree diagrams? I hope not. > >>> I frequently have to manually edit the pyang-generated trees > to get them > >>> to fit in the xml2rfc output. Is there a work around for this > that I don¹t > >>> know about? > >> In the latest pyang, I have added --tree-line-length. Use: > >> > >> pyang -f -tree --tree-line-length 69 ... > >> > >> to fit RFCs. > >> > >> > >> /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 Mon Mar 13 14:25:36 2017 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 B49DC129A59 for ; Mon, 13 Mar 2017 14:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 HE1QH_XC7L5P for ; Mon, 13 Mar 2017 14:25:33 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCAF1293DC for ; Mon, 13 Mar 2017 14:25:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5A272735 for ; Mon, 13 Mar 2017 22:25:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xZTETvJ9Tgsj for ; Mon, 13 Mar 2017 22:25:31 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 13 Mar 2017 22:25:32 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20A892003C for ; Mon, 13 Mar 2017 22:25:32 +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 KVCTGGB0ltE0; Mon, 13 Mar 2017 22:25:31 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC9182003B; Mon, 13 Mar 2017 22:25:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 387183EBA8FA; Mon, 13 Mar 2017 22:25:37 +0100 (CET) Date: Mon, 13 Mar 2017 22:25:37 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20170313212537.GB53972@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:25:34 -0000 Hi, this came up during IESG processing of a YANG module - is there a new security guideline boilerplate text covering RESTCONF? This was briefly discussed on the yang-doctors but somehow the discussion stopped because RESTCONF was not published yet at that time. I think this affects draft-ietf-netmod-rfc6087bis-12.txt. draft-ietf-netmod-rfc6087bis-12.txt has several pointers to read online documents - why do we need several points? I think some are also not working. Ideally, there should be a single stable URL. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 13 14:51:52 2017 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 DAA18129BB4; Mon, 13 Mar 2017 14:51:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944191086.20405.12127664510229651631@ietfa.amsl.com> Date: Mon, 13 Mar 2017 14:51:50 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:51:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : Network Management Datastore Architecture Authors : Martin Bjorklund Juergen Schoenwaelder Phil Shafer Kent Watsen Rob Wilton Filename : draft-ietf-netmod-revised-datastores-01.txt Pages : 44 Date : 2017-03-13 Abstract: Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as NETCONF and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-01 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 Mar 14 07:26:03 2017 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 7ED8312FF53 for ; Tue, 14 Mar 2017 07:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PG4otGh7rCAH for ; Tue, 14 Mar 2017 07:25:21 -0700 (PDT) Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [63.128.21.128]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D6D12FF59 for ; Tue, 14 Mar 2017 07:25:20 -0700 (PDT) Received: from ex-hc2.corp.adtran.com (ex-hc3.adtran.com [76.164.174.83]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-156-2sc7N-_0PQi7dgOHNmGgCg-1; Tue, 14 Mar 2017 10:25:17 -0400 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 09:25:16 -0500 From: JOEY BOYD To: "'netmod@ietf.org'" Thread-Topic: augment and if-feature Thread-Index: AdKczsxhgAE7MoK8QX+MSXhvQgcZPg== Date: Tue, 14 Mar 2017 14:25:15 +0000 Message-ID: <26CE489EF4611643B3EFE43D06E02654015E6596C7@ex-mb1.corp.adtran.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.108.75] MIME-Version: 1.0 X-MC-Unique: 2sc7N-_0PQi7dgOHNmGgCg-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 14:25:23 -0000 Hi all, An issue arose recently where a certain tool failed to build the schema tre= e when a feature was turned off. The problem was that an augmenting module = did not have the same if-feature statement as the node being augmented. For= example, I have these two modules. module base-module { prefix bmod; feature do-things; container things { if-feature do-things; ... } } module augment-module { prefix amod; augment "/bmod:do-things" { container other-things { } } } If I included both modules and turned off the feature, 'do-things', the too= l would complain that the node being augmented did not exist. Forgetting th= e obvious solution of not including the augmenting module if you don't supp= ort the feature (this is a very simplified example), my thought was that th= e schema tree should first be built including all augments, then the featur= e is applied. What are your thoughts on this? Surely, an augment should not have to conta= in if-feature statements of all parents of the augmented node. Best regards, Joey From nobody Tue Mar 14 08:33:56 2017 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 8A6171294F5 for ; Tue, 14 Mar 2017 08:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 sfFbZMvEs0jZ for ; Tue, 14 Mar 2017 08:33:52 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBCF129421 for ; Tue, 14 Mar 2017 08:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6424; q=dns/txt; s=iport; t=1489505632; x=1490715232; h=from:subject:to:message-id:date:mime-version; bh=AKV3QEicdcTk1pyKnaDIfyP9RPYlda+I4QHjOoAofW4=; b=eOe5xeWTGMFKcnb2SPEXo/YN6ogQ7EWi2utdqwJ85Kw5sUAVwlh+0n8C DiaAcZ0wA+n6nMcxw/Wr3o6Bs/Vr8MMjmkRC3VAF9WegRa8cmkWihhu+R 4ugqFQVU+tMRjRgZT7WFBt4oAUu+ajgZS4dXcmV6e694uY6UfAosw+/Rd E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzBADiC8hY/xbLJq1dHAEBBAEBCgEBh?= =?us-ascii?q?DIqYINgig1zoHCDHoIPgg4qiRAYAQIBAQEBAQEBayiFP29EAl8NCAEBiXwOj0W?= =?us-ascii?q?NVY5XD4EggiYrijgMJoZOggWHEBEBgyKCXwWGaZVahnaGTYR4gk+IA4ZTiziDb?= =?us-ascii?q?YQiHzh8CCMWCBcVhxk/NYZ3DRcHghABAQE?= X-IronPort-AV: E=Sophos;i="5.36,164,1486425600"; d="scan'208,217";a="653267615" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 15:33:49 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2EFXnj5028193 for ; Tue, 14 Mar 2017 15:33:49 GMT From: Benoit Claise To: NETMOD Working Group Message-ID: <8378cd03-e74e-c6c0-e978-f1f7be2975ee@cisco.com> Date: Tue, 14 Mar 2017 16:33:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B42B0AB6935BC3074CF29FD8" Archived-At: Subject: [netmod] Posting YANG modules: different tool chains, different results X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 15:33:54 -0000 This is a multi-part message in MIME format. --------------B42B0AB6935BC3074CF29FD8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, I've been spending much time the last days, running my scripts multiple times per day, and informing authors about errors/warnings from my reports . Let me hope it made a difference ! There are multiple tools out there, which might produce different results. And that generated some questions/concerns recently: why do I get this error on the yangvalidator.org? I didn't get any warnings from the idnits? How come that you have different errors in your reports? So let me explain the situation. 1. We added pyang to the submission tool during one of the previous IETF hackathons. Note that pyang doesn't check xpath Yes, we might have some caching issue here when people submit multiple interdependent drafts the same day, typically the last day before the deadline. Reason: when a new draft is posted with a YANG module, it validates the new YANG module based on the YANG modules it knows from the previous day. 2. yangvalidator.org is a best effort tool maintained by Carl Moberg. And yes, we could have some caching issue here too. Same reason as above. However, you can load multiple drafts or YANG modules for validation. Radek will be adding yanglint to the yangvalidator.org during this coming hackathon. Note that yanglint validates xpath. 3. The right way to do it is: - start from scratch, - download all the drafts, - extract all YANG models (and correct the extraction issues/warn the authors) - include all the RFC YANG modules, and the other YANG modules (IEEE, openconfig, etc.) that might be needed - validate all these YANG modules with 4 validators (2 opensource, 2 commercial) that you obviously need to keep up to date - report bugs to the different validators. - keep the validators up to date - report issues to the authors to fix their YANG modules while keeping in mind the different validator issue (ex: this output warning from validator X is a bug and will be solved soon, so don't pay attention to it) - wash ... rinse ... repeat All this (I skipped some steps to shorten the email ) is what I do in with my own tool chain to generate my reports (http://www.claise.be/2016/07/ietf-yang-modules-statistiques/), for IETF drafts and github repo. When I see how much time that takes, no wonder that 2 above might not be fully up to date I hope this explains the situation, and that you get a good service for what you pay for. :-) See you at the next hackathon to improve those tools. Regards, Benoit --------------B42B0AB6935BC3074CF29FD8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

I've been spending much time the last days, running my scripts multiple times per day, and informing authors about errors/warnings from my reports.
Let me hope it made a difference!

There are multiple tools out there, which might produce different results.
And that generated some questions/concerns recently: why do I get this error on the yangvalidator.org? I didn't get any warnings from the idnits? How come that you have different errors in your reports?

So let me explain the situation.

1. We added pyang to the submission tool during one of the previous IETF hackathons.
Note that pyang doesn't check xpath
Yes, we might have some caching issue here when people submit multiple interdependent drafts the same day, typically the last day before the deadline.
Reason: when a new draft is posted with a YANG module, it validates the new YANG module based on the YANG modules it knows from the previous day.

2. yangvalidator.org is a best effort tool maintained by Carl Moberg.
And yes, we could have some caching issue here too. Same reason as above.
However, you can load multiple drafts or YANG modules for validation.
Radek will be adding yanglint to the yangvalidator.org during this coming hackathon. Note that yanglint validates xpath.

3. The right way to do it is:
    - start from scratch,
    - download all the drafts,
    - extract all YANG models (and correct the extraction issues/warn the authors)
    - include all the RFC YANG modules, and the other YANG modules (IEEE, openconfig, etc.) that might be needed
    - validate all these YANG modules with 4 validators (2 opensource, 2 commercial) that you obviously need to keep up to date
    - report bugs to the different validators.
    - keep the validators up to date
    - report issues to the authors to fix their YANG modules while keeping in mind the different validator issue
      (ex: this output warning from validator X is a bug and will be solved soon, so don't pay attention to it)
    - wash ... rinse ... repeat
All this (I skipped some steps to shorten the email ) is what I do in with my own tool chain to generate my reports (http://www.claise.be/2016/07/ietf-yang-modules-statistiques/), for IETF drafts and github repo. When I see how much time that takes, no wonder that 2 above might not be fully up to date

I hope this explains the situation, and that you get a good service for what you pay for. :-)

See you at the next hackathon to improve those tools.

Regards, Benoit

--------------B42B0AB6935BC3074CF29FD8-- From nobody Tue Mar 14 10:39:55 2017 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 29CF1129892 for ; Tue, 14 Mar 2017 10:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 aUkOO_EyV-4W for ; Tue, 14 Mar 2017 10:39:53 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 07F93129499 for ; Tue, 14 Mar 2017 10:39:52 -0700 (PDT) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 007711AE018C; Tue, 14 Mar 2017 18:39:50 +0100 (CET) Date: Tue, 14 Mar 2017 18:39:50 +0100 (CET) Message-Id: <20170314.183950.1234657423841109832.mbj@tail-f.com> To: joey.boyd@adtran.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <26CE489EF4611643B3EFE43D06E02654015E6596C7@ex-mb1.corp.adtran.com> References: <26CE489EF4611643B3EFE43D06E02654015E6596C7@ex-mb1.corp.adtran.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] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 17:39:54 -0000 Hi, JOEY BOYD wrote: > Hi all, > > An issue arose recently where a certain tool failed to build the > schema tree when a feature was turned off. The problem was that an > augmenting module did not have the same if-feature statement as the > node being augmented. For example, I have these two modules. > > module base-module { > prefix bmod; > > feature do-things; > > container things { > if-feature do-things; > ... > } > } > > module augment-module { > prefix amod; > > augment "/bmod:do-things" { > container other-things { > } > } > } > > If I included both modules and turned off the feature, 'do-things', > the tool would complain that the node being augmented did not > exist. Forgetting the obvious solution of not including the augmenting > module if you don't support the feature (this is a very simplified > example), my thought was that the schema tree should first be built > including all augments, then the feature is applied. > > What are your thoughts on this? Surely, an augment should not have to > contain if-feature statements of all parents of the augmented node. The spec says: When a server implements a module containing an "augment" statement, that implies that the server's implementation of the augmented module contains the additional nodes. Compare with a simple augment of a node w/o an if-feature. In this case, if the server implements the augmenting module, it MUST also implement the augmented module. /martin From nobody Tue Mar 14 11:21:24 2017 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 51911127020 for ; Tue, 14 Mar 2017 11:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzHXs2vB7Zor for ; Tue, 14 Mar 2017 11:21:20 -0700 (PDT) Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [216.205.24.128]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085CB12777E for ; Tue, 14 Mar 2017 11:21:19 -0700 (PDT) Received: from ex-hc2.corp.adtran.com (ex-hc3.adtran.com [76.164.174.83]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-41-CrO7Rgu5NR6gu6DvDg6b6A-1; Tue, 14 Mar 2017 14:21:17 -0400 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 13:21:15 -0500 From: JOEY BOYD To: 'Martin Bjorklund' CC: "netmod@ietf.org" Thread-Topic: [netmod] augment and if-feature Thread-Index: AdKczsxhgAE7MoK8QX+MSXhvQgcZPgARRd4AAAlB/MA= Date: Tue, 14 Mar 2017 18:21:15 +0000 Message-ID: <26CE489EF4611643B3EFE43D06E02654015E659C11@ex-mb1.corp.adtran.com> References: <26CE489EF4611643B3EFE43D06E02654015E6596C7@ex-mb1.corp.adtran.com> <20170314.183950.1234657423841109832.mbj@tail-f.com> In-Reply-To: <20170314.183950.1234657423841109832.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.108.75] MIME-Version: 1.0 X-MC-Unique: CrO7Rgu5NR6gu6DvDg6b6A-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 18:21:22 -0000 What about this scenario? module base-module { prefix bmod; feature things; feature widgets; container things { if-feature things; ... container widgets { if-feature widgets; ... } } } =20 module augment-module { prefix amod; augment "/bmod:things" { container other-things { } } augment "/bmod:widgets" { container other-widgets { } } } At some point, a product wants to implement the base-module and the augment= -module but does not support 'widgets'. How should this be handled? I reali= ze that ideally you would have an augment module for things and another for= widgets but let's say that is not the case and you are left with the above= . The question then is does the augment need to be conditional via the same= feature or does it implicitly inherit the feature of the augmented node? Regards, Joey -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Tuesday, March 14, 2017 12:40 PM To: JOEY BOYD Cc: netmod@ietf.org Subject: Re: [netmod] augment and if-feature Hi, JOEY BOYD wrote: > Hi all, >=20 > An issue arose recently where a certain tool failed to build the=20 > schema tree when a feature was turned off. The problem was that an=20 > augmenting module did not have the same if-feature statement as the=20 > node being augmented. For example, I have these two modules. >=20 > module base-module { > prefix bmod; >=20 > feature do-things; >=20 > container things { > if-feature do-things; > ... > } > } >=20 > module augment-module { > prefix amod; >=20 > augment "/bmod:do-things" { > container other-things { > } > } > } >=20 > If I included both modules and turned off the feature, 'do-things',=20 > the tool would complain that the node being augmented did not exist.=20 > Forgetting the obvious solution of not including the augmenting module=20 > if you don't support the feature (this is a very simplified example),=20 > my thought was that the schema tree should first be built including=20 > all augments, then the feature is applied. >=20 > What are your thoughts on this? Surely, an augment should not have to=20 > contain if-feature statements of all parents of the augmented node. The spec says: When a server implements a module containing an "augment" statement, that implies that the server's implementation of the augmented module contains the additional nodes. Compare with a simple augment of a node w/o an if-feature. In this case, i= f the server implements the augmenting module, it MUST also implement the a= ugmented module. /martin From nobody Tue Mar 14 12:03:46 2017 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 7F4DA129465 for ; Tue, 14 Mar 2017 12:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93Gz0Fg5FWwG for ; Tue, 14 Mar 2017 12:03:36 -0700 (PDT) Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [63.128.21.128]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12EEB1288B8 for ; Tue, 14 Mar 2017 12:03:36 -0700 (PDT) Received: from ex-hc3.corp.adtran.com (ex-hc2.adtran.com [76.164.174.82]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-20-Gse-FpWBPIOMpWZg0MXv6g-1; Tue, 14 Mar 2017 15:03:32 -0400 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 14:03:25 -0500 From: JOEY BOYD To: 'Martin Bjorklund' CC: "'netmod@ietf.org'" Thread-Topic: [netmod] augment and if-feature Thread-Index: AdKczsxhgAE7MoK8QX+MSXhvQgcZPgARRd4AAAlB/MAAENhHwA== Date: Tue, 14 Mar 2017 19:03:25 +0000 Message-ID: <26CE489EF4611643B3EFE43D06E02654015E659C82@ex-mb1.corp.adtran.com> References: <26CE489EF4611643B3EFE43D06E02654015E6596C7@ex-mb1.corp.adtran.com> <20170314.183950.1234657423841109832.mbj@tail-f.com> <26CE489EF4611643B3EFE43D06E02654015E659C11@ex-mb1.corp.adtran.com> In-Reply-To: <26CE489EF4611643B3EFE43D06E02654015E659C11@ex-mb1.corp.adtran.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.108.75] MIME-Version: 1.0 X-MC-Unique: Gse-FpWBPIOMpWZg0MXv6g-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 19:03:44 -0000 Correcting the second augment below. Joey -----Original Message----- From: JOEY BOYD=20 Sent: Tuesday, March 14, 2017 1:21 PM To: 'Martin Bjorklund' Cc: netmod@ietf.org Subject: RE: [netmod] augment and if-feature What about this scenario? module base-module { prefix bmod; feature things; feature widgets; container things { if-feature things; ... container widgets { if-feature widgets; ... } } } =20 module augment-module { prefix amod; augment "/bmod:things" { container other-things { } } augment "/bmod:things/bmod:widgets" { container other-widgets { } } } At some point, a product wants to implement the base-module and the augment= -module but does not support 'widgets'. How should this be handled? I reali= ze that ideally you would have an augment module for things and another for= widgets but let's say that is not the case and you are left with the above= . The question then is does the augment need to be conditional via the same= feature or does it implicitly inherit the feature of the augmented node? Regards, Joey -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Tuesday, March 14, 2017 12:40 PM To: JOEY BOYD Cc: netmod@ietf.org Subject: Re: [netmod] augment and if-feature Hi, JOEY BOYD wrote: > Hi all, >=20 > An issue arose recently where a certain tool failed to build the=20 > schema tree when a feature was turned off. The problem was that an=20 > augmenting module did not have the same if-feature statement as the=20 > node being augmented. For example, I have these two modules. >=20 > module base-module { > prefix bmod; >=20 > feature do-things; >=20 > container things { > if-feature do-things; > ... > } > } >=20 > module augment-module { > prefix amod; >=20 > augment "/bmod:do-things" { > container other-things { > } > } > } >=20 > If I included both modules and turned off the feature, 'do-things',=20 > the tool would complain that the node being augmented did not exist. > Forgetting the obvious solution of not including the augmenting module=20 > if you don't support the feature (this is a very simplified example),=20 > my thought was that the schema tree should first be built including=20 > all augments, then the feature is applied. >=20 > What are your thoughts on this? Surely, an augment should not have to=20 > contain if-feature statements of all parents of the augmented node. The spec says: When a server implements a module containing an "augment" statement, that implies that the server's implementation of the augmented module contains the additional nodes. Compare with a simple augment of a node w/o an if-feature. In this case, i= f the server implements the augmenting module, it MUST also implement the a= ugmented module. /martin From nobody Tue Mar 14 13:15:43 2017 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 896181314B4 for ; Tue, 14 Mar 2017 13:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 38fmWfTwO1lY for ; Tue, 14 Mar 2017 13:15:40 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0138.outbound.protection.outlook.com [104.47.41.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2276D1296F7 for ; Tue, 14 Mar 2017 13:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ujfpok4hT3iE5VDJfTBKIf/7G8FD9DMdZyKj7OzYr9g=; b=WXAlV5RV4AXT8zJ/Pqe68oI/VBy8yTJ35KVUFj+cv1nrHu7loWK21CHCimLpla+sqGQlQyVxWWyi23LOurIL0wYl4XtQ0eY1Sogg+bPrQYs/zv7muK1M6UTYyoi2wgtlDAMdLO/vcktmrCmyUNsvKkea7MPGpEb+UTVu2Dp8gEY= Received: from CO2PR05CA023.namprd05.prod.outlook.com (10.141.241.151) by BY2PR0501MB1750.namprd05.prod.outlook.com (10.163.154.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Tue, 14 Mar 2017 20:15:38 +0000 Received: from BL2FFO11OLC003.protection.gbl (2a01:111:f400:7c09::101) by CO2PR05CA023.outlook.office365.com (2a01:111:e400:1429::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5 via Frontend Transport; Tue, 14 Mar 2017 20:15:38 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11OLC003.mail.protection.outlook.com (10.173.161.187) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.961.10 via Frontend Transport; Tue, 14 Mar 2017 20:15:37 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 14 Mar 2017 13:15:14 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v2EKFDja009491; Tue, 14 Mar 2017 13:15:14 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v2EKB9Cd072710; Tue, 14 Mar 2017 16:11:10 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201703142011.v2EKB9Cd072710@idle.juniper.net> To: Martin Bjorklund CC: , In-Reply-To: <20170314.183950.1234657423841109832.mbj@tail-f.com> Date: Tue, 14 Mar 2017 16:11:09 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39850400002)(39860400002)(39410400002)(39840400002)(2980300002)(189002)(52054003)(199003)(9170700003)(48376002)(6916009)(54356999)(5660300001)(5003940100001)(47776003)(2950100002)(50466002)(7696004)(1076002)(53416004)(2810700001)(2906002)(50986999)(54906002)(77096006)(229853002)(8936002)(305945005)(4326008)(356003)(8276002)(86362001)(106466001)(189998001)(8676002)(81166006)(105596002)(53936002)(6246003)(38730400002)(110136004)(7126002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1750; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC003; 1:1f0+9MDE+mgPZDcxFSV1VfhvoEsTX+Chkj/nwFTsC9QMN1fVIzGvSLSMd7h9pgXCclZqYU4qf5Z1zH0Fcpqpgg/XYJg0shuiEKb6ddH8vzGDeq5V+OVK3pQfZ1oau9prOrQC/s727lLCpVwymu6KFUic1ALAFYazVeCMwd/INVcxZLLkDKpvtL2ZLrsq2kSkHCXQAq9E8xEnDYEvSRRLh/VCklbMpQrFoByakb2/kIKt7/8Tk32WUmsvkjXtEAlGqePFJzCVhcbiQl7t/+L68Kiyx4fARJ+pWtJK/9Kx2tndjdRKObwe1BRX0agnNkHZCijIFEfEef1buYHnQtliAlhMdrI76nZLELor5pL8aQZhY2p/vsgDIbbJwHIjGk2qSh9yJ+oejxKldhYT3EaPBDpQKBOrhJMSwmhwlHiXlTJGjGs3/rgXHV5+Pm6yv8qhxwIw3hHabSsR0Ml/tLvpI5eMdlTtT2iEh84OcHOoN2r5cTNu1P7Q3dNaZ9szAsfRtF5Pt1+K+lGiH5c+IP/ZhED60hRuN2atNmBgwx9U4XZSTn8FlRque2O9lGIynv4DpwksVsxYG0kkgriAP+CgSg== X-MS-Office365-Filtering-Correlation-Id: aae0fc36-318b-442a-bbff-08d46b16e178 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR0501MB1750; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1750; 3:zTkmh53mclM80aDW/hMdWVRhM5g4CKipHSm2jOKqKqlwicjzzeynl/CocQamOtor6iyHwrXwKuSJxYC+Tw43hEGIXUOrHkK1jIbPcGYkdM5l907s3fP0NPDgJkdiBvTpAb3cNzcg02rls4WwF6umbIBT4OgkxWOSAxM4lXiSOuRMVddKQ28KIBupcB6zVjSxPisE6kTungZfpz0vlYdczbbapECCQCM6hKFv5UvD2BOibRcqkijmPnV8hrkETnACFmPZz1jC86JKXKqbaewIQeLhrBL/uyvkGGhRd2cpzb1P0DFV1c41JwpcmJPGIA6f87jiIFbksVNuoqfOlEHQ+rXSOVcN8q8PTOgqE0UMvfR/h81B9ZxQ2ZcvSKKTGhel; 25:0dzzXI09qwRzcYJUuO0WTvsIE3ITxcRVWqplCa1jDThWbYoRI4m00s+LMYQY+vN88UY/JKp83XOQFM4pEWCkeHnyxRJ8uXB1VfbQlacUIoodsLLwZGD53D5Q/TOSbAbzvPjVuDfxc0yEmTrl5OGoIw98YLoN8VM9V75tuDrHJk7XyKp0T4doeyp29+jirk0ZieH3btUu/SmXrGHEFDUaapqHZG6MKtgOtF0AzGyUQBOVNTUQNC/oHb4yD+1dBVhT9bbe27RGAgKkYRmX53E4ueDjjNzUwT4/ptZUZNTgAuQLyLQXESUr3tXwROJyqq/zNXuIt9kpg/xb6c9fukWf+9E9E+ui1m8+7Zp6o2NINaQAdqVaneWkfA+5ikvC98P7QV78Tk94qH+38h/Xo1CVlpV3CE6YwEUQQEeSf7oPmKUziwMmMPRyUeRiIpjJ4F4XKoUmSia8NCg3UwPOlKvzrA== X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1750; 31:fQG5jtRD3Dwv/NdscOjD5LEc0WSUwbuWK7WJE+bsA3f9Amil+ZFiijM4IA0NUgp+gXAfOgxaowY1ZfTLqkoJ4PhthdHaofigrt7r2M7yPyuG2HOXTvy5Paw36ppuU0KbGktF/RIWEwkLy4zmbm2DmYmIhLEf+Vhj1bojFV0sSBX7rSNqG2zKXXIf5iKUYWSZkA5MYAXo7Wl6BjqPWECPhNUHw8nuHe/c+6ryUU6yrUOKWA+3jJwD9sbGeNXimunIc189jFjfRNuEqa/eUStUu6re0RupanQTXpYw6RpnGzk=; 20:0h4GD8UvmaTb/UWAU/NDbasRcb/DNiyLlIsfe9Bs2Ko1keAqZYKACniaKHNnAOugYmL06168kNU4H9MVgXtVUPvEgWAsvKmEiIJMAGwirxpIWICdi9TQcJv9IKQoNOUXpoZWaO5slLKuIOurG2P61ikG808GPj6OeKFPGpmJSZlamUrNZcn5BmjEZi2kbt4MQO/2ewXoQLUpMVyBR4L+tDNBIVFWTOfebvy9kVAyh/gMnj2N40iTjYt7sewiyTffdml1owUcORwPrSO6RTqroa5ML9rVmUKzV7VJ3L9IxPraLEhAL1Khyy27xSSVPYjVSw0W7fqCg6hGkb7TOiCrU2hhk3vNni+KqArYperlalHBdASHRkSlMfOAjclBiu9pzVccT+2w3nABtnobB4zlmSN2zWhf7GR6a418ZT7+SRnGQEnQghB97uGnEr87MiF8ylpy9A8aXsTZLlDmgDkD9whpFOcKlM4Z9e9s5WtkDX2TANolrqTVYOk65u2cnYal X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13015025)(8121501046)(5005006)(13017025)(13018025)(13023025)(13024025)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(6072148); SRVR:BY2PR0501MB1750; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1750; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1750; 4:WR/Tcr21jg9BmvBOOQsVBv9awOinRA5j7fjSCQynEbxoOipQZc6UOvjmnsBFb2iE5D5ngzCIGnHQolEnXiWGWRS+6wneHbXEuqeOZZFxJWDPUfhWklR5hWH7vEyVFmh/kJaIe3p1yw9q1078MtBcGYgd17PyeWKPCnUgAmB+tlAlQqjed242wpCyjyZxACO11dWDgNRhVpaL7SslFnS00Uyph/ZWKvGjRCNBhGnpILDm2HUWbGgCPo1+5D19n0frMjkZJFqXNqugBTwjrW9jeE4pn3NqXwzi25TXtscaSC5DmUYT5B2FXylVX0zAbM/gEkcVCBxusCwcc4ZJ6rmtP/dHYTsXUbD94LTL4/07P/LQ4xRHcS0/LU+T7uoQMgJvGOuRlbnyuGNHAAQqYDKwdAXWqDmkb8w6v6GR16IHcEwAM3EVhPerzkPXsdqohRLXMglmG5TeoM6nA1f494pCWrjJjsTROXPaYHV9ukLhQ05Hr2Eg0yaGIcMJfhomgcXtq10WwZUu85V9+WolyzO6ajwp+4/u7aiVjlkV1ivGUPViy532S03Kgo351ThIZ/N3pKD/zqf22QVSt/01WAK/qON5G86YS7SgCVI8fFTWcPXxBlDjlK7a2f6w45uhK6Z0I8caXYdZxNhDJalSbphr61M65s+y9mwNl689Rj/7Y9up3KA7xyy/G51NFSFtBZFCCvILcobm4xuFSlv4a3Mq1jnC5rK6xukFkrxWrmHadBjOH3UIFS+WerB8ZmJxqB3i0NDNcfcnHxJdWVJm1kQJEg== X-Forefront-PRVS: 02462830BE X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR0501MB1750; 23:RNJ2ojbjUS6A/Kmx0a7reMCkO1yqyZdYFdYYz6G?= =?us-ascii?Q?bAzEAIyhugPi8tmRjdTOySQ+2U4pWo2UeUf3K+3PukhnrmTq9m7GBTYOgFqw?= =?us-ascii?Q?OKefwlTd6wT0XoJ3ESOCCF0map5VpGrUc29eT3M0yQL5j1Gxt4SOcvld4RHV?= =?us-ascii?Q?KBT5AgiDmZUxk3L+mTxbYY9T30OscSBzVO8/G2+o3037s83sLThX6ntYqzlA?= =?us-ascii?Q?sB3uUeMEnMLjwDiEygkjNJWcNtHGSyUV1mgxIBO03avPId/6wqS81+SmznOD?= =?us-ascii?Q?eriLzVhWtWVMJv+3iQ5HPMvpbMbnyPfSTGfhvXKKs3OmEA8jgw4jyeqezfKs?= =?us-ascii?Q?9NXrBuC3RAj7t8zIBOrcQoTeaRZoaB3hD3I5Zhk+w0iGenBBb9OdS5d8+sRT?= =?us-ascii?Q?1LN3Od5veNgIxWENMlgNZ3/rcmqOr9zIk4VJ6V5mPlaYRu0OMXIwAEM90zkL?= =?us-ascii?Q?g8GkcVK7xINZTCjbp1VqAgRf3m6h3oF0mXABsoyESfde3RepdR/L7xQPl8s9?= =?us-ascii?Q?hHRQ+dG82p6YwA2ld3JsBKVDOq37Gn3dqHk9AMBzVIGNYQ8BLktcMRBkFVIx?= =?us-ascii?Q?DdAwn5uZxQjbLVXYqQ31Bl2GBoGMUP2eFC100Q0uZubBWKEzx5KGG/Qxs2dz?= =?us-ascii?Q?QpWDvlq5GEiO0A7C2e0h/kjhdtA15nDXOsy39MSopfBrJzAu98Y3PCIqpa6m?= =?us-ascii?Q?web9OPbRxHcVfpb1ykonh+zvdeXdAErMo3Pxwg7plCNCdiOYWEQ19C1JOmd6?= =?us-ascii?Q?6wZuB0FXpeqLxqIFEzhAADjEqiKkZwkqgmGcKUeWLO8uVLvPN+KsDygUYZy2?= =?us-ascii?Q?ojTh91T7jmnpmLyaxOwpPl1ZdCr7BxDhLEmI8fvzWQW7ejz5bQZ3TLc2nHaC?= =?us-ascii?Q?aak9KvWXiBCuh/PPVWw/3S3ISuj98MjjbLRVHhu63xtm/UkCB50AZkf4BkX+?= =?us-ascii?Q?B/lzZHHvq75EHgWMESwpTuEZtH7bKP2lzqrQS2I6HuUo980xy2mP8+dJKE++?= =?us-ascii?Q?T64IrYtbYr30IF7Kp/uvTvn5JgQBfsfpANuSe+aae3aYyF4RHVVRmQ8Soai9?= =?us-ascii?Q?timLsH/vKAruddt75mFuYlDvl1lctu+1wzAguDQItISFK4/CyKg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1750; 6:/Vnk7+Ou9BtwnVjar55uSgnQzM5US7V9KYt7/g1NLgsigUGlogPn3pkoHSwyFuGxnmRfmS6OHWToOyobzGgysIO0V7S8j1gZHMBcqyK65hmmOQjqlmz4rCl0cV7ENgvvI29oe6aqruu/tW+p4XDPfWjf7oV22lN04klq3geB/oKd39qt5Nj1H5TDD1hikg7YqjIVpn+RYxZ4YzGzVqkLFmyXrnbMZj1nW7oy9XpQfr4VRvTqduEkLE/Wqk4e5qk3IhimuaSzuvEneU6mTWzGPA7IUHXndl7nvjOsii1ONwkzyfnpf6p2TQstlkNi5MwwN4Bkxi5XH28lAU+qHkYjQtUpdaK9cq6ZTS5Te1dnAnIWG2emORg3VGuOzPkX35B+LbzGg1QHMHBL63RBbeqNCS/rCW9fQ+KMTn5XzlTe3wU=; 5:vR1XEUWWjDRluJ7y08+58PXFLBAVEBhrjrNjcvIX5KrW5uD5OfvifWVKJ3G780Fc8UJqjMTlGdionfDhPU24RIWj3gnVx5hkCzWp9qsngkJniqmYhFFkiq1TzSrmIzgaGXuq6TQx17cbcLYLe3OrCw==; 24:DVDhSG0veVBN1Px3M+YXSuIvkDvUBULHxnXw5SFoE9BNs69EGLkCGyvwV9b/oT6frEf1u3thn+inGWg/TbXyXzy5VZsg5AKWA+28UnkSXn4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1750; 7:X+YFdgohObGIVpq0Vk5fy9bPc2ZgA01iC8Yfcf89pE189UsefdrQCps6HAUfNGmo94eytsjRrdscIFsjNd7cOBP0Q1OFwgY3AYeHy8zmzWaoEU4znhuF5+otdEI/X7q2ooWuzRm1tJwlQQwsLgGDsW1Ntk4Y8GfqDJBJQZ1m0BhuOHb97gRQs6rGToMYLeGh6D5J2haW6mnGQQ7Z+1A+2Bm2UXrYFj7T46Xxq0MARt796LbFkZtINPgVUEn+Iosc7Hg1F1MmXqvq9r/vTSlgBhrg9IQC+6HgKb+R+aC9elx3fgFtoP8TQur89FfsAKchZ/AwN0+5xC9ZpbBWoCvtAQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2017 20:15:37.8577 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1750 Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 20:15:41 -0000 Martin Bjorklund writes: >> What are your thoughts on this? Surely, an augment should not have to >> contain if-feature statements of all parents of the augmented node. > >The spec says: > > When a server implements a module containing an "augment" statement, > that implies that the server's implementation of the augmented module > contains the additional nodes. > >Compare with a simple augment of a node w/o an if-feature. In this >case, if the server implements the augmenting module, it MUST also >implement the augmented module. It implements the module, but it doesn't implement the nodes since it doesn't express the feature. IMHO this is a tool bug and/or an errata, since otherwise one has to carry features forward, repeating the if-feature using the original modules prefix:feature-name on every augment of feature-based nodes. Thanks, Phil From nobody Tue Mar 14 13:50:45 2017 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 C25971314F0 for ; Tue, 14 Mar 2017 13:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001, 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 22QxmSMwEILS for ; Tue, 14 Mar 2017 13:50:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 70CFD1314E9 for ; Tue, 14 Mar 2017 13:50:43 -0700 (PDT) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 61DB61AE018C; Tue, 14 Mar 2017 21:50:41 +0100 (CET) Date: Tue, 14 Mar 2017 21:50:41 +0100 (CET) Message-Id: <20170314.215041.1542757804066431921.mbj@tail-f.com> To: phil@juniper.net Cc: joey.boyd@adtran.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <201703142011.v2EKB9Cd072710@idle.juniper.net> References: <20170314.183950.1234657423841109832.mbj@tail-f.com> <201703142011.v2EKB9Cd072710@idle.juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 20:50:45 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >> What are your thoughts on this? Surely, an augment should not have to > >> contain if-feature statements of all parents of the augmented node. > > > >The spec says: > > > > When a server implements a module containing an "augment" statement, > > that implies that the server's implementation of the augmented module > > contains the additional nodes. > > > >Compare with a simple augment of a node w/o an if-feature. In this > >case, if the server implements the augmenting module, it MUST also > >implement the augmented module. > > It implements the module, but it doesn't implement the nodes > since it doesn't express the feature. IMHO this is a tool > bug and/or an errata,since otherwise one has to carry features > forward, repeating the if-feature using the original modules > prefix:feature-name on every augment of feature-based nodes. Well, I agree that it would have been better to state that if a server doesn't implement the augment target, then it doesn't implement the augment either. But the text is pretty clear; this is not how it works. This is not appropriate to "fix" in an errata. /martin From nobody Tue Mar 14 14:14:52 2017 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 EA44C129B40 for ; Tue, 14 Mar 2017 14:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeGGIZ-hpwvE for ; Tue, 14 Mar 2017 14:14:49 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id C8F70129B42 for ; Tue, 14 Mar 2017 14:14:49 -0700 (PDT) Received: (qmail 10015 invoked by uid 0); 14 Mar 2017 21:14:43 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 14 Mar 2017 21:14:43 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id vxEg1u00d2SSUrH01xEjCK; Tue, 14 Mar 2017 15:14:43 -0600 X-Authority-Analysis: v=2.1 cv=WOnsABcR c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=48vgC7mUAAAA:8 a=EyuznfCmkwt3ea_Go_EA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JffhWVOO/rP9PVK/oOKo3SZU9uERsYzEO5JCxROam4w=; b=q3QcYjczMihsABr17sHMCDIMiO o7BJGf3Ku9kHCOcHTo4eb2S1mvDRtKViisQGDoxnbjHLSB07GsuVLHwi2qe3lvdhmNyC0lJp43I0X FctVh//H8Jq3bWd7jX5j6tulx; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:60332 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cntmC-0001zb-P0; Tue, 14 Mar 2017 15:14:40 -0600 To: NetMod WG Cc: NetMod WG Chairs , "Zitao (Michael) Wang" From: Lou Berger Message-ID: <8c395501-8b28-9a08-1be7-1ec89bd2e0cc@labn.net> Date: Tue, 14 Mar 2017 17:14:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cntmC-0001zb-P0 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:60332 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [netmod] Draft Chicago Agenda Posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 21:14:51 -0000 All, Thanks to our WG Secretary we have a draft agenda for Chicagoat posted: https://datatracker.ietf.org/meeting/98/agenda/netmod/ Please let us know if anything is missing. The draft has us meeting for 2.5 hours in a single session. Our original intent was to meet for 3 hours over two sessions, but we see a couple of advantages of fitting into just one 2.5 hour session - iff this doesn't limit WG progress. As the current agenda is full, we will move back to 2 sessions if any additional agenda requests need to be satisfied. Thanks Lou (Kent, and Michael) From nobody Tue Mar 14 15:28:06 2017 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 C4C07129496 for ; Tue, 14 Mar 2017 15:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 lmwVclKaSTJN for ; Tue, 14 Mar 2017 15:28:00 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0115.outbound.protection.outlook.com [104.47.40.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D977312947B for ; Tue, 14 Mar 2017 15:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uLGljdP0ivRHXgiY0XvZURyQ3Sb0RgONBJ3QpJbN5AM=; b=YvM6LabOau4iOLk0YjxoOJLuIsq5SkzTgvKC5VMyGubFMpzhDClxT99mp8gVPDHcr28XsvMLsJwUpgEZogh6DVKrjURRZBuo39nqquRzpUoY+XftmygeHmMapl2Gb3Bd3d3s/JKDoVsgkmSdqfLMC+9/bsgIo0L3teGVMmNo8aw= Received: from CY1PR05CA0026.namprd05.prod.outlook.com (10.166.186.164) by BLUPR05MB933.namprd05.prod.outlook.com (10.255.190.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Tue, 14 Mar 2017 22:27:58 +0000 Received: from BL2FFO11OLC002.protection.gbl (2a01:111:f400:7c09::144) by CY1PR05CA0026.outlook.office365.com (2a01:111:e400:c5a4::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5 via Frontend Transport; Tue, 14 Mar 2017 22:27:58 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11OLC002.mail.protection.outlook.com (10.173.161.186) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.961.10 via Frontend Transport; Tue, 14 Mar 2017 22:27:57 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 14 Mar 2017 15:27:56 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v2EMRtCS005370; Tue, 14 Mar 2017 15:27:55 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v2EMNpnW074003; Tue, 14 Mar 2017 18:23:51 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201703142223.v2EMNpnW074003@idle.juniper.net> To: Martin Bjorklund CC: , In-Reply-To: <20170314.215041.1542757804066431921.mbj@tail-f.com> Date: Tue, 14 Mar 2017 18:23:51 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39860400002)(39450400003)(39840400002)(2980300002)(199003)(52054003)(24454002)(189002)(9170700003)(105596002)(106466001)(53416004)(2950100002)(6916009)(5660300001)(8676002)(189998001)(81166006)(305945005)(356003)(8936002)(2906002)(86362001)(50466002)(54906002)(7126002)(48376002)(77096006)(229853002)(7696004)(5003940100001)(47776003)(54356999)(50986999)(38730400002)(2810700001)(110136004)(53936002)(6246003)(8276002)(4326008)(1076002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB933; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC002; 1:RZE4z7CBByvhkJzLivwI78nsaBJ4yrGtmJzH3ktZjZE6cYMHs/P5aYSO4XQDfRW89xWH8WmU4yzezpa/ZvtJIftZyRtyXHJUSzLR1EbmVXSV63elI5Ctsw17TSKvtVjEDNcQYmrvRj7+apqwB83ad54jEMeYx6EDsCWe/Wof3uqTY5cx7bGPxkUBOk3En5lTjFFplINJFCqmbrMoQxrLqmQsUt9RDuQrem8ScCMWSt7vRV4HHBzxrcYZCyMx/iZhjdZBnGjosaTgEAekbFUgmLX6yZeOnWLVH+15mI9Jnm9eUmLW/Qs5S4xfxDcsLzFaP2ygz3GAq3MwFCDqWtmgb/uVfncp05TcTxIHw3h/FQS81Pgjwgqlk/EyYC0q+Dvb3OxHwcjpyYawp/BDjN7PZMZkMCStPHxI7dI7s/WBvtUPRfZuKaOnthduYRjvHfzSD5mRLRTJ6hxe4bsM8lKQe621jn1zXFjzs38QoAH+IpyGAY2ghSjcfLiuYY0lqyAaHtM7l3VRnTZgih7COfKN1bYSynqQZkL+NePIQeYjpGJZAnWNEDQVfYnWVlzPJBx2w1HduFXDMpP00Mi5Qol9tkfOXaqkmsfbHaq/HjzKIA8= X-MS-Office365-Filtering-Correlation-Id: 010ff119-3d9f-49e8-fb08-08d46b295df6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254018); SRVR:BLUPR05MB933; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB933; 3:tH/SRbJyzoHXeH3fH3Ztsr5sEmH70Ok2moJSf/lyWK88Mw2uB64ucJbvVcqt+jGeV0X2fuH8djzQMwygIY1QiR5TX8OoHzpTmoujGUnQG4JwokxPo37F855JDa0/hins1ODyJlMU7VKod62Y3DGlu5bSVynSCrUECCMxSrO8/rOISCiPDq6ip0W4RuVbN/MdiKzqOuDw9adnE5wtJZAuupu0c8Kgh+MCxdDrABnRjNfvdCsCPyTRM3DEGdTQtt1Dh1WAshEEEh2LPs/zDoO6MBmId7wsPMIiHOyHRZqb/bnMA39EgpYnvPyVPtHwtMtf07J5TmalQtRuOoHXjshdVKN0GYh1R6Kl67lTUj5BJEY/JtdCUgSMzL3y3s07jmxdZt5sdnNmEHe96Uvcrgrjxg==; 25:3NHw1voLnLug3NYxsdy+G7QZo152cQ02U78fxWmOWFLikG3TXW/ZE19BzqM8+oM/xI37Gzej616I9ZO0xGHDmzvFh+0TCcsFZAxWOZHjkEDoIWNKsAQd1f0mwJaGTB+2fAYT1Wc7i+b8nN8OYGCDSjw5dSfIrumjfvo/59/RYOAove4LtonkVKbixmKwxTkYh0ySiOtMQNMQyYEhGKToI0uW6RF4VA8aCZrOX26CmGNuO4a2zKNs1FXQU/Zc77wg+7UAfE+SIHQSTkzKEV1uHMRH5RkZhumKPfZ8Z8rdQvfOplKIIGpm4Yl4viGo+Wz/JPjrVLnv34Sl4sKvS/VsDLsnx7NotguZryXsrGNSrTiHNy+C3/KWpB8LPyJBpiLCBrdeJO7G71OlGTZ/j9RheUYZlJaTlMcwV5EWOzcPaYeIzOEoA8OQ8MoAz2UplGsy+9638WWM1y0rZYYSr3ECRQ== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB933; 31:Lo08pNnWZIOMVpVnffTKEeGUdhOOiZbbPYfCR3Ep2H/cgwfGLBkJjy/mGP0+a15owSfJ0WbNoCiZ/oW2tTXnxVO8rMsvAt7xAZt3ADszFSHFAjO0kGS64eP+dbqAemfCxjetB4RFd+TNe7ujhUjxBApVi+rSBNrwaDL4f9aP1jzEFSaj4XR3T0UPYSnZuZdIGV/kJHMUC2eIHXvYidFltYBHEzYsHsawtFD12CkmEwdFristWv9XCLoFEZ3CPaaN4sIsn8i8aiIKAzrrISEEGg==; 20:3+8zOs9jQs6M8HTBPw3mFUJTJGHsaVT+y6DITUDpDNimJnBZlx+yU5TD67Sy1l2Hdr6UY2Am1jmv/k5gt8hMMt59f6YZlEfe7GaAS6R+iyoYu2dJX1SHvRDqsKkMh1J8fzspiEKRbS2JVg0Vwyq70NI/9xc3uKtfr5jRKJ0fDIGB4WRHp6JUOZpRPNEf5CpbcFkkAckLEETVixDFlg54mpkGQgqCgVtfZXr375mG5SCjmhxi3JQ7DfJtmFILwi+8aZrD4CNUD5XGrEYc8vtIh0ZIw+dyVEi2+0ZY14nu/wKU2hvAaLX+uh9c9048hxYywPRHMGwaDZZK5gSuK7OUvVfp207eJ1L9wuATFML/aoACizlhVhmZAxqF0wBaI1n+ca6dzUwJN2w+f85EjFQm+7XXdlcUZiuVPMbalZ0gZRQGhd6KP/pTnsU2eNz4Pekd4bBMVsFpzrivYPDrI4P5b5N1+ASXJL/sZ3taG0vGxDEvVHbLWvJRbi8lfhPIaXrS X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13024025)(13018025)(13017025)(8121501046)(13015025)(5005006)(13023025)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123558025)(20161123564025)(6072148); SRVR:BLUPR05MB933; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB933; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB933; 4:/ITsacnw3zqnTNnQs0LehVi2yNPX7wt7FmTQ3n0w/Kbi9d2OUyeHXL9SU1JGJadSjGjv4QX+XL97Xk4AVX4dYjJrnrqHOhIrhcT+sJmq6zAD82L7BLaTastxK/l49QOE/0N9iiBfJwETqKj/Md25PK+NM2FMeAW420sEebCNvfm+Mf6Af5nnLrq6CagYsOBQjd4VfvnPnHYaXifdqt7rf84pO+fkfvtDYOX8WDtmLB3bz/WtwHQCNZEqIVJsrRu0OEY6Ri35braa+VPNXVCjTox+fXvoxvU/kdTqA/YYuBr7Qq4UYc4TflvN1TuPQ/s0PzoTOqJZlRHLdecREbJfcV3TIR9tSIrs87yHghtwlAbbtJ8yNicRTr3a5aiKR7yCq2tSt2vVW1DmqMSS8Xbj5EfWLI9qnGyaa8fhJm2FL92C206FaaUDO3fwxj06W53BA1LcGvv2UVJb2lsTYsLwLwjEaFAXmdvxYRQ5uCsM+9m4ng2H4LVFXDDiz0oW6WsBweRdEdx7xfm1iMghERx/pdPwcVmwcJTfREVgA9ZMn3xZwsiLwTeL+wukqBBDxBcoEMZCEKjzGTSyCfn3cV+kpadUkc8lTCQZi5WxGI39aPJh7EIt1gh6gmAi1kKoxJcC7CXheRNMLeBba0zyDLSjeUmzsPhaXnyhyJpDM6U+6n9fA0xUo+KZqlw1/5inD9aZKpBWsS2+RH7hWpmF+5CXodu7yvp5dIuHB+s70ED3Ao4cIUP/M4GuEZ+xp488wU63Xw+Yn+3xIJDZXeH/Mj/83MfZPWN51T2caaswg+sTfxo= X-Forefront-PRVS: 02462830BE X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB933; 23:lkbnbO+jx5/LK7wbtYm+uW2mhu0wu72Q/iq7yRHGXQ?= =?us-ascii?Q?gtUOuoOd8y0dfqWilcV+kSedH9hNQUt0Ur8viNeAfYxYg/1WTIZXVLKHsVam?= =?us-ascii?Q?F6H3zP+vtoPSxw9OYhP63FOvGByyzfKeZgeAceppQWMP6XLYHdwQWgyq8KoU?= =?us-ascii?Q?ekSVmGYUWgTep4a1bsyXPJB98494ech9VEw+svyUSYwivZrW2QQ7JDxOiBDX?= =?us-ascii?Q?eSA+ES+9AjROipCFzQMPnKnR/1RdhaKIKVCMBgB4od/Mq+viB2jwplRMAxln?= =?us-ascii?Q?RFxsx5NGKyh0GUlOA5ZjUoQfm3D8L3koKycepmesbdU2P4RHTAaDwJtDCgTF?= =?us-ascii?Q?auZ2lA+2LGesYDHgXNWQ6XwAVz6/wgcwGvXG1FkfyofEHcCr9PhZV/fzG13u?= =?us-ascii?Q?/MYhj+3Ci0QS3TFlhMpDKINfHfvZ0l/mgtQmWmaku2G20RTMN/L7cj7ZWKvY?= =?us-ascii?Q?RC1nQjOxUgKXYLYo+dvHimFUTtTu5QaEPjTjr0nyA9qIq+NS5fT/DrdH4xKa?= =?us-ascii?Q?eWu5i5Vci5xp0TkLgcfhoc3H8abwJhbEipKPOuf9ERaa1mafxtNXnosO9eyW?= =?us-ascii?Q?P2rheV1FAZZocmrRWIPpfpXpqBCFoEpmhgnPEhdA5fu2yn9U4mom4F9D3NoY?= =?us-ascii?Q?uH1V/KhAxIIUI2KSMyKO8cfLMswWRiiljdbT1Qg7D8qf0So5uqqXaRV0jKAq?= =?us-ascii?Q?6Bzpci7qPaf5IX+Rzkv5R+yikPnRn19G1yieOiVrZqneQNMwOoAiBi8W5Q8L?= =?us-ascii?Q?rtjle0gX3QJyJe5ZgwrinxcsaDcZLm0HhZAqBlaNXtfXAj7qQDxUsiUrrBJ2?= =?us-ascii?Q?67mfpFW+vEN+BytzttN8Uk91QckEs8uB4lUf94evYWGfGVEH8PWAxbblsKga?= =?us-ascii?Q?dvqvTYOYSN4lkQBROdD5Gj3MCwNUT3/Y/E9bN3BU8oQ398rqzT6bw5mpbw92?= =?us-ascii?Q?bP0S3OIrvCL+f/yslqmE0SbvRZ4OOXDaSdNXIvKK5uSyMwPxvOJpm6uzMCJS?= =?us-ascii?Q?s2Fu25H6LX47fq45ynTqoAW8tHuio7mXdXrk60pDO4mJZVxn2akfWESp9n7/?= =?us-ascii?Q?c5cEN3PmUeWJxg9IhuaUX2WSb0F+R+boDudi3b3R7vTK5MCOBgj+IuWu6ebB?= =?us-ascii?Q?Ftb/lfVnY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB933; 6:hjDpOmAnTY/w/HrDznrZ4O/gAGSdCLMfyXfWdbGQlcyWAcePZToCauDuE1+AWMi6hTyIEWbvTg0JST2Zavl44ThNpg72GvIvNA4oibUDpJeBCf0irGC3BuhYA9PUl4TTV0i2wzrHcY9OHsBUufBFrNxxEa1EmqNUn1djVINNs74NZhx6+zKg2HXhCo4YAxxlLH+kymLNEyEhcRTSX4icHVqLBz1guwkxcbs0JmXVNAueTo20QuUFRJ5s2buUXXeGycLaZ5cjrrid/c4HzzyZdSeVKBc8qesSKoge7HZSQm9m+0S3UFbPnReP00OXwKjphkBsECf+mdIGdgEDj0U0c2phpch+uxYjvWdXHp0C24fPK0C9WZ0lCqCmgc///SeaseVVtLGN3Zwv5jGwLTFXnOuURBptqNT2GZUd0mKml2U=; 5:OSMUgC/OZKXzU/NqiD3wlRxcJTWbTmQK3kHWj17V3xe7nb1xFhbv/UxDQ235DSrmFAFAyjP9a3YMVtcMGOe1ZBi0NfG/jlDUB0KetoOLyPavhmfO4S6Ubo1SPNQxVV6z5OZKQjroMFXKcQOlYkFKjQ==; 24:fw5yIh/eIeGCzqI5sP6i/QulD72EvSaTkBEcnkaPPeijRr0d+a8zLi9AN3KllI/Ak1UE4bO4omK9cBVx0KIAbc0VwQ1At94lbvOTr3yjAYA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB933; 7:HTe4wMfdz+tWvs4RSkKYnq7mN8YqOTkL/gZmgSQ04XNdV57PAQkfgr9XrJANSeRyC8BP55Tfm4ML78sHwpm862/bdBCRHxER7IvrmOBMwfjrZQUAY9KhzZI6/SnttfBd5dtFfJQV8JnuXYr8zeVgJwD5frrmwmeE3LsJRvYfnfFeRjpOugD2cqUbyK70bGLLWpfqVdCGucPIwjIGu2Nbj1+jM78lKgzmo6y4uXpn3XyzZEA1KDXV+RAqia/cvbHvww8S1UMlRpJHtvEh+Gl0dgA6MZMnxoQnIw1j88xiFhh8zOuiw6gYPnItAkz6eg4cTIOLK4Z2Gp6+5nILKCvw+w== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2017 22:27:57.6792 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB933 Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:28:05 -0000 Martin Bjorklund writes: >Phil Shafer wrote: >> Martin Bjorklund writes: >> >> What are your thoughts on this? Surely, an augment should not have to >> >> contain if-feature statements of all parents of the augmented node. >> > >> >The spec says: >> > >> > When a server implements a module containing an "augment" statement, >> > that implies that the server's implementation of the augmented module >> > contains the additional nodes. >> > >> >Compare with a simple augment of a node w/o an if-feature. In this >> >case, if the server implements the augmenting module, it MUST also >> >implement the augmented module. >> >> It implements the module, but it doesn't implement the nodes >> since it doesn't express the feature. IMHO this is a tool >> bug and/or an errata,since otherwise one has to carry features >> forward, repeating the if-feature using the original modules >> prefix:feature-name on every augment of feature-based nodes. > >Well, I agree that it would have been better to state that if a server >doesn't implement the augment target, then it doesn't implement the >augment either. But the text is pretty clear; this is not how it >works. This is not appropriate to "fix" in an errata. I'm missing the part of the text that's clear. The above quoted section certainly doesn't say this. That text is saying "if you implement a module that augments a set of nodes, then the server's schema for that original set of nodes now includes the new set of nodes". It's referring to schema nodes. And if those schema nodes are conditional based on if-feature, then those nodes are still in the schema, but are not supported by a server unless the if-feature condition evaluates to true. I don't see a conflict, it's just a case that we didn't think about or write about. It's a case that's not clearly handled in the spec, for which reasonable implementations can disagree. That's a bug in the spec and it that can be clarified via errata. Thanks, Phil From nobody Tue Mar 14 17:06:08 2017 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 D66C51316E9 for ; Tue, 14 Mar 2017 17:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 FSQqIs6IfFXH for ; Tue, 14 Mar 2017 17:06:06 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 F33F1129BCD for ; Tue, 14 Mar 2017 17:06:05 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-05v.sys.comcast.net with SMTP id nwRjcebdg4CjQnwS5c8U5Q; Wed, 15 Mar 2017 00:06:05 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-09v.sys.comcast.net with SMTP id nwS3crmBbQcYynwS4c0YSm; Wed, 15 Mar 2017 00:06:04 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2F063rM004670; Tue, 14 Mar 2017 20:06:03 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2F062V1004667; Tue, 14 Mar 2017 20:06:02 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Clyde Wildes \(cwildes\)" Cc: netmod@ietf.org In-Reply-To: (cwildes@cisco.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 14 Mar 2017 20:06:02 -0400 Message-ID: <87innb2yl1.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJrcXrCvcbz4EFTZee3abee6awKj5va7YRid5ni5Sm2Gmwc2U/4bd+XYcuMgx9ixBFNeQfEUo4kAoOKp2GkDuK+/Q/uI8Z6TlSOIG4D0GuK0ANhvfMuD R/8oyWQnWrQHCatn3HEZrr7BDUzJro84viFTkuLxXB+VLLoQSf0+VKbKOw+8TocQLNy1TdFqaR99LQ== Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 00:06:07 -0000 "Clyde Wildes (cwildes)" writes: > Thanks for the simplification. I have incorporated this in the next > draft-ietf-netmod-syslog-model revision. Ah, thanks! Looking at -13, I see this: A syslog message is processed if: There is an element of facility-list (F, S) where the message facility matches F (if it is present) and the message severity matches S (if it is present) or the message text matches the regex pattern (if it is present) I think you want to move the line "and the message severity ..." to the left by two spaces so that the lines are aligned by how they are grouped by the logical operators. That would give: There is an element of facility-list (F, S) where the message facility matches F (if it is present) and the message severity matches S (if it is present) or the message text matches the regex pattern (if it is present) Dale From nobody Tue Mar 14 18:13:02 2017 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 433E3129471 for ; Tue, 14 Mar 2017 18:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 ZxKauuuRemEW for ; Tue, 14 Mar 2017 18:12:57 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0092.outbound.protection.outlook.com [104.47.36.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B25129404 for ; Tue, 14 Mar 2017 18:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YUChRmgHDGPXEVQCN+Gn/QCsjUXn+YNwXxMiVOBC5u4=; b=X8Ji9vGgKhCwYHCXb6VOUFmjE/d+gWhrlagKNh6QyjY4S+19mJGks/BdMDeiP8LYe2Tfs9GXO8b0foOFqjDg0BUH8XWTwxnrEat+taOPDt0n7OZqZMc/akbtP8o80m/ZRIl7JHVGOSxwq8NnPOAJr/rMgG0EuSvCOQUXl7B8YMY= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 01:12:56 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0977.010; Wed, 15 Mar 2017 01:12:56 +0000 From: Kent Watsen To: David Bannister CC: Dean Bogdanovic , NetMod WG Thread-Topic: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt Thread-Index: AQHSnSlHwAqIi04elk+0OsiclimezA== Date: Wed, 15 Mar 2017 01:12:55 +0000 Message-ID: <4D50BFD4-0E59-4DF8-BEC9-0D9BE50F5BA6@juniper.net> References: <148939875845.17039.4017763838166134753.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: netflix.com; dkim=none (message not signed) header.d=none;netflix.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:NRvGE8JZpXJE1lEGO8YtUhLw1IrFdDMVNq9Ae5rLZNSOALJay+EErYoT8p1K8Q/Q6AOPyI68FWxQ4g4Kce9XiObL87MJWg+jRgre6z78Okgrq2rlzPyy1Ala6s+HwT4GFOfq7vTUWoNXjXCUFiSs250byD0pa3I//raLOXbZd8oq3L960XwjMoPFAS9t/mJslT1u+WaF7EDNHkAmO+yhpZhpvU/OrBRQqtdzlDvJqaeG+0/A9kTMDG55VMljlpclwizOiRFfue1oJ8TS8gLrWIJuzaQhCvGlOKQoCs3ZaK1+tMjxPJFjtBZvztx3527NgImZHs9vHXegQwupBrrsIw== x-ms-office365-filtering-correlation-id: 4f7d5b50-6aa1-4937-6f1f-08d46b4069b7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39850400002)(39410400002)(39450400003)(39840400002)(377424004)(78124002)(24454002)(377454003)(230783001)(9326002)(14971765001)(3660700001)(39060400002)(3280700002)(7736002)(83716003)(15650500001)(10710500007)(8936002)(2420400007)(66066001)(2906002)(81166006)(8676002)(6916009)(4326008)(6246003)(38730400002)(53386004)(110136004)(102836003)(3846002)(53936002)(6116002)(6506006)(2900100001)(6486002)(2950100002)(229853002)(36756003)(606005)(76176999)(6306002)(6512007)(236005)(54896002)(54906002)(99286003)(50986999)(77096006)(6436002)(86362001)(54356999)(122556002)(25786008)(82746002)(33656002)(83506001)(1680700002)(7110500001)(189998001)(4001350100001)(5660300001)(7906003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_4D50BFD40E594DF8BEC90D9BE50F5BA6junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 01:12:55.8848 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 01:13:00 -0000 --_000_4D50BFD40E594DF8BEC90D9BE50F5BA6junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNCkNhbiB5b3UgcGxlYXNlIGNvbmZpcm0gdGhhdCB0aGUgYWRkaXRpb25hbCBl eGFtcGxlcyBhZGRyZXNzIHlvdXIgY29uY2Vybj8gIEFuZCwgaWYgbm90LCBwbGVhc2UNCmV4cGxh aW4gaWYgdGhlcmUgaXMgYW55IHJlYXNvbiB3aHkgd2hhdCB5b3UncmUgbG9va2luZyBmb3IgY291 bGRuJ3QgYmUgYWRkZWQgb3IgYXVnbWVudGVkIGluDQppbiB0aGUgZnV0dXJlLg0KDQpUaGFua3Ms DQpLZW50IC8vIHNoZXBoZXJkDQoNCk9uIDMvMTMvMTcsIDU6NTcgQU0sICJuZXRtb2Qgb24gYmVo YWxmIG9mIERlYW4gQm9nZGFub3ZpYyIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpu ZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGl2YW5kZWFuQGdtYWlsLmNvbTxt YWlsdG86aXZhbmRlYW5AZ21haWwuY29tPj4gd3JvdGU6DQoNCkhlcmUgaXMgdGhlIG5ldyB2ZXJz aW9uIG9mIHRoZSBBQ0wgZHJhZnQuIFNpbmNlIERlY2VtYmVyIGFuZCBzb21lIGFkZGl0aW9uYWwg Y29tbWVudHMgYWJvdXQgdGhlIEFDTCBtb2RlbCwgSSBzcG9rZSB3aXRoIG1hbnkgb3BlcmF0b3Jz IGFuZCBob3cgdGhleSB1c2UgQUNMcy4gSSBoYXZlIGFsc28gcmVjZWl2ZWQgbG90IG9mIGRldGFp bGVkIEFDTCBjb25maWd1cmF0aW9ucy4gSW4gbW9zdCBjYXNlcywgdGhlIG1vZGVsIGlzIGVhc2ls eSBhZGFwdGVkIHRvIHRoZSBjdXJyZW50IHVzZSBjYXNlcyBpbiBvcGVyYXRpb25zLiBCdXQgdG8g YW5zd2VyIHRoZSBjb21tZW50cywgdGhlIGF1dGhvcnMgaGF2ZSBhZGRlZCBhIGRldGFpbGVkIGV4 YW1wbGUgaW4gdGhlIGFkZGVuZHVtIHNlY3Rpb24gaG93IHRoZSBtb2RlbCBjYW4gYmUgZXh0ZW5k ZWQgYW5kIGhvdyB0aGlzIG1vZGVsIGNhbiBiZSB1c2VkLg0KDQpDaGVlcnMsDQoNCkRlYW4NCg0K DQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEwLnR4dA0K RGF0ZTogTWFyY2ggMTMsIDIwMTcgYXQgMTA6NTI6MzggQU0gR01UKzENClRvOiA8bmV0bW9kLWNo YWlyc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz4+LCAiS2lyYW4gS291 c2hpayIgPGtrb3VzaGlrQGNpc2NvLmNvbTxtYWlsdG86a2tvdXNoaWtAY2lzY28uY29tPj4sICJM aXNhIEh1YW5nIiA8bHlpaHVhbmcxNkBnbWFpbC5jb208bWFpbHRvOmx5aWh1YW5nMTZAZ21haWwu Y29tPj4sICJEZWFuIEJvZ2Rhbm92aWMiIDxpdmFuZGVhbkBnbWFpbC5jb208bWFpbHRvOml2YW5k ZWFuQGdtYWlsLmNvbT4+LCAiRGFuYSBCbGFpciIgPGRibGFpckBjaXNjby5jb208bWFpbHRvOmRi bGFpckBjaXNjby5jb20+PiwgIktpcmFuIEFncmFoYXJhIFNyZWVuaXZhc2EiIDxra291c2hpa0Bj aXNjby5jb208bWFpbHRvOmtrb3VzaGlrQGNpc2NvLmNvbT4+DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xMC50eHQNCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgRGVhbiBCb2dkYW5vdmljIGFuZCBwb3N0ZWQgdG8gdGhlDQpJ RVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6IGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbA0KUmV2 aXNpb246IDEwDQpUaXRsZTogTmV0d29yayBBY2Nlc3MgQ29udHJvbCBMaXN0IChBQ0wpIFlBTkcg RGF0YSBNb2RlbA0KRG9jdW1lbnQgZGF0ZTogMjAxNy0wMy0xMw0KR3JvdXA6IG5ldG1vZA0KUGFn ZXM6IDMyDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xMC50eHQNClN0YXR1czogICAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9k ZWwvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbmV0bW9kLWFjbC1tb2RlbC0xMA0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTANCg0KQWJzdHJh Y3Q6DQogIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgZGF0YSBtb2RlbCBvZiBBY2Nlc3MgQ29u dHJvbCBMaXN0IChBQ0wpDQogIGJhc2ljIGJ1aWxkaW5nIGJsb2Nrcy4NCg0KICBFZGl0b3JpYWwg Tm90ZSAoVG8gYmUgcmVtb3ZlZCBieSBSRkMgRWRpdG9yKQ0KDQogIFRoaXMgZHJhZnQgY29udGFp bnMgbWFueSBwbGFjZWhvbGRlciB2YWx1ZXMgdGhhdCBuZWVkIHRvIGJlIHJlcGxhY2VkDQogIHdp dGggZmluYWxpemVkIHZhbHVlcyBhdCB0aGUgdGltZSBvZiBwdWJsaWNhdGlvbi4gIFRoaXMgbm90 ZQ0KICBzdW1tYXJpemVzIGFsbCBvZiB0aGUgc3Vic3RpdHV0aW9ucyB0aGF0IGFyZSBuZWVkZWQu ICBQbGVhc2Ugbm90ZQ0KICB0aGF0IG5vIG90aGVyIFJGQyBFZGl0b3IgaW5zdHJ1Y3Rpb25zIGFy ZSBzcGVjaWZpZWQgYW55d2hlcmUgZWxzZSBpbg0KICB0aGlzIGRvY3VtZW50Lg0KDQogIEFydHdv cmsgaW4gdGhpcyBkb2N1bWVudCBjb250YWlucyBzaG9ydGhhbmQgcmVmZXJlbmNlcyB0byBkcmFm dHMgaW4NCiAgcHJvZ3Jlc3MuICBQbGVhc2UgYXBwbHkgdGhlIGZvbGxvd2luZyByZXBsYWNlbWVu dHMNCg0KICBvICAiWFhYWCIgLS0+IHRoZSBhc3NpZ25lZCBSRkMgdmFsdWUgZm9yIHRoaXMgZHJh ZnQuDQoNCiAgbyAgUmV2aXNpb24gZGF0ZSBpbiBtb2RlbCAoT2N0IDEyLCAyMDE2KSBuZWVkcyB0 byBnZXQgdXBkYXRlZCB3aXRoDQogICAgIHRoZSBkYXRlIHRoZSBkcmFmdCBnZXRzIGFwcHJvdmVk LiAgVGhlIGRhdGUgYWxzbyBuZWVkcyB0byBnZXQNCiAgICAgcmVmbGVjdGVkIG9uIHRoZSBsaW5l IHdpdGggPENPREUgQkVHSU5TPi4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= --_000_4D50BFD40E594DF8BEC90D9BE50F5BA6junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <3263F843C97E234D8F77E2B11672B36A@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIgMCA1IDMgMCAwIDAgMiAwIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1u YW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJZm9udC12YXJpYW50Om5v cm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9u ZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2VsaW5l O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHls ZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSI+SGkgRGF2aWQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpIj5DYW4geW91IHBsZWFzZSBjb25maXJtIHRoYXQgdGhlIGFkZGl0aW9uYWwg ZXhhbXBsZXMgYWRkcmVzcyB5b3VyIGNvbmNlcm4/Jm5ic3A7IEFuZCwgaWYgbm90LCBwbGVhc2U8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ZXhwbGFpbiBpZiB0aGVyZSBpcyBhbnkgcmVhc29uIHdoeSB3 aGF0IHlvdSdyZSBsb29raW5nIGZvciBjb3VsZG4ndCBiZSBhZGRlZCBvciBhdWdtZW50ZWQgaW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSI+aW4gdGhlIGZ1dHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+ S2VudCAvLyBzaGVwaGVyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMvMTMvMTcs IDU6NTcgQU0sICZxdW90O25ldG1vZCBvbiBiZWhhbGYgb2YgRGVhbiBCb2dkYW5vdmljJnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzppdmFuZGVhbkBn bWFpbC5jb20iPml2YW5kZWFuQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBpcyB0aGUgbmV3 IHZlcnNpb24gb2YgdGhlIEFDTCBkcmFmdC4gU2luY2UgRGVjZW1iZXIgYW5kIHNvbWUgYWRkaXRp b25hbCBjb21tZW50cyBhYm91dCB0aGUgQUNMIG1vZGVsLCBJIHNwb2tlIHdpdGggbWFueSBvcGVy YXRvcnMgYW5kIGhvdyB0aGV5IHVzZSBBQ0xzLiBJIGhhdmUgYWxzbyByZWNlaXZlZCBsb3Qgb2Yg ZGV0YWlsZWQgQUNMIGNvbmZpZ3VyYXRpb25zLiBJbiBtb3N0IGNhc2VzLCB0aGUgbW9kZWwNCiBp cyBlYXNpbHkgYWRhcHRlZCB0byB0aGUgY3VycmVudCB1c2UgY2FzZXMgaW4gb3BlcmF0aW9ucy4g QnV0IHRvIGFuc3dlciB0aGUgY29tbWVudHMsIHRoZSBhdXRob3JzIGhhdmUgYWRkZWQgYSBkZXRh aWxlZCBleGFtcGxlIGluIHRoZSBhZGRlbmR1bSBzZWN0aW9uIGhvdyB0aGUgbW9kZWwgY2FuIGJl IGV4dGVuZGVkIGFuZCBob3cgdGhpcyBtb2RlbCBjYW4gYmUgdXNlZC4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlZ2luIGZvcndhcmRlZCBtZXNzYWdl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPkZyb206IDwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij48YSBo cmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7Ij5TdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWll dGYtbmV0bW9kLWFjbC1tb2RlbC0xMC50eHQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5EYXRlOiA8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+TWFyY2ggMTMsIDIw MTcgYXQgMTA6NTI6MzggQU0gR01UJiM0MzsxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5UbzogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPiZsdDs8YSBocmVmPSJtYWls dG86bmV0bW9kLWNoYWlyc0BpZXRmLm9yZyI+bmV0bW9kLWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7 LCAmcXVvdDtLaXJhbiBLb3VzaGlrJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86a2tvdXNoaWtA Y2lzY28uY29tIj5ra291c2hpa0BjaXNjby5jb208L2E+Jmd0OywNCiAmcXVvdDtMaXNhIEh1YW5n JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bHlpaHVhbmcxNkBnbWFpbC5jb20iPmx5aWh1YW5n MTZAZ21haWwuY29tPC9hPiZndDssICZxdW90O0RlYW4gQm9nZGFub3ZpYyZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOml2YW5kZWFuQGdtYWlsLmNvbSI+aXZhbmRlYW5AZ21haWwuY29tPC9hPiZn dDssICZxdW90O0RhbmEgQmxhaXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkYmxhaXJAY2lz Y28uY29tIj5kYmxhaXJAY2lzY28uY29tPC9hPiZndDssICZxdW90O0tpcmFuIEFncmFoYXJhIFNy ZWVuaXZhc2EmcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtrb3VzaGlrQGNpc2NvLmNvbSI+ a2tvdXNoaWtAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTAudHh0 PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEZWFuIEJvZ2Rhbm92aWMg YW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTo8 c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiA8L3NwYW4+ZHJhZnQtaWV0Zi1uZXRtb2QtYWNs LW1vZGVsPGJyPg0KUmV2aXNpb246PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4gPC9zcGFu PjEwPGJyPg0KVGl0bGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPk5ldHdv cmsgQWNjZXNzIENvbnRyb2wgTGlzdCAoQUNMKSBZQU5HIERhdGEgTW9kZWw8YnI+DQpEb2N1bWVu dCBkYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj4yMDE3LTAzLTEzPGJy Pg0KR3JvdXA6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPm5ldG1vZDxicj4N ClBhZ2VzOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj4zMjxicj4NClVSTDog Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xMC50eHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTAudHh0PC9hPjxicj4N ClN0YXR1czogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRt b2QtYWNsLW1vZGVsLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1uZXRtb2QtYWNsLW1vZGVsLzwvYT48YnI+DQpIdG1saXplZDogJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xMDwvYT48YnI+DQpEaWZmOiAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2QtYWNs LW1vZGVsLTEwIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1u ZXRtb2QtYWNsLW1vZGVsLTEwPC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyZu YnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgZGF0YSBtb2RlbCBvZiBBY2Nlc3MgQ29udHJv bCBMaXN0IChBQ0wpPGJyPg0KJm5ic3A7Jm5ic3A7YmFzaWMgYnVpbGRpbmcgYmxvY2tzLjxicj4N Cjxicj4NCiZuYnNwOyZuYnNwO0VkaXRvcmlhbCBOb3RlIChUbyBiZSByZW1vdmVkIGJ5IFJGQyBF ZGl0b3IpPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7VGhpcyBkcmFmdCBjb250YWlucyBtYW55IHBs YWNlaG9sZGVyIHZhbHVlcyB0aGF0IG5lZWQgdG8gYmUgcmVwbGFjZWQ8YnI+DQombmJzcDsmbmJz cDt3aXRoIGZpbmFsaXplZCB2YWx1ZXMgYXQgdGhlIHRpbWUgb2YgcHVibGljYXRpb24uICZuYnNw O1RoaXMgbm90ZTxicj4NCiZuYnNwOyZuYnNwO3N1bW1hcml6ZXMgYWxsIG9mIHRoZSBzdWJzdGl0 dXRpb25zIHRoYXQgYXJlIG5lZWRlZC4gJm5ic3A7UGxlYXNlIG5vdGU8YnI+DQombmJzcDsmbmJz cDt0aGF0IG5vIG90aGVyIFJGQyBFZGl0b3IgaW5zdHJ1Y3Rpb25zIGFyZSBzcGVjaWZpZWQgYW55 d2hlcmUgZWxzZSBpbjxicj4NCiZuYnNwOyZuYnNwO3RoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0K Jm5ic3A7Jm5ic3A7QXJ0d29yayBpbiB0aGlzIGRvY3VtZW50IGNvbnRhaW5zIHNob3J0aGFuZCBy ZWZlcmVuY2VzIHRvIGRyYWZ0cyBpbjxicj4NCiZuYnNwOyZuYnNwO3Byb2dyZXNzLiAmbmJzcDtQ bGVhc2UgYXBwbHkgdGhlIGZvbGxvd2luZyByZXBsYWNlbWVudHM8YnI+DQo8YnI+DQombmJzcDsm bmJzcDtvICZuYnNwOyZxdW90O1hYWFgmcXVvdDsgLS0mZ3Q7IHRoZSBhc3NpZ25lZCBSRkMgdmFs dWUgZm9yIHRoaXMgZHJhZnQuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7byAmbmJzcDtSZXZpc2lv biBkYXRlIGluIG1vZGVsIChPY3QgMTIsIDIwMTYpIG5lZWRzIHRvIGdldCB1cGRhdGVkIHdpdGg8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgZGF0ZSB0aGUgZHJhZnQgZ2V0 cyBhcHByb3ZlZC4gJm5ic3A7VGhlIGRhdGUgYWxzbyBuZWVkcyB0byBnZXQ8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZWZsZWN0ZWQgb24gdGhlIGxpbmUgd2l0aCAmbHQ7Q09E RSBCRUdJTlMmZ3Q7Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyI+DQp0b29scy5pZXRmLm9yZzwv YT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4D50BFD40E594DF8BEC90D9BE50F5BA6junipernet_-- From nobody Tue Mar 14 19:13:11 2017 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 DF22E129A2F for ; Tue, 14 Mar 2017 19:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-1sRM7sMxVn for ; Tue, 14 Mar 2017 19:13:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242C31299E2 for ; Tue, 14 Mar 2017 19:13:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCU68149; Wed, 15 Mar 2017 02:13:05 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Mar 2017 02:13:05 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Wed, 15 Mar 2017 10:12:58 +0800 From: wangzitao To: Lou Berger , NetMod WG Thread-Topic: Draft Chicago Agenda Posted Thread-Index: AQHSnQgFLPJnyoqF2kyoFNXu7DnPiqGVJmHg Date: Wed, 15 Mar 2017 02:12:58 +0000 Message-ID: References: <8c395501-8b28-9a08-1be7-1ec89bd2e0cc@labn.net> In-Reply-To: <8c395501-8b28-9a08-1be7-1ec89bd2e0cc@labn.net> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.198] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58C8A332.013F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.14, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d21dc9cd862265b86c33de20bac836dc Archived-At: Subject: Re: [netmod] Draft Chicago Agenda Posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 02:13:10 -0000 SGkgV0csDQoNClRoYW5rcyBMb3UgZm9yIHBvc3RpbmcgdGhpcyBkcmFmdCBhZ2VuZGEuDQpBbmQg aWYgdGhlcmUgaXMgYW55IGFkZGl0aW9uYWwgdGltZSBzbG90cyByZXF1ZXN0LCBwbGVhc2Ugc2Vu ZCBpdCB0byBvdXIgV0cgY2hhaXJzIGFuZCBtZSBiZWZvcmUgbmV4dCBNb25kYXksIGJlY2F1c2Ug dGhlIFJldmlzZWQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1ZSBieSBVVEMgMjM6NTksIDIwMTct MDMtMjAgKE1vbmRheSkuDQoNCkJlc3QgUmVnYXJkcyENCi1NaWNoYWVsDQoNCi0tLS0t6YKu5Lu2 5Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5u ZXRdIA0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0M+aciDE15pelIDU6MTUNCuaUtuS7tuS6ujogTmV0 TW9kIFdHDQrmioTpgIE6IE5ldE1vZCBXRyBDaGFpcnM7IHdhbmd6aXRhbw0K5Li76aKYOiBEcmFm dCBDaGljYWdvIEFnZW5kYSBQb3N0ZWQNCg0KQWxsLA0KDQogICAgVGhhbmtzIHRvIG91ciBXRyBT ZWNyZXRhcnkgd2UgaGF2ZSBhIGRyYWZ0IGFnZW5kYSBmb3IgQ2hpY2Fnb2F0ICBwb3N0ZWQ6DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTgvYWdlbmRhL25ldG1vZC8NCg0K UGxlYXNlIGxldCB1cyBrbm93IGlmIGFueXRoaW5nIGlzIG1pc3NpbmcuDQoNClRoZSBkcmFmdCBo YXMgdXMgbWVldGluZyBmb3IgMi41IGhvdXJzIGluIGEgc2luZ2xlIHNlc3Npb24uICBPdXIgb3Jp Z2luYWwgaW50ZW50IHdhcyB0byBtZWV0IGZvciAzIGhvdXJzIG92ZXIgdHdvIHNlc3Npb25zLCBi dXQgd2Ugc2VlIGEgY291cGxlIG9mIGFkdmFudGFnZXMgb2YgZml0dGluZyBpbnRvIGp1c3Qgb25l IDIuNSBob3VyIHNlc3Npb24gLSBpZmYNCnRoaXMgZG9lc24ndCBsaW1pdCBXRyBwcm9ncmVzcy4g ICBBcyB0aGUgY3VycmVudCBhZ2VuZGEgaXMgZnVsbCwgd2Ugd2lsbA0KbW92ZSBiYWNrIHRvIDIg c2Vzc2lvbnMgaWYgYW55IGFkZGl0aW9uYWwgYWdlbmRhIHJlcXVlc3RzIG5lZWQgdG8gYmUgc2F0 aXNmaWVkLg0KDQpUaGFua3MNCg0KTG91IChLZW50LCBhbmQgTWljaGFlbCkNCg0KDQoNCg== From nobody Wed Mar 15 00:28:15 2017 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 E149112969C for ; Wed, 15 Mar 2017 00:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm5iRFmv_bfj for ; Wed, 15 Mar 2017 00:28:12 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9608212969B for ; Wed, 15 Mar 2017 00:28:12 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 96A291AE02A7; Wed, 15 Mar 2017 08:28:09 +0100 (CET) Date: Wed, 15 Mar 2017 08:28:14 +0100 (CET) Message-Id: <20170315.082814.1668142020606045450.mbj@tail-f.com> To: phil@juniper.net Cc: joey.boyd@adtran.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <201703142223.v2EMNpnW074003@idle.juniper.net> References: <20170314.215041.1542757804066431921.mbj@tail-f.com> <201703142223.v2EMNpnW074003@idle.juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 07:28:14 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >Phil Shafer wrote: > >> Martin Bjorklund writes: > >> >> What are your thoughts on this? Surely, an augment should not have to > >> >> contain if-feature statements of all parents of the augmented node. > >> > > >> >The spec says: > >> > > >> > When a server implements a module containing an "augment" statement, > >> > that implies that the server's implementation of the augmented module > >> > contains the additional nodes. > >> > > >> >Compare with a simple augment of a node w/o an if-feature. In this > >> >case, if the server implements the augmenting module, it MUST also > >> >implement the augmented module. > >> > >> It implements the module, but it doesn't implement the nodes > >> since it doesn't express the feature. IMHO this is a tool > >> bug and/or an errata,since otherwise one has to carry features > >> forward, repeating the if-feature using the original modules > >> prefix:feature-name on every augment of feature-based nodes. > > > >Well, I agree that it would have been better to state that if a server > >doesn't implement the augment target, then it doesn't implement the > >augment either. But the text is pretty clear; this is not how it > >works. This is not appropriate to "fix" in an errata. > > I'm missing the part of the text that's clear. The above quoted > section certainly doesn't say this. That text is saying "if you > implement a module that augments a set of nodes, then the server's > schema for that original set of nodes now includes the new set of > nodes". It's referring to schema nodes. It explicitly says that server's *implementation* of the augmented module contains the additional nodes. If you don't advertise a certain module, I don't think you can claim that your implementation contains that module. And similarly, if you don't advertise a feature, I don't think you can claim that your implementation implements nodes that are conditional on that feature. > And if those schema nodes are conditional based on if-feature, then > those nodes are still in the schema, but are not supported by a > server unless the if-feature condition evaluates to true. > > I don't see a conflict, > it's just a case that we didn't think about > or write about. This I agree with. > It's a case that's not clearly handled in the spec, > for which reasonable implementations can disagree. That's a bug > in the spec and it that can be clarified via errata. > > Thanks, > Phil > /martin From nobody Wed Mar 15 03:12:42 2017 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 DF49A129A96 for ; Wed, 15 Mar 2017 03:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 tMfiBGHUzff3 for ; Wed, 15 Mar 2017 03:12:39 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4190129A9D for ; Wed, 15 Mar 2017 03:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3856; q=dns/txt; s=iport; t=1489572758; x=1490782358; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=6OeF9vQxBS8z1dkYUJrJ/ipX45yjT+Fpty0JAfn0W9M=; b=OyywC1DgBSG3iieyoNpS0sM9oXq65/wE5MGJIQ8KnuDADDeik+0EWGG4 rdk13OJlQrv64OmPwDZSFaAnjaVKR3CV/sTjfD49Gfx7q+/3wz+umkgkL qd67+sbFs2wCozGMk+GbJyjUvejh7J4eFgtzp/5ts3DdX54yV75/izhFR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgBABIE8lY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqYI5gkEQflTyCDh8LhS5KAoMoFgECAQEBAQEBAWsohRUBAQE?= =?us-ascii?q?BAgEBATY2CxALDgouJzAGAQwGAgEBiXQIDq9uil8BAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEYBYZOggUIYIIChD6FewWPW4xokjuKUoZTiziIDyYDLj5GIxYIFxVBhld?= =?us-ascii?q?ANYkyAQEB?= X-IronPort-AV: E=Sophos;i="5.36,168,1486425600"; d="scan'208";a="693005304" 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; 15 Mar 2017 10:12:23 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2FACN4g004503; Wed, 15 Mar 2017 10:12:23 GMT To: Martin Bjorklund , phil@juniper.net References: <20170314.215041.1542757804066431921.mbj@tail-f.com> <201703142223.v2EMNpnW074003@idle.juniper.net> <20170315.082814.1668142020606045450.mbj@tail-f.com> Cc: netmod@ietf.org, joey.boyd@adtran.com From: Robert Wilton Message-ID: Date: Wed, 15 Mar 2017 10:12:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170315.082814.1668142020606045450.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 10:12:41 -0000 Hi, On 15/03/2017 07:28, Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >>> Phil Shafer wrote: >>>> Martin Bjorklund writes: >>>>>> What are your thoughts on this? Surely, an augment should not have to >>>>>> contain if-feature statements of all parents of the augmented node. >>>>> The spec says: >>>>> >>>>> When a server implements a module containing an "augment" statement, >>>>> that implies that the server's implementation of the augmented module >>>>> contains the additional nodes. >>>>> >>>>> Compare with a simple augment of a node w/o an if-feature. In this >>>>> case, if the server implements the augmenting module, it MUST also >>>>> implement the augmented module. >>>> It implements the module, but it doesn't implement the nodes >>>> since it doesn't express the feature. IMHO this is a tool >>>> bug and/or an errata,since otherwise one has to carry features >>>> forward, repeating the if-feature using the original modules >>>> prefix:feature-name on every augment of feature-based nodes. >>> Well, I agree that it would have been better to state that if a server >>> doesn't implement the augment target, then it doesn't implement the >>> augment either. But the text is pretty clear; this is not how it >>> works. This is not appropriate to "fix" in an errata. >> I'm missing the part of the text that's clear. The above quoted >> section certainly doesn't say this. That text is saying "if you >> implement a module that augments a set of nodes, then the server's >> schema for that original set of nodes now includes the new set of >> nodes". It's referring to schema nodes. > It explicitly says that server's *implementation* of the augmented > module contains the additional nodes. Section "5.6.5. Implementing a Module", doesn't mention features at all. Section "5.6.2. Optional Features" doesn't mention implementation at all. It only writes about portions of a model that are conditional, supported, or valid. Section "7.20.1. The "feature" Statement" also doesn't mention implementation, it only writes about portions of the model being conditional. So, I find the text that you are quoting as ambiguous in respect to its applicability to features. > > If you don't advertise a certain module, I don't think you can claim > that your implementation contains that module. I agree with this. > > And similarly, if you don't advertise a feature, I don't think you can > claim that your implementation implements nodes that are conditional > on that feature. I'm not convinced that the RFC text supports this view. The nodes could be implemented but conditionally not supported. > >> And if those schema nodes are conditional based on if-feature, then >> those nodes are still in the schema, but are not supported by a >> server unless the if-feature condition evaluates to true. >> >> I don't see a conflict, >> it's just a case that we didn't think about >> or write about. > This I agree with. > >> It's a case that's not clearly handled in the spec, >> for which reasonable implementations can disagree. That's a bug >> in the spec and it that can be clarified via errata. I also think that this needs to be clarified one way or the other. I would also prefer it to be allowed to augment a node that is conditional on an if-feature without having to restate the if-feature condition, in exactly the same way that it is allowed to augment a node with a when statement without having to restate the when statement in the augmentation. Rob >> >> Thanks, >> Phil >> > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Wed Mar 15 03:20:42 2017 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 15894129A9E for ; Wed, 15 Mar 2017 03:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsBG-pPQSIAe for ; Wed, 15 Mar 2017 03:20:39 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A0255129A9D for ; Wed, 15 Mar 2017 03:20:39 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 79E131AE02A7; Wed, 15 Mar 2017 11:20:38 +0100 (CET) Date: Wed, 15 Mar 2017 11:20:44 +0100 (CET) Message-Id: <20170315.112044.1525149482580030224.mbj@tail-f.com> To: rwilton@cisco.com Cc: phil@juniper.net, netmod@ietf.org, joey.boyd@adtran.com From: Martin Bjorklund In-Reply-To: References: <201703142223.v2EMNpnW074003@idle.juniper.net> <20170315.082814.1668142020606045450.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 10:20:41 -0000 Robert Wilton wrote: > Hi, > > On 15/03/2017 07:28, Martin Bjorklund wrote: > > Phil Shafer wrote: > >> Martin Bjorklund writes: > >>> Phil Shafer wrote: > >>>> Martin Bjorklund writes: > >>>>>> What are your thoughts on this? Surely, an augment should not have to > >>>>>> contain if-feature statements of all parents of the augmented node. > >>>>> The spec says: > >>>>> > >>>>> When a server implements a module containing an "augment" statement, > >>>>> that implies that the server's implementation of the augmented module > >>>>> contains the additional nodes. > >>>>> > >>>>> Compare with a simple augment of a node w/o an if-feature. In this > >>>>> case, if the server implements the augmenting module, it MUST also > >>>>> implement the augmented module. > >>>> It implements the module, but it doesn't implement the nodes > >>>> since it doesn't express the feature. IMHO this is a tool > >>>> bug and/or an errata,since otherwise one has to carry features > >>>> forward, repeating the if-feature using the original modules > >>>> prefix:feature-name on every augment of feature-based nodes. > >>> Well, I agree that it would have been better to state that if a server > >>> doesn't implement the augment target, then it doesn't implement the > >>> augment either. But the text is pretty clear; this is not how it > >>> works. This is not appropriate to "fix" in an errata. > >> I'm missing the part of the text that's clear. The above quoted > >> section certainly doesn't say this. That text is saying "if you > >> implement a module that augments a set of nodes, then the server's > >> schema for that original set of nodes now includes the new set of > >> nodes". It's referring to schema nodes. > > It explicitly says that server's *implementation* of the augmented > > module contains the additional nodes. > Section "5.6.5. Implementing a Module", doesn't mention features at > all. > Section "5.6.2. Optional Features" doesn't mention implementation at > all. It only writes about portions of a model that are conditional, > supported, or valid. > Section "7.20.1. The "feature" Statement" also doesn't mention > implementation, it only writes about portions of the model being > conditional. > > So, I find the text that you are quoting as ambiguous in respect to > its applicability to features. > > > > > > > If you don't advertise a certain module, I don't think you can claim > > that your implementation contains that module. > I agree with this. > > > > > And similarly, if you don't advertise a feature, I don't think you can > > claim that your implementation implements nodes that are conditional > > on that feature. > I'm not convinced that the RFC text supports this view. The nodes > could be implemented but conditionally not supported. The same can be said about a whole module; it could be implemented but temporarily disabled. > >> And if those schema nodes are conditional based on if-feature, then > >> those nodes are still in the schema, but are not supported by a > >> server unless the if-feature condition evaluates to true. > >> > >> I don't see a conflict, > >> it's just a case that we didn't think about > >> or write about. > > This I agree with. > > > >> It's a case that's not clearly handled in the spec, > >> for which reasonable implementations can disagree. That's a bug > >> in the spec and it that can be clarified via errata. > I also think that this needs to be clarified one way or the other. > > I would also prefer it to be allowed to augment a node that is > conditional on an if-feature without having to restate the if-feature > condition, in exactly the same way that it is allowed to augment a > node with a when statement without having to restate the when > statement in the augmentation. Just to be clear - I prefer this as well. I also think the same thing applies to normal augment w/o features; if you implement module A that has an augment of B, and you don't implement B, you should still be able to state that you implement A. But I don't think it can be done in an errata. /martin From nobody Wed Mar 15 03:51:02 2017 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 2B5DF129B0E for ; Wed, 15 Mar 2017 03:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 p9edyyflqDx6 for ; Wed, 15 Mar 2017 03:51:00 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550BF129AF9 for ; Wed, 15 Mar 2017 03:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4485; q=dns/txt; s=iport; t=1489575059; x=1490784659; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=THrknMwW9CD1ae6POITjFeyiaX6o6B56KQ2p0/pHUkg=; b=aKIjXyTucoYw+UcHdmfA2a99ble0x5uytXT70FB75Zi2MoABOhlG8P4f Fp8HtgGSHLdW9sIRPh9AnF+AdbC+2NGkmqx1wK5MQJFrplUsofMlVLGgN YCOL3WKLZanukKDILUZPDGsyuqxNszL9z0nHwag5Te8WZVd6Q9ukr9D2K E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAgB/G8lY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhFxgjmCQY5dKhiICgykVAQIBAQEBAQEBayiFFgEFOEEQCw4KLlc?= =?us-ascii?q?GDQYCAQGJfK99il8BAQEBAQEBAQEBAQEBAQEBASGGToIFaIIChD6FewEEj1uMa?= =?us-ascii?q?JI7ilKGU4s4iA81IoEEIxYIFxWFGB2BY0A1hnUqghMBAQE?= X-IronPort-AV: E=Sophos;i="5.36,168,1486425600"; d="scan'208";a="651464403" 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; 15 Mar 2017 10:50:57 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2FAouxr015265; Wed, 15 Mar 2017 10:50:57 GMT To: Martin Bjorklund References: <201703142223.v2EMNpnW074003@idle.juniper.net> <20170315.082814.1668142020606045450.mbj@tail-f.com> <20170315.112044.1525149482580030224.mbj@tail-f.com> Cc: phil@juniper.net, netmod@ietf.org, joey.boyd@adtran.com From: Robert Wilton Message-ID: Date: Wed, 15 Mar 2017 10:50:57 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170315.112044.1525149482580030224.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 10:51:01 -0000 On 15/03/2017 10:20, Martin Bjorklund wrote: > Robert Wilton wrote: >> Hi, >> >> On 15/03/2017 07:28, Martin Bjorklund wrote: >>> Phil Shafer wrote: >>>> Martin Bjorklund writes: >>>>> Phil Shafer wrote: >>>>>> Martin Bjorklund writes: >>>>>>>> What are your thoughts on this? Surely, an augment should not have to >>>>>>>> contain if-feature statements of all parents of the augmented node. >>>>>>> The spec says: >>>>>>> >>>>>>> When a server implements a module containing an "augment" statement, >>>>>>> that implies that the server's implementation of the augmented module >>>>>>> contains the additional nodes. >>>>>>> >>>>>>> Compare with a simple augment of a node w/o an if-feature. In this >>>>>>> case, if the server implements the augmenting module, it MUST also >>>>>>> implement the augmented module. >>>>>> It implements the module, but it doesn't implement the nodes >>>>>> since it doesn't express the feature. IMHO this is a tool >>>>>> bug and/or an errata,since otherwise one has to carry features >>>>>> forward, repeating the if-feature using the original modules >>>>>> prefix:feature-name on every augment of feature-based nodes. >>>>> Well, I agree that it would have been better to state that if a server >>>>> doesn't implement the augment target, then it doesn't implement the >>>>> augment either. But the text is pretty clear; this is not how it >>>>> works. This is not appropriate to "fix" in an errata. >>>> I'm missing the part of the text that's clear. The above quoted >>>> section certainly doesn't say this. That text is saying "if you >>>> implement a module that augments a set of nodes, then the server's >>>> schema for that original set of nodes now includes the new set of >>>> nodes". It's referring to schema nodes. >>> It explicitly says that server's *implementation* of the augmented >>> module contains the additional nodes. >> Section "5.6.5. Implementing a Module", doesn't mention features at >> all. >> Section "5.6.2. Optional Features" doesn't mention implementation at >> all. It only writes about portions of a model that are conditional, >> supported, or valid. >> Section "7.20.1. The "feature" Statement" also doesn't mention >> implementation, it only writes about portions of the model being >> conditional. >> >> So, I find the text that you are quoting as ambiguous in respect to >> its applicability to features. >> >> >> >>> If you don't advertise a certain module, I don't think you can claim >>> that your implementation contains that module. >> I agree with this. >> >>> And similarly, if you don't advertise a feature, I don't think you can >>> claim that your implementation implements nodes that are conditional >>> on that feature. >> I'm not convinced that the RFC text supports this view. The nodes >> could be implemented but conditionally not supported. > The same can be said about a whole module; it could be implemented but > temporarily disabled. > >>>> And if those schema nodes are conditional based on if-feature, then >>>> those nodes are still in the schema, but are not supported by a >>>> server unless the if-feature condition evaluates to true. >>>> >>>> I don't see a conflict, >>>> it's just a case that we didn't think about >>>> or write about. >>> This I agree with. >>> >>>> It's a case that's not clearly handled in the spec, >>>> for which reasonable implementations can disagree. That's a bug >>>> in the spec and it that can be clarified via errata. >> I also think that this needs to be clarified one way or the other. >> >> I would also prefer it to be allowed to augment a node that is >> conditional on an if-feature without having to restate the if-feature >> condition, in exactly the same way that it is allowed to augment a >> node with a when statement without having to restate the when >> statement in the augmentation. > Just to be clear - I prefer this as well. I also think the same thing > applies to normal augment w/o features; if you implement module A that > has an augment of B, and you don't implement B, you should > still be able to state that you implement A. > > But I don't think it can be done in an errata. Does this just leave the behaviour as undefined then? I.e. it is up to the implementation to decide whether they error the augmentation. Rob > > > /martin > . > From nobody Wed Mar 15 05:05:56 2017 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 D0166129C60 for ; Wed, 15 Mar 2017 05:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy-bfDq7Q_0n for ; Wed, 15 Mar 2017 05:05:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DC186129C34 for ; Wed, 15 Mar 2017 05:05:51 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 1F8811AE02A7; Wed, 15 Mar 2017 13:05:50 +0100 (CET) Date: Wed, 15 Mar 2017 13:05:55 +0100 (CET) Message-Id: <20170315.130555.1100205223171802711.mbj@tail-f.com> To: rwilton@cisco.com Cc: phil@juniper.net, netmod@ietf.org, joey.boyd@adtran.com From: Martin Bjorklund In-Reply-To: References: <20170315.112044.1525149482580030224.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 12:05:54 -0000 Robert Wilton wrote: > > > On 15/03/2017 10:20, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> Hi, > >> > >> On 15/03/2017 07:28, Martin Bjorklund wrote: > >>> Phil Shafer wrote: > >>>> Martin Bjorklund writes: > >>>>> Phil Shafer wrote: > >>>>>> Martin Bjorklund writes: > >>>>>>>> What are your thoughts on this? Surely, an augment should not have to > >>>>>>>> contain if-feature statements of all parents of the augmented node. > >>>>>>> The spec says: > >>>>>>> > >>>>>>> When a server implements a module containing an "augment" > >>>>>>> statement, > >>>>>>> that implies that the server's implementation of the augmented > >>>>>>> module > >>>>>>> contains the additional nodes. > >>>>>>> > >>>>>>> Compare with a simple augment of a node w/o an if-feature. In this > >>>>>>> case, if the server implements the augmenting module, it MUST also > >>>>>>> implement the augmented module. > >>>>>> It implements the module, but it doesn't implement the nodes > >>>>>> since it doesn't express the feature. IMHO this is a tool > >>>>>> bug and/or an errata,since otherwise one has to carry features > >>>>>> forward, repeating the if-feature using the original modules > >>>>>> prefix:feature-name on every augment of feature-based nodes. > >>>>> Well, I agree that it would have been better to state that if a server > >>>>> doesn't implement the augment target, then it doesn't implement the > >>>>> augment either. But the text is pretty clear; this is not how it > >>>>> works. This is not appropriate to "fix" in an errata. > >>>> I'm missing the part of the text that's clear. The above quoted > >>>> section certainly doesn't say this. That text is saying "if you > >>>> implement a module that augments a set of nodes, then the server's > >>>> schema for that original set of nodes now includes the new set of > >>>> nodes". It's referring to schema nodes. > >>> It explicitly says that server's *implementation* of the augmented > >>> module contains the additional nodes. > >> Section "5.6.5. Implementing a Module", doesn't mention features at > >> all. > >> Section "5.6.2. Optional Features" doesn't mention implementation at > >> all. It only writes about portions of a model that are conditional, > >> supported, or valid. > >> Section "7.20.1. The "feature" Statement" also doesn't mention > >> implementation, it only writes about portions of the model being > >> conditional. > >> > >> So, I find the text that you are quoting as ambiguous in respect to > >> its applicability to features. I have to agree. Reading the quoted text again, it is actually not clear what it tries to say. I did some digging, and it turns out that the text was added very late, as a part of the Gen-ART review (see https://mailarchive.ietf.org/arch/msg/netmod/rmt_T-lMcFm6MPoo8DwrVuZNUxA). So what it perhaps should have said was: When a server implements a module containing an "augment" statement, that implies that if the server implements the augmented node, its implementation of the augmented node contains the additional nodes. Also, it turns out that this text is in section 4.2.8 which is marked as non-normative (whole section 4). So now I am going to argue that the spec allows the case in the original question :) There is no normative text that says that an augment of a target node with an if-feature statement is illegal. If it is legal it must mean something. And the only reasonable interpretation is that if the server doesn't implement the feature, then it also doesn't implement the augmented nodes. (I still think it is unfortunate that the "doesn't implement a feature" case is handled differently than the "doesn't implement the module" case) /martin From nobody Wed Mar 15 05:26:20 2017 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 4EED1130889 for ; Wed, 15 Mar 2017 05:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 m6OiZhwzjGtk for ; Wed, 15 Mar 2017 05:26:17 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0090.outbound.protection.outlook.com [104.47.34.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCDD130154 for ; Wed, 15 Mar 2017 05:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HBzJuMVRht/IQl12EnRZFJ4ekNnX4e/lxUltRsGX8Og=; b=aucA+oTWzpWHbVH2EA16sP2yLKUd/sr4N3TayCwwBanKzJwlBQ19wQHVxla/31WK/rGSCTzMkxlXEtQvdnXM2lrNuoJEp88fVX4aojAAQhAd7RqbwLy+/sB/XxXN/VTFZydVVmDxJqVFUtD1MGR4K4UQXk5EBqr4zuc+0y0+Wmg= Received: from BLUPR05CA0072.namprd05.prod.outlook.com (10.141.20.42) by BN1PR05MB311.namprd05.prod.outlook.com (10.141.63.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 12:26:16 +0000 Received: from BY2FFO11FD029.protection.gbl (2a01:111:f400:7c0c::132) by BLUPR05CA0072.outlook.office365.com (2a01:111:e400:855::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5 via Frontend Transport; Wed, 15 Mar 2017 12:26:16 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BY2FFO11FD029.mail.protection.outlook.com (10.1.14.212) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.961.10 via Frontend Transport; Wed, 15 Mar 2017 12:26:16 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 15 Mar 2017 05:26:15 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v2FCQEoV029373; Wed, 15 Mar 2017 05:26:14 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v2FCLrw9080651; Wed, 15 Mar 2017 08:21:54 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201703151221.v2FCLrw9080651@idle.juniper.net> To: Martin Bjorklund CC: , In-Reply-To: <20170315.082814.1668142020606045450.mbj@tail-f.com> Date: Wed, 15 Mar 2017 08:21:53 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39850400002)(39450400003)(39410400002)(2980300002)(199003)(189002)(9170700003)(50986999)(8936002)(305945005)(189998001)(8676002)(86362001)(38730400002)(7696004)(53416004)(54356999)(6916009)(5660300001)(53936002)(356003)(2950100002)(105596002)(2906002)(76506005)(7126002)(106466001)(54906002)(2810700001)(47776003)(81166006)(50466002)(48376002)(5003940100001)(1076002)(6246003)(110136004)(77096006)(4326008)(229853002)(8276002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB311; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD029; 1:wvxVT7xXbTzfPw/0dzYsKlJcBbAteuchS/XpQ2nF1xyWQp3tUah46x2jRXgi+YYqMAeDogHD/dvEhKEsBWybDtcPrxgbU0JKekXVOnGq3LyRpoeluCF2apNhlo+j4924+xf6v0LJaFeAvaPcqJTWHz7N0of3JPcFoeLdLlql/r1xUMB3bPyflX8V/AaH1Ft428igyeDJN8ql0trEbQ0lOLPSc1T1Y2FCQxKLrfnZEW+zL8/sszG9rvTJgsL3lqqYcRPqqcjv+jnA4N4LZw9ara1sWBbfRNCCLCjAgHzWIkYcWrdxp8y+OtXHXwrwPsfnDrD9XiICTXqjLjDrQb40VVgfYJMGvznkOLEjoY8tXnLtoFlIfCyvb49qdJw5e//AgJGLfzs/A1wvxaNy6AXfLRcbwPDyNxxcz0GplfXngwiHQqqlwS95sIJgyomg0AnbLWgenBTtIJFpFzmD1Ep3AO13HNJk1JPtL/CM+qggz3CK5XtR++vCyLJhOOuWTPbWEE3OOWaB+oZWWF8eVV4+Ij0LtmS34UlScmHMCNt5aY6pjTINhvxclfK1QjiE0Riovk4EpOYVnjaljJ6UPrupYg== X-MS-Office365-Filtering-Correlation-Id: fe2a53d4-a8a7-47ef-50a2-08d46b9e7a2e X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN1PR05MB311; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB311; 3:WrlHWrqbM7gD3r1CdnbQulXBz7WOq5x7YW1oTXtjyC9A38DLHk2XlN/nBySePXiYHl34oJDqARneq+bzuw1wfn4BlrIWDQhNf47QjqP/Xs9UZyEKMl9AS7QPq+WHyj8Tl4VkkN4IHzZlnLaKcXwxXTa/Qglo3O1QHK3iQL1/WQSHq2ibOv8i+eLKc52WteTCKb66Na+ZeM2IonIUT203f7sab7nB73Jx12KkfuUUYRJk6fsfw45trPbXo3ddNjJUkmEWv/ldIOHqhbGyQQPOlDxVFveJslrKssS7w7H8wc9IOK6pQaBer/hy8lN9vcrKepNeVpcBsE0mIpn8NEjJvjJuZAyBG/k5NN9YsOIGyJ4BAjSC8xHnROeFmqW5B1hi; 25:5r6+vPJFGsXzeOu9cjPAviA/AOVBlKLtHHoIewt8BEFQcQVQYiwNEw74vKBWn5oT2jZuDIEHQRJ6fyY998OPwC1LBnfWtuz29rYRRnc2J4Aa3mB5OMfkZSQG6NwWKx1T59aJ8y4udM0NNM0TXc2Vhhuj7ql5bSwd7FQ9aGGI8Vu+ZvOT0SH6a//VHg8RCF9nOvw7wXfhGr1wKZRtNnzk/0TNp2rBam8eEwsvAKbMVARAeMcacWl/807VqwX7Y0ADn88ifL52eV4VFKAj12Jy2WwD8qFwZXv+xCGx6zJxNN4u7H7HgxlIdghPT1FEEYE1vxrJpP3CGrmT7No91FhUrBKIoc44XHorcCP2Fs/+Q5Urwg/4uI3luBWmmaxZsoSWcQ7newMG/YYeh3uusT/P0JDFhOyjvbSF4zWGc6lmqRoizMgq6cHrluYBgbBKV3SVCalUQBphrbwELxlYRYURiA== X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB311; 31:4HSeaeR/XXqTy3C1gBzzCrAeGoQExMq3kmdPVqWIhxMiKKaDOuIYzVgPC/4pMLPaMC2UHemQUYdS4qg+EG7BKwWjf91RFGE0TGjgvbYlHgyviqIFddEntSWIC0LXQqe7KvHzewdaQ7x6kKaMjj0tTdMMbxpRf62lJZMSUjAaoU6ozZ8VGIrvDPODJVTno58ecci0gThUmczz16/ExbklCMViwkWeIjoPrit93SE3LTBlWZwK35dHQTTbNmr1myYZuP093I4yxJKVVHHUzs7I0A==; 20:WwkhXzHS8taZ++nGcp8CsQ9VSrYBZArimyQcoWQBBQzd05mg2AF7VjY8UWBXpOgBRzjWfnw7zXwAtui6i17Lbj4OOH06zTsHy6BU7JnVOjvrqUFlNtgBZyMgwFPIrqv/Li33aVgB43kV2ouQuGbGA9hIc/iUwx5DHQhM87fLBOoPBrkk3XmbWn+EaXlGh7ch96horl0vhiLYzjpQjuPH1KcOfGrLOMD/tOXFK4Bvz/7NlbK3GpgRdsh9OcvO8+ABO8iQW0m3UYbpFgC2tpxvrGQq201ea+ASXduESjUjy6eJWhKwkEHvKBvWMqKh+fwELANHivm7TRyEBs+ivFYHVUqmVMYVcpbiu/yR+8iMwnGHz0I0jX/wmua9MiWnN2yGo+PioK8tmxwV3WIEik5NZsCTqbHUacA6UWG2SAHBiBrV+Rp43mjR3GosPk6bxVPli+PmHO3cY95CCt/Bb5rka442Q6WQ2LdjB3RYjORxbS0VnxFooqp012sg5L2W8yBa X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13018025)(13023025)(13024025)(13015025)(5005006)(8121501046)(13017025)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:BN1PR05MB311; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB311; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB311; 4:ik5T+KtcazR9u0eU68QgABsyOUKAkg85STy+1ePgaQ8akGmULzTPFNlnSwC95+tkjFillOdrTJeIUpb/KMsFEiaQ5VHJpKpcF35J/jKUK8OWDnP9yxql9SJc4dVOyU0gH5bGZOGEVv2oRADwu/Z+STCI/KuUwA4UN9dG9WSDPuRZAHwvnDhkvoi5YP0wgAOIPUJc/lXJsbzFAjZYpCnP6b1kDuNwuAhxNWwDc7Mhh5tdCpU/W5CDg9KwyOKugCP4NArnULI2pX7eTEKkhGyVJZSFcHPmm61bW85I+w16imsasUosztinqO0TjdhWU63bUZY1Kt7Lg+l9MS5pMw5hPoFz2hHphy+19iiUS+8NG7K1HUMYnCfBKnfyxwnKHrfrJpCeuLS/Fgn5po5mMTea6gk0JwGtBup/QEUuw76Xu1cWrB7lwUsbSgVOiJAoGNN0wB6Qy2JW7zXl8yWxmUGYxirq5kZOPcWX0rZ8cgw9GrkNNtL9OG9ZB83tqPP2+vWg2PQ36y+RUvECW69q3FWwPf9/4gS5EEM/SgHIP71RhyS8B8K6h7XsAXBAI+hwqQWvYt0TDDrG87yci2Wp5W51nEuTPiviuGSiKGsJOumAgVWpZOEQcx0JC+O3oU9GlFzMpKfjmjlhKGHMb50j/qDCSztXXzMaaTHWiAPuzks49mvv+S3EFtmBuAYSi++7Nd9tIuwdOivyyCz3Hk/X526HkCdpqIOu/eY60oxVnzKH/krAjl/GWWfjtRRt4CQZ6+yVu9MzQ/vKhl71+vNF2WoGEw== X-Forefront-PRVS: 02475B2A01 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB311; 23:oHYGH2LUrye7SOkqSSc+clqr2lO9axCi7hJt0xbbtv?= =?us-ascii?Q?4BdxbvYmVpuNdbutUwr08ZarJK4aokFtI1P9jGRnYkZ6GQcWC+1oEM6wnCgk?= =?us-ascii?Q?CT1k/xN/4Fh0LeexR2c9cI96dThhptayYFNcEhhLZc3lMWl1zsliVZMOmrT9?= =?us-ascii?Q?B0zelvBwCMV31SUuTsuJ82U61ZdlisXvE+DC/BhDXmI7xbG++GUtGnQvTRc7?= =?us-ascii?Q?TfCw4XFZIt70w+Vmsotf8yIXZq2+jW9U0844eGef62g7lq9cmQbysXdCO+c4?= =?us-ascii?Q?4sk8M2NU/7VgpichhBxJzwA52Y75pTMuS1Our4S95vSPC2G7bevYbq0DLAMB?= =?us-ascii?Q?AH8f9xTTdqVdvZt4faDYe3vkraT7HgA/y3OJhdba5YFGm/BU8+YytRn7LbMd?= =?us-ascii?Q?mSVWNTjLI76AmG6x2jguUm+kSfk9mZMfafs4MXpty+yXYYNwbir1EjfE/5mF?= =?us-ascii?Q?L6qnkrnjlm4C6Hqy2EEJ00koJYhpBTr9Pn1yr9G0Ta30DQjeABaIIOghzJv+?= =?us-ascii?Q?0LrHuz7aKwTtf8cmatwj/1QrhjKJs3FnW3fCznnzMQVazagPBnFoChq4QM4R?= =?us-ascii?Q?HADR+axDGn1TgMPUkZeiSfuJovMGsNGDgIQgrtnSHBuiEicgcDwIPaPxGydh?= =?us-ascii?Q?fRm8Mqg8bxqXlXWsZOxRfjNcdCpF0pznLkpUEVJCua65npD0roFkpnPoNvtP?= =?us-ascii?Q?dU5eA/etJwfRG5rZI5TAKriVKzf1eJIpgRU2pg5l8ghqCp+9fekDp4dQdtp9?= =?us-ascii?Q?M1EVPx81hCr4QbuI0Z0bbJlSb9ESfJMBZH2rShNLrhRO3xjnfMWPEBDdgXIF?= =?us-ascii?Q?HKzDrlyRv4XcvO2aTd1UHglet9AJeApB0QAOoVXEfQNA76Xs/k9xEymGNbBM?= =?us-ascii?Q?1H6kQlY9ZkIvMlhSK5yOBEsZvDSIZa/BEU5E8v/7Z9ZHpZZYUUvh/jxZ8GUf?= =?us-ascii?Q?NC2WnGqJwbXa+A9qlpiKLHAjxWaQHvJ9jImEIW3B35sY8re3LVbED0G81o/o?= =?us-ascii?Q?7Q8Mc0LTTWmFuFByeBkLsjQ0YZvT8urdM7RzU2wzpykuGZE9gzuVc2u0GIp3?= =?us-ascii?Q?70CoUHs7bY95dRki8k70CA0hW9+rwlfnJzrU6zDN9RGavoWw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB311; 6:VBO9lzv+nOPk6TP5BzXYSRQWa/4FOnV5D8itBYXlbvUefyO0zi6h7QjW6xGRyEDgBJKT4RMp4rusQjDXcG71hn/K9LvfdVh7vCdhuCNGN1wTE09IXEruTabCgSbM0W0xw6tLuNS1/WEX85pNVsg/UZBpyOlMo7A+P4Kzwo6ah6bfJrwalc6dPxWoyMwfFHL4I9Jnu7GjCnW7UyAVOa3ore6oWtc8htQELN3P2XcXiJ72bRsYDp4EIeCmawhy+R3EQA3JnkaKdRuWF1df8INVb3uvRSU1GGbUvoMrvGisUEQQhtt2D0KQuOLs3njix6hy4+QbO/IGGiTfgftRIvyM9ZIWfBzBFSU9km6+JePtY+/dziAH6dwQf/JjqqqCUQpNUbxFR+RTiaiJlorg4C4UQxWOD+nTqeaV1V3JuT5RHZU=; 5:M5ChjELFx3pZayrE4x365g0L466sOd4Ht5+1Q0ERh58NRTaW4g9SasoiTz0ileMVRM9MrQNKClwalRI+BHj3oP1iP4iaPQjSw0wXNc6wNeuC92RClLI3eCFoNDB5Xcr5tynX8CDJqSqGfAXC4j/i3pNfyi96KfHbNXVMaJ80LPA=; 24:CUD9tDSvNRMQV7Zy4Ngbm6sokQu1wb/oaEO6Mc9Y+WP42HW4kvLqFmI2sW7mC8s/9FMxZ4/T6kUbflfyOFVAMYNiCz9u9Pt6Y451VK9FtvY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB311; 7:SYb17dPFHsX2YPJg9JV8xAdAqUbnFqpDBKzCu4z0MnK1uFWwvhEEEyev/AUuWEw8Avsh+aNShRb8gp8W3iKf1XwS72py7CBQkVaFcYqTgNI+jM+ke26MWbgwtUE35YGFgcpTJHsRpClx9OdZRXxPNwPl6TLdTKhG7POUkTiyOk4iF2xgM/yOaIBoPjRnkVswLgoLyROUCB8KNIgz5CyCx66zgZwt/TswbQvp53SpHUzPqO8mORaYkP+bkGJBDVYHVR5wsxfn0t/YbDxhwUgFCRy9sTzd9aru1QhaZe3QbPmQaHcCw6kcyU0pL6SXkfpGv5GzUz4L7f4AofYT4b01zA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Mar 2017 12:26:16.2758 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB311 Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 12:26:19 -0000 Martin Bjorklund writes: >It explicitly says that server's *implementation* of the augmented >module contains the additional nodes. > >If you don't advertise a certain module, I don't think you can claim >that your implementation contains that module. The issue is that the module is advertised/implemented/supported but a feature of that module is not. If an module is also advertised/implemented/supported, is that module's author forced to repeat the if-feature conditionals for the first module? I think this is a bad idea/design/precedent, and makes life harder. >And similarly, if you don't advertise a feature, I don't think you can >claim that your implementation implements nodes that are conditional >on that feature. You certainly can. Consider the "feature local-storage" from the spec, where this feature indicates availability of local storage. The feature may be conditionally advertised, based on the presence of an SD card. But that's not even what the spec says. It's more narrow: > When a server implements a module containing an "augment" statement, > that implies that the server's implementation of the augmented module > contains the additional nodes. The "additional nodes" it's talking about are the _new_ nodes from the augmentation, not the original modules nodes. I think this is a case we did not consider previously and we should find a suitable answer and document it as errata, rather than leave it hanging in the breeze. Thanks, Phil From nobody Wed Mar 15 05:49:40 2017 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 EAB9D131485 for ; Wed, 15 Mar 2017 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6p1DLK-QnclU for ; Wed, 15 Mar 2017 05:49:38 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id B33AC131484 for ; Wed, 15 Mar 2017 05:49:38 -0700 (PDT) Received: (qmail 1041 invoked by uid 0); 15 Mar 2017 12:49:36 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 15 Mar 2017 12:49:36 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id wCpY1u01P2SSUrH01Cpbm6; Wed, 15 Mar 2017 06:49:36 -0600 X-Authority-Analysis: v=2.1 cv=H5NInYoi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=48vgC7mUAAAA:8 a=nLi1NlykcDppTQkCK4wA:9 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=kvv+pZNncBtNEq/PB4NT+JDMyClu93gzSJWtbZzKQu8=; b=bUDXksh3L+y4sheGLr7lrq/pyd 6QJ+irtKzTHPX2IOej71ObGG2qEcbcmpOOSwSTcUgpVvHV8p6hUf3HBk7ivA2R9mQqUEB0cxA3XUp qKNz26pXJkx4C+tNhLjrUA5Ep; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:38858 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1co8Mu-0004wO-OY; Wed, 15 Mar 2017 06:49:32 -0600 To: NetMod WG References: <8c395501-8b28-9a08-1be7-1ec89bd2e0cc@labn.net> Cc: NetMod WG Chairs From: Lou Berger Message-ID: Date: Wed, 15 Mar 2017 08:49:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <8c395501-8b28-9a08-1be7-1ec89bd2e0cc@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1co8Mu-0004wO-OY X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:38858 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] Draft Chicago Agenda Posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 12:49:40 -0000 WG, It looks like we're likely to need the extra time, so please expect that the updated agenda will include both session: Session 1: TUESDAY, March 28, 2017 09:00-11:30 Tuesday Morning Session I (2:30 hours) Zurich G Session 2: THURSDAY, March 30, 2017 17:40-18:40 Thursday Afternoon Session III (1 hour) Zurich D Lou and Kent On 3/14/2017 5:14 PM, Lou Berger wrote: > All, > > Thanks to our WG Secretary we have a draft agenda for Chicago posted at: > https://datatracker.ietf.org/meeting/98/agenda/netmod/ > > Please let us know if anything is missing. > > The draft has us meeting for 2.5 hours in a single session. Our > original intent was to meet for 3 hours over two sessions, but we see a > couple of advantages of fitting into just one 2.5 hour session - iff > this doesn't limit WG progress. As the current agenda is full, we will > move back to 2 sessions if any additional agenda requests need to be > satisfied. > > Thanks > > Lou (Kent, and Michael) > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Mar 15 06:50:13 2017 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 9ED18131511 for ; Wed, 15 Mar 2017 06:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 gD4ruk-Uglkr for ; Wed, 15 Mar 2017 06:50:08 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51004131512 for ; Wed, 15 Mar 2017 06:50:08 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id u48so11448781wrc.0 for ; Wed, 15 Mar 2017 06:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=mdFPHQvBmEc3s6P25XKrZpb0E7+NtdUj7Ad7RazS344=; b=HXr+gFATGlL/dd79sjdMzFLk0aUNh/WXGB0aQpgixZuSP6FmRLHQ8RutsdIy6oBxSm Vwe9x28hNgYlr86cCYErPvHfp85oIRtzf/T8zyWnIyiSJ84A6rUhncYdAfSl+1GgTZDx 4SyQWXu9T5k9yJmZN9EwPy7m4FGlkFsF2MJ9xMIJcKV0NwbL6qH0kacSNnn/wi86wCNE iKUCMe6fkBQfYeB7LytgtHM7Y4jvk95wOXruDVcE6ioZTxtL9s2NUgs4oR0EO/1vhXrF 8pc8mOQBtTDiWMEAAD5lqv/TKbN64n2EBMvrIX/0bpUpeipFxGEDnaTsg5vjxFWiYPSB k/8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=mdFPHQvBmEc3s6P25XKrZpb0E7+NtdUj7Ad7RazS344=; b=c9VjP+SG2AEbwuFphdQk/9rmdx6KcRmvWJ+BAH8n4095YbBB6gH7wEoMj/+FuqQM7O 22/gfrrtwovqNN3AhwgseuZmuTnuDMb8+KFSOSk+twcdArRj9OWVnoFcgSSnQ/aWtdIB hEu66GudMduBAHDFFU1Qafw8y99XJToPWAf/ML0GNq2ensySPZkcpggyDLa4ogjJqxCF zgsrrdNYvxeHcTNW6W0EaVKqp7P6EzIjndcsMj9EXb+XQuOchZ3WKSLrXKO98JYvjW+/ VMoblH8b5Ryrrm3/CSMv5c3+XfF9fItCEZQ7uQNJioPXe5YHQohYamczLsPROJWc8ihC 6t6Q== X-Gm-Message-State: AFeK/H1JikA9RwDMhaUhzo+jqcpxLsvK422C2AYx6W8lpt7PFfVNn/AFz2P2FTcPGMaQPg== X-Received: by 10.223.129.230 with SMTP id 93mr3094152wra.41.1489585806611; Wed, 15 Mar 2017 06:50:06 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p5DCC645C.dip0.t-ipconnect.de. [93.204.100.92]) by smtp.gmail.com with ESMTPSA id o52sm2438561wrb.51.2017.03.15.06.50.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 06:50:06 -0700 (PDT) From: "Mehmet Ersue" To: "'Lou Berger'" , "'Kent Watsen'" , References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> In-Reply-To: Date: Wed, 15 Mar 2017 14:50:06 +0100 Message-ID: <02e701d29d93$0e770480$2b650d80$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUoqgvM/28IAKaKVw Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0203.58C9468D.0273,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:50:12 -0000 Hi Lou, Kent, it appears to me the issues I raised below are not closed. I believe at least a "minimal" WG item focus formulation is required to match to the high-level WG focus topics in a)-f). I was thinking my proposal below is acceptable. Netconf WG will ensure avoiding double-work concerning the DS concept draft, however Netconf needs to specify what is required for the use of the DS concept from protocol standards pov. That said different people including Netconf WG co-chairs think the DS concept document is Informational in nature and should be published as an Informational concept to be used in and adopted for the needs in diverse protocol WGs. This is as I think also important to avoid an overlapping between NETCONF and NETMOD charters. PS: I expect that most of the Netconf WG member read also the Netmod maillist and therefor skip sending to both ML. Thanks, Mehmet > -----Original Message----- > From: Mehmet Ersue > Sent: Thursday, March 9, 2017 7:36 PM > To: Lou Berger ; 'Kent Watsen' ; > netmod@ietf.org > Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' > > Subject: RE: [netmod] draft netmod charter update proposal > > Hi Lou, > > > The charters from the last couple of years don't have the intended status -- > at least the ones we checked. > > I actually feel pretty strongly about this (which of course can be > > easily overruled by our AD). It's my experience that premature > > discussions on intended status, i.e., before a document is sufficiently > mature, leads to process-focused arguments that detracts from making > technical progress. While once a document is mature and core > direction/content is fixed, it is generally obvious what status is appropriate. > > The charters from the last couple of years have a short WG item definition, > which would be IMO sufficient. > You are right the intended status is not available since a few years, but IMO it > is part of the target definition and would be very useful for the draft authors > and WG members to regard. > > > > It would be good to bring the high-level topics in relation to the WG > items. > > I'm sorry, I don't understand this last sentence can you rephrase it? > > What I meant is that the high-level topics a)-f) might be good as WG focus > description but are not sufficient as draft target definition. > If you think the high-level topic description is more or less the WG item > definition, then we could simply write "this is achieved with WG item XY". > If not, we could keep the high-level focus text but set additionally the > borders of the WG item with some concrete words. > > > > BTW: We agreed in diverse discussions that the DS concept is > Informational in nature. > > > I think this should be corrected in the draft. > > > > So this sounds like an objection to a specific document. This is a > > fair point to raise, but in our opinion it is not a charter impacting > > point or discussion. If this is in fact the issue you'd like to raise > > and discuss, lets do so under a document specific thread, e.g., "Subject: > intended status of revised-datastore". > > I am actually raising this point since November meeting. There are different > threads where I explained why it is appropriate as Informational. > The last thread I remember is at: > https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH1 > 1xcY > The recent position of NETCONF co-chairs is in > https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd > 8qr5k > > Thank you for your consideration. > > Regards, > Mehmet > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, March 8, 2017 11:28 PM > > To: Mehmet Ersue ; 'Kent Watsen' > > ; netmod@ietf.org > > Subject: Re: [netmod] draft netmod charter update proposal > > > > Hi Mehmet, > > > > On 3/8/2017 4:47 PM, Mehmet Ersue wrote: > > > Kent, > > > > > >> we understand that this is how NETCONF charters are structured, but > > >> it is not our practice, > > > AFAIK it was the NETMOD practice for the charters until today. > > > > The charters from the last couple of years don't have the intended > > status -- at least the ones we checked. > > > > I actually feel pretty strongly about this (which of course can be > > easily overruled by our AD). It's my experience that premature > > discussions on intended status, i.e., before a document is > > sufficiently mature, leads to process-focused arguments that detracts from > making technical progress. > > While once a document is mature and core direction/content is fixed, > > it is generally obvious what status is appropriate. > > > > > > > I did not ask > > > more than written in the current charter. > > > It would be good to bring the high-level topics in relation to the WG > items. > > I'm sorry, I don't understand this last sentence can you rephrase it? > > > > >> as the information is available at the top of each draft, and also > > >> because > > this information need not be fixed when the milestone is added. > > > > > I believe a WG charter should be self-sufficient covering the target > > > definition and intended status of the WG items. > > > Otherwise one can change the target for a WG item by simply editing > > > the draft abstract anytime. > > > > Per IETF process, all it ever takes to make a change in document > > status is WG consensus, and then IESG and IETF buy-in as part of the > publication process. > > > > > BTW: We agreed in diverse discussions that the DS concept is > > > Informational in nature. > > > I think this should be corrected in the draft. > > > > So this sounds like an objection to a specific document. This is a > > fair point to raise, but in our opinion it is not a charter impacting > > point or discussion. If this is in fact the issue you'd like to raise > > and discuss, lets do so under a document specific thread, e.g., "Subject: > > intended status of revised-datastore". > > > > Thanks, > > Lou > > > > > > > > Mehmet > > > > > >> -----Original Message----- > > >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent > > >> Watsen > > >> Sent: Wednesday, March 8, 2017 7:45 PM > > >> To: netmod@ietf.org > > >> Cc: netmod-chairs@ietf.org > > >> Subject: Re: [netmod] draft netmod charter update proposal > > >> > > >> > > >> > > >> > > >> Hi NETMOD WG, > > >> > > >> Please find below draft-4 having the following change: > > >> > > >> - added "(e.g., I2RS, RTGWG)" to a sentence. > > >> > > >> Hi Sue, Lou and I looked at the proposed charter and found a > > >> sentence that nicely describes our WG's intent to work with and > > >> support other WGs (beyond NETCONF), but we felt that the text could > > >> be made more clear by adding in the above-mentioned change. Beyond > > >> this, and the existing a), > > > b), > > >> and c), we believe that the charter proposal covers our support for > > >> I2RS, > > > do > > >> you agree? > > >> > > >> Hi Mehmet, regarding putting a short description and the intended > > >> status > > > for > > >> each draft into the charter, we understand that this is how NETCONF > > > charters > > >> are structured, but it is not our practice, as the information is > > > available at the > > >> top of each draft, and also because this information need not be > > >> fixed > > > when > > >> the milestone is added. > > >> > > >> All, Any other comments? > > >> > > >> Kent > > >> > > >> > > >> > > >> > > >> Network Modeling (NETMOD) > > >> ------------------------- > > >> > > >> Charter > > >> > > >> Current Status: Active > > >> > > >> Chairs: > > >> Lou Berger > > >> Kent Watsen > > >> > > >> Operations and Management Area Directors: > > >> Benoit Claise > > >> Joel Jaeggli > > >> > > >> Operations and Management Area Advisor: > > >> Benoit Claise > > >> > > >> Secretary: > > >> Zitao (Michael) Wang > > >> > > >> Mailing Lists: > > >> General Discussion: netmod@ietf.org > > >> To Subscribe: https://www.ietf.org/mailman/listinfo/netmod > > >> Archive: https://mailarchive.ietf.org/arch/browse/netmod/ > > >> > > >> Description of Working Group: > > >> > > >> The Network Modeling (NETMOD) working group is responsible for > > >> the YANG > > >> data modeling language, and guidelines for developing YANG models. > > The > > >> NETMOD working group addresses general topics related to the use > > >> of > > the > > >> YANG language and YANG models, for example, the mapping of YANG > > >> modeled > > >> data into various encodings. Finally, the NETMOD working group > > >> also defines core YANG models used as basic YANG building blocks, > and > > >> YANG models that do not otherwise fall under the charter of any other > > >> IETF working group. > > >> > > >> The NETMOD WG is responsible for: > > >> > > >> a) Maintaining the data modeling language YANG. This effort entails > > >> periodically updating the specification to address new requirements > > >> as they arise. > > >> > > >> b) Maintaining the guidelines for developing YANG models. This effort > > >> is primarily driven by updates made to the YANG specification. > > >> > > >> c) Maintaining a conceptual framework in which YANG models are > used. > > >> This effort entails describing the generic context that in YANG > > >> exists and how certain YANG statements interact in that context. > > >> An example of this is YANG's relationship with datastores. > > >> > > >> d) Maintaining encodings for YANG modeled data. This effort entails > > >> updating encodings already defined by the NETMOD working (XML > and > > >> JSON) to accommodate changes to the YANG specification, and > > defining > > >> new encodings that are needed, and yet do not fall under the charter > > >> of any other active IETF working group. > > >> > > >> e) Maintaining YANG models used as basic YANG building blocks. This > > >> effort entails updating existing YANG models (ietf-yang-types and > > >> ietf-inet-types) as needed, as well as defining additional core YANG > > >> data models when necessary. > > >> > > >> f) Defining and maintaining YANG models that do not fall under the > > >> charter of any other active IETF working group. > > >> > > >> The NETMOD working group consults with the NETCONF working > group > > to > > >> ensure that new requirements are understood and can be met by the > > >> protocols (e.g., NETCONF and RESTCONF) developed within that > working > > >> group. The NETMOD working group coordinates with other working > > groups > > >> (e.g., I2RS, RTGWG) on possible extensions to YANG to address new > > >> modeling requirements and, when needed, which group will run the > > >> process on a specific model. > > >> > > >> The NETMOD working group does not serve as a review team for > YANG > > >> modules developed by other working groups. Instead, the YANG > > doctors, > > >> as organized by the OPS area director responsible for network > > >> management, will act as advisors for other working groups and provide > > >> YANG reviews for the OPS area directors. > > >> > > >> Milestones: > > >> > > >> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for publication > > >> Mar 2017 - Submit draft-ietf-netmod-yang-model-classification to IESG > > >> for publication > > >> Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for publication > > >> Apr 2017 - Submit draft-ietf-netmod-entity to IESG for publication > > >> Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG for > > > publication > > >> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for > > > publication > > >> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for > > >> publication > > >> Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > > >> publication > > >> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for > > >> publication > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > From nobody Wed Mar 15 06:56:30 2017 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 E265B131529 for ; Wed, 15 Mar 2017 06:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 Fg2Zt4aOeJks for ; Wed, 15 Mar 2017 06:56:27 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0092.outbound.protection.outlook.com [104.47.37.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF780131537 for ; Wed, 15 Mar 2017 06:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hSUy4zWCgBa5oiQBv86IZ+HS7I73hkC024c3kx1SKrw=; b=Wl91RaOzYUmN6KZhLz5e9dKV8mQ8ZBqic3KBX8G9Z0ueTerR9+cUmKk+NQ1TU60pP6JPKnWAxUMG8JNZQVLR+EwJDtESmW2btIKHH/NPDGhBtvgQ4+Qxmt1wuP6dnCKe30K5n1AhJuGxClrfG15bMoub4TLym/IlklwfN+1bH2I= Received: from DM2PR0501CA0010.namprd05.prod.outlook.com (10.162.29.148) by BLUPR05MB305.namprd05.prod.outlook.com (10.141.23.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 13:56:22 +0000 Received: from BN1BFFO11FD047.protection.gbl (2a01:111:f400:7c10::1:159) by DM2PR0501CA0010.outlook.office365.com (2a01:111:e400:5148::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5 via Frontend Transport; Wed, 15 Mar 2017 13:56:22 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1BFFO11FD047.mail.protection.outlook.com (10.58.145.2) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.961.10 via Frontend Transport; Wed, 15 Mar 2017 13:56:21 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 15 Mar 2017 06:55:59 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v2FDtvUp022662; Wed, 15 Mar 2017 06:55:58 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v2FDpU3s081481; Wed, 15 Mar 2017 09:51:35 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201703151351.v2FDpU3s081481@idle.juniper.net> To: Robert Wilton CC: Martin Bjorklund , , In-Reply-To: Date: Wed, 15 Mar 2017 09:51:30 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39410400002)(39860400002)(39850400002)(39450400003)(2980300002)(199003)(189002)(9170700003)(106466001)(5660300001)(47776003)(105596002)(50986999)(53936002)(54356999)(54906002)(77096006)(5003940100001)(356003)(6666003)(8276002)(6916009)(53416004)(2950100002)(229853002)(76506005)(7696004)(1076002)(38730400002)(110136004)(189998001)(2810700001)(86362001)(8936002)(4326008)(6246003)(48376002)(305945005)(81166006)(7126002)(8676002)(2906002)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB305; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD047; 1:12Bobai8ql5I1rKPW1NeDR/xTPMo6TZxw0XtK18vs09ZMwrLnoihSsEbge7yUDZ9qFtqb1Cb+ny+U4RHDlNWGZwu/mZ6F9EN3ub9m6qilV2D6Xsu7KD6e4fSGR7LpqK6AAGqKSYKdAA9BmBIy75wPqwEd7XUNeo6JuwSIzGtztwjGCFwv2UsvsiVf4M4uma05M3HWgtZV3L1pe+NYrLDaWeWLcQ6ree+/VC14MVDdBH77ntyVyH0rvRk5GVmB42CpZYoo66fsOpnhzCm9PiG9MNneAoI6QBwunGLV0zik6AE+foNjRKcR7Di0KQVNEUXbZ8TkVm6icDsfwuPkZLwCA+cYn/bTOe+VppxotJVbY9s38b+GlSvO9CNGOr0Rv5cJ5GKPoJY0Dc/n/lNTtTaH70bTzExfCF01hsjEX8PBq8FKCGP0y80/BmPIiyLQivn8TAEYLpk033UKX5gMwWYaVvn0uLMuORDVMXzQqjsYdc1s3mVNj9IRh9FPkcgCC198mZMPT1F7ylabVcR+bwv7FFj4jt3e4Sg4j2yAJfZfPAMdAmTRu4Bc3QdkEa8VGL+ssPcM0ToLwaXW1Un5UAo/eS/KuiFzroF9D6hTmKNl6e3zRb/hhjihiY2NDmeD5Io X-MS-Office365-Filtering-Correlation-Id: 7f359e86-0910-44f3-2ee3-08d46bab1024 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BLUPR05MB305; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB305; 3:eXP9rU58g5yk8EqxKXJ7iEbJCVfQpuHqtPtHLXdpkCE6K+GyVBWu7BW8SqyGSVCdH6IVC7MDoJOp3GVFI/dXQgoytOYBNWwABP3qoickDBa2eWBAh+3Su/vQTpUyyTgqT21Pm4vwDTVPlTQAO68VVkp3QLefwxE2lu6Fff/4HyMd6QsBlQL00koeM0lT9Vtb4lXntlvaVWcrt01x2kym4BDdMVZtz4322n3hmzbnLCQoFX+vAnHiLUBM/LkMvKOSm1SrzbOy+KONMJ84ltSGwh0ifEeeFGOnNNhRYCVmcBeMkjYv1asfg44L1cK3VZgkU7mKzgXDQppWME7UHEfsH+2LjxjB1zea8npRlND8k6k8HwTuWC1pDh7VXROlG/o0; 25:t299z2kQH9eiWiKshNk9tAiOGJpblcPHlmzKOtgDpFY/Q3YeBXiRilwmtWWFS8OLH9WCoH0sopeLFqpho+LNDDhKA7WoKgv7FbJdIHkMucPrMn/teRilgtOPPiTXQsiWIGYdaHaeHh1uyI09vhQQH5HZtauU+l0Qg+P6bsKSa5uLErJ43Bh4mktiPH28eY2WWrIF1O5D2tll53TF7G3wPmF5P2sSKrUrjTPGMgLeQZSBO2w7o6RD2SgWy8xXhFxY6UxlXOv02fUViN+FbRoLyOVYWFT5rF7xNYWTqA0a/0vZkNVvcJOrrxgb0dqeezYRSaX2jU6ZM300xOvOLkul6bsD/Cg9MpWanNYF0h+vejK8nPAjCcB6WcVuZqsP+dY7S8I4uKAJWjiN9z1601E1I2dwkdd1rBRr5geFxdCEuq90njlRU2+KH8n929RFZoCMcxpfmq0qon5I7K0ZE0hvAA== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB305; 31:WZGHIUnF/AbXAIrLJa2ZkhquDr/NveJlUotDW7btJnP80t+H7Frq8mbHVAColFJlvSP1p57dNqqrgR5OsaonseUuh9ApiuQ5MhT+/cPWCA13utoA/QsaC8AbkIH7LZFWRrEyXaXNxM9t1ccbkjdJE/cPWynzlOctXDgU49MRAIDh+My9GmT5QiP31DFBF5JyFiNAPl76xrLXgVPnchhYsra9zvh+lLxkP6QTAmGai41J6Ky5F8v5k2Ng9YeBL/T2Kk1NEGCvd8mc2xkYQlN6OA==; 20:d0rqCTXuvbIOvv8DksRe2Yv+CbXp4ByxSMXxVFAREgIUQZ4XMDetxZxz5GDX2Vpii6Zn9hIS7QP/7ZF84CUJi4hUu7NXJHJcShD6RMSIJBBqhscUpDjS8L1Sb2IfqzMn7+alBKFKAFV0S2Xjr/anCiSeAcIPUeS1nbDDG+lkloXwic/Ns34LCe7qcsLlOQbFQJl/kdoRd9MAWtxn6QJ3RHLixr0zdCXdTs404BYG9g9qq0moLwgJnRfwceygQCVDx54YbfAuuTvuACdGcNPMtz3vybC1LMHA9kK3MB5hO68PRyp48ngvXWOsfgT19u8rptqf4VTbaRfzgotXCA+8Wic1O+SOOYvEtN13QAJj1HJ/40A15ogYsnY2EaoqK0+ukagqOt7ER5wHTtYNmVDEO12U8PlUWtm1TS9VKYlfkh05YLyp8Kak6xwfHQcvpS/QMF0JKtueER6SsS0QWsCorn4pGo+Xjd48bwLB96oY0RpaPah7/2eyHMCaOC9G17gZ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13018025)(13024025)(13023025)(8121501046)(5005006)(13015025)(13017025)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123558025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:BLUPR05MB305; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB305; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB305; 4:JsoIn1FlAFYLpTFS0G3G81Q7aHBjU1e7gbv/aTa3adio1EseiRtiI2sybe2HPTK5yU8ebRXiua8gkLvL57t0wKtqxCFjwy1u6yIT3rnE3TeidiPX25H5+JdXjaKfKLca76lAm4D0gSsbo8n8SkRAC9k7plfjWwESAHjhuMEbj6xa3vM7FPcxRj1/YaG1QHL0FI1wJBuixGx5CjkS/vjj96GmgYeAuVSXE0QNOScx07r2HI7BGVNpZYukpW6PTv/g9ctcfCeeB+00La8keiuexUQKafvAbN89OSbsHrNspxjXBraQHNHWjYEKHfHESmUQK5HkQ8TRW25l/Wejbhk5bAEQczqOx2RU+rAMnuyJql0wHkMnbtMwJ2J8NT4njmWoT9L89hS0rycIu26JuTuP/b6NZUjr/f7wPyWbQnt/pziMYSN6fQtW/VDQXj8IZ0wP1GtFIZXxJWrBOqqARGPOvur0sPQ8Scvc0WatXBGwlfvatdNL18dRXKxWXLs89Ce6Ogb8hqy+n+62tdBvHDMHmHRnR2FXQrqciVXhT2qg5Y3WlzfJDpUS3WlbeTDK/DcxedFgFd2LoUaB+4Yl+p7gONikZCzBiW/D6pnfSZVcDstK1C2Lyy7FvDzdVJAcy9mlZa7p0XhMVlogG+A42mu4IcKHFcmVn+av33tuP1tGvenOhqN9Dy7L9g0Hkk6Zraa2kYCHhUCftqD3M2r0iTk3zA== X-Forefront-PRVS: 02475B2A01 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB305; 23:zqj4mJ1rxPnLPpm3ubNKRB2IXi/XEO0fn0zzmuwRIR?= =?us-ascii?Q?fpxdN12YdaV56Cw6bAyc2GtdRX9QE+50KPPbIB4bII2dxeYpA4QGbbV0ZiIA?= =?us-ascii?Q?Zy7RIdkHE9D15UqXlBlwGX3SpHdNF5aPJJroGCCfz/U9HYTnfFDD92oZuOmm?= =?us-ascii?Q?aTGUrIFXylOGBFiPe/2o8C52VZmhxMONLDUq80U409zSI7XPfy9doaZhBKKe?= =?us-ascii?Q?Mh8GEFXF1JTlSjx1YRHrZIbkzO29mXMIyk89hrwJ9FCpI9ZNvHy0ucvvKS0a?= =?us-ascii?Q?+hUg8CpI4MK0yoJjLJKm+q5bAe+lbpEdZHKah/p8QL0QMyMTHrcDhgV/xoMk?= =?us-ascii?Q?5n4CATjsmZGWjQ5QO80yGrUAeKra3oSZ/wb+aLDALYpMtIx9TnvZ9MgWVMWQ?= =?us-ascii?Q?IRxx+xrJyx6jSu3adST1Vi4/wqTXWn8kp4yajL9gZSihiA8dpVjtnPAoDMe2?= =?us-ascii?Q?EctFTguuEWNvViffyedn/UZlyB8GZrvZPw30v392dKtcAMSdrqg/Phz5QFyg?= =?us-ascii?Q?PELehNSnJR4Y5ax+oHaOdw+2n8xSm9ewpkDvp0hRLr+EdZtZ4v2Vhu5cF5Ms?= =?us-ascii?Q?Y3zn2Ok2sNCi26HxCovbISAmgeQgo6mU9ROIOOsHeET+UUp/KO+SMYmDLdIM?= =?us-ascii?Q?Ii6kCNuzAmTgUlYU7MogKM7sVeGkJpgdcCQkp1voFZ10EmweaBUr56gBxvOs?= =?us-ascii?Q?dU4whDDmLSFu35RbNLyEICpBjOOFP+w83ez17PWg2E/Wl6RMHLIbCkJZ9dhD?= =?us-ascii?Q?rLhSniegM5c0RRvO2Wribe0RQ9k5qV1BAQtDZ2rehHEcufAdVX1v4p1HW4FD?= =?us-ascii?Q?QiQp/dEvyhlGK8IBx4Ompg5Gr6AEvJWVqcxmnWpJjuq+Eojp5D8dCN17NaBY?= =?us-ascii?Q?M6DSZBmMHpWPPRIL8K1GjLC4to4cUkFjmC6h6Cd5RVHTHZJAEl/yEcEupRgO?= =?us-ascii?Q?JRYBbutJSgaLYUrLnH+QMSMdmDxSKmjOseLxXZ5333NGYD+37OimRWDmppF+?= =?us-ascii?Q?lzLt6A7jimtwd3osc+3efpLl/JzLQMFbKGuwTSimn5INqsxpsx0+wSU/HK3u?= =?us-ascii?Q?HEfjED7kMq7B78Ul+wlPIhXWcfNIQ3C1xJu3IHRp5lk3qUX2Kp9CyblliX1s?= =?us-ascii?Q?UiABczfrk=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB305; 6:I6NDCvmUWPiS8p3Q2m1NrKpP3vVFhFwIc+8ru0dIWcoWUbpTdjQ7jOkZ7S0lE6xmGtfaDhktHhshyH+NRPqtYs3Oh51WqBwt9O6gPbcZtE0ZYCnLHmNDHJ4fBqE2db3nN1DFeWYAarsJVZ94hljUQAZeueYa82yMZpRw0hQiDXIyFBtdz0d7Ok38leET+hlJvpMlCnJzXBK8aPuzhgOHkv6xO7odnmAAjCwfBLKyQb7kFBzQVmM9jf8YmBhO9fHGxEf+7DjDZbr7SFKHih3m8IQEswgHLf+yRTwrnuq50lkm9M24I5VCpuFNBC5sGUyCBExxU1NtIniz4+spjXlevmMQ61cKDLMxnU3o7w1UCC9wGQ6isxcjNXhMk2ClVgcf7vraCtGYbmxCUMl0w5hdFbYwyKvH2didCfq/32Myj7U=; 5:d4SSegi4oDfhenToOhwgsivHBN5VVaLXyaRcX0pYfJM8Npjto0OIaIE56fK2ke5NF1BmWCizxNYD7BuDRuPEWJ326lArWdHWj3iRXx4vZT/XgCwW1LM30Fs/Hi66cjT9FNLy3tmpunwJXALGwkxk3Q==; 24:7JDWuktDwSd3SLwICeJIjgVGFzUHFcUvvXhxRm1DCtD36OR/Ms6o+CGwcVDuDkade8zsG/YOzcX8pPYD744mlwd6V00+/pq+uK+8kB6cXAI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB305; 7:tL/Rw+XD2XQ2LDIZLV6LAHctCWNCi/x3NO5GalsJRZaG5g/KCXsSggClYLz0+4RLtVuEN33eC49rs/ouVJ/Y25IAWSDaC90q8Csp+tVAol6F2SnG0zUUDjMMdrIqk0RlJ/sJst4q6DWae5BkvHJIShExZMgYYEZB/tmf0hzsyhVA1sRZN4QSs6tIYQ1lt7KtrDs1YOY/2RZvCs5hwqW+9gqd+dNV9a5gowJG2wBm6Vrzif4MPmL5lwQUUThdL2q06G+StuGrlOpNc/HTlxiQiN0rNpUpTfU5BgbG297U4z2S/yr75GdmCwvsXFZe7U9+PRHyi6xDPIu7VGfjRQ8arw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Mar 2017 13:56:21.6725 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB305 Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:56:29 -0000 Robert Wilton writes: >> But I don't think it can be done in an errata. >Does this just leave the behaviour as undefined then? I.e. it is up to >the implementation to decide whether they error the augmentation. Which is an unacceptable outcome. Errata are an acceptable means of addressing this. We are not fixing a protocol design error, but repairing a missing scenario. A savvy implementer of the specification can often, but not always, figure out what was intended by the RFC as published, but technical errors should be announced somehow. In this case, the spec says nothing about an odd but interesting scenario. I don't think this requires a new version of the protocol, just a clarification. Thanks, Phil From nobody Wed Mar 15 08:15:25 2017 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 90D3313165D for ; Wed, 15 Mar 2017 08:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 mk9xIRVHGIN4 for ; Wed, 15 Mar 2017 08:15:23 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208CB131658 for ; Wed, 15 Mar 2017 08:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2834; q=dns/txt; s=iport; t=1489590923; x=1490800523; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bwL81GKRhg4pNlfHP6g0tXurqQdm2bKF1qqZgFNtCw0=; b=Md4E3ikjFLTMzL94ClHj2EifNvwqpk1YmcVJenENTaVdhrIZ6nopvzxh rlfLDy2HJLwyRL0ceiMDRib0hEWyZEVFuxF9yLUU6CltY6Io1RDVqP4/A HY5FNJEw5gaV6dJYqFF0Z0LUsnhiW8kkZ30lNdsVilfcAqK8opRw3/q1I Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQCkWclY/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHjWaRVpU8gg4fC4UuSgKCaz8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQECAQEBODQJAgULAgEIFQIfECcLHQgCBAENBQiJcAgOsDKKXwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhk6Eb4I9gXoBAU2FMwWcQwGGdYMoiBSRLpNGAR84gQR?= =?us-ascii?q?YFUGFDYFKdQGHA4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,169,1486425600"; d="scan'208";a="397722433" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2017 15:15:22 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v2FFFLtb012933 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Mar 2017 15:15:22 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Mar 2017 11:15:21 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Wed, 15 Mar 2017 11:15:21 -0400 From: "Eric Voit (evoit)" To: Ladislav Lhotka , Juergen Schoenwaelder , Alexander Clemm , "Andy Bierman (andy@yumaworks.com)" CC: "netmod@ietf.org" Thread-Topic: [netmod] notifications2, new draft (was RE: notifications...and yang-next) Thread-Index: AQHSnZ72yRcsVY8lF0CHuvxM3/BvfQ== Date: Wed, 15 Mar 2017 15:15:21 +0000 Message-ID: <5899d3c50174435cb9631d4193967246@XCH-RTP-013.cisco.com> References: <83212dff34af49c59e917bfffe8c0604@XCH-RTP-013.cisco.com> In-Reply-To: <83212dff34af49c59e917bfffe8c0604@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] notifications2, new draft (was RE: notifications...and yang-next) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 15:15:24 -0000 Hi Lada, Juergen, Alex, Andy, In January your comments on "notifications" helped frame the context of dra= ft-voit-netmod-yang-notifications2. See thread https://www.ietf.org/mail-archive/web/netmod/current/msg17434.ht= ml The is an open question between WG chairs on whether this question is more = appropriate for NETMOD or NETCONF. I am ok if it lands in either, but I w= as wondering if you have opinions on its placement (or where it might be di= scussed in Chicago) as you commented previously. Eric > From: Eric Voit, February 24, 2017 12:23 PM >=20 > Alex, Tim, Andy, & I have posted at new draft at: > https://tools.ietf.org/html/draft-voit-netmod-yang-notifications2-00 >=20 > Explored here are notification capabilities beyond RFC-7950 section 7.16: >=20 > * what are the set of transport agnostic header objects which might be us= eful > within a YANG notification >=20 > * how might a set of YANG notifications be bundled for bulk transport. >=20 > * how do you query the originator of a notification to troubleshoot eleme= nts of > this process. >=20 > Any feedback would be appreciated. >=20 > Thanks, > Eric >=20 > > From: netmod, January 25, 2017 8:53 PM > > Subject: Re: [netmod] notifications...and yang-next > > > > > > The NETCONF and NETMOD chairs are actively discussing how we might > > move content around between drafts maintained by the two groups. > > Resolving this notification statement issue is part of that. Here are > > some of my thoughts about this: > > > > 1) I think that YANG is primarily used to define the notification's > > data tree, the payload, which may be wrapped by a protocol-specific > > envelop that includes, for instance, a timestamp. This being the > > case, I'm hoping that there isn't much to do here. > > > > 2) Yes, RFC 7950 references RFC 5277, but note that it does so only in > > a section called "NETCONF XML Encoding Rules". It is my hope that we > > will move all such sections out in the next revision RFC 7950 (see > > https://github.com/netmod-wg/yang-next/issues/11) > > > > 3) Above and beyond the notification statement issue, Lada also notes > > that RFC > > 7950 Section 3 references RFC 6241 for some terms. I believe that, in > > order to remove these normative references to 6241, these terms should > > be moved to the revised-datastore draft (see > > https://github.com/netmod-wg/yang- > > next/issues/12). > > > > Thoughts? > > > > > > Kent // mostly as a contributor > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 15 09:45:30 2017 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 11F6B1316AA; Wed, 15 Mar 2017 09:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 4Ff-2LPeW9ZY; Wed, 15 Mar 2017 09:45:27 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF52F1316A1; Wed, 15 Mar 2017 09:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9517; q=dns/txt; s=iport; t=1489596327; x=1490805927; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to; bh=Uf3scEEE8n+0kHZGZZZw4Kem5e9QgN1sKejj8jlmn9I=; b=NZk7KZ1xCMom37NW+D16EdgnzK/VZTAjKkIy0axm8tmbm2u5Hbw2zDFC mLr7LkAQBgNeq/BCMQUmeBni6GfldaNCUwwNhihaRbzYq0b27p+nP/auA XzUF60HoIFM5uz9s2cb42TmmnLiPalWwLngb79IAq7AWIB4feeCJQeZrc 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAQAqb8lY/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhDIqYI1tc5BjkA+DHoIPgg4qhXgCgy4YAQIBAQEBAQEBayiFFgEEAXk?= =?us-ascii?q?FCwtGVxMIAQGJdAgOsHArijQBAQEBAQEEAQEBAQEBAQEBH4ZOggWCaoo5BZxDh?= =?us-ascii?q?naLRYF7VIgDI4YwiziIDw8QOIEEIxYIFxVBhlg/NQEBiTABAQE?= X-IronPort-AV: E=Sophos;i="5.36,169,1486425600"; d="scan'208,217";a="650450186" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2017 16:45:24 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2FGjNvY007517; Wed, 15 Mar 2017 16:45:23 GMT To: netmod@ietf.org References: <20170313212537.GB53972@elstar.local> From: Benoit Claise Cc: "sec-ads@ietf.org" Message-ID: <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> Date: Wed, 15 Mar 2017 17:45:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170313212537.GB53972@elstar.local> Content-Type: multipart/alternative; boundary="------------897996A7A7C648C0E15B99A6" Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:45:29 -0000 This is a multi-part message in MIME format. --------------897996A7A7C648C0E15B99A6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear all, [copying the security ADs to make sure the new security section is fine] Let's separate the two issues 1. the multiple URLs in draft-ietf-netmod-rfc6087bis-12.txt Basically, I agree with Jürgen I see section 4.7: This section MUST be patterned after the latest approved template (available athttp://trac.tools.ietf.org/area/ops/trac/wiki/ yang-security-guidelines ).Section 7.1 contains the security considerations template dated 2013-05-08. Authors MUST check the WEB page at the URL listed above in case there is a more recent version available. Then, I see section 7: The following section contains the security considerations template dated 2010-06-16. Not sure why it contains this cut/paste? It should just say: the latest version is at this URL. Then, I see in the same section: This section MUST be patterned after the latest approved template (available at http://www.ops.ietf.org/netconf/yang-security-considerations.txt This page is not found. This should be corrected in rfc6087bis. 2. the new security guidelines must include RESTCONF. At this point, this is a blocking factor for the publication of YANG module. As an example, draft-ietf-lmap-yang-11 , A YANG Data Model for LMAP Measurement Agents, on the telechat tomorrow. As mentioned the most up to date version is https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines Here is the proposal, discussed on the YANG doctors list: OLD The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content. NEW The YANG module defined in this memo is designed to be accessed via the NETCONF [RFC6241] or RESTCONF [RFC8040] protocol. The lowest NETCONF layer is the secure transport layer, and mandatory-to-implement is Secure Shell (SSH) [RFC6242], while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement secure transport is Transport Layer Security (TLS) [RFC5246]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. Any objections? Have covered all that we need for the new RESTCONF protocol? Regards, Benoit > Hi, > > this came up during IESG processing of a YANG module - is there a new > security guideline boilerplate text covering RESTCONF? This was > briefly discussed on the yang-doctors but somehow the discussion > stopped because RESTCONF was not published yet at that time. I think > this affects draft-ietf-netmod-rfc6087bis-12.txt. > > draft-ietf-netmod-rfc6087bis-12.txt has several pointers to read > online documents - why do we need several points? I think some are > also not working. Ideally, there should be a single stable URL. > > /js > --------------897996A7A7C648C0E15B99A6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear all,

[copying the security ADs to make sure the new security section is fine]
Let's separate the two issues

1. the multiple URLs in draft-ietf-netmod-rfc6087bis-12.txt
Basically, I agree with Jürgen
I see section 4.7:
   This section MUST be patterned after the latest approved template
   (available at http://trac.tools.ietf.org/area/ops/trac/wiki/
   yang-security-guidelines).  Section 7.1 contains the security
   considerations template dated 2013-05-08.  Authors MUST check the WEB
   page at the URL listed above in case there is a more recent version
   available.
Then, I see section 7: 
  The following section contains the security considerations template
   dated 2010-06-16.
Not sure why it contains this cut/paste? It should just say: the latest version is at this URL.
Then, I see in the same section:
This section MUST be patterned after the latest approved
   template (available at

    http://www.ops.ietf.org/netconf/yang-security-considerations.txt
This page is not found.
This should be corrected in rfc6087bis.


2. the new security guidelines must include RESTCONF.
At this point, this is a blocking factor for the publication of YANG module. As an example,
draft-ietf-lmap-yang-11, A YANG Data Model for LMAP Measurement Agents, on the telechat tomorrow.
As mentioned the most up to date version is https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

Here is the proposal, discussed on the YANG doctors list:

        OLD

The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content.

NEW

The YANG module defined in this memo is designed to be accessed via the NETCONF [RFC6241] or RESTCONF [RFC8040] protocol. The lowest NETCONF layer is the secure transport layer, and mandatory-to-implement is Secure Shell (SSH) [RFC6242], while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement secure transport is Transport Layer Security (TLS) [RFC5246]. 
The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content.
Any objections?
Have covered all that we need for the new RESTCONF protocol?

Regards, Benoit


Hi,

this came up during IESG processing of a YANG module - is there a new
security guideline boilerplate text covering RESTCONF? This was
briefly discussed on the yang-doctors but somehow the discussion
stopped because RESTCONF was not published yet at that time. I think
this affects draft-ietf-netmod-rfc6087bis-12.txt.

draft-ietf-netmod-rfc6087bis-12.txt has several pointers to read
online documents - why do we need several points? I think some are
also not working. Ideally, there should be a single stable URL.

/js

--------------897996A7A7C648C0E15B99A6-- From nobody Wed Mar 15 09:59:24 2017 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 B922D131722 for ; Wed, 15 Mar 2017 09:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 hMOGxTUzRZzD for ; Wed, 15 Mar 2017 09:59:15 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FBBF131720 for ; Wed, 15 Mar 2017 09:59:15 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id u132so15775176wmg.0 for ; Wed, 15 Mar 2017 09:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZEnXzGXleWWnp+34hBBrlonbcadTTLRmnmRTC1e5rH0=; b=UYn0x+LJxpLVkAdfWMQppJ0MB9UhwEX2GgQXZ0jWg/83PoghmxeRmcb/BxRHBGDdPt 6B66EUEZ4tzhq7TvzqLBzGQUkIWaOjRP+dW57f7gmM2RUEFR1wTkjeqiBQPfR7VxXyjQ wqDjY7uc46FkS1gEwl903wqSnatDct0FkKPp2NUsY5+mz4nYfF+fF090Z2VQMN8hHDZR QrSc5QgCBEN65WnonFEBbEWKD/0m8+y0wL24P3W/XT+p6WjIs4owW1WcZCg1o5dcOy+g 6rM73qC6+wxAqVOE3tsv9CR9rdlNwCoLPFN2+EUU3j2RTvJzZJwjzskx0PLUrd73fd29 Tu/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZEnXzGXleWWnp+34hBBrlonbcadTTLRmnmRTC1e5rH0=; b=PyyniWEhlJspQOKgZKINl1DSYFyAwr0SYAH4kJlJXrf2mgM0YVoZhzNJ2QGMMReCbz MfFql6GQ3eHbxEaQ0N9NIQdFEJ8HJK4VNR7UCFBr7gWSRQI5ZBrCUcccubFuekpQ1Q8R yT/hhOUrgHVVNBrZChYdZTT59FjEUYKtBRrZ2sX5CGKbHGfQ1d5XNDEqTo2wkCIgbvPI lS7mj1kTaKOWn4G1KJRSUqZDpv5Mz0++v75vYM8j4wIjaLsy7dFFvwEj31KJaQdfQ2RH yOHCDXbU1D/McCj/GD8bQcuWg2cenxb6XA/kgTABSlkBUdRF07rSyMCRIdUtsHv6aSfz tHMg== X-Gm-Message-State: AFeK/H0mbAU+scEzh/RPt2DESM9fqbLIJnf4/3EKl5xT8GgW9BWo4dGG0JgdTaKNWMc1ylsQwFcgK3J4oxJ4VA== X-Received: by 10.28.136.204 with SMTP id k195mr2942097wmd.99.1489597153804; Wed, 15 Mar 2017 09:59:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.166.37 with HTTP; Wed, 15 Mar 2017 09:59:13 -0700 (PDT) In-Reply-To: <201703151351.v2FDpU3s081481@idle.juniper.net> References: <201703151351.v2FDpU3s081481@idle.juniper.net> From: Andy Bierman Date: Wed, 15 Mar 2017 09:59:13 -0700 Message-ID: To: Phil Shafer Cc: Robert Wilton , joey.boyd@adtran.com, "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a114431d4360e66054ac7ddef Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:59:23 -0000 --001a114431d4360e66054ac7ddef Content-Type: text/plain; charset=UTF-8 Hi, This thread is not surprising because the YANG conformance model is not that well defined. As long as the protocols that access hierarchical YANG data require the parent to be implemented in order to access the child, it really doesn't matter how you want to spin the augment conformance. In YANG terms "implement the module" means "implement all base module constructs". The server can claim conformance to the module and also choose not to implement any of the YANG features. Anything with an if-feature is optional-to-implement. I don't see how the text you are debating changes that. Andy On Wed, Mar 15, 2017 at 6:51 AM, Phil Shafer wrote: > Robert Wilton writes: > >> But I don't think it can be done in an errata. > >Does this just leave the behaviour as undefined then? I.e. it is up to > >the implementation to decide whether they error the augmentation. > > Which is an unacceptable outcome. Errata are an acceptable > means of addressing this. We are not fixing a protocol design > error, but repairing a missing scenario. > > A savvy implementer of the specification can often, but not always, > figure out what was intended by the RFC as published, but technical > errors should be announced somehow. > > In this case, the spec says nothing about an odd but interesting > scenario. I don't think this requires a new version of the protocol, > just a clarification. > > Thanks, > Phil > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114431d4360e66054ac7ddef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This thread is not surprising becau= se the YANG conformance model is not that well defined.

As long as the protocols that access hierarchical YANG data require t= he parent
to be implemented in order to access the child, it real= ly doesn't matter how you
want to spin the augment conformanc= e.=C2=A0

In YANG terms "implement the module&= quot; means "implement all base module constructs".
The= server can claim conformance to the module and also choose not to implemen= t
any of the YANG features. Anything with an if-feature is option= al-to-implement.
I don't see how the text you are debating ch= anges that.


Andy


On Wed, M= ar 15, 2017 at 6:51 AM, Phil Shafer <phil@juniper.net> wrote:=
Robert Wilton writes:
>> But I don't think it can be done in an errata.
>Does this just leave the behaviour as undefined then? I.e. it is up to<= br> >the implementation to decide whether they error the augmentation.

Which is an unacceptable outcome.=C2=A0 Errata are an acceptable
means of addressing this.=C2=A0 We are not fixing a protocol design
error, but repairing a missing scenario.

=C2=A0 =C2=A0A savvy implementer of the specification can often, but not al= ways,
=C2=A0 =C2=A0figure out what was intended by the RFC as published, but tech= nical
=C2=A0 =C2=A0errors should be announced somehow.

In this case, the spec says nothing about an odd but interesting
scenario.=C2=A0 I don't think this requires a new version of the protoc= ol,
just a clarification.

Thanks,
=C2=A0Phil

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

--001a114431d4360e66054ac7ddef-- From nobody Wed Mar 15 10:09:12 2017 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 7948F13171D; Wed, 15 Mar 2017 10:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 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_LOW=-0.7, 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=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 dXK7GK1hBpfG; Wed, 15 Mar 2017 10:09:09 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7E113171A; Wed, 15 Mar 2017 10:09:08 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id t189so28321087wmt.1; Wed, 15 Mar 2017 10:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=TpLKFJU9A6x2UQ8ek9jfERXE3IMC7/C6GbUTXF/VoaQ=; b=O3EatxK2hSXnXqWxbNTpNFQp9/pDIuCXiUeDw63k4kKjSML1RGeoX2TBM19gRztn/L uHJjMrb6+Pse6YCJ2FndlLSYKnpCASoC2Wh2u+qHHL3ZNeTQz7sy900Ms0X+/1dvG1kg B/f6Rf5LLrKSx/IF4dAvYoOaoXFnRF8JnLbvbaM0B2nyc/kDq5+lC7UH6Y09yBUSC/d4 9RW3kGLbXX2PFtE8Mn1Q5LiCYHbfw1DUmoLyfuD+UQvN+ChJcOe7wxdbd12z2fPZlyGk NbvYjbJ72GRyyljwY8IskfELasMVb2gqME2C8xAUZutCNZ2hVwhV6zJMQI0fcbw1l3ao RyJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=TpLKFJU9A6x2UQ8ek9jfERXE3IMC7/C6GbUTXF/VoaQ=; b=kXoQwxUqfvHwH/bX0+r1Olax/96I3Iy2Wq9x8EKS0pPksRIHSo11MqTpUnmzfjaH1f M6Ew5fOTnjbII8ntf/IPT6X03iTYwspNqVQyfJCiLHbou65nV/HOZpRdj1OfyIQAfzcz VtPzHKpQ1HZCkBiPOQ+ID0c0pWL7AfDIC9qeiKqxhCt5gZ0uKac3NGY6TXlxUTsP73WR 9p5Ta0Wws6RhRVo6900VczOAwA0X3ZCVEs/dad9PsPnL2b4VqrmCZR5Zj9jfwoiZj9yf rUJNX1xsn/wBRxoG2NKJbnNanfKQfKJNUsHklKTbUhfmj9MmJl13n1xkCEj24pxjrR41 fw8g== X-Gm-Message-State: AFeK/H0tc+cCxm4ZHED9JedaONOSpN3XzUTOOHTN5NsiRMdUJ0dmhQodSoAg2bCAXFDgow== X-Received: by 10.28.208.72 with SMTP id h69mr21187478wmg.100.1489597746943; Wed, 15 Mar 2017 10:09:06 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p5DCC645C.dip0.t-ipconnect.de. [93.204.100.92]) by smtp.gmail.com with ESMTPSA id g45sm3073949wrd.11.2017.03.15.10.09.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 10:09:06 -0700 (PDT) From: "Mehmet Ersue" To: "'Benoit Claise'" , Cc: References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> In-Reply-To: <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> Date: Wed, 15 Mar 2017 18:09:07 +0100 Message-ID: <03cc01d29dae$db5aff90$9210feb0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03CD_01D29DB7.3D235F30" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGJMIRwVHbcr6YpIqDDgDof1YDe8gGzbvedohtgQGA= Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0201.58C97531.023D,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 17:09:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03CD_01D29DB7.3D235F30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looks good to me.=20 However, I think we should change: s/and mandatory-to-implement is Secure Shell/ and the mandatory-to-implement secure transport is Secure Shell/ =20 Mehmet =20 From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Wednesday, March 15, 2017 5:45 PM To: netmod@ietf.org Cc: sec-ads@ietf.org Subject: Re: [netmod] security considerations boilerplate updates to = cover RESTCONF =20 Dear all, [copying the security ADs to make sure the new security section is fine] = Let's separate the two issues 1. the multiple URLs in draft-ietf-netmod-rfc6087bis-12.txt Basically, I agree with J=FCrgen I see section 4.7: This section MUST be patterned after the latest approved template (available at http://trac.tools.ietf.org/area/ops/trac/wiki/ = yang-security-guidelines = ). Section 7.1 = contains the security considerations template dated 2013-05-08. Authors MUST check the WEB page at the URL listed above in case there is a more recent version available. Then, I see section 7:=20 The following section contains the security considerations template dated 2010-06-16. Not sure why it contains this cut/paste? It should just say: the latest version is at this URL. Then, I see in the same section: This section MUST be patterned after the latest approved template (available at =20 http://www.ops.ietf.org/netconf/yang-security-considerations.txt This page is not found. This should be corrected in rfc6087bis. 2. the new security guidelines must include RESTCONF. At this point, this is a blocking factor for the publication of YANG = module. As an example,=20 draft-ietf-lmap-yang-11 , A YANG Data = Model for LMAP Measurement Agents, on the telechat tomorrow. As mentioned the most up to date version is https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines Here is the proposal, discussed on the YANG doctors list: =20 OLD The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure = transport layer, and the mandatory-to-implement secure transport is Secure Shell = (SSH) [RFC6242]. The NETCONF access control model [RFC6536] provides the means = to restrict access for particular NETCONF users to a pre-configured subset = of all available NETCONF protocol operations and content. NEW =20 The YANG module defined in this memo is designed to be accessed via the NETCONF [RFC6241] or RESTCONF [RFC8040] protocol. The lowest NETCONF = layer is the secure transport layer, and mandatory-to-implement is Secure = Shell (SSH) [RFC6242], while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement secure transport is Transport Layer Security = (TLS) [RFC5246].=20 The NETCONF access control model [RFC6536] provides the means to = restrict access for particular NETCONF or RESTCONF users to a pre-configured = subset of all available NETCONF or RESTCONF protocol operations and content. Any objections? Have covered all that we need for the new RESTCONF protocol? Regards, Benoit =20 Hi, =20 this came up during IESG processing of a YANG module - is there a new security guideline boilerplate text covering RESTCONF? This was briefly discussed on the yang-doctors but somehow the discussion stopped because RESTCONF was not published yet at that time. I think this affects draft-ietf-netmod-rfc6087bis-12.txt. =20 draft-ietf-netmod-rfc6087bis-12.txt has several pointers to read online documents - why do we need several points? I think some are also not working. Ideally, there should be a single stable URL. =20 /js =20 =20 ------=_NextPart_000_03CD_01D29DB7.3D235F30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Looks good to me.

However, I think we should change:

s/and mandatory-to-implement is Secure Shell/

and the mandatory-to-implement secure transport is Secure = Shell/

 

Mehmet

 

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Benoit = Claise
Sent: Wednesday, March 15, 2017 5:45 PM
To: = netmod@ietf.org
Cc: sec-ads@ietf.org
Subject: Re: = [netmod] security considerations boilerplate updates to cover = RESTCONF

 

Dear = all,

[copying the security ADs to make sure the new security = section is fine]
Let's separate the two issues

1. the = multiple URLs in draft-ietf-netmod-rfc6087bis-12.txt
Basically, I = agree with J=FCrgen
I see section 4.7:

=A0=A0 This section =
MUST be patterned after the latest approved =
template
=A0=A0 (available at http://trac.tools.ietf.org/area/ops/trac/wiki/
=A0=A0 yang-security-guidelines).=A0 Section 7.1 contains the =
security
=A0=A0 considerations template dated =
2013-05-08.=A0 Authors MUST check the WEB
=A0=A0 =
page at the URL listed above in case there is a more recent =
version
=A0=A0 =
available.

Then, I see = section 7: 

=A0=A0The following =
section contains the security considerations =
template
=A0=A0 dated =
2010-06-16.

Not sure = why it contains this cut/paste? It should just say: the latest version = is at this URL.
Then, I see in the same = section:

This section MUST be =
patterned after the latest approved
=A0=A0 template =
(available at
 
=A0=A0=A0 =
http://www.ops.ietf.org/netconf/yang-security-considerations.txt

This page is not = found.
This should be corrected in rfc6087bis.


2. the new = security guidelines must include RESTCONF.
At this point, this is a = blocking factor for the publication of YANG module. As an example, =

draft-iet= f-lmap-yang-11, A YANG Data Model for LMAP Measurement Agents, on = the telechat tomorrow.

As = mentioned the most up to date version is htt= ps://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

Here= is the proposal, discussed on the YANG doctors = list:

 

        = OLD

The YANG module defined in this memo is designed to be accessed via = the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure = transport layer, and the mandatory-to-implement secure transport is = Secure Shell (SSH) [RFC6242]. The NETCONF access control model [RFC6536] = provides the means to restrict access for particular NETCONF users to a = pre-configured subset of all available NETCONF protocol operations and = content.

NEW

 

The YANG module defined in = this memo is designed to be accessed via the NETCONF [RFC6241] or = RESTCONF [RFC8040] protocol. The lowest NETCONF layer is the secure = transport layer, and mandatory-to-implement is Secure Shell (SSH) = [RFC6242], while the lowest RESTCONF layer is HTTP, and the = mandatory-to-implement secure transport is Transport Layer Security = (TLS) [RFC5246]. 

The NETCONF access control model [RFC6536] = provides the means to restrict access for particular NETCONF or RESTCONF = users to a pre-configured subset of all available NETCONF or RESTCONF = protocol operations and = content.

Any objections?
Have covered all that = we need for the new RESTCONF protocol?

Regards, Benoit

 

Hi,
<= pre> 
this came up during IESG processing of a =
YANG module - is there a new
security guideline =
boilerplate text covering RESTCONF? This =
was
briefly discussed on the yang-doctors but =
somehow the discussion
stopped because RESTCONF was =
not published yet at that time. I think
this =
affects =
draft-ietf-netmod-rfc6087bis-12.txt.
 
draft-ietf-netmod-rfc6087bis-12.txt has several pointers to =
read
online documents - why do we need several =
points? I think some are
also not working. Ideally, =
there should be a single stable =
URL.
 
/js
 

 

------=_NextPart_000_03CD_01D29DB7.3D235F30-- From nobody Wed Mar 15 10:19:33 2017 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 E19FD131728 for ; Wed, 15 Mar 2017 10:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9209xKySFR31 for ; Wed, 15 Mar 2017 10:19:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D7913172A for ; Wed, 15 Mar 2017 10:19:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCV94525; Wed, 15 Mar 2017 17:19:23 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Mar 2017 17:18:31 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Wed, 15 Mar 2017 10:18:17 -0700 From: Alexander Clemm To: "Eric Voit (evoit)" , Ladislav Lhotka , Juergen Schoenwaelder , "Andy Bierman (andy@yumaworks.com)" CC: "netmod@ietf.org" Thread-Topic: [netmod] notifications2, new draft (was RE: notifications...and yang-next) Thread-Index: AQHSnZ8JbTYyKKpFn0asnBZEMJy02aGWJHgg Date: Wed, 15 Mar 2017 17:18:15 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF87126@SJCEML703-CHM.china.huawei.com> References: <83212dff34af49c59e917bfffe8c0604@XCH-RTP-013.cisco.com> <5899d3c50174435cb9631d4193967246@XCH-RTP-013.cisco.com> In-Reply-To: <5899d3c50174435cb9631d4193967246@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.58C9779C.00BC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 04006203165a8511f8f4e0715b8fa9b8 Archived-At: Subject: Re: [netmod] notifications2, new draft (was RE: notifications...and yang-next) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 17:19:32 -0000 Hi Eric, I think it might fit better into NETCONF, actually. But as you point out, = it could land in either and whichever way the chairs decide is fine with me= . =20 --- Alex -----Original Message----- From: Eric Voit (evoit) [mailto:evoit@cisco.com]=20 Sent: Wednesday, March 15, 2017 8:15 AM To: Ladislav Lhotka ; Juergen Schoenwaelder ; Alexander Clemm ; Andy = Bierman (andy@yumaworks.com) Cc: netmod@ietf.org Subject: RE: [netmod] notifications2, new draft (was RE: notifications...an= d yang-next) Hi Lada, Juergen, Alex, Andy, In January your comments on "notifications" helped frame the context of dra= ft-voit-netmod-yang-notifications2. See thread https://www.ietf.org/mail-archive/web/netmod/current/msg17434.ht= ml The is an open question between WG chairs on whether this question is more = appropriate for NETMOD or NETCONF. I am ok if it lands in either, but I w= as wondering if you have opinions on its placement (or where it might be di= scussed in Chicago) as you commented previously. Eric > From: Eric Voit, February 24, 2017 12:23 PM >=20 > Alex, Tim, Andy, & I have posted at new draft at: > https://tools.ietf.org/html/draft-voit-netmod-yang-notifications2-00 >=20 > Explored here are notification capabilities beyond RFC-7950 section 7.16: >=20 > * what are the set of transport agnostic header objects which might be=20 > useful within a YANG notification >=20 > * how might a set of YANG notifications be bundled for bulk transport. >=20 > * how do you query the originator of a notification to troubleshoot=20 > elements of this process. >=20 > Any feedback would be appreciated. >=20 > Thanks, > Eric >=20 > > From: netmod, January 25, 2017 8:53 PM > > Subject: Re: [netmod] notifications...and yang-next > > > > > > The NETCONF and NETMOD chairs are actively discussing how we might=20 > > move content around between drafts maintained by the two groups. > > Resolving this notification statement issue is part of that. Here=20 > > are some of my thoughts about this: > > > > 1) I think that YANG is primarily used to define the notification's=20 > > data tree, the payload, which may be wrapped by a protocol-specific=20 > > envelop that includes, for instance, a timestamp. This being the=20 > > case, I'm hoping that there isn't much to do here. > > > > 2) Yes, RFC 7950 references RFC 5277, but note that it does so only=20 > > in a section called "NETCONF XML Encoding Rules". It is my hope=20 > > that we will move all such sections out in the next revision RFC=20 > > 7950 (see > > https://github.com/netmod-wg/yang-next/issues/11) > > > > 3) Above and beyond the notification statement issue, Lada also=20 > > notes that RFC > > 7950 Section 3 references RFC 6241 for some terms. I believe that,=20 > > in order to remove these normative references to 6241, these terms=20 > > should be moved to the revised-datastore draft (see > > https://github.com/netmod-wg/yang- > > next/issues/12). > > > > Thoughts? > > > > > > Kent // mostly as a contributor > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 15 10:32:40 2017 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 2239513174B; Wed, 15 Mar 2017 10:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 fU4wjdM7OPFB; Wed, 15 Mar 2017 10:32:35 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0097.outbound.protection.outlook.com [104.47.37.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD53413172F; Wed, 15 Mar 2017 10:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=G4snYr0vtgoblw1z/l/nRponu75/GAjn6ML5IbGOslE=; b=e3kdv62AigiNaRWc0hYk7XqX+LkGhusa5cZEVHvFR34O5ldXz+hOjBLVnyu/ZXjTzTJU517urzj3ZsISQDBp/nhTbKLhmctna+iMcACQRTAXVWYG/x9/Pj9PXfUUNNGSyMomX/seR0Fvugy3iA3jN20/DStDtqwbRFWPqA1qY1A= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 17:32:32 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0977.010; Wed, 15 Mar 2017 17:32:32 +0000 From: Kent Watsen To: Benoit Claise , "netmod@ietf.org" CC: "sec-ads@ietf.org" Thread-Topic: [netmod] security considerations boilerplate updates to cover RESTCONF Thread-Index: AQHSnauR8sIuzui9AkeB/6DkSo5/yqGV5dqA Date: Wed, 15 Mar 2017 17:32:32 +0000 Message-ID: <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> In-Reply-To: <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:yXGsQPk1fB9qgseLQS1X8OXL15PlBtck84wbBWzY3pSXCviN9mvmRhC9ecyjTEMq9XQ+YV9HCXoSeO2nFFtARgArTQbVtQe4HSBWF8EcP3zDbXvTSQJn/6z+uZ+EPVf12fNhTnqT9N7kuhvzJMyo6VbG7qywEMb5g93iYP6yPFWs/ed3M7pI03a/ahZwPRTw0aQHAFshC9uRuLl2rK0Oh6TOmwxFxjPOwqa9d5HnWPBPfg5QPKgtkbtrg9R9YnXMFNvWwtMseNJ0OzwfXbJEXpGzIJulUOYEoBNGdYlSss0MaK3SJFgzc/i9y7o4KQKU/y7bfCLyQs7Q/UA8Yjpd9g== x-ms-office365-filtering-correlation-id: 04ef71b6-ca21-4fe9-0f17-08d46bc94350 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(209352067349851)(192374486261705)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39850400002)(39860400002)(39450400003)(39840400002)(57704003)(377454003)(24454002)(3660700001)(83716003)(2950100002)(2906002)(50986999)(3280700002)(76176999)(10710500007)(54356999)(5660300001)(36756003)(82746002)(189998001)(33656002)(7110500001)(102836003)(122556002)(606005)(561944003)(38730400002)(8676002)(77096006)(25786008)(6486002)(6506006)(6436002)(2900100001)(53936002)(6116002)(6512007)(236005)(3846002)(99286003)(7906003)(6306002)(8936002)(53546007)(81166006)(86362001)(229853002)(4326008)(2501003)(966004)(4001350100001)(2420400007)(6246003)(7736002)(15650500001)(66066001)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_8E887FD198494A05A43FCF675056A7B5junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 17:32:32.5419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 17:32:38 -0000 --_000_8E887FD198494A05A43FCF675056A7B5junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpCZW5vaXQsDQoNCkkgZml4ZWQgdGhpcyB0ZXh0IGluIG15IGRyYWZ0cyBhbHJlYWR5LiAgQWN0 dWFsbHksIEkgZm91bmQgdGhlIG9sZCB0ZXh0IGRpZmZpY3VsdCB0bw0KcmVhZCwgc28gSSBmaXhl ZCBpdCBsaWtlIHRoaXM6DQoNCiAgIFRoZSBZQU5HIG1vZHVsZSBkZWZpbmVkIGluIHRoaXMgZG9j dW1lbnQgaXMgZGVzaWduZWQgdG8gYmUgYWNjZXNzZWQNCiAgIHZpYSBZQU5HIGJhc2VkIG1hbmFn ZW1lbnQgcHJvdG9jb2xzLCBzdWNoIGFzIE5FVENPTkYgW1JGQzYyNDE8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzYyNDE+XSBhbmQNCiAgIFJFU1RDT05GIFtSRkM4MDQwPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDQwPl0uICBCb3RoIG9mIHRoZXNlIHByb3RvY29scyBo YXZlIG1hbmRhdG9yeS10by0NCiAgIGltcGxlbWVudCBzZWN1cmUgdHJhbnNwb3J0IGxheWVycyAo ZS5nLiwgU1NILCBUTFMpIHdpdGggbXV0dWFsDQogICBhdXRoZW50aWNhdGlvbi4NCg0KICAgVGhl IE5FVENPTkYgYWNjZXNzIGNvbnRyb2wgbW9kZWwgKE5BQ00pIFtSRkM2NTM2PGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTM2Pl0gcHJvdmlkZXMgdGhlIG1lYW5zDQogICB0byByZXN0 cmljdCBhY2Nlc3MgZm9yIHBhcnRpY3VsYXIgdXNlcnMgdG8gYSBwcmUtY29uZmlndXJlZCBzdWJz ZXQgb2YNCiAgIGFsbCBhdmFpbGFibGUgcHJvdG9jb2wgb3BlcmF0aW9ucyBhbmQgY29udGVudC4N Cg0KICAgKGZyb206IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNv bmYta2V5c3RvcmUtMDEjc2VjdGlvbi00KS4NCg0KUmVsYXRlZCwgSSB3YXNuJ3QgZW50aXJlbHkg c3VyZSBob3cgdG8gaGFuZGxlIHRoZSBzaXR1YXRpb24gd2hlcmUgYSBkcmFmdCB1c2VzDQpncm91 cGluZ3MgZnJvbSBhbm90aGVyIGRyYWZ0LiAgRG9lcyBpdCBzaW1wbHkgcG9pbnQgdG8gdGhlIG90 aGVyIGRyYWZ0J3MgU2VjdXJpdHkNCkNvbnNpZGVyYXRpb25zLCBvciByZWNyZWF0ZSB0aGVtIGlu IGl0cyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uPyAgRm9yIG5vdywNCkkgY2hvc2Ug dGhlIGZvcm1lciwgZm9yIGluc3RhbmNlOg0KDQogICBUaGUgWUFORyBtb2R1bGUgZGVmaW5lZCBp biB0aGlzIGRvY3VtZW50IHVzZXMgZ3JvdXBpbmdzIGRlZmluZWQgaW4NCiAgIFtJLUQuaWV0Zi1u ZXRjb25mLXNzaC1jbGllbnQtc2VydmVyPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW5ldGNvbmYtbmV0Y29uZi1jbGllbnQtc2VydmVyLTAyI3JlZi1JLUQuaWV0Zi1uZXRj b25mLXNzaC1jbGllbnQtc2VydmVyPl0gYW5kIFtJLUQuaWV0Zi1uZXRjb25mLXRscy1jbGllbnQt c2VydmVyPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtbmV0 Y29uZi1jbGllbnQtc2VydmVyLTAyI3JlZi1JLUQuaWV0Zi1uZXRjb25mLXRscy1jbGllbnQtc2Vy dmVyPl0uDQogICBQbGVhc2Ugc2VlIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u IGluIHRob3NlIGRvY3VtZW50cyBmb3INCiAgIGNvbmNlcm5zIHJlbGF0ZWQgdGhvc2UgZ3JvdXBp bmdzLg0KDQogICAoZnJvbTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bmV0Y29uZi1uZXRjb25mLWNsaWVudC1zZXJ2ZXItMDIjc2VjdGlvbi01KQ0KDQoNClRoYW5rcywN CktlbnQgIC8vIGNvbnRyaWJ1dG9yDQoNCg0KLS0tLS1PUklHSU5BTCBNRVNTQUdFLS0tLS0tDQoN Ck9uIDMvMTUvMTcsIDEyOjQ1IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBCZW5vaXQgQ2xhaXNl IiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgYmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lzY28uY29t Pj4gd3JvdGU6DQoNCkRlYXIgYWxsLA0KDQpbY29weWluZyB0aGUgc2VjdXJpdHkgQURzIHRvIG1h a2Ugc3VyZSB0aGUgbmV3IHNlY3VyaXR5IHNlY3Rpb24gaXMgZmluZV0NCkxldCdzIHNlcGFyYXRl IHRoZSB0d28gaXNzdWVzDQoNCjEuIHRoZSBtdWx0aXBsZSBVUkxzIGluIGRyYWZ0LWlldGYtbmV0 bW9kLXJmYzYwODdiaXMtMTIudHh0DQpCYXNpY2FsbHksIEkgYWdyZWUgd2l0aCBKw7xyZ2VuDQpJ IHNlZSBzZWN0aW9uIDQuNzoNCg0KICAgVGhpcyBzZWN0aW9uIE1VU1QgYmUgcGF0dGVybmVkIGFm dGVyIHRoZSBsYXRlc3QgYXBwcm92ZWQgdGVtcGxhdGUNCg0KICAgKGF2YWlsYWJsZSBhdCBodHRw Oi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL29wcy90cmFjL3dpa2kvPGh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvb3BzL3RyYWMvd2lraS95YW5nLXNlY3VyaXR5LWd1aWRlbGluZXM+ DQoNCiAgIHlhbmctc2VjdXJpdHktZ3VpZGVsaW5lczxodHRwOi8vdHJhYy50b29scy5pZXRmLm9y Zy9hcmVhL29wcy90cmFjL3dpa2kveWFuZy1zZWN1cml0eS1ndWlkZWxpbmVzPikuICBTZWN0aW9u IDcuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjA4 N2Jpcy0xMiNzZWN0aW9uLTcuMT4gY29udGFpbnMgdGhlIHNlY3VyaXR5DQoNCiAgIGNvbnNpZGVy YXRpb25zIHRlbXBsYXRlIGRhdGVkIDIwMTMtMDUtMDguICBBdXRob3JzIE1VU1QgY2hlY2sgdGhl IFdFQg0KDQogICBwYWdlIGF0IHRoZSBVUkwgbGlzdGVkIGFib3ZlIGluIGNhc2UgdGhlcmUgaXMg YSBtb3JlIHJlY2VudCB2ZXJzaW9uDQoNCiAgIGF2YWlsYWJsZS4NClRoZW4sIEkgc2VlIHNlY3Rp b24gNzoNCg0KICBUaGUgZm9sbG93aW5nIHNlY3Rpb24gY29udGFpbnMgdGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIHRlbXBsYXRlDQoNCiAgIGRhdGVkIDIwMTAtMDYtMTYuDQpOb3Qgc3VyZSB3 aHkgaXQgY29udGFpbnMgdGhpcyBjdXQvcGFzdGU/IEl0IHNob3VsZCBqdXN0IHNheTogdGhlIGxh dGVzdCB2ZXJzaW9uIGlzIGF0IHRoaXMgVVJMLg0KVGhlbiwgSSBzZWUgaW4gdGhlIHNhbWUgc2Vj dGlvbjoNCg0KVGhpcyBzZWN0aW9uIE1VU1QgYmUgcGF0dGVybmVkIGFmdGVyIHRoZSBsYXRlc3Qg YXBwcm92ZWQNCg0KICAgdGVtcGxhdGUgKGF2YWlsYWJsZSBhdA0KDQoNCg0KICAgIGh0dHA6Ly93 d3cub3BzLmlldGYub3JnL25ldGNvbmYveWFuZy1zZWN1cml0eS1jb25zaWRlcmF0aW9ucy50eHQN ClRoaXMgcGFnZSBpcyBub3QgZm91bmQuDQpUaGlzIHNob3VsZCBiZSBjb3JyZWN0ZWQgaW4gcmZj NjA4N2Jpcy4NCg0KDQoyLiB0aGUgbmV3IHNlY3VyaXR5IGd1aWRlbGluZXMgbXVzdCBpbmNsdWRl IFJFU1RDT05GLg0KQXQgdGhpcyBwb2ludCwgdGhpcyBpcyBhIGJsb2NraW5nIGZhY3RvciBmb3Ig dGhlIHB1YmxpY2F0aW9uIG9mIFlBTkcgbW9kdWxlLiBBcyBhbiBleGFtcGxlLA0KZHJhZnQtaWV0 Zi1sbWFwLXlhbmctMTE8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1sbWFwLXlhbmcvPiwgQSBZQU5HIERhdGEgTW9kZWwgZm9yIExNQVAgTWVhc3VyZW1lbnQgQWdl bnRzLCBvbiB0aGUgdGVsZWNoYXQgdG9tb3Jyb3cuDQpBcyBtZW50aW9uZWQgdGhlIG1vc3QgdXAg dG8gZGF0ZSB2ZXJzaW9uIGlzIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL29wcy93aWtpL3lh bmctc2VjdXJpdHktZ3VpZGVsaW5lcw0KDQpIZXJlIGlzIHRoZSBwcm9wb3NhbCwgZGlzY3Vzc2Vk IG9uIHRoZSBZQU5HIGRvY3RvcnMgbGlzdDoNCg0KICAgICAgICBPTEQNClRoZSBZQU5HIG1vZHVs ZSBkZWZpbmVkIGluIHRoaXMgbWVtbyBpcyBkZXNpZ25lZCB0byBiZSBhY2Nlc3NlZCB2aWEgdGhl IE5FVENPTkYgcHJvdG9jb2wgW1JGQzYyNDFdLiBUaGUgbG93ZXN0IE5FVENPTkYgbGF5ZXIgaXMg dGhlIHNlY3VyZSB0cmFuc3BvcnQgbGF5ZXIsIGFuZCB0aGUgbWFuZGF0b3J5LXRvLWltcGxlbWVu dCBzZWN1cmUgdHJhbnNwb3J0IGlzIFNlY3VyZSBTaGVsbCAoU1NIKSBbUkZDNjI0Ml0uIFRoZSBO RVRDT05GIGFjY2VzcyBjb250cm9sIG1vZGVsIFtSRkM2NTM2XSBwcm92aWRlcyB0aGUgbWVhbnMg dG8gcmVzdHJpY3QgYWNjZXNzIGZvciBwYXJ0aWN1bGFyIE5FVENPTkYgdXNlcnMgdG8gYSBwcmUt Y29uZmlndXJlZCBzdWJzZXQgb2YgYWxsIGF2YWlsYWJsZSBORVRDT05GIHByb3RvY29sIG9wZXJh dGlvbnMgYW5kIGNvbnRlbnQuDQpORVcNCg0KVGhlIFlBTkcgbW9kdWxlIGRlZmluZWQgaW4gdGhp cyBtZW1vIGlzIGRlc2lnbmVkIHRvIGJlIGFjY2Vzc2VkIHZpYSB0aGUgTkVUQ09ORiBbUkZDNjI0 MV0gb3IgUkVTVENPTkYgW1JGQzgwNDBdIHByb3RvY29sLiBUaGUgbG93ZXN0IE5FVENPTkYgbGF5 ZXIgaXMgdGhlIHNlY3VyZSB0cmFuc3BvcnQgbGF5ZXIsIGFuZCBtYW5kYXRvcnktdG8taW1wbGVt ZW50IGlzIFNlY3VyZSBTaGVsbCAoU1NIKSBbUkZDNjI0Ml0sIHdoaWxlIHRoZSBsb3dlc3QgUkVT VENPTkYgbGF5ZXIgaXMgSFRUUCwgYW5kIHRoZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IHNlY3Vy ZSB0cmFuc3BvcnQgaXMgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIFtSRkM1MjQ2XS4N ClRoZSBORVRDT05GIGFjY2VzcyBjb250cm9sIG1vZGVsIFtSRkM2NTM2XSBwcm92aWRlcyB0aGUg bWVhbnMgdG8gcmVzdHJpY3QgYWNjZXNzIGZvciBwYXJ0aWN1bGFyIE5FVENPTkYgb3IgUkVTVENP TkYgdXNlcnMgdG8gYSBwcmUtY29uZmlndXJlZCBzdWJzZXQgb2YgYWxsIGF2YWlsYWJsZSBORVRD T05GIG9yIFJFU1RDT05GIHByb3RvY29sIG9wZXJhdGlvbnMgYW5kIGNvbnRlbnQuDQpBbnkgb2Jq ZWN0aW9ucz8NCkhhdmUgY292ZXJlZCBhbGwgdGhhdCB3ZSBuZWVkIGZvciB0aGUgbmV3IFJFU1RD T05GIHByb3RvY29sPw0KUmVnYXJkcywgQmVub2l0DQoNCg0KSGksDQoNCg0KDQp0aGlzIGNhbWUg dXAgZHVyaW5nIElFU0cgcHJvY2Vzc2luZyBvZiBhIFlBTkcgbW9kdWxlIC0gaXMgdGhlcmUgYSBu ZXcNCg0Kc2VjdXJpdHkgZ3VpZGVsaW5lIGJvaWxlcnBsYXRlIHRleHQgY292ZXJpbmcgUkVTVENP TkY/IFRoaXMgd2FzDQoNCmJyaWVmbHkgZGlzY3Vzc2VkIG9uIHRoZSB5YW5nLWRvY3RvcnMgYnV0 IHNvbWVob3cgdGhlIGRpc2N1c3Npb24NCg0Kc3RvcHBlZCBiZWNhdXNlIFJFU1RDT05GIHdhcyBu b3QgcHVibGlzaGVkIHlldCBhdCB0aGF0IHRpbWUuIEkgdGhpbmsNCg0KdGhpcyBhZmZlY3RzIGRy YWZ0LWlldGYtbmV0bW9kLXJmYzYwODdiaXMtMTIudHh0Lg0KDQoNCg0KZHJhZnQtaWV0Zi1uZXRt b2QtcmZjNjA4N2Jpcy0xMi50eHQgaGFzIHNldmVyYWwgcG9pbnRlcnMgdG8gcmVhZA0KDQpvbmxp bmUgZG9jdW1lbnRzIC0gd2h5IGRvIHdlIG5lZWQgc2V2ZXJhbCBwb2ludHM/IEkgdGhpbmsgc29t ZSBhcmUNCg0KYWxzbyBub3Qgd29ya2luZy4gSWRlYWxseSwgdGhlcmUgc2hvdWxkIGJlIGEgc2lu Z2xlIHN0YWJsZSBVUkwuDQoNCg0KDQovanMNCg0KDQoNCg0K --_000_8E887FD198494A05A43FCF675056A7B5junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xv cjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5v bmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpIj5CZW5vaXQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpIj5JIGZpeGVkIHRoaXMgdGV4dCBpbiBteSBkcmFmdHMgYWxyZWFkeS4m bmJzcDsgQWN0dWFsbHksIEkgZm91bmQgdGhlIG9sZCB0ZXh0IGRpZmZpY3VsdCB0bw0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmkiPnJlYWQsIHNvIEkgZml4ZWQgaXQgbGlrZSB0aGlzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7IFRoZSBZ QU5HIG1vZHVsZSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgZGVzaWduZWQgdG8gYmUgYWNj ZXNzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7IHZpYSBZQU5HIGJhc2VkIG1h bmFnZW1lbnQgcHJvdG9jb2xzLCBzdWNoIGFzIE5FVENPTkYgWzxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjQxIiB0aXRsZT0iJnF1b3Q7TmV0d29yayBDb25maWd1cmF0 aW9uIFByb3RvY29sIChORVRDT05GKSZxdW90OyI+UkZDNjI0MTwvYT5dIGFuZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsgUkVTVENPTkYgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM4MDQwIiB0aXRsZT0iJnF1b3Q7UkVTVENPTkYgUHJvdG9jb2wmcXVv dDsiPlJGQzgwNDA8L2E+XS4mbmJzcDsgQm90aCBvZiB0aGVzZSBwcm90b2NvbHMgaGF2ZSBtYW5k YXRvcnktdG8tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyBpbXBsZW1lbnQgc2Vj dXJlIHRyYW5zcG9ydCBsYXllcnMgKGUuZy4sIFNTSCwgVExTKSB3aXRoIG11dHVhbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsgYXV0aGVudGljYXRpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsgVGhlIE5FVENP TkYgYWNjZXNzIGNvbnRyb2wgbW9kZWwgKE5BQ00pIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNjUzNiIgdGl0bGU9IiZxdW90O05ldHdvcmsgQ29uZmlndXJhdGlvbiBQ cm90b2NvbCAoTkVUQ09ORikgQWNjZXNzIENvbnRyb2wgTW9kZWwmcXVvdDsiPlJGQzY1MzY8L2E+ XSBwcm92aWRlcyB0aGUgbWVhbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7IHRv IHJlc3RyaWN0IGFjY2VzcyBmb3IgcGFydGljdWxhciB1c2VycyB0byBhIHByZS1jb25maWd1cmVk IHN1YnNldCBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsgYWxsIGF2YWlsYWJs ZSBwcm90b2NvbCBvcGVyYXRpb25zIGFuZCBjb250ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7IChmcm9tOiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLWtleXN0b3JlLTAxI3NlY3Rpb24t NCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5SZWxh dGVkLCBJIHdhc24ndCBlbnRpcmVseSBzdXJlIGhvdyB0byBoYW5kbGUgdGhlIHNpdHVhdGlvbiB3 aGVyZSBhIGRyYWZ0IHVzZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Z3JvdXBpbmdzIGZyb20gYW5v dGhlciBkcmFmdC4mbmJzcDsgRG9lcyBpdCBzaW1wbHkgcG9pbnQgdG8gdGhlIG90aGVyIGRyYWZ0 J3MgU2VjdXJpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Q29uc2lkZXJhdGlvbnMsIG9yIHJlY3Jl YXRlIHRoZW0gaW4gaXRzIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24/Jm5ic3A7IEZv ciBub3csPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkkgY2hvc2UgdGhlIGZvcm1lciwgZm9yIGluc3Rh bmNlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5i c3A7Jm5ic3A7IFRoZSBZQU5HIG1vZHVsZSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgdXNlcyBn cm91cGluZ3MgZGVmaW5lZCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsgWzxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtbmV0 Y29uZi1jbGllbnQtc2VydmVyLTAyI3JlZi1JLUQuaWV0Zi1uZXRjb25mLXNzaC1jbGllbnQtc2Vy dmVyIj5JLUQuaWV0Zi1uZXRjb25mLXNzaC1jbGllbnQtc2VydmVyPC9hPl0gYW5kIFs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLW5ldGNvbmYt Y2xpZW50LXNlcnZlci0wMiNyZWYtSS1ELmlldGYtbmV0Y29uZi10bHMtY2xpZW50LXNlcnZlciI+ SS1ELmlldGYtbmV0Y29uZi10bHMtY2xpZW50LXNlcnZlcjwvYT5dLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwO1BsZWFzZSBzZWUgdGhlIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIHNlY3Rpb24gaW4gdGhvc2UgZG9jdW1lbnRzIGZvcg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmkiPiZuYnNwOyZuYnNwOyZuYnNwO2NvbmNlcm5zIHJlbGF0ZWQgdGhvc2UgZ3JvdXBpbmdzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5i c3A7IChmcm9tOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25m LW5ldGNvbmYtY2xpZW50LXNlcnZlci0wMiNzZWN0aW9uLTUpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5LZW50Jm5ic3A7IC8vIGNvbnRyaWJ1dG9yPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSI+LS0tLS1PUklHSU5BTCBNRVNTQUdFLS0tLS0tPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gMy8xNS8xNywgMTI6NDUgUE0sICZxdW90O25ldG1vZCBvbiBi ZWhhbGYgb2YgQmVub2l0IENsYWlzZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1i b3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9m DQo8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20iPmJjbGFpc2VAY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RGVhciBhbGwsPGJyPg0KPGJyPg0KW2NvcHlpbmcgdGhlIHNlY3Vy aXR5IEFEcyB0byBtYWtlIHN1cmUgdGhlIG5ldyBzZWN1cml0eSBzZWN0aW9uIGlzIGZpbmVdIDxi cj4NCkxldCdzIHNlcGFyYXRlIHRoZSB0d28gaXNzdWVzPGJyPg0KPGJyPg0KMS4gdGhlIG11bHRp cGxlIFVSTHMgaW4gZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjA4N2Jpcy0xMi50eHQ8YnI+DQpCYXNp Y2FsbHksIEkgYWdyZWUgd2l0aCBKw7xyZ2VuPGJyPg0KSSBzZWUgc2VjdGlvbiA0Ljc6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoaXMgc2VjdGlvbiBNVVNUIGJlIHBhdHRl cm5lZCBhZnRlciB0aGUgbGF0ZXN0IGFwcHJvdmVkIHRlbXBsYXRlPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IChhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYXJlYS9vcHMvdHJhYy93aWtpL3lhbmctc2VjdXJpdHktZ3VpZGVsaW5lcyI+ aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9vcHMvdHJhYy93aWtpLzwvYT48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9vcHMvdHJhYy93aWtpL3lhbmctc2VjdXJpdHktZ3VpZGVsaW5lcyI+eWFu Zy1zZWN1cml0eS1ndWlkZWxpbmVzPC9hPikuJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzLTEyI3NlY3Rpb24tNy4x Ij5TZWN0aW9uIDcuMTwvYT4gY29udGFpbnMgdGhlIHNlY3VyaXR5PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IGNvbnNpZGVyYXRpb25zIHRlbXBsYXRlIGRhdGVkIDIwMTMtMDUt MDguJm5ic3A7IEF1dGhvcnMgTVVTVCBjaGVjayB0aGUgV0VCPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IHBhZ2UgYXQgdGhlIFVSTCBsaXN0ZWQgYWJvdmUgaW4gY2FzZSB0aGVy ZSBpcyBhIG1vcmUgcmVjZW50IHZlcnNpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgYXZhaWxhYmxlLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGVuLCBJIHNlZSBzZWN0aW9uIDc6IDxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cHJlPiZuYnNwOyZuYnNwO1RoZSBmb2xsb3dpbmcgc2VjdGlvbiBjb250YWlucyB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgdGVtcGxhdGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgZGF0ZWQgMjAxMC0wNi0xNi48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHN1cmUgd2h5IGl0IGNvbnRhaW5zIHRoaXMgY3V0L3Bh c3RlPyBJdCBzaG91bGQganVzdCBzYXk6IHRoZSBsYXRlc3QgdmVyc2lvbiBpcyBhdCB0aGlzIFVS TC48YnI+DQpUaGVuLCBJIHNlZSBpbiB0aGUgc2FtZSBzZWN0aW9uOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cHJlPlRoaXMgc2VjdGlvbiBNVVNUIGJlIHBhdHRlcm5lZCBhZnRlciB0aGUgbGF0ZXN0IGFw cHJvdmVkPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRlbXBsYXRlIChhdmFp bGFibGUgYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5vcHMuaWV0Zi5vcmcv bmV0Y29uZi95YW5nLXNlY3VyaXR5LWNvbnNpZGVyYXRpb25zLnR4dCI+aHR0cDovL3d3dy5vcHMu aWV0Zi5vcmcvbmV0Y29uZi95YW5nLXNlY3VyaXR5LWNvbnNpZGVyYXRpb25zLnR4dDwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBw YWdlIGlzIG5vdCBmb3VuZC48YnI+DQpUaGlzIHNob3VsZCBiZSBjb3JyZWN0ZWQgaW4gcmZjNjA4 N2Jpcy48YnI+DQo8YnI+DQo8YnI+DQoyLiB0aGUgbmV3IHNlY3VyaXR5IGd1aWRlbGluZXMgbXVz dCBpbmNsdWRlIFJFU1RDT05GLjxicj4NCkF0IHRoaXMgcG9pbnQsIHRoaXMgaXMgYSBibG9ja2lu ZyBmYWN0b3IgZm9yIHRoZSBwdWJsaWNhdGlvbiBvZiBZQU5HIG1vZHVsZS4gQXMgYW4gZXhhbXBs ZSwNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbG1hcC15YW5nLyI+ ZHJhZnQtaWV0Zi1sbWFwLXlhbmctMTE8L2E+LCBBIFlBTkcgRGF0YSBNb2RlbCBmb3IgTE1BUCBN ZWFzdXJlbWVudCBBZ2VudHMsIG9uIHRoZSB0ZWxlY2hhdCB0b21vcnJvdy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgbWVudGlvbmVkIHRoZSBtb3N0IHVw IHRvIGRhdGUgdmVyc2lvbiBpcyA8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9v cHMvd2lraS95YW5nLXNlY3VyaXR5LWd1aWRlbGluZXMiPg0KaHR0cHM6Ly90cmFjLmlldGYub3Jn L3RyYWMvb3BzL3dpa2kveWFuZy1zZWN1cml0eS1ndWlkZWxpbmVzPC9hPjxicj4NCjxicj4NCkhl cmUgaXMgdGhlIHByb3Bvc2FsLCBkaXNjdXNzZWQgb24gdGhlIFlBTkcgZG9jdG9ycyBsaXN0Ojxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgT0xEPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7Zm9udC12YXJpYW50 LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsO2ZvbnQtdmFy aWFudC1udW1lcmljOiBub3JtYWw7Zm9udC12YXJpYW50LWFsdGVybmF0ZXM6IG5vcm1hbDtmb250 LXZhcmlhbnQtZWFzdC1hc2lhbjoNCiAgICAgICAgICBub3JtYWw7d2lkb3dzOiAxIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NClRoZSBZQU5HIG1vZHVsZSBkZWZp bmVkIGluIHRoaXMgbWVtbyBpcyBkZXNpZ25lZCB0byBiZSBhY2Nlc3NlZCB2aWEgdGhlIE5FVENP TkYgcHJvdG9jb2wgW1JGQzYyNDFdLiBUaGUgbG93ZXN0IE5FVENPTkYgbGF5ZXIgaXMgdGhlIHNl Y3VyZSB0cmFuc3BvcnQgbGF5ZXIsIGFuZCB0aGUgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBzZWN1 cmUgdHJhbnNwb3J0IGlzIFNlY3VyZSBTaGVsbCAoU1NIKSBbUkZDNjI0Ml0uIFRoZSBORVRDT05G IGFjY2VzcyBjb250cm9sDQogbW9kZWwgW1JGQzY1MzZdIHByb3ZpZGVzIHRoZSBtZWFucyB0byBy ZXN0cmljdCBhY2Nlc3MgZm9yIHBhcnRpY3VsYXIgTkVUQ09ORiB1c2VycyB0byBhIHByZS1jb25m aWd1cmVkIHN1YnNldCBvZiBhbGwgYXZhaWxhYmxlIE5FVENPTkYgcHJvdG9jb2wgb3BlcmF0aW9u cyBhbmQgY29udGVudC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+TkVXPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+VGhlIFlBTkcgbW9kdWxlIGRlZmluZWQgaW4gdGhpcyBtZW1v IGlzIGRlc2lnbmVkIHRvIGJlIGFjY2Vzc2VkIHZpYSB0aGUgTkVUQ09ORiBbUkZDNjI0MV0gb3Ig UkVTVENPTkYgW1JGQzgwNDBdIHByb3RvY29sLiBUaGUgbG93ZXN0IE5FVENPTkYgbGF5ZXIgaXMg dGhlIHNlY3VyZSB0cmFuc3BvcnQgbGF5ZXIsIGFuZCBtYW5kYXRvcnktdG8taW1wbGVtZW50IGlz IFNlY3VyZQ0KIFNoZWxsIChTU0gpIFtSRkM2MjQyXSwgd2hpbGUgdGhlIGxvd2VzdCBSRVNUQ09O RiBsYXllciBpcyBIVFRQLCBhbmQgdGhlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgc2VjdXJlIHRy YW5zcG9ydCBpcyBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgW1JGQzUyNDZdLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+VGhlIE5FVENPTkYgYWNjZXNzIGNvbnRyb2wgbW9kZWwgW1JGQzY1MzZd IHByb3ZpZGVzIHRoZSBtZWFucyB0byByZXN0cmljdCBhY2Nlc3MgZm9yIHBhcnRpY3VsYXIgTkVU Q09ORiBvciBSRVNUQ09ORiB1c2VycyB0byBhIHByZS1jb25maWd1cmVkIHN1YnNldCBvZiBhbGwg YXZhaWxhYmxlIE5FVENPTkYgb3IgUkVTVENPTkYgcHJvdG9jb2wgb3BlcmF0aW9ucyBhbmQgY29u dGVudC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QW55IG9iamVjdGlv bnM/PGJyPg0KSGF2ZSBjb3ZlcmVkIGFsbCB0aGF0IHdlIG5lZWQgZm9yIHRoZSBuZXcgUkVTVENP TkYgcHJvdG9jb2w/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UmVnYXJkcywgQmVub2l0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHByZT5IaSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT50aGlzIGNhbWUgdXAgZHVyaW5nIElFU0cgcHJvY2Vzc2luZyBvZiBhIFlB TkcgbW9kdWxlIC0gaXMgdGhlcmUgYSBuZXc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zZWN1cml0 eSBndWlkZWxpbmUgYm9pbGVycGxhdGUgdGV4dCBjb3ZlcmluZyBSRVNUQ09ORj8gVGhpcyB3YXM8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5icmllZmx5IGRpc2N1c3NlZCBvbiB0aGUgeWFuZy1kb2N0 b3JzIGJ1dCBzb21laG93IHRoZSBkaXNjdXNzaW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+c3Rv cHBlZCBiZWNhdXNlIFJFU1RDT05GIHdhcyBub3QgcHVibGlzaGVkIHlldCBhdCB0aGF0IHRpbWUu IEkgdGhpbms8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGlzIGFmZmVjdHMgZHJhZnQtaWV0Zi1u ZXRtb2QtcmZjNjA4N2Jpcy0xMi50eHQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+ZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjA4N2Jpcy0xMi50eHQg aGFzIHNldmVyYWwgcG9pbnRlcnMgdG8gcmVhZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9ubGlu ZSBkb2N1bWVudHMgLSB3aHkgZG8gd2UgbmVlZCBzZXZlcmFsIHBvaW50cz8gSSB0aGluayBzb21l IGFyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFsc28gbm90IHdvcmtpbmcuIElkZWFsbHksIHRo ZXJlIHNob3VsZCBiZSBhIHNpbmdsZSBzdGFibGUgVVJMLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi9qczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_8E887FD198494A05A43FCF675056A7B5junipernet_-- From nobody Wed Mar 15 12:02:35 2017 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 993421317C4 for ; Wed, 15 Mar 2017 12:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 h8ysMf0M2aUF for ; Wed, 15 Mar 2017 12:02:32 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 B1DA31317C1 for ; Wed, 15 Mar 2017 12:02:32 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-03v.sys.comcast.net with SMTP id oEA3cV9uKdEjjoEBrciffL; Wed, 15 Mar 2017 19:02:31 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-17v.sys.comcast.net with SMTP id oEBqc0051UA1toEBrcwtOm; Wed, 15 Mar 2017 19:02:31 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2FJ2Ujx019671; Wed, 15 Mar 2017 15:02:30 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2FJ2TN3019668; Wed, 15 Mar 2017 15:02:30 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: JOEY BOYD Cc: netmod@ietf.org In-Reply-To: <26CE489EF4611643B3EFE43D06E02654015E6596C7@ex-mb1.corp.adtran.com> (joey.boyd@adtran.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 15 Mar 2017 15:02:29 -0400 Message-ID: <877f3q2wje.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJAPLcIq3MGvA58KKuF6Xg7pPoFG2HZ2chEfE+26I2adWDSV/1LO+xQUU2c9vyRWjzuV56+nEOIaYpIPlRsruC18Yl89S2bfSE8JEnQzdiJrDqnjQ7c3 0xCx6yNGGkfwVdBRN2NPYE03c7NaLkDBPgRwwHp6XtDMi1GT9sT38vMHeKWVolJgNdQ3O7V+pncc3A== Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 19:02:34 -0000 JOEY BOYD writes: > module base-module { > prefix bmod; > > feature do-things; > > container things { > if-feature do-things; > ... > } > } > > module augment-module { > prefix amod; > > augment "/bmod:do-things" { > container other-things { > } > } > } First question: I'm not expert in Yang, but as far as I can figure out, the augment statement is augmenting "container things", right? So the augment statement should be 'augment "/bmod:things"' not 'augment "/bmod:do-things"'. But on the important question, I don't see it as at all unreasonable that the augment needs to be qualified by the same if-feature. The reason is that if you're reading the text of module augment-module, it's helpful to have documented, right there, that the augmentation depends on the presence of a particular feature in the augmented module. And it's helpful to know that the designer did, at least for one moment, think about the fact that the augmentation is conditional. Dale From nobody Wed Mar 15 12:10:31 2017 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 9B9C51317B0; Wed, 15 Mar 2017 12:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 txK_sGQ_94rL; Wed, 15 Mar 2017 12:10:27 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88BEF1316AC; Wed, 15 Mar 2017 12:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25737; q=dns/txt; s=iport; t=1489605026; x=1490814626; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=ZC6lvbagl4ICdeuw2/5+XPTtHFjYLsDJX+VZdTrCTzU=; b=E+WVySfMyY6/TVNEUS4arMlakCrD2yYhBNLdkbe7v1wbyZxYz2HN0LnG pdwXUNm4hLgy2gzCL+cdeK+sV6kSma0WX0Hh5+2f4Cix6wmgZVAXBmlZ3 06tiTCHwU3BXT4q/GMhyClk4eZbG4kj3KNqBycMRh/6qOIaJP675+X1gv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAgDpkMlY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm6BRCpgg2CKDXOQRB+TLYIPgg4uhXQCgzEYAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECASNWBQsJAg4KIAcDAgJGEQYBDAYCAQGJdAgOkSidW4ImK4o0AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYZOggUIgmKEPoMcgl8FnEOGdotFgXtUhFGDMiO?= =?us-ascii?q?GMIs4iA8fOD5GIxYIFxVBhlg/NQEBiTABAQE?= X-IronPort-AV: E=Sophos;i="5.36,170,1486425600"; d="scan'208,217";a="650452421" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2017 19:10:23 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2FJAKO6009029; Wed, 15 Mar 2017 19:10:23 GMT To: Kent Watsen , "netmod@ietf.org" References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> Cc: "sec-ads@ietf.org" From: Benoit Claise Message-ID: <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> Date: Wed, 15 Mar 2017 20:10:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> Content-Type: multipart/alternative; boundary="------------316676C86B8475EA725E7197" Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 19:10:30 -0000 This is a multi-part message in MIME format. --------------316676C86B8475EA725E7197 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/15/2017 6:32 PM, Kent Watsen wrote: > > Benoit, > > I fixed this text in my drafts already. Actually, I found the old > text difficult to > > read, so I fixed it like this: > > The YANG module defined in this document is designed to be accessed > > via YANG based management protocols, such as NETCONF [RFC6241 > ] and > > RESTCONF [RFC8040 ]. Both of > these protocols have mandatory-to- > > implement secure transport layers (e.g., SSH, TLS) with mutual > > authentication. > > The NETCONF access control model (NACM) [RFC6536 > ] provides the means > > to restrict access for particular users to a pre-configured subset of > > all available protocol operations and content. > > (from: > https://tools.ietf.org/html/draft-ietf-netconf-keystore-01#section-4). > I like the "YANG based management protocols" part Trying the combine the different proposals: The YANG module defined in this document is designed to be accessed via YANG based management protocols, NETCONF [RFC6241 ] or RESTCONF [RFC8040 ]. The lowest NETCONF layer is the secure transport layer, and mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242], while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement secure transport is Transport Layer Security (TLS) [RFC5246]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. > Related, I wasn't entirely sure how to handle the situation where a > draft uses > > groupings from another draft. Does it simply point to the other > draft's Security > > Considerations, or recreate them in its Security Considerations > section? For now, > > I chose the former, for instance: > > The YANG module defined in this document uses groupings defined in > > [I-D.ietf-netconf-ssh-client-server > ] > and [I-D.ietf-netconf-tls-client-server > ]. > > > Please see the Security Considerations section in those documents for > > concerns related those groupings. > I believe this is the right approach. Regards, Benoit > > (from: > https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-02#section-5) > > Thanks, > > Kent // contributor > > -----ORIGINAL MESSAGE------ > > On 3/15/17, 12:45 PM, "netmod on behalf of Benoit Claise" > on behalf of > bclaise@cisco.com > wrote: > > Dear all, > > [copying the security ADs to make sure the new security section is fine] > Let's separate the two issues > > 1. the multiple URLs in draft-ietf-netmod-rfc6087bis-12.txt > Basically, I agree with Jürgen > I see section 4.7: > > This section MUST be patterned after the latest approved template > > (available athttp://trac.tools.ietf.org/area/ops/trac/wiki/ > > > yang-security-guidelines > ).Section 7.1 > contains the security > > considerations template dated 2013-05-08. Authors MUST check the WEB > > page at the URL listed above in case there is a more recent version > > available. > > Then, I see section 7: > > The following section contains the security considerations template > > dated 2010-06-16. > > Not sure why it contains this cut/paste? It should just say: the > latest version is at this URL. > Then, I see in the same section: > > This section MUST be patterned after the latest approved > > template (available at > > http://www.ops.ietf.org/netconf/yang-security-considerations.txt > > This page is not found. > This should be corrected in rfc6087bis. > > > 2. the new security guidelines must include RESTCONF. > At this point, this is a blocking factor for the publication of YANG > module. As an example, > > draft-ietf-lmap-yang-11 > , A YANG Data > Model for LMAP Measurement Agents, on the telechat tomorrow. > > As mentioned the most up to date version is > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines > > Here is the proposal, discussed on the YANG doctors list: > > OLD > > The YANG module defined in this memo is designed to be > accessed via the NETCONF protocol [RFC6241]. The lowest > NETCONF layer is the secure transport layer, and the > mandatory-to-implement secure transport is Secure Shell (SSH) > [RFC6242]. The NETCONF access control model [RFC6536] provides > the means to restrict access for particular NETCONF users to a > pre-configured subset of all available NETCONF protocol > operations and content. > > NEW > > The YANG module defined in this memo is designed to be > accessed via the NETCONF [RFC6241] or RESTCONF [RFC8040] > protocol. The lowest NETCONF layer is the secure transport > layer, and mandatory-to-implement is Secure Shell (SSH) > [RFC6242], while the lowest RESTCONF layer is HTTP, and the > mandatory-to-implement secure transport is Transport Layer > Security (TLS) [RFC5246]. > > The NETCONF access control model [RFC6536] provides the means > to restrict access for particular NETCONF or RESTCONF users to > a pre-configured subset of all available NETCONF or RESTCONF > protocol operations and content. > > Any objections? > Have covered all that we need for the new RESTCONF protocol? > > Regards, Benoit > > Hi, > > this came up during IESG processing of a YANG module - is there a new > > security guideline boilerplate text covering RESTCONF? This was > > briefly discussed on the yang-doctors but somehow the discussion > > stopped because RESTCONF was not published yet at that time. I think > > this affects draft-ietf-netmod-rfc6087bis-12.txt. > > draft-ietf-netmod-rfc6087bis-12.txt has several pointers to read > > online documents - why do we need several points? I think some are > > also not working. Ideally, there should be a single stable URL. > > /js > > > --------------316676C86B8475EA725E7197 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/15/2017 6:32 PM, Kent Watsen wrote:

 

Benoit,

 

I fixed this text in my drafts already.  Actually, I found the old text difficult to

read, so I fixed it like this:

 

   The YANG module defined in this document is designed to be accessed

   via YANG based management protocols, such as NETCONF [RFC6241] and

   RESTCONF [RFC8040].  Both of these protocols have mandatory-to-

   implement secure transport layers (e.g., SSH, TLS) with mutual

   authentication.

 

   The NETCONF access control model (NACM) [RFC6536] provides the means

   to restrict access for particular users to a pre-configured subset of

   all available protocol operations and content.

 

   (from: https://tools.ietf.org/html/draft-ietf-netconf-keystore-01#section-4).


I like the "YANG based management protocols" part

Trying the combine the different proposals:
   The YANG module defined in this document is designed to be accessed
   via YANG based management protocols, NETCONF [RFC6241] or
    RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer,
    and mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242],
    while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement secure
    transport is Transport Layer Security (TLS) [RFC5246].

    The NETCONF access control model [RFC6536] provides the means to restrict
    access for particular NETCONF or RESTCONF users to a pre-configured subset
    of all available NETCONF or RESTCONF protocol operations and content.

 

Related, I wasn't entirely sure how to handle the situation where a draft uses

groupings from another draft.  Does it simply point to the other draft's Security

Considerations, or recreate them in its Security Considerations section?  For now,

I chose the former, for instance:

 

   The YANG module defined in this document uses groupings defined in

   [I-D.ietf-netconf-ssh-client-server] and [I-D.ietf-netconf-tls-client-server].

   Please see the Security Considerations section in those documents for

   concerns related those groupings.

I believe this is the right approach.

Regards, Benoit

 

   (from: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-02#section-5)

 

 

Thanks,

Kent  // contributor

 

 

-----ORIGINAL MESSAGE------

 

On 3/15/17, 12:45 PM, "netmod on behalf of Benoit Claise" <netmod-bounces@ietf.org on behalf of bclaise@cisco.com> wrote:

 

Dear all,

[copying the security ADs to make sure the new security section is fine]
Let's separate the two issues

1. the multiple URLs in draft-ietf-netmod-rfc6087bis-12.txt
Basically, I agree with Jürgen
I see section 4.7:

   This section MUST be patterned after the latest approved template
   (available at http://trac.tools.ietf.org/area/ops/trac/wiki/
   yang-security-guidelines).  Section 7.1 contains the security
   considerations template dated 2013-05-08.  Authors MUST check the WEB
   page at the URL listed above in case there is a more recent version
   available.

Then, I see section 7: 

  The following section contains the security considerations template
   dated 2010-06-16.

Not sure why it contains this cut/paste? It should just say: the latest version is at this URL.
Then, I see in the same section:

This section MUST be patterned after the latest approved
   template (available at
 
    http://www.ops.ietf.org/netconf/yang-security-considerations.txt

This page is not found.
This should be corrected in rfc6087bis.


2. the new security guidelines must include RESTCONF.
At this point, this is a blocking factor for the publication of YANG module. As an example,

draft-ietf-lmap-yang-11, A YANG Data Model for LMAP Measurement Agents, on the telechat tomorrow.

As mentioned the most up to date version is https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

Here is the proposal, discussed on the YANG doctors list:

 

        OLD

The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content.

NEW

 

The YANG module defined in this memo is designed to be accessed via the NETCONF [RFC6241] or RESTCONF [RFC8040] protocol. The lowest NETCONF layer is the secure transport layer, and mandatory-to-implement is Secure Shell (SSH) [RFC6242], while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement secure transport is Transport Layer Security (TLS) [RFC5246]. 

The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content.

Any objections?
Have covered all that we need for the new RESTCONF protocol?

Regards, Benoit

 

Hi,
 
this came up during IESG processing of a YANG module - is there a new
security guideline boilerplate text covering RESTCONF? This was
briefly discussed on the yang-doctors but somehow the discussion
stopped because RESTCONF was not published yet at that time. I think
this affects draft-ietf-netmod-rfc6087bis-12.txt.
 
draft-ietf-netmod-rfc6087bis-12.txt has several pointers to read
online documents - why do we need several points? I think some are
also not working. Ideally, there should be a single stable URL.
 
/js
 




--------------316676C86B8475EA725E7197-- From nobody Wed Mar 15 15:59:15 2017 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 7709C129C67 for ; Wed, 15 Mar 2017 15:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeQdIEWpelkM for ; Wed, 15 Mar 2017 15:59:11 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 200AC129C62 for ; Wed, 15 Mar 2017 15:59:11 -0700 (PDT) Received: (qmail 16226 invoked by uid 0); 15 Mar 2017 22:59:07 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 15 Mar 2017 22:59:07 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id wNz31u00T2SSUrH01Nz6r5; Wed, 15 Mar 2017 16:59:07 -0600 X-Authority-Analysis: v=2.1 cv=R4+QR7hX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=6Iz7jQTuP9IA:10 a=wU2YTnxGAAAA:8 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=pGLkceISAAAA:8 a=xcTfSnc4AAAA:8 a=i0EeH86SAAAA:8 a=x78QIoBwFa2JUXZmt1AA:9 a=B2lBIY0MLYecI2lv:21 a=neFZ-MnPJhN2Bjq6:21 a=pILNOxqGKmIA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=cAcMbU7R10T-QSRYIcO_:22 a=w1C3t2QeGrPiZgrLijVG:22 a=TSZmLRzkpGLBZRr3r8m8:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=AlSe2FwLBhvzWS46gZ1m:22 a=02toJ7V-nxh73JlV0Smw:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=w8t5nrD+YTDJ4XY9/QbdsXKPWQMjnhSy//aRDYR7eKg=; b=H42oM6pKENDh1h+vJ7PruR1l7x ux02x01r6Fl9KV47zCt8snV5uxCIdfLQ8mXXoICktEc8ksC0wPNu6h9ese6hXQ3F1tibPO42QHnvC sf8JSK55hpGKP8ixUxC1G9Acm; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:41512 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1coHsl-0000ES-GP; Wed, 15 Mar 2017 16:59:03 -0600 To: Mehmet Ersue , 'Kent Watsen' , netmod@ietf.org References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> From: Lou Berger Message-ID: <675654fd-1532-1755-621c-a3ecb06950e3@labn.net> Date: Wed, 15 Mar 2017 18:59:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <02e701d29d93$0e770480$2b650d80$@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1coHsl-0000ES-GP X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.85.191]:41512 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:59:14 -0000 Mehmet, On 03/15/2017 09:50 AM, Mehmet Ersue wrote: > Hi Lou, Kent, > > it appears to me the issues I raised below are not closed. it wasn't clear from your mail that a response was needed as it seemed to be covering points otherwise discussed, and where we may not agree. It's good that you are re-raising them now. > > I believe at least a "minimal" WG item focus formulation is required to > match to the high-level WG focus topics in a)-f). I was thinking my proposal > below is acceptable. > I think we disagree on this point. That said, perhaps our objection is in the abstract and not the specific. Can you propose specific text change you'd like to see made to the charter and we can discuss it? > Netconf WG will ensure avoiding double-work concerning the DS concept draft, > however Netconf needs to specify what is required for the use of the DS > concept from protocol standards pov. okay. I think we agree that the protocol aspects belong in NetConf - and we're expecting those to be covered during the NetConf WG session in Chicago. > That said different people including Netconf WG co-chairs think the DS > concept document is Informational in nature and should be published as an > Informational concept to be used in and adopted for the needs in diverse > protocol WGs. okay. > This is as I think also important to avoid an overlapping > between NETCONF and NETMOD charters. I don't follow this point. Certainly I'd hope that the protocol impact of revised DS are covered in a PS document, unless for some reason there are no "on-the-wire" changes needed. TI wouldn't expect that the document status of the base revised data store document would impact that. Do you? If so, how? > PS: I expect that most of the Netconf WG member read also the Netmod > maillist and therefor skip sending to both ML. > Great. Thanks. Lou > Thanks, > Mehmet > >> -----Original Message----- >> From: Mehmet Ersue >> Sent: Thursday, March 9, 2017 7:36 PM >> To: Lou Berger ; 'Kent Watsen' ; >> netmod@ietf.org >> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' >> >> Subject: RE: [netmod] draft netmod charter update proposal >> >> Hi Lou, >> >>> The charters from the last couple of years don't have the intended > status -- >> at least the ones we checked. >>> I actually feel pretty strongly about this (which of course can be >>> easily overruled by our AD). It's my experience that premature >>> discussions on intended status, i.e., before a document is sufficiently >> mature, leads to process-focused arguments that detracts from making >> technical progress. While once a document is mature and core >> direction/content is fixed, it is generally obvious what status is > appropriate. >> >> The charters from the last couple of years have a short WG item > definition, >> which would be IMO sufficient. >> You are right the intended status is not available since a few years, but > IMO it >> is part of the target definition and would be very useful for the draft > authors >> and WG members to regard. >> >>>> It would be good to bring the high-level topics in relation to the WG >> items. >>> I'm sorry, I don't understand this last sentence can you rephrase it? >> >> What I meant is that the high-level topics a)-f) might be good as WG focus >> description but are not sufficient as draft target definition. >> If you think the high-level topic description is more or less the WG item >> definition, then we could simply write "this is achieved with WG item XY". >> If not, we could keep the high-level focus text but set additionally the >> borders of the WG item with some concrete words. >> >>>> BTW: We agreed in diverse discussions that the DS concept is >> Informational in nature. >>>> I think this should be corrected in the draft. >>> >>> So this sounds like an objection to a specific document. This is a >>> fair point to raise, but in our opinion it is not a charter impacting >>> point or discussion. If this is in fact the issue you'd like to raise >>> and discuss, lets do so under a document specific thread, e.g., > "Subject: >> intended status of revised-datastore". >> >> I am actually raising this point since November meeting. There are > different >> threads where I explained why it is appropriate as Informational. >> The last thread I remember is at: >> https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH1 >> 1xcY >> The recent position of NETCONF co-chairs is in >> https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd >> 8qr5k >> >> Thank you for your consideration. >> >> Regards, >> Mehmet >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Wednesday, March 8, 2017 11:28 PM >>> To: Mehmet Ersue ; 'Kent Watsen' >>> ; netmod@ietf.org >>> Subject: Re: [netmod] draft netmod charter update proposal >>> >>> Hi Mehmet, >>> >>> On 3/8/2017 4:47 PM, Mehmet Ersue wrote: >>>> Kent, >>>> >>>>> we understand that this is how NETCONF charters are structured, but >>>>> it is not our practice, >>>> AFAIK it was the NETMOD practice for the charters until today. >>> >>> The charters from the last couple of years don't have the intended >>> status -- at least the ones we checked. >>> >>> I actually feel pretty strongly about this (which of course can be >>> easily overruled by our AD). It's my experience that premature >>> discussions on intended status, i.e., before a document is >>> sufficiently mature, leads to process-focused arguments that detracts > from >> making technical progress. >>> While once a document is mature and core direction/content is fixed, >>> it is generally obvious what status is appropriate. >>> >>> >>>> I did not ask >>>> more than written in the current charter. >>>> It would be good to bring the high-level topics in relation to the WG >> items. >>> I'm sorry, I don't understand this last sentence can you rephrase it? >>> >>>>> as the information is available at the top of each draft, and also >>>>> because >>> this information need not be fixed when the milestone is added. >>> >>>> I believe a WG charter should be self-sufficient covering the target >>>> definition and intended status of the WG items. >>>> Otherwise one can change the target for a WG item by simply editing >>>> the draft abstract anytime. >>> >>> Per IETF process, all it ever takes to make a change in document >>> status is WG consensus, and then IESG and IETF buy-in as part of the >> publication process. >>> >>>> BTW: We agreed in diverse discussions that the DS concept is >>>> Informational in nature. >>>> I think this should be corrected in the draft. >>> >>> So this sounds like an objection to a specific document. This is a >>> fair point to raise, but in our opinion it is not a charter impacting >>> point or discussion. If this is in fact the issue you'd like to raise >>> and discuss, lets do so under a document specific thread, e.g., > "Subject: >>> intended status of revised-datastore". >>> >>> Thanks, >>> Lou >>> >>>> >>>> Mehmet >>>> >>>>> -----Original Message----- >>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent >>>>> Watsen >>>>> Sent: Wednesday, March 8, 2017 7:45 PM >>>>> To: netmod@ietf.org >>>>> Cc: netmod-chairs@ietf.org >>>>> Subject: Re: [netmod] draft netmod charter update proposal >>>>> >>>>> >>>>> >>>>> >>>>> Hi NETMOD WG, >>>>> >>>>> Please find below draft-4 having the following change: >>>>> >>>>> - added "(e.g., I2RS, RTGWG)" to a sentence. >>>>> >>>>> Hi Sue, Lou and I looked at the proposed charter and found a >>>>> sentence that nicely describes our WG's intent to work with and >>>>> support other WGs (beyond NETCONF), but we felt that the text could >>>>> be made more clear by adding in the above-mentioned change. Beyond >>>>> this, and the existing a), >>>> b), >>>>> and c), we believe that the charter proposal covers our support for >>>>> I2RS, >>>> do >>>>> you agree? >>>>> >>>>> Hi Mehmet, regarding putting a short description and the intended >>>>> status >>>> for >>>>> each draft into the charter, we understand that this is how NETCONF >>>> charters >>>>> are structured, but it is not our practice, as the information is >>>> available at the >>>>> top of each draft, and also because this information need not be >>>>> fixed >>>> when >>>>> the milestone is added. >>>>> >>>>> All, Any other comments? >>>>> >>>>> Kent >>>>> >>>>> >>>>> >>>>> >>>>> Network Modeling (NETMOD) >>>>> ------------------------- >>>>> >>>>> Charter >>>>> >>>>> Current Status: Active >>>>> >>>>> Chairs: >>>>> Lou Berger >>>>> Kent Watsen >>>>> >>>>> Operations and Management Area Directors: >>>>> Benoit Claise >>>>> Joel Jaeggli >>>>> >>>>> Operations and Management Area Advisor: >>>>> Benoit Claise >>>>> >>>>> Secretary: >>>>> Zitao (Michael) Wang >>>>> >>>>> Mailing Lists: >>>>> General Discussion: netmod@ietf.org >>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/netmod >>>>> Archive: > https://mailarchive.ietf.org/arch/browse/netmod/ >>>>> >>>>> Description of Working Group: >>>>> >>>>> The Network Modeling (NETMOD) working group is responsible for >>>>> the YANG >>>>> data modeling language, and guidelines for developing YANG models. >>> The >>>>> NETMOD working group addresses general topics related to the use >>>>> of >>> the >>>>> YANG language and YANG models, for example, the mapping of YANG >>>>> modeled >>>>> data into various encodings. Finally, the NETMOD working group >>>>> also defines core YANG models used as basic YANG building blocks, >> and >>>>> YANG models that do not otherwise fall under the charter of any > other >>>>> IETF working group. >>>>> >>>>> The NETMOD WG is responsible for: >>>>> >>>>> a) Maintaining the data modeling language YANG. This effort > entails >>>>> periodically updating the specification to address new > requirements >>>>> as they arise. >>>>> >>>>> b) Maintaining the guidelines for developing YANG models. This > effort >>>>> is primarily driven by updates made to the YANG specification. >>>>> >>>>> c) Maintaining a conceptual framework in which YANG models are >> used. >>>>> This effort entails describing the generic context that in YANG >>>>> exists and how certain YANG statements interact in that > context. >>>>> An example of this is YANG's relationship with datastores. >>>>> >>>>> d) Maintaining encodings for YANG modeled data. This effort > entails >>>>> updating encodings already defined by the NETMOD working (XML >> and >>>>> JSON) to accommodate changes to the YANG specification, and >>> defining >>>>> new encodings that are needed, and yet do not fall under the > charter >>>>> of any other active IETF working group. >>>>> >>>>> e) Maintaining YANG models used as basic YANG building blocks. > This >>>>> effort entails updating existing YANG models (ietf-yang-types > and >>>>> ietf-inet-types) as needed, as well as defining additional core > YANG >>>>> data models when necessary. >>>>> >>>>> f) Defining and maintaining YANG models that do not fall under the >>>>> charter of any other active IETF working group. >>>>> >>>>> The NETMOD working group consults with the NETCONF working >> group >>> to >>>>> ensure that new requirements are understood and can be met by the >>>>> protocols (e.g., NETCONF and RESTCONF) developed within that >> working >>>>> group. The NETMOD working group coordinates with other working >>> groups >>>>> (e.g., I2RS, RTGWG) on possible extensions to YANG to address new >>>>> modeling requirements and, when needed, which group will run the >>>>> process on a specific model. >>>>> >>>>> The NETMOD working group does not serve as a review team for >> YANG >>>>> modules developed by other working groups. Instead, the YANG >>> doctors, >>>>> as organized by the OPS area director responsible for network >>>>> management, will act as advisors for other working groups and > provide >>>>> YANG reviews for the OPS area directors. >>>>> >>>>> Milestones: >>>>> >>>>> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for > publication >>>>> Mar 2017 - Submit draft-ietf-netmod-yang-model-classification to > IESG >>>>> for publication >>>>> Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for > publication >>>>> Apr 2017 - Submit draft-ietf-netmod-entity to IESG for publication >>>>> Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG for >>>> publication >>>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for >>>> publication >>>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for >>>>> publication >>>>> Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for >>>>> publication >>>>> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for >>>>> publication >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> > > > From nobody Wed Mar 15 23:44:21 2017 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 2C1CB1243FE for ; Wed, 15 Mar 2017 23:44:20 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 lGE39_viqcLY for ; Wed, 15 Mar 2017 23:44:18 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1D2126579 for ; Wed, 15 Mar 2017 23:44:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AB9A812E0; Thu, 16 Mar 2017 07:44:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nhgA0D8ybqlR; Thu, 16 Mar 2017 07:44:14 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Mar 2017 07:44:15 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C72B20035; Thu, 16 Mar 2017 07:44:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yX4vZV5B_DB3; Thu, 16 Mar 2017 07:44:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04A8B20033; Thu, 16 Mar 2017 07:44:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 88D8E3EBE96C; Thu, 16 Mar 2017 07:44:19 +0100 (CET) Date: Thu, 16 Mar 2017 07:44:19 +0100 From: Juergen Schoenwaelder To: Mehmet Ersue Cc: 'Lou Berger' , 'Kent Watsen' , netmod@ietf.org Message-ID: <20170316064419.GA59114@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Mehmet Ersue , 'Lou Berger' , 'Kent Watsen' , netmod@ietf.org References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02e701d29d93$0e770480$2b650d80$@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 06:44:20 -0000 On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: > That said different people including Netconf WG co-chairs think the DS > concept document is Informational in nature and should be published as an > Informational concept to be used in and adopted for the needs in diverse > protocol WGs. This is as I think also important to avoid an overlapping > between NETCONF and NETMOD charters. The current datastore draft includes concrete YANG idenity definitions for datastores and origins and these definitions better be standards track. /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 Thu Mar 16 00:27:56 2017 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 9989B126D73; Thu, 16 Mar 2017 00:27:55 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 Cl_WvFENzDT0; Thu, 16 Mar 2017 00:27:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CEE6126D05; Thu, 16 Mar 2017 00:27:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 34C2F12D4; Thu, 16 Mar 2017 08:27:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id y_A4O1yiUa8K; Thu, 16 Mar 2017 08:27:51 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Mar 2017 08:27:53 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F080320035; Thu, 16 Mar 2017 08:27:52 +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 QbUgVLbXmrIY; Thu, 16 Mar 2017 08:27:52 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB77B20033; Thu, 16 Mar 2017 08:27:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EF6C03EBEC26; Thu, 16 Mar 2017 08:27:57 +0100 (CET) Date: Thu, 16 Mar 2017 08:27:57 +0100 From: Juergen Schoenwaelder To: Benoit Claise Cc: Kent Watsen , "netmod@ietf.org" , "sec-ads@ietf.org" Message-ID: <20170316072757.GD59114@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Benoit Claise , Kent Watsen , "netmod@ietf.org" , "sec-ads@ietf.org" References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 07:27:55 -0000 On Wed, Mar 15, 2017 at 08:10:22PM +0100, Benoit Claise wrote: > I like the "YANG based management protocols" part I think 'YANG based' is not needed (and to some extend even incorrect) and I would spell out 'network management' instead of 'management': The YANG module defined in this document is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. /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 Thu Mar 16 00:37:47 2017 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 29817126C23; Thu, 16 Mar 2017 00:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 syRv2ANtOZrl; Thu, 16 Mar 2017 00:37:44 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0C3126BF7; Thu, 16 Mar 2017 00:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1402; q=dns/txt; s=iport; t=1489649863; x=1490859463; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=YimrlcwGJ30LdUnadAq+2kUh4+1vWD7VoEwJnWMEon0=; b=I7SeKDBeYn57ZL4Lh24ox2ywBx1hUcM0OGvmrAlgjc8oNG8Ps4UEWS/x rKnd0wULuuHZJjJExFVzt58/oaR4pCY8t1Pso7anscLQ9qimRk2LdibTK MGXXg9J6MMXTVzd0Eh6iC/FS8QO3DysjlA3W0wbbqD4nGebK+Lmz//1iU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAgByQMpY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqj0OQZZMvgg+CDoYiAoNSFwECAQEBAQEBAWsohRYBBThRCw4?= =?us-ascii?q?KLlcGAQwIAQGJfLIdilQBAQEBAQEBAQIBAQEBAQEihk6CBYJqijkFnESSPYpUh?= =?us-ascii?q?lOLPIgPIAE2gQQjFggXFYcZP4l4AQEB?= X-IronPort-AV: E=Sophos;i="5.36,170,1486425600"; d="scan'208";a="653305016" 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; 16 Mar 2017 07:37:41 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2G7bePT019777; Thu, 16 Mar 2017 07:37:41 GMT To: Kent Watsen , "netmod@ietf.org" , "sec-ads@ietf.org" References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> From: Benoit Claise Message-ID: <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> Date: Thu, 16 Mar 2017 08:37:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170316072757.GD59114@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 07:37:45 -0000 On 3/16/2017 8:27 AM, Juergen Schoenwaelder wrote: > On Wed, Mar 15, 2017 at 08:10:22PM +0100, Benoit Claise wrote: > >> I like the "YANG based management protocols" part > I think 'YANG based' is not needed (and to some extend even incorrect) > and I would spell out 'network management' instead of 'management': > > The YANG module defined in this document is designed to be accessed > via network management protocols such as NETCONF [RFC6241] or > RESTCONF [RFC8040]. I could live with that. Latest proposal: The YANG module defined in this document is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242], while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement secure transport is Transport Layer Security (TLS) [RFC5246]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. I'll discuss this proposal with the security ADs during the telechat today, even if these changes should non controversial. Regards, Benoit > > /js > From nobody Thu Mar 16 00:57:04 2017 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 E925B126DC2; Thu, 16 Mar 2017 00:56:56 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 o22ttWoj6uHq; Thu, 16 Mar 2017 00:56:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1564D126C23; Thu, 16 Mar 2017 00:56:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D893426; Thu, 16 Mar 2017 08:56:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EJ6EYHsqYEv0; Thu, 16 Mar 2017 08:56:52 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Mar 2017 08:56:53 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 887A320035; Thu, 16 Mar 2017 08:56:53 +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 keVyAxTXy7Aj; Thu, 16 Mar 2017 08:56:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12CA720033; Thu, 16 Mar 2017 08:56:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5D3BC3EBED4D; Thu, 16 Mar 2017 08:56:57 +0100 (CET) Date: Thu, 16 Mar 2017 08:56:57 +0100 From: Juergen Schoenwaelder To: Benoit Claise Cc: Kent Watsen , "netmod@ietf.org" , "sec-ads@ietf.org" Message-ID: <20170316075657.GF59114@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Benoit Claise , Kent Watsen , "netmod@ietf.org" , "sec-ads@ietf.org" References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 07:56:57 -0000 On Thu, Mar 16, 2017 at 08:37:39AM +0100, Benoit Claise wrote: > Latest proposal: > > The YANG module defined in this document is designed to be accessed > via network management protocols such as NETCONF [RFC6241] or > RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport > layer, > and mandatory-to-implement secure transport is Secure Shell (SSH) > [RFC6242], > while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement > secure > transport is Transport Layer Security (TLS) [RFC5246]. Picking wording from Section 12 of RFC 8040 to replace your second sentence I get this: The YANG module defined in this document is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. /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 Thu Mar 16 01:02:13 2017 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 B11B0126E3A; Thu, 16 Mar 2017 01:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 gr6FzMfPT_zg; Thu, 16 Mar 2017 01:02:11 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A25126D74; Thu, 16 Mar 2017 01:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1467; q=dns/txt; s=iport; t=1489651330; x=1490860930; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=D3J1JHLYpD4t8Y1Q8tgjleiDRuBC+T37KS2gtmiOIsc=; b=jRlEo0uV1sNMRN/NZEeSloMknnQJndVeLolaHtnmZ9Iu3w+FeEy5b/f3 uVdoq8C7514VsvCmqpXJu2bOfZD1erek5Nir5gq0F6t0ZGWxMnY+4K5RM uoFydTIF3FqM8BehSlu9kYA0hzrFA6x2Uw6mkWwslEnm3KHze6aBS5hAf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAQArRcpY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqjlBzkGWTL4IPgg6GIgKDURgBAgEBAQEBAQFrKIUWAQU4UQs?= =?us-ascii?q?OCi5XBgEMCAEBiXyyI4pUAQEBAQEBAQMBAQEBAQEihk6CBYJqijkFnESSPYpUh?= =?us-ascii?q?lOLPIgPHziBBCMWCBcVhxk/iXgBAQE?= X-IronPort-AV: E=Sophos;i="5.36,170,1486425600"; d="scan'208";a="653305464" 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; 16 Mar 2017 08:02:08 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2G828Ho031600; Thu, 16 Mar 2017 08:02:08 GMT To: Kent Watsen , "netmod@ietf.org" , "sec-ads@ietf.org" References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> From: Benoit Claise Message-ID: Date: Thu, 16 Mar 2017 09:02:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170316075657.GF59114@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 08:02:13 -0000 On 3/16/2017 8:56 AM, Juergen Schoenwaelder wrote: > On Thu, Mar 16, 2017 at 08:37:39AM +0100, Benoit Claise wrote: >> Latest proposal: >> >> The YANG module defined in this document is designed to be accessed >> via network management protocols such as NETCONF [RFC6241] or >> RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport >> layer, >> and mandatory-to-implement secure transport is Secure Shell (SSH) >> [RFC6242], >> while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement >> secure >> transport is Transport Layer Security (TLS) [RFC5246]. > Picking wording from Section 12 of RFC 8040 to replace your second > sentence I get this: > > The YANG module defined in this document is designed to be > accessed via network management protocols such as NETCONF > [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the > secure transport layer, and the mandatory-to-implement secure > transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF > layer is HTTPS, and the mandatory-to-implement secure transport is > TLS [RFC5246]. > > The NETCONF access control model [RFC6536] provides the means to > restrict access for particular NETCONF or RESTCONF users to a > pre-configured subset of all available NETCONF or RESTCONF > protocol operations and content. Yes, thank you. Regards, B. > > /js > From nobody Thu Mar 16 02:54:23 2017 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 7695B12704B for ; Thu, 16 Mar 2017 02:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 7kiuEYQwfaXK for ; Thu, 16 Mar 2017 02:54:19 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D27A126D74 for ; Thu, 16 Mar 2017 02:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2193; q=dns/txt; s=iport; t=1489658058; x=1490867658; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=WFFWg8nAtsAvS0ZZIyQ3q8QZr6RSQrZh9EvKTBc/bTs=; b=OeOqJwP79LZyvAvGEB5TNxqrOKQhRyVThuZCi8GdW7+pqdzYRlOpYG9p KVy3gw783Uy3UVUBf2jjT/ertsJrOq4A4oEcDTmopEK2pqUP/ZFXy2HgV Zf4CDzmASDb0OKVPx0lEPLRjubnS+g6IrURzARXirDBtT7Jd+Mr9w0r7A k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAQAYYMpY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqYI1wc5BGH5U/gg4fC4UuSgKDVRgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBAQE2MwMLEAsYLicwBgEMBgIBAYl0CA6yQIpSAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBGAWGToIFCIJiijkFnEWSPoF7iFuGU4hLgnOIDx84gQQjFggXFUGEVx2?= =?us-ascii?q?BY0A1iUgBAQE?= X-IronPort-AV: E=Sophos;i="5.36,170,1486425600"; d="scan'208";a="651487186" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 09:54:16 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2G9sFkb028528; Thu, 16 Mar 2017 09:54:16 GMT To: "Dale R. Worley" , JOEY BOYD References: <877f3q2wje.fsf@hobgoblin.ariadne.com> Cc: netmod@ietf.org From: Robert Wilton Message-ID: Date: Thu, 16 Mar 2017 09:54:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <877f3q2wje.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 09:54:21 -0000 Hi Dale, On 15/03/2017 19:02, Dale R. Worley wrote: > JOEY BOYD writes: >> module base-module { >> prefix bmod; >> >> feature do-things; >> >> container things { >> if-feature do-things; >> ... >> } >> } >> >> module augment-module { >> prefix amod; >> >> augment "/bmod:do-things" { >> container other-things { >> } >> } >> } > First question: I'm not expert in Yang, but as far as I can figure out, > the augment statement is augmenting "container things", right? So the > augment statement should be 'augment "/bmod:things"' not 'augment > "/bmod:do-things"'. Yes, the augment should be to "things". > > But on the important question, I don't see it as at all unreasonable > that the augment needs to be qualified by the same if-feature. The > reason is that if you're reading the text of module augment-module, it's > helpful to have documented, right there, that the augmentation depends > on the presence of a particular feature in the augmented module. And > it's helpful to know that the designer did, at least for one moment, > think about the fact that the augmentation is conditional. It isn't just any if-feature on the container that is being augmented that needs to be considered. You would have to consider all if-feature statements by walking up the augmented node's ancestors to the top of the tree and combine them, or have multiple if-feature statements. Further, the 7950 YANG update rules allow for the augmented module to be revised and some of those if-feature statements to be subsequently removed. If the augmenting module had restated the if-feature conditions then this would probably leave the augmenting module unintentionally out of sync with the module that it is augmenting. In short, I think that if-feature statements work better if they act on the given node and all descendant nodes, regardless of which module those descendants are defined in. Rob > > Dale > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Thu Mar 16 03:04:28 2017 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 56CE0127097 for ; Thu, 16 Mar 2017 03:04:27 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 GvR8fSA-5gpf for ; Thu, 16 Mar 2017 03:04:25 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D463126DD9 for ; Thu, 16 Mar 2017 03:04:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D8812131E; Thu, 16 Mar 2017 11:04:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id FzphUcW7qvEY; Thu, 16 Mar 2017 11:04:20 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Mar 2017 11:04:21 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C98820033; Thu, 16 Mar 2017 11:04:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZXT7U2s8b-5L; Thu, 16 Mar 2017 11:04:20 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB15D20038; Thu, 16 Mar 2017 11:04:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 594293EDBCC4; Thu, 16 Mar 2017 11:04:24 +0100 (CET) Date: Thu, 16 Mar 2017 11:04:23 +0100 From: Juergen Schoenwaelder To: Robert Wilton Cc: netmod@ietf.org Message-ID: <20170316100421.GA59698@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , netmod@ietf.org References: <877f3q2wje.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 10:04:27 -0000 On Thu, Mar 16, 2017 at 09:54:14AM +0000, Robert Wilton wrote: > In short, I think that if-feature statements work better if they act on the > given node and all descendant nodes, regardless of which module those > descendants are defined in. I think there is something important here. The augment does not really make a difference. What seems to be the root of the issue is whether an if-feature on say a container or list applies down the hierarchy. RFC 7950 is not very specific about this. It only says: The "if-feature" statement makes its parent statement conditional. Of course, if a container or list is conditional, then everything inside will only exist if the feature is supported, so I think it is reasonable to assume that the if-feature applies down the hierarchy but this is not explicitly stated (but it seems to be the only reasonable way to implement this). Anyway, once we have clarified this, the augment behaviour falls out of this. That said, as a service to readers, it might still be useful to repeat the if-feature definition in augmenting modules but this would purely be a service to the readers, not something that is required by the language itself. /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 Thu Mar 16 03:05:08 2017 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 21BBE127337 for ; Thu, 16 Mar 2017 03:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 GTbE2L72CIxP for ; Thu, 16 Mar 2017 03:04:59 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F22A1270FC for ; Thu, 16 Mar 2017 03:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=621; q=dns/txt; s=iport; t=1489658698; x=1490868298; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=mqykfhTj/713j7Vs4ZMFks75gyzY23cToNMWvpfabKI=; b=kL6m7+2B+rrijtTJaaTUO1g9f3wAVV3fDaO8PlbEbT7eUPwNi+1neRUi hYXKRuSUD6xsbLXh1hWZSsIrPaQ49Vzp5dxcUmjfwshHtyvVdAHOu5zh7 KNY7wZz1uFXkJm58PEZjHmmV0YaIq4hW9JQYMiPsDapsZ7sLvbDtklh40 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DSAgBuYspY/xbLJq1dHAEBBAEBCgEBh?= =?us-ascii?q?FyEQYoPc6Ykgg6JcBgBAgEBAQEBAQFrHQuFPxV2AiYCXw0IAQGJfKArkAaCJop?= =?us-ascii?q?SAQEIAiaBC4VDggWKRIJfBZxFgVOQa4FjiHOGU4s+iA8fOIEEIxYIFxWHGECJf?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,170,1486425600"; d="scan'208";a="693029347" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 10:04:56 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2GA4u0o028032 for ; Thu, 16 Mar 2017 10:04:56 GMT To: "netmod@ietf.org" From: Robert Wilton Message-ID: <088dd4ae-4f0b-6b38-93ee-472666dcf66b@cisco.com> Date: Thu, 16 Mar 2017 10:04:56 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Combining if-feature statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 10:05:07 -0000 YANG nodes can have multiple if-feature statements. Its not entirely obvious to me how if-feature statements combine for a given node. I presume that a node is supported if all if-feature statements on the node are valid. Is this the correct interpretation? I.e. in the example below, "things" container is only supported if both "do-things" and "do-more-things" features are enabled. E.g. module base-module { prefix bmod; feature do-things; feature do-more-things; container things { if-feature do-things; if-feature do-more-things; ... } } Thanks, Rob From nobody Thu Mar 16 03:09:09 2017 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 20EFE127286 for ; Thu, 16 Mar 2017 03:09:07 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 P-zPTJc5UNgw for ; Thu, 16 Mar 2017 03:09:06 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9491270A7 for ; Thu, 16 Mar 2017 03:09:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5DAE878D; Thu, 16 Mar 2017 11:09:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id K0kVkkKtItnT; Thu, 16 Mar 2017 11:09:02 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Mar 2017 11:09:04 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2729620035; Thu, 16 Mar 2017 11:09:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uOMmDiGVamTs; Thu, 16 Mar 2017 11:09:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9932920033; Thu, 16 Mar 2017 11:09:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4ECCF3EDBD54; Thu, 16 Mar 2017 11:09:08 +0100 (CET) Date: Thu, 16 Mar 2017 11:09:07 +0100 From: Juergen Schoenwaelder To: Robert Wilton Cc: "netmod@ietf.org" Message-ID: <20170316100907.GB59698@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , "netmod@ietf.org" References: <088dd4ae-4f0b-6b38-93ee-472666dcf66b@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <088dd4ae-4f0b-6b38-93ee-472666dcf66b@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Combining if-feature statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 10:09:07 -0000 On Thu, Mar 16, 2017 at 10:04:56AM +0000, Robert Wilton wrote: > YANG nodes can have multiple if-feature statements. Its not entirely > obvious to me how if-feature statements combine for a given node. I presume > that a node is supported if all if-feature statements on the node are valid. > Is this the correct interpretation? yes /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 Thu Mar 16 03:09:42 2017 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 B33941270A7 for ; Thu, 16 Mar 2017 03:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 wk_iBadZfZZv for ; Thu, 16 Mar 2017 03:09:39 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 62D15127444 for ; Thu, 16 Mar 2017 03:09:31 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 2EF0C1AE0332; Thu, 16 Mar 2017 11:09:30 +0100 (CET) Date: Thu, 16 Mar 2017 11:09:35 +0100 (CET) Message-Id: <20170316.110935.1340323781914172394.mbj@tail-f.com> To: rwilton@cisco.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <088dd4ae-4f0b-6b38-93ee-472666dcf66b@cisco.com> References: <088dd4ae-4f0b-6b38-93ee-472666dcf66b@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Combining if-feature statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 10:09:41 -0000 Robert Wilton wrote: > YANG nodes can have multiple if-feature statements. Its not entirely > obvious to me how if-feature statements combine for a given node. I > presume that a node is supported if all if-feature statements on the > node are valid. Is this the correct interpretation? Yes. /martin > > I.e. in the example below, "things" container is only supported if > both "do-things" and "do-more-things" features are enabled. > > E.g. > > module base-module { > prefix bmod; > > feature do-things; > feature do-more-things; > > container things { > if-feature do-things; > if-feature do-more-things; > ... > } > } > > Thanks, > Rob > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Mar 16 04:32:52 2017 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 690791293DB for ; Thu, 16 Mar 2017 04:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK6rTeC6GZWH for ; Thu, 16 Mar 2017 04:32:49 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 13F5B1293DA for ; Thu, 16 Mar 2017 04:32:49 -0700 (PDT) Received: (qmail 23076 invoked by uid 0); 16 Mar 2017 11:32:40 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy2.mail.unifiedlayer.com with SMTP; 16 Mar 2017 11:32:40 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id wbTc1u00s2SSUrH01bTftD; Thu, 16 Mar 2017 05:27:40 -0600 X-Authority-Analysis: v=2.1 cv=R4+QR7hX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=6Iz7jQTuP9IA:10 a=j3Z76cjpAAAA:8 a=a0vFWJJCwpmC6TrbJB4A:9 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=9ZYBcOd_X9kS2t7VFny2:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=9lvXgTEMy9wRpsq6B6Vv9JsR4bBmTr4Gnotd2gVFiTs=; b=o8WLikv/CSfYVVgngs+kWoThTv yGGZJdRTxT5ADdVKSZZdzqU2sZjL+1880Xf2UcHbH/TXBbdM9HQou+ePS+nk1nhQO3rxAECOG69aA dCiznqEu/TFtzxeD54p1XMINX; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:32976 helo=[192.168.1.236]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1coTZA-0002ar-Ic; Thu, 16 Mar 2017 05:27:36 -0600 From: Lou Berger To: Juergen Schoenwaelder , Mehmet Ersue CC: "'Kent Watsen'" , Date: Thu, 16 Mar 2017 07:27:34 -0400 Message-ID: <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <20170316064419.GA59114@elstar.local> References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> User-Agent: AquaMail/1.8.1-193 (build: 100800100) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1coTZA-0002ar-Ic X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([192.168.1.236]) [100.15.85.191]:32976 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 11:32:50 -0000 Juergen, Thank you for the input. I think your point highlights how the technical contents of a document drives the intended status of a document. Lou PS as a reminder to all, intended status of documents is *not* typically included in charters and are not included in the distributed version. On March 16, 2017 2:44:53 AM Juergen Schoenwaelder wrote: > On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: > >> That said different people including Netconf WG co-chairs think the DS >> concept document is Informational in nature and should be published as an >> Informational concept to be used in and adopted for the needs in diverse >> protocol WGs. This is as I think also important to avoid an overlapping >> between NETCONF and NETMOD charters. > > The current datastore draft includes concrete YANG idenity definitions > for datastores and origins and these definitions better be standards > track. > > /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 Thu Mar 16 05:48:37 2017 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 08F2F129483; Thu, 16 Mar 2017 05:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 YsE8wGB99dYH; Thu, 16 Mar 2017 05:48:35 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0115.outbound.protection.outlook.com [104.47.34.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1EF1270A0; Thu, 16 Mar 2017 05:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ycDHNs0wWZHNhFrgSIDeCem+BZNIG+LUyYLnL3io7lg=; b=LZP6Xux/aq1JuWb209TsyqeaIwMDpwhpa2Af1SQl8D42LDhsyhYxzT32I7YgX8mlAHcBg47ev+hMOQxy7qUHd2zHwozY3CgwF7YfUCm3fNYu1oKw1kv5mz/TguULKjyR4PPBa7eg2Tp31isNLdQkPWuC343fewH7OvAyCgO8feU= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Thu, 16 Mar 2017 12:48:34 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0977.013; Thu, 16 Mar 2017 12:48:34 +0000 From: Kent Watsen To: Benoit Claise , "netmod@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [netmod] security considerations boilerplate updates to cover RESTCONF Thread-Index: AQHSnauR8sIuzui9AkeB/6DkSo5/yqGV5dqAgABeZQCAAM4UgIAAAraAgAAFZICAAAFwAIAADPwA Date: Thu, 16 Mar 2017 12:48:34 +0000 Message-ID: <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:u+rEACz/gRLF1Ert37NrnDVKh/SLnUzT5CLXN1uH0asLB/9oMHHf8hl0Fc97360XdTOySN54dYWyMjiaYj168tNTRc7KlrUD31z34gcTM0NU2ZEfEzZIj/9OzLF8cGtPOxWm5kaw1wCP+p9rFeAstAVXTpMuYy7/Bc/OGsV5iSCQKJWy9kQg2c329Sud7XPSciBvfAMwh29u6VfWvEM7Q9NC6srrQmu/JEJl2wkIr2me48anBuERWyVciA5YG+yqJugTXxA1AlyW3m9uKWTnSNkbDT0LtGe1ZSece96TXiFrnuB/vZpya43n1KbhV8dv3o+c0EydGAteLzbdBPjaGg== x-ms-office365-filtering-correlation-id: 8f0793c5-2434-427f-6eaa-08d46c6ac1f7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(20161123562025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(24454002)(377454003)(77096006)(102836003)(3846002)(54356999)(50986999)(76176999)(93886004)(6486002)(6506006)(6116002)(4001350100001)(33656002)(561944003)(229853002)(2900100001)(2950100002)(36756003)(5660300001)(189998001)(122556002)(53936002)(86362001)(15650500001)(6512007)(38730400002)(6246003)(53546007)(66066001)(2906002)(7736002)(25786008)(2501003)(305945005)(3280700002)(81166006)(8936002)(8676002)(6436002)(99286003)(83506001)(3660700001)(2201001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 16 Mar 2017 12:48:34.1773 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 12:48:37 -0000 DQpBIGNvdXBsZSBjb21tZW50czoNCg0KMSkgZHJpbGxpbmcgZG93biBvbiB0aGUgbWFuZGF0b3J5 LXRvLWltcGxlbWVudCBOQy9SQyBwcm90b2NvbHMNCiAgIGlzIHNvbWV3aGF0IG1pc3NpbmcgdGhl IHBvaW50LiAgVGhlIGltcG9ydGFudCBiaXQgaXMgdGhhdA0KICAgKmFsbCogcHJvdG9jb2xzIHRy YW5zcG9ydGluZyBZQU5HLW1vZGVsZWQgZGF0YSAqb25seSogaGF2ZQ0KICAgc2VjdXJlIHRyYW5z cG9ydCBsYXllcnMuICBNb3JlIHNwZWNpZmljYWxseSwgWUFORy1tb2RlbGVkDQogICBkYXRhIG1h eSBiZSB0cmFuc3BvcnRlZCBvdmVyIG90aGVyIHByb3RvY29scyAoZS5nLiwgY29hcCksDQogICBh bmQgYWxzbyBvbmUgb2YgdGhlIHByb3RvY29scyBoYXZlIGFuIGluc2VjdXJlIHRyYW5zcG9ydA0K ICAgcHJvdG9jb2wgKGUuZy4sIGl0IGRvZXNuJ3QgbXVjaCBoZWxwIHRvIHRhbGsgYWJvdXQgSFRU UFMNCiAgIGJlaW5nIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgaWYgUkVTVENPTkYgYWxsb3dlZCBI VFRQKS4NCg0KMikganVzdCBzdGF0aW5nIHRoYXQgdGhlcmUgYXJlIHNlY3VyZSB0cmFuc3BvcnQg bGF5ZXJzIHN0aWxsDQogICBpc27igJl0IHN1ZmZpY2llbnQsIGFzIHRoZXNlIHByb3RvY29scyBt dXN0IGFsc28gcmVxdWlyZQ0KICAgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGluIG9yZGVyIHRvIGJl IHNlY3VyZSwgYW5kIGZvciANCiAgIHN0YXRlbWVudHMgcmVnYXJkaW5nIE5BQ00gdG8gbWFrZSBz ZW5zZS4gIFRoZSB0ZXh0IEkgcG9zdGVkDQogICBiZWZvcmUgaGFkIGEgc3RhdGVtZW50IGxpa2Ug dGhpcyBpbiBpdC4gIA0KDQpJJ20gYmVnaW5uaW5nIHRvIGJlY29tZSBhIGZhbiBvZiB0aGUgaWRl YSBvZiBkZWZpbmluZyBhIGdlbmVyaWMNCiJSZXF1aXJlbWVudHMgZm9yIFByb3RvY29scyBUcmFu c3BvcnRpbmcgWUFORy1tb2RlbGVkIERhdGEiDQpkb2N1bWVudCAtIHRoYXQgd291bGQgbm90IG9u bHkgZGlzY3VzcyBzZWN1cml0eSBhc3BlY3RzLCBidXQNCmFsc28gZ2VuZXJpYyBwcm90b2NvbCBv cGVyYXRpb25zLCB0aGF0IGRvY3VtZW50cyBsaWtlIE5DLCBSQywNCkNvQVAsIGV0Yy4gY2FuIHBv aW50IHRvLi4uYW5kIGV2ZW4gWUFORyAoUkZDIDc5NTApLCByYXRoZXIgdGhhbg0KcG9pbnRpbmcg ZGlyZWN0bHkgYXQgTkVUQ09ORiBhcyBpdCBkb2VzIHRvZGF5Li4uDQoNCktlbnQgLy8gY29udHJp YnV0b3INCg0KDQpPbiAzLzE2LzIwMTcgODo1NiBBTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdy b3RlOg0KPiBPbiBUaHUsIE1hciAxNiwgMjAxNyBhdCAwODozNzozOUFNICswMTAwLCBCZW5vaXQg Q2xhaXNlIHdyb3RlOg0KPj4gTGF0ZXN0IHByb3Bvc2FsOg0KPj4NCj4+ICAgICAgVGhlIFlBTkcg bW9kdWxlIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBkZXNpZ25lZCB0byBiZSBhY2Nlc3Nl ZA0KPj4gICAgICB2aWEgbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scyBzdWNoIGFzIE5FVENP TkYgW1JGQzYyNDFdIG9yDQo+PiAgICAgIFJFU1RDT05GIFtSRkM4MDQwXS4gVGhlIGxvd2VzdCBO RVRDT05GIGxheWVyIGlzIHRoZSBzZWN1cmUgdHJhbnNwb3J0DQo+PiBsYXllciwNCj4+ICAgICAg YW5kIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgc2VjdXJlIHRyYW5zcG9ydCBpcyBTZWN1cmUgU2hl bGwgKFNTSCkNCj4+IFtSRkM2MjQyXSwNCj4+ICAgICAgd2hpbGUgdGhlIGxvd2VzdCBSRVNUQ09O RiBsYXllciBpcyBIVFRQLCBhbmQgdGhlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQNCj4+IHNlY3Vy ZQ0KPj4gICAgICB0cmFuc3BvcnQgaXMgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIFtS RkM1MjQ2XS4NCj4gUGlja2luZyB3b3JkaW5nIGZyb20gU2VjdGlvbiAxMiBvZiBSRkMgODA0MCB0 byByZXBsYWNlIHlvdXIgc2Vjb25kDQo+IHNlbnRlbmNlIEkgZ2V0IHRoaXM6DQo+DQo+ICAgICAg VGhlIFlBTkcgbW9kdWxlIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBkZXNpZ25lZCB0byBi ZQ0KPiAgICAgIGFjY2Vzc2VkIHZpYSBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2xzIHN1Y2gg YXMgTkVUQ09ORg0KPiAgICAgIFtSRkM2MjQxXSBvciBSRVNUQ09ORiBbUkZDODA0MF0uIFRoZSBs b3dlc3QgTkVUQ09ORiBsYXllciBpcyB0aGUNCj4gICAgICBzZWN1cmUgdHJhbnNwb3J0IGxheWVy LCBhbmQgdGhlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgc2VjdXJlDQo+ICAgICAgdHJhbnNwb3J0 IGlzIFNlY3VyZSBTaGVsbCAoU1NIKSBbUkZDNjI0Ml0uIFRoZSBsb3dlc3QgUkVTVENPTkYNCj4g ICAgICBsYXllciBpcyBIVFRQUywgYW5kIHRoZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IHNlY3Vy ZSB0cmFuc3BvcnQgaXMNCj4gICAgICBUTFMgW1JGQzUyNDZdLg0KPg0KPiAgICAgIFRoZSBORVRD T05GIGFjY2VzcyBjb250cm9sIG1vZGVsIFtSRkM2NTM2XSBwcm92aWRlcyB0aGUgbWVhbnMgdG8N Cj4gICAgICByZXN0cmljdCBhY2Nlc3MgZm9yIHBhcnRpY3VsYXIgTkVUQ09ORiBvciBSRVNUQ09O RiB1c2VycyB0byBhDQo+ICAgICAgcHJlLWNvbmZpZ3VyZWQgc3Vic2V0IG9mIGFsbCBhdmFpbGFi bGUgTkVUQ09ORiBvciBSRVNUQ09ORg0KPiAgICAgIHByb3RvY29sIG9wZXJhdGlvbnMgYW5kIGNv bnRlbnQuDQpZZXMsIHRoYW5rIHlvdS4NCg0KUmVnYXJkcywgQi4NCj4NCj4gL2pzDQo+DQoNCg0K DQo= From nobody Thu Mar 16 06:22:18 2017 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 48C431294D1; Thu, 16 Mar 2017 06:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 XIE0DRCzPyZd; Thu, 16 Mar 2017 06:22:15 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0096.outbound.protection.outlook.com [104.47.42.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640651294C7; Thu, 16 Mar 2017 06:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6Wh20PJvSRDxPfkCw2Kd2SNn8rYJ+mWonR370W9b5nQ=; b=DcIVaW+nd4yy0tH2F0R2INJA+rldhBYNKP1u+vaYhH6hSAp+L1d9DhZwN01DRRxlEzSh5D8eXB1+zJss2crSIEkfaw8wYAyoKbpHc14R/QA/tUVFC8ujAj/IXwufzfW49JP6gAx3CUBJMK4I9hW/GIR51GqcBawL504u8CaKTkA= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Thu, 16 Mar 2017 13:22:14 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0977.013; Thu, 16 Mar 2017 13:22:14 +0000 From: Kent Watsen To: Benoit Claise , "netmod@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [netmod] security considerations boilerplate updates to cover RESTCONF Thread-Index: AQHSnauR8sIuzui9AkeB/6DkSo5/yqGV5dqAgABeZQCAAM4UgIAAAraAgAAFZICAAAFwAIAADPwAgAAJZ4A= Date: Thu, 16 Mar 2017 13:22:14 +0000 Message-ID: <63F8E8D6-2F84-4AD0-866C-61FCB76A1AB0@juniper.net> References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> In-Reply-To: <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:f8rFtxQddw5mXocddp4LHVE0pgpM6e5mL1/e3huqxXSLXtNL7mNV3gBVBO0gvJy+38t9Y0LHr9c2X0UjdGZ3D2T5lTDJYi+HGpPDJwN5/rz9Ra6SrH9g1E9oGK7CVi8LaB3kfqS7JKBPbnuZiSg+rk4JgKLpGfYgcmUV52oEhqIJXvxjPDDBR2aD8LeGv7vVl9vm14Isc48PHa+0Kvgdov5lxe8UwWsu3C7us2AM26vRDPKc7rkNsDhfA647Oy9S+WfbvlJczO6camwzAIs9HPapiRwB3M4YI7jwGnHbkrPTgsQbNdNSUJkR+qL09W7yocqZZ6+9fP+vH/96zEUH8g== x-ms-office365-filtering-correlation-id: 8ed38a21-2f46-440b-79d7-08d46c6f7626 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39840400002)(39850400002)(39860400002)(377454003)(24454002)(2900100001)(6306002)(25786008)(3280700002)(3660700001)(38730400002)(2501003)(3846002)(53936002)(6246003)(99286003)(76176999)(2950100002)(7736002)(6116002)(102836003)(54356999)(50986999)(66066001)(53546007)(36756003)(5660300001)(305945005)(561944003)(15650500001)(33656002)(6512007)(8676002)(8936002)(81166006)(93886004)(229853002)(86362001)(2201001)(2906002)(122556002)(83506001)(6506006)(6486002)(189998001)(6436002)(4001350100001)(77096006)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8D59197EDE581447982B2C1C612D8DED@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 13:22:14.4814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 13:22:17 -0000 dHlwbzoNCg0KIG5ldzogb25lIG9mIHRoZSBwcm90b2NvbHMgKm1heSogaGF2ZSBhbiBpbnNlY3Vy ZSBwcm90b2NvbA0KDQpLLg0KDQotLS0tLU9SSUdJTkFMIE1FU1NBR0UtLS0tLQ0KDQpBIGNvdXBs ZSBjb21tZW50czoNCg0KMSkgZHJpbGxpbmcgZG93biBvbiB0aGUgbWFuZGF0b3J5LXRvLWltcGxl bWVudCBOQy9SQyBwcm90b2NvbHMNCiAgIGlzIHNvbWV3aGF0IG1pc3NpbmcgdGhlIHBvaW50LiAg VGhlIGltcG9ydGFudCBiaXQgaXMgdGhhdA0KICAgKmFsbCogcHJvdG9jb2xzIHRyYW5zcG9ydGlu ZyBZQU5HLW1vZGVsZWQgZGF0YSAqb25seSogaGF2ZQ0KICAgc2VjdXJlIHRyYW5zcG9ydCBsYXll cnMuICBNb3JlIHNwZWNpZmljYWxseSwgWUFORy1tb2RlbGVkDQogICBkYXRhIG1heSBiZSB0cmFu c3BvcnRlZCBvdmVyIG90aGVyIHByb3RvY29scyAoZS5nLiwgY29hcCksDQogICBhbmQgYWxzbyBv bmUgb2YgdGhlIHByb3RvY29scyBoYXZlIGFuIGluc2VjdXJlIHRyYW5zcG9ydA0KICAgcHJvdG9j b2wgKGUuZy4sIGl0IGRvZXNuJ3QgbXVjaCBoZWxwIHRvIHRhbGsgYWJvdXQgSFRUUFMNCiAgIGJl aW5nIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgaWYgUkVTVENPTkYgYWxsb3dlZCBIVFRQKS4NCg0K MikganVzdCBzdGF0aW5nIHRoYXQgdGhlcmUgYXJlIHNlY3VyZSB0cmFuc3BvcnQgbGF5ZXJzIHN0 aWxsDQogICBpc27igJl0IHN1ZmZpY2llbnQsIGFzIHRoZXNlIHByb3RvY29scyBtdXN0IGFsc28g cmVxdWlyZQ0KICAgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGluIG9yZGVyIHRvIGJlIHNlY3VyZSwg YW5kIGZvciANCiAgIHN0YXRlbWVudHMgcmVnYXJkaW5nIE5BQ00gdG8gbWFrZSBzZW5zZS4gIFRo ZSB0ZXh0IEkgcG9zdGVkDQogICBiZWZvcmUgaGFkIGEgc3RhdGVtZW50IGxpa2UgdGhpcyBpbiBp dC4gIA0KDQpJJ20gYmVnaW5uaW5nIHRvIGJlY29tZSBhIGZhbiBvZiB0aGUgaWRlYSBvZiBkZWZp bmluZyBhIGdlbmVyaWMNCiJSZXF1aXJlbWVudHMgZm9yIFByb3RvY29scyBUcmFuc3BvcnRpbmcg WUFORy1tb2RlbGVkIERhdGEiDQpkb2N1bWVudCAtIHRoYXQgd291bGQgbm90IG9ubHkgZGlzY3Vz cyBzZWN1cml0eSBhc3BlY3RzLCBidXQNCmFsc28gZ2VuZXJpYyBwcm90b2NvbCBvcGVyYXRpb25z LCB0aGF0IGRvY3VtZW50cyBsaWtlIE5DLCBSQywNCkNvQVAsIGV0Yy4gY2FuIHBvaW50IHRvLi4u YW5kIGV2ZW4gWUFORyAoUkZDIDc5NTApLCByYXRoZXIgdGhhbg0KcG9pbnRpbmcgZGlyZWN0bHkg YXQgTkVUQ09ORiBhcyBpdCBkb2VzIHRvZGF5Li4uDQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0K DQpPbiAzLzE2LzIwMTcgODo1NiBBTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdyb3RlOg0KPiBP biBUaHUsIE1hciAxNiwgMjAxNyBhdCAwODozNzozOUFNICswMTAwLCBCZW5vaXQgQ2xhaXNlIHdy b3RlOg0KPj4gTGF0ZXN0IHByb3Bvc2FsOg0KPj4NCj4+ICAgICAgVGhlIFlBTkcgbW9kdWxlIGRl ZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBkZXNpZ25lZCB0byBiZSBhY2Nlc3NlZA0KPj4gICAg ICB2aWEgbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scyBzdWNoIGFzIE5FVENPTkYgW1JGQzYy NDFdIG9yDQo+PiAgICAgIFJFU1RDT05GIFtSRkM4MDQwXS4gVGhlIGxvd2VzdCBORVRDT05GIGxh eWVyIGlzIHRoZSBzZWN1cmUgdHJhbnNwb3J0DQo+PiBsYXllciwNCj4+ICAgICAgYW5kIG1hbmRh dG9yeS10by1pbXBsZW1lbnQgc2VjdXJlIHRyYW5zcG9ydCBpcyBTZWN1cmUgU2hlbGwgKFNTSCkN Cj4+IFtSRkM2MjQyXSwNCj4+ICAgICAgd2hpbGUgdGhlIGxvd2VzdCBSRVNUQ09ORiBsYXllciBp cyBIVFRQLCBhbmQgdGhlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQNCj4+IHNlY3VyZQ0KPj4gICAg ICB0cmFuc3BvcnQgaXMgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIFtSRkM1MjQ2XS4N Cj4gUGlja2luZyB3b3JkaW5nIGZyb20gU2VjdGlvbiAxMiBvZiBSRkMgODA0MCB0byByZXBsYWNl IHlvdXIgc2Vjb25kDQo+IHNlbnRlbmNlIEkgZ2V0IHRoaXM6DQo+DQo+ICAgICAgVGhlIFlBTkcg bW9kdWxlIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBkZXNpZ25lZCB0byBiZQ0KPiAgICAg IGFjY2Vzc2VkIHZpYSBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2xzIHN1Y2ggYXMgTkVUQ09O Rg0KPiAgICAgIFtSRkM2MjQxXSBvciBSRVNUQ09ORiBbUkZDODA0MF0uIFRoZSBsb3dlc3QgTkVU Q09ORiBsYXllciBpcyB0aGUNCj4gICAgICBzZWN1cmUgdHJhbnNwb3J0IGxheWVyLCBhbmQgdGhl IG1hbmRhdG9yeS10by1pbXBsZW1lbnQgc2VjdXJlDQo+ICAgICAgdHJhbnNwb3J0IGlzIFNlY3Vy ZSBTaGVsbCAoU1NIKSBbUkZDNjI0Ml0uIFRoZSBsb3dlc3QgUkVTVENPTkYNCj4gICAgICBsYXll ciBpcyBIVFRQUywgYW5kIHRoZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IHNlY3VyZSB0cmFuc3Bv cnQgaXMNCj4gICAgICBUTFMgW1JGQzUyNDZdLg0KPg0KPiAgICAgIFRoZSBORVRDT05GIGFjY2Vz cyBjb250cm9sIG1vZGVsIFtSRkM2NTM2XSBwcm92aWRlcyB0aGUgbWVhbnMgdG8NCj4gICAgICBy ZXN0cmljdCBhY2Nlc3MgZm9yIHBhcnRpY3VsYXIgTkVUQ09ORiBvciBSRVNUQ09ORiB1c2VycyB0 byBhDQo+ICAgICAgcHJlLWNvbmZpZ3VyZWQgc3Vic2V0IG9mIGFsbCBhdmFpbGFibGUgTkVUQ09O RiBvciBSRVNUQ09ORg0KPiAgICAgIHByb3RvY29sIG9wZXJhdGlvbnMgYW5kIGNvbnRlbnQuDQpZ ZXMsIHRoYW5rIHlvdS4NCg0KUmVnYXJkcywgQi4NCj4NCj4gL2pzDQo+DQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcg bGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZA0KDQoNCg== From nobody Thu Mar 16 06:40:01 2017 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 84FFB1294E4; Thu, 16 Mar 2017 06:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uB_Ww_kL_EB8; Thu, 16 Mar 2017 06:39:57 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964121294AB; Thu, 16 Mar 2017 06:39:57 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id w189so24600768pfb.0; Thu, 16 Mar 2017 06:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5J2RE6LG+Ebr0mqeQ4BR0uca9VbdT3Uf9i+3J37Kug4=; b=UMgooAuqNh5WJxKqu/H1UPd2ImYgWtZdGoudBFtinxRvkUwAfjOuuVQc9EDQ52LYpB 43miTumXG0KdNAxYrnen/V+RoNX6o4LVLRGPHLXYTWMI7HK8r4ZOuzFMfQFi2mXrQW4H bpsQK6bL0g0HdLNckW8RjQx9t6/xsue8Gk69JwsyKpBL0CyF3oEp7ncLedZvjVBtyBqB DxmHtjV/F04StTSV4aarby/q8jrIswngmbvLyPDAgm8ATMiBR1bVDNGTIS5Wyu6727NE J5hJrKVuANPbqAVhb//AU+P8ouG6XkXsm/pT+YqGyGivM+UQ1OKSJNmOwuIIX2bbbF9i 8xpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5J2RE6LG+Ebr0mqeQ4BR0uca9VbdT3Uf9i+3J37Kug4=; b=rbKbA+kQn66+MsvAIo9SPZEvW6GHz2V2JVNkibT+XQtQBD9QmegN05++G3myYgz7QP 8yK5+zb9VjvXj8VX/jpwZJ8gioKzjSPWv6k4bl4zzOiXmzanEC7TiDdfDbLpUEnL8MtC 5pQd2sg+jh33dG6ManpH1C7CEzvPXHGiB7GVajP8RsEcxrevjSNhRLzGgSqhJaNqwKrU ADaKToqidXNJFwpe5VCbBT6oih9vgILlBPT2zlV4lNlGGxt99d6XiuiBrZAz3hIpCJ6v enMWQxbF88UmO0DmbtzcOPvG9iwnguUICLwBSD6/l00M9V4S5kNVPQPmcGb/oMkvDsgU U5fg== X-Gm-Message-State: AFeK/H3nOr9X7d+D95aLV6O5t1DF7L8rt+a/E6TpLoTQz6vOcHYwLuv6X4aJEV0mjMvg/Ml0rvjfkPiX1FYceg== X-Received: by 10.84.202.12 with SMTP id w12mr12477707pld.55.1489671597163; Thu, 16 Mar 2017 06:39:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.177.199 with HTTP; Thu, 16 Mar 2017 06:39:56 -0700 (PDT) In-Reply-To: <63F8E8D6-2F84-4AD0-866C-61FCB76A1AB0@juniper.net> References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> <63F8E8D6-2F84-4AD0-866C-61FCB76A1AB0@juniper.net> From: Kathleen Moriarty Date: Thu, 16 Mar 2017 09:39:56 -0400 Message-ID: To: Kent Watsen Cc: Benoit Claise , "netmod@ietf.org" , "sec-ads@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 13:39:59 -0000 I just have a general comment, I'm happy with the direction and objective of the new text. It looks like you are down to editorial nits and I'll stay out of that now that secure transport for RESTCONF is covered in the considerations. Thank you for the updated boilerplate! Kathleen On Thu, Mar 16, 2017 at 9:22 AM, Kent Watsen wrote: > typo: > > new: one of the protocols *may* have an insecure protocol > > K. > > -----ORIGINAL MESSAGE----- > > A couple comments: > > 1) drilling down on the mandatory-to-implement NC/RC protocols > is somewhat missing the point. The important bit is that > *all* protocols transporting YANG-modeled data *only* have > secure transport layers. More specifically, YANG-modeled > data may be transported over other protocols (e.g., coap), > and also one of the protocols have an insecure transport > protocol (e.g., it doesn't much help to talk about HTTPS > being mandatory-to-implement if RESTCONF allowed HTTP). > > 2) just stating that there are secure transport layers still > isn=E2=80=99t sufficient, as these protocols must also require > mutual authentication in order to be secure, and for > statements regarding NACM to make sense. The text I posted > before had a statement like this in it. > > I'm beginning to become a fan of the idea of defining a generic > "Requirements for Protocols Transporting YANG-modeled Data" > document - that would not only discuss security aspects, but > also generic protocol operations, that documents like NC, RC, > CoAP, etc. can point to...and even YANG (RFC 7950), rather than > pointing directly at NETCONF as it does today... > > Kent // contributor > > > On 3/16/2017 8:56 AM, Juergen Schoenwaelder wrote: >> On Thu, Mar 16, 2017 at 08:37:39AM +0100, Benoit Claise wrote: >>> Latest proposal: >>> >>> The YANG module defined in this document is designed to be accesse= d >>> via network management protocols such as NETCONF [RFC6241] or >>> RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transpo= rt >>> layer, >>> and mandatory-to-implement secure transport is Secure Shell (SSH) >>> [RFC6242], >>> while the lowest RESTCONF layer is HTTP, and the mandatory-to-impl= ement >>> secure >>> transport is Transport Layer Security (TLS) [RFC5246]. >> Picking wording from Section 12 of RFC 8040 to replace your second >> sentence I get this: >> >> The YANG module defined in this document is designed to be >> accessed via network management protocols such as NETCONF >> [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the >> secure transport layer, and the mandatory-to-implement secure >> transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF >> layer is HTTPS, and the mandatory-to-implement secure transport is >> TLS [RFC5246]. >> >> The NETCONF access control model [RFC6536] provides the means to >> restrict access for particular NETCONF or RESTCONF users to a >> pre-configured subset of all available NETCONF or RESTCONF >> protocol operations and content. > Yes, thank you. > > Regards, B. >> >> /js >> > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --=20 Best regards, Kathleen From nobody Thu Mar 16 06:51:50 2017 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 323821294FF; Thu, 16 Mar 2017 06:51:45 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 8T9-_wcwZMUZ; Thu, 16 Mar 2017 06:51:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644341294FE; Thu, 16 Mar 2017 06:51:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3C605745; Thu, 16 Mar 2017 14:51:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tGt1QgqiOYQB; Thu, 16 Mar 2017 14:51:39 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Mar 2017 14:51:40 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF4902003A; Thu, 16 Mar 2017 14:51:40 +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 RZ_W1wFZW0P5; Thu, 16 Mar 2017 14:51:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6FC1F20033; Thu, 16 Mar 2017 14:51:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 983213EE8514; Thu, 16 Mar 2017 14:51:45 +0100 (CET) Date: Thu, 16 Mar 2017 14:51:45 +0100 From: Juergen Schoenwaelder To: Kent Watsen Cc: Benoit Claise , "netmod@ietf.org" , "sec-ads@ietf.org" Message-ID: <20170316135145.GB23450@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Benoit Claise , "netmod@ietf.org" , "sec-ads@ietf.org" References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 13:51:45 -0000 On Thu, Mar 16, 2017 at 12:48:34PM +0000, Kent Watsen wrote: > > A couple comments: > > 1) drilling down on the mandatory-to-implement NC/RC protocols > is somewhat missing the point. The important bit is that > *all* protocols transporting YANG-modeled data *only* have > secure transport layers. More specifically, YANG-modeled > data may be transported over other protocols (e.g., coap), > and also one of the protocols have an insecure transport > protocol (e.g., it doesn't much help to talk about HTTPS > being mandatory-to-implement if RESTCONF allowed HTTP). RESTCONF says MUST use TLS. Making an open ended statement about security properties of unknown protocols sounds risky. > 2) just stating that there are secure transport layers still > isn’t sufficient, as these protocols must also require > mutual authentication in order to be secure, and for > statements regarding NACM to make sense. The text I posted > before had a statement like this in it. > > I'm beginning to become a fan of the idea of defining a generic > "Requirements for Protocols Transporting YANG-modeled Data" > document - that would not only discuss security aspects, but > also generic protocol operations, that documents like NC, RC, > CoAP, etc. can point to...and even YANG (RFC 7950), rather than > pointing directly at NETCONF as it does today... Keep in mind that I2RS believes in a requirement for cleartext transport protocols. Perhaps this never makes it through the IESG but so far it was not possible to stop this... /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 Thu Mar 16 07:13:25 2017 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 ED876129534; Thu, 16 Mar 2017 07:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOj2TXZL9E4o; Thu, 16 Mar 2017 07:13:21 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 A478C129533; Thu, 16 Mar 2017 07:13:20 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id l37so33020484wrc.1; Thu, 16 Mar 2017 07:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=CvM//3/tRWXu1UDDNFuogwbLtgpDsX6EenpBYtIkea8=; b=e2Z5g953JVrZrkk9EKTq3ha2tEaUNv0Ki2B8dDifrbPDM/9USTbJmU4BsRZnQ338Be QAe1P1gLC3Dh8kCQUE5syeAwLWb465qgYt3O6sAQW/i8jGqqjrLYSiGiHWSduh5BS+mu zUUOpU2uRB/Zk44RNQmyLmZGOQyRTWNu3P/dtQQ+9Ab/ifd/3YIiTh/Bq3Wx4X0tqWAK cGugcn4Vo3JZQ59EJR9CHdgkEvpfmLJCmMGsHRxMqxA3TJNfC5/CA24rkspD9XNFko3e sos8sNnNmQMLdWwYRwCe+/LLSHOlkMdm8q72oi+NH7Kr7qr7kqzKWrgrgG1FrkBypi4f spZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=CvM//3/tRWXu1UDDNFuogwbLtgpDsX6EenpBYtIkea8=; b=pm/Xll8f/2L/18WRBRVEYOBdjheUEo17gEYkTsyJ6Ic2gLaKQqHXCN1kSSHflHaATT giGjwf4U0pkf2qlXIp8WE4szOTXde2bxL75BUQ/r04mngKpGk8I355LrhG5ZqOEmU3cd 2fEi/Lyrnzu9UjnRWpqGh0rRLRVdwJ6a303m3Lw4WFUjQpCH9Gu6xy0+p2vHNbyzyQvF Ubomp4P6RWWlTdcEUhLLQrSp6rNHCiY6LlcBAin6QOXyZw2HrWOkvPsys9OW7sgvKvQz LM4wxjVdVDVfcLpgLNF7lRYUWKXHpweFyGj4DRkLS1oewhLu4M/U157Tr4Vu2bKPlxW2 hvSw== X-Gm-Message-State: AFeK/H0qDWE1Yruk4E4/Nw4XACCXKv4VzAxeuCULJXh1esJOGaZj9tC0DPB60E4G4nDUT+qj5sEu6DP6eBFsqw== X-Received: by 10.223.155.193 with SMTP id e1mr8574650wrc.86.1489673598852; Thu, 16 Mar 2017 07:13:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.145.69 with HTTP; Thu, 16 Mar 2017 07:13:18 -0700 (PDT) In-Reply-To: <20170316135145.GB23450@elstar.local> References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> <20170316135145.GB23450@elstar.local> From: Alia Atlas Date: Thu, 16 Mar 2017 10:13:18 -0400 Message-ID: To: Juergen Schoenwaelder , Kent Watsen , Benoit Claise , "netmod@ietf.org" , "sec-ads@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1b31f2b0e8f0054ad9a91b Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 14:13:23 -0000 --94eb2c1b31f2b0e8f0054ad9a91b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Juergen, On Thu, Mar 16, 2017 at 9:51 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Mar 16, 2017 at 12:48:34PM +0000, Kent Watsen wrote: > > > > A couple comments: > > > > 1) drilling down on the mandatory-to-implement NC/RC protocols > > is somewhat missing the point. The important bit is that > > *all* protocols transporting YANG-modeled data *only* have > > secure transport layers. More specifically, YANG-modeled > > data may be transported over other protocols (e.g., coap), > > and also one of the protocols have an insecure transport > > protocol (e.g., it doesn't much help to talk about HTTPS > > being mandatory-to-implement if RESTCONF allowed HTTP). > > RESTCONF says MUST use TLS. Making an open ended statement about > security properties of unknown protocols sounds risky. > > > 2) just stating that there are secure transport layers still > > isn=E2=80=99t sufficient, as these protocols must also require > > mutual authentication in order to be secure, and for > > statements regarding NACM to make sense. The text I posted > > before had a statement like this in it. > > > > I'm beginning to become a fan of the idea of defining a generic > > "Requirements for Protocols Transporting YANG-modeled Data" > > document - that would not only discuss security aspects, but > > also generic protocol operations, that documents like NC, RC, > > CoAP, etc. can point to...and even YANG (RFC 7950), rather than > > pointing directly at NETCONF as it does today... > > Keep in mind that I2RS believes in a requirement for cleartext > transport protocols. Perhaps this never makes it through the IESG but > so far it was not possible to stop this... > This is solely for notifications that can be sent, just as IPFIX information may be sent unencrypted. Those requirements are in draft-ietf-i2rs-protocol-security-requirements-17 , which is in the RFC Editor queue. Regards, Alia > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --94eb2c1b31f2b0e8f0054ad9a91b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen,

On Thu, Mar 16, 2017 at 9:51 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
=
On= Thu, Mar 16, 2017 at 12:48:34PM +0000, Kent Watsen wrote:
>
> A couple comments:
>
> 1) drilling down on the mandatory-to-implement NC/RC protocols
>=C2=A0 =C2=A0 is somewhat missing the point.=C2=A0 The important bit is= that
>=C2=A0 =C2=A0 *all* protocols transporting YANG-modeled data *only* hav= e
>=C2=A0 =C2=A0 secure transport layers.=C2=A0 More specifically, YANG-mo= deled
>=C2=A0 =C2=A0 data may be transported over other protocols (e.g., coap)= ,
>=C2=A0 =C2=A0 and also one of the protocols have an insecure transport<= br> >=C2=A0 =C2=A0 protocol (e.g., it doesn't much help to talk about HT= TPS
>=C2=A0 =C2=A0 being mandatory-to-implement if RESTCONF allowed HTTP).
RESTCONF says MUST use TLS. Making an open ended statement about
security properties of unknown protocols sounds risky.

> 2) just stating that there are secure transport layers still
>=C2=A0 =C2=A0 isn=E2=80=99t sufficient, as these protocols must also re= quire
>=C2=A0 =C2=A0 mutual authentication in order to be secure, and for
>=C2=A0 =C2=A0 statements regarding NACM to make sense.=C2=A0 The text I= posted
>=C2=A0 =C2=A0 before had a statement like this in it.
>
> I'm beginning to become a fan of the idea of defining a generic > "Requirements for Protocols Transporting YANG-modeled Data"<= br> > document - that would not only discuss security aspects, but
> also generic protocol operations, that documents like NC, RC,
> CoAP, etc. can point to...and even YANG (RFC 7950), rather than
> pointing directly at NETCONF as it does today...

Keep in mind that I2RS believes in a requirement for cleartext
transport protocols. Perhaps this never makes it through the IESG but
so far it was not possible to stop this...

<= div>This is solely for notifications that can be sent, just as IPFIX inform= ation may
be sent unencrypted.=C2=A0 Those requirements are in=C2= =A0draft-ietf-i2rs-protocol-security-requiremen= ts-17, which is in the RFC Editor queue.

Regar= ds,
Alia=C2=A0
=C2=A0
/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>

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

--94eb2c1b31f2b0e8f0054ad9a91b-- From nobody Thu Mar 16 07:25:59 2017 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 628E7129527 for ; Thu, 16 Mar 2017 07:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtuZrluz6N7c for ; Thu, 16 Mar 2017 07:25:55 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 0A154129492 for ; Thu, 16 Mar 2017 07:25:55 -0700 (PDT) Received: (qmail 27044 invoked by uid 0); 16 Mar 2017 14:25:54 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy3.mail.unifiedlayer.com with SMTP; 16 Mar 2017 14:25:54 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id weRq1u01Q2SSUrH01eRt5q; Thu, 16 Mar 2017 08:25:54 -0600 X-Authority-Analysis: v=2.1 cv=R4+QR7hX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=48vgC7mUAAAA:8 a=yPQ-J4uHeFpsOXhMlh0A:9 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=yvQ+9nTqDI7Ea8UAwCosxMXwtRL1G6NHAkpe4A5w3NU=; b=zaRud6S7ARuEKiz0c8HiRe/9Rc wp92+6WtqoVVylWcAr6GPq0ldNsyjjjlSPohIUQ7tvBcnGZcYh3G8hvMjlrPVe35hqwCkOV1qs1Cg zoqQ4c0aw6Kjw5kLm7XSU1mP5; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:47822 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1coWLe-00061T-PO; Thu, 16 Mar 2017 08:25:50 -0600 To: NetMod WG References: <8c395501-8b28-9a08-1be7-1ec89bd2e0cc@labn.net> Cc: NetMod WG Chairs From: Lou Berger Message-ID: <8e956446-22b1-4c82-f3fa-342b86341d7d@labn.net> Date: Thu, 16 Mar 2017 10:25:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8c395501-8b28-9a08-1be7-1ec89bd2e0cc@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1coWLe-00061T-PO X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:47822 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] Draft Chicago Agenda Posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 14:25:57 -0000 All, An updated agenda has been uploaded. We now have full agendas for both sessions. Please send edits per Michael's mail. Lou (Kent, and Michael) On 3/14/2017 5:14 PM, Lou Berger wrote: > All, > > Thanks to our WG Secretary we have a draft agenda for Chicago posted at: > https://datatracker.ietf.org/meeting/98/agenda/netmod/ > > Please let us know if anything is missing. > > The draft has us meeting for 2.5 hours in a single session. Our > original intent was to meet for 3 hours over two sessions, but we see a > couple of advantages of fitting into just one 2.5 hour session - iff > this doesn't limit WG progress. As the current agenda is full, we will > move back to 2 sessions if any additional agenda requests need to be > satisfied. > > Thanks > > Lou (Kent, and Michael) > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Mar 16 07:38:08 2017 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 9FA03129519; Thu, 16 Mar 2017 07:38:06 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 GBmRej1Tnn3N; Thu, 16 Mar 2017 07:38:04 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920BE1294E7; Thu, 16 Mar 2017 07:38:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6707A699; Thu, 16 Mar 2017 15:38:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2Tadrpc5TtXY; Thu, 16 Mar 2017 15:38:01 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Mar 2017 15:38:02 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAF1E20033; Thu, 16 Mar 2017 15:38:02 +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 DcuUwgHYZoOU; Thu, 16 Mar 2017 15:38:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 600E320035; Thu, 16 Mar 2017 15:38:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C831D3EE87E7; Thu, 16 Mar 2017 15:38:05 +0100 (CET) Date: Thu, 16 Mar 2017 15:38:05 +0100 From: Juergen Schoenwaelder To: Alia Atlas Cc: Kent Watsen , Benoit Claise , "netmod@ietf.org" , "sec-ads@ietf.org" Message-ID: <20170316143803.GB23686@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Alia Atlas , Kent Watsen , Benoit Claise , "netmod@ietf.org" , "sec-ads@ietf.org" References: <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> <20170316135145.GB23450@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 14:38:07 -0000 On Thu, Mar 16, 2017 at 10:13:18AM -0400, Alia Atlas wrote: > > > > Keep in mind that I2RS believes in a requirement for cleartext > > transport protocols. Perhaps this never makes it through the IESG but > > so far it was not possible to stop this... > > > > This is solely for notifications that can be sent, just as IPFIX > information may > be sent unencrypted. Those requirements are in > draft-ietf-i2rs-protocol-security-requirements-17 > , > which is in the RFC Editor queue. > The new features are priority, an opaque secondary identifier, and an insecure protocol for read-only data constrained to specific standard usages. The optional insecure transport can only be used restricted set of publically data available (events or information) or a select set of legacy data. Data passed over the insecure transport channel MUST NOT contain any data which identifies a person. I think your statement that it is only for notifications is wrong. The fact that some data ships in a notification does not mean the data is not sensitive. Furthermore, I think we all meanwhile know that IPFIX data is highly sensitive if you have the right context information (so the analogy is flawed). And what the heck is a 'select set of legacy data'? SEC-REQ-06: An I2RS agent receiving an I2RS message over an insecure transport MUST confirm that the content is suitable for transfer over such a transport. An agent can't decide this. It is the context information that often decides whether a piece of information is sensitive or not. So the only decision an agent can do is to only allow messages with empty content over an insecure transport. The I2RS architecture defines three scopes: read, write, and notification scope. Insecure data can only be used for read scope and notification scope of "non-confidential data". I understand that the IESG approved the security requirements. I do not know why the security ADs did let this pass - perhaps since the document is just about requirements and they will look closer at a solution and then ask questions what 'non-confidentail' data' is, what a 'select set of legacy data' is, or how an agent confirms that the content of messages is suitable for an insecure transport. Anyway, this does not belong here, the point I wanted to make is simply that Kent's assumption that a protocol transporting YANG defined data is always protecting the data is not true from the viewpoint of the I2RS proponents. Thanks for confirming this. /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 Thu Mar 16 08:06:27 2017 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 2613212957A for ; Thu, 16 Mar 2017 08:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 VqVnE8ZQX9W5 for ; Thu, 16 Mar 2017 08:06:23 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 846621294E7 for ; Thu, 16 Mar 2017 08:05:51 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-12v.sys.comcast.net with SMTP id oWvqcb7YBUZfBoWyMcP2Si; Thu, 16 Mar 2017 15:05:50 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-07v.sys.comcast.net with SMTP id oWyJc7hV9IDwKoWyLcy3aw; Thu, 16 Mar 2017 15:05:50 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2GF5k3M007603; Thu, 16 Mar 2017 11:05:46 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2GF5jFJ007577; Thu, 16 Mar 2017 11:05:45 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Robert Wilton Cc: joey.boyd@adtran.com, netmod@ietf.org In-Reply-To: (rwilton@cisco.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 16 Mar 2017 11:05:45 -0400 Message-ID: <87efxx1cty.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfEEfkxaUvIYLSLPSrNwwnb00bTERZ9MSA9bZr9UqVHKoGt0jz6sTqfMb3F+h4dE3GaY4usOFgvarHmRC4TJ1zh2v2v7yex/yEcPcp95gnGUBTuDiQ1Tc Bf215kUskBjQ64TkNhR1rS1PXmIJpxiVhNv14AhPCB5oYGZiJheLNEvyJqYL1g+boNhGMSEbGpGmifNfPOMVXicBveFlIOtvS7Ltnc834EkNmxT/kVbKYG3J Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 15:06:24 -0000 Robert Wilton writes: > It isn't just any if-feature on the container that is being augmented > that needs to be considered. You would have to consider all if-feature > statements by walking up the augmented node's ancestors to the top of > the tree and combine them, or have multiple if-feature statements. Yes, I would expect that. > Further, the 7950 YANG update rules allow for the augmented module to be > revised and some of those if-feature statements to be subsequently > removed. If the augmenting module had restated the if-feature > conditions then this would probably leave the augmenting module > unintentionally out of sync with the module that it is augmenting. It's an interesting sort of out-of-sync, though, as nothing would be *incorrect*. With some combinations of features, the augmented node would have the agumentation and with some, it would not. But it seems to me that is quite OK, since whatever depends on the presence of the augmentation (e.g., client logic or XPath expressions in the augmentation) only expects the augmentation to be there if the additional feature is present. Dale From nobody Thu Mar 16 09:17:39 2017 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 A5F93129663 for ; Thu, 16 Mar 2017 09:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQDhjahDFDll for ; Thu, 16 Mar 2017 09:17:36 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 B83561296A0 for ; Thu, 16 Mar 2017 09:17:35 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id n11so116236831wma.1 for ; Thu, 16 Mar 2017 09:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jJxiZNnfWNQr7whqD8ysMCpFCC99/4raCmFFFSVjNX0=; b=XkntpegqQH/pAjKXe/Bq2gbr9pAMhTTFvvCV1PaBqE6EfY4VivUfvkQIxUoIXeELz6 2cRhNZ6yWYkQbhy2ioPQRudiDfii2UdZemV9XACHMPOdYRUkM5havftpgTG8mEIKhcXe lEzGnQWoT+9cR5aphaaBXzSHIqMI2gtXFrdF3rcTuX3IwNx2u3TyuN4VYSndlC0RKdAV PKl0FGxSOgzv7Gh7fmC36M9PkvElno5r6yllhbW3dEQGiDBQyyf8xkoxUaPALD1KyGJf eoDyeAC5w03qYpxQ6n28orOLrZTDXOFDXhrKj+EaOxuDackYGKFXg764zskUKfqh2t4x LzdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jJxiZNnfWNQr7whqD8ysMCpFCC99/4raCmFFFSVjNX0=; b=uSu4y1RX4xMCd62e1bsfNiSqNPGXrGaagt61VrloC3KaRTXFeXhNHI492U8DoIDGDs fjCbm8uighTs3VB3RELLmW6g+MXQjdoicfBPmzYSvMZW+4lylVsWj6iA0s3ZAZA44Ljr VzRRILNEu0p3pLoQNj9XN/p3ucl8knOwe/X2RXkbfG4ZJyDIBPwlSznat5YEdeq/hU6T LhN/GzkqU9mAViCZ5fsPmzvv/IAKnO1iMdY6pAPli8yyzjV5YEwWvaHj+zyz1HmbGK/y tk8eAucA33D9Z0nOcokmK8Pjlro/kGGjI3v3HiiGmCi+8PT5tFuZUxRb8ivGlEwj+V1X MnlA== X-Gm-Message-State: AFeK/H3uaH51ORJLsI6DQDDFzbI8kCDJLouxZI8FdfoN3kbw68ONSGH4LAlnmRoLwjGGgVVh+F1g8tO/dfkXCA== X-Received: by 10.28.234.206 with SMTP id g75mr9670324wmi.54.1489681054283; Thu, 16 Mar 2017 09:17:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.166.37 with HTTP; Thu, 16 Mar 2017 09:17:33 -0700 (PDT) In-Reply-To: References: <877f3q2wje.fsf@hobgoblin.ariadne.com> From: Andy Bierman Date: Thu, 16 Mar 2017 09:17:33 -0700 Message-ID: To: Robert Wilton Cc: "Dale R. Worley" , JOEY BOYD , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11472b9e11f2a1054adb66cd Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 16:17:38 -0000 --001a11472b9e11f2a1054adb66cd Content-Type: text/plain; charset=UTF-8 On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton wrote: > Hi Dale, > > > On 15/03/2017 19:02, Dale R. Worley wrote: > >> JOEY BOYD writes: >> >>> module base-module { >>> prefix bmod; >>> >>> feature do-things; >>> >>> container things { >>> if-feature do-things; >>> ... >>> } >>> } >>> >>> module augment-module { >>> prefix amod; >>> >>> augment "/bmod:do-things" { >>> container other-things { >>> } >>> } >>> } >>> >> First question: I'm not expert in Yang, but as far as I can figure out, >> the augment statement is augmenting "container things", right? So the >> augment statement should be 'augment "/bmod:things"' not 'augment >> "/bmod:do-things"'. >> > Yes, the augment should be to "things". > > >> But on the important question, I don't see it as at all unreasonable >> that the augment needs to be qualified by the same if-feature. The >> reason is that if you're reading the text of module augment-module, it's >> helpful to have documented, right there, that the augmentation depends >> on the presence of a particular feature in the augmented module. And >> it's helpful to know that the designer did, at least for one moment, >> think about the fact that the augmentation is conditional. >> > > It isn't just any if-feature on the container that is being augmented that > needs to be considered. You would have to consider all if-feature > statements by walking up the augmented node's ancestors to the top of the > tree and combine them, or have multiple if-feature statements. > > Further, the 7950 YANG update rules allow for the augmented module to be > revised and some of those if-feature statements to be subsequently > removed. If the augmenting module had restated the if-feature conditions > then this would probably leave the augmenting module unintentionally out of > sync with the module that it is augmenting. > > In short, I think that if-feature statements work better if they act on > the given node and all descendant nodes, regardless of which module those > descendants are defined in. > > "work better" Please explain which protocol you are using that allows you to manage descendant nodes of unimplemented nodes. NETCONF and RESTCONF do not work at all wrt/ accessing such nodes. > Rob > > Andy > > >> Dale >> >> _______________________________________________ >> 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 > --001a11472b9e11f2a1054adb66cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
Hi Dale,


On 15/03/2017 19:02, Dale R. Worley wrote:
JOEY BOYD <joe= y.boyd@adtran.com> writes:
module base-module {
=C2=A0 =C2=A0prefix bmod;

=C2=A0 =C2=A0feature do-things;

=C2=A0 =C2=A0container things {
=C2=A0 =C2=A0 =C2=A0if-feature do-things;
=C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0}
}

module augment-module {
=C2=A0 =C2=A0prefix amod;

=C2=A0 =C2=A0augment "/bmod:do-things" {
=C2=A0 =C2=A0 =C2=A0container other-things {
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}
}
First question:=C2=A0 I'm not expert in Yang, but as far as I can figur= e out,
the augment statement is augmenting "container things", right?=C2= =A0 So the
augment statement should be 'augment "/bmod:things"' not = 'augment
"/bmod:do-things"'.
Yes, the augment should be to "things".


But on the important question, I don't see it as at all unreasonable that the augment needs to be qualified by the same if-feature.=C2=A0 The reason is that if you're reading the text of module augment-module, it&= #39;s
helpful to have documented, right there, that the augmentation depends
on the presence of a particular feature in the augmented module.=C2=A0 And<= br> it's helpful to know that the designer did, at least for one moment, think about the fact that the augmentation is conditional.

It isn't just any if-feature on the container that is being augmented t= hat needs to be considered.=C2=A0 You would have to consider all if-feature= statements by walking up the augmented node's ancestors to the top of = the tree and combine them, or have multiple if-feature statements.

Further, the 7950 YANG update rules allow for the augmented module to be re= vised and some of those if-feature statements to be subsequently removed.= =C2=A0 If the augmenting module had restated the if-feature conditions then= this would probably leave the augmenting module unintentionally out of syn= c with the module that it is augmenting.

In short, I think that if-feature statements work better if they act on the= given node and all descendant nodes, regardless of which module those desc= endants are defined in.


"work better"

=
Please explain which protocol you are using that allows you to m= anage descendant nodes of unimplemented nodes.

NET= CONF and RESTCONF do not work at all wrt/ accessing such nodes.
= =C2=A0
Rob


Andy
=C2=A0


Dale

_______________________________________________
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

--001a11472b9e11f2a1054adb66cd-- From nobody Thu Mar 16 09:39:23 2017 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 CC2891296B3 for ; Thu, 16 Mar 2017 09:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B6XrOnQolcu for ; Thu, 16 Mar 2017 09:39:19 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6635312968F for ; Thu, 16 Mar 2017 09:39:19 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id u132so39915018wmg.0 for ; Thu, 16 Mar 2017 09:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2iSa4vXeT6tRvfifpFREAaC6WP2QgfJ5TTztmgfa8XM=; b=hdlsf449KK1KqXxyVQdaB7N9yB9p8iDeZ9E/v5kYq8IWLluIR7732HRLxS21zwH1Y/ mDdcpjUwiX5HvqWQURdUh09PCGiQr86NA3yFaeFt42ikrpVz2v77qEx1Hddf9cRljqif GhNwdYk7xUxFSjgRlMrQP0eY1ISDc1lCTqZc0gfgFTrEHDPvDQcDhjqyeYzVOqgLulUS Yz25KHjv///Ea01QmLBrcOMIUMpvfrDKjwKbDEdhfIDkXtstgM1ox8+ZQRsiHiJgwEd9 e30HQdAnDZ1kOAdrogb4hnlsvvYvy++IgPbp8TMXX6MZ70oZnWJ9u8pRaxROlNYIfbDf ShHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2iSa4vXeT6tRvfifpFREAaC6WP2QgfJ5TTztmgfa8XM=; b=kHAz5nMtfGDuFMG8m8vf0AenxFqYRpqclnblrXZJ0DXalJxvnvH81IvwpxEBpMG/BN tttOqHXqmIAC+qQZ3HQweFURC5ehd229FlxFw3p5Gqtq3Hxrq2XL0tpJXjO1yAE5om5S DSUKd66SqkA2JMzr2kYAP0Coe8cCGw7XNm54hQSzGcGvdE5uuR46ETh6Dt8cxP/Xlcq5 a5crniwVIrcGVG4HnZTP6wPecHLk9MWju5ih5QJNaRtf8PVcvRjEIsHvjtQQhPg5SPjz KwSzdy8PcW30SGeWmQ2c1kZtAYqtXXw1gNgJ3WxXx+vVOjU7CQbdlv8lITo2hvfK6SFv UrXg== X-Gm-Message-State: AFeK/H0pN8FO09RZb9VhCOANwlslmMPb3BK4GXsQrE2owsAG1CK0sMxPG2saeUjCYpJ8XFAJRs8fTQxWA6CQJA== X-Received: by 10.28.194.7 with SMTP id s7mr24335506wmf.136.1489682357922; Thu, 16 Mar 2017 09:39:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.166.37 with HTTP; Thu, 16 Mar 2017 09:39:17 -0700 (PDT) In-Reply-To: <87efxx1cty.fsf@hobgoblin.ariadne.com> References: <87efxx1cty.fsf@hobgoblin.ariadne.com> From: Andy Bierman Date: Thu, 16 Mar 2017 09:39:17 -0700 Message-ID: To: "Dale R. Worley" Cc: Robert Wilton , "netmod@ietf.org" , JOEY BOYD Content-Type: multipart/alternative; boundary=001a1148f862c5dcb6054adbb3e8 Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 16:39:22 -0000 --001a1148f862c5dcb6054adbb3e8 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 16, 2017 at 8:05 AM, Dale R. Worley wrote: > Robert Wilton writes: > > It isn't just any if-feature on the container that is being augmented > > that needs to be considered. You would have to consider all if-feature > > statements by walking up the augmented node's ancestors to the top of > > the tree and combine them, or have multiple if-feature statements. > > Yes, I would expect that. > > > Further, the 7950 YANG update rules allow for the augmented module to be > > revised and some of those if-feature statements to be subsequently > > removed. If the augmenting module had restated the if-feature > > conditions then this would probably leave the augmenting module > > unintentionally out of sync with the module that it is augmenting. > > It's an interesting sort of out-of-sync, though, as nothing would be > *incorrect*. With some combinations of features, the augmented node > would have the agumentation and with some, it would not. But it seems > to me that is quite OK, since whatever depends on the presence of the > augmentation (e.g., client logic or XPath expressions in the > augmentation) only expects the augmentation to be there if the > additional feature is present. > YANG does not do a great job of separating conformance from conditional schema nodes. The if-feature-stmt does not say false means the conformance requirement is removed. It says the schema node is removed. This means a server cannot pick some nodes from a YANG feature. The schema tree has all or none (of the nodes marked with this if-feature). This distinction may be important, especially if one tries to reconcile the "always exists" property of NP-containers with if-feature. If there are no semantics for an NP-container then how can it be included or excluded from the conformance model or the implementation? Maybe when-stmt and if-feature-stmt on an NP container really just impacts the descendants, not the NP-container itself. > Dale > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1148f862c5dcb6054adbb3e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 16, 2017 at 8:05 AM, Dale R. Worley <<= a href=3D"mailto:worley@ariadne.com" target=3D"_blank">worley@ariadne.com> wrote:
Robert Wilton <rwilton@cisco.com> writes:
> It isn't just any if-feature on the container that is being augmen= ted
> that needs to be considered.=C2=A0 You would have to consider all if-f= eature
> statements by walking up the augmented node's ancestors to the top= of
> the tree and combine them, or have multiple if-feature statements.

Yes, I would expect that.

> Further, the 7950 YANG update rules allow for the augmented module to = be
> revised and some of those if-feature statements to be subsequently
> removed.=C2=A0 If the augmenting module had restated the if-feature > conditions then this would probably leave the augmenting module
> unintentionally out of sync with the module that it is augmenting.

It's an interesting sort of out-of-sync, though, as nothing would be *incorrect*.=C2=A0 With some combinations of features, the augmented node would have the agumentation and with some, it would not.=C2=A0 But it seems=
to me that is quite OK, since whatever depends on the presence of the
augmentation (e.g., client logic or XPath expressions in the
augmentation) only expects the augmentation to be there if the
additional feature is present.


YANG does not do a great job of separating conformance from conditio= nal schema nodes.
The if-feature-stmt does not say false means th= e conformance requirement is removed.
It says the schema node is = removed.=C2=A0 This means a server cannot pick some nodes
from a = YANG feature. The schema tree has all or none (of the nodes marked with thi= s if-feature).

This distinction may be important, = especially if one tries to reconcile the "always exists" property=
of NP-containers with if-feature. If there are no semantics for = an NP-container then how
can it be included or excluded from the = conformance model or the implementation?
Maybe when-stmt and if-f= eature-stmt on an NP container really just impacts the descendants,
not the NP-container itself.



Dale

Andy
=C2=A0

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

--001a1148f862c5dcb6054adbb3e8-- From nobody Thu Mar 16 10:18:12 2017 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 E4D981296CD for ; Thu, 16 Mar 2017 10:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 IiqRYp7Iv4Dx for ; Thu, 16 Mar 2017 10:18:06 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECF81296C0 for ; Thu, 16 Mar 2017 10:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13336; q=dns/txt; s=iport; t=1489684686; x=1490894286; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=nrdikzzmRSlNuJudbCAfDDUhz6J8zmYPWNyJV7kr5k8=; b=hSJSEpO2oCPGlUCjTuGYlIcETYBG/f5PbUJC6Kh2rqAeGVNH/uAPNCIP 5G1LhtQyKcKcwMxta0VMhJOZwkMp6kUYP4H3N7Kv8LrCn/kmsySXAp4U/ 0wn5zFmQzR1a3nHHfZOK/GYQQYy6m4lfZs9xw04XraLujRuqZfszuMIVt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAQB7x8pY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqYINhig9zkGWQEYUugg4fAQqFLkoCg0UYAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECAQEBIUgDCwULCxgnAwICJx8RBg0GAgEBiXQIDrEngiYriiYBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYZOggWCaoQcgz6CXwWcRZI+gXuFKIMzhlOIS4J?= =?us-ascii?q?ziA8fOIEEIxYIFxVBhB45HYFjQDWHGoIuAQEB?= X-IronPort-AV: E=Sophos;i="5.36,173,1486425600"; d="scan'208,217";a="653321666" 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; 16 Mar 2017 17:18:01 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2GHI1Zc005656; Thu, 16 Mar 2017 17:18:01 GMT To: Andy Bierman References: <877f3q2wje.fsf@hobgoblin.ariadne.com> Cc: "Dale R. Worley" , JOEY BOYD , "netmod@ietf.org" From: Robert Wilton Message-ID: <67e7ba2b-c526-fd9b-f39f-14f5b0490f4f@cisco.com> Date: Thu, 16 Mar 2017 17:18:01 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3C9747A27FE9B20AC5E64FC8" Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:18:10 -0000 This is a multi-part message in MIME format. --------------3C9747A27FE9B20AC5E64FC8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, On 16/03/2017 16:17, Andy Bierman wrote: > > > On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton > wrote: > > Hi Dale, > > > On 15/03/2017 19:02, Dale R. Worley wrote: > > JOEY BOYD > > writes: > > module base-module { > prefix bmod; > > feature do-things; > > container things { > if-feature do-things; > ... > } > } > > module augment-module { > prefix amod; > > augment "/bmod:do-things" { > container other-things { > } > } > } > > First question: I'm not expert in Yang, but as far as I can > figure out, > the augment statement is augmenting "container things", > right? So the > augment statement should be 'augment "/bmod:things"' not 'augment > "/bmod:do-things"'. > > Yes, the augment should be to "things". > > > But on the important question, I don't see it as at all > unreasonable > that the augment needs to be qualified by the same > if-feature. The > reason is that if you're reading the text of module > augment-module, it's > helpful to have documented, right there, that the augmentation > depends > on the presence of a particular feature in the augmented > module. And > it's helpful to know that the designer did, at least for one > moment, > think about the fact that the augmentation is conditional. > > > It isn't just any if-feature on the container that is being > augmented that needs to be considered. You would have to consider > all if-feature statements by walking up the augmented node's > ancestors to the top of the tree and combine them, or have > multiple if-feature statements. > > Further, the 7950 YANG update rules allow for the augmented module > to be revised and some of those if-feature statements to be > subsequently removed. If the augmenting module had restated the > if-feature conditions then this would probably leave the > augmenting module unintentionally out of sync with the module that > it is augmenting. > > In short, I think that if-feature statements work better if they > act on the given node and all descendant nodes, regardless of > which module those descendants are defined in. > > > "work better" > > Please explain which protocol you are using that allows you to manage > descendant nodes of unimplemented nodes. > > NETCONF and RESTCONF do not work at all wrt/ accessing such nodes. I think that we may be crossing wires: It was NETCONF/RESTCONF that I was thinking of, and I am not considering managing descendant nodes of unimplemented nodes. I think that the question is only whether an augmentation of a node that has an if-feature statement also requires the same if-feature statement on the augment statement. To quote Joey's example, I think that both of the following modules are valid (presuming that they are both implemented by a device) regardless of which features are enabled. Do you agree? module base-module { prefix bmod; feature things; feature widgets; container things { if-feature things; ... container widgets { if-feature widgets; ... } } } module augment-module { prefix amod; augment "/bmod:things" { container other-things { } } augment "/bmod:things/bmod:widgets" { container other-widgets { } } } Thanks, Rob > Rob > > > Andy > > > > Dale > > _______________________________________________ > 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 > > > --------------3C9747A27FE9B20AC5E64FC8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andy,


On 16/03/2017 16:17, Andy Bierman wrote:


On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi Dale,


On 15/03/2017 19:02, Dale R. Worley wrote:
JOEY BOYD <joey.boyd@adtran.com> writes:
module base-module {
   prefix bmod;

   feature do-things;

   container things {
     if-feature do-things;
     ...
   }
}

module augment-module {
   prefix amod;

   augment "/bmod:do-things" {
     container other-things {
     }
   }
}
First question:  I'm not expert in Yang, but as far as I can figure out,
the augment statement is augmenting "container things", right?  So the
augment statement should be 'augment "/bmod:things"' not 'augment
"/bmod:do-things"'.
Yes, the augment should be to "things".


But on the important question, I don't see it as at all unreasonable
that the augment needs to be qualified by the same if-feature.  The
reason is that if you're reading the text of module augment-module, it's
helpful to have documented, right there, that the augmentation depends
on the presence of a particular feature in the augmented module.  And
it's helpful to know that the designer did, at least for one moment,
think about the fact that the augmentation is conditional.

It isn't just any if-feature on the container that is being augmented that needs to be considered.  You would have to consider all if-feature statements by walking up the augmented node's ancestors to the top of the tree and combine them, or have multiple if-feature statements.

Further, the 7950 YANG update rules allow for the augmented module to be revised and some of those if-feature statements to be subsequently removed.  If the augmenting module had restated the if-feature conditions then this would probably leave the augmenting module unintentionally out of sync with the module that it is augmenting.

In short, I think that if-feature statements work better if they act on the given node and all descendant nodes, regardless of which module those descendants are defined in.


"work better"

Please explain which protocol you are using that allows you to manage descendant nodes of unimplemented nodes.

NETCONF and RESTCONF do not work at all wrt/ accessing such nodes.
I think that we may be crossing wires:

It was NETCONF/RESTCONF that I was thinking of, and I am not considering managing descendant nodes of unimplemented nodes.

I think that the question is only whether an augmentation of a node that has an if-feature statement also requires the same if-feature statement on the augment statement.

To quote Joey's example,  I think that both of the following modules are valid (presuming that they are both implemented by a device) regardless of which features are enabled.  Do you agree?

module base-module {
  prefix bmod;

  feature things;
  feature widgets;

  container things {
    if-feature things;
    ...
    container widgets {
      if-feature widgets;
      ...
    }
  }
}    

module augment-module {
  prefix amod;

  augment "/bmod:things" {
    container other-things {
    }
  }

  augment "/bmod:things/bmod:widgets" {
    container other-widgets {
    }
  }
}
Thanks,
Rob


 
Rob


Andy
 


Dale

_______________________________________________
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


--------------3C9747A27FE9B20AC5E64FC8-- From nobody Thu Mar 16 10:26:15 2017 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 E5A981296C8 for ; Thu, 16 Mar 2017 10:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEHTuwa1cZRq for ; Thu, 16 Mar 2017 10:26:11 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A461296DC for ; Thu, 16 Mar 2017 10:26:11 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id t189so53861470wmt.1 for ; Thu, 16 Mar 2017 10:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NhuMELW2ze61ziml8taK/bLgihEj9lwZY38IF4drdfM=; b=cbGtfxemuekC8cO5caPZXs3ZDan4IDk1987cMXJ4CJtO458waUyDZ6C6oQDWyvmyB8 CWJNuj83pQ/0E8WyPiWcK33rih6xp/r9LUrkJznncv2eX/Dv6fyoAsVoBZcaC/PhTosX oJ/t0cwTfS7QUZNh/yFl6wLlZg5kN5qmyNuFteCng81ofjGoXVpekCsJ3SdN95ByRJ6W 5I4IjWor103tGAXJDgfzpRzJKVFxecRAJ+2GaC0RqAG0PeWchp0gOv4ZMQXsiECMA4rp /Z+0S3XXh/sYhoebYYfIEOPaCeRHThszpix3TpoAJKo2lsa9OEiHc/0CLbDAPiCfl0Zl 23pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NhuMELW2ze61ziml8taK/bLgihEj9lwZY38IF4drdfM=; b=J5i0iCYoUjh5jv+pDzIjLF6rRtJQ22J6e5Xw7PdtPcV1FvX/hB/u3VUBKR2U+QxmdC vbwekQyXdVWUQMJqMIMKMYCamfgeJOva95Wfnu9DdIvetuLTtj0xzepLAd3//7ptGdBI ApEPBgtvwIvi/di1Ig18EHntlo/SnEZ6XC3xgqS1t1909/MJOAP2bV3aYyHqhGvy2LAK hR4IRawe+G2VhVCiNi51FM/7O408r0oR2FamoFsySCGJ5Rk+oxBeZZDMlJBR659tKE+m 0sdASTtwiEygl2vfE897NXP5EqJ71U+pvY0TR7hqhy7dLK9gNRFBdERyCXjwPWS07iFY 54UQ== X-Gm-Message-State: AFeK/H0oUhBoU9uPjfFltzT1DlfoD5fFPm5BJnrKAcslI4WC0BFBn7WdBNMPbP5Xmd93GloA1ufpv5CzGdUWmg== X-Received: by 10.28.103.3 with SMTP id b3mr24018494wmc.99.1489685169561; Thu, 16 Mar 2017 10:26:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.166.37 with HTTP; Thu, 16 Mar 2017 10:26:08 -0700 (PDT) In-Reply-To: <67e7ba2b-c526-fd9b-f39f-14f5b0490f4f@cisco.com> References: <877f3q2wje.fsf@hobgoblin.ariadne.com> <67e7ba2b-c526-fd9b-f39f-14f5b0490f4f@cisco.com> From: Andy Bierman Date: Thu, 16 Mar 2017 10:26:08 -0700 Message-ID: To: Robert Wilton Cc: "Dale R. Worley" , JOEY BOYD , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a114a91b25c0a6d054adc5b10 Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:26:14 -0000 --001a114a91b25c0a6d054adc5b10 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 16, 2017 at 10:18 AM, Robert Wilton wrote: > Hi Andy, > > On 16/03/2017 16:17, Andy Bierman wrote: > > > > On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton wrote: > >> Hi Dale, >> >> >> On 15/03/2017 19:02, Dale R. Worley wrote: >> >>> JOEY BOYD writes: >>> >>>> module base-module { >>>> prefix bmod; >>>> >>>> feature do-things; >>>> >>>> container things { >>>> if-feature do-things; >>>> ... >>>> } >>>> } >>>> >>>> module augment-module { >>>> prefix amod; >>>> >>>> augment "/bmod:do-things" { >>>> container other-things { >>>> } >>>> } >>>> } >>>> >>> First question: I'm not expert in Yang, but as far as I can figure out, >>> the augment statement is augmenting "container things", right? So the >>> augment statement should be 'augment "/bmod:things"' not 'augment >>> "/bmod:do-things"'. >>> >> Yes, the augment should be to "things". >> >> >>> But on the important question, I don't see it as at all unreasonable >>> that the augment needs to be qualified by the same if-feature. The >>> reason is that if you're reading the text of module augment-module, it's >>> helpful to have documented, right there, that the augmentation depends >>> on the presence of a particular feature in the augmented module. And >>> it's helpful to know that the designer did, at least for one moment, >>> think about the fact that the augmentation is conditional. >>> >> >> It isn't just any if-feature on the container that is being augmented >> that needs to be considered. You would have to consider all if-feature >> statements by walking up the augmented node's ancestors to the top of the >> tree and combine them, or have multiple if-feature statements. >> >> Further, the 7950 YANG update rules allow for the augmented module to be >> revised and some of those if-feature statements to be subsequently >> removed. If the augmenting module had restated the if-feature conditions >> then this would probably leave the augmenting module unintentionally out of >> sync with the module that it is augmenting. >> >> In short, I think that if-feature statements work better if they act on >> the given node and all descendant nodes, regardless of which module those >> descendants are defined in. >> >> > "work better" > > Please explain which protocol you are using that allows you to manage > descendant nodes of unimplemented nodes. > > NETCONF and RESTCONF do not work at all wrt/ accessing such nodes. > > I think that we may be crossing wires: > > It was NETCONF/RESTCONF that I was thinking of, and I am not considering > managing descendant nodes of unimplemented nodes. > > I think that the question is only whether an augmentation of a node that > has an if-feature statement also requires the same if-feature statement on > the augment statement. > > no -- I don't think there is any requirement. As pointed out, the if-features can be anywhere in the ancestor nodes. If any of them are false for a given server, then the augmenting nodes are inaccessible. To quote Joey's example, I think that both of the following modules are > valid (presuming that they are both implemented by a device) regardless of > which features are enabled. Do you agree? > > The modules are valid. The conformance decision (i.e., which features are advertised and which are not by a server implementation) does not change the compile-time validity of the YANG modules > module base-module { > prefix bmod; > > feature things; > feature widgets; > > container things { > if-feature things; > ... > container widgets { > if-feature widgets; > ... > } > } > } > > module augment-module { > prefix amod; > > augment "/bmod:things" { > container other-things { > } > } > > augment "/bmod:things/bmod:widgets" { > container other-widgets { > } > } > } > > Thanks, > Rob > > > Andy > > >> Rob >> >> > Andy > > >> >> >>> Dale >>> >>> _______________________________________________ >>> 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 >> > > > --001a114a91b25c0a6d054adc5b10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 16, 2017 at 10:18 AM, Robert Wilton <<= a href=3D"mailto:rwilton@cisco.com" target=3D"_blank">rwilton@cisco.com= > wrote:
=20 =20 =20

Hi Andy,


On 16/03/2017 16:17= , Andy Bierman wrote:
=20


On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi Dale,


On 15/03/2017 19:02, Dale R. Worley wrote:
JOEY BOYD <joey.boyd@adtran.com> writes:
module base-module {
=C2=A0 =C2=A0prefix bmod;

=C2=A0 =C2=A0feature do-things;

=C2=A0 =C2=A0container things {
=C2=A0 =C2=A0 =C2=A0if-feature do-things;
=C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0}
}

module augment-module {
=C2=A0 =C2=A0prefix amod;

=C2=A0 =C2=A0augment "/bmod:do-things" {
=C2=A0 =C2=A0 =C2=A0container other-things {
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}
}
First question:=C2=A0 I'm not expert in Yang, but as fa= r as I can figure out,
the augment statement is augmenting "container things&= quot;, right?=C2=A0 So the
augment statement should be 'augment "/bmod:things= "' not 'augment
"/bmod:do-things"'.
Yes, the augment should be to "things".


But on the important question, I don't see it as at all unreasonable
that the augment needs to be qualified by the same if-feature.=C2=A0 The
reason is that if you're reading the text of module augment-module, it's
helpful to have documented, right there, that the augmentation depends
on the presence of a particular feature in the augmented module.=C2=A0 And
it's helpful to know that the designer did, at least fo= r one moment,
think about the fact that the augmentation is conditional.

It isn't just any if-feature on the container that is being augmented that needs to be considered.=C2=A0 You would have to consider all if-feature statements by walking up the augmented node's ancestors to the top of the tree and combine them, or have multiple if-feature statements.

Further, the 7950 YANG update rules allow for the augmented module to be revised and some of those if-feature statements to be subsequently removed.=C2=A0 If th= e augmenting module had restated the if-feature conditions then this would probably leave the augmenting module unintentionally out of sync with the module that it is augmenting.

In short, I think that if-feature statements work better if they act on the given node and all descendant nodes, regardless of which module those descendants are defined in.


"work better"

Please explain which protocol you are using that allows you to manage descendant nodes of unimplemented nodes.

NETCONF and RESTCONF do not work at all wrt/ accessing such nodes.
I think that we may be crossing wires:

It was NETCONF/RESTCONF that I was thinking of, and I am not considering managing descendant nodes of unimplemented nodes.

I think that the question is only whether an augmentation of a node that has an if-feature statement also requires the same if-feature statement on the augment statement.


no -- I don't th= ink there is any requirement.
As pointed out, the if-features can= be anywhere in the ancestor nodes.
If any of them are false for = a given server, then the augmenting nodes are inaccessible.

<= /div>

To quote Joey's example,=C2=A0 I think that both of the following modules are valid (presuming that they are both implemented by a device) regardless of which features are enabled.=C2=A0 Do you agree?=



The m= odules are valid.
The conformance decision (i.e., which features = are advertised and which are not by a server implementation)
does= not change the compile-time validity of the YANG modules
=C2=A0<= /div>
module base-module {
  prefix bmod;

  feature things;
  feature widgets;

  container things {
    if-feature things;
    ...
    container widgets {
      if-feature widgets;
      ...
    }
  }
}   =20

module augment-module {
  prefix amod;

  augment "/bmod:things" {
    container other-things {
    }
  }

  augment "/bmod:things/bmod:widgets" {
    container other-widgets {
    }
  }
}
Thanks,
Rob




Andy
=C2=A0
=C2=A0
Rob


Andy
=C2=A0


Dale

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


_______________________________________________
netmod mailing list
netmod@i= etf.org
https://www.ietf.org/mailman/listinf= o/netmod



--001a114a91b25c0a6d054adc5b10-- From nobody Thu Mar 16 10:29:06 2017 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 E28251296D1 for ; Thu, 16 Mar 2017 10:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 c_yGKrrW4_iF for ; Thu, 16 Mar 2017 10:29:02 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0104.outbound.protection.outlook.com [104.47.2.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84692129494 for ; Thu, 16 Mar 2017 10:29:01 -0700 (PDT) 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; bh=9JKCYNbGMdO75pMUEGrDit8WnmvZ/KdgRXWmwYZ4UYY=; b=IYb/TYaNTqERwx/IyiCY9ZhDhSc92w4zGJQCpnAfuN5ms2+Dccaf8OjMHipz9DbEiskzU6FMG8rJkfKjrWvL9UTqkuJpM8Zfzw2SOaOkBk0EdRL+ESXTQtc70cr/RWRQ2JRHDc0ux09j3fGccHb/cZGbL8HB2/Gv3UFu/VamoTk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.203.75) by HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Thu, 16 Mar 2017 17:28:58 +0000 Message-ID: <02a101d29e7a$98231380$4001a8c0@gateway.2wire.net> From: t.petch To: "Clyde Wildes (cwildes)" CC: References: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> <3F4C49C9-1A6A-4644-97C6-F9CDC2E4EB4B@cisco.com> <1CC274D2-72B9-4F79-A70F-3DF332C65A60@cisco.com> <44C50B18-8918-47E4-A9FE-F4A676E64AA1@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF818AA@SJCEML703-CHM.china.huawei.com> <02B9298C-631A-46F7-9FA9-19B1959327FE@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81C18@SJCEML703-CHM.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81CBA@SJCEML703-CHM.china.huawei.com> <033D3CA2-7297-48C8-A5BD-B723F7F1911B@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81CF7@SJCEML703-CHM.china.huawei.com> <075901d29286$5def4300$4001a8c0@gateway.2wire.net> <63894410-D14B-4F3D-B72C-898CE30B5104@cisco.com> Date: Thu, 16 Mar 2017 17:04:52 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.203.75] X-ClientProxiedBy: DB6P18901CA0020.EURP189.PROD.OUTLOOK.COM (10.169.208.158) To HE1PR0701MB3002.eurprd07.prod.outlook.com (10.168.93.136) X-MS-Office365-Filtering-Correlation-Id: 7cca31e1-9f93-4f46-7057-08d46c91ee81 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:lN8FJXevv2Z1rwuJhEUJXVxMocMp+/nNiW8lI3j8lcbdn+7PeIOfbZu+Y1Vm2nbaokKJ2Iglt0g66BdzgyFwpf1KT+i78zs8qHVtN70Ms/Kmwfr7XF9eHx0a8IGYxwSp7HFTNGjfC12lukMy055N3IEeCpCIoHNw1t1mVr6HTGm7iWaZF51gRLi22yvOK6TcY12R6X29C6JqQ7S4LwTs/4Xmyt1Qqi2H6A3hcuRSKW5WR3D88gsx6ffrQioJ3vtS61pjMhEQeuIdzkOkQ9f2iA==; 25:/XVKW/SP2BIp6hrZRqSf5FbhYjxxIRrsk7i15Z5ZxRbTZ1Q7kUITvKILchjEZVtAoBu5J8NL5GkdIo8KWD3RgHVu8R9vOrmhl1eJ9b+GoyJIbM8ICIo9D2DlD5M/CtoGk27RWsdFMCBJmk4o5Rluj1sWvbgi/SMTPrlodIwkUuZRlBOKhfo6eM+wDG/k7b1wqZw3ClnRBV4QFDurntLFV6KneZo53M8W2ODl0VbkuawyKFZS7dZ7YrdZE9mmCr09PJ4/I0wiJFeN5ijCbcgeeHEKyVVZbRnmhUPlrM9oC/wlPxhThnjsrSGpF5vqtt0Dzw7FL2O/xzNiVKk+xcQXahXDtW2FlfBgEnyu43YajhDTpY2X3RIhj0w39lfNUM53Q8uwlAAmPSYXm73jriWtQ8/abyoDB1Wcghrq2OlMTzj6Txim9dNGN28UeF+I/285xhTszkYzkZFabbINthZt2Q== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 31:e2Yu5IfGVuDwVAaxxQ+IFwZRE5NhMEVGRS7ZsqoEwKI8J+XWwY+K+yASH6CIOmVZ49ZZMQuE/+1+LTJclfET43VSU5JTmNnPpxY/db5dja6OY5oYF6mp5JA6/P797t2E6DoaqTCmaUfASOb67/c4VkXKV20wzoTOsu7UpDjxQcusHZzUEtnKjf8QNXeiuRTz7LusgA37fICzQF1CG07zzGZJsWSftZpOCDxvBHbQjosqGOS7zli0n93a1IWriEJEiD1F5yFquiS3CfhwU/hCvw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(50582790962513)(95692535739014)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558025)(6072148)(6042181); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 4:aBklDIRmOhUxC7EUWlPA3Ayi+OnadFGQeWJZ7yusi1EBiCkQAYNzNkXu21d1/9D9utVhRPffC3sVd9VD//BaoWDlgC7+18sTEizA/u0YvlJ80+LnKdpwYb5rNIYSWJDH8yTXkvseDfEH7xtjWpuJL4pZs1DlAyNc6uCzDtio1f3gHom6Tr+Hq+WUv7JsC79OUcAiMJB0o1eEzWDJeeLaDTgeRg9IcaMH+jIdsRcIirU0A1BqgKqPBrp7ewOiPhevCUrDkVNX8Qr4jP9Qra8oN/X2YATatZMwTjGkLCoUD+zzuN0hJw7b5eAzPu+72petpnl6nvrDrLMHFCjjhYSgqs5pLL3v+0upgXWLscrbp8s65u3k0ynZ9OuddafhnPFjh7zTLEhRPsh+QabtUiot/qAH/lQ6LkBcQ6IpIlhkaLl1xclMm0C9+KIL3MqvFTEDO7ippuL5eNlxRng9gefBBnPTISG6B+AIa7CLRpazNvnjoE6afChoVHSrsbhHMWxTC4MHrwcpqqcHHsBI7sA9TLAaAMgubZKpA5aAG+a8gFuzaRZoYQKC0w6ugxD39AP9wgc8sM5B/NqeZRN/HNuwvgAZY7sY/Tt1/rG9alleFxLhFrInKsuWRfWY8tigAj3m8jeoMJn/tIZXN1b34zKpzyy+UNSS8yQeCC4bBqMmaB4GEsSyeW0fuKoEtVoNMvi7CUlldvX2H0TTo6MIFL+J68nBI+EmF6l4OwpzIUywT6flvHBRMqc8yvgns2jDMIL2L3VpkafWl4A+jRb8oSHLSw== X-Forefront-PRVS: 024847EE92 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(377454003)(24454002)(13464003)(2870700001)(25786008)(189998001)(5660300001)(6116002)(3846002)(97736004)(61296003)(8676002)(6666003)(42186005)(5820100001)(47776003)(50226002)(6916009)(2906002)(23676002)(44716002)(84392002)(66066001)(106356001)(62236002)(76176999)(305945005)(6246003)(7736002)(81686999)(38730400002)(1556002)(50986999)(9686003)(110136004)(229853002)(81166006)(44736005)(6306002)(4326008)(33646002)(53546007)(230783001)(14496001)(116806002)(4720700003)(6496005)(50466002)(1456003)(53936002)(86362001)(81816999)(6486002)(93886004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDI7MjM6RXFYQkNaQmZ2dExlcmZxeWZyMUtUOUl1?= =?utf-8?B?TUNzRDlPNGxubXY5Ung3YXo1OHA1WDFwdU5DeWtiTWdsZTV2NmtrSCtnZEtE?= =?utf-8?B?QWk0d0JuMkF4L0t1RUkxV1JmVDVCMEpoWjJTK2w0ZXd5SlZScXZ6OStxRE1w?= =?utf-8?B?RmVwNm5uNXRkeWJmT0llQytrTnhML2dNemdGVjFISFNweWR5ZFE0dTMxbEQ5?= =?utf-8?B?RmR3a1lLUHQ2TkhQR1ZhRFpsVmd6K3ZEczZEMFZiWTJIcjMxMEIyNjFNSE1k?= =?utf-8?B?SFp6Wlh5VkJYcnRWVTJCdlhJVWplT3Q2YlZTak1kVjhFQ0ZMd2QxaWJId1Rq?= =?utf-8?B?ZW9GU0R2RmFMbnBiS2NOODg5Zm5JMm52WDVxTkJLUGdoZUdMZHI4UEwxMG9T?= =?utf-8?B?c1VXdkR3REJYVEdidHNNVkYxeWd0MytzL0k4L0M2cktwKzBTLzNMWE03cENo?= =?utf-8?B?Z3FlemRyaW4vTjYwMXRzUmFIZEphTGlBU3BVRDkvQS9qaFZPUGZWTXg0aW1C?= =?utf-8?B?dnRZamNsQy9MemFwVkp2S05aZHQrNjFYOEw4eUZmL1VOQ2NwMmhaYWU0RXdM?= =?utf-8?B?Y2t2ZG9PUnQ1Mk9ONVJ3RDBsWnF5QlI3WDRzM1VPeC9sLzZXSVpLb2RiM21W?= =?utf-8?B?U1BlTVF3NXZzWEMva1dnZld2YnUyekJRaVFXbjFNRTR3MU5DN3JncHdVakJ5?= =?utf-8?B?SUxKRWhkUFB4Q2huMDVRZHRBOWZ6M280VzBVWmRsd282bTJ2OGFGeDJQdHFZ?= =?utf-8?B?b0FUL3RLcFBUcmMrVXZmeXd5WW1NdVNVTHk1cGNSVFRub1k5NnlvM3RXL2g0?= =?utf-8?B?R2U5eWJucDJpMW1IendyZ3dXVkFYK3lpOUF1bVZ2RUkrSjU0SDZLZW5wNGk5?= =?utf-8?B?UlRHMzdZUnllYUtrUjBpNzZmVjRFY3Btckc2YWRKQjVVZXN4YWZVVnZzbENw?= =?utf-8?B?elp6MDhWelF6UGlFcDNqQmRqYjFPSE05SEZEekdPSGhMekdRbFhXVStQb1NB?= =?utf-8?B?TjBKL0JPakkyMXNGVTViNmNhTWFzM0tRNVFRUi85U0JIS3lvUnppUXJIdWRW?= =?utf-8?B?WjhMYitiNk5HcFFkWmpEWkp3bFQvMi81V05OR3RRSDdFQ0YvSDFtdS8rYUhp?= =?utf-8?B?RzlISzU1R0RFb0lzZ1VzU0QwMjhUbjREOWltOUhFM3c1ZStqcS9rb00vOTBX?= =?utf-8?B?UGFkWjBFRElzc2pMWExYOWZSc0NFZlEyQVZvOW5jZ25MOGFNYytXdUt1WkdR?= =?utf-8?B?ODlCaEEvU21BYjl1YlBvVksyTzFkbllmR21kTkxQVWFPKy9PWCt4cHcxT1Fi?= =?utf-8?B?a00veDlHc0YwQkJjQkxkMUhKdkhSdHRZZThERFZlQWpGWGtkWGRhNlBMdGhn?= =?utf-8?B?bnA0TC8veWtsNnFZSTMrTDFrdXdhdWR2SWQ4WjJFbzNBVEE1Z1IvbzRHSDlp?= =?utf-8?B?V2Z2Z3Q5N0tKanJBdHdQR0d0cy92ei9TR295L1pxcCs3SzJCcXE0SmxJUGNY?= =?utf-8?B?YnlMV215OFh0SGNvOUZzeVYvQ1QrQVhRZGFKbHgvcm83bFRhT2Z0dGFMVUhm?= =?utf-8?B?bjJyZGxRdzdlSDVodDE1eHFyWTZZQjlvVzJkT0thZFBzdFVYWlBtSUJSMEtD?= =?utf-8?B?b0Q2VWw4bGdVdm43MG4xNjNSRjBOT08zdU5XRllZUXo2V2VBWUJxUXFydERY?= =?utf-8?B?VGJ5cGJVU21mUnRoekU0OTF0SnNQOG9NWHlZdVVzOTJKV0lyR1kyQXBNbUw1?= =?utf-8?B?Rm9zTDhSWittUVNIOVg3MFFGeVJIWGY5dEJLZVdlUDFIWTdmajZ4QnVzb2R3?= =?utf-8?B?TE1QeFNTeER4dHNkWHJtd09VM3UyRVhkWlgyb3FUd1ZCQVlXUWlPMGR6VEpD?= =?utf-8?Q?adLdCZoCsols8=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:tBVjJvp4yFPjqc1FffO8QIvXnPaUwX0MMawmbt30/zLPMtuFqr4QElGC/oIyWt1etZknhruDcLcLz7GtAuhsWevJxPfXINDhadoa7LSCRtP9rJL83P+krPL5D+qJ9pyPmkT8E4HF7ZttAFAZkdC8jZjWVpRLmNVrSKYnEl3boDxEy3YFYYjDV7lTyyomlbKnagiDFbHRbC6PZoHlsmz0jVRd+D/jayd9fG5F7iZhlGgoLbJf05sUqVCsRW1KbGenpN6i6EtmZCmsSC9vPbmbuWfAuTgVt/G8jUvC0CBqLJC6JdqfWpGYeOL9993NG6LiWD9V+YME7nAS6ZhKwOdsgPrTbrfTtsxDuFkAFAZEDn5wKKoO48VOrYsslpGnkHk1NIcGTfLPs3YP3Va0Mu1/NQ==; 5:Uvu5T1UAlgRVTrtEY79qBCjEE/j225IabPcHdG7no3zK82SYRUYZfQrz5uK9LapNkkzQ6pLTpca7Pq4hI44aKRl5dfnbFm7+UcbgHqbbu9L0VrPSU1BzV2cYm5MUdyb5hDRYvEIvW6Bb8c6koc8XdA==; 24:M6rN+QlBiEiwiEWzNW8QStTvxfuIEV7BqgbScKrgu56Gm5NqPfddJdD/Qhe3vaFR80CNyNbYf8LT2hXyUN2JayV3IiXo08ews7ASfqxMmeM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 7:dSTkqoxg6GrMktU35xJpGBUDq41RvWuRi1omOkFrDzmKndxpfhyKHpEFzgO7FJVnlIGyUdDGdzf9nOdR9VeCbjbOWdIfKxEUwSp/6/S0kwQP3HrnnrxUquv6fPbUW6LwFHplSrfck0QpVeMlcNnnMIHI67+YM2Q1JwaNFZfX/rmudbQF+BM9rKtKImowTqX97ejjWKGdhjH+TqJrU/7A0kIty6ZyyrNDW/nscOM2Nid7TMqPOBfYBFhcZTDd+eBDKj2Z7Ipf/katTPqyHhzKpG+MzYVvApWmZvkKpqDgjbf0ECSNC/BKLG6ut9NWOfoWfDf4HYVESd3D7gyPvuu8uQ== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2017 17:28:58.9427 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Subject: Re: [netmod] draft-ietf-netmod-syslog-model-12 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:29:05 -0000 ----- Original Message ----- From: "Clyde Wildes (cwildes)" Sent: Monday, March 13, 2017 6:11 PM > Tom, > > The next revision of the draft-ietf-netmod-syslog-model includes a change to the Yang tree diagram explanation to include the text from RFC6087bis. > > RFC5426 is referenced in the model where "Transmission of Syslog Messages over UDP†occurs: > > case udp { > container udp { > description > "This container describes the UDP transport > options."; > reference > "RFC 5426: Transmission of Syslog Messages over UDP"; > > This is a correct reference. Indeed but I don't think that [RFC5426] is going to work as part of leaf sig-number-resends while leaf structured-data { ... as per RFC5424 is not the usual style. On another tack, I thought that you agreed to change one of the identifiers in grouping selector { description container selector { Tom Petch > Thanks, > > Clyde > > On 3/1/17, 4:20 AM, "netmod on behalf of t.petch" wrote: > > The explanation of the YANG tree diagram is not that in RFC6087; I think > that it should be (or else explain why not) > > I am confused by the variation in the references to RFC in the modules. > > I see > RFC 5424 > [RFC5426] > RFC5424 > > I think the first correct > > Tom Petch > > ----- Original Message ----- > From: "Alexander Clemm" > To: "Kent Watsen" ; > > Cc: > Sent: Friday, February 24, 2017 12:25 AM > Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > From nobody Thu Mar 16 10:34:58 2017 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 E65981296CB for ; Thu, 16 Mar 2017 10:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 DD6ZcIcu6dNq for ; Thu, 16 Mar 2017 10:34:54 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67831296C4 for ; Thu, 16 Mar 2017 10:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20339; q=dns/txt; s=iport; t=1489685693; x=1490895293; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=N/FCbpDx02XvCPaONbOac0ovjqjTo9jY6WWaVhG03vA=; b=L5SDumkamNdXK4ky8abwI9ep90T94Zn+Ry/uPwgqPh++gVthOlOrTlCB oGaYKql44Z6EW3Has1rMEJvensb7+/XqI9/bmQSYg9ElXbpiP65mEnM6F i3/hUHfUi5X3Pjy6YgR/mFKY9FwAELSmNhFMla6wdv1idyw6ctUEk2X94 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiBABnzMpY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqYINhiwKQZZU/gg4fAQqFLkoCg0YXAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQECAQEBIUgDCwULCxgnAwICJx8RBg0GAgEBiXQIDrE0giYriiQBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYZOggWCaoQcIoMcgl8FlgCGRZI+gXuFKIMzhlOIS4J?= =?us-ascii?q?ziA8gATaBBCMWCBcVQYQeOR2BY0A1hxqCLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,173,1486425600"; d="scan'208,217";a="653321956" 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; 16 Mar 2017 17:34:49 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2GHYlFN013087; Thu, 16 Mar 2017 17:34:48 GMT To: Andy Bierman References: <877f3q2wje.fsf@hobgoblin.ariadne.com> <67e7ba2b-c526-fd9b-f39f-14f5b0490f4f@cisco.com> Cc: "Dale R. Worley" , JOEY BOYD , "netmod@ietf.org" From: Robert Wilton Message-ID: <6e3ac8db-8c6e-1d31-277a-8d5536ff7afe@cisco.com> Date: Thu, 16 Mar 2017 17:34:47 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3D30BD99DEB39E2E1BEAB479" Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:34:57 -0000 This is a multi-part message in MIME format. --------------3D30BD99DEB39E2E1BEAB479 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 16/03/2017 17:26, Andy Bierman wrote: > > > On Thu, Mar 16, 2017 at 10:18 AM, Robert Wilton > wrote: > > Hi Andy, > > > On 16/03/2017 16:17, Andy Bierman wrote: >> >> >> On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton > > wrote: >> >> Hi Dale, >> >> >> On 15/03/2017 19:02, Dale R. Worley wrote: >> >> JOEY BOYD > > writes: >> >> module base-module { >> prefix bmod; >> >> feature do-things; >> >> container things { >> if-feature do-things; >> ... >> } >> } >> >> module augment-module { >> prefix amod; >> >> augment "/bmod:do-things" { >> container other-things { >> } >> } >> } >> >> First question: I'm not expert in Yang, but as far as I >> can figure out, >> the augment statement is augmenting "container things", >> right? So the >> augment statement should be 'augment "/bmod:things"' not >> 'augment >> "/bmod:do-things"'. >> >> Yes, the augment should be to "things". >> >> >> But on the important question, I don't see it as at all >> unreasonable >> that the augment needs to be qualified by the same >> if-feature. The >> reason is that if you're reading the text of module >> augment-module, it's >> helpful to have documented, right there, that the >> augmentation depends >> on the presence of a particular feature in the augmented >> module. And >> it's helpful to know that the designer did, at least for >> one moment, >> think about the fact that the augmentation is conditional. >> >> >> It isn't just any if-feature on the container that is being >> augmented that needs to be considered. You would have to >> consider all if-feature statements by walking up the >> augmented node's ancestors to the top of the tree and combine >> them, or have multiple if-feature statements. >> >> Further, the 7950 YANG update rules allow for the augmented >> module to be revised and some of those if-feature statements >> to be subsequently removed. If the augmenting module had >> restated the if-feature conditions then this would probably >> leave the augmenting module unintentionally out of sync with >> the module that it is augmenting. >> >> In short, I think that if-feature statements work better if >> they act on the given node and all descendant nodes, >> regardless of which module those descendants are defined in. >> >> >> "work better" >> >> Please explain which protocol you are using that allows you to >> manage descendant nodes of unimplemented nodes. >> >> NETCONF and RESTCONF do not work at all wrt/ accessing such nodes. > I think that we may be crossing wires: > > It was NETCONF/RESTCONF that I was thinking of, and I am not > considering managing descendant nodes of unimplemented nodes. > > I think that the question is only whether an augmentation of a > node that has an if-feature statement also requires the same > if-feature statement on the augment statement. > > > no -- I don't think there is any requirement. > As pointed out, the if-features can be anywhere in the ancestor nodes. > If any of them are false for a given server, then the augmenting nodes > are inaccessible. Agreed. > > > To quote Joey's example, I think that both of the following > modules are valid (presuming that they are both implemented by a > device) regardless of which features are enabled. Do you agree? > > > > The modules are valid. > The conformance decision (i.e., which features are advertised and > which are not by a server implementation) > does not change the compile-time validity of the YANG modules Also agreed. Thanks, Rob > module base-module { > prefix bmod; > > feature things; > feature widgets; > > container things { > if-feature things; > ... > container widgets { > if-feature widgets; > ... > } > } > } > > module augment-module { > prefix amod; > > augment "/bmod:things" { > container other-things { > } > } > > augment "/bmod:things/bmod:widgets" { > container other-widgets { > } > } > } > > Thanks, > Rob > > > > > Andy > >> Rob >> >> >> Andy >> >> >> >> Dale >> >> _______________________________________________ >> 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 >> >> >> > > --------------3D30BD99DEB39E2E1BEAB479 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 16/03/2017 17:26, Andy Bierman wrote:


On Thu, Mar 16, 2017 at 10:18 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,


On 16/03/2017 16:17, Andy Bierman wrote:


On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi Dale,


On 15/03/2017 19:02, Dale R. Worley wrote:
JOEY BOYD <joey.boyd@adtran.com> writes:
module base-module {
   prefix bmod;

   feature do-things;

   container things {
     if-feature do-things;
     ...
   }
}

module augment-module {
   prefix amod;

   augment "/bmod:do-things" {
     container other-things {
     }
   }
}
First question:  I'm not expert in Yang, but as far as I can figure out,
the augment statement is augmenting "container things", right?  So the
augment statement should be 'augment "/bmod:things"' not 'augment
"/bmod:do-things"'.
Yes, the augment should be to "things".


But on the important question, I don't see it as at all unreasonable
that the augment needs to be qualified by the same if-feature.  The
reason is that if you're reading the text of module augment-module, it's
helpful to have documented, right there, that the augmentation depends
on the presence of a particular feature in the augmented module.  And
it's helpful to know that the designer did, at least for one moment,
think about the fact that the augmentation is conditional.

It isn't just any if-feature on the container that is being augmented that needs to be considered.  You would have to consider all if-feature statements by walking up the augmented node's ancestors to the top of the tree and combine them, or have multiple if-feature statements.

Further, the 7950 YANG update rules allow for the augmented module to be revised and some of those if-feature statements to be subsequently removed.  If the augmenting module had restated the if-feature conditions then this would probably leave the augmenting module unintentionally out of sync with the module that it is augmenting.

In short, I think that if-feature statements work better if they act on the given node and all descendant nodes, regardless of which module those descendants are defined in.


"work better"

Please explain which protocol you are using that allows you to manage descendant nodes of unimplemented nodes.

NETCONF and RESTCONF do not work at all wrt/ accessing such nodes.
I think that we may be crossing wires:

It was NETCONF/RESTCONF that I was thinking of, and I am not considering managing descendant nodes of unimplemented nodes.

I think that the question is only whether an augmentation of a node that has an if-feature statement also requires the same if-feature statement on the augment statement.


no -- I don't think there is any requirement.
As pointed out, the if-features can be anywhere in the ancestor nodes.
If any of them are false for a given server, then the augmenting nodes are inaccessible.
Agreed.



To quote Joey's example,  I think that both of the following modules are valid (presuming that they are both implemented by a device) regardless of which features are enabled.  Do you agree?



The modules are valid.
The conformance decision (i.e., which features are advertised and which are not by a server implementation)
does not change the compile-time validity of the YANG modules

Also agreed.

Thanks,
Rob


 
module base-module {
  prefix bmod;

  feature things;
  feature widgets;

  container things {
    if-feature things;
    ...
    container widgets {
      if-feature widgets;
      ...
    }
  }
}    

module augment-module {
  prefix amod;

  augment "/bmod:things" {
    container other-things {
    }
  }

  augment "/bmod:things/bmod:widgets" {
    container other-widgets {
    }
  }
}
Thanks,
Rob




Andy
 
 
Rob


Andy
 


Dale

_______________________________________________
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




--------------3D30BD99DEB39E2E1BEAB479-- From nobody Thu Mar 16 10:43:30 2017 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 194761296CB; Thu, 16 Mar 2017 10:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 X5P5ViqEjYPP; Thu, 16 Mar 2017 10:43:26 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50201296FA; Thu, 16 Mar 2017 10:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8737; q=dns/txt; s=iport; t=1489686205; x=1490895805; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=dkhzIi2WkblxC/O3jBoUtXSpTHZFgPBd9UbCoeCQFtM=; b=S+EWcnlQFn+TQk4gNDVpbuemUyDNIUjQpBBg6por4XfJ3P7H4mLKSR5U kgETVLYUshoLKW70xCrm+4zJLV8pKxgKWnk4ReljXqw55YPkQhTmAkb8p vXn0nPCPiImTazOhRwpzGNiX66wIIWZbkpVZ8DwuXQMIiWcmKUBmDpytP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQCSzcpY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyeBCyqOUHOQZZARgx+CD4IOLIV2AoNFGAECAQEBAQEBAWsohRY?= =?us-ascii?q?BBYEJCw4EBi5JDgYBCQMIAQEXiWUOs08riiQBAQEBAQEBAQIBAQEBAQEBAQEaB?= =?us-ascii?q?YZOggWCaoo5BZxFhneLR4F7iFsjhjCLPogPHziBBCMWCBcVhRgdgWQ/iX0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,173,1486425600"; d="scan'208,217";a="650479244" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 17:43:21 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2GHhKXT014717; Thu, 16 Mar 2017 17:43:20 GMT To: Alia Atlas , Kent Watsen , "netmod@ietf.org" , "sec-ads@ietf.org" References: <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> <20170316135145.GB23450@elstar.local> <20170316143803.GB23686@elstar.local> From: Benoit Claise Message-ID: <328c7b27-389a-3c58-4efd-dc5a86fedfbc@cisco.com> Date: Thu, 16 Mar 2017 18:43:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170316143803.GB23686@elstar.local> Content-Type: multipart/alternative; boundary="------------184BC62530535F7C5500B4BA" Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:43:29 -0000 This is a multi-part message in MIME format. --------------184BC62530535F7C5500B4BA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, As discussed during the IESG telechat today, we should only focus on the addition of the RESTCONF bits, and not attempt to include the I2RS future protocol now. Hence this minimum change proposal: The YANG module defined in this document is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. Regards, Benoit > On Thu, Mar 16, 2017 at 10:13:18AM -0400, Alia Atlas wrote: >>> Keep in mind that I2RS believes in a requirement for cleartext >>> transport protocols. Perhaps this never makes it through the IESG but >>> so far it was not possible to stop this... >>> >> This is solely for notifications that can be sent, just as IPFIX >> information may >> be sent unencrypted. Those requirements are in >> draft-ietf-i2rs-protocol-security-requirements-17 >> , >> which is in the RFC Editor queue. >> > The new features are priority, an opaque secondary identifier, and an > insecure protocol for read-only data constrained to specific standard > usages. > > The optional insecure transport can only be used > restricted set of publically data available (events or information) > or a select set of legacy data. Data passed over the insecure > transport channel MUST NOT contain any data which identifies a > person. > > I think your statement that it is only for notifications is wrong. > The fact that some data ships in a notification does not mean the data > is not sensitive. Furthermore, I think we all meanwhile know that > IPFIX data is highly sensitive if you have the right context > information (so the analogy is flawed). And what the heck is a 'select > set of legacy data'? > > SEC-REQ-06: An I2RS agent receiving an I2RS message over an > insecure transport MUST confirm that the content is suitable for > transfer over such a transport. > > An agent can't decide this. It is the context information that often > decides whether a piece of information is sensitive or not. So the > only decision an agent can do is to only allow messages with empty > content over an insecure transport. > > The I2RS architecture defines three scopes: read, write, and > notification scope. Insecure data can only be used for read scope > and notification scope of "non-confidential data". > > I understand that the IESG approved the security requirements. I do > not know why the security ADs did let this pass - perhaps since the > document is just about requirements and they will look closer at a > solution and then ask questions what 'non-confidentail' data' is, what > a 'select set of legacy data' is, or how an agent confirms that the > content of messages is suitable for an insecure transport. > > Anyway, this does not belong here, the point I wanted to make is > simply that Kent's assumption that a protocol transporting YANG > defined data is always protecting the data is not true from the > viewpoint of the I2RS proponents. Thanks for confirming this. > > /js > --------------184BC62530535F7C5500B4BA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear all,

As discussed during the IESG telechat today, we should only focus on the addition of the RESTCONF bits, and not attempt to include the I2RS future protocol now.
Hence this minimum change proposal:
     The YANG module defined in this document is designed to be
     accessed via network management protocols such as NETCONF
     [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the
     secure transport layer, and the mandatory-to-implement secure
     transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF
     layer is HTTPS, and the mandatory-to-implement secure transport is
     TLS [RFC5246].

     The NETCONF access control model [RFC6536] provides the means to
     restrict access for particular NETCONF or RESTCONF users to a
     pre-configured subset of all available NETCONF or RESTCONF
     protocol operations and content.
Regards, Benoit
On Thu, Mar 16, 2017 at 10:13:18AM -0400, Alia Atlas wrote:

Keep in mind that I2RS believes in a requirement for cleartext
transport protocols. Perhaps this never makes it through the IESG but
so far it was not possible to stop this...


This is solely for notifications that can be sent, just as IPFIX
information may
be sent unencrypted.  Those requirements are in
draft-ietf-i2rs-protocol-security-requirements-17
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/>,
which is in the RFC Editor queue.


   The new features are priority, an opaque secondary identifier, and an
   insecure protocol for read-only data constrained to specific standard
   usages.

   The optional insecure transport can only be used
   restricted set of publically data available (events or information)
   or a select set of legacy data.  Data passed over the insecure
   transport channel MUST NOT contain any data which identifies a
   person.

I think your statement that it is only for notifications is wrong.
The fact that some data ships in a notification does not mean the data
is not sensitive. Furthermore, I think we all meanwhile know that
IPFIX data is highly sensitive if you have the right context
information (so the analogy is flawed). And what the heck is a 'select
set of legacy data'?

      SEC-REQ-06: An I2RS agent receiving an I2RS message over an
      insecure transport MUST confirm that the content is suitable for
      transfer over such a transport.

An agent can't decide this. It is the context information that often
decides whether a piece of information is sensitive or not. So the
only decision an agent can do is to only allow messages with empty
content over an insecure transport.

   The I2RS architecture defines three scopes: read, write, and
   notification scope.  Insecure data can only be used for read scope
   and notification scope of "non-confidential data".

I understand that the IESG approved the security requirements. I do
not know why the security ADs did let this pass - perhaps since the
document is just about requirements and they will look closer at a
solution and then ask questions what 'non-confidentail' data' is, what
a 'select set of legacy data' is, or how an agent confirms that the
content of messages is suitable for an insecure transport.

Anyway, this does not belong here, the point I wanted to make is
simply that Kent's assumption that a protocol transporting YANG
defined data is always protecting the data is not true from the
viewpoint of the I2RS proponents. Thanks for confirming this.

/js

--------------184BC62530535F7C5500B4BA-- From nobody Thu Mar 16 10:58:51 2017 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 CF8B6129722 for ; Thu, 16 Mar 2017 10:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 63Tuor1jm_k1 for ; Thu, 16 Mar 2017 10:58:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC311296DE for ; Thu, 16 Mar 2017 10:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4222; q=dns/txt; s=iport; t=1489687125; x=1490896725; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=m28opj3VDnuDkwfJjvJM/JZdDv6nO4aOtHz3QQ+iwUA=; b=Rg5fcQ286w2xB1jfl7sdVZu/AsSW0UfrSvC66sVwHvcVlqF+GRQw9FhG hQXjJj91nyFfvcpD6vrBLSwxiMDKP0VSrXr9k2if39TyNRhBjjzW2ylXS n7Re/pGHxANwyWlfRrOskMux7a81Ozht4JkKFvPqrL8Yf4ZpzPRQ3blDE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAQAG0spY/5xdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1qKD5FYlT+CDh8LhS5KAhqCbD8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECAQEBGwYROgsMBAIBCBEEAQEBAgImAgICJQsVCAgCBA4FiXgIDrEsg?= =?us-ascii?q?iaKTwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFQ4IFgmqEVBeCby6CMQWPW4Y?= =?us-ascii?q?lhkUBkj2Be4UoigaTTAEfOIEEWBVBEQGGRXWIOwGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,173,1486425600"; d="scan'208";a="224265879" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 17:58:20 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2GHwKgj010386 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Mar 2017 17:58:20 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Mar 2017 12:58:19 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Thu, 16 Mar 2017 12:58:19 -0500 From: "Clyde Wildes (cwildes)" To: "t.petch" CC: "netmod@ietf.org" Thread-Topic: [netmod] draft-ietf-netmod-syslog-model-12 Thread-Index: AQHSkobQ/9SfvUTqzk20DVCcI8lG36GTA94AgATMsTn//+amgA== Date: Thu, 16 Mar 2017 17:58:19 +0000 Message-ID: References: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> <3F4C49C9-1A6A-4644-97C6-F9CDC2E4EB4B@cisco.com> <1CC274D2-72B9-4F79-A70F-3DF332C65A60@cisco.com> <44C50B18-8918-47E4-A9FE-F4A676E64AA1@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF818AA@SJCEML703-CHM.china.huawei.com> <02B9298C-631A-46F7-9FA9-19B1959327FE@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81C18@SJCEML703-CHM.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81CBA@SJCEML703-CHM.china.huawei.com> <033D3CA2-7297-48C8-A5BD-B723F7F1911B@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81CF7@SJCEML703-CHM.china.huawei.com> <075901d29286$5def4300$4001a8c0@gateway.2wire.net> <63894410-D14B-4F3D-B72C-898CE30B5104@cisco.com> <02a101d29e7a$98231380$4001a8c0@gateway.2wire.net> In-Reply-To: <02a101d29e7a$98231380$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.37] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] draft-ietf-netmod-syslog-model-12 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:58:50 -0000 VG9tLA0KDQpJbmxpbmXigKYNCg0KT24gMy8xNi8xNywgMTA6MDQgQU0sICJ0LnBldGNoIiA8aWV0 ZmNAYnRjb25uZWN0LmNvbT4gd3JvdGU6DQoNCiAgICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tDQogICAgRnJvbTogIkNseWRlIFdpbGRlcyAoY3dpbGRlcykiIDxjd2lsZGVzQGNpc2NvLmNv bT4NCiAgICBTZW50OiBNb25kYXksIE1hcmNoIDEzLCAyMDE3IDY6MTEgUE0NCiAgICANCiAgICA+ IFRvbSwNCiAgICA+DQogICAgPiBUaGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQtaWV0Zi1u ZXRtb2Qtc3lzbG9nLW1vZGVsIGluY2x1ZGVzIGENCiAgICBjaGFuZ2UgdG8gdGhlIFlhbmcgdHJl ZSBkaWFncmFtIGV4cGxhbmF0aW9uIHRvIGluY2x1ZGUgdGhlIHRleHQgZnJvbQ0KICAgIFJGQzYw ODdiaXMuDQogICAgPg0KICAgID4gUkZDNTQyNiBpcyByZWZlcmVuY2VkIGluIHRoZSBtb2RlbCB3 aGVyZSAiVHJhbnNtaXNzaW9uIG9mIFN5c2xvZw0KICAgIE1lc3NhZ2VzIG92ZXIgVURQ4oCdIG9j Y3VyczoNCiAgICA+DQogICAgPiAgICAgICAgICAgICAgIGNhc2UgdWRwIHsNCiAgICA+ICAgICAg ICAgICAgICAgICAgY29udGFpbmVyIHVkcCB7DQogICAgPiAgICAgICAgICAgICAgICAgICAgZGVz Y3JpcHRpb24NCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICJUaGlzIGNvbnRhaW5lciBkZXNj cmliZXMgdGhlIFVEUCB0cmFuc3BvcnQNCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICBvcHRp b25zLiI7DQogICAgPiAgICAgICAgICAgICAgICAgICAgcmVmZXJlbmNlDQogICAgPiAgICAgICAg ICAgICAgICAgICAgICAiUkZDIDU0MjY6IFRyYW5zbWlzc2lvbiBvZiBTeXNsb2cgTWVzc2FnZXMg b3Zlcg0KICAgIFVEUCI7DQogICAgPg0KICAgID4gVGhpcyBpcyBhIGNvcnJlY3QgcmVmZXJlbmNl Lg0KICAgIA0KICAgIEluZGVlZCBidXQgSSBkb24ndCB0aGluayB0aGF0IFtSRkM1NDI2XSAgaXMg Z29pbmcgdG8gd29yayBhcyBwYXJ0IG9mDQogICAgbGVhZiBzaWctbnVtYmVyLXJlc2VuZHMNCiAg ICB3aGlsZQ0KICAgIA0KICAgICAgICAgICBsZWFmIHN0cnVjdHVyZWQtZGF0YSB7DQogICAgICAg ICAgICAuLi4NCiAgICAgICAgICAgYXMgcGVyIFJGQzU0MjQNCiAgICANCiAgICBpcyBub3QgdGhl IHVzdWFsIHN0eWxlLg0KICAgIA0KW2NseWRlXSBJIHdhcyB1cmdlZCB0byB1c2UgdGhlIGRlc2Ny aXB0aW9ucyBkaXJlY3RseSBmcm9tIFJGQzU4NDgg4oCTIGluIHRoaXMgY2FzZSBmcm9tIHNlY3Rp b24gNi4xLjIuIENvbmZpZ3VyYXRpb24gUGFyYW1ldGVycyBmb3IgU2lnbmF0dXJlIEJsb2NrcyAo cGFnZSAyNSkNCg0KICAgIHNpZ051bWJlclJlc2VuZHMgPSBudW1iZXIgb2YgdGltZXMgYSBTaWdu YXR1cmUgQmxvY2sgaXMgcmVzZW50Lg0KICAgICAgKEl0IGlzIHJlY29tbWVuZGVkIHRvIHNlbGVj dCBhIHZhbHVlIG9mIGdyZWF0ZXIgdGhhbiAiMCIgaW4NCiAgICAgIHBhcnRpY3VsYXIgd2hlbiB0 aGUgVURQIHRyYW5zcG9ydCBbUkZDNTQyNl0gaXMgdXNlZC4pICAgIA0KDQpbY2x5ZGVdIFBsZWFz ZSBzdWdnZXN0IGEgbmV3IG5hbWUgZm9yIHRoZSBzZWxlY3RvciB0aGF0IHlvdSB0aGluayBzaG91 bGQgYmUgY2hhbmdlZC4gSSBjb3VsZCBub3QgZmluZCBhIHJlZmVyZW5jZSB0byB0aGlzIGluIG15 IG5vdGVzLg0KDQogICAgT24gYW5vdGhlciB0YWNrLCBJIHRob3VnaHQgdGhhdCB5b3UgYWdyZWVk IHRvIGNoYW5nZSBvbmUgb2YgdGhlDQogICAgaWRlbnRpZmllcnMgaW4NCiAgICANCiAgICAgICAg IGdyb3VwaW5nIHNlbGVjdG9yIHsNCiAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICANCiAgICAg ICAgICAgY29udGFpbmVyIHNlbGVjdG9yIHsNCiAgICANClRoYW5rcywNCg0KQ2x5ZGUgDQoNCiAg IA0KICAgIFRvbSBQZXRjaA0KICAgIA0KICAgID4gVGhhbmtzLA0KICAgID4NCiAgICA+IENseWRl DQogICAgPg0KICAgID4gT24gMy8xLzE3LCA0OjIwIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiB0 LnBldGNoIg0KICAgIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaWV0ZmNA YnRjb25uZWN0LmNvbT4gd3JvdGU6DQogICAgPg0KICAgID4gICAgIFRoZSBleHBsYW5hdGlvbiBv ZiB0aGUgWUFORyB0cmVlIGRpYWdyYW0gaXMgbm90IHRoYXQgaW4gUkZDNjA4NzsgSQ0KICAgIHRo aW5rDQogICAgPiAgICAgdGhhdCBpdCBzaG91bGQgYmUgKG9yIGVsc2UgZXhwbGFpbiB3aHkgbm90 KQ0KICAgID4NCiAgICA+ICAgICBJIGFtIGNvbmZ1c2VkIGJ5IHRoZSB2YXJpYXRpb24gaW4gdGhl IHJlZmVyZW5jZXMgdG8gUkZDIGluIHRoZQ0KICAgIG1vZHVsZXMuDQogICAgPg0KICAgID4gICAg IEkgc2VlDQogICAgPiAgICAgUkZDIDU0MjQNCiAgICA+ICAgICBbUkZDNTQyNl0NCiAgICA+ICAg ICBSRkM1NDI0DQogICAgPg0KICAgID4gICAgIEkgdGhpbmsgdGhlIGZpcnN0IGNvcnJlY3QNCiAg ICA+DQogICAgPiAgICAgVG9tIFBldGNoDQogICAgPg0KICAgID4gICAgIC0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0NCiAgICA+ICAgICBGcm9tOiAiQWxleGFuZGVyIENsZW1tIiA8YWxleGFu ZGVyLmNsZW1tQGh1YXdlaS5jb20+DQogICAgPiAgICAgVG86ICJLZW50IFdhdHNlbiIgPGt3YXRz ZW5AanVuaXBlci5uZXQ+Ow0KICAgID4gICAgIDxkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9k ZWxAaWV0Zi5vcmc+DQogICAgPiAgICAgQ2M6IDxuZXRtb2RAaWV0Zi5vcmc+DQogICAgPiAgICAg U2VudDogRnJpZGF5LCBGZWJydWFyeSAyNCwgMjAxNyAxMjoyNSBBTQ0KICAgID4gICAgIFN1Ympl Y3Q6IFJlOiBbbmV0bW9kXSBXRyBMYXN0IENhbGwgZm9yDQogICAgZHJhZnQtaWV0Zi1uZXRtb2Qt c3lzbG9nLW1vZGVsLTExDQogICAgPg0KICAgID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAgICAgbmV0bW9kIG1haWxpbmcgbGlzdA0K ICAgID4gICAgIG5ldG1vZEBpZXRmLm9yZw0KICAgID4gICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgPg0KICAgID4NCiAgICA+DQogICAgDQogICAg DQoNCg== From nobody Thu Mar 16 11:24:22 2017 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 A966E1297A5 for ; Thu, 16 Mar 2017 11:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3URPcdWQtDn for ; Thu, 16 Mar 2017 11:24:18 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 7A0C5129841 for ; Thu, 16 Mar 2017 11:24:17 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id l37so37942352wrc.1 for ; Thu, 16 Mar 2017 11:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=8i+W+whGE0+5u1YtgwesryAhDlvxmhVyxgsooZQgUUM=; b=Ou6VOtawfwyHhVVoPw9HRSnkJUiDXzOvh16Ah43Yr4JAS3STay57FowdO1JAgI0+3P JpfA0eZ6UvvpWkftmbJWqti+bRZBc+IvnoUpozyWWIvZvG68sepwmYUeo+asSsiKUJnz TXRYcbnc0PVJ2lmazFqiDu3yvoBFYCtSer8dkw3uHOi2cMaL2FFHn6cbrvd+b5qZAqgU HzH9NPsihwCp4LXLcyUYcm3MksQENYeCJyTpzJYx1CPC2HcXmpkl/AbsFxFXyDCqtG85 QZZWnzKQTLBdOhiJNEXhjo2BjXXfm1k2z5nqN0caRoLHT0IUGt0sDUTPQahyT/Dp0Xt/ 0BCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=8i+W+whGE0+5u1YtgwesryAhDlvxmhVyxgsooZQgUUM=; b=TD34S6tadnL9+0yiK2VpdAQ7wTxDsQ48p55f0l9zYJYIIEUDh3DzWU5/zgZ+Tn+lTf u9WeOnRAT5KmALorcDnQJ4PmDNB2zGRkmNjU0qBvfs+zoF57UYDKTup7i7eNcJfa9x1s qeLqNkpPYknxkXkFspa28CmVhSylE+y529W//+f+NRheRlAK1Oy+FKsNdH5vvZzIo0yY 8EbZfJOuP2GmgrQcfUUBdbUqpoH7nlJWJsH590t13CPEDTwY9sKjSzDKnwk7mTlUd2z8 AeZOIM1B2nGLiV+uksmUMVUmDj9wnBs0hAys6B87duW7JFOeSywVRuYjmzFDhUzqYCs9 gsvQ== X-Gm-Message-State: AFeK/H2VSII75lqxLlyzweKj1sUwMhh6OIh8bMEzMiESBxD2mgA2EQGYDYsuwhpGh5vCSg== X-Received: by 10.223.132.37 with SMTP id 34mr8906156wrf.45.1489688655592; Thu, 16 Mar 2017 11:24:15 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p5B341913.dip0.t-ipconnect.de. [91.52.25.19]) by smtp.gmail.com with ESMTPSA id h3sm7111107wrb.6.2017.03.16.11.24.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 11:24:15 -0700 (PDT) From: "Mehmet Ersue" To: "'Lou Berger'" , "'Kent Watsen'" , References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <675654fd-1532-1755-621c-a3ecb06950e3@labn.net> In-Reply-To: <675654fd-1532-1755-621c-a3ecb06950e3@labn.net> Date: Thu, 16 Mar 2017 19:24:15 +0100 Message-ID: <025a01d29e82$8549d070$8fdd7150$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUooBvvnQPAGVQNXroK5l/jA= Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0202.58CAD84E.01F6,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 18:24:22 -0000 Lou, > Mehmet, > > On 03/15/2017 09:50 AM, Mehmet Ersue wrote: > > Hi Lou, Kent, > > > > it appears to me the issues I raised below are not closed. > it wasn't clear from your mail that a response was needed as it seemed to be > covering points otherwise discussed, and where we may not agree. > It's good that you are re-raising them now. > > > > > I believe at least a "minimal" WG item focus formulation is required > > to match to the high-level WG focus topics in a)-f). I was thinking my > > proposal below is acceptable. > > > I think we disagree on this point. That said, perhaps our objection is in the > abstract and not the specific. Can you propose specific text change you'd like > to see made to the charter and we can discuss it? I believe IETF WG charters need to be defined for a particular period of time with a specific target for development. The current charter proposal seems to provide a high-level WG focus definition without time limits. I think the WG items to develop in the planned time period need to be defined at least minimally, at least as an indication. This is the basis for me as a WG member by which I agree or object to the approval of a charter proposal for the planned development period. I actually provided a very simple proposal. You guys can fill the idea with minimal text better than me. I'm fine whatever the text is. If you think the high-level topic description a)-f) does already define the WG item clearly you can simply say "this is achieved with WG item XY". If not, you can keep the high-level focus text but set additionally the borders of the WG item with a few concrete words. > > Netconf WG will ensure avoiding double-work concerning the DS concept > > draft, however Netconf needs to specify what is required for the use > > of the DS concept from protocol standards pov. > > okay. I think we agree that the protocol aspects belong in NetConf - and > we're expecting those to be covered during the NetConf WG session in > Chicago. > > > That said different people including Netconf WG co-chairs think the DS > > concept document is Informational in nature and should be published as > > an Informational concept to be used in and adopted for the needs in > > diverse protocol WGs. > > okay. I'm not sure whether your "okay" means the same as I meant. I think the DS draft provides a conceptual framework for diverse DS usage scenarios to be used by many protocols, where IETF WGs may actually decide using a subset of the DS framework for their purpose and for their protocol standardization. Based on this the conceptual framework cannot be standardized as it is but the protocols using a consistent subset have to be standardized. Following this consideration I think the intended status of the DS draft should be changed to: Informational RFC If you agree please indicate this change accordingly. > > This is as I think also important to avoid an overlapping between > > NETCONF and NETMOD charters. > > I don't follow this point. Certainly I'd hope that the protocol impact of > revised DS are covered in a PS document, unless for some reason there are > no "on-the-wire" changes needed. TI wouldn't expect that the document > status of the base revised data store document would impact that. Do you? > If so, how? My comment is actually superfluous if you agree with my considerations above. The worst case would in my opinion happen if the DS conceptual framework covering many high-level DS usage scenarios would be attempted to standardize, which at the end would prescribe protocol WGs what they should be standardizing. In such a case the conceptual framework would most likely cause a competing situation with protocol WG's goals and documents and cannot be adopted successfully. Thanks, Mehmet > > PS: I expect that most of the Netconf WG member read also the Netmod > > maillist and therefor skip sending to both ML. > > > > Great. > > Thanks. > Lou > > Thanks, > > Mehmet > > > >> -----Original Message----- > >> From: Mehmet Ersue > >> Sent: Thursday, March 9, 2017 7:36 PM > >> To: Lou Berger ; 'Kent Watsen' > >> ; netmod@ietf.org > >> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' > >> > >> Subject: RE: [netmod] draft netmod charter update proposal > >> > >> Hi Lou, > >> > >>> The charters from the last couple of years don't have the intended > > status -- > >> at least the ones we checked. > >>> I actually feel pretty strongly about this (which of course can be > >>> easily overruled by our AD). It's my experience that premature > >>> discussions on intended status, i.e., before a document is > >>> sufficiently > >> mature, leads to process-focused arguments that detracts from making > >> technical progress. While once a document is mature and core > >> direction/content is fixed, it is generally obvious what status is > > appropriate. > >> > >> The charters from the last couple of years have a short WG item > > definition, > >> which would be IMO sufficient. > >> You are right the intended status is not available since a few years, > >> but > > IMO it > >> is part of the target definition and would be very useful for the > >> draft > > authors > >> and WG members to regard. > >> > >>>> It would be good to bring the high-level topics in relation to the > >>>> WG > >> items. > >>> I'm sorry, I don't understand this last sentence can you rephrase it? > >> > >> What I meant is that the high-level topics a)-f) might be good as WG > >> focus description but are not sufficient as draft target definition. > >> If you think the high-level topic description is more or less the WG > >> item definition, then we could simply write "this is achieved with WG item > XY". > >> If not, we could keep the high-level focus text but set additionally > >> the borders of the WG item with some concrete words. > >> > >>>> BTW: We agreed in diverse discussions that the DS concept is > >> Informational in nature. > >>>> I think this should be corrected in the draft. > >>> > >>> So this sounds like an objection to a specific document. This is a > >>> fair point to raise, but in our opinion it is not a charter > >>> impacting point or discussion. If this is in fact the issue you'd > >>> like to raise and discuss, lets do so under a document specific > >>> thread, e.g., > > "Subject: > >> intended status of revised-datastore". > >> > >> I am actually raising this point since November meeting. There are > > different > >> threads where I explained why it is appropriate as Informational. > >> The last thread I remember is at: > >> > https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH1 > >> 1xcY > >> The recent position of NETCONF co-chairs is in > >> > https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd > >> 8qr5k > >> > >> Thank you for your consideration. > >> > >> Regards, > >> Mehmet > >> > >>> -----Original Message----- > >>> From: Lou Berger [mailto:lberger@labn.net] > >>> Sent: Wednesday, March 8, 2017 11:28 PM > >>> To: Mehmet Ersue ; 'Kent Watsen' > >>> ; netmod@ietf.org > >>> Subject: Re: [netmod] draft netmod charter update proposal > >>> > >>> Hi Mehmet, > >>> > >>> On 3/8/2017 4:47 PM, Mehmet Ersue wrote: > >>>> Kent, > >>>> > >>>>> we understand that this is how NETCONF charters are structured, > >>>>> but it is not our practice, > >>>> AFAIK it was the NETMOD practice for the charters until today. > >>> > >>> The charters from the last couple of years don't have the intended > >>> status -- at least the ones we checked. > >>> > >>> I actually feel pretty strongly about this (which of course can be > >>> easily overruled by our AD). It's my experience that premature > >>> discussions on intended status, i.e., before a document is > >>> sufficiently mature, leads to process-focused arguments that > >>> detracts > > from > >> making technical progress. > >>> While once a document is mature and core direction/content is fixed, > >>> it is generally obvious what status is appropriate. > >>> > >>> > >>>> I did not ask > >>>> more than written in the current charter. > >>>> It would be good to bring the high-level topics in relation to the > >>>> WG > >> items. > >>> I'm sorry, I don't understand this last sentence can you rephrase it? > >>> > >>>>> as the information is available at the top of each draft, and also > >>>>> because > >>> this information need not be fixed when the milestone is added. > >>> > >>>> I believe a WG charter should be self-sufficient covering the > >>>> target definition and intended status of the WG items. > >>>> Otherwise one can change the target for a WG item by simply editing > >>>> the draft abstract anytime. > >>> > >>> Per IETF process, all it ever takes to make a change in document > >>> status is WG consensus, and then IESG and IETF buy-in as part of the > >> publication process. > >>> > >>>> BTW: We agreed in diverse discussions that the DS concept is > >>>> Informational in nature. > >>>> I think this should be corrected in the draft. > >>> > >>> So this sounds like an objection to a specific document. This is a > >>> fair point to raise, but in our opinion it is not a charter > >>> impacting point or discussion. If this is in fact the issue you'd > >>> like to raise and discuss, lets do so under a document specific > >>> thread, e.g., > > "Subject: > >>> intended status of revised-datastore". > >>> > >>> Thanks, > >>> Lou > >>> > >>>> > >>>> Mehmet > >>>> > >>>>> -----Original Message----- > >>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent > >>>>> Watsen > >>>>> Sent: Wednesday, March 8, 2017 7:45 PM > >>>>> To: netmod@ietf.org > >>>>> Cc: netmod-chairs@ietf.org > >>>>> Subject: Re: [netmod] draft netmod charter update proposal > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Hi NETMOD WG, > >>>>> > >>>>> Please find below draft-4 having the following change: > >>>>> > >>>>> - added "(e.g., I2RS, RTGWG)" to a sentence. > >>>>> > >>>>> Hi Sue, Lou and I looked at the proposed charter and found a > >>>>> sentence that nicely describes our WG's intent to work with and > >>>>> support other WGs (beyond NETCONF), but we felt that the text > >>>>> could be made more clear by adding in the above-mentioned change. > >>>>> Beyond this, and the existing a), > >>>> b), > >>>>> and c), we believe that the charter proposal covers our support > >>>>> for I2RS, > >>>> do > >>>>> you agree? > >>>>> > >>>>> Hi Mehmet, regarding putting a short description and the intended > >>>>> status > >>>> for > >>>>> each draft into the charter, we understand that this is how > >>>>> NETCONF > >>>> charters > >>>>> are structured, but it is not our practice, as the information is > >>>> available at the > >>>>> top of each draft, and also because this information need not be > >>>>> fixed > >>>> when > >>>>> the milestone is added. > >>>>> > >>>>> All, Any other comments? > >>>>> > >>>>> Kent > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Network Modeling (NETMOD) > >>>>> ------------------------- > >>>>> > >>>>> Charter > >>>>> > >>>>> Current Status: Active > >>>>> > >>>>> Chairs: > >>>>> Lou Berger > >>>>> Kent Watsen > >>>>> > >>>>> Operations and Management Area Directors: > >>>>> Benoit Claise > >>>>> Joel Jaeggli > >>>>> > >>>>> Operations and Management Area Advisor: > >>>>> Benoit Claise > >>>>> > >>>>> Secretary: > >>>>> Zitao (Michael) Wang > >>>>> > >>>>> Mailing Lists: > >>>>> General Discussion: netmod@ietf.org > >>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/netmod > >>>>> Archive: > > https://mailarchive.ietf.org/arch/browse/netmod/ > >>>>> > >>>>> Description of Working Group: > >>>>> > >>>>> The Network Modeling (NETMOD) working group is responsible for > >>>>> the YANG > >>>>> data modeling language, and guidelines for developing YANG > models. > >>> The > >>>>> NETMOD working group addresses general topics related to the > >>>>> use of > >>> the > >>>>> YANG language and YANG models, for example, the mapping of > YANG > >>>>> modeled > >>>>> data into various encodings. Finally, the NETMOD working group > >>>>> also defines core YANG models used as basic YANG building > >>>>> blocks, > >> and > >>>>> YANG models that do not otherwise fall under the charter of any > > other > >>>>> IETF working group. > >>>>> > >>>>> The NETMOD WG is responsible for: > >>>>> > >>>>> a) Maintaining the data modeling language YANG. This effort > > entails > >>>>> periodically updating the specification to address new > > requirements > >>>>> as they arise. > >>>>> > >>>>> b) Maintaining the guidelines for developing YANG models. This > > effort > >>>>> is primarily driven by updates made to the YANG specification. > >>>>> > >>>>> c) Maintaining a conceptual framework in which YANG models are > >> used. > >>>>> This effort entails describing the generic context that in YANG > >>>>> exists and how certain YANG statements interact in that > > context. > >>>>> An example of this is YANG's relationship with datastores. > >>>>> > >>>>> d) Maintaining encodings for YANG modeled data. This effort > > entails > >>>>> updating encodings already defined by the NETMOD working > >>>>> (XML > >> and > >>>>> JSON) to accommodate changes to the YANG specification, and > >>> defining > >>>>> new encodings that are needed, and yet do not fall under the > > charter > >>>>> of any other active IETF working group. > >>>>> > >>>>> e) Maintaining YANG models used as basic YANG building blocks. > > This > >>>>> effort entails updating existing YANG models > >>>>> (ietf-yang-types > > and > >>>>> ietf-inet-types) as needed, as well as defining additional > >>>>> core > > YANG > >>>>> data models when necessary. > >>>>> > >>>>> f) Defining and maintaining YANG models that do not fall under the > >>>>> charter of any other active IETF working group. > >>>>> > >>>>> The NETMOD working group consults with the NETCONF working > >> group > >>> to > >>>>> ensure that new requirements are understood and can be met by > the > >>>>> protocols (e.g., NETCONF and RESTCONF) developed within that > >> working > >>>>> group. The NETMOD working group coordinates with other working > >>> groups > >>>>> (e.g., I2RS, RTGWG) on possible extensions to YANG to address new > >>>>> modeling requirements and, when needed, which group will run the > >>>>> process on a specific model. > >>>>> > >>>>> The NETMOD working group does not serve as a review team for > >> YANG > >>>>> modules developed by other working groups. Instead, the YANG > >>> doctors, > >>>>> as organized by the OPS area director responsible for network > >>>>> management, will act as advisors for other working groups and > > provide > >>>>> YANG reviews for the OPS area directors. > >>>>> > >>>>> Milestones: > >>>>> > >>>>> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for > > publication > >>>>> Mar 2017 - Submit draft-ietf-netmod-yang-model-classification > >>>>> to > > IESG > >>>>> for publication > >>>>> Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for > > publication > >>>>> Apr 2017 - Submit draft-ietf-netmod-entity to IESG for publication > >>>>> Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG for > >>>> publication > >>>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for > >>>> publication > >>>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for > >>>>> publication > >>>>> Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > >>>>> publication > >>>>> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for > >>>>> publication > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 Mar 16 12:49:50 2017 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 7231B129A41; Thu, 16 Mar 2017 12:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 VAhtyJhRFdAN; Thu, 16 Mar 2017 12:49:46 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0124.outbound.protection.outlook.com [104.47.33.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE1E129A3A; Thu, 16 Mar 2017 12:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SlOFl26auvpoSTb70b8WqzB5xKVn6VymzOv7DvVsr6o=; b=J0E6Uxp1oD8R8nRDSnunnUYupzRp81JEb3l9TVGw5g30cjGn+nWszLF+a4QWLEPFHIewoUIaiTEw0mdw3KNllvrHT4q9havdPOUgSAyJEjNdG9XRy3IjL1vLIwLOH+eT4+rwG9RLXNRCFO+bKkIeatzDnj7X3PldQ1VTKkfZqJg= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Thu, 16 Mar 2017 19:49:45 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0977.013; Thu, 16 Mar 2017 19:49:45 +0000 From: Kent Watsen To: Juergen Schoenwaelder CC: Benoit Claise , "netmod@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [netmod] security considerations boilerplate updates to cover RESTCONF Thread-Index: AQHSnauR8sIuzui9AkeB/6DkSo5/yqGV5dqAgABeZQCAAM4UgIAAAraAgAAFZICAAAFwAIAADPwAgABUtYCAACD3AA== Date: Thu, 16 Mar 2017 19:49:45 +0000 Message-ID: References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> <20170316135145.GB23450@elstar.local> In-Reply-To: <20170316135145.GB23450@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:gD42ksr4VplAWf1SdaqAJmRf9y5SVYJC++iaenhRnkVJKWoHKtIZ2ET97nrjt61AAWKi58B13ABRrOJ5Bp9MoBUllHXCyuGw33Y+icluxZ012+Gxapt7W9wWoic2Mx7toTOyEnTOrobCmukU0rZLOqN2gbShuxId9izzvk1kfF61SOEB7PIu5nD1UR9INiuHyERp/D5XF3CW+yC85dPSXZgiJozcG62AItMaER5MP6GZmSi4PkYueemjHCokSOFy16uzy7+TEdTfW3cheDx4VogZeg9/E7RjFvsxffAmAReThtiCeP1R8bRV8PuXBCcO/qsqDy/TXM/TzbBNqi6r9Q== x-ms-office365-filtering-correlation-id: 1ba02319-199f-41cc-1b69-08d46ca598ba x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(25786008)(2900100001)(3660700001)(38730400002)(110136004)(3280700002)(54906002)(53936002)(6246003)(99286003)(2950100002)(7736002)(54356999)(76176999)(102836003)(50986999)(6116002)(6916009)(36756003)(66066001)(5660300001)(6436002)(305945005)(15650500001)(33656002)(4326008)(8936002)(8676002)(81166006)(93886004)(6512007)(229853002)(86362001)(2906002)(83506001)(189998001)(6506006)(6486002)(122556002)(4001350100001)(77096006)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 16 Mar 2017 19:49:45.2458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 19:49:48 -0000 DQoNCj4+IDEpIGRyaWxsaW5nIGRvd24gb24gdGhlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgTkMv UkMgcHJvdG9jb2xzDQo+PiAgICBpcyBzb21ld2hhdCBtaXNzaW5nIHRoZSBwb2ludC4gIFRoZSBp bXBvcnRhbnQgYml0IGlzIHRoYXQNCj4+ICAgICphbGwqIHByb3RvY29scyB0cmFuc3BvcnRpbmcg WUFORy1tb2RlbGVkIGRhdGEgKm9ubHkqIGhhdmUNCj4+ICAgIHNlY3VyZSB0cmFuc3BvcnQgbGF5 ZXJzLiAgTW9yZSBzcGVjaWZpY2FsbHksIFlBTkctbW9kZWxlZA0KPj4gICAgZGF0YSBtYXkgYmUg dHJhbnNwb3J0ZWQgb3ZlciBvdGhlciBwcm90b2NvbHMgKGUuZy4sIGNvYXApLA0KPj4gICAgYW5k IGFsc28gYSBwcm90b2NvbHMgbWlnaHQgaGF2ZSBhbiBpbnNlY3VyZSB0cmFuc3BvcnQNCj4+ICAg IHByb3RvY29sIChlLmcuLCBpdCBkb2Vzbid0IG11Y2ggaGVscCB0byB0YWxrIGFib3V0IEhUVFBT DQo+PiAgICBiZWluZyBtYW5kYXRvcnktdG8taW1wbGVtZW50IGlmIFJFU1RDT05GIGFsbG93ZWQg SFRUUCkuDQo+DQo+IFJFU1RDT05GIHNheXMgTVVTVCB1c2UgVExTLiBNYWtpbmcgYW4gb3BlbiBl bmRlZCBzdGF0ZW1lbnQgYWJvdXQNCj4gc2VjdXJpdHkgcHJvcGVydGllcyBvZiB1bmtub3duIHBy b3RvY29scyBzb3VuZHMgcmlza3kuDQoNCkkgd2Fzbid0IHRyeWluZyB0byBtYWtlIGFuZCBvcGVu LWVuZGVkIHN0YXRlbWVudCwgb3IgZXZlbiBhbg0KYXNzdW1wdGlvbiBhYm91dCB0aG9zZSBwcm90 b2NvbHMuICBJIHdhcyB0cnlpbmcgdG8gc2F5IHRoYXQgMSkNCkJlbm9pdCdzIHRleHQgZ29lcyBp bnRvIHRoZSB3ZWVkcyB0YWxraW5nIGFib3V0IG1hbmRhdG9yeSB0bw0KaW1wbGVtZW50IGFzcGVj dHMgb2YgYSBjb3VwbGUgc3BlY2lmaWMgcHJvdG9jb2xzIGFuZCAyKSB0aGUgDQp0ZXh0IHNob3Vs ZCBpbnN0ZWFkIG1ha2UgZ2VuZXJhbCBzdGF0ZW1lbnRzIGFib3V0IHRoZSANCmV4cGVjdGF0aW9u cyBvZiBwcm90b2NvbHMgdHJhbnNwb3J0aW5nIHRoZSBZQU5HLW1vZGVsZWQgZGF0YS4NCk9mIGNv dXJzZSwgaWYgYSBwcm90b2NvbCBzZW5kcyBkYXRhIGluIHRoZSBjbGVhciBvciBkb2Vzbid0DQpy ZXF1aXJlIG11dHVhbCBhdXRoZW50aWNhdGlvbiwgdGhlbiB0aGUgZW50aXJlIFNlY3VyaXR5IA0K Q29uc2lkZXJhdGlvbiBpcyBhIHNvbWV3aGF0IHBvaW50bGVzcyByZWFkLg0KDQpLLiAgLy8gY29u dHJpYnV0b3INCg0KDQoNCg== From nobody Thu Mar 16 13:09:12 2017 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 AC5AB129A41; Thu, 16 Mar 2017 13:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 zJ58v83wIHhk; Thu, 16 Mar 2017 13:09:04 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0132.outbound.protection.outlook.com [104.47.37.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727A7129A2F; Thu, 16 Mar 2017 13:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q+Ve8m/M8+pDm/3Qz7ouyqSBADmMvC6r3sSufprw2qs=; b=ElBMCjnOALl+G2e+/aeG75SqE29TdIg03T3kR3ZlPZXaxdYdkrhfE4rVBZiIuU1T7/5mx52D48oxWvATElWaSKmfXTIvQgbQB896Zyuq4ngxN3OyeURKFMbzHudNpm1DDBaFfENm/VoZnBaV/0idpkfFQq7gpE4eQIMD5kanSs0= Received: from SN1PR0501CA0011.namprd05.prod.outlook.com (10.163.126.149) by CY1PR0501MB1755.namprd05.prod.outlook.com (10.163.140.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Thu, 16 Mar 2017 20:09:02 +0000 Received: from BY2FFO11FD004.protection.gbl (2a01:111:f400:7c0c::142) by SN1PR0501CA0011.outlook.office365.com (2a01:111:e400:52fe::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4 via Frontend Transport; Thu, 16 Mar 2017 20:09:01 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.961.10 via Frontend Transport; Thu, 16 Mar 2017 20:09:01 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 16 Mar 2017 13:09:01 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v2GK8xbi012555; Thu, 16 Mar 2017 13:09:00 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v2GK4uKV004163; Thu, 16 Mar 2017 16:04:56 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201703162004.v2GK4uKV004163@idle.juniper.net> To: Kent Watsen CC: Benoit Claise , "netmod@ietf.org" , "sec-ads@ietf.org" In-Reply-To: <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> Date: Thu, 16 Mar 2017 16:04:55 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(2980300002)(377454003)(199003)(189002)(24454002)(9170700003)(189998001)(8676002)(8936002)(86362001)(5660300001)(105596002)(81166006)(1076002)(38730400002)(561944003)(47776003)(76506005)(6862004)(53416004)(110136004)(6246003)(106466001)(15650500001)(2950100002)(50986999)(305945005)(2906002)(54356999)(50466002)(2810700001)(54906002)(7126002)(77096006)(6636002)(4326008)(8276002)(53936002)(7696004)(6306002)(5003940100001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1755; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD004; 1:wOmQnyhOVe6ZGhscIJc25b8NevFbPQ1ruJmUZD9TnDuF3DTBJVIpxW2Ev4Xbf5wk6h9I+q0bRa9bZSnbOYOk79UFzC9DwyFeoEe+KJQtPk5G6J+CjANMmmgE/C14TF37OFEF7NjtCKj0KeOlxwapIk7x8RRlhe8pzTja2qg66GVczU8BY1hKkO70RZj+s8DqzNQxtKuw7Gclz3aAjzbbcf43HgFriq6kJOYEy/cq3Xqn+M7xuKr2Bu5pX+MZK0WKKEXJm0BLsB+9URi0vjWznmxffD4CofkmGx0Z2du4y8TeHA3UHbrAJw/IKktD464UPry7b+F4hXwxxgCLWuiwJSIzbpdKAgwurbmB6rgRtLAK6xstdEO8DpuUerpwJx0R9rVl9Z0ciep4DYrtuNokdI9wOhJk1VTZgkGxm7KWka7LcE8JN2WFv4e4zj0+OC3NjGazVYXXEKbR6N7UKwqBu9JsktLQMOF8NTnNbNuZMoYJAF8Nu0fbkPwaEWNrk206rGPRoNJwB+5ftxDYlJyYd/g5VaS3DkCbOZeZepl1ioV646jh6uTiI3o1gxMd+TtRHhAY6oDpuuC6sg3vrxghCYOhcTTd1BLvbxUpYSGeTlk= X-MS-Office365-Filtering-Correlation-Id: 61ac024c-ee15-439a-4b89-08d46ca84a06 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254037); SRVR:CY1PR0501MB1755; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1755; 3:sZHt0TaYqzOBj3OjEpcLZxdnFnM5o4w8pTLvrFl5gDsnStv2pDZx5RAcMjqCN7PGCDq1uPEpkXDZEbDn9H/HZBskISzhqepRtm7GtTwJRkEPVSUSY5cgeanwIGMXu/XEb2Bq9VStc1xJ8jRTcp3NSHSaetv9qtJrXlSg+IvdAumvT0pAmU0XlX1UXJLfVs6BcGmOh5cV2XVvCNLKaai9IBQNWohg8gQxASw03Q07/LhkIPrSWstDzwS6jdYQJ7blPNVEqzreDxRmJusEI4WdkEjXEIZsLxgTAJwpnOn0XRQ3zgL9g2bd8nV4hBi33q8UfjxmetmEns9HHLfzgwesJ7k8/Ens6VdoqBn8xA9KxJ0blhk/5R9PEv+ZabMhzu+4zcGiBIxNOhgwA7lh90dTlg==; 25:WSqZApaPdS+S0lw7O23+9V61QczMFPUjo9eqVkc/5R2ttQ9MAn5tfucgppoBWa0iNpcU7JFNkLd2lCcJ/bBcIhwOohRXcCM/2ndeNQXnG4RjwMTMJ4y38g6ScGVcVl0ZIGe7AKI+F/521+9ty+OosIn/graLX6eDjoEaedNFDpu1SGDww19xnaEEispmRj1wIlYilF7GywIqFN8SK/TSqQtwVr9p4JzhFWrEcjQApfaTqeCSx07R2ANsCcELAn689OBT/luhPec8iCmbt51JFt3Fy1Wwyeehr4p8kdrvVAaF2igyBXASUo89Rh0OlsfPstrSfce49sh5+TWaAipSkBzcotAdIiS5crPMEqxCuZhAvraR6lelK6MTA31lAX5v5S/nL54i9LTphEVl8ryvn5Soe2PMh7zXXMiX6lYojyenCuugcjwAF78z0EiaN2ee75l/WwdBIIFI4Vtv4IQ4BQ== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1755; 31:aFLxyeviWfVze6trgcusijULD4r25Opb6zrEnICiafItzJK6b87DrcqZbWcsB54og4GfQGzJ1L7reYs1OP+C+wpsUvLV8ZpVMX6Sb9AEZQf+8EIcaV39nBtHcT5oYOsEARFRRF8d9C6BvoIqdrx8IwhmZoL8VNjc6m0fmQXjstFYrnFkApQ2omc7HIXO1KHtYAVzdPaBxw+6VgFMivP6zNI0Jo9eLG5/EgMjmlXZ+2wegsuRvAH44qEoyBFIoJ1YENFWx52kLpKJJxux9MtK6Q==; 20:PwlbX9B2zHLi/cLT0LqaDz3NCKgaQ+dG7ZpuAGJmk3UUdfc0tyT2/3q5qNtM1zCORHxYY+CJmcAQ5diX0KvdMMlxBO94z7Gabc2Q80YJPEBCCFHXu4kyBxoLKOo0LJ9yIsH+uvx5qdx5XDWAFBUD9Ul/HBSFNrw5u5eQ/laaabPQh2uyKQMw7dnsfXQr484vNuwfsqXZDdZRMvEqB9RaE+KM1W/b5C4bO0VTZyNWW55dJ7GFW2dpT8n9lEUqW33Nz4YRkfbLd4h18dzpi4HtZUiS5zDW1fjtDtGpuq1mXY+QyKwxFkcAlv3zcnvBoSTeU0nNYg5oWBSNYc8TNO+knfd4GtslTta4Rk72SvKFdGi/CoKEPcj30cBBTLZHwMqmJ1sFiSTfx2fvV/ZAbqkfU4to1sCWBiv2kiif66sOxjStDXFiC58ObLS3GqP57yACYjGpaI4uMs7OMq3PGBs2jt+UHF76QgKpnAhUVSZ/0cj1/H0Eli7RWkaq3AU/Uw8x X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(13024025)(13023025)(13017025)(13015025)(5005006)(13018025)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123558025)(20161123560025)(20161123555025)(6072148); SRVR:CY1PR0501MB1755; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1755; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1755; 4:8OFMZ3uuT6EyF29Ah4Ok1Ml5zTXzRfUU9rq7/hMSGkKpUDC9b2WCjK6xJWxGzzuc/5KEYKN6tArWPZLyKZcT90sfjcJf7ShxGQ6GH4d/Op7ORvn1HK+mIpTDWA6P73LgQznvLwLWrHDWT2XFNhh8Mg2/7ls2SpagiOeygNAgXCLlTe8L0Jjep7kjeQyDEpP49RQOj4MaAYye+wjfL8pCccZefirnB1R2C9xt1qhApw7grUJ9FfMrvujgl9CiNPn2Oqyh2vJ5RXKX+tX99gGdfIzU19U6ZZD9R1U+U4y8tYyrZW4UC++QCn9xA+2gdxP4Bk8CJcSo8n9xmPAefUR8nf3AQhGnhXZE1Xc0rWcp0rkbxVnWiZuWib2YD9MLwTXPMlx9DCZ0jyvEq28ekzvnPtEwzQIur0XZetBZUi9YvP5wK+jeIXKVdi4cGKDMG+PGF/wbZtul0oNRMc4DxmjzveRWUoDD4ZhWxHNL+ttTnqKYr/TrvKxs4UyqoWDLOLo0U/ZnwgBqehHOVPVSs88PzaJinFeRiizOdBBTrhlmbC9irdtOQ5GeSruT2d1h1a7NlipNvUIb+myCM5kr+Znmru/AMuVnlPUrEKGy947qKp2gggiyvZ13h00oVg18ag+jwcDLh5dM8GDHgiIDgWagRbfJMDr2kY/cL2ugmQYXJ07h5UdltdKJbVYq8qrFanvEYbYsdRrw/H/u3637JzajuSl/4f4hfpJ/19kwnTeOP6cmNg26n5i6r8OI3A/gQlv66po6DF2NLb55vYQy2UUON4m4hURaQpLxh/2PBGyPYk4= X-Forefront-PRVS: 024847EE92 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1755; 23:DQw68WVR+6GFDFOIhPWqUbiTu5NgFFnVREAyF+V?= =?us-ascii?Q?mZfnZ+GVa8X2QQDO+iQygoeOEYRvW2gMJhRYUk/mRoSrC0uFZM7VvqPAdV47?= =?us-ascii?Q?BNOG9NZI544VJECrmSwuRU4v1Leo9EwVn7m0Zmv5YKuagrCgyc/nqUoMmKf3?= =?us-ascii?Q?qpfYkxSSJJaivBzzMvnu9Jwgu70AbRWh+zuIVfKnlAwoAeJ1qjN0SjqlNHEL?= =?us-ascii?Q?nm0VtiwrPnfs6gZW179E2yuiP6rsjK7AunlO6M4vBMYzNK8djfjp748g+rP7?= =?us-ascii?Q?VrjVh1ocX6d5PS9Ndnu65/ga0mNviXShHGQxOt41gmSc5b9B5u9efPvJJUg2?= =?us-ascii?Q?NtEzgjGKiMvn/s5p9VCZTqJWuxvG6HCepM1COqP4ckmKbZWboTz6OvCBwZgY?= =?us-ascii?Q?qDlo8brmM5IPhsB/ioXRRcx3k87PHDAU1pYk3+VhoOYINFKimHtvFY8WGaxJ?= =?us-ascii?Q?MhU0DqDyvyYhLXEciU1IVKPK6PtAPfrAje8XIZ530LzuxDvT0il2fJK4L0Pv?= =?us-ascii?Q?qbBxE9oGJFbiqW1L8xt8xuwgN475LwSxPwDP0tySX8bn46CqvD+eniVa5iNT?= =?us-ascii?Q?4kgkPrEPGVk9Cl3+Dv8MqDDwgRPb5Rqbo5W/0C7e5aknDE5Lh5W7xphcQVOb?= =?us-ascii?Q?slZCZAkzW4JgDLkfvA/HS6GdioTckMnIVP/cknIhVfhHx8fx9A45JRHUypAc?= =?us-ascii?Q?gzRyU4NLQ6KpYaXb63KF4xWHSFcIZc8EAS15sAqRpPfAHYEIeqm5f7GETH3a?= =?us-ascii?Q?qxKonT0DfMf7j98ZxcnLoqxAOhnihMk1Ogfi+aCpGkPSpak9lp31i83HkIGt?= =?us-ascii?Q?tw0eFd9j86QB6KhgK8soyyQ2Ercthj5hdWvlL46x79w5/+DXe3mydjlLGBJP?= =?us-ascii?Q?CO2DAEX/EXWdWDKM++34TWHWxERCtHMoRoEvcvuACdGiiUsXoCuYfQQ3CMF+?= =?us-ascii?Q?q0f+tPWLTchqdPdHASI0NiG2X2pThxcPG/V8SflQQDm9Zl/oo+YFTkuozI+5?= =?us-ascii?Q?B5ete/CbaIHL9parqy+XhbKbqChDuaOL8qsa8CVh5yHEsdLnQPfqWOWaFyDk?= =?us-ascii?Q?OMwVR4CuJpVkPT8LKU+qg3W84Oa1ztMIy6UWWxg7YsdNS/1YHj7dNpvN+Qq+?= =?us-ascii?Q?+4SG25LjNJABy69zeQZC6VaJbrZNAw9bj?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1755; 6:94iUcJA2zFDNJxmOhoE26L+jhJplbYeucnc3Taiy8mi1axvCM6BSn0Qv7AwBG9NluM+PNZZcHnqmQb86NsL3orRdbg37E3G7cVhPHg/yKmmOpaolLq//e8PlKWrPCGXKzXh9xN5Lt6fG2my4I1fSJuPLf8qMjGZQGznbjOcOGSQ74ckyNYlBbjx+z+dFsuZOh31kTS/F1q+hyw/LDbOcVBIXXzpoSBAHuYF0hI30s6hMUmlT5CoZajLOysGFUIgTSHC63R6JWoLHqW5L8sN5x551kQZWdsgmfz0z4htbgdKqOv8kigUEp3k3TTb/QmlknPjmdM10o8Sy/Wf8pknE8UMJKltFzcEZAJkvEZ6j2hIMbb82DWYsiYjdpn0/YQdVUQPNq31eHGf+Q3zWXjEPfQrHey19HRVatpcOTqFEPkQ=; 5:ccxHIi8/0ZywCPgwxBD72Oq71nh3lZSdoS8pqhCs812UqpOnJrL9mUbfdlMdRAgGfRIE2sbo2yY8bi7JdA0QuqCW/CzClLfu1oZnRrWSa5jJaZ54T9uZlD7mWDrfZ0yLd/cUXyNA5r8WiqHb02gKwA==; 24:iBQhix3SMg9tI2QnCV57XE1G6wrjYCJ5mudQ+CEDdFsPBlVBiMJ828NTdlICZUWhVglCRrj973EMyDbSb4XbBZ4l4E1wJBjLKo0hg0dM8m8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1755; 7:8M9Qlv1z83ULNsMMlm5IqvET+6bE6a91uI9jP8UrbDFcLKRK6wRYxfAHlCrqeSYGdnigPcaG05D9oGYY0nL0dqjgNlQ6Nxrpqe3/7+kTvRoL+23pTVpOw/XU4KNI45PNWp68OvZOuinUGN4CoDMw3535/yYsOxeHvEdTPXPqG8Cw87YdRgtng9ucgshsPVLNTEdf9xFc9nyypt3D19Bvg70YcLWxYJ0wgb/vDI/diSSlSLLFNOcL26bfozFr3pWfsOB0uN19zBFwQoQgEyar7yb99czPRg9u58LxQfxBDZTvdXf7dMdAGXLq0ifSJuN0dQ+FyqkHC8VzRZ66UZt3qQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2017 20:09:01.6130 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1755 Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 20:09:07 -0000 The considerations should say more about how we delegate encryption and authentication to the underlaying protocols, whatever they may be. We don't need details, just an understanding of the role of each layer. Thanks, Phil Kent Watsen writes: > >A couple comments: > >1) drilling down on the mandatory-to-implement NC/RC protocols > is somewhat missing the point. The important bit is that > *all* protocols transporting YANG-modeled data *only* have > secure transport layers. More specifically, YANG-modeled > data may be transported over other protocols (e.g., coap), > and also one of the protocols have an insecure transport > protocol (e.g., it doesn't much help to talk about HTTPS > being mandatory-to-implement if RESTCONF allowed HTTP). > >2) just stating that there are secure transport layers still > isn’t sufficient, as these protocols must also require > mutual authentication in order to be secure, and for > statements regarding NACM to make sense. The text I posted > before had a statement like this in it. > >I'm beginning to become a fan of the idea of defining a generic >"Requirements for Protocols Transporting YANG-modeled Data" >document - that would not only discuss security aspects, but >also generic protocol operations, that documents like NC, RC, >CoAP, etc. can point to...and even YANG (RFC 7950), rather than >pointing directly at NETCONF as it does today... > >Kent // contributor > > >On 3/16/2017 8:56 AM, Juergen Schoenwaelder wrote: >> On Thu, Mar 16, 2017 at 08:37:39AM +0100, Benoit Claise wrote: >>> Latest proposal: >>> >>> The YANG module defined in this document is designed to be accessed >>> via network management protocols such as NETCONF [RFC6241] or >>> RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport >>> layer, >>> and mandatory-to-implement secure transport is Secure Shell (SSH) >>> [RFC6242], >>> while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement >>> secure >>> transport is Transport Layer Security (TLS) [RFC5246]. >> Picking wording from Section 12 of RFC 8040 to replace your second >> sentence I get this: >> >> The YANG module defined in this document is designed to be >> accessed via network management protocols such as NETCONF >> [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the >> secure transport layer, and the mandatory-to-implement secure >> transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF >> layer is HTTPS, and the mandatory-to-implement secure transport is >> TLS [RFC5246]. >> >> The NETCONF access control model [RFC6536] provides the means to >> restrict access for particular NETCONF or RESTCONF users to a >> pre-configured subset of all available NETCONF or RESTCONF >> protocol operations and content. >Yes, thank you. > >Regards, B. >> >> /js >> > > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Mar 16 14:52:31 2017 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 E97CE129ABD for ; Thu, 16 Mar 2017 14:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13A3eNj1rHD7 for ; Thu, 16 Mar 2017 14:52:26 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id F2FCD129AB7 for ; Thu, 16 Mar 2017 14:52:25 -0700 (PDT) Received: (qmail 14484 invoked by uid 0); 16 Mar 2017 21:52:23 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 16 Mar 2017 21:52:23 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id wlsL1u0092SSUrH01lsPhm; Thu, 16 Mar 2017 15:52:23 -0600 X-Authority-Analysis: v=2.1 cv=R4+QR7hX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=wU2YTnxGAAAA:8 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=pGLkceISAAAA:8 a=xcTfSnc4AAAA:8 a=i0EeH86SAAAA:8 a=4MpHeDZdjMi4cHXfiloA:9 a=YKdk1Sg7XhWOeCST:21 a=1gaz9vBfT6dckGR0:21 a=pILNOxqGKmIA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=cAcMbU7R10T-QSRYIcO_:22 a=w1C3t2QeGrPiZgrLijVG:22 a=TSZmLRzkpGLBZRr3r8m8:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=AlSe2FwLBhvzWS46gZ1m:22 a=02toJ7V-nxh73JlV0Smw:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=w2xeodyG7BBJDUR9sVNdTnTfYisHEFc9Hzq95xIga8s=; b=HEE0KUv2QWWrQ3RhS0s8cLmrsf AI6+G21lQJm4raQ9CM+Et0c591JdPBVgtEA9GIKhytlev5gvxV/GbHoy17t3UYOGTITceEZpac/VS Ffxj9VpGwhzFa4HY+J3tyCITT; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:56758 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1codJe-0004x8-QW; Thu, 16 Mar 2017 15:52:20 -0600 To: Mehmet Ersue , 'Kent Watsen' , netmod@ietf.org References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <675654fd-1532-1755-621c-a3ecb06950e3@labn.net> <025a01d29e82$8549d070$8fdd7150$@gmail.com> From: Lou Berger Message-ID: Date: Thu, 16 Mar 2017 17:51:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <025a01d29e82$8549d070$8fdd7150$@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1codJe-0004x8-QW X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:56758 X-Source-Auth: lberger@labn.net X-Email-Count: 13 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 21:52:30 -0000 Mehmet, see below. On 3/16/2017 2:24 PM, Mehmet Ersue wrote: > Lou, > >> Mehmet, >> >> On 03/15/2017 09:50 AM, Mehmet Ersue wrote: >>> Hi Lou, Kent, >>> >>> it appears to me the issues I raised below are not closed. >> it wasn't clear from your mail that a response was needed as it seemed to > be >> covering points otherwise discussed, and where we may not agree. >> It's good that you are re-raising them now. >> >>> I believe at least a "minimal" WG item focus formulation is required >>> to match to the high-level WG focus topics in a)-f). I was thinking my >>> proposal below is acceptable. >>> >> I think we disagree on this point. That said, perhaps our objection is in > the >> abstract and not the specific. Can you propose specific text change you'd > like >> to see made to the charter and we can discuss it? > I believe IETF WG charters need to be defined for a particular period of > time with a specific target for development. > The current charter proposal seems to provide a high-level WG focus > definition without time limits. > I think the WG items to develop in the planned time period need to be > defined at least minimally, at least as an indication. > This is the basis for me as a WG member by which I agree or object to the > approval of a charter proposal for the planned development period. > > I actually provided a very simple proposal. You guys can fill the idea with > minimal text better than me. I'm fine whatever the text is. > If you think the high-level topic description a)-f) does already define the > WG item clearly you can simply say "this is achieved with WG item XY". > If not, you can keep the high-level focus text but set additionally the > borders of the WG item with a few concrete words. I really can't tell for sure, but it feels to me that this comment boils down to a style comment and you have a preference for different contents in the charter. I'd like to be sensitive to this. As our style differs, having a concrete proposal on specific text changes would be really helpful in us (and the WG) evaluating the changes you'd like to see. Without such specific examples and think we're left with the charter as currently proposed. Perhaps someone else who has similar feelings can chime in and provide proposed text. Anyone else have any comments or proposed changes? >>> Netconf WG will ensure avoiding double-work concerning the DS concept >>> draft, however Netconf needs to specify what is required for the use >>> of the DS concept from protocol standards pov. >> okay. I think we agree that the protocol aspects belong in NetConf - and >> we're expecting those to be covered during the NetConf WG session in >> Chicago. >> >>> That said different people including Netconf WG co-chairs think the DS >>> concept document is Informational in nature and should be published as >>> an Informational concept to be used in and adopted for the needs in >>> diverse protocol WGs. >> okay. > I'm not sure whether your "okay" means the same as I meant. it meant, "Okay, I heard you." I've already responded to this comment multiple times so didn't think it would add anything to say it again. > I think the DS draft provides a conceptual framework for diverse DS usage > scenarios to be used by many protocols, where IETF WGs may actually decide > using a subset of the DS framework for their purpose and for their protocol > standardization. > Based on this the conceptual framework cannot be standardized as it is but > the protocols using a consistent subset have to be standardized. > Following this consideration I think the intended status of the DS draft > should be changed to: Informational RFC > If you agree please indicate this change accordingly. I think Juergen's reply to your previous message highlights that there is a difference of opinion here based on the technical specifics of the draft. My position as chair is that I'll support whatever makes sense based on the document produced by the WG. Today the document authors believe PS is appropriate, once we have a version that is stabilizing for LC -- which hopefully will be the next version or two -- then will be a good time to revisit this. >>> This is as I think also important to avoid an overlapping between >>> NETCONF and NETMOD charters. >> I don't follow this point. Certainly I'd hope that the protocol impact of >> revised DS are covered in a PS document, unless for some reason there are >> no "on-the-wire" changes needed. TI wouldn't expect that the document >> status of the base revised data store document would impact that. Do you? >> If so, how? > My comment is actually superfluous if you agree with my considerations > above. > The worst case would in my opinion happen if the DS conceptual framework > covering many high-level DS usage scenarios would be attempted to > standardize, which at the end would prescribe protocol WGs what they should > be standardizing. Yang presumes a certain set of functions for the protocols it operates over. I'm not sure why having a document that specifies this would be an issue. > In such a case the conceptual framework would most likely cause a competing > situation with protocol WG's goals and documents and cannot be adopted > successfully. If a protocol doesn't provide full support for yang (requirements) it can't fully support all yang features. If your point is that when NetMod changes basic yang functions/operations that this might constrain the protocols (and related WGs) over which it operates, then I agree that this is the case. How could it be otherwise? Thanks, Lou > Thanks, > Mehmet > >>> PS: I expect that most of the Netconf WG member read also the Netmod >>> maillist and therefor skip sending to both ML. >>> >> Great. >> >> Thanks. >> Lou >>> Thanks, >>> Mehmet >>> >>>> -----Original Message----- >>>> From: Mehmet Ersue >>>> Sent: Thursday, March 9, 2017 7:36 PM >>>> To: Lou Berger ; 'Kent Watsen' >>>> ; netmod@ietf.org >>>> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' >>>> >>>> Subject: RE: [netmod] draft netmod charter update proposal >>>> >>>> Hi Lou, >>>> >>>>> The charters from the last couple of years don't have the intended >>> status -- >>>> at least the ones we checked. >>>>> I actually feel pretty strongly about this (which of course can be >>>>> easily overruled by our AD). It's my experience that premature >>>>> discussions on intended status, i.e., before a document is >>>>> sufficiently >>>> mature, leads to process-focused arguments that detracts from making >>>> technical progress. While once a document is mature and core >>>> direction/content is fixed, it is generally obvious what status is >>> appropriate. >>>> The charters from the last couple of years have a short WG item >>> definition, >>>> which would be IMO sufficient. >>>> You are right the intended status is not available since a few years, >>>> but >>> IMO it >>>> is part of the target definition and would be very useful for the >>>> draft >>> authors >>>> and WG members to regard. >>>> >>>>>> It would be good to bring the high-level topics in relation to the >>>>>> WG >>>> items. >>>>> I'm sorry, I don't understand this last sentence can you rephrase it? >>>> What I meant is that the high-level topics a)-f) might be good as WG >>>> focus description but are not sufficient as draft target definition. >>>> If you think the high-level topic description is more or less the WG >>>> item definition, then we could simply write "this is achieved with WG > item >> XY". >>>> If not, we could keep the high-level focus text but set additionally >>>> the borders of the WG item with some concrete words. >>>> >>>>>> BTW: We agreed in diverse discussions that the DS concept is >>>> Informational in nature. >>>>>> I think this should be corrected in the draft. >>>>> So this sounds like an objection to a specific document. This is a >>>>> fair point to raise, but in our opinion it is not a charter >>>>> impacting point or discussion. If this is in fact the issue you'd >>>>> like to raise and discuss, lets do so under a document specific >>>>> thread, e.g., >>> "Subject: >>>> intended status of revised-datastore". >>>> >>>> I am actually raising this point since November meeting. There are >>> different >>>> threads where I explained why it is appropriate as Informational. >>>> The last thread I remember is at: >>>> >> https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH1 >>>> 1xcY >>>> The recent position of NETCONF co-chairs is in >>>> >> https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd >>>> 8qr5k >>>> >>>> Thank you for your consideration. >>>> >>>> Regards, >>>> Mehmet >>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Wednesday, March 8, 2017 11:28 PM >>>>> To: Mehmet Ersue ; 'Kent Watsen' >>>>> ; netmod@ietf.org >>>>> Subject: Re: [netmod] draft netmod charter update proposal >>>>> >>>>> Hi Mehmet, >>>>> >>>>> On 3/8/2017 4:47 PM, Mehmet Ersue wrote: >>>>>> Kent, >>>>>> >>>>>>> we understand that this is how NETCONF charters are structured, >>>>>>> but it is not our practice, >>>>>> AFAIK it was the NETMOD practice for the charters until today. >>>>> The charters from the last couple of years don't have the intended >>>>> status -- at least the ones we checked. >>>>> >>>>> I actually feel pretty strongly about this (which of course can be >>>>> easily overruled by our AD). It's my experience that premature >>>>> discussions on intended status, i.e., before a document is >>>>> sufficiently mature, leads to process-focused arguments that >>>>> detracts >>> from >>>> making technical progress. >>>>> While once a document is mature and core direction/content is fixed, >>>>> it is generally obvious what status is appropriate. >>>>> >>>>> >>>>>> I did not ask >>>>>> more than written in the current charter. >>>>>> It would be good to bring the high-level topics in relation to the >>>>>> WG >>>> items. >>>>> I'm sorry, I don't understand this last sentence can you rephrase it? >>>>> >>>>>>> as the information is available at the top of each draft, and also >>>>>>> because >>>>> this information need not be fixed when the milestone is added. >>>>> >>>>>> I believe a WG charter should be self-sufficient covering the >>>>>> target definition and intended status of the WG items. >>>>>> Otherwise one can change the target for a WG item by simply editing >>>>>> the draft abstract anytime. >>>>> Per IETF process, all it ever takes to make a change in document >>>>> status is WG consensus, and then IESG and IETF buy-in as part of the >>>> publication process. >>>>>> BTW: We agreed in diverse discussions that the DS concept is >>>>>> Informational in nature. >>>>>> I think this should be corrected in the draft. >>>>> So this sounds like an objection to a specific document. This is a >>>>> fair point to raise, but in our opinion it is not a charter >>>>> impacting point or discussion. If this is in fact the issue you'd >>>>> like to raise and discuss, lets do so under a document specific >>>>> thread, e.g., >>> "Subject: >>>>> intended status of revised-datastore". >>>>> >>>>> Thanks, >>>>> Lou >>>>> >>>>>> Mehmet >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent >>>>>>> Watsen >>>>>>> Sent: Wednesday, March 8, 2017 7:45 PM >>>>>>> To: netmod@ietf.org >>>>>>> Cc: netmod-chairs@ietf.org >>>>>>> Subject: Re: [netmod] draft netmod charter update proposal >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi NETMOD WG, >>>>>>> >>>>>>> Please find below draft-4 having the following change: >>>>>>> >>>>>>> - added "(e.g., I2RS, RTGWG)" to a sentence. >>>>>>> >>>>>>> Hi Sue, Lou and I looked at the proposed charter and found a >>>>>>> sentence that nicely describes our WG's intent to work with and >>>>>>> support other WGs (beyond NETCONF), but we felt that the text >>>>>>> could be made more clear by adding in the above-mentioned change. >>>>>>> Beyond this, and the existing a), >>>>>> b), >>>>>>> and c), we believe that the charter proposal covers our support >>>>>>> for I2RS, >>>>>> do >>>>>>> you agree? >>>>>>> >>>>>>> Hi Mehmet, regarding putting a short description and the intended >>>>>>> status >>>>>> for >>>>>>> each draft into the charter, we understand that this is how >>>>>>> NETCONF >>>>>> charters >>>>>>> are structured, but it is not our practice, as the information is >>>>>> available at the >>>>>>> top of each draft, and also because this information need not be >>>>>>> fixed >>>>>> when >>>>>>> the milestone is added. >>>>>>> >>>>>>> All, Any other comments? >>>>>>> >>>>>>> Kent >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Network Modeling (NETMOD) >>>>>>> ------------------------- >>>>>>> >>>>>>> Charter >>>>>>> >>>>>>> Current Status: Active >>>>>>> >>>>>>> Chairs: >>>>>>> Lou Berger >>>>>>> Kent Watsen >>>>>>> >>>>>>> Operations and Management Area Directors: >>>>>>> Benoit Claise >>>>>>> Joel Jaeggli >>>>>>> >>>>>>> Operations and Management Area Advisor: >>>>>>> Benoit Claise >>>>>>> >>>>>>> Secretary: >>>>>>> Zitao (Michael) Wang >>>>>>> >>>>>>> Mailing Lists: >>>>>>> General Discussion: netmod@ietf.org >>>>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/netmod >>>>>>> Archive: >>> https://mailarchive.ietf.org/arch/browse/netmod/ >>>>>>> Description of Working Group: >>>>>>> >>>>>>> The Network Modeling (NETMOD) working group is responsible for >>>>>>> the YANG >>>>>>> data modeling language, and guidelines for developing YANG >> models. >>>>> The >>>>>>> NETMOD working group addresses general topics related to the >>>>>>> use of >>>>> the >>>>>>> YANG language and YANG models, for example, the mapping of >> YANG >>>>>>> modeled >>>>>>> data into various encodings. Finally, the NETMOD working group >>>>>>> also defines core YANG models used as basic YANG building >>>>>>> blocks, >>>> and >>>>>>> YANG models that do not otherwise fall under the charter of any >>> other >>>>>>> IETF working group. >>>>>>> >>>>>>> The NETMOD WG is responsible for: >>>>>>> >>>>>>> a) Maintaining the data modeling language YANG. This effort >>> entails >>>>>>> periodically updating the specification to address new >>> requirements >>>>>>> as they arise. >>>>>>> >>>>>>> b) Maintaining the guidelines for developing YANG models. This >>> effort >>>>>>> is primarily driven by updates made to the YANG specification. >>>>>>> >>>>>>> c) Maintaining a conceptual framework in which YANG models are >>>> used. >>>>>>> This effort entails describing the generic context that in > YANG >>>>>>> exists and how certain YANG statements interact in that >>> context. >>>>>>> An example of this is YANG's relationship with datastores. >>>>>>> >>>>>>> d) Maintaining encodings for YANG modeled data. This effort >>> entails >>>>>>> updating encodings already defined by the NETMOD working >>>>>>> (XML >>>> and >>>>>>> JSON) to accommodate changes to the YANG specification, and >>>>> defining >>>>>>> new encodings that are needed, and yet do not fall under the >>> charter >>>>>>> of any other active IETF working group. >>>>>>> >>>>>>> e) Maintaining YANG models used as basic YANG building blocks. >>> This >>>>>>> effort entails updating existing YANG models >>>>>>> (ietf-yang-types >>> and >>>>>>> ietf-inet-types) as needed, as well as defining additional >>>>>>> core >>> YANG >>>>>>> data models when necessary. >>>>>>> >>>>>>> f) Defining and maintaining YANG models that do not fall under > the >>>>>>> charter of any other active IETF working group. >>>>>>> >>>>>>> The NETMOD working group consults with the NETCONF working >>>> group >>>>> to >>>>>>> ensure that new requirements are understood and can be met by >> the >>>>>>> protocols (e.g., NETCONF and RESTCONF) developed within that >>>> working >>>>>>> group. The NETMOD working group coordinates with other working >>>>> groups >>>>>>> (e.g., I2RS, RTGWG) on possible extensions to YANG to address new >>>>>>> modeling requirements and, when needed, which group will run the >>>>>>> process on a specific model. >>>>>>> >>>>>>> The NETMOD working group does not serve as a review team for >>>> YANG >>>>>>> modules developed by other working groups. Instead, the YANG >>>>> doctors, >>>>>>> as organized by the OPS area director responsible for network >>>>>>> management, will act as advisors for other working groups and >>> provide >>>>>>> YANG reviews for the OPS area directors. >>>>>>> >>>>>>> Milestones: >>>>>>> >>>>>>> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for >>> publication >>>>>>> Mar 2017 - Submit draft-ietf-netmod-yang-model-classification >>>>>>> to >>> IESG >>>>>>> for publication >>>>>>> Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for >>> publication >>>>>>> Apr 2017 - Submit draft-ietf-netmod-entity to IESG for > publication >>>>>>> Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG for >>>>>> publication >>>>>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for >>>>>> publication >>>>>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to IESG > for >>>>>>> publication >>>>>>> Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for >>>>>>> publication >>>>>>> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG > for >>>>>>> publication >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 Mar 16 15:58:50 2017 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 E9267129B35 for ; Thu, 16 Mar 2017 15:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dEZyT2ZTKzPE for ; Thu, 16 Mar 2017 15:58:46 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 7C2BF129B42 for ; Thu, 16 Mar 2017 15:58:45 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id 196so6032382wmm.1 for ; Thu, 16 Mar 2017 15:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=hrfzF5QznJOhYuRAAGyte2klLBKpkIpPcCkx6Zf5To0=; b=ds5Mq4Ofj2TCbqex6HfIbIgcwKdoPWOFeyyXlH0dpQ4g5x6clEQ2tYqKFt19l1/8Dz /rwrQKCeHZ+3FzdOayyG/pBjlKAw+sXTDQg9QZ6c17ph3ewtrCADzWESG8J3aGQZ8fjm OWc1XwmELhbD05G6zmroQIPaIrx/IddF9oMo+yJvvj3+3GAN8Nd18g7MzWKJWiWbTgUH cemwmQ2sO04gGHvSOUdFXBpiGaTIy3d9QPHKTBsfjkxsW7JjNrNnldCn1i8f+Rvd0anu iNZNcbm3DNxxuaMVvYO6+EAl4i4PDCfYRvKcU4gkoNBxdcYBbWh8aLLn80UTi/DYZ8np i4vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=hrfzF5QznJOhYuRAAGyte2klLBKpkIpPcCkx6Zf5To0=; b=btUjvE/6KFjB6fFJf4p2GuFLW6PmUmIin7IphgDpdTpDs1xp1QkNI0b18AX2w4SupW 0OsG10UKAECvSZ96V+9lbk7jbaBjxh4fGkNpjyJg/Jik+ICgOEr6Xy4IbSVcwWGJzoTw G5dpZ7cUndOWfNjSAy2o0t5Wa0N7M43YvvOAXqN42G9IGV+Y+lULA0F+ylZutFls39mo DlcCe7XOOAnINsjC4eEoA+nxWvAEAKkkqFIWxuo54/LK50DtLQlgOXuTAq/sXVl+A5Ei gIU/G5YLv3Qff/6uI1d+oOp4NuoL4SlhEbJzARHp6Xir0FTOIPAVzLgrDKKLebmdeUEF RdcQ== X-Gm-Message-State: AFeK/H1qwZl67lhrzKq+JNakVh0kwXhflNl1/6t0r/jDHVTuaGWPfFjMVLnd/4XciNxv8Q== X-Received: by 10.28.20.70 with SMTP id 67mr148264wmu.86.1489705123901; Thu, 16 Mar 2017 15:58:43 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p5B341913.dip0.t-ipconnect.de. [91.52.25.19]) by smtp.gmail.com with ESMTPSA id p185sm513411wme.20.2017.03.16.15.58.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 15:58:43 -0700 (PDT) From: "Mehmet Ersue" To: "'Lou Berger'" , "'Kent Watsen'" , References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <675654fd-1532-1755-621c-a3ecb06950e3@labn.net> <025a01d29e82$8549d070$8fdd7150$@gmail.com> In-Reply-To: Date: Thu, 16 Mar 2017 23:58:44 +0100 Message-ID: <02bb01d29ea8$dd232cd0$97698670$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUooBvvnQPAGVQNXrAT+Tz94BQZmbIKCarq1A Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0206.58CB18A3.003B,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 22:58:49 -0000 > From: Lou Berger [mailto:lberger@labn.net] > Mehmet, > see below. > On 3/16/2017 2:24 PM, Mehmet Ersue wrote: > > Lou, . . . > > I actually provided a very simple proposal. You guys can fill the idea > > with minimal text better than me. I'm fine whatever the text is. > > If you think the high-level topic description a)-f) does already > > define the WG item clearly you can simply say "this is achieved with WG > item XY". > > If not, you can keep the high-level focus text but set additionally > > the borders of the WG item with a few concrete words. > > I really can't tell for sure, but it feels to me that this comment boils down to a > style comment and you have a preference for different contents in the > charter. I'd like to be sensitive to this. As our style differs, having a concrete > proposal on specific text changes would be really helpful in us (and the WG) > evaluating the changes you'd like to see. Without such specific examples and > think we're left with the charter as currently proposed. Perhaps someone > else who has similar feelings can chime in and provide proposed text. > > Anyone else have any comments or proposed changes? I think the wording depends on the time period is for which the charter is prepared. I can try some text once I have time tomorrow. . . . > > I think the DS draft provides a conceptual framework for diverse DS > > usage scenarios to be used by many protocols, where IETF WGs may > > actually decide using a subset of the DS framework for their purpose > > and for their protocol standardization. > > Based on this the conceptual framework cannot be standardized as it is > > but the protocols using a consistent subset have to be standardized. > > Following this consideration I think the intended status of the DS > > draft should be changed to: Informational RFC If you agree please > > indicate this change accordingly. > > I think Juergen's reply to your previous message highlights that there is a > difference of opinion here based on the technical specifics of the draft. My > position as chair is that I'll support whatever makes sense based on the > document produced by the WG. Today the document authors believe PS is > appropriate, once we have a version that is stabilizing for LC -- which > hopefully will be the next version or two -- then will be a good time to revisit > this. There are indeed different opinions concerning the goal of the DS draft. I agree with the document introduction and see it as a conceptual framework covering many usage scenarios. Such a conceptual framework describing possible solutions is informational in nature and is not relevant for standardization. > >>> This is as I think also important to avoid an overlapping between > >>> NETCONF and NETMOD charters. > >> I don't follow this point. Certainly I'd hope that the protocol > >> impact of revised DS are covered in a PS document, unless for some > >> reason there are no "on-the-wire" changes needed. TI wouldn't expect > >> that the document status of the base revised data store document would > impact that. Do you? > >> If so, how? > > My comment is actually superfluous if you agree with my considerations > > above. > > The worst case would in my opinion happen if the DS conceptual > > framework covering many high-level DS usage scenarios would be > > attempted to standardize, which at the end would prescribe protocol > > WGs what they should be standardizing. > > Yang presumes a certain set of functions for the protocols it operates over. > I'm not sure why having a document that specifies this would be an issue. This is again an interesting discussion which SHOULD be discussed in a joint session. I don't have a strong opinion but it can be seen differently. > > In such a case the conceptual framework would most likely cause a > > competing situation with protocol WG's goals and documents and cannot > > be adopted successfully. > > If a protocol doesn't provide full support for yang (requirements) it can't fully > support all yang features. If your point is that when NetMod changes basic > yang functions/operations that this might constrain the protocols (and > related WGs) over which it operates, then I agree that this is the case. How > could it be otherwise? Usually modeling languages provide many language constructs and people modeling models choose which one is best for their purpose. The same applies to the DS concept framework. The protocol WGs would like to have the freedom to choose the subset to adopt from the protocol pov. > Thanks, > > Lou > > > Thanks, > > Mehmet > > > >>> PS: I expect that most of the Netconf WG member read also the > Netmod > >>> maillist and therefor skip sending to both ML. > >>> > >> Great. > >> > >> Thanks. > >> Lou > >>> Thanks, > >>> Mehmet > >>> > >>>> -----Original Message----- > >>>> From: Mehmet Ersue > >>>> Sent: Thursday, March 9, 2017 7:36 PM > >>>> To: Lou Berger ; 'Kent Watsen' > >>>> ; netmod@ietf.org > >>>> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' > >>>> > >>>> Subject: RE: [netmod] draft netmod charter update proposal > >>>> > >>>> Hi Lou, > >>>> > >>>>> The charters from the last couple of years don't have the intended > >>> status -- > >>>> at least the ones we checked. > >>>>> I actually feel pretty strongly about this (which of course can be > >>>>> easily overruled by our AD). It's my experience that premature > >>>>> discussions on intended status, i.e., before a document is > >>>>> sufficiently > >>>> mature, leads to process-focused arguments that detracts from > >>>> making technical progress. While once a document is mature and > >>>> core direction/content is fixed, it is generally obvious what > >>>> status is > >>> appropriate. > >>>> The charters from the last couple of years have a short WG item > >>> definition, > >>>> which would be IMO sufficient. > >>>> You are right the intended status is not available since a few > >>>> years, but > >>> IMO it > >>>> is part of the target definition and would be very useful for the > >>>> draft > >>> authors > >>>> and WG members to regard. > >>>> > >>>>>> It would be good to bring the high-level topics in relation to > >>>>>> the WG > >>>> items. > >>>>> I'm sorry, I don't understand this last sentence can you rephrase it? > >>>> What I meant is that the high-level topics a)-f) might be good as > >>>> WG focus description but are not sufficient as draft target definition. > >>>> If you think the high-level topic description is more or less the > >>>> WG item definition, then we could simply write "this is achieved > >>>> with WG > > item > >> XY". > >>>> If not, we could keep the high-level focus text but set > >>>> additionally the borders of the WG item with some concrete words. > >>>> > >>>>>> BTW: We agreed in diverse discussions that the DS concept is > >>>> Informational in nature. > >>>>>> I think this should be corrected in the draft. > >>>>> So this sounds like an objection to a specific document. This is > >>>>> a fair point to raise, but in our opinion it is not a charter > >>>>> impacting point or discussion. If this is in fact the issue you'd > >>>>> like to raise and discuss, lets do so under a document specific > >>>>> thread, e.g., > >>> "Subject: > >>>> intended status of revised-datastore". > >>>> > >>>> I am actually raising this point since November meeting. There are > >>> different > >>>> threads where I explained why it is appropriate as Informational. > >>>> The last thread I remember is at: > >>>> > >> > https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH1 > >>>> 1xcY > >>>> The recent position of NETCONF co-chairs is in > >>>> > >> > https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd > >>>> 8qr5k > >>>> > >>>> Thank you for your consideration. > >>>> > >>>> Regards, > >>>> Mehmet > >>>> > >>>>> -----Original Message----- > >>>>> From: Lou Berger [mailto:lberger@labn.net] > >>>>> Sent: Wednesday, March 8, 2017 11:28 PM > >>>>> To: Mehmet Ersue ; 'Kent Watsen' > >>>>> ; netmod@ietf.org > >>>>> Subject: Re: [netmod] draft netmod charter update proposal > >>>>> > >>>>> Hi Mehmet, > >>>>> > >>>>> On 3/8/2017 4:47 PM, Mehmet Ersue wrote: > >>>>>> Kent, > >>>>>> > >>>>>>> we understand that this is how NETCONF charters are structured, > >>>>>>> but it is not our practice, > >>>>>> AFAIK it was the NETMOD practice for the charters until today. > >>>>> The charters from the last couple of years don't have the intended > >>>>> status -- at least the ones we checked. > >>>>> > >>>>> I actually feel pretty strongly about this (which of course can be > >>>>> easily overruled by our AD). It's my experience that premature > >>>>> discussions on intended status, i.e., before a document is > >>>>> sufficiently mature, leads to process-focused arguments that > >>>>> detracts > >>> from > >>>> making technical progress. > >>>>> While once a document is mature and core direction/content is > >>>>> fixed, it is generally obvious what status is appropriate. > >>>>> > >>>>> > >>>>>> I did not ask > >>>>>> more than written in the current charter. > >>>>>> It would be good to bring the high-level topics in relation to > >>>>>> the WG > >>>> items. > >>>>> I'm sorry, I don't understand this last sentence can you rephrase it? > >>>>> > >>>>>>> as the information is available at the top of each draft, and > >>>>>>> also because > >>>>> this information need not be fixed when the milestone is added. > >>>>> > >>>>>> I believe a WG charter should be self-sufficient covering the > >>>>>> target definition and intended status of the WG items. > >>>>>> Otherwise one can change the target for a WG item by simply > >>>>>> editing the draft abstract anytime. > >>>>> Per IETF process, all it ever takes to make a change in document > >>>>> status is WG consensus, and then IESG and IETF buy-in as part of > >>>>> the > >>>> publication process. > >>>>>> BTW: We agreed in diverse discussions that the DS concept is > >>>>>> Informational in nature. > >>>>>> I think this should be corrected in the draft. > >>>>> So this sounds like an objection to a specific document. This is > >>>>> a fair point to raise, but in our opinion it is not a charter > >>>>> impacting point or discussion. If this is in fact the issue you'd > >>>>> like to raise and discuss, lets do so under a document specific > >>>>> thread, e.g., > >>> "Subject: > >>>>> intended status of revised-datastore". > >>>>> > >>>>> Thanks, > >>>>> Lou > >>>>> > >>>>>> Mehmet > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of > Kent > >>>>>>> Watsen > >>>>>>> Sent: Wednesday, March 8, 2017 7:45 PM > >>>>>>> To: netmod@ietf.org > >>>>>>> Cc: netmod-chairs@ietf.org > >>>>>>> Subject: Re: [netmod] draft netmod charter update proposal > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Hi NETMOD WG, > >>>>>>> > >>>>>>> Please find below draft-4 having the following change: > >>>>>>> > >>>>>>> - added "(e.g., I2RS, RTGWG)" to a sentence. > >>>>>>> > >>>>>>> Hi Sue, Lou and I looked at the proposed charter and found a > >>>>>>> sentence that nicely describes our WG's intent to work with and > >>>>>>> support other WGs (beyond NETCONF), but we felt that the text > >>>>>>> could be made more clear by adding in the above-mentioned > change. > >>>>>>> Beyond this, and the existing a), > >>>>>> b), > >>>>>>> and c), we believe that the charter proposal covers our support > >>>>>>> for I2RS, > >>>>>> do > >>>>>>> you agree? > >>>>>>> > >>>>>>> Hi Mehmet, regarding putting a short description and the > >>>>>>> intended status > >>>>>> for > >>>>>>> each draft into the charter, we understand that this is how > >>>>>>> NETCONF > >>>>>> charters > >>>>>>> are structured, but it is not our practice, as the information > >>>>>>> is > >>>>>> available at the > >>>>>>> top of each draft, and also because this information need not be > >>>>>>> fixed > >>>>>> when > >>>>>>> the milestone is added. > >>>>>>> > >>>>>>> All, Any other comments? > >>>>>>> > >>>>>>> Kent > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Network Modeling (NETMOD) > >>>>>>> ------------------------- > >>>>>>> > >>>>>>> Charter > >>>>>>> > >>>>>>> Current Status: Active > >>>>>>> > >>>>>>> Chairs: > >>>>>>> Lou Berger > >>>>>>> Kent Watsen > >>>>>>> > >>>>>>> Operations and Management Area Directors: > >>>>>>> Benoit Claise > >>>>>>> Joel Jaeggli > >>>>>>> > >>>>>>> Operations and Management Area Advisor: > >>>>>>> Benoit Claise > >>>>>>> > >>>>>>> Secretary: > >>>>>>> Zitao (Michael) Wang > >>>>>>> > >>>>>>> Mailing Lists: > >>>>>>> General Discussion: netmod@ietf.org > >>>>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/netmod > >>>>>>> Archive: > >>> https://mailarchive.ietf.org/arch/browse/netmod/ > >>>>>>> Description of Working Group: > >>>>>>> > >>>>>>> The Network Modeling (NETMOD) working group is responsible > >>>>>>> for the YANG > >>>>>>> data modeling language, and guidelines for developing YANG > >> models. > >>>>> The > >>>>>>> NETMOD working group addresses general topics related to the > >>>>>>> use of > >>>>> the > >>>>>>> YANG language and YANG models, for example, the mapping of > >> YANG > >>>>>>> modeled > >>>>>>> data into various encodings. Finally, the NETMOD working group > >>>>>>> also defines core YANG models used as basic YANG building > >>>>>>> blocks, > >>>> and > >>>>>>> YANG models that do not otherwise fall under the charter of > >>>>>>> any > >>> other > >>>>>>> IETF working group. > >>>>>>> > >>>>>>> The NETMOD WG is responsible for: > >>>>>>> > >>>>>>> a) Maintaining the data modeling language YANG. This effort > >>> entails > >>>>>>> periodically updating the specification to address new > >>> requirements > >>>>>>> as they arise. > >>>>>>> > >>>>>>> b) Maintaining the guidelines for developing YANG models. > >>>>>>> This > >>> effort > >>>>>>> is primarily driven by updates made to the YANG specification. > >>>>>>> > >>>>>>> c) Maintaining a conceptual framework in which YANG models > >>>>>>> are > >>>> used. > >>>>>>> This effort entails describing the generic context that in > > YANG > >>>>>>> exists and how certain YANG statements interact in that > >>> context. > >>>>>>> An example of this is YANG's relationship with datastores. > >>>>>>> > >>>>>>> d) Maintaining encodings for YANG modeled data. This effort > >>> entails > >>>>>>> updating encodings already defined by the NETMOD working > >>>>>>> (XML > >>>> and > >>>>>>> JSON) to accommodate changes to the YANG specification, > >>>>>>> and > >>>>> defining > >>>>>>> new encodings that are needed, and yet do not fall under > >>>>>>> the > >>> charter > >>>>>>> of any other active IETF working group. > >>>>>>> > >>>>>>> e) Maintaining YANG models used as basic YANG building blocks. > >>> This > >>>>>>> effort entails updating existing YANG models > >>>>>>> (ietf-yang-types > >>> and > >>>>>>> ietf-inet-types) as needed, as well as defining additional > >>>>>>> core > >>> YANG > >>>>>>> data models when necessary. > >>>>>>> > >>>>>>> f) Defining and maintaining YANG models that do not fall > >>>>>>> under > > the > >>>>>>> charter of any other active IETF working group. > >>>>>>> > >>>>>>> The NETMOD working group consults with the NETCONF working > >>>> group > >>>>> to > >>>>>>> ensure that new requirements are understood and can be met by > >> the > >>>>>>> protocols (e.g., NETCONF and RESTCONF) developed within that > >>>> working > >>>>>>> group. The NETMOD working group coordinates with other > >>>>>>> working > >>>>> groups > >>>>>>> (e.g., I2RS, RTGWG) on possible extensions to YANG to address > new > >>>>>>> modeling requirements and, when needed, which group will run > the > >>>>>>> process on a specific model. > >>>>>>> > >>>>>>> The NETMOD working group does not serve as a review team for > >>>> YANG > >>>>>>> modules developed by other working groups. Instead, the YANG > >>>>> doctors, > >>>>>>> as organized by the OPS area director responsible for network > >>>>>>> management, will act as advisors for other working groups and > >>> provide > >>>>>>> YANG reviews for the OPS area directors. > >>>>>>> > >>>>>>> Milestones: > >>>>>>> > >>>>>>> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for > >>> publication > >>>>>>> Mar 2017 - Submit draft-ietf-netmod-yang-model-classification > >>>>>>> to > >>> IESG > >>>>>>> for publication > >>>>>>> Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for > >>> publication > >>>>>>> Apr 2017 - Submit draft-ietf-netmod-entity to IESG for > > publication > >>>>>>> Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG for > >>>>>> publication > >>>>>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for > >>>>>> publication > >>>>>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to > >>>>>>> IESG > > for > >>>>>>> publication > >>>>>>> Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > >>>>>>> publication > >>>>>>> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to > >>>>>>> IESG > > for > >>>>>>> publication > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> netmod mailing list > >>>>>>> netmod@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/netmod > >>>>>> _______________________________________________ > >>>>>> netmod mailing list > >>>>>> netmod@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/netmod > >>>>>> > >>> > >>> > > > > From nobody Fri Mar 17 05:30:10 2017 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 CB05E129329 for ; Fri, 17 Mar 2017 05:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 0WLnI5d5eocm for ; Fri, 17 Mar 2017 05:30:07 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C192127735 for ; Fri, 17 Mar 2017 05:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1662; q=dns/txt; s=iport; t=1489753807; x=1490963407; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=31ME5KdOPZaJeWrs40eJStRYiDzPtDLYEIKLVa6wE+o=; b=gXnWkXGBCezzuUXmtNfmO0rgX6JclhEvrdEAaVJZSttj/+uFWqUIPDL9 lpDG8bJUTe955i7EgX9g78XQYyBfv6CjUW/zkTgxWj2y2OZ+lEN1lCqy2 SrA3iXYdACkEkuNGsnQanYnXiH5MQXwLsfmUhnQlhLNSQ56t2kIbNZyHx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DSBwD91ctY/xbLJq1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBgyeBNYRCiwKQRpdviWUVAQIBAQEBAQEBayiFPxV2AiYCXwEMCAEBiXyxd4I?= =?us-ascii?q?milMBAQEBBgIBJYELhUOCBQiEHoYegl8FnEmBU5BvgXuIWyOGMotCiBE1IoEEI?= =?us-ascii?q?xYIFxWFJYFzQIoMAQEB?= X-IronPort-AV: E=Sophos;i="5.36,176,1486425600"; d="scan'208";a="650495094" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2017 12:30:05 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2HCU5xL011394; Fri, 17 Mar 2017 12:30:05 GMT To: "netmod@ietf.org" , Ladislav Lhotka From: Robert Wilton Message-ID: Date: Fri, 17 Mar 2017 12:30:04 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Comments on draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 12:30:09 -0000 Hi Lada, I've had a quick scan of your YANG markup extension draft and I have a few comments: Allowing description, and similar descriptive statements, to use something other than text seems like it could be useful in some cases. I'm not sure that allowing the statements to use any text-like media type is a good idea, this could increase the burden on tool makers if each module author chooses their own preferred format. Instead, I think that it might be better to restrict it to a very small set of media types, that could be extended in future. I would think that initially just allowing plain text and one particular flavour of markdown would be a reasonable starting point. I think that the only formats that should be allowed are those that are still readily readable as plain text, so that tools that don't want to parse the formatted text can still sensibly display the descriptive statements. I.e. I don't think that it would be helpful to allow things like text/xml since it isn't easy to read. Allowing this extension on particular descriptive statements may also be helpful. It seems plausible that the vast majority of these statements in a module might just be written in plain text with just a few of them using more advanced formatting like markdown. Finally, I have a concern that if more structured formatting in the comments is used then would that encourage model writers to produce more verbose comments, and if so that might possibly reduce the readability of the modules. Although, I guess ultimately one has to trust the model writers to do the right thing. Thanks, Rob From nobody Fri Mar 17 05:55:09 2017 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 9D704129400 for ; Fri, 17 Mar 2017 05:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 drMM4GCQAMS1 for ; Fri, 17 Mar 2017 05:55:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0BD1293F2 for ; Fri, 17 Mar 2017 05:55:05 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id 544B460190; Fri, 17 Mar 2017 13:55:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1489755304; bh=CpYkRzJ+w4imVOv8UF7kJvLnN41PV5E5MBrEnZPbkLI=; h=From:Date:To; b=gZsPkoz4sjpFJOTFs5Bxuk0SkZWF/MyVn5aV/9NYelo/IHaxkBsoZPzZAo/93Quop q49vGiKbN+15yL9gWugVnjxFB+T13rKnbJbBJsgCUcqhCzqC4QS/fvWgTzlghy06dr n7KLQylWWo8y7pL9Yq1pgnfTWeV5jdOSahuARvN0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 17 Mar 2017 13:55:03 +0100 Cc: "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Comments on draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 12:55:08 -0000 Hi Rob, thank you for reading the draft. > On 17 Mar 2017, at 13:30, Robert Wilton wrote: >=20 > Hi Lada, >=20 > I've had a quick scan of your YANG markup extension draft and I have a = few comments: >=20 > Allowing description, and similar descriptive statements, to use = something other than text seems like it could be useful in some cases. >=20 > I'm not sure that allowing the statements to use any text-like media = type is a good idea, this could increase the burden on tool makers if = each module author chooses their own preferred format. >=20 > Instead, I think that it might be better to restrict it to a very = small set of media types, that could be extended in future. I would = think that initially just allowing plain text and one particular flavour = of markdown would be a reasonable starting point. I agree although I am not sure that we can easily find an agreement on = the particular flavour. So maybe we can leave it open and let the = "market" decide. >=20 > I think that the only formats that should be allowed are those that = are still readily readable as plain text, so that tools that don't want = to parse the formatted text can still sensibly display the descriptive = statements. I.e. I don't think that it would be helpful to allow things = like text/xml since it isn't easy to read. Sure, and the draft says: It is RECOMMENDED to use only media types representing "lightweight" markup that is easy to read even in the unprocessed source form, such as "text/markdown". >=20 > Allowing this extension on particular descriptive statements may also = be helpful. It seems plausible that the vast majority of these = statements in a module might just be written in plain text with just a = few of them using more advanced formatting like markdown. Yes, I was thinking about this. On the other hand, plain text is = typically compatible with any markup format, so this would probably be = useful only if somebody wanted to use multiple different markup formats = in the same module, which sounds crazy. But we can discuss it. >=20 > Finally, I have a concern that if more structured formatting in the = comments is used then would that encourage model writers to produce more = verbose comments, and if so that might possibly reduce the readability = of the modules. Although, I guess ultimately one has to trust the model = writers to do the right thing. Well, this draft doesn't permit anything above what module writers can = do already now - the descriptions etc. have to be valid YANG strings as = before. The only new thing is a piece of metadata that may be helpful = for some tools but that can also be safely ignored. Thanks, Lada >=20 > Thanks, > Rob >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 17 06:13:29 2017 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 4ED4E129412 for ; Fri, 17 Mar 2017 06:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AxzDVRD-BGiS for ; Fri, 17 Mar 2017 06:13:26 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33656129410 for ; Fri, 17 Mar 2017 06:13:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 39B3E1E568C; Fri, 17 Mar 2017 06:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HDDEPwBSfMV5; Fri, 17 Mar 2017 06:11:58 -0700 (PDT) Received: from [192.168.1.127] (host81-132-49-127.range81-132.btcentralplus.com [81.132.49.127]) by c8a.amsl.com (Postfix) with ESMTPSA id 37C721E5676; Fri, 17 Mar 2017 06:11:57 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: William Lupton In-Reply-To: Date: Fri, 17 Mar 2017 13:13:24 +0000 Cc: "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <63CCC53D-F261-4A32-B32A-B95738CD610B@broadband-forum.org> References: To: Ladislav Lhotka , Robert Wilton X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] Comments on draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 13:13:28 -0000 Lada, Rob, all, I would support use of markdown, with the principle that descriptions = (etc) should remain readable as plain text. Indeed many of the published = NETMOD YANG modules have descriptions that look as though they would = already render quite well if regarded as markdown (blank lines as = paragraph separators, bulleted and numbered lists etc). Note that GitHub have recently published = https://githubengineering.com/a-formal-spec-for-github-markdown, which = might be worth looking at or even adopting? =46rom a quick perusal, it = doesn=E2=80=99t seem to include any GH specifics (e.g for referencing = issues or pull requests), which actually surprised me a little. Maybe this goes too far, but I would also consider conventions allowing = validation of references to enums, bits, nodes etc within descriptions. = Obviously this is potentially a slippery slope and potentially (if = additional markup is needed) a threat to readability, but also a = potential gain (can be validated and so increases quality, can become = hyperlinks when rendered, etc). William PS, We support this sort of thing in TR-069 data model description = strings. Showing our age, the markup is mediawiki-like. For example: * If the ACS sets the value of this parameter to {{enum|Requested}}, the = CPE MUST initiate the corresponding diagnostic test. When writing, the = only allowed values are {{enum|Requested}} and {{enum|Canceled}}=E2=80=A6 * Identifier of the class of product for which the serial number = applies. That is, for a given manufacturer, this parameter is used to = identify the product or class of product over which the = {{param|SerialNumber}} parameter is unique. > On 17 Mar 2017, at 12:55, Ladislav Lhotka wrote: >=20 > Hi Rob, >=20 > thank you for reading the draft. >=20 >> On 17 Mar 2017, at 13:30, Robert Wilton wrote: >>=20 >> Hi Lada, >>=20 >> I've had a quick scan of your YANG markup extension draft and I have = a few comments: >>=20 >> Allowing description, and similar descriptive statements, to use = something other than text seems like it could be useful in some cases. >>=20 >> I'm not sure that allowing the statements to use any text-like media = type is a good idea, this could increase the burden on tool makers if = each module author chooses their own preferred format. >>=20 >> Instead, I think that it might be better to restrict it to a very = small set of media types, that could be extended in future. I would = think that initially just allowing plain text and one particular flavour = of markdown would be a reasonable starting point. >=20 > I agree although I am not sure that we can easily find an agreement on = the particular flavour. So maybe we can leave it open and let the = "market" decide. >=20 >>=20 >> I think that the only formats that should be allowed are those that = are still readily readable as plain text, so that tools that don't want = to parse the formatted text can still sensibly display the descriptive = statements. I.e. I don't think that it would be helpful to allow things = like text/xml since it isn't easy to read. >=20 > Sure, and the draft says: >=20 > It is RECOMMENDED to use only media types representing "lightweight" > markup that is easy to read even in the unprocessed source form, = such > as "text/markdown". >=20 >>=20 >> Allowing this extension on particular descriptive statements may also = be helpful. It seems plausible that the vast majority of these = statements in a module might just be written in plain text with just a = few of them using more advanced formatting like markdown. >=20 > Yes, I was thinking about this. On the other hand, plain text is = typically compatible with any markup format, so this would probably be = useful only if somebody wanted to use multiple different markup formats = in the same module, which sounds crazy. But we can discuss it. >=20 >>=20 >> Finally, I have a concern that if more structured formatting in the = comments is used then would that encourage model writers to produce more = verbose comments, and if so that might possibly reduce the readability = of the modules. Although, I guess ultimately one has to trust the model = writers to do the right thing. >=20 > Well, this draft doesn't permit anything above what module writers can = do already now - the descriptions etc. have to be valid YANG strings as = before. The only new thing is a piece of metadata that may be helpful = for some tools but that can also be safely ignored. >=20 > Thanks, Lada >=20 >>=20 >> Thanks, >> Rob From nobody Fri Mar 17 06:22:47 2017 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 20D47129418 for ; Fri, 17 Mar 2017 06:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 m1uAEzCMi5NP for ; Fri, 17 Mar 2017 06:22:44 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 7BF09129412 for ; Fri, 17 Mar 2017 06:22:44 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n11so15469894wma.1 for ; Fri, 17 Mar 2017 06:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=9a3edj1Mr+dEpSR3/KuvhC2Nme6yl1pAKJd9F1rfUeM=; b=fv1qAoZgxAojo7V2OJfbcSlMEZJwLsotZKygHBrFTUghYExrb4a6gdVCawoYR53Hx0 Tn246ZjAPl1g1jCPkw7D6PRWQTvcJNKkEc6uKk6l49Oxx8TLMwWjBINZ6x53RFGkjTwY v0rNKHV6MDanDVldPUlxsPfFYEAZt3tJFceCa0c+TKCskTDj6bNfZc4iWzv0O80VIPcM G7cz4xGVIebZ4hWGx5onUBhwCC22YeOycWpSpIdkeUuqPERimFEpl7g0BA+36/nGFnez Po26wDTj0eMptdZRfbr9zFkQJqBbikSo5psN5xbJvFHKmEIhscYyDMLS8VvCXRO7ev62 5TMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=9a3edj1Mr+dEpSR3/KuvhC2Nme6yl1pAKJd9F1rfUeM=; b=koEd4JL0dOvSO4mKmIjjJioPmOjOKUL9DD3AfE4lgmPnRN55cuukYvnAPoAJyp/1IU Fiier0nv3s8QB458Egx794UCX/E5T0BMbx2UATbNGp7u9geTM5VIbp+piibRrDxFnU5e YIQX0W/UhGbPbQ7arbq6NswV5RKRvPmOQQG+Kf2TFeg6VYdSb89ri2kHe9r2P2k/gTno DolBF7m663kxzzuk9fbBUe7xXcGT5Nh7UvZydJn0T3E5Ua9nQSCuekln46LLM5967WlD wKHNIFbk0K91SoMNyZ23TWjOfw/YzwV+2X6rFtAADtFUr55e8I2gNiqU6JnFOIy+QgVi iBvg== X-Gm-Message-State: AFeK/H3bDAMX2oz/Kq0VScLSoYy+oOVK47kYzH3Pr+dQW9uHH6rE22n1hqeAw1ygx/4U3Q== X-Received: by 10.28.6.6 with SMTP id 6mr2874172wmg.111.1489756962887; Fri, 17 Mar 2017 06:22:42 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p5B342480.dip0.t-ipconnect.de. [91.52.36.128]) by smtp.gmail.com with ESMTPSA id g43sm4651280wrg.35.2017.03.17.06.22.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 06:22:42 -0700 (PDT) From: "Mehmet Ersue" To: "'Lou Berger'" , "'Juergen Schoenwaelder'" Cc: "'Kent Watsen'" , References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Fri, 17 Mar 2017 14:22:43 +0100 Message-ID: <000f01d29f21$8fe93c10$afbbb430$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUooBvvnQPAF+jVm3AXSML+2gpMjSUA== Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0208.58CBE322.0141,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 13:22:46 -0000 I think YANG identities should be standardized with 7950bis. Mehmet > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, March 16, 2017 12:28 PM > To: Juergen Schoenwaelder ; > Mehmet Ersue > Cc: 'Kent Watsen' ; netmod@ietf.org > Subject: Re: [netmod] draft netmod charter update proposal > > Juergen, > > Thank you for the input. I think your point highlights how the technical > contents of a document drives the intended status of a document. > > Lou > > PS as a reminder to all, intended status of documents is *not* typically > included in charters and are not included in the distributed version. > > > > > On March 16, 2017 2:44:53 AM Juergen Schoenwaelder > wrote: > > > On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: > > > >> That said different people including Netconf WG co-chairs think the DS > >> concept document is Informational in nature and should be published as > an > >> Informational concept to be used in and adopted for the needs in diverse > >> protocol WGs. This is as I think also important to avoid an overlapping > >> between NETCONF and NETMOD charters. > > > > The current datastore draft includes concrete YANG idenity definitions > > for datastores and origins and these definitions better be standards > > track. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > From nobody Fri Mar 17 06:50:32 2017 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 2EF04129432; Fri, 17 Mar 2017 06:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAY6YDA4zMpC; Fri, 17 Mar 2017 06:50:23 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6031F129437; Fri, 17 Mar 2017 06:50:23 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 4A5B21820044; Fri, 17 Mar 2017 14:49:59 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , Benoit Claise , "netmod\@ietf.org" , "sec-ads\@ietf.org" In-Reply-To: <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> Date: Fri, 17 Mar 2017 14:50:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 13:50:30 -0000 Kent Watsen writes: > A couple comments: > > 1) drilling down on the mandatory-to-implement NC/RC protocols > is somewhat missing the point. The important bit is that > *all* protocols transporting YANG-modeled data *only* have > secure transport layers. More specifically, YANG-modeledq > data may be transported over other protocols (e.g., coap), > and also one of the protocols have an insecure transport > protocol (e.g., it doesn't much help to talk about HTTPS > being mandatory-to-implement if RESTCONF allowed HTTP). I agree, and it will become even more relevant if we make YANG protocol-independent. In fact, data models may be useful even without any network transport involved, e.g. for a local CLI implementation. > > 2) just stating that there are secure transport layers still > isn=E2=80=99t sufficient, as these protocols must also require > mutual authentication in order to be secure, and for=20 > statements regarding NACM to make sense. The text I posted > before had a statement like this in it. Right, security considerations attached to data models should deal with security aspects of the static data (which items are security-sensitive etc.) and not with transport security. Lada > > I'm beginning to become a fan of the idea of defining a generic > "Requirements for Protocols Transporting YANG-modeled Data" > document - that would not only discuss security aspects, but > also generic protocol operations, that documents like NC, RC, > CoAP, etc. can point to...and even YANG (RFC 7950), rather than > pointing directly at NETCONF as it does today... > > Kent // contributor > > > On 3/16/2017 8:56 AM, Juergen Schoenwaelder wrote: >> On Thu, Mar 16, 2017 at 08:37:39AM +0100, Benoit Claise wrote: >>> Latest proposal: >>> >>> The YANG module defined in this document is designed to be accessed >>> via network management protocols such as NETCONF [RFC6241] or >>> RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transpo= rt >>> layer, >>> and mandatory-to-implement secure transport is Secure Shell (SSH) >>> [RFC6242], >>> while the lowest RESTCONF layer is HTTP, and the mandatory-to-impl= ement >>> secure >>> transport is Transport Layer Security (TLS) [RFC5246]. >> Picking wording from Section 12 of RFC 8040 to replace your second >> sentence I get this: >> >> The YANG module defined in this document is designed to be >> accessed via network management protocols such as NETCONF >> [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the >> secure transport layer, and the mandatory-to-implement secure >> transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF >> layer is HTTPS, and the mandatory-to-implement secure transport is >> TLS [RFC5246]. >> >> The NETCONF access control model [RFC6536] provides the means to >> restrict access for particular NETCONF or RESTCONF users to a >> pre-configured subset of all available NETCONF or RESTCONF >> protocol operations and content. > Yes, thank you. > > Regards, B. >> >> /js >> > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 17 07:02:46 2017 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 EB34F129447 for ; Fri, 17 Mar 2017 07:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 4ysFCISFtcAd for ; Fri, 17 Mar 2017 07:02:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC1112943D for ; Fri, 17 Mar 2017 07:02:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D8C0613E4; Fri, 17 Mar 2017 15:02:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id N7iM8YMB7n5A; Fri, 17 Mar 2017 15:02:36 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Mar 2017 15:02:38 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A615B20038; Fri, 17 Mar 2017 15:02:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YKt8qIRJowTo; Fri, 17 Mar 2017 15:02:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDD7E20035; Fri, 17 Mar 2017 15:02:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DF06F3EEB7EB; Fri, 17 Mar 2017 15:02:19 +0100 (CET) Date: Fri, 17 Mar 2017 15:02:19 +0100 From: Juergen Schoenwaelder To: Mehmet Ersue Cc: 'Lou Berger' , 'Kent Watsen' , netmod@ietf.org Message-ID: <20170317140219.GA27893@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Mehmet Ersue , 'Lou Berger' , 'Kent Watsen' , netmod@ietf.org References: <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000f01d29f21$8fe93c10$afbbb430$@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:02:42 -0000 On Fri, Mar 17, 2017 at 02:22:43PM +0100, Mehmet Ersue wrote: > I think YANG identities should be standardized with 7950bis. Why? These identities are not specific to the YANG language itself. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 17 07:03:22 2017 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 5564D129441 for ; Fri, 17 Mar 2017 07:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 QXZWAXXesH4m for ; Fri, 17 Mar 2017 07:03:17 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 48FC612943C for ; Fri, 17 Mar 2017 07:03:17 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-03v.sys.comcast.net with SMTP id osSZcXvw2dEjjosTMco0V4; Fri, 17 Mar 2017 14:03:16 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-18v.sys.comcast.net with SMTP id osTKcviVQpxUzosTLcF1OL; Fri, 17 Mar 2017 14:03:16 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2HE3EJv032023; Fri, 17 Mar 2017 10:03:14 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2HE3EQb032020; Fri, 17 Mar 2017 10:03:14 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Robert Wilton Cc: andy@yumaworks.com, joey.boyd@adtran.com, netmod@ietf.org In-Reply-To: <67e7ba2b-c526-fd9b-f39f-14f5b0490f4f@cisco.com> (rwilton@cisco.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 17 Mar 2017 10:03:14 -0400 Message-ID: <87pohgova5.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfAyhE/DrEbMaetpmv4G1tSkq+bkIRx1rWW+nEg2RFPB2+Ap5nvmR4qF0osOdt38pReU5Y5HaUYlKO8Wrqhe79NkruhioZmzsJj6e29SPBH+tKkPwFPbH CvkMh2y+6zJLD+iubulOEUGt52++5B7He/KYRT6Mh3hCJ/X00nBkf7hbYf85e3Jf6xr3aTGE5w5trhf5qaBf8KsLR750r35diQ60lXC+4N8LvI1xDkNcaGwD yJOCA+jFvnfOdW95s2DS0g== Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:03:21 -0000 Robert Wilton writes: > To quote Joey's example, I think that both of the following modules are > valid (presuming that they are both implemented by a device) regardless > of which features are enabled. Do you agree? > > module base-module { > prefix bmod; > > feature things; > feature widgets; > > container things { > if-feature things; > ... > container widgets { > if-feature widgets; > ... > } > } > } > > module augment-module { > prefix amod; > > augment "/bmod:things" { > container other-things { > } > } > > augment "/bmod:things/bmod:widgets" { > container other-widgets { > } > } > } Does it remain valid if base-module is changed to: module base-module { prefix bmod; feature things; feature widgets; container things { if-feature things; ... } } } As I analyze it, the augment statement is unconditional, but the presence of its target node can be (1) unconditional, (2) conditional, or (3) *never* present. My preferred approach is that an augment is only valid if it is "present" only if the target node is present (a condition I think can be verified statically). But if we allow the augment to silently have no effect if the target node is not present in the current implementation, do we still require that there is some possible implementation in which the target node exists? Dale From nobody Fri Mar 17 07:04:35 2017 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 13D92129436 for ; Fri, 17 Mar 2017 07:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 B0k2HS2SwR2n for ; Fri, 17 Mar 2017 07:04:31 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E302712943D for ; Fri, 17 Mar 2017 07:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2827; q=dns/txt; s=iport; t=1489759471; x=1490969071; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=VXjtY8ffXi2ZydyasQHMudbMBd2Mc661jLZrTtZyr1Y=; b=b7kx+hF5VB5pAkNcNNY8wOQOBaKndorf0H0jWeBamlpmC2ERTk6GjsbA LixnlangU2YWbtXF+6Wr1HoLV7maTA9MxrdPXE9GtuU1KEdy0MTNz0t+W /vMG78E7O15Yghphg+ycob3rN/Y2dckFdm+eauup1MvNUv2m2NZJSi0xE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAQBs7MtY/xbLJq1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQyKmCNcXOQZYgSjTCCDh8LhS5KAoM/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAwEBNjYGBQwCAgsOAgEEAQEBJwcbBgYfCQgGAQwGAgEBiWQDFQ60JIc3D?= =?us-ascii?q?YMOAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWGSYIFgmqCUYIkJoUeBZwPOo4RhDG?= =?us-ascii?q?Be4hbhlWIToISYogRHzg+RiMWCBcVQYRXHYFjQDWJVwEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,176,1486425600"; d="scan'208";a="650496629" 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; 17 Mar 2017 14:04:28 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2HE4RiX021620; Fri, 17 Mar 2017 14:04:27 GMT To: Mehmet Ersue , "'Lou Berger'" , "'Juergen Schoenwaelder'" References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> Cc: netmod@ietf.org From: Robert Wilton Message-ID: <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> Date: Fri, 17 Mar 2017 14:04:26 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <000f01d29f21$8fe93c10$afbbb430$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:04:34 -0000 Hi, Would 7950bis be allowed to have a normative reference to an Informational RFC that defined the YANG datastores? If we did a 7950bis document (and it isn't clear that one is actually required to support the revised datastores draft) then does that mean we would also need to have a new version of YANG? That would potentially seem like a backwards step. Also what would it mean for an implementation that is aware of the new datastores but is using a mix of YANG modules with different versions? I don't understand why the revised datastores draft should not be standards track once the various appendices have been moved out, noting that they are really only in the one draft at this stage because it seemed like that would make it easier for folks to review and comment on. Is the only issue here which WG the draft is being worked on? Thanks, Rob On 17/03/2017 13:22, Mehmet Ersue wrote: > I think YANG identities should be standardized with 7950bis. > > Mehmet > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Thursday, March 16, 2017 12:28 PM >> To: Juergen Schoenwaelder ; >> Mehmet Ersue >> Cc: 'Kent Watsen' ; netmod@ietf.org >> Subject: Re: [netmod] draft netmod charter update proposal >> >> Juergen, >> >> Thank you for the input. I think your point highlights how the technical >> contents of a document drives the intended status of a document. >> >> Lou >> >> PS as a reminder to all, intended status of documents is *not* typically >> included in charters and are not included in the distributed version. >> >> >> >> >> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder >> wrote: >> >>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: >>> >>>> That said different people including Netconf WG co-chairs think the DS >>>> concept document is Informational in nature and should be published as >> an >>>> Informational concept to be used in and adopted for the needs in > diverse >>>> protocol WGs. This is as I think also important to avoid an overlapping >>>> between NETCONF and NETMOD charters. >>> The current datastore draft includes concrete YANG idenity definitions >>> for datastores and origins and these definitions better be standards >>> track. >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >>> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Fri Mar 17 07:11:53 2017 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 D2BED126C23 for ; Fri, 17 Mar 2017 07:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 e08fJMs-7hu7 for ; Fri, 17 Mar 2017 07:11:50 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58FD3129436 for ; Fri, 17 Mar 2017 07:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3426; q=dns/txt; s=iport; t=1489759910; x=1490969510; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=rCRgaO9Lw5D7Dq8FWG/D1oRGH6TPvpT5jhlDwsCqW+w=; b=MSywdl9uG7NTwIu3S2U26w11+autOD/kM7qf7TlrIzaJaJy2djnQcOpo KXR53dmPgiLtk0kmSTlCmHIkSYOJB2GBIBYtZvXmXlKeFJNIJ50O0iNLs 6qDAVzOol6jlvsRWIL+jFxYsB4xft2TIo9vlzNpllh4K7AN854cR5zvVj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQBh7ctY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyeBNWCNcXOQRh+VQoIOhiICgz8YAQIBAQEBAQEBayiFFQEBAQE?= =?us-ascii?q?CAThBEAsYLlcGDQYCAQGJdAi0NopRAQEBAQEBAQEBAQEBAQEBAQEhhk6CBQiCY?= =?us-ascii?q?oE8iH0BBJxJkkKBe4hbI4Yyi0KIER84gQQjFggXFYUlgXNANYlXAQEB?= X-IronPort-AV: E=Sophos;i="5.36,176,1486425600"; d="scan'208";a="651518444" 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; 17 Mar 2017 14:11:48 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2HEBmh1032163; Fri, 17 Mar 2017 14:11:48 GMT To: Ladislav Lhotka References: Cc: "netmod@ietf.org" From: Robert Wilton Message-ID: <18a2e042-919b-9468-2dc8-f751bd924125@cisco.com> Date: Fri, 17 Mar 2017 14:11:47 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Comments on draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:11:52 -0000 On 17/03/2017 12:55, Ladislav Lhotka wrote: > Hi Rob, > > thank you for reading the draft. > >> On 17 Mar 2017, at 13:30, Robert Wilton wrote: >> >> Hi Lada, >> >> I've had a quick scan of your YANG markup extension draft and I have a few comments: >> >> Allowing description, and similar descriptive statements, to use something other than text seems like it could be useful in some cases. >> >> I'm not sure that allowing the statements to use any text-like media type is a good idea, this could increase the burden on tool makers if each module author chooses their own preferred format. >> >> Instead, I think that it might be better to restrict it to a very small set of media types, that could be extended in future. I would think that initially just allowing plain text and one particular flavour of markdown would be a reasonable starting point. > I agree although I am not sure that we can easily find an agreement on the particular flavour. So maybe we can leave it open and let the "market" decide. I think that would be a mistake. How would device/tools vendors know which versions to spend time implementing? > >> I think that the only formats that should be allowed are those that are still readily readable as plain text, so that tools that don't want to parse the formatted text can still sensibly display the descriptive statements. I.e. I don't think that it would be helpful to allow things like text/xml since it isn't easy to read. > Sure, and the draft says: > > It is RECOMMENDED to use only media types representing "lightweight" > markup that is easy to read even in the unprocessed source form, such > as "text/markdown". I was proposing REQUIRED instead of RECOMMENDED. > >> Allowing this extension on particular descriptive statements may also be helpful. It seems plausible that the vast majority of these statements in a module might just be written in plain text with just a few of them using more advanced formatting like markdown. > Yes, I was thinking about this. On the other hand, plain text is typically compatible with any markup format, so this would probably be useful only if somebody wanted to use multiple different markup formats in the same module, which sounds crazy. But we can discuss it. I was only thinking of a mix of some plain text descriptions and some using markup. Tooling may choose to format raw text differently from markup text (e.g. converting lines into a paragraph). Also a markup processor would be extra work, and may not warn or error on the structure of a plain text description that doesn't conform to the markup rules. > >> Finally, I have a concern that if more structured formatting in the comments is used then would that encourage model writers to produce more verbose comments, and if so that might possibly reduce the readability of the modules. Although, I guess ultimately one has to trust the model writers to do the right thing. > Well, this draft doesn't permit anything above what module writers can do already now - the descriptions etc. have to be valid YANG strings as before. The only new thing is a piece of metadata that may be helpful for some tools but that can also be safely ignored. Thanks, Rob > > Thanks, Lada > >> Thanks, >> Rob >> > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > . > From nobody Fri Mar 17 07:16:25 2017 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 0247D12944A for ; Fri, 17 Mar 2017 07:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 s8MmMzKgezig for ; Fri, 17 Mar 2017 07:16:13 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6AF7129436 for ; Fri, 17 Mar 2017 07:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4724; q=dns/txt; s=iport; t=1489760172; x=1490969772; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=DCm2Qo2727cStXyjeT4zA/oya3hQs+QETu0DMSZmSNE=; b=irmgEPdY4ME1KmjO7qOhRzB6v6aVcx5Q0dPnWeU/guCgokgzP2G+RvTE WslQro2N6OlUNpYY0Y3lb20RjI/yBSgIFv251/GsD8/piusCmyfeDw7JH yGou5oue52IYqsYQCga/2GViMrJZTCdGP4ZRn2cW2p8fuAiN2flTnovy8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAQC67stY/xbLJq1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMngQsqYINiig9zkGWVQoIOKoV4AoM+GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEjDwEFNAoDEAsOCgICJgICVwYBDAYCAQGJdAgOsgeCJopQAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYELhUOCBYJqgTyCcIMugl8FiSWTJIZ5i0mBe1SIByO?= =?us-ascii?q?GMosGPIgRHziBBCMWCBcVhSWBc0A1AYcZAgIiB4IQAQEB?= X-IronPort-AV: E=Sophos;i="5.36,176,1486425600"; d="scan'208";a="651518535" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2017 14:16:10 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2HEGAhS030686; Fri, 17 Mar 2017 14:16:10 GMT To: William Lupton , Ladislav Lhotka References: <63CCC53D-F261-4A32-B32A-B95738CD610B@broadband-forum.org> Cc: "netmod@ietf.org" From: Robert Wilton Message-ID: <746496ed-1da8-e978-34c4-ebf782bb0f7a@cisco.com> Date: Fri, 17 Mar 2017 14:16:09 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <63CCC53D-F261-4A32-B32A-B95738CD610B@broadband-forum.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Comments on draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:16:23 -0000 Hi William, On 17/03/2017 13:13, William Lupton wrote: > Lada, Rob, all, > > I would support use of markdown, with the principle that descriptions (etc) should remain readable as plain text. Indeed many of the published NETMOD YANG modules have descriptions that look as though they would already render quite well if regarded as markdown (blank lines as paragraph separators, bulleted and numbered lists etc). > > Note that GitHub have recently published https://githubengineering.com/a-formal-spec-for-github-markdown, which might be worth looking at or even adopting? From a quick perusal, it doesn’t seem to include any GH specifics (e.g for referencing issues or pull requests), which actually surprised me a little. The spec that this is based on seems to be very long though! E.g. http://spec.commonmark.org/0.27/, 115 pages! > > Maybe this goes too far, but I would also consider conventions allowing validation of references to enums, bits, nodes etc within descriptions. Obviously this is potentially a slippery slope and potentially (if additional markup is needed) a threat to readability, but also a potential gain (can be validated and so increases quality, can become hyperlinks when rendered, etc). A reasonable idea. > > William > > PS, We support this sort of thing in TR-069 data model description strings. Showing our age, the markup is mediawiki-like. For example: > * If the ACS sets the value of this parameter to {{enum|Requested}}, the CPE MUST initiate the corresponding diagnostic test. When writing, the only allowed values are {{enum|Requested}} and {{enum|Canceled}}… > * Identifier of the class of product for which the serial number applies. That is, for a given manufacturer, this parameter is used to identify the product or class of product over which the {{param|SerialNumber}} parameter is unique. Thanks, Rob >> On 17 Mar 2017, at 12:55, Ladislav Lhotka wrote: >> >> Hi Rob, >> >> thank you for reading the draft. >> >>> On 17 Mar 2017, at 13:30, Robert Wilton wrote: >>> >>> Hi Lada, >>> >>> I've had a quick scan of your YANG markup extension draft and I have a few comments: >>> >>> Allowing description, and similar descriptive statements, to use something other than text seems like it could be useful in some cases. >>> >>> I'm not sure that allowing the statements to use any text-like media type is a good idea, this could increase the burden on tool makers if each module author chooses their own preferred format. >>> >>> Instead, I think that it might be better to restrict it to a very small set of media types, that could be extended in future. I would think that initially just allowing plain text and one particular flavour of markdown would be a reasonable starting point. >> I agree although I am not sure that we can easily find an agreement on the particular flavour. So maybe we can leave it open and let the "market" decide. >> >>> I think that the only formats that should be allowed are those that are still readily readable as plain text, so that tools that don't want to parse the formatted text can still sensibly display the descriptive statements. I.e. I don't think that it would be helpful to allow things like text/xml since it isn't easy to read. >> Sure, and the draft says: >> >> It is RECOMMENDED to use only media types representing "lightweight" >> markup that is easy to read even in the unprocessed source form, such >> as "text/markdown". >> >>> Allowing this extension on particular descriptive statements may also be helpful. It seems plausible that the vast majority of these statements in a module might just be written in plain text with just a few of them using more advanced formatting like markdown. >> Yes, I was thinking about this. On the other hand, plain text is typically compatible with any markup format, so this would probably be useful only if somebody wanted to use multiple different markup formats in the same module, which sounds crazy. But we can discuss it. >> >>> Finally, I have a concern that if more structured formatting in the comments is used then would that encourage model writers to produce more verbose comments, and if so that might possibly reduce the readability of the modules. Although, I guess ultimately one has to trust the model writers to do the right thing. >> Well, this draft doesn't permit anything above what module writers can do already now - the descriptions etc. have to be valid YANG strings as before. The only new thing is a piece of metadata that may be helpful for some tools but that can also be safely ignored. >> >> Thanks, Lada >> >>> Thanks, >>> Rob > . > From nobody Fri Mar 17 07:24:17 2017 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 6F0D112944F for ; Fri, 17 Mar 2017 07:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 HxxuiHXiCrfH for ; Fri, 17 Mar 2017 07:24:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8446F12945B for ; Fri, 17 Mar 2017 07:24:13 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id 3BAF86057A; Fri, 17 Mar 2017 15:24:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1489760652; bh=5eznTtsvDxrSy2e9vT0PEuArGVRDrgwfH9GLuKSoYYg=; h=From:Date:To; b=FC/EEnjZ3Fm0CaYCTgwXgKMUI6DO+J4FDDSOrlWAXoUZU/vTX60kJzXUGcvjO1w7d 87/UT6D4vj0YKYohS8nGp+7bbNx/pKJTPoqQvQx0AzrD46Jk4GC9/es/gNra8NjakI eSrF0gctL7nDstQCZZoNiMQZcwhWFwyxnh8BMOyo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <63CCC53D-F261-4A32-B32A-B95738CD610B@broadband-forum.org> Date: Fri, 17 Mar 2017 15:24:11 +0100 Cc: Robert Wilton , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <63CCC53D-F261-4A32-B32A-B95738CD610B@broadband-forum.org> To: William Lupton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Comments on draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:24:16 -0000 > On 17 Mar 2017, at 14:13, William Lupton = wrote: >=20 > Lada, Rob, all, >=20 > I would support use of markdown, with the principle that descriptions = (etc) should remain readable as plain text. Indeed many of the published = NETMOD YANG modules have descriptions that look as though they would = already render quite well if regarded as markdown (blank lines as = paragraph separators, bulleted and numbered lists etc). Right, actually my itch that I am trying to scratch with this proposal = is the use of descriptions from existing modules in HTML, e.g. in = tooltips, and parsing lists is tricky because module authors use = different whitespace conventions. >=20 > Note that GitHub have recently published = https://githubengineering.com/a-formal-spec-for-github-markdown, which = might be worth looking at or even adopting? =46rom a quick perusal, it = doesn=E2=80=99t seem to include any GH specifics (e.g for referencing = issues or pull requests), which actually surprised me a little. May be there are two levels: one is YANG the language where I would = prefer not to prescribe a particular markup format, and another is = 6087bis that may do it for IETF documents. >=20 > Maybe this goes too far, but I would also consider conventions = allowing validation of references to enums, bits, nodes etc within = descriptions. Obviously this is potentially a slippery slope and = potentially (if additional markup is needed) a threat to readability, = but also a potential gain (can be validated and so increases quality, = can become hyperlinks when rendered, etc). In fact, it would be quite useful to be able to include such references = in custom error messages. Schematron allows for it, and this is why with = DSDL validation messages generated by Schematron are often more helpful = than those coming from RELAX NG. Lada >=20 > William >=20 > PS, We support this sort of thing in TR-069 data model description = strings. Showing our age, the markup is mediawiki-like. For example: > * If the ACS sets the value of this parameter to {{enum|Requested}}, = the CPE MUST initiate the corresponding diagnostic test. When writing, = the only allowed values are {{enum|Requested}} and {{enum|Canceled}}=E2=80= =A6 > * Identifier of the class of product for which the serial number = applies. That is, for a given manufacturer, this parameter is used to = identify the product or class of product over which the = {{param|SerialNumber}} parameter is unique. >=20 >> On 17 Mar 2017, at 12:55, Ladislav Lhotka wrote: >>=20 >> Hi Rob, >>=20 >> thank you for reading the draft. >>=20 >>> On 17 Mar 2017, at 13:30, Robert Wilton wrote: >>>=20 >>> Hi Lada, >>>=20 >>> I've had a quick scan of your YANG markup extension draft and I have = a few comments: >>>=20 >>> Allowing description, and similar descriptive statements, to use = something other than text seems like it could be useful in some cases. >>>=20 >>> I'm not sure that allowing the statements to use any text-like media = type is a good idea, this could increase the burden on tool makers if = each module author chooses their own preferred format. >>>=20 >>> Instead, I think that it might be better to restrict it to a very = small set of media types, that could be extended in future. I would = think that initially just allowing plain text and one particular flavour = of markdown would be a reasonable starting point. >>=20 >> I agree although I am not sure that we can easily find an agreement = on the particular flavour. So maybe we can leave it open and let the = "market" decide. >>=20 >>>=20 >>> I think that the only formats that should be allowed are those that = are still readily readable as plain text, so that tools that don't want = to parse the formatted text can still sensibly display the descriptive = statements. I.e. I don't think that it would be helpful to allow things = like text/xml since it isn't easy to read. >>=20 >> Sure, and the draft says: >>=20 >> It is RECOMMENDED to use only media types representing "lightweight" >> markup that is easy to read even in the unprocessed source form, = such >> as "text/markdown". >>=20 >>>=20 >>> Allowing this extension on particular descriptive statements may = also be helpful. It seems plausible that the vast majority of these = statements in a module might just be written in plain text with just a = few of them using more advanced formatting like markdown. >>=20 >> Yes, I was thinking about this. On the other hand, plain text is = typically compatible with any markup format, so this would probably be = useful only if somebody wanted to use multiple different markup formats = in the same module, which sounds crazy. But we can discuss it. >>=20 >>>=20 >>> Finally, I have a concern that if more structured formatting in the = comments is used then would that encourage model writers to produce more = verbose comments, and if so that might possibly reduce the readability = of the modules. Although, I guess ultimately one has to trust the model = writers to do the right thing. >>=20 >> Well, this draft doesn't permit anything above what module writers = can do already now - the descriptions etc. have to be valid YANG strings = as before. The only new thing is a piece of metadata that may be helpful = for some tools but that can also be safely ignored. >>=20 >> Thanks, Lada >>=20 >>>=20 >>> Thanks, >>> Rob >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 17 07:32:17 2017 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 CC17E129443 for ; Fri, 17 Mar 2017 07:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 kupWrqgxIKDZ for ; Fri, 17 Mar 2017 07:32:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C2B126C23 for ; Fri, 17 Mar 2017 07:32:12 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id C3AF1600C8; Fri, 17 Mar 2017 15:32:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1489761130; bh=OZVwC3m8BaRt7iHqvK+CU0njyUS/0YKceQnv44pnnY4=; h=From:Date:To; b=Eiqi6WrDS0eTFhBnduMb5KO6do9jXDZ4ruHCvHFzzSh2lCVKEgdv07G7zXRUfoKlX tB30JIkuVuQMEQCDtWjjMXvEpJhFyXgYpyv1QscmsXChEPqmKkbaSSjKWYX3ikVp2B 9ejEXsyHu3cAbE8oJe24Wqo/USYf31hHjMlzVA8E= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> Date: Fri, 17 Mar 2017 15:32:10 +0100 Cc: Mehmet Ersue , Lou Berger , =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:32:15 -0000 > On 17 Mar 2017, at 15:04, Robert Wilton wrote: >=20 > Hi, >=20 > Would 7950bis be allowed to have a normative reference to an = Informational RFC that defined the YANG datastores? My idea is that 7950bis should be made independent of any particular set = of datastores, so such a normative reference shouldn't be needed. Lada >=20 > If we did a 7950bis document (and it isn't clear that one is actually = required to support the revised datastores draft) then does that mean we = would also need to have a new version of YANG? >=20 > That would potentially seem like a backwards step. Also what would it = mean for an implementation that is aware of the new datastores but is = using a mix of YANG modules with different versions? >=20 > I don't understand why the revised datastores draft should not be = standards track once the various appendices have been moved out, noting = that they are really only in the one draft at this stage because it = seemed like that would make it easier for folks to review and comment = on. >=20 > Is the only issue here which WG the draft is being worked on? >=20 > Thanks, > Rob >=20 >=20 > On 17/03/2017 13:22, Mehmet Ersue wrote: >> I think YANG identities should be standardized with 7950bis. >>=20 >> Mehmet >>=20 >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Thursday, March 16, 2017 12:28 PM >>> To: Juergen Schoenwaelder ; >>> Mehmet Ersue >>> Cc: 'Kent Watsen' ; netmod@ietf.org >>> Subject: Re: [netmod] draft netmod charter update proposal >>>=20 >>> Juergen, >>>=20 >>> Thank you for the input. I think your point highlights how the = technical >>> contents of a document drives the intended status of a document. >>>=20 >>> Lou >>>=20 >>> PS as a reminder to all, intended status of documents is *not* = typically >>> included in charters and are not included in the distributed = version. >>>=20 >>>=20 >>>=20 >>>=20 >>> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder >>> wrote: >>>=20 >>>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: >>>>=20 >>>>> That said different people including Netconf WG co-chairs think = the DS >>>>> concept document is Informational in nature and should be = published as >>> an >>>>> Informational concept to be used in and adopted for the needs in >> diverse >>>>> protocol WGs. This is as I think also important to avoid an = overlapping >>>>> between NETCONF and NETMOD charters. >>>> The current datastore draft includes concrete YANG idenity = definitions >>>> for datastores and origins and these definitions better be = standards >>>> track. >>>>=20 >>>> /js >>>>=20 >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 17 07:41:03 2017 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 24DD11293DF for ; Fri, 17 Mar 2017 07:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 ZUrtgSUKLbCG for ; Fri, 17 Mar 2017 07:41:00 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BAC2129457 for ; Fri, 17 Mar 2017 07:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2697; q=dns/txt; s=iport; t=1489761659; x=1490971259; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=cGLhoe64Wa5Q2Qpb2V/amHhOGBDMygVmHP8PU7rb7Wg=; b=M5eL6pxX5jT6z9NpLXu2OKVF1SAiLINFbhtfr+cY1+cBsn/X3CVwLpO9 FH02bIQq4E82azG05cogkPvADZTTkpj16xO+OYdUD9G0hpXQwj3WV+v4E vwf4nn6c4KYtC5p3Rt+3kA6EA7+JGhfz8opbitbYwLqoo8VztDzS1EEcB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgCs9MtY/xbLJq1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyeBNQdZjXFzkGWVQoIOgmyDNgKDPhgBAgEBAQEBAQFrKIUVAQEBAQI?= =?us-ascii?q?BOEEQCxguVwYNBgIBAYl0CLQ5ik8BAQEBAQEBAQEBAQEBAQEBASGGToIFgmqKO?= =?us-ascii?q?QEEnEmSQopWhlWLQogRHziBBCMWCBcVhxhANYlXAQEB?= X-IronPort-AV: E=Sophos;i="5.36,177,1486425600"; d="scan'208";a="653340102" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2017 14:40:57 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2HEeueq029343; Fri, 17 Mar 2017 14:40:57 GMT To: "Dale R. Worley" References: <87pohgova5.fsf@hobgoblin.ariadne.com> Cc: andy@yumaworks.com, joey.boyd@adtran.com, netmod@ietf.org From: Robert Wilton Message-ID: <3006056f-0b0e-1cab-e402-a1251ee77e7e@cisco.com> Date: Fri, 17 Mar 2017 14:40:55 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <87pohgova5.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] augment and if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:41:02 -0000 On 17/03/2017 14:03, Dale R. Worley wrote: > Robert Wilton writes: >> To quote Joey's example, I think that both of the following modules are >> valid (presuming that they are both implemented by a device) regardless >> of which features are enabled. Do you agree? >> >> module base-module { >> prefix bmod; >> >> feature things; >> feature widgets; >> >> container things { >> if-feature things; >> ... >> container widgets { >> if-feature widgets; >> ... >> } >> } >> } >> >> module augment-module { >> prefix amod; >> >> augment "/bmod:things" { >> container other-things { >> } >> } >> >> augment "/bmod:things/bmod:widgets" { >> container other-widgets { >> } >> } >> } > Does it remain valid if base-module is changed to: > > module base-module { > prefix bmod; > > feature things; > feature widgets; > > container things { > if-feature things; > ... > } > } > } No, I don't think that it is valid because this augment fails because the base node "/bmod:things/bmod:widgets" doesn't exist. > > As I analyze it, the augment statement is unconditional, but the > presence of its target node can be (1) unconditional, (2) conditional, > or (3) *never* present. > > My preferred approach is that an augment is only valid if it is > "present" only if the target node is present (a condition I think can be > verified statically). But if we allow the augment to silently have no > effect if the target node is not present in the current implementation, > do we still require that there is some possible implementation in which > the target node exists? I guess that I think that a node with an if-feature stmt is logically present in the schema (and hence can always be augmented), but just that it (and its descendant nodes) can be supported/unsupported depending on what features a device advertises that it is supporting. But I don't think that means that an augmentation is ever is ignored, but it might add nodes to the schema tree that aren't supported because a given feature isn't supported. Phil's example of a feature that relates to whether an SD card is present is interesting because it gives an example of when it might be useful to dynamically modify the set of supported features whilst a device is running. Likewise, I could see how the features could change due to adding/removing software components, or different revisions of hardware. Thanks, Rob > > Dale > . > From nobody Fri Mar 17 07:46:50 2017 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 B9CD2126C23 for ; Fri, 17 Mar 2017 07:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 m_vgGTHpWgND for ; Fri, 17 Mar 2017 07:46:47 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10EBE128796 for ; Fri, 17 Mar 2017 07:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3899; q=dns/txt; s=iport; t=1489762007; x=1490971607; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=DyDZmrraBEIekbx0Ueg4yrQlbfADIZyYi5bIS5VUWr8=; b=gmWIqpMNUEwS8UY2G/g/3OC9wVL1Y30GIwyuEvUVp1/jzfroo6yjFiw7 3irOIcYMezJ1xatnUkh+9d833m4iJh/XFcQhMMP9KMIGwGufI1ljjr0MK FChuw7J+K3JFToCHA/ctIsOdhtHLXu3GgLYe9rY0k4FzIMetyMaabWpdp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7AQDJ9ctY/xbLJq1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQyKmCNcXOQRh+IEo0wgg4fC4UuSgKDPhgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBAQE2NgYFDAICCxABAQMBAQEnBxsGBh8DBggGDQYCAQGJZAMNCA60K?= =?us-ascii?q?4c0DYMOAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWGSYIFCIJiglGCJCaFHgWcDzq?= =?us-ascii?q?OEYQxgXuIW4ZViE6CEmKIER84gQQjFggXFUGEVx2BY0A1hxwrghABAQE?= X-IronPort-AV: E=Sophos;i="5.36,177,1486425600"; d="scan'208";a="651519150" 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; 17 Mar 2017 14:46:45 +0000 Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2HEkibZ008116; Fri, 17 Mar 2017 14:46:44 GMT To: Ladislav Lhotka References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> Cc: Mehmet Ersue , Lou Berger , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , netmod@ietf.org From: Robert Wilton Message-ID: <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> Date: Fri, 17 Mar 2017 14:46:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:46:50 -0000 On 17/03/2017 14:32, Ladislav Lhotka wrote: >> On 17 Mar 2017, at 15:04, Robert Wilton wrote: >> >> Hi, >> >> Would 7950bis be allowed to have a normative reference to an Informational RFC that defined the YANG datastores? > My idea is that 7950bis should be made independent of any particular set of datastores, so such a normative reference shouldn't be needed. OK, if 70590bis was entirely datastore agnostic, then there would need to be a description of how YANG applies to a particular set of datastores (in particular the config: true|false statement), and which datastores are validated. Would that go in the revised datastores architecture or somewhere else? It wouldn't make sense to have to repeat this for every network configuration protocol. Thanks, Rob > > Lada > >> If we did a 7950bis document (and it isn't clear that one is actually required to support the revised datastores draft) then does that mean we would also need to have a new version of YANG? >> >> That would potentially seem like a backwards step. Also what would it mean for an implementation that is aware of the new datastores but is using a mix of YANG modules with different versions? >> >> I don't understand why the revised datastores draft should not be standards track once the various appendices have been moved out, noting that they are really only in the one draft at this stage because it seemed like that would make it easier for folks to review and comment on. >> >> Is the only issue here which WG the draft is being worked on? >> >> Thanks, >> Rob >> >> >> On 17/03/2017 13:22, Mehmet Ersue wrote: >>> I think YANG identities should be standardized with 7950bis. >>> >>> Mehmet >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, March 16, 2017 12:28 PM >>>> To: Juergen Schoenwaelder ; >>>> Mehmet Ersue >>>> Cc: 'Kent Watsen' ; netmod@ietf.org >>>> Subject: Re: [netmod] draft netmod charter update proposal >>>> >>>> Juergen, >>>> >>>> Thank you for the input. I think your point highlights how the technical >>>> contents of a document drives the intended status of a document. >>>> >>>> Lou >>>> >>>> PS as a reminder to all, intended status of documents is *not* typically >>>> included in charters and are not included in the distributed version. >>>> >>>> >>>> >>>> >>>> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder >>>> wrote: >>>> >>>>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: >>>>> >>>>>> That said different people including Netconf WG co-chairs think the DS >>>>>> concept document is Informational in nature and should be published as >>>> an >>>>>> Informational concept to be used in and adopted for the needs in >>> diverse >>>>>> protocol WGs. This is as I think also important to avoid an overlapping >>>>>> between NETCONF and NETMOD charters. >>>>> The current datastore draft includes concrete YANG idenity definitions >>>>> for datastores and origins and these definitions better be standards >>>>> track. >>>>> >>>>> /js >>>>> >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>> Fax: +49 421 200 3103 >>>>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > . > From nobody Fri Mar 17 07:48:29 2017 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 8505012946B for ; Fri, 17 Mar 2017 07:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 bkGBqEZSjzCH for ; Fri, 17 Mar 2017 07:48:23 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93C0129467 for ; Fri, 17 Mar 2017 07:48:22 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id u48so53510192wrc.0 for ; Fri, 17 Mar 2017 07:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=J5/EPb6DaZNTkUst2s4OxbfZ9ovHRfEPmAdDJ14RPdM=; b=qlph7kFlfS6V3jTm1Rpr23CJJbmYkTn6UpS4vt9dAubaUvD61ChNJj1GSRLhvFkgQN NDpmU8MfGtTEeXxa4uQCA+x7hVS0+agtviubi+Lk4gg4pYkmCSe2BYOJky9GQ2oRnk4S fMfYlTEsWB2IhZ9MMHBfXBFBuzn6g1R7uMpdZ8IxI4i5RbTu+qi2qaz7gZRO07YRdIo7 EKwA7/nlkajY/AiHLQyZVwtBUNeCgpHin8ZJQsgQnZcyRHDDd0P6TueTRzusPQirXHLy MwyCwLxVKlSa0dYJU0Dc/LuykTMnpO8u/zP29Cvk0ruVOe5dtmTPRsYvzT4SmbGKnDSV ywbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=J5/EPb6DaZNTkUst2s4OxbfZ9ovHRfEPmAdDJ14RPdM=; b=D4LROKWJIaMfbspcJYUlVHDnfY0oLD5x9jzlSpMGyRseL9xIDV45fdVVHM7xQGzyK7 gn6kXTb4H/sBBa3s6SJSKa9zqrfRSwrSo5CLmdKaEKmoFmCWdW57vW2D6ZPaNqRC7ydn 6UzzUqMgt3xxpVvqsNkiW/dmbbHCizEMQDn7PcxkFSeJerdi+QZoa9qOR3ApwLAxq35q Wps0cp/t5YqFM9nK2ZyCcqu82hR5iXCxGnwiWGy8LTkIXZVeNQW3zvSYBSRu0TzGCkvr 2QGFW7UHx9FfE8+GpQET/sqZRBxFhCWI3hcoM1m1lk4lDYLYcQGzBDZm+JWPh0O0/H8S tr8A== X-Gm-Message-State: AFeK/H1zGR9Tjy9pr4cRuOwt5kflOdxEV3DolinKp1Knhvv/PWdcRAheexfBLxPyFqBnPg== X-Received: by 10.223.169.161 with SMTP id b30mr13899761wrd.196.1489762101185; Fri, 17 Mar 2017 07:48:21 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p5B342480.dip0.t-ipconnect.de. [91.52.36.128]) by smtp.gmail.com with ESMTPSA id g43sm4899740wrg.35.2017.03.17.07.48.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 07:48:20 -0700 (PDT) From: "Mehmet Ersue" To: "'Robert Wilton'" , "'Lou Berger'" , "'Juergen Schoenwaelder'" Cc: References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> In-Reply-To: <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> Date: Fri, 17 Mar 2017 15:48:21 +0100 Message-ID: <008501d29f2d$86839240$938ab6c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUooBvvnQPAF+jVm3AXSML+0Bm+Ek1gGgPefFoIsAr4A= Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0207.58CBF734.014E,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 14:48:26 -0000 Hi Robert, I2RS has a different environment and datastore framework than NETCONF. NETCONF uses a different datastore framework compared to RESTCONF. DS conceptual model describes an overall picture and defines how it could like. Such a concept providing the basis for many environments cannot be standardized. Protocol WGs are in charge to choose a consistent subset out of the DS conceptual model and standardize the usage of these DSs as part of the protocol specification. BR, Mehmet > -----Original Message----- > From: Robert Wilton [mailto:rwilton@cisco.com] > Sent: Friday, March 17, 2017 3:04 PM > To: Mehmet Ersue ; 'Lou Berger' ; > 'Juergen Schoenwaelder' > Cc: netmod@ietf.org > Subject: Re: [netmod] draft netmod charter update proposal > > Hi, > > Would 7950bis be allowed to have a normative reference to an Informational > RFC that defined the YANG datastores? > > If we did a 7950bis document (and it isn't clear that one is actually required to > support the revised datastores draft) then does that mean we would also > need to have a new version of YANG? > > That would potentially seem like a backwards step. Also what would it mean > for an implementation that is aware of the new datastores but is using a mix > of YANG modules with different versions? > > I don't understand why the revised datastores draft should not be standards > track once the various appendices have been moved out, noting that they > are really only in the one draft at this stage because it seemed like that would > make it easier for folks to review and comment on. > > Is the only issue here which WG the draft is being worked on? > > Thanks, > Rob > > > On 17/03/2017 13:22, Mehmet Ersue wrote: > > I think YANG identities should be standardized with 7950bis. > > > > Mehmet > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Thursday, March 16, 2017 12:28 PM > >> To: Juergen Schoenwaelder ; > >> Mehmet Ersue > >> Cc: 'Kent Watsen' ; netmod@ietf.org > >> Subject: Re: [netmod] draft netmod charter update proposal > >> > >> Juergen, > >> > >> Thank you for the input. I think your point highlights how the > >> technical contents of a document drives the intended status of a > document. > >> > >> Lou > >> > >> PS as a reminder to all, intended status of documents is *not* > >> typically included in charters and are not included in the distributed > version. > >> > >> > >> > >> > >> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder > >> wrote: > >> > >>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: > >>> > >>>> That said different people including Netconf WG co-chairs think the > >>>> DS concept document is Informational in nature and should be > >>>> published as > >> an > >>>> Informational concept to be used in and adopted for the needs in > > diverse > >>>> protocol WGs. This is as I think also important to avoid an > >>>> overlapping between NETCONF and NETMOD charters. > >>> The current datastore draft includes concrete YANG idenity > >>> definitions for datastores and origins and these definitions better > >>> be standards track. > >>> > >>> /js > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >>> Fax: +49 421 200 3103 > >>> > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > From nobody Fri Mar 17 08:09:01 2017 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 9060512946E for ; Fri, 17 Mar 2017 08:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 gAx8EZ3SLxtd for ; Fri, 17 Mar 2017 08:08:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89842129464 for ; Fri, 17 Mar 2017 08:08:44 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id AEBBF61E3D; Fri, 17 Mar 2017 16:08:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1489763322; bh=YXw/AyGKo8LvDEPmEeeG1hAeyR863nJtcfJ4SJ7bWgE=; h=From:Date:To; b=TLfuJrxSD4oswtAz/O1Ix7+POjQGIH3DLvhnE5AdU4+coR1KBwjQsvS8Nvdk6JH/F XqWGEFSTcl4c/ipOFvsr6uVhzmzJ5ud85R6hhR00jS5eT9j7lGf+g3r6eDDIYko2oE H1M4rpy0ZeCQEkzD449XqW4EC1J/LdWHRepxGPx8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <18a2e042-919b-9468-2dc8-f751bd924125@cisco.com> Date: Fri, 17 Mar 2017 16:08:42 +0100 Cc: "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <18a2e042-919b-9468-2dc8-f751bd924125@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Comments on draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 15:08:59 -0000 > On 17 Mar 2017, at 15:11, Robert Wilton wrote: >=20 >=20 >=20 > On 17/03/2017 12:55, Ladislav Lhotka wrote: >> Hi Rob, >>=20 >> thank you for reading the draft. >>=20 >>> On 17 Mar 2017, at 13:30, Robert Wilton wrote: >>>=20 >>> Hi Lada, >>>=20 >>> I've had a quick scan of your YANG markup extension draft and I have = a few comments: >>>=20 >>> Allowing description, and similar descriptive statements, to use = something other than text seems like it could be useful in some cases. >>>=20 >>> I'm not sure that allowing the statements to use any text-like media = type is a good idea, this could increase the burden on tool makers if = each module author chooses their own preferred format. >>>=20 >>> Instead, I think that it might be better to restrict it to a very = small set of media types, that could be extended in future. I would = think that initially just allowing plain text and one particular flavour = of markdown would be a reasonable starting point. >> I agree although I am not sure that we can easily find an agreement = on the particular flavour. So maybe we can leave it open and let the = "market" decide. > I think that would be a mistake. How would device/tools vendors know = which versions to spend time implementing? I would agree to have a fixed choice in 6087bis, but there may be niche = communities or special cases that need something else, so YANG IMO = shouldn't preclude it a priori. >=20 >>=20 >>> I think that the only formats that should be allowed are those that = are still readily readable as plain text, so that tools that don't want = to parse the formatted text can still sensibly display the descriptive = statements. I.e. I don't think that it would be helpful to allow things = like text/xml since it isn't easy to read. >> Sure, and the draft says: >>=20 >> It is RECOMMENDED to use only media types representing = "lightweight" >> markup that is easy to read even in the unprocessed source form, = such >> as "text/markdown". > I was proposing REQUIRED instead of RECOMMENDED.=20 I usually write my modules in the YIN format with a very restricted set = of HTML tags that are used in the text arguments: = https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang#yin-schema-e= xtensions It would be useful to indicate "text/html" media type, and a YIN->YANG = convertor could translate it e.g. to "text/markdown". >=20 >>=20 >>> Allowing this extension on particular descriptive statements may = also be helpful. It seems plausible that the vast majority of these = statements in a module might just be written in plain text with just a = few of them using more advanced formatting like markdown. >> Yes, I was thinking about this. On the other hand, plain text is = typically compatible with any markup format, so this would probably be = useful only if somebody wanted to use multiple different markup formats = in the same module, which sounds crazy. But we can discuss it. > I was only thinking of a mix of some plain text descriptions and some = using markup. >=20 > Tooling may choose to format raw text differently from markup text = (e.g. converting lines into a paragraph). Also a markup processor would = be extra work, and may not warn or error on the structure of a plain = text description that doesn't conform to the markup rules. Actually, the design philosophy behind markdown is that there is no = formal concept of validity and so processors should never complain. On the other hand, it is conceivable that some descriptions may use a = more specialized format. For example, we could use a media type = (variant) for the top-level "contact" statements that we include in = modules, and tools could then more easily extract this metadata. So maybe we could really permit the "text-media-type" extension anywhere = and apply some natural scoping rules. Lada >=20 >>=20 >>> Finally, I have a concern that if more structured formatting in the = comments is used then would that encourage model writers to produce more = verbose comments, and if so that might possibly reduce the readability = of the modules. Although, I guess ultimately one has to trust the model = writers to do the right thing. >> Well, this draft doesn't permit anything above what module writers = can do already now - the descriptions etc. have to be valid YANG strings = as before. The only new thing is a piece of metadata that may be helpful = for some tools but that can also be safely ignored. > Thanks, > Rob >=20 >>=20 >> Thanks, Lada >>=20 >>> Thanks, >>> Rob >>>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >>=20 >>=20 >>=20 >>=20 >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 17 08:33:30 2017 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 6EA2F1294AB for ; Fri, 17 Mar 2017 08:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 ayjl6AnTEtOV for ; Fri, 17 Mar 2017 08:33:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED541294A9 for ; Fri, 17 Mar 2017 08:33:26 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id D025A6040C; Fri, 17 Mar 2017 16:33:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1489764804; bh=mq3GzvjWDAhyfWQZcp+Jz33Nt95fQ/mvjOvY3A1z1kc=; h=From:Date:To; b=IaXJbmPvYMuqU5k/IadIzqsgIcX4FGT4ZbgkFOFGMnEmtuuow5/+5Zp3ytDpkUJN9 WI/RFBm8rTYEH207kSbic0NmFAje5uTS7MRiSIye++3HNvWXeAy4464iOnC+zVNotA ljmSS8izIkQgaKtpEfzCr7CEPb5hJ0vXe+mksaSw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> Date: Fri, 17 Mar 2017 16:33:24 +0100 Cc: Mehmet Ersue , Lou Berger , =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 15:33:28 -0000 > On 17 Mar 2017, at 15:46, Robert Wilton wrote: >=20 >=20 >=20 > On 17/03/2017 14:32, Ladislav Lhotka wrote: >>> On 17 Mar 2017, at 15:04, Robert Wilton wrote: >>>=20 >>> Hi, >>>=20 >>> Would 7950bis be allowed to have a normative reference to an = Informational RFC that defined the YANG datastores? >> My idea is that 7950bis should be made independent of any particular = set of datastores, so such a normative reference shouldn't be needed. > OK, if 70590bis was entirely datastore agnostic, then there would need = to be a description of how YANG applies to a particular set of = datastores (in particular the config: true|false statement), and which = datastores are validated. Would that go in the revised I don't think that config true/false is necessarily tied to a particular = set of datastores, it can be generalized to RW/RO. > datastores architecture or somewhere else? It wouldn't make sense to = have to repeat this for every network configuration protocol. I think the structure of datastores and validation workflow could be = supplied as extra info, see item #3 near the end of this message: https://www.ietf.org/mail-archive/web/netmod/current/msg17673.html Lada >=20 > Thanks, > Rob >=20 >=20 >>=20 >> Lada >>=20 >>> If we did a 7950bis document (and it isn't clear that one is = actually required to support the revised datastores draft) then does = that mean we would also need to have a new version of YANG? >>>=20 >>> That would potentially seem like a backwards step. Also what would = it mean for an implementation that is aware of the new datastores but is = using a mix of YANG modules with different versions? >>>=20 >>> I don't understand why the revised datastores draft should not be = standards track once the various appendices have been moved out, noting = that they are really only in the one draft at this stage because it = seemed like that would make it easier for folks to review and comment = on. >>>=20 >>> Is the only issue here which WG the draft is being worked on? >>>=20 >>> Thanks, >>> Rob >>>=20 >>>=20 >>> On 17/03/2017 13:22, Mehmet Ersue wrote: >>>> I think YANG identities should be standardized with 7950bis. >>>>=20 >>>> Mehmet >>>>=20 >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Thursday, March 16, 2017 12:28 PM >>>>> To: Juergen Schoenwaelder ; >>>>> Mehmet Ersue >>>>> Cc: 'Kent Watsen' ; netmod@ietf.org >>>>> Subject: Re: [netmod] draft netmod charter update proposal >>>>>=20 >>>>> Juergen, >>>>>=20 >>>>> Thank you for the input. I think your point highlights how the = technical >>>>> contents of a document drives the intended status of a document. >>>>>=20 >>>>> Lou >>>>>=20 >>>>> PS as a reminder to all, intended status of documents is *not* = typically >>>>> included in charters and are not included in the distributed = version. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder >>>>> wrote: >>>>>=20 >>>>>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: >>>>>>=20 >>>>>>> That said different people including Netconf WG co-chairs think = the DS >>>>>>> concept document is Informational in nature and should be = published as >>>>> an >>>>>>> Informational concept to be used in and adopted for the needs in >>>> diverse >>>>>>> protocol WGs. This is as I think also important to avoid an = overlapping >>>>>>> between NETCONF and NETMOD charters. >>>>>> The current datastore draft includes concrete YANG idenity = definitions >>>>>> for datastores and origins and these definitions better be = standards >>>>>> track. >>>>>>=20 >>>>>> /js >>>>>>=20 >>>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>>> Fax: +49 421 200 3103 = >>>>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> . >>>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >>=20 >>=20 >>=20 >>=20 >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 17 08:36:20 2017 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 80BE11294AC; Fri, 17 Mar 2017 08:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 GU35sv-Ot-T9; Fri, 17 Mar 2017 08:36:16 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0115.outbound.protection.outlook.com [104.47.40.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7F3129479; Fri, 17 Mar 2017 08:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bMOoZ5N0kGgkWPwnuk1dxT76YHS5IadE7eKL8loYAiQ=; b=Y1ht6nZTtVD66KFwaKwiazvAJh5T06LE0Cht9c4sXl7dxxrCf6spef7HLdfDsEQqEBXEx8S/EEidNEF3hxqD+OLx3R9ZHSValiIr3jX/sNYTJ3AhZ316a+kJo+CPJHhFXlSs8x/sAu5HTmN9m0rVN4c7Yp/GuvJes7IY8LeEvrU= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Fri, 17 Mar 2017 15:36:13 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0977.013; Fri, 17 Mar 2017 15:36:13 +0000 From: Kent Watsen To: Ladislav Lhotka , Benoit Claise , "netmod@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [netmod] security considerations boilerplate updates to cover RESTCONF Thread-Index: AQHSnauR8sIuzui9AkeB/6DkSo5/yqGV5dqAgABeZQCAAM4UgIAAAraAgAAFZICAAAFwAIAADPwAgAHmpID//9qHAA== Date: Fri, 17 Mar 2017 15:36:13 +0000 Message-ID: <696C1A19-0A68-49A1-A6DA-8B3ACEEFC85B@juniper.net> References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:ao98TudQ8dC74o9WV51DsQKztwLu0LQ3XWp4MjPp34zQTVltxhGFRnF+iT+Hbuh5k/KkELoDHJmzLipeZpYsys2ciLim9+4m9ef5giFNHYs6mma0b3n4+nomVfpRgcG0OdKLsVGNtjZFGzTDuh9edwg2nRkUEddoUtyyaBye+IXOD90Hc2dOKpI58XWtFChtAAiFsT5TTem0mfAasMvUwp9uWlo8syKaWyE4xjXgATJgNwsxaqV2Tt8yZ/34bI6dEWKhlchVSKv9zNGdkBFTj9yx5VK9H2hczIkP71ZGczzy4W59h/G8gNM9EROLwBtJ2QuLfe2lvSrkmpKofQAQ0g== x-ms-office365-filtering-correlation-id: eef1dfa8-7965-4b7f-5cc1-08d46d4b5842 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(138986009662008)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123558025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0249EFCB0B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(24454002)(377454003)(93886004)(122556002)(53936002)(3280700002)(3660700001)(15650500001)(2906002)(8676002)(7736002)(81166006)(66066001)(38730400002)(102836003)(53546008)(6116002)(6246003)(3846002)(6486002)(54356999)(305945005)(99286003)(6436002)(36756003)(77096006)(189998001)(2501003)(2950100002)(6512007)(50986999)(25786008)(76176999)(6506006)(229853002)(5660300001)(8936002)(561944003)(83506001)(86362001)(6306002)(33656002)(4001350100001)(2201001)(5890100001)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 17 Mar 2017 15:36:13.4379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 15:36:19 -0000 DQpBZGRpbmcgYSBmaW5hbCB0aG91Z2h0IHRvIHRoaXMsIEkgZm91bmQgaXQgc3RyYW5nZSB3aGVu IEkgY29waWVkIHRoZQ0KU2VjdXJpdHkgZ3VpZGVsaW5lcyBpbnRvIHNvbWUgb2YgbXkgWUFORy1t b2RlbCBmb2N1c2VkIGRyYWZ0cywgdGhhdA0KSSBzdWRkZW5seSBoYWQgdG8gYWRkIEluZm9ybWF0 aXZlIFJlZmVyZW5jZXMgZm9yIHNvbWUgdHJhbnNwb3J0DQpwcm90b2NvbHMuICAgV2h5IHNob3Vs ZCBhIFlBTkcgbW9kZWwgY2FyZSBhYm91dCB0cmFuc3BvcnQgcHJvdG9jb2xzPw0KQXJlIHdlIGdv aW5nIHRvIGV4dGVuZCB0aGlzIHN0YXRlbWVudCB0byBpbmNsdWRlIGFsbCBmdXR1cmUgcHJvdG9j b2xzDQp0b28gKENvQVAsIGdSUEMsIGV0Yy4pPyAgTm90IHRvIG1lbnRpb24gWUFORyBtb2R1bGVz IHRoYXQgb25seSBkZWZpbmUNCmFuIGFydGlmYWN0IChpLmUuIHJjOnlhbmctZGF0YSkuICBXaGVy ZSBkb2VzIGl0IGVuZD8NCg0KSSB0aGluayB0aGUgOTAlIG9mIHRoZSBndWlkZWxpbmVzIGFyZSBv a2F5LCBwdXR0aW5nIGZvY3VzIG9uIHNlbGVjdA0KcmVhZGFibGUgbm9kZXMsIHdyaXRhYmxlIG5v ZGVzLCBhbmQgUlBDcyBpcyBnb29kLiAgSXQncyBqdXN0IHRoZSANCmZpcnN0ICBwYXJhZ3JhcGgg SSBoYXZlIGlzc3VlIHdpdGguICBUaGUgbW9yZSBJIHRoaW5rIGFib3V0IGl0LCB0aGUNCm1vcmUg SSB0aGluayB0aGUgZmlyc3QgcGFyYWdyYXBoIHNob3VsZCwgZm9yIHRoZSBtb3N0IHBhcnQsIGRp c2FwcGVhci4NCg0KSy4gLy8gY29udHJpYnV0b3INCg0KDQoNCi0tLS0tT1JJR0lOQUwgTUVTU0FH RS0tLS0tDQoNCktlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cml0ZXM6DQoNCj4g QSBjb3VwbGUgY29tbWVudHM6DQo+DQo+IDEpIGRyaWxsaW5nIGRvd24gb24gdGhlIG1hbmRhdG9y eS10by1pbXBsZW1lbnQgTkMvUkMgcHJvdG9jb2xzDQo+ICAgIGlzIHNvbWV3aGF0IG1pc3Npbmcg dGhlIHBvaW50LiAgVGhlIGltcG9ydGFudCBiaXQgaXMgdGhhdA0KPiAgICAqYWxsKiBwcm90b2Nv bHMgdHJhbnNwb3J0aW5nIFlBTkctbW9kZWxlZCBkYXRhICpvbmx5KiBoYXZlDQo+ICAgIHNlY3Vy ZSB0cmFuc3BvcnQgbGF5ZXJzLiAgTW9yZSBzcGVjaWZpY2FsbHksIFlBTkctbW9kZWxlZHENCj4g ICAgZGF0YSBtYXkgYmUgdHJhbnNwb3J0ZWQgb3ZlciBvdGhlciBwcm90b2NvbHMgKGUuZy4sIGNv YXApLA0KPiAgICBhbmQgYWxzbyBvbmUgb2YgdGhlIHByb3RvY29scyBoYXZlIGFuIGluc2VjdXJl IHRyYW5zcG9ydA0KPiAgICBwcm90b2NvbCAoZS5nLiwgaXQgZG9lc24ndCBtdWNoIGhlbHAgdG8g dGFsayBhYm91dCBIVFRQUw0KPiAgICBiZWluZyBtYW5kYXRvcnktdG8taW1wbGVtZW50IGlmIFJF U1RDT05GIGFsbG93ZWQgSFRUUCkuDQoNCkkgYWdyZWUsIGFuZCBpdCB3aWxsIGJlY29tZSBldmVu IG1vcmUgcmVsZXZhbnQgaWYgd2UgbWFrZSBZQU5HDQpwcm90b2NvbC1pbmRlcGVuZGVudC4gSW4g ZmFjdCwgZGF0YSBtb2RlbHMgbWF5IGJlIHVzZWZ1bCBldmVuIHdpdGhvdXQNCmFueSBuZXR3b3Jr IHRyYW5zcG9ydCBpbnZvbHZlZCwgZS5nLiBmb3IgYSBsb2NhbCBDTEkgaW1wbGVtZW50YXRpb24u DQoNCj4NCj4gMikganVzdCBzdGF0aW5nIHRoYXQgdGhlcmUgYXJlIHNlY3VyZSB0cmFuc3BvcnQg bGF5ZXJzIHN0aWxsDQo+ICAgIGlzbuKAmXQgc3VmZmljaWVudCwgYXMgdGhlc2UgcHJvdG9jb2xz IG11c3QgYWxzbyByZXF1aXJlDQo+ICAgIG11dHVhbCBhdXRoZW50aWNhdGlvbiBpbiBvcmRlciB0 byBiZSBzZWN1cmUsIGFuZCBmb3IgDQo+ICAgIHN0YXRlbWVudHMgcmVnYXJkaW5nIE5BQ00gdG8g bWFrZSBzZW5zZS4gIFRoZSB0ZXh0IEkgcG9zdGVkDQo+ICAgIGJlZm9yZSBoYWQgYSBzdGF0ZW1l bnQgbGlrZSB0aGlzIGluIGl0Lg0KDQpSaWdodCwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXR0 YWNoZWQgdG8gZGF0YSBtb2RlbHMgc2hvdWxkIGRlYWwgd2l0aA0Kc2VjdXJpdHkgYXNwZWN0cyBv ZiB0aGUgc3RhdGljIGRhdGEgKHdoaWNoIGl0ZW1zIGFyZSBzZWN1cml0eS1zZW5zaXRpdmUNCmV0 Yy4pIGFuZCBub3Qgd2l0aCB0cmFuc3BvcnQgc2VjdXJpdHkuDQoNCkxhZGENCg0KPg0KPiBJJ20g YmVnaW5uaW5nIHRvIGJlY29tZSBhIGZhbiBvZiB0aGUgaWRlYSBvZiBkZWZpbmluZyBhIGdlbmVy aWMNCj4gIlJlcXVpcmVtZW50cyBmb3IgUHJvdG9jb2xzIFRyYW5zcG9ydGluZyBZQU5HLW1vZGVs ZWQgRGF0YSINCj4gZG9jdW1lbnQgLSB0aGF0IHdvdWxkIG5vdCBvbmx5IGRpc2N1c3Mgc2VjdXJp dHkgYXNwZWN0cywgYnV0DQo+IGFsc28gZ2VuZXJpYyBwcm90b2NvbCBvcGVyYXRpb25zLCB0aGF0 IGRvY3VtZW50cyBsaWtlIE5DLCBSQywNCj4gQ29BUCwgZXRjLiBjYW4gcG9pbnQgdG8uLi5hbmQg ZXZlbiBZQU5HIChSRkMgNzk1MCksIHJhdGhlciB0aGFuDQo+IHBvaW50aW5nIGRpcmVjdGx5IGF0 IE5FVENPTkYgYXMgaXQgZG9lcyB0b2RheS4uLg0KPg0KPiBLZW50IC8vIGNvbnRyaWJ1dG9yDQo+ DQo+DQo+IE9uIDMvMTYvMjAxNyA4OjU2IEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgd3JvdGU6 DQo+PiBPbiBUaHUsIE1hciAxNiwgMjAxNyBhdCAwODozNzozOUFNICswMTAwLCBCZW5vaXQgQ2xh aXNlIHdyb3RlOg0KPj4+IExhdGVzdCBwcm9wb3NhbDoNCj4+Pg0KPj4+ICAgICAgVGhlIFlBTkcg bW9kdWxlIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBkZXNpZ25lZCB0byBiZSBhY2Nlc3Nl ZA0KPj4+ICAgICAgdmlhIG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbHMgc3VjaCBhcyBORVRD T05GIFtSRkM2MjQxXSBvcg0KPj4+ICAgICAgUkVTVENPTkYgW1JGQzgwNDBdLiBUaGUgbG93ZXN0 IE5FVENPTkYgbGF5ZXIgaXMgdGhlIHNlY3VyZSB0cmFuc3BvcnQNCj4+PiBsYXllciwNCj4+PiAg ICAgIGFuZCBtYW5kYXRvcnktdG8taW1wbGVtZW50IHNlY3VyZSB0cmFuc3BvcnQgaXMgU2VjdXJl IFNoZWxsIChTU0gpDQo+Pj4gW1JGQzYyNDJdLA0KPj4+ICAgICAgd2hpbGUgdGhlIGxvd2VzdCBS RVNUQ09ORiBsYXllciBpcyBIVFRQLCBhbmQgdGhlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQNCj4+ PiBzZWN1cmUNCj4+PiAgICAgIHRyYW5zcG9ydCBpcyBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkg KFRMUykgW1JGQzUyNDZdLg0KPj4gUGlja2luZyB3b3JkaW5nIGZyb20gU2VjdGlvbiAxMiBvZiBS RkMgODA0MCB0byByZXBsYWNlIHlvdXIgc2Vjb25kDQo+PiBzZW50ZW5jZSBJIGdldCB0aGlzOg0K Pj4NCj4+ICAgICAgVGhlIFlBTkcgbW9kdWxlIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBk ZXNpZ25lZCB0byBiZQ0KPj4gICAgICBhY2Nlc3NlZCB2aWEgbmV0d29yayBtYW5hZ2VtZW50IHBy b3RvY29scyBzdWNoIGFzIE5FVENPTkYNCj4+ICAgICAgW1JGQzYyNDFdIG9yIFJFU1RDT05GIFtS RkM4MDQwXS4gVGhlIGxvd2VzdCBORVRDT05GIGxheWVyIGlzIHRoZQ0KPj4gICAgICBzZWN1cmUg dHJhbnNwb3J0IGxheWVyLCBhbmQgdGhlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgc2VjdXJlDQo+ PiAgICAgIHRyYW5zcG9ydCBpcyBTZWN1cmUgU2hlbGwgKFNTSCkgW1JGQzYyNDJdLiBUaGUgbG93 ZXN0IFJFU1RDT05GDQo+PiAgICAgIGxheWVyIGlzIEhUVFBTLCBhbmQgdGhlIG1hbmRhdG9yeS10 by1pbXBsZW1lbnQgc2VjdXJlIHRyYW5zcG9ydCBpcw0KPj4gICAgICBUTFMgW1JGQzUyNDZdLg0K Pj4NCj4+ICAgICAgVGhlIE5FVENPTkYgYWNjZXNzIGNvbnRyb2wgbW9kZWwgW1JGQzY1MzZdIHBy b3ZpZGVzIHRoZSBtZWFucyB0bw0KPj4gICAgICByZXN0cmljdCBhY2Nlc3MgZm9yIHBhcnRpY3Vs YXIgTkVUQ09ORiBvciBSRVNUQ09ORiB1c2VycyB0byBhDQo+PiAgICAgIHByZS1jb25maWd1cmVk IHN1YnNldCBvZiBhbGwgYXZhaWxhYmxlIE5FVENPTkYgb3IgUkVTVENPTkYNCj4+ICAgICAgcHJv dG9jb2wgb3BlcmF0aW9ucyBhbmQgY29udGVudC4NCj4gWWVzLCB0aGFuayB5b3UuDQo+DQo+IFJl Z2FyZHMsIEIuDQo+Pg0KPj4gL2pzDQo+Pg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5l dG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZA0KDQotLSANCkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNClBHUCBLZXkgSUQ6IDB4 QjhGOTJCMDhBOUY3NkM2Nw0KDQoNCg== From nobody Fri Mar 17 08:40:13 2017 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 30A1A1294A6 for ; Fri, 17 Mar 2017 08:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 K6DBjdOdYEOs for ; Fri, 17 Mar 2017 08:40:09 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0102.outbound.protection.outlook.com [104.47.32.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C447512945B for ; Fri, 17 Mar 2017 08:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hh1ovVg02UO7HV+7b3BiFUphE+4Y66V4QrrUxH25vwg=; b=X3/ARZL7ZGd3ZXVs0fxWmeKjanb1xckpgpUaMkg+gJQecafqSIm0sH2LHnHS/FZZmopqpKP/9TM+nYth0MmYZkItJndgl2t9vu3Zxo1Ai7/L9PkqMuyfGku17UNoR9f0mOu5a2Tfr+PBnVl11psjx8LGcMyRzRf3h5VE+y12bcY= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Fri, 17 Mar 2017 15:40:07 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0977.013; Fri, 17 Mar 2017 15:40:07 +0000 From: Kent Watsen To: Ladislav Lhotka , Robert Wilton CC: "netmod@ietf.org" Thread-Topic: [netmod] draft netmod charter update proposal Thread-Index: AQHSjWtMgvd1I9y/IUSjVG5c54oSBgFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUoqgvM/28IAKaKVwgFNKOYCAAE8kAIABsoGAgAALqACAAAe/AIAABBAAgAANDAD//77RAA== Date: Fri, 17 Mar 2017 15:40:07 +0000 Message-ID: References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> In-Reply-To: <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:ss+wmO7n8etIRQ3cMfhM1zI5qxwUrXqoJRkDdfRxcT578GmTZJzs/GOwDhVBhmDsE0v42Tcge/4l4hwLO7lf0rknqdn8eOe/pnFwf9MZgwBZ2e44/QuwqSNc7n+oumqHXI42KBOFmnkNxDvcUQkA7TjgXcoazuxKvkHIPZa/TvUfdPqr76Eo5SYrt7pP37uDi0UZId/26hH+Y/aZyBGIQwGBpi7ho6gFdkBF1anvH8JJ0rbQixzUt9z9DdZeXQwcJ3PsUqSGznC9BMF9FTSS4B6uBWpHGoTu4wL4mzy8GuBGQaO+Z7LIBavFixxxt7TJhwenClAY7OtZoFNps7qHGw== x-ms-office365-filtering-correlation-id: 09ec16d9-85eb-4935-6378-08d46d4be38f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(271806183753584)(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123558025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0249EFCB0B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39850400002)(39410400002)(39450400003)(377454003)(24454002)(13464003)(50986999)(6512007)(229853002)(25786008)(76176999)(6506006)(54356999)(6486002)(305945005)(6436002)(36756003)(77096006)(2950100002)(189998001)(99286003)(4001350100001)(2900100001)(561944003)(83506001)(5660300001)(8936002)(6306002)(33656002)(86362001)(7736002)(8676002)(10710500007)(81166006)(345774005)(3660700001)(122556002)(93886004)(3280700002)(53936002)(2420400007)(15650500001)(2906002)(4326008)(6246003)(3846002)(6116002)(66066001)(102836003)(53546008)(38730400002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4B8CD5BF04B2BC43B06655A08E20144F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2017 15:40:07.1430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 15:40:11 -0000 SGkgTGFkYSwNCg0KSSB0aGluayBzb21lIG9mIHdoYXQgeW91J3JlIGdldHRpbmcgYXQgaXMgaW4g dGhlc2UgZ3VpZGVsaW5lczoNCg0KICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzLTAxI3NlY3Rpb24tNQ0KDQpCdXQgeW91J3Jl IHRoaW5raW5nIGFib3V0IHNvbWV0aGluZyBtb3JlIGdlbmVyYWxpemVkPw0KDQpLZW50ICAvLyBj b250cmlidXRvcg0KDQoNCi0tLS0tT1JJR0lOQUwgTUVTU0FHRS0tLS0tDQoNCj4gT24gMTcgTWFy IDIwMTcsIGF0IDE1OjQ2LCBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6 DQo+IA0KPiANCj4gDQo+IE9uIDE3LzAzLzIwMTcgMTQ6MzIsIExhZGlzbGF2IExob3RrYSB3cm90 ZToNCj4+PiBPbiAxNyBNYXIgMjAxNywgYXQgMTU6MDQsIFJvYmVydCBXaWx0b24gPHJ3aWx0b25A Y2lzY28uY29tPiB3cm90ZToNCj4+PiANCj4+PiBIaSwNCj4+PiANCj4+PiBXb3VsZCA3OTUwYmlz IGJlIGFsbG93ZWQgdG8gaGF2ZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gYW4gSW5mb3JtYXRp b25hbCBSRkMgdGhhdCBkZWZpbmVkIHRoZSBZQU5HIGRhdGFzdG9yZXM/DQo+PiBNeSBpZGVhIGlz IHRoYXQgNzk1MGJpcyBzaG91bGQgYmUgbWFkZSBpbmRlcGVuZGVudCBvZiBhbnkgcGFydGljdWxh ciBzZXQgb2YgZGF0YXN0b3Jlcywgc28gc3VjaCBhIG5vcm1hdGl2ZSByZWZlcmVuY2Ugc2hvdWxk bid0IGJlIG5lZWRlZC4NCj4gT0ssIGlmIDcwNTkwYmlzIHdhcyBlbnRpcmVseSBkYXRhc3RvcmUg YWdub3N0aWMsIHRoZW4gdGhlcmUgd291bGQgbmVlZCB0byBiZSBhIGRlc2NyaXB0aW9uIG9mIGhv dyBZQU5HIGFwcGxpZXMgdG8gYSBwYXJ0aWN1bGFyIHNldCBvZiBkYXRhc3RvcmVzIChpbiBwYXJ0 aWN1bGFyIHRoZSBjb25maWc6IHRydWV8ZmFsc2Ugc3RhdGVtZW50KSwgYW5kIHdoaWNoIGRhdGFz dG9yZXMgYXJlIHZhbGlkYXRlZC4gIFdvdWxkIHRoYXQgZ28gaW4gdGhlIHJldmlzZWQNCg0KSSBk b24ndCB0aGluayB0aGF0IGNvbmZpZyB0cnVlL2ZhbHNlIGlzIG5lY2Vzc2FyaWx5IHRpZWQgdG8g YSBwYXJ0aWN1bGFyIHNldCBvZiBkYXRhc3RvcmVzLCBpdCBjYW4gYmUgZ2VuZXJhbGl6ZWQgdG8g UlcvUk8uDQoNCj4gIGRhdGFzdG9yZXMgYXJjaGl0ZWN0dXJlIG9yIHNvbWV3aGVyZSBlbHNlPyAg SXQgd291bGRuJ3QgbWFrZSBzZW5zZSB0byBoYXZlIHRvIHJlcGVhdCB0aGlzIGZvciBldmVyeSBu ZXR3b3JrIGNvbmZpZ3VyYXRpb24gcHJvdG9jb2wuDQoNCkkgdGhpbmsgdGhlIHN0cnVjdHVyZSBv ZiBkYXRhc3RvcmVzIGFuZCB2YWxpZGF0aW9uIHdvcmtmbG93IGNvdWxkIGJlIHN1cHBsaWVkIGFz IGV4dHJhIGluZm8sIHNlZSBpdGVtICMzIG5lYXIgdGhlIGVuZCBvZiB0aGlzIG1lc3NhZ2U6DQoN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNn MTc2NzMuaHRtbA0KDQpMYWRhDQoNCj4gDQo+IFRoYW5rcywNCj4gUm9iDQo+IA0KPiANCj4+IA0K Pj4gTGFkYQ0KPj4gDQo+Pj4gSWYgd2UgZGlkIGEgNzk1MGJpcyBkb2N1bWVudCAoYW5kIGl0IGlz bid0IGNsZWFyIHRoYXQgb25lIGlzIGFjdHVhbGx5IHJlcXVpcmVkIHRvIHN1cHBvcnQgdGhlIHJl dmlzZWQgZGF0YXN0b3JlcyBkcmFmdCkgdGhlbiBkb2VzIHRoYXQgbWVhbiB3ZSB3b3VsZCBhbHNv IG5lZWQgdG8gaGF2ZSBhIG5ldyB2ZXJzaW9uIG9mIFlBTkc/DQo+Pj4gDQo+Pj4gVGhhdCB3b3Vs ZCBwb3RlbnRpYWxseSBzZWVtIGxpa2UgYSBiYWNrd2FyZHMgc3RlcC4gIEFsc28gd2hhdCB3b3Vs ZCBpdCBtZWFuIGZvciBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IGlzIGF3YXJlIG9mIHRoZSBuZXcg ZGF0YXN0b3JlcyBidXQgaXMgdXNpbmcgYSBtaXggb2YgWUFORyBtb2R1bGVzIHdpdGggZGlmZmVy ZW50IHZlcnNpb25zPw0KPj4+IA0KPj4+IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdGhlIHJldmlz ZWQgZGF0YXN0b3JlcyBkcmFmdCBzaG91bGQgbm90IGJlIHN0YW5kYXJkcyB0cmFjayBvbmNlIHRo ZSB2YXJpb3VzIGFwcGVuZGljZXMgaGF2ZSBiZWVuIG1vdmVkIG91dCwgbm90aW5nIHRoYXQgdGhl eSBhcmUgcmVhbGx5IG9ubHkgaW4gdGhlIG9uZSBkcmFmdCBhdCB0aGlzIHN0YWdlIGJlY2F1c2Ug aXQgc2VlbWVkIGxpa2UgdGhhdCB3b3VsZCBtYWtlIGl0IGVhc2llciBmb3IgZm9sa3MgdG8gcmV2 aWV3IGFuZCBjb21tZW50IG9uLg0KPj4+IA0KPj4+IElzIHRoZSBvbmx5IGlzc3VlIGhlcmUgd2hp Y2ggV0cgdGhlIGRyYWZ0IGlzIGJlaW5nIHdvcmtlZCBvbj8NCj4+PiANCj4+PiBUaGFua3MsDQo+ Pj4gUm9iDQo+Pj4gDQo+Pj4gDQo+Pj4gT24gMTcvMDMvMjAxNyAxMzoyMiwgTWVobWV0IEVyc3Vl IHdyb3RlOg0KPj4+PiBJIHRoaW5rIFlBTkcgaWRlbnRpdGllcyBzaG91bGQgYmUgc3RhbmRhcmRp emVkIHdpdGggNzk1MGJpcy4NCj4+Pj4gDQo+Pj4+IE1laG1ldA0KPj4+PiANCj4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJl cmdlckBsYWJuLm5ldF0NCj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNiwgMjAxNyAxMjoy OCBQTQ0KPj4+Pj4gVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGph Y29icy11bml2ZXJzaXR5LmRlPjsNCj4+Pj4+IE1laG1ldCBFcnN1ZSA8bWVyc3VlQGdtYWlsLmNv bT4NCj4+Pj4+IENjOiAnS2VudCBXYXRzZW4nIDxrd2F0c2VuQGp1bmlwZXIubmV0PjsgbmV0bW9k QGlldGYub3JnDQo+Pj4+PiBTdWJqZWN0OiBSZTogW25ldG1vZF0gZHJhZnQgbmV0bW9kIGNoYXJ0 ZXIgdXBkYXRlIHByb3Bvc2FsDQo+Pj4+PiANCj4+Pj4+IEp1ZXJnZW4sDQo+Pj4+PiANCj4+Pj4+ IFRoYW5rIHlvdSBmb3IgdGhlIGlucHV0LiAgSSB0aGluayB5b3VyIHBvaW50IGhpZ2hsaWdodHMg aG93IHRoZSB0ZWNobmljYWwNCj4+Pj4+IGNvbnRlbnRzIG9mIGEgZG9jdW1lbnQgZHJpdmVzIHRo ZSBpbnRlbmRlZCBzdGF0dXMgb2YgYSBkb2N1bWVudC4NCj4+Pj4+IA0KPj4+Pj4gTG91DQo+Pj4+ PiANCj4+Pj4+IFBTIGFzIGEgcmVtaW5kZXIgdG8gYWxsLCBpbnRlbmRlZCBzdGF0dXMgb2YgZG9j dW1lbnRzIGlzICpub3QqIHR5cGljYWxseQ0KPj4+Pj4gaW5jbHVkZWQgaW4gY2hhcnRlcnMgYW5k IGFyZSBub3QgaW5jbHVkZWQgaW4gdGhlIGRpc3RyaWJ1dGVkIHZlcnNpb24uDQo+Pj4+PiANCj4+ Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE9uIE1hcmNoIDE2LCAyMDE3IDI6NDQ6NTMgQU0g SnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+Pj4+PiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4+IE9uIFdlZCwgTWFyIDE1LCAyMDE3IGF0 IDAyOjUwOjA2UE0gKzAxMDAsIE1laG1ldCBFcnN1ZSB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+Pj4g VGhhdCBzYWlkIGRpZmZlcmVudCBwZW9wbGUgaW5jbHVkaW5nIE5ldGNvbmYgV0cgY28tY2hhaXJz IHRoaW5rIHRoZSBEUw0KPj4+Pj4+PiBjb25jZXB0IGRvY3VtZW50IGlzIEluZm9ybWF0aW9uYWwg aW4gbmF0dXJlIGFuZCBzaG91bGQgYmUgcHVibGlzaGVkIGFzDQo+Pj4+PiBhbg0KPj4+Pj4+PiBJ bmZvcm1hdGlvbmFsIGNvbmNlcHQgdG8gYmUgdXNlZCBpbiBhbmQgYWRvcHRlZCBmb3IgdGhlIG5l ZWRzIGluDQo+Pj4+IGRpdmVyc2UNCj4+Pj4+Pj4gcHJvdG9jb2wgV0dzLiBUaGlzIGlzIGFzIEkg dGhpbmsgYWxzbyBpbXBvcnRhbnQgdG8gYXZvaWQgYW4gb3ZlcmxhcHBpbmcNCj4+Pj4+Pj4gYmV0 d2VlbiBORVRDT05GIGFuZCBORVRNT0QgY2hhcnRlcnMuDQo+Pj4+Pj4gVGhlIGN1cnJlbnQgZGF0 YXN0b3JlIGRyYWZ0IGluY2x1ZGVzIGNvbmNyZXRlIFlBTkcgaWRlbml0eSBkZWZpbml0aW9ucw0K Pj4+Pj4+IGZvciBkYXRhc3RvcmVzIGFuZCBvcmlnaW5zIGFuZCB0aGVzZSBkZWZpbml0aW9ucyBi ZXR0ZXIgYmUgc3RhbmRhcmRzDQo+Pj4+Pj4gdHJhY2suDQo+Pj4+Pj4gDQo+Pj4+Pj4gL2pzDQo+ Pj4+Pj4gDQo+Pj4+Pj4gLS0NCj4+Pj4+PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAg IEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPj4+Pj4+IFBob25lOiArNDkgNDIxIDIw MCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4+ Pj4+PiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11 bml2ZXJzaXR5LmRlLz4NCj4+Pj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+PiBuZXRt b2RAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QNCj4+Pj4gLg0KPj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0 Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K Pj4gLS0NCj4+IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+IFBHUCBLZXkgSUQ6IDB4 QjhGOTJCMDhBOUY3NkM2Nw0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IC4NCg0KLS0NCkxh ZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNClBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2 Nw0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg0K From nobody Fri Mar 17 08:41:54 2017 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 15E8E12945B; Fri, 17 Mar 2017 08:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 xSSAu3iPuOEQ; Fri, 17 Mar 2017 08:41:51 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68DA1294A6; Fri, 17 Mar 2017 08:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4825; q=dns/txt; s=iport; t=1489765310; x=1490974910; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0xcXSgs64C5bwYOl/NyxFOMnQRgY0dqa9gkGsRKpMc8=; b=LNcsjItq6c28QtvzQWCoYW5/LAcSE2QNKTW18daFIMXbrzhzEFt0g8dQ Md37mhj2yZcKQuHoNQejtOMZBaNPHgkOqQYlVWCzaOYXEy5ueBr5pw0pV fwnTUqJuiU5nDvOYIGmsidETq7JMq3wPeVGNQCu3rzMiSPYyW1+HGQn5/ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAQDqAsxY/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHjWqRW5VCgg4fC4UuSgKCfz8YAQIBAQEBAQEBayiFFgE?= =?us-ascii?q?BAQMBAWwbAgEIDgouJwslAgQBEooADrRDilMBAQEBAQEBAQEBAQEBAQEBAQEBG?= =?us-ascii?q?gWLPYo5BZAcjC0BiiCIIZErk1IBHziBBFgVQYZXdYhKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,177,1486425600"; d="scan'208";a="395599116" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2017 15:41:49 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v2HFfnfa016357 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Mar 2017 15:41:49 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 17 Mar 2017 11:41:48 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 17 Mar 2017 11:41:48 -0400 From: "Acee Lindem (acee)" To: Kent Watsen , Ladislav Lhotka , "Benoit Claise (bclaise)" , "netmod@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [netmod] security considerations boilerplate updates to cover RESTCONF Thread-Index: AQHSnauTLk4wWtsVc0C/SyKyHk76UqGV5dqAgABeZQCAAM4UgIAAAraAgAAFZICAAAFwAIAADPwAgAIpsoCAAB2WgP//vn6A Date: Fri, 17 Mar 2017 15:41:48 +0000 Message-ID: References: <20170313212537.GB53972@elstar.local> <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> <696C1A19-0A68-49A1-A6DA-8B3ACEEFC85B@juniper.net> In-Reply-To: <696C1A19-0A68-49A1-A6DA-8B3ACEEFC85B@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 15:41:53 -0000 I=B9m if I looked hard enough I'd find it. However, I imagine many others will have the same question. Where is Wiki or format URL where the boilerplate will be maintained? Thanks, Acee On 3/17/17, 11:36 AM, "netmod on behalf of Kent Watsen" wrote: > >Adding a final thought to this, I found it strange when I copied the >Security guidelines into some of my YANG-model focused drafts, that >I suddenly had to add Informative References for some transport >protocols. Why should a YANG model care about transport protocols? >Are we going to extend this statement to include all future protocols >too (CoAP, gRPC, etc.)? Not to mention YANG modules that only define >an artifact (i.e. rc:yang-data). Where does it end? > >I think the 90% of the guidelines are okay, putting focus on select >readable nodes, writable nodes, and RPCs is good. It's just the >first paragraph I have issue with. The more I think about it, the >more I think the first paragraph should, for the most part, disappear. > >K. // contributor > > > >-----ORIGINAL MESSAGE----- > >Kent Watsen writes: > >> A couple comments: >> >> 1) drilling down on the mandatory-to-implement NC/RC protocols >> is somewhat missing the point. The important bit is that >> *all* protocols transporting YANG-modeled data *only* have >> secure transport layers. More specifically, YANG-modeledq >> data may be transported over other protocols (e.g., coap), >> and also one of the protocols have an insecure transport >> protocol (e.g., it doesn't much help to talk about HTTPS >> being mandatory-to-implement if RESTCONF allowed HTTP). > >I agree, and it will become even more relevant if we make YANG >protocol-independent. In fact, data models may be useful even without >any network transport involved, e.g. for a local CLI implementation. > >> >> 2) just stating that there are secure transport layers still >> isn=B9t sufficient, as these protocols must also require >> mutual authentication in order to be secure, and for >> statements regarding NACM to make sense. The text I posted >> before had a statement like this in it. > >Right, security considerations attached to data models should deal with >security aspects of the static data (which items are security-sensitive >etc.) and not with transport security. > >Lada > >> >> I'm beginning to become a fan of the idea of defining a generic >> "Requirements for Protocols Transporting YANG-modeled Data" >> document - that would not only discuss security aspects, but >> also generic protocol operations, that documents like NC, RC, >> CoAP, etc. can point to...and even YANG (RFC 7950), rather than >> pointing directly at NETCONF as it does today... >> >> Kent // contributor >> >> >> On 3/16/2017 8:56 AM, Juergen Schoenwaelder wrote: >>> On Thu, Mar 16, 2017 at 08:37:39AM +0100, Benoit Claise wrote: >>>> Latest proposal: >>>> >>>> The YANG module defined in this document is designed to be >>>>accessed >>>> via network management protocols such as NETCONF [RFC6241] or >>>> RESTCONF [RFC8040]. The lowest NETCONF layer is the secure >>>>transport >>>> layer, >>>> and mandatory-to-implement secure transport is Secure Shell (SSH) >>>> [RFC6242], >>>> while the lowest RESTCONF layer is HTTP, and the >>>>mandatory-to-implement >>>> secure >>>> transport is Transport Layer Security (TLS) [RFC5246]. >>> Picking wording from Section 12 of RFC 8040 to replace your second >>> sentence I get this: >>> >>> The YANG module defined in this document is designed to be >>> accessed via network management protocols such as NETCONF >>> [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the >>> secure transport layer, and the mandatory-to-implement secure >>> transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF >>> layer is HTTPS, and the mandatory-to-implement secure transport is >>> TLS [RFC5246]. >>> >>> The NETCONF access control model [RFC6536] provides the means to >>> restrict access for particular NETCONF or RESTCONF users to a >>> pre-configured subset of all available NETCONF or RESTCONF >>> protocol operations and content. >> Yes, thank you. >> >> Regards, B. >>> >>> /js >>> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: 0xB8F92B08A9F76C67 > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Mar 17 09:59:08 2017 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 369EC129484 for ; Fri, 17 Mar 2017 09:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 KPqwE151uwGz for ; Fri, 17 Mar 2017 09:59:04 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0122.outbound.protection.outlook.com [104.47.0.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0791201F2 for ; Fri, 17 Mar 2017 09:59:03 -0700 (PDT) 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; bh=hJmRf+8qsqRkJoqgZ26RiH0A8Q9ivKoCLWFJ/2AAALo=; b=jiof5raMo/c9lxCrLmfqycd3ZbVrGKIL7n/F1IMo3gVGPS35DRB5wGY1KD6gLQEgoh+4Ual/QQO50VMB0wWsUbgSyzhQrbtSLrfTTACpMnZubLB5ZyjHhHb8GK7lHsRenOKe2KyaMymlmWTXBe0jKEq1gtMLDn1ki19TLbxXQPY= Authentication-Results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.203.75) by AM5PR0701MB2995.eurprd07.prod.outlook.com (10.168.156.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Fri, 17 Mar 2017 16:59:00 +0000 Message-ID: <01b901d29f3f$91b85b20$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka CC: References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> Date: Fri, 17 Mar 2017 16:57:24 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.203.75] X-ClientProxiedBy: HE1P18901CA0004.EURP189.PROD.OUTLOOK.COM (10.168.181.142) To AM5PR0701MB2995.eurprd07.prod.outlook.com (10.168.156.145) X-MS-Office365-Filtering-Correlation-Id: 3cad46a4-1ede-49b3-85ae-08d46d56e921 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2995; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 3:cgt8uj4qF2Jym4jSqPba9EZyc//SnD2cyH9sm6yBSNKfs9sf0/UypYVb8WT+VnwGyo9JMduVgla+UC7HWq8baFykN+hDw90YVr+MepDWWcl80fdiVbunnZdATR6CGERBnJAR350+GOxXbekJogmT42w9aTmllp+HkvPKTV/xqRu5MIY2HppeMzXbTZ1q+3EE4d6+3Hy7XEHO3haY9BLBhh+XKNWr3IZpPZ3rMwg2Q4EpWlbiokuiWyKMpx+V4CNMC7ytF+hs3ui2XVSvLxofdA==; 25:JEl2W1cifYRiaHTEFyopmQlvdTW97w3Uix/dIwllm/cHW37JKMjaHsK3GMyVNw1AI+E8ojRDkmZYjMK79/THnlyUfnHdC+oysvTyJtV+/fyf/2uLCfzGBu2GUd6YadHeQAbv27Rl6p7D3tUihgRf85f0lbyOoYcEh+LAFZWn/B7Bi6EYVVZMDBisikkdhnXUczXazWApHwbGe3y9e3mXMNgWoFOuq81dmjEavNaGEToLgoIw4NcPMfBgXNPaOdukKN4wlRN8nK+aQXZ0aCtjS9li/p5MwLlSFOS8tUSBukRDvo4PMsj+RbMqNSkhS+tHMR8jmwdjKi/G/mw2Ayy+0/hhcvSbgpHufF16Kfa74NAlGFlkCoolnHzys1Vl6i3poTHyxYO4Xr8Pr2SraYxBVcss22v3EEM0LRslBRgXpC9ZslvI5cSUP/Q8D/JW3cUoY21tMExekOvAREp2ey6T7w== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 31:L4FAWdN2qtnTzv0DKj5TLeo8hp/dA3iCZFnM+oVJ9Yu9jgHCmH7wcSgkzPKm+6SqlEZzFA9SuB0ZCcORaj8bQsGQjdEfvWN2IBkF/Lpm0EApVpxJxbXt+AVM51dCty+7v4kcNOerIjpOTnNr1ekdliY0C5Kwz9AraWnU+dCuuIN4FBtUaJ83q+ipShibHegSji8K0F2VbCswQh9I4pQsc3gdTGzH8197eczafkMa7hcGhn1qufWhXBPdVwl6hQX4d7XBtvzy2aP+/Em62pt7lQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(20161123558025)(6072148); SRVR:AM5PR0701MB2995; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2995; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 4:BOZTQdJlCeJX+QzXgFYpBqz6sRuJwBLmvsLbXb5A2MNNTiBYNSTJWLu/4lGwFYTrJAoD3yP4uYdVGt/8GgNn7qwwqAER5UeD5ZKsoi6vNyogSSWs4zx6cU8TMjetFw8011x4EwNM/n46W7T8YLcOpNilekvdQuW/OCfvP6jrOczwGake0lMVnwBgYxxIXotsLMsHBIouscyB2j+XBQH8+bMzivvjha+2r6mM/u3q/XKLBQKHDvJQGr5IP+j2wWQ2Bz8HjIhwcxIo8IkNk7/QWBGTD6TFHP9JevPfeA1I1Khw+qHS2/H8xqg7x0z26MlGsxO7xx8B4+Fg3hWxUwu8RzuaLQ/JQQVDJPsnDOHmwQvX9IYo1n9Gb6RZ3XCo+uIP3SidKXSrgdccC3HpQnEtnR4nXy0mst3hoV9R7IM2vrQ5GoTFvPZ86Y5AxyEWgjIIThHqTSXwpGAIfkarvUQurVcQ76Wl5KWUVweqShBnwJAPGPglc5UuNsU5I+t3mik3SDdVEnu2iiDbUNhRzjujux5mDCJ7UqO6VEIXVmnhG7pJl+ROaFYh8aM/tO0e5bghUWgn5+BbWDo7uxZshjOTDZGqe+TLREhVsE263hIP2d4tlkgosIQehGoGhpr7exIYpX7M+v69I3mazbwZZQnIXfFJCnR6oYyiBfKJtiZFWj7tUOwnsgdaQLvu39dyW1ZN X-Forefront-PRVS: 0249EFCB0B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39450400003)(24454002)(377454003)(13464003)(4326008)(229853002)(76176999)(6116002)(14496001)(110136004)(6486002)(230700001)(1556002)(561944003)(25786008)(81166006)(8676002)(50226002)(66066001)(50466002)(33646002)(86362001)(53936002)(53546008)(23756003)(305945005)(44736005)(6306002)(3846002)(6496005)(9686003)(6246003)(345774005)(84392002)(189998001)(7110500001)(6916009)(38730400002)(50986999)(116806002)(1456003)(5660300001)(15650500001)(2420400007)(81816999)(81686999)(61296003)(62236002)(7736002)(4720700003)(44716002)(93886004)(6666003)(42186005)(2906002)(10710500007)(47776003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2995; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM5PR0701MB2995; 23:97Oxb39+Gh+B6Yb0B1LLv7TEoqAHn8/VP5Iwt?= =?iso-8859-1?Q?SSenIu+mdO4CL94H0yghlMijMr3Ew1X5oAU/h1Q0WJElahUBSYNKUhiFlc?= =?iso-8859-1?Q?okSVzgsHlTi5w7Tt0rPi4ttKD50PAGY5t9YJoxtrUiF5/G5kUN+KPPCP+V?= =?iso-8859-1?Q?85bpv7uNF++wgAT4cRSLS+BunSMOWcvdyUhC813hrfwchLxVImdDGgTYHD?= =?iso-8859-1?Q?5xTrmZhuXQzs9+3KvspZraq8/Ay1ULwUe+WlLHOIhcWZ+AK9E6xwpaVAkb?= =?iso-8859-1?Q?HArhRvfz1dI49IpInw49df8LxGN01aoSSBlRcMOFLX6KMJyulkKlZ4PjV8?= =?iso-8859-1?Q?1NfYkZLjpRyciEkQNrF9+qd89b/XANIWrJ9YaOkpQ00PQRFbmvS+XzYSLe?= =?iso-8859-1?Q?uoqlsd3vT+JDFcx7qYtBnmqrWn1gz4E4td+qUCsWo77gHU4frQvx0U3L7Z?= =?iso-8859-1?Q?4W5EKTNoZu6L9ktPgVuMbPashf1KW5hjpeiC8BHe7OGEsbfHTjvY3/9ITb?= =?iso-8859-1?Q?WVlc4A39msAhXcmUGrjAWco1ZzjuQnj1cfQDIPQ4+JT4Vldgi84fivJFry?= =?iso-8859-1?Q?8NGtBHTeXh9eJVZRceLRuVYt9r/Tn9be5eMEuCIZJW+aa9basoLTRA0RTG?= =?iso-8859-1?Q?Q6zTp4mgPYD9FWSktyLFey8/8afq8I+24lcWnvZwDv5Te3KrXQX+70GrSM?= =?iso-8859-1?Q?Y7cC6jBWxfQT3EET6UbnltSr7BoSol4iUz4a5065JweQL/n4jsRT/TEipr?= =?iso-8859-1?Q?KCflkFmYlLCRuc6yimq1PQRqDcaKRunL7hieZkvNft43YYmGDyl3hfQD24?= =?iso-8859-1?Q?jP/YY0SEfN306aQOh9l2/6C9IRkU2m9NmyiPyik8PGLJzEHxKIaA+n0Njc?= =?iso-8859-1?Q?V+G9spZ/3Wbm4zdRnw14uhZ9P5t03F91OCUYk26unN+bKPFIubK6bBCFhF?= =?iso-8859-1?Q?7KLBtaB66HhZmC7iWocCpwS9Fwyjm4gtTfY2SwrU5dOiodDSMQjTQvbESk?= =?iso-8859-1?Q?b9V7hsQCTxgw04bHeMa0TiEYTS3OMDtsCYY2cG8X2nlBtSJRd2SB+avKzL?= =?iso-8859-1?Q?u4jYVllCQQhS8I11q0B3phjSmxp58MFJEc3IImfT6pEmlo3KcBldJ0Ko/9?= =?iso-8859-1?Q?U4yeQqLQr1EcNCbEgWxiq9Ylp/56OqCcf6mRgC2gf4wGGTQl9iq7UtwNA9?= =?iso-8859-1?Q?6bpVhUXHJHx+CmVz3vvbfanD8BHvmGipGsoQUyMCmsaY4dxNtqXWeM6+TW?= =?iso-8859-1?Q?rqbi92qbYwtRW4oR6h6Y2wzE04WIYou+3PImsEVmWp0LWdNOAqDvusK++c?= =?iso-8859-1?Q?nC1JQCK+p7W++v+9UJj7gfIbWjTCvhxbngsJ8eHwOa2wpY2DkG2FSDG5UY?= =?iso-8859-1?Q?mQs8qQeC0T42ZPNXyl2efgRCu9m7xBjryT6f8GjE1IvPJHl/aZanIbOjL0?= =?iso-8859-1?Q?/o4WZr2USlYCL4/ZcWm7Uc8iUrJkbMCIMmZN54YKOdOhuN8cv9Gw/Jx7zX?= =?iso-8859-1?Q?EOVnsxW5RvnLXLrHwxEbKBKy5fmvVqwOe/aF7+pFanv?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 6:hu4vqJf9o8W3VYIV579Xw5LpyXweKEvRX/X0KGLxkMho/ptcXEtcyCvjIJcizNT5RdI/0Y+Z/MoG92mz3kFRxs4Ht3N2ZWwiV+A59HnA8ETHTaHZ9qv6KIIzYPGKpG1+hDMzTiKrJrPPTr/13xVtRra+6WTztUXjFWNb2NWVKTTO0327pippxMVtgeLwyGEcTMy2jOGASjh6gMjNO7K1hW52jzEJeCw31+HgC+bNRyq+Rc52ajHdJ1XD/XkgIwwRhpPF1YyWNqoJZE0zGuksT3ZYGE+G3/JmMT2n+d8dVth15Kun0MMnH6j4mpEH+fQC6jSBMMeAAtET9+zOveWk6Jej7tSVD8H2JOHkkN1CmHUXUek1u2jndcjfVgGlDdrEf3euoQKk349vN5OvfJFflg==; 5:EFnvsZFNPv2l45ymdr8sQOxwTleyRAQAhmBiNu1AFwzvCZ7QhDbjwAB0jRMcvLHxGihZ+l9p4LwaQFe5PhqyWzYUEHBT/J4Bm1gQTf7jMZDgr9oqslTa07c4TLLfhlHrXtLBMaUjAQa3e9Da17W8sQ==; 24:T8tJcfzh16Z7RHwiziWqiDH9kMmkPKsOi1T+WKKRhIIhIAPDetxekA910ghH3UZS15wk2+2MTra6BpgNH45vjqbXC+Zuretqxwif055GpUc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 7:tmVrHSexlqccZyJRQ/1Mop4gzuyGWNgMnpDn1npQwBPd2njiA8uqsvm2fGTiO0vykDbpSeDKwaIrdsHhMBeHVDej9c1L9Z8zwQ+oPHw9AKecabyWDAiwyGb1UzCBKV9pZSg5z+G7mlJT2nFS3gcZJHNMiE9mR5Z8IzrkcjrPJl1Shmn1VgU8O+7hUrnhIToPLfAKwSNaYbp/GUHuxR9Jg8l/5CXX5Sz+xoLf0yvjD7rLm53qLZ3AsdVlQGC4oxTWjwWvsS+7YEJnYk3T0FfVTdzTHKWOTOrbgxazPll/uz7C0T8kWIR+FJwT+nQXK191pmGzW2PINXfkCECtYAjDdQ== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2017 16:59:00.7261 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2995 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 16:59:07 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "Robert Wilton" Cc: Sent: Friday, March 17, 2017 2:32 PM > > > On 17 Mar 2017, at 15:04, Robert Wilton wrote: > > > > Would 7950bis be allowed to have a normative reference to an Informational RFC that defined the YANG datastores? > > My idea is that 7950bis should be made independent of any particular set of datastores, so such a normative reference shouldn't be needed. Lada You say 'set of datastores' which I would agree with but I would propose that the concept of a datastore, which could be a different term, just semantically equivalent to that of 'datastore', is still needed for validation. The scope of validation is a closed set of data and the current term for that is datastore (as opposed to module, model or any other unit of data).. Tom Petch > > Lada > > > > > If we did a 7950bis document (and it isn't clear that one is actually required to support the revised datastores draft) then does that mean we would also need to have a new version of YANG? > > > > That would potentially seem like a backwards step. Also what would it mean for an implementation that is aware of the new datastores but is using a mix of YANG modules with different versions? > > > > I don't understand why the revised datastores draft should not be standards track once the various appendices have been moved out, noting that they are really only in the one draft at this stage because it seemed like that would make it easier for folks to review and comment on. > > > > Is the only issue here which WG the draft is being worked on? > > > > Thanks, > > Rob > > > > > > On 17/03/2017 13:22, Mehmet Ersue wrote: > >> I think YANG identities should be standardized with 7950bis. > >> > >> Mehmet > >> > >>> -----Original Message----- > >>> From: Lou Berger [mailto:lberger@labn.net] > >>> Sent: Thursday, March 16, 2017 12:28 PM > >>> To: Juergen Schoenwaelder ; > >>> Mehmet Ersue > >>> Cc: 'Kent Watsen' ; netmod@ietf.org > >>> Subject: Re: [netmod] draft netmod charter update proposal > >>> > >>> Juergen, > >>> > >>> Thank you for the input. I think your point highlights how the technical > >>> contents of a document drives the intended status of a document. > >>> > >>> Lou > >>> > >>> PS as a reminder to all, intended status of documents is *not* typically > >>> included in charters and are not included in the distributed version. > >>> > >>> > >>> > >>> > >>> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder > >>> wrote: > >>> > >>>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: > >>>> > >>>>> That said different people including Netconf WG co-chairs think the DS > >>>>> concept document is Informational in nature and should be published as > >>> an > >>>>> Informational concept to be used in and adopted for the needs in > >> diverse > >>>>> protocol WGs. This is as I think also important to avoid an overlapping > >>>>> between NETCONF and NETMOD charters. > >>>> The current datastore draft includes concrete YANG idenity definitions > >>>> for datastores and origins and these definitions better be standards > >>>> track. > >>>> > >>>> /js > >>>> > >>>> -- > >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >>>> Fax: +49 421 200 3103 > >>>> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> . > >> > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Mar 17 10:15:33 2017 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 25D631294E7 for ; Fri, 17 Mar 2017 10:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 7l9MPzpDcSgO for ; Fri, 17 Mar 2017 10:15:29 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9B31201F2 for ; Fri, 17 Mar 2017 10:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5481; q=dns/txt; s=iport; t=1489770929; x=1490980529; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ASgrSaa3L3sqja07imG0Lu25X86YOp81MjZ07jVEZb0=; b=JIHB7cFzhUeneCzsEoPKjlA7JFevoYyvXUaeewxj2feFgwIEv1Qi9lEk 6X9pSHpqe8rNNU97laxmGlA109BG1yZXG6uct/kHEBxOnalXOEHDNl3N+ yBuSE8U6n5CEZHq3Z0BdXRrqL/udCDA8AeOpoeazcvZipPSETakVVv5Vu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAQAuGcxY/xbLJq1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyeBCypgjXFzkGeVQoIOLIV2AoM+GAECAQEBAQEBAWsohRUBAQEBAgE?= =?us-ascii?q?nEUEQCxguVwYNBgIBAYl0CA60GzqKSgEBAQEBAQEBAQEBAQEBAQEBAQEaBYZOg?= =?us-ascii?q?gWCaoE8iH0BBJxJhnmLSYF7iFsjhjKLQogRHziBBCMWCBcVhSWBc0A1iVcBAQE?= X-IronPort-AV: E=Sophos;i="5.36,177,1486425600"; d="scan'208";a="693063849" 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; 17 Mar 2017 17:15:26 +0000 Received: from [10.61.70.68] (ams3-vpn-dhcp1604.cisco.com [10.61.70.68]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2HHFP1Q006794; Fri, 17 Mar 2017 17:15:26 GMT To: Ladislav Lhotka References: <18a2e042-919b-9468-2dc8-f751bd924125@cisco.com> Cc: "netmod@ietf.org" From: Robert Wilton Message-ID: <77d0cd5a-2b83-1c40-c54a-a5c6212671b1@cisco.com> Date: Fri, 17 Mar 2017 17:15:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Comments on draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:15:32 -0000 On 17/03/2017 15:08, Ladislav Lhotka wrote: >> On 17 Mar 2017, at 15:11, Robert Wilton wrote: >> >> >> >> On 17/03/2017 12:55, Ladislav Lhotka wrote: >>> Hi Rob, >>> >>> thank you for reading the draft. >>> >>>> On 17 Mar 2017, at 13:30, Robert Wilton wrote: >>>> >>>> Hi Lada, >>>> >>>> I've had a quick scan of your YANG markup extension draft and I have a few comments: >>>> >>>> Allowing description, and similar descriptive statements, to use something other than text seems like it could be useful in some cases. >>>> >>>> I'm not sure that allowing the statements to use any text-like media type is a good idea, this could increase the burden on tool makers if each module author chooses their own preferred format. >>>> >>>> Instead, I think that it might be better to restrict it to a very small set of media types, that could be extended in future. I would think that initially just allowing plain text and one particular flavour of markdown would be a reasonable starting point. >>> I agree although I am not sure that we can easily find an agreement on the particular flavour. So maybe we can leave it open and let the "market" decide. >> I think that would be a mistake. How would device/tools vendors know which versions to spend time implementing? > I would agree to have a fixed choice in 6087bis, but there may be niche communities or special cases that need something else, so YANG IMO shouldn't preclude it a priori. I think that this idea works quite well as a YANG extension, and that would be a better path than baking it into YANG at this time. I'm still not convinced that allowing an arbitrary encoding is a good idea. > >>>> I think that the only formats that should be allowed are those that are still readily readable as plain text, so that tools that don't want to parse the formatted text can still sensibly display the descriptive statements. I.e. I don't think that it would be helpful to allow things like text/xml since it isn't easy to read. >>> Sure, and the draft says: >>> >>> It is RECOMMENDED to use only media types representing "lightweight" >>> markup that is easy to read even in the unprocessed source form, such >>> as "text/markdown". >> I was proposing REQUIRED instead of RECOMMENDED. > I usually write my modules in the YIN format with a very restricted set of HTML tags that are used in the text arguments: > > https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang#yin-schema-extensions OK. I had assumed that nobody was using YIN ;-) > > It would be useful to indicate "text/html" media type, and a YIN->YANG convertor could translate it e.g. to "text/markdown". Isn't that just part of the YIN conversion to YANG. I.e. by the time the file is YANG it would be text/markdown. > >>>> Allowing this extension on particular descriptive statements may also be helpful. It seems plausible that the vast majority of these statements in a module might just be written in plain text with just a few of them using more advanced formatting like markdown. >>> Yes, I was thinking about this. On the other hand, plain text is typically compatible with any markup format, so this would probably be useful only if somebody wanted to use multiple different markup formats in the same module, which sounds crazy. But we can discuss it. >> I was only thinking of a mix of some plain text descriptions and some using markup. >> >> Tooling may choose to format raw text differently from markup text (e.g. converting lines into a paragraph). Also a markup processor would be extra work, and may not warn or error on the structure of a plain text description that doesn't conform to the markup rules. > Actually, the design philosophy behind markdown is that there is no formal concept of validity and so processors should never complain. But how does an implementation know what it needs to support so that it works with all descriptions? I think that there would need to be a based specification to be useful. > > On the other hand, it is conceivable that some descriptions may use a more specialized format. For example, we could use a media type (variant) for the top-level "contact" statements that we include in modules, and tools could then more easily extract this metadata. I'm not sure ... this is just sounding like extra work/complexity, and YANG is already pretty complex! Thanks, Rob > > So maybe we could really permit the "text-media-type" extension anywhere and apply some natural scoping rules. > > Lada > >>>> Finally, I have a concern that if more structured formatting in the comments is used then would that encourage model writers to produce more verbose comments, and if so that might possibly reduce the readability of the modules. Although, I guess ultimately one has to trust the model writers to do the right thing. >>> Well, this draft doesn't permit anything above what module writers can do already now - the descriptions etc. have to be valid YANG strings as before. The only new thing is a piece of metadata that may be helpful for some tools but that can also be safely ignored. >> Thanks, >> Rob >> >>> Thanks, Lada >>> >>>> Thanks, >>>> Rob >>>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>> >>> >>> >>> >>> >>> . > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > . > From nobody Fri Mar 17 10:16:32 2017 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 26D131294FE for ; Fri, 17 Mar 2017 10:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 q3X528jnxvP0 for ; Fri, 17 Mar 2017 10:16:29 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0124.outbound.protection.outlook.com [104.47.1.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD691294E7 for ; Fri, 17 Mar 2017 10:16:28 -0700 (PDT) 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; bh=eZ1z/BmFLN5/kkABg2+udvDLg/ni2miFVdHLtH30Jek=; b=SX1PRGkm5jcovzA2YhxuDPJROAAHUfvHuTm8Xum4zIGN7kFkehw1+WjE7tFMavS5DFfNsironEQgOdIejiGGwp0qXTNaEose71eMexJG1wHwvXm0u920RcjHPNwuvphKKJMOJ8Xk7k8yLXSrsg6K1l4shlsnHAtznzgn5czmofU= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.203.75) by AM5PR0701MB2994.eurprd07.prod.outlook.com (10.168.156.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Fri, 17 Mar 2017 17:16:25 +0000 Message-ID: <01c301d29f42$0076a880$4001a8c0@gateway.2wire.net> From: t.petch To: "Clyde Wildes (cwildes)" CC: References: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> <1CC274D2-72B9-4F79-A70F-3DF332C65A60@cisco.com> <44C50B18-8918-47E4-A9FE-F4A676E64AA1@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF818AA@SJCEML703-CHM.china.huawei.com> <02B9298C-631A-46F7-9FA9-19B1959327FE@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81C18@SJCEML703-CHM.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81CBA@SJCEML703-CHM.china.huawei.com> <033D3CA2-7297-48C8-A5BD-B723F7F1911B@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF81CF7@SJCEML703-CHM.china.huawei.com> <075901d29286$5def4300$4001a8c0@gateway.2wire.net> <63894410-D14B-4F3D-B72C-898CE30B5104@cisco.com> <02a101d29e7a$98231380$4001a8c0@gateway.2wire.net> Date: Fri, 17 Mar 2017 17:14:40 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.203.75] X-ClientProxiedBy: HE1P18901CA0008.EURP189.PROD.OUTLOOK.COM (10.168.181.146) To AM5PR0701MB2994.eurprd07.prod.outlook.com (10.168.156.144) X-MS-Office365-Filtering-Correlation-Id: 0a9f22ed-acd0-4010-9a56-08d46d5957eb X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2994; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 3:UcQV9+alNRinXtaNzgWJTH/NloguijmNnav0QhMoePAYn8ONKK9seF1ZMdlj1UDOVuMqAlrg13sDWfdCb8GGAGgAI8hV+0zkzYuGP7dRx5qMBBym5a9WrPgAno+HnvxfrmgHpl5IYt+CJv0IGy6JC8ROtdFjLLeYEHFbvpATqieKvfq9JdBBR977dOF10brmC2MGfVkKzBk4Bk8Fj65xy4YneYxdj1d58oRkDhBfx1o3s2Szoc8ykspKDA0LmS8qXkbZwhpbxGMJXBwcHDVPiQ==; 25:5YsrLJflOYs8VmQ3DU4ELgff1jib+s35o2yG/FC7uY9QZc+kUUBemgM3xT2k/aIbVRTJwkktTsHB1beEQbEQUVkontbn+4R4cIqAdPA1K6msIVABoN5UP/m8ZKmVgQqWrjW8N+KC97scFJy+18IRGv2/zmS7sKEJQLshYaME1qgSob7sI4dVra+TezaLkyyGI3FxJy7Kk0Mkl5nv6j4Ck2+ikKHTLxXB6DWEeK29Whks0CzIuEeU66GX9bo1mmaRXXR5dahxiT0+XrJV8KVgURJ7+nGUhVfXY/+Ke+0HmCgR+xjcfeUcMGjeEQhKXyWe04kI1zvqC/BHQWZ9MCyH7Ca+EqcLe7b9H2mUZ0mtkalKCGVVx52W5QQzcOv3tgIyhGxVExE7okHDpFZsIxFHueFIWEH2sgVWETLyLwFLb4gvYKp0kCIZ7n8PHil1UwjI5I2l5kA1ALIen6kMLpi5Jg== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 31:wVantY9sRnaLWqos3kZUyXBKZrmAxOC9NCJ3Shb9aevL7l58wnYml4E6GRmvcdtx9WquiK+tH2FkYdJDkY0/l4PMoBXnwx53x4fewVEnWkYe30I7kKWQyYxiCW34SIQ1dS1EtnJ4pHrNAmOs3afCYgZANK82Hoci41u5Baszs/LxODFdesWOzz0bgG/xxHs5rbGdc2lxpfhDg67B6TuzNVAoRKrEOUFZVNntssj5SmM3YqOva75pvnS+vVrH1sXSBkDms8A01zNBN63LfbZ/lU/yyLCTBw4snVTYI8J/e10= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(50582790962513)(95692535739014)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:AM5PR0701MB2994; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2994; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 4:16AZzLXYusOk5099LmPZ+qnKoAoMdncEs5zEr6qFxBPuQT6MRWiKPdOrLdVSZHB6J+Dp3GpXiiyJiF/ggmviwWncl2DULSpq6sV/mRP9X+OszArM+O0HCWHkDm1eZTlTUvK7SssAiWW/ocw9zUeXRlUzieOCAoWOWWEcIMIn8a/w0sZeYpfEXXc/1J2khy/RdYVkDUs9Ex7cOZdqvqSxzGiGrQl1OnRRDGXZfVWf8yvYEBo7C31Ns8/r3vLAPw6X91Cf2VDUYoVTQzOiRoBJr+Ru3f0PwLucsYOZMUvSQDjiithtpMb1J5xLvoC32w9dPVL6d8wKKp2+Y6tXjuq7SYlMSp6HDLI9UD0jNUKeXgMPUtdkK8VEbhLE0UpFqzi7Va/4LOI5HVOLd6TCMZ7PFrC+x/ho3/k/LM0i8rafLgUJ99XnpZq6co6uEZe8fXCroKMaTemU9ARpR463cXvsGWRcUIwJJ3wFjZhYxrRLnjHVAVpn+S6PwZgJvgBhHyMlw70EppeT11N1Lpht9z6VOhuRkZ4wxiBmeBz3v4tK3H6Zzz+ezQjQw+uhow75EuoVRjutlTRzluSzge2VzYiHBXsJq9Jm3uz7+fzldOJB8t058HMyzXvotBKA7cMgIDq1loje9OLytZqTmzouyVtwx+F89N1yU5RFHzwJRHj3h4pvZfhkljRnToq9cvihzmW6Pii45RsJUlzn5oes87bVJFl6zlN6be8CmueGoWbdONh8uWPW6m29AbWX7hbeAV8P X-Forefront-PRVS: 0249EFCB0B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39450400003)(24454002)(13464003)(377454003)(76176999)(50986999)(81816999)(81686999)(7736002)(110136004)(66066001)(25786008)(2906002)(38730400002)(44736005)(6486002)(2870700001)(189998001)(50226002)(47776003)(42186005)(1456003)(305945005)(53546008)(8676002)(50466002)(61296003)(5820100001)(81166006)(44716002)(229853002)(62236002)(4326008)(3846002)(1556002)(6116002)(23676002)(116806002)(53936002)(6666003)(4720700003)(93886004)(230783001)(6916009)(33646002)(14496001)(84392002)(6246003)(86362001)(6306002)(5660300001)(9686003)(6496005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2994; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTQ7MjM6VU9wbU80MUxuN2pDN1hwaFJ4WDZ2WkY1?= =?utf-8?B?WUx5a3pnNXdRMithN2hMUktIRmVOL05jTHRoOWM4UWpubnJxT2VpYit4cERq?= =?utf-8?B?ZS9vUkRjaWhSWjNyR3pybzlXblVlVVM1MjJSaU9JdWg2S1hUanA1OU5DekVp?= =?utf-8?B?ZlNGT082U1ltclQ5Yis5WVJ1eU1walNNMFIreUxBNllYZXN6alBEdFhLdDVy?= =?utf-8?B?ZEVFb0pEdHhCaWx3ZExFblB5TkdNeC9Vam1IbWsxSXJ0dVRacVBkSEV0c3Nv?= =?utf-8?B?QnRjRDJpVWh0eWZlVHhucTZxSk1VL1IybTBmUjhHWERlZ3ljRktOa0tzNENq?= =?utf-8?B?LzJNWXJHZHJmV3lHQ3YyRnZCOTFJMmZmZXJOVDlqVy91bFZCWlVMYWR4SzdL?= =?utf-8?B?ZUUrdVRFa1JxZnNPSjN5c0dvampHL3ZscU5YYmNCbWg2QmV1YnBRYUNkcFBN?= =?utf-8?B?ZHJEZVZJZTNoYUV1Y0EyS21BMTU2em1vM2tmNkhtTmZ6UlRXNU00cmxNcXZF?= =?utf-8?B?NUhOSmpNOWp3cDJiOTFnNit3SG9JQTBjSklqbnFqcEQ5RDJ2YnFoaW1EeEkv?= =?utf-8?B?MlZQUVBWQldLNDFKazVwL0ZzeGZHMUg1QWMyUUVkamVPLzg2TEdwM2tCd3BI?= =?utf-8?B?VFBPSngzUWVuLytncVU4MjFiUkIxN1JWQnUzV1ZPOFhjUDY5QmJuS2JJQm82?= =?utf-8?B?WjROS0RsMWRxR2FFbEt5MXF0VHV6Mkk2NUc3OXRBZ0dZUytQOTRkWXAzTWh4?= =?utf-8?B?N05Ibmt0SUdWSTFFVG5ucFF4dzFHOUxGeVB3T3ZTVlpKNGNSd291UkxjT0FR?= =?utf-8?B?Zkl6Zjh3WitvMU00QUIxUzZNMFo3MlNrYUdHd0ZMYi9qTjAyanNpdjVXaHU1?= =?utf-8?B?YzB3V2NFQ2VLRDFMcWpNakZNOVJTWFVNd2RoS1J2NHRndjE1QWJ1d3RoOUhq?= =?utf-8?B?eHlsLy9JSFd5aUd5QW8xbWdTRmkxZXB1SXhFazlpYWwyM3RPeFlJYmFsbGFF?= =?utf-8?B?ajA5MlpueHJjRU5JWENFOWwwY2hqZXF4TG5oQkc2RWV4NzFSY0tLOUVMMzlm?= =?utf-8?B?ZzBteFAyM1NZU0pXdys0MnFXYVFQZVJTUnQvcjROekk4M2ZSTENIcjdlWlA2?= =?utf-8?B?LzcrbG9yZDBMdkVlT2h2ZjEvUEZUWXBlTHB4Mzl5Z0cvUnJoWFlXbVhaWkJm?= =?utf-8?B?RkU1a0FURDF5M3B4VWQyZ1NtMWNtQkhwbXdlWndFTWtPcm5vRTJGTmN0Rjls?= =?utf-8?B?dTB6bWdMaHRWbVNOekxKcjZld0xJZUJGK1F5c0t1OXlZQy82d25TSXI1L3VE?= =?utf-8?B?ZWpyTTZvb1FGeENmRVc3ek9NbjB5ZGFEWXV6YlBTNkFBZjhLYURRVDhhdEov?= =?utf-8?B?TzgxcnViT01tc0RyR0taKzlXQk1icjJHUWF3QVFSVmhKalFCVzErSDR2cWtv?= =?utf-8?B?V0JqL0hSVUVIVEhmSElMOXhHOWk2N1RNN0wzZVdqNHZkMDU0c0tTbVl3c2Zu?= =?utf-8?B?MlZWakxGS3RtS2FuQ0E4V3FMRWUrZWJqWEZ3YmFPZEdNcSsyTkIwWHlBZFhi?= =?utf-8?B?NCs5VlRoanpuOUIxLzdzRGl5TlVxSlByTGhOY1drUk5QNmhwZHY2VHZQM0tD?= =?utf-8?B?S0R1TE02ZUV2NVdlSjI0cTNDTXliWG5JaCtVYmxNWGlRTUhlaE9jVnJEdXBS?= =?utf-8?B?V2Z5V2xhUjIydTJsVnFDbHJyL1lsSjkxNmZMSFB2Ymd2STlLRTluQUkyUzVI?= =?utf-8?B?Y3VXcHVRaUtFdTJFV082TWtvbjlaL3ZPaVp3TlVPOFVSN2NnV041emtZVFg0?= =?utf-8?B?eEhGWHRTQUVyT0NXR1QweXpPRTlBZWNNREI1Ti96dWNnTDBIdz09?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 6:cIOphLBGdzJp47Z282lFq4ufrevgAy+3lgeImvHzxP4u/QGnGAlgrJSdnzn0E9Sq3dH1FjdFRtCb7/w2E8i95GNymSROg0k38XP5Va0I4rFI2E7Y9Y4LRWZcCmmlCy9Afc9wUkLwQsLjY1OfADPVj0TiVbUzyNlQ/ZLZ+1GfwzY67178gH43hxMhi6MGGx2eFPcUfCiJpEKONlsCsQPTG5ZOI+7SO+J8bXaKJvooeX57YMX5Z6QSmiH+t0OMGgDjDVzeJ6UbsrUAWLhC1QG5t/jY0HsJT8PY+S4BCuQz0z6/fFrVT0NGu1n44pdhNat4QhvK4IaW5SqUy3DzhoWCCQs0i4XsHjwMoPrWpUYAgOoVU5jNwR1shi7GG2SdOtGAYXfhU7ft0mZO1jIk0cmLWw==; 5:NQgcSNwwl/0u1fp8OzT6SH2MXTVnD+hLbklGNip4ifw3eDFOfXQEjMVt3sp2aFlun2aQY3rJBbGZKyUYBz6VjGMkksB4J8BvySCgdbiWvSCOAZ+FKI94GGz8FXvtjnXuXvgICvXuzXu7WePoy6eAGQ==; 24:BV/S0r95UnIncN7OZtLYWLI6Ddrv6MySQz9+O8QwkGpom3JxN9Hugj4DzITX8PzeVaYqv+8VI6x4XAWEsGKRW5zk/plc9aZHUYMwMTHqKHs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 7:aOpTpPYDrGal2mF06rxxgvdqjkeJx0jbr33C8AaMGPVkZ+ZLXs7OSUzzuSTUUyaUFfEDBoKh+skr5zVN6OLeWFHAWU3Nb4jA5WvVeIVU2x7HDSV1DYEQdxQE+ZC1xFxXJacvDRweX8W8fIlRu9w1slx9Iu0ZtYOqakaWscNFkfE5UiwRPeEXmzSg5J81W4cZOnst8dA2U/4OTEqDfgfBLXtACIVq0SDx7Drx55U16BX/WKMBuoTUiBNrKrxMPG7wQsRSmIFO/IUjRsk4Yp+tV48+ovdyyVVjI277yUgaodQv5qcy8C50AWJ+IujJbBfE+Id5y7hrfcZmQwkbz8RnZA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2017 17:16:25.5933 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2994 Archived-At: Subject: Re: [netmod] draft-ietf-netmod-syslog-model-12 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:16:31 -0000 ---- Original Message ----- From: "Clyde Wildes (cwildes)" Sent: Thursday, March 16, 2017 5:58 PM > Tom, > > Inline… > > On 3/16/17, 10:04 AM, "t.petch" wrote: > > ----- Original Message ----- > From: "Clyde Wildes (cwildes)" > Sent: Monday, March 13, 2017 6:11 PM > > > Tom, > > > > The next revision of the draft-ietf-netmod-syslog-model includes a > change to the Yang tree diagram explanation to include the text from > RFC6087bis. > > > > RFC5426 is referenced in the model where "Transmission of Syslog > Messages over UDP†occurs: > > > > case udp { > > container udp { > > description > > "This container describes the UDP transport > > options."; > > reference > > "RFC 5426: Transmission of Syslog Messages over > UDP"; > > > > This is a correct reference. > > Indeed but I don't think that [RFC5426] is going to work as part of > leaf sig-number-resends > while > > leaf structured-data { > ... > as per RFC5424 > > is not the usual style. > > [clyde] I was urged to use the descriptions directly from RFC5848 – in this case from section 6.1.2. Configuration Parameters for Signature Blocks (page 25) > > sigNumberResends = number of times a Signature Block is resent. > (It is recommended to select a value of greater than "0" in > particular when the UDP transport [RFC5426] is used.) Clyde The semantics are fine but it is the [ syntax ] I think incorrect. > [clyde] Please suggest a new name for the selector that you think should be changed. I could not find a reference to this in my notes. > > On another tack, I thought that you agreed to change one of the > identifiers in > > grouping selector { > description > > container selector { I made a note of a comment by AC (but which?) that selector selector was confusing, which I agreed to, and I thought you agreed too, but I discarded that thread and cannot now find it (it could be several versions ago). Anyhow, I find it confusing and would suggest 'filter' (which RFC5424 uses) not 'selector' . Since the container appears in the diagram, I would be inclined to use 'filter' there but it is removing the apparent ambiguity e.g. of a usage such as uses selector { refine " selector" { that concerns me more. Tom Petch > Thanks, > > Clyde > > > Tom Petch > > > Thanks, > > > > Clyde > > > > On 3/1/17, 4:20 AM, "netmod on behalf of t.petch" > wrote: > > > > The explanation of the YANG tree diagram is not that in RFC6087; I > think > > that it should be (or else explain why not) > > > > I am confused by the variation in the references to RFC in the > modules. > > > > I see > > RFC 5424 > > [RFC5426] > > RFC5424 > > > > I think the first correct > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Alexander Clemm" > > To: "Kent Watsen" ; > > > > Cc: > > Sent: Friday, February 24, 2017 12:25 AM > > Subject: Re: [netmod] WG Last Call for > draft-ietf-netmod-syslog-model-11 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > From nobody Fri Mar 17 10:18:55 2017 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 196431294E7 for ; Fri, 17 Mar 2017 10:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 oE1xacrYIWVT for ; Fri, 17 Mar 2017 10:18:51 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C1A1294D7 for ; Fri, 17 Mar 2017 10:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12601; q=dns/txt; s=iport; t=1489771131; x=1490980731; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9qUQMzgsdry11J7AYn6RfNbbElY29RFXfqUc2iCxFEc=; b=PtCXVkep8C5Mg8m8uU6dP+y4vECnQKDf+J0eeBcy7SG6PAuaONyvACKL ACnUGba4zIpu442PbCZBHrokZoZJ0Tq9MkcGM+QYrjFcAIjtYh/jQXsWe 9fssHHc9HQWhNvS9xMHDTKAFe5TsEA7husdbm2u9HtFaJ/9rhddW80fSp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQBlGcxY/4kNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHjWqRWpAOhTSCDh8LgkKCbEoCgn8/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEBAWUHGwIBCBguJwslAgQBEol4CA60VYpKAQEBAQEBBAEBAQEBA?= =?us-ascii?q?QEBGwWKNIEJhCYKBwEchWUFj1uMbgGIPooDgXuFKIoIiE6GYYQjAR84fAhYFUG?= =?us-ascii?q?EVCCBY3WHGg8XgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,177,1486425600"; d="scan'208";a="398461818" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Mar 2017 17:18:50 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2HHInSU004642 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Mar 2017 17:18:50 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 17 Mar 2017 13:18:49 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 17 Mar 2017 13:18:49 -0400 From: "Acee Lindem (acee)" To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03 Thread-Index: AQHSmZYCCbCj3iRLkk2OXix38XM4rKGOcIyAgAAKaoCACtbtAA== Date: Fri, 17 Mar 2017 17:18:49 +0000 Message-ID: References: <33d0132e-750b-97ed-8bdb-0befeb1b81c3@cisco.com> <0400d1cb-30ce-e074-b707-202026161ebb@cisco.com> <12f97503-9801-56f5-650f-8accdab68e4c@cisco.com> In-Reply-To: <12f97503-9801-56f5-650f-8accdab68e4c@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:18:54 -0000 Hi Rob,=20 On 3/10/17, 9:46 AM, "netmod on behalf of Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" wrote: >Lada, > >Thanks for the comments, some further comments inline ... > > >On 10/03/2017 14:09, Ladislav Lhotka wrote: >> Hi Rob, >> >> please see inline. >> >> Robert Wilton writes: >> >>> Hi Lada, >>> >>> To pick up an old thread, I'm updating the interface model per your >>> comments below, and I had a few questions that you might have an >>>opinion on. >>> >>> On 22/12/2016 14:32, Robert Wilton wrote: >>>> Hi Lada, >>>> >>>> Thanks for the review and comments. >>>> >>>> >>>> On 21/12/2016 13:08, Ladislav Lhotka wrote: >>>>> Hi, >>>>> >>>>> I think this is a very useful addition to ietf-interfaces. In >>>>>general, >>>>> the document is clearly written and YANG modules nicely designed. >>>>>Here >>>>> are my comments: >>>>> >>>>> *** Sec. 1 >>>>> - "This document defines two YANG RFC 7950 [RFC7950] modules = =8A" >>>>> looks weird. I'd suggest "=8A YANG 1.1 [RFC7950] =8A" instead= . >>>> OK. >>> Fixed. >>>>> *** Sec. 2 >>>>> - first line: s/of of/of/ >>> Fixed. >>> >>>>> *** Sec. 3.1 >>>>> - If the "bandwidth" parameter is only used for tuning routing >>>>> algorithms and has nothing to do with real bandwidth on the >>>>> interface, I would suggest to use a different name >>>>> (metric?). Perhaps it may indeed be better to leave this to >>>>> routing protocol modules because they can also specify how >>>>> exactly such a parameter is used. >>>> Yes, possibility it would be better to define this as part of the >>>> routing models. The idea here is that the bandwidth would span across >>>> the routing protocols rather than be tied to a specific protocol. >>> I think that we need a better name than just "bandwidth" since this >>>leaf >>> doesn't affect the actual bandwidth on the of the link, just the >>> bandwidth that is reported to routing protocols to implicitly adjust >>> their link metrics. Hence, I was considering renaming this to >>> "reported-bandwidth"? >> This looks like something for routing people to decide. I believe this is referred to as maximum-reservable-bandwidth in RFC 3630. 2.5.7. Maximum Reservable Bandwidth The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). This SHOULD be user-configurable; the default value should be the Maximum Bandwidth. The units are bytes per second. Perhaps, reservable-bandwidth would suffice. >> >>> I also think that it would be good to follow up with the routing folks >>> to see if this leaf would be better covered in a general routing model. >>> Where do you think is the best place that I raise this, the routing >>>area >>> yang design team? >> Maybe, or RTGWG? >OK. I'll send an email that way, after I've published this next revision. > >> >>> >>>>> *** Sec. 3.6 >>>>> - The "l3-mtu" parameter is probably the same as "mtu" defined >>>>>in >>>>> ietf-ip. Again, I would suggest to leave the definition of >>>>>MTU >>>>> to each L3 protocol because there may be specific aspects and >>>>> constraints. >>>> The MTU being defined here is an "l2-mtu" parameter. I.e. the maximum >>>> size of the L2 frames that can be sent/received. For some devices >>>> this value is independent of a protocol specific L3 MTU that only >>>> affects that particular protocol instance. >>> I've updated the text to make it clear that it is only a L2 MTU >>> configuration leaf, and if not configured, the system will >>>automatically >>> decide on the L2 MTU. >> Shouldn't it have a "when" substatement to make it available only for >> "layer-2" interfaces? >It can apply to all interfaces that use a layer 2 encapsulation, i.e. >most interfaces. It seems that an L3 interface could still have an L2 MTU? Of course, the IP or IPv6 MTU could not exceed the L2 MTU. > >The only interfaces that it wouldn't apply to are: > - interfaces that are performing optical switching - but then I think >that they are probably not really interfaces at all. > - software interfaces that represent a tunnel endpoint that carriers >L3 frames with no L2 encapsulation. Although in this case you could >just regard them as having a 0 byte layer 2 overhead. > > > >> >>>> >>>>> *** Sec. 3.8 >>>>> - I think that "transport-layer" is not a good name because in >>>>>the >>>>> ISO OSI model it denotes a particular layer (L4). How about >>>>> "iso-osi-layer"? >>> I agree that "transport-layer" is somewhat ambiguous. >>> >>> I was wondering whether "service-layer" or "service-type" would work? >> This looks more like a business term, "iso-osi-layer" or just >> "osi-layer" seems better to me, even if you include only layers >> 1-3. Actually, the OSI model calls these three "media layers", but this >> term isn't commonly used. >The problem with osi-layer is that I don't think that the name really >indicates what it means. If we have trouble deciding on the semantics, perhaps the data node isn=B9t useful.=20 Thanks, Acee=20 > >> >>> Or perhaps it could be called "forwarding-mode"? >> IMO, the layers are not only about forwarding. >Agreed, but this configuration is to provide a constraint as to what >services and forwarding paradigm can be enabled. > >E.g. an "l2 transport/service" would be connected to an L2VPN instance >but not IP. >An ACL applied to a "L2 transport/service" would filter on MAC >addresses/VLAN Ids rather than IP header fields. > >> >>>>> - The type of "transport-layer" has three enums, namely >>>>> "layer-[123]". I would suggest to use descriptive names >>>>> ("physical-layer" etc.), include the remaining layers of the >>>>>ISO >>>>> OSI model, and maybe also define it as a typedef - or does >>>>>this >>>>> belong to ietf-inet-types? >>> I'm not sure that defining the higher layers of the OSI model helps. >>> Perhaps using identities would be a better choice? >>> >>> Perhaps: >>> "physical-layer" >>> "data-link-layer" >>> "network-layer" >>> >>> But I prefer "layer-2" over "data-link-layer" since I think that term >>> is much more widespread. I'm also not quite sure whether >> OK. >> >>> "physical-layer" is actually the right term, I think that is probably >>> really "below-layer-2" >>> >> In terms of the OSI model, there is only layer 1 (physical) below layer >> 2. Or do you mean things like Ethernet-over-MPLS? I don't know how the >> layer classification works in such convoluted cases. >For layer-2, I think of carrying L2 frames over another service (e.g. >IP, MPLS, or MAC-in-MAC). >For layer-1, I was thinking of things like optical switching or OTN >switching. But again it does come back to whether those are represented >as interfaces. Although, even in the optical switching cases, I think >that devices sometimes snoop the layer 2 frame statistics. > >> >>>>> - Is a leaf sufficient? I think some interfaces can be in >>>>>multiple >>>>> layers at the same time (e.g. an ATM interface is L3 but can >>>>> also be L2 for Classical IP over ATM). Or is the idea that >>>>>such >>>>> an interface will be split into two entries of the >>>>>"interface" >>>>> list? >>>> This needs some further thought/work. >>> I think that using sub-interfaces is the cleanest way of doing this, so >>> each sub-interface can be offering a service at a different layer. >>> >>> >>>> The main idea here was to be able to label sub-interfaces as >>>> supporting only L2 services or L3 services, since on some platforms >>>> different types of interfaces get instantiated internally. >> OK, I don't dare to give any suggestions here. >> >>>>> *** YANG modules >>>>> - Descriptions are not consistently formatted. I think that the >>>>> current BCP is to start description text on the same line as >>>>>the >>>>> "description" keyword only if it all fits on one line. >>>>> - I don't have a strong opinion on this but it might increase >>>>> readability if the number of augments is reduced. Perhaps at >>>>> least augments that contain only one node could be made into >>>>>one >>>>> (and the "feature" and "when" statements moved to the nodes' >>>>> definitions. >>>> Yes, I'll fix these, probably using Martin's suggested approach. >>> I've fixed the descriptions, and merged all the augments except for the >>> sub-interface one (which is an if-feature conditional augment of a >>> mandatory node). >> Good. >> >>> I also have a question about the "encapsulation" container that is >>> currently defined as: >>> >>> /* >>> * Various types of interfaces support a configurable layer 2 >>> * encapsulation, any that are supported by YANG should be >>> * listed here. >>> * >>> * Different encapsulations can hook into the common encaps-type >>> * choice statement. >>> */ >>> container encapsulation { >>> when >>> "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or >>> derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or >>> derived-from-or-self(if:type, 'ianaift:pos') or >>> derived-from-or-self(if:type, 'ianaift:atmSubInterface') or >>> derived-from-or-self(if:type, 'ethSubInterface')" { >>> >>> description >>> "All interface types that can have a configurable L2 >>> encapsulation"; >>> /* >>> * TODO - Should we introduce an abstract type to make this >>> * extensible to new interface types, or vendor >>> * specific interface types? >>> */ >>> } >>> >>> description >>> "Holds the OSI layer 2 encapsulation associated with an >>> interface"; >>> choice encaps-type { >>> description "Extensible choice of L2 encapsulations"; >>> } >>> } >>> >>> I was considering removing the when statement to generalize this, since >>> the case statements can be constricted to suitable interface types >>>using >>> when statements anyway. E.g. I'm proposing to changing it to something >>> like this: >>> >>> /* >>> * Various types of interfaces support a configurable >>> * encapsulation. >>> * >>> * Different encapsulations (often layer 2) can hook into the >>> * common encaps-type choice statement. >>> */ >>> container encapsulation { >>> description >>> "Holds the encapsulation (often layer 2) associated with an >>> interface"; >>> choice encaps-type { >>> description >>> "Extensible choice of encapsulations"; >>> } >>> } >>> >>> Do you have a view on this? >> This demonstrates that the IANA interface types are not very useful for >> restricting the data model. As you indicate, multiple levels of the >> interface hierarchy (abstract interface types) might be better, perhaps >> you could also make use of multiple inheritance of identities, hence >> allowing for arbitrary mixes of interface properties encoded in the >>type. >Yes, I think that the IANA interface types are a problem. > >Previously I was planning on writing up a draft with abstract types >deriving from the IANA types, but I'm not sure whether this helps in the >general case. > >It might be that we need to define a set of abstract types (e.g. >physical interfaces, ethernet-like, sub-interface, logical interface, >etc) and then update the type identities in iana-if-type.yang to derive >from those base types (which I believe would be an allowed backwards >compatible change). > >Thanks, >Rob > > >> >> Cheers, Lada >> >>> Thanks, >>> Rob >>> >>> >>>> Thanks again, >>>> Rob >>>> >>>>> Lada >>>>> > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Mar 17 10:19:54 2017 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 C6E52129510 for ; Fri, 17 Mar 2017 10:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 KT6jDsfxWYrf for ; Fri, 17 Mar 2017 10:19:51 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6653412950C for ; Fri, 17 Mar 2017 10:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4309; q=dns/txt; s=iport; t=1489771190; x=1490980790; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=B8ZLHtLiCoLQ8RBMBg8i1Q2Opmh6pCRklcOBTuWTg/E=; b=RYt03LMzV7YJNz6w5A1DpO0IqtfPMHHAZmeTdXd2rHoaUvd9SK7SZv+7 AthSwbTZujvTpEA8XEQr37dq+CRO2lFOJ7G4SuJQH36uzVQdoewBxTqG0 4H715PsRi4LfNpaiU+WlFngsDKhc0nlbkpy5W5xvRcf0OmM8/Tl88eMNO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAQAVGsxY/xbLJq1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQyKmCNcXOQZ4gSjTCCDh8LhS5KAoM+GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEBATY2BgUMAgILDgIBBAEBAScHGwYGHwkIBgEMBgIBAYlkAw0IDrRYh?= =?us-ascii?q?zQNgwkBAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYZJggWCaoJRgiQmhR4FnA86jhG?= =?us-ascii?q?EMYF7iFuGVYhOghJiiBEfOIEEIxYIFxVBhFcdgWNANYlXAQEB?= X-IronPort-AV: E=Sophos;i="5.36,177,1486425600"; d="scan'208";a="651521834" 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; 17 Mar 2017 17:19:48 +0000 Received: from [10.61.70.68] (ams3-vpn-dhcp1604.cisco.com [10.61.70.68]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2HHJfHL029266; Fri, 17 Mar 2017 17:19:43 GMT To: Mehmet Ersue , "'Lou Berger'" , "'Juergen Schoenwaelder'" References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <008501d29f2d$86839240$938ab6c0$@gmail.com> Cc: netmod@ietf.org From: Robert Wilton Message-ID: Date: Fri, 17 Mar 2017 17:19:40 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <008501d29f2d$86839240$938ab6c0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:19:53 -0000 On 17/03/2017 14:48, Mehmet Ersue wrote: > Hi Robert, > > I2RS has a different environment and datastore framework than NETCONF. > NETCONF uses a different datastore framework compared to RESTCONF. Sure. But there should still be *definitive* references of what those datastores mean. Where should the definitive reference for the "intended" and "operational" datastores go? > > DS conceptual model describes an overall picture and defines how it could > like. > Such a concept providing the basis for many environments cannot be > standardized. Why not? > > Protocol WGs are in charge to choose a consistent subset out of the DS > conceptual model and standardize the usage of these DSs as part of the > protocol specification. OK. But where is the definitive reference to those datastores. Having it is an "Informational" draft would seem to be a wrong. Thanks, Rob > > BR, > Mehmet > >> -----Original Message----- >> From: Robert Wilton [mailto:rwilton@cisco.com] >> Sent: Friday, March 17, 2017 3:04 PM >> To: Mehmet Ersue ; 'Lou Berger' ; >> 'Juergen Schoenwaelder' >> Cc: netmod@ietf.org >> Subject: Re: [netmod] draft netmod charter update proposal >> >> Hi, >> >> Would 7950bis be allowed to have a normative reference to an Informational >> RFC that defined the YANG datastores? >> >> If we did a 7950bis document (and it isn't clear that one is actually > required to >> support the revised datastores draft) then does that mean we would also >> need to have a new version of YANG? >> >> That would potentially seem like a backwards step. Also what would it > mean >> for an implementation that is aware of the new datastores but is using a > mix >> of YANG modules with different versions? >> >> I don't understand why the revised datastores draft should not be > standards >> track once the various appendices have been moved out, noting that they >> are really only in the one draft at this stage because it seemed like that > would >> make it easier for folks to review and comment on. >> >> Is the only issue here which WG the draft is being worked on? >> >> Thanks, >> Rob >> >> >> On 17/03/2017 13:22, Mehmet Ersue wrote: >>> I think YANG identities should be standardized with 7950bis. >>> >>> Mehmet >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, March 16, 2017 12:28 PM >>>> To: Juergen Schoenwaelder ; >>>> Mehmet Ersue >>>> Cc: 'Kent Watsen' ; netmod@ietf.org >>>> Subject: Re: [netmod] draft netmod charter update proposal >>>> >>>> Juergen, >>>> >>>> Thank you for the input. I think your point highlights how the >>>> technical contents of a document drives the intended status of a >> document. >>>> Lou >>>> >>>> PS as a reminder to all, intended status of documents is *not* >>>> typically included in charters and are not included in the distributed >> version. >>>> >>>> >>>> >>>> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder >>>> wrote: >>>> >>>>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: >>>>> >>>>>> That said different people including Netconf WG co-chairs think the >>>>>> DS concept document is Informational in nature and should be >>>>>> published as >>>> an >>>>>> Informational concept to be used in and adopted for the needs in >>> diverse >>>>>> protocol WGs. This is as I think also important to avoid an >>>>>> overlapping between NETCONF and NETMOD charters. >>>>> The current datastore draft includes concrete YANG idenity >>>>> definitions for datastores and origins and these definitions better >>>>> be standards track. >>>>> >>>>> /js >>>>> >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>> Fax: +49 421 200 3103 >>>>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> > > . > From nobody Fri Mar 17 10:26:47 2017 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 78A641294EF for ; Fri, 17 Mar 2017 10:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 NPerdFX40UI0 for ; Fri, 17 Mar 2017 10:26:43 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0124.outbound.protection.outlook.com [104.47.2.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D381294D7 for ; Fri, 17 Mar 2017 10:26:43 -0700 (PDT) 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; bh=OiokFMB8VuzXhGUgLs8Wdqc4zbFFooqLzG02wkX9+zc=; b=fGJeY2I6XEmQb7sVmy40dkGyk7a7W/oG4VthqMUgvD6DceDqG3hEHXh6W3J4R5MLpmRC5H0F1CqpB3dSNvradQtraEat8Z6CCIu5pevYQNWN62v4J6v0D0MQD5YwhbGcxjkRmnYOdBce6JEJYedZUdbxCch+q+J0apIfqat9HvA= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.203.75) by AM5PR0701MB2995.eurprd07.prod.outlook.com (10.168.156.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Fri, 17 Mar 2017 17:26:40 +0000 Message-ID: <01f901d29f43$6f09bca0$4001a8c0@gateway.2wire.net> From: t.petch To: Robert Wilton CC: References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> Date: Fri, 17 Mar 2017 17:24:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.203.75] X-ClientProxiedBy: HE1P18901CA0008.EURP189.PROD.OUTLOOK.COM (10.168.181.146) To AM5PR0701MB2995.eurprd07.prod.outlook.com (10.168.156.145) X-MS-Office365-Filtering-Correlation-Id: 5a4e4ec6-e4aa-4cad-37b2-08d46d5ac671 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2995; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 3:aTebWj58G0nEMPdgEeMTGIwUisZBVtxlcZbJIrxKjszoRmUmTZDqLKwQPiSZ4897UFuC9CGPYKcK5MjaOhI2Hz4/xNRWCkEwkOHGFUGMaTW5K+A/QbOcn0zNCafpxh6ZXmBKrTl47q7vk9V0R+2Zqm5giS5MK90ry2bzjuDKeoMpGS9cXd9I5BKeea49gMtBFheeobNwUIkf4eeQ5SbfoDhoAeFkI6TOpt5rgNCt7VYnH1xIiCtddYjFO0SBZpYOc1VmoJmFQhnWGAbbTtdK2w==; 25:fFuscs7CKhS7fmey3E40rl+xMS6PeKopiIA2521Oxpk+mAoiOaVwNds5QnGEk4SnzDP1Y7rIM2URlr6HJ8Ijcd25mUKz1918izq7x3cLkh5KWh1JFkTy5ZdLdmD9dxDrjNy984uusEU3/yljIq1LBoVINezzYyy9VPpnJUf1mM+mIIbktQR35avZgYzXYdD8gLDgngDOjxBf/1OSPUa6IomU9ioYh6NT+g8L3T3CzAN0mxbNrzFxo9cbhd3552FhP75PeE1di53srgJHz8rSBUAwawEEt3Lf4cslRf/NCQeOfzdge6UCSTjQIdDbFxthIvWz2uoLZ/aPJkd3yH5VNIwHyEffp3DGXrIWQguv54FkJ1/Mgu5D+UxUWv4k+FqCLHrPPxpIGR6Hvsc2Uf7I6Rn/lNi76bvtfal1uNG4bZVTseznjwbHQnC1+LEsxeFo6wRfUcqzwutd4LduAzvNcA== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 31:3Iz8tm0yj6xUDX/zIeAN4OFkLNV2BtdhzYT4qQHHO6TtxYzVhY1r7Fx0RV7gL8lwa8gh2LQjgxd5qErrbB2i3nI4KVz1WTursA1GsSvlrPs/JfUUUhbJWN2KxAo4Kg7DbB7oIcFtBQjn5Ttudzn6g9IcAR3Omazb39K5eCXDowMkdIrf2toJB2ri67SMm3+j76siONlEYQjauKFu1iPuOvtM8rD2xBS0MZepR0VEPC91sXajAzVS4sxDQe+AXejFP/2PvGA02jUA1sTZpNfbxP9uBpdkBXq6AcBtDfzF20s= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(20161123558025)(6072148); SRVR:AM5PR0701MB2995; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2995; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 4:v1zfUv/fSFJJDTYqmtumRIGOuoauUH44uc1TOMH+BWfWmzVUtEfEfbjlMXHYfnRfHsb/i6aSAtDE53nNG2cpt8PYD/32BwkdoduVjRQ/b7We+qry4bznZCkvQA8pKA/myDjzd41uS84QbCnecks3rTkylm1xhhw+RCfbJGuxrf4U8xuXeraXtJj3/uOWEUofomgVNxidcsPY1UoMORHzAD9blWd4I6dx3eXj3VbqjArhwAa36lDgrdxqNfYPgohri5YrwE9jWKkTLG8MjriwvtFlN95+97JkYLJ2LFSWHh308SHKkv0ttLoKMSjPH/hXBUfsMmZjqPhbs81BBqrZZx2Nep/RMraNs2q8ZzEuCKlvYZyq8Yt6OCF8gpXitWotfv3zVRbEEdRFz16kaqP6CWXYVodcCMK9RvopfohMH9XsLKhRrTo4NMyfmW3xdVqn20rWPL+U23b63o416nQMEMuTzmeKG9Xa3upNpjY6S0WaVIAKBoAn1Sb5gQXRabI0x4Y78OMJAivC1dpIcapPA8rHcpp69zmLmG+O0csdgNvzNaOe9n8o0389mx3EJh56WXJbZd0+4Ii/QPu/kv8c5jVHe6kGdwwqyeyGlZtjK51GkRH5r+7GfrwLaX6dGaApTzdshc4+v2GkSTPe9h0ZxcdqB1JtD1C7ce0VK7vBiBE6WZlwO70hUf13cb6rJlRD X-Forefront-PRVS: 0249EFCB0B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39450400003)(51444003)(24454002)(377454003)(13464003)(229853002)(4326008)(76176999)(6116002)(14496001)(110136004)(6486002)(230700001)(1556002)(561944003)(25786008)(81166006)(8676002)(50226002)(66066001)(50466002)(33646002)(86362001)(53936002)(53546008)(23756003)(305945005)(44736005)(6306002)(6496005)(3846002)(9686003)(6246003)(345774005)(84392002)(189998001)(7110500001)(6916009)(38730400002)(116806002)(1456003)(50986999)(5660300001)(15650500001)(2420400007)(81816999)(81686999)(61296003)(62236002)(7736002)(4720700003)(44716002)(93886004)(6666003)(42186005)(2906002)(10710500007)(47776003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2995; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM5PR0701MB2995; 23:KkZ4xPsMIkfnkKqUNpFqOfmvmciTU3dxQIn6F?= =?iso-8859-1?Q?nweA5yq1Zubp/cW93gY03H7VrqAhY1MyRIDtiCVrSBwER7MuO4HS/IGx/b?= =?iso-8859-1?Q?d6aSXWkbtDiIHdROMBGNNaH0tOJvnsHJQAa+v9S2ZD/lrxVze2WJP+Eyh2?= =?iso-8859-1?Q?NFzKXJFcxhptEKBZQ0sRwMril+0zoAepGEFhxXY/iLkqbXWW0+cQrmR3+I?= =?iso-8859-1?Q?MB1ElJovURaCsh3vAMxHBcG1akDnWNGNBb6GqDlLAd+3bMHzRT5mvTgd/Q?= =?iso-8859-1?Q?nDIpEQ2dV307wAIldmuBRR/5qftk82QJBzBUJF0lWNQWYByasUBcFnd3V4?= =?iso-8859-1?Q?rWcACXj5lW1W4zLYJ987daglnD1LidroCfsUIqbjyAUFHYlsXdYGjEepkv?= =?iso-8859-1?Q?hN/mrkTQbyo0nEyiEmUaR4HLPKlHdGvGClRuBfIxe7vQ2CgxIOpuhG6shB?= =?iso-8859-1?Q?+SpARMmVjB3H6OjbGTUCZpmvgz4ge96rnX+ybP5nCGSNfzpZm2Uwkr8K7B?= =?iso-8859-1?Q?RAXxSSa1EzSHjkJIYBQEksCeBcH37Jn2j0lepdLO++Sk+e5clW7Qgfzz86?= =?iso-8859-1?Q?exvq0e4dmOELIIe476InAbvuO/7ajulev2b4gH71ZmeY1e2gm1MTCbRD1d?= =?iso-8859-1?Q?S8t3BLFrXjTqP4eCZ3PnNUMjxwz6xRofffmUSROrtb1UHN/p2uu+Uk8q5k?= =?iso-8859-1?Q?gMQIhIOpj8HjUdOAyGqTT6TtIm95HO/vsWJxLmfE7XJNGrymteYspNHYYv?= =?iso-8859-1?Q?7y71azWfqAnJvgDUmBnhY16ROd9cTCuC/EPkuGMUwdj671mkX3YUHspyKk?= =?iso-8859-1?Q?AMksts8W+5+uPOMyboY7DBlkfpkIZ9Rn706OJgkksIPYUyojxQPe+oH37H?= =?iso-8859-1?Q?YuJIAF4w9jr5sS+tYfstTSkcHZX2wSNOPS7y/psdHCJczAwyHvofSMkoN2?= =?iso-8859-1?Q?zYf8WI6YzXdV0KvZ7MUpuRd+Bx9Oq71Oyf+hg7xrCn7rKWT/S4DTHfSgA4?= =?iso-8859-1?Q?fBjXFVI8rqVu9T8EkUuqJdJIwdlVP8Or9Xj4Ejg/gd2vV+4JU9qdjxUs1I?= =?iso-8859-1?Q?c0JIPqrWOqJ5xvQZtkRRiUUaO+ilCVlK4i9JK0kFQrJmmDxYQ4yJajhUaZ?= =?iso-8859-1?Q?6HPVayRfaJxR+oJ7pjNJB8HBi0yVGjY8kKzp23NqilxgjPiikTAy1AGMej?= =?iso-8859-1?Q?tIadMkz1edAS9M/V+4jMlA0ZlJV2YHUADe9HakJJ8SXcmD0xsFqe+aV/8E?= =?iso-8859-1?Q?S37G/TwxSaPPqqwSg/cxiypiJkWnPrG7jo+adO95xWscp4HjJrEUwy6zJU?= =?iso-8859-1?Q?v3OzYL5y21f+bTTDomMM0wXSu3mG3pUPEvFJRMnWv2uE2L90NXOrqhwJcF?= =?iso-8859-1?Q?UVtUPnOLjKCidJoct1Acka4etshIm8L+21HZlmiEQ931Bn6HTdLlEhFv9n?= =?iso-8859-1?Q?8jJLZobos+WcjPTl270jPF2xGWeHZXQ8q7w9oQJi4HvQ0goRlvS6Hz3UZA?= =?iso-8859-1?Q?ppWUdUzAOvSsNNpkOi6Z+LueqKsldsDwywygLvrM1AfDgpw+3v8jcS77DL?= =?iso-8859-1?Q?ZyhPQzA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 6:fg8CJh/yEZGhHEPzQkTn+4xp4HMoegeX2/6oGM1Ys5loKouXxKc5vNjVgc9ej0tyAbzLFdccIQ27LI8HBYEZOHT+e9CtSLPC7pr8s+y13R1Sel7zCp+CjQWOV8icv7a2uN3Xx4OXfn2YxfBrhcUxOnyMUcE7RvNFKrGjdkvgRk0zN8Vaq+1NVVq2Rk5LHhz5KoqNTthgYP+aaDJdyYcUIpgE90Cf5lZRmYeySfvrPtCU4vsGnmZ3/hKYWvX9Y64bku0tjhMKEWokmfvExqjRkZOurLK85UC0p6SF3lmI2ReqSj+J2ufdKZVHkfAgTtxurzkxniGsJX60TYRvTSKcNXssvt3in+bknepQY+GtJY8r5llqa0HT9gOdvPSFewCY0uuUPZGtHaVGwniYNhjuaQ==; 5:pPpkq+KnkXAlSVqA3BrOdLWYk9njHTloLIe1UapApdwhrux3bPkXR/2qU93iRVZYvXRy5rZ0HW2/c/ujTH1p46yP+eXaplA3lXAnjzva2huvEAHAJDVJRmSE3SKkIEg54ulpxCSJVzHeAjTZA/eS/A==; 24:mGX1FI5KqcJr7Xonio0mAus1lAiFw8DwJ4Jov8u+fsbeVQCWqIv1FXz05I4LMf3oDxKL43d3gd+iKVdY4nZSIydW+VD6w/gu6Nd4lQwqxiE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 7:CXncgST/mPOcJoilFnstgJiZEYMbBgbTDOECvxTTgLVvnYkfUyDI+e1RNPMwQYx/UTbIxA7edHvHcWMpPKYoka2QO7Er40dbf7E1+HK6CMWGNS4glv0m03huD9jjtL4UhZQHlgy1rUdfmdYfxfTZ1o3+T/3cLhl1KP3IfZsL+bLKL4hQ5JWkk6yNVQGAqT43RWvsNUkU43cCdA70sFEGOL6shquh0mFYWPCWXXORg4idBU5n/cR11wPsoO5cKZ8dtMSjbFNWd9YYhIwqIk3DtKdomHNOrDDlH6xrz97IA9lSiIjJoLQoS66fs04ryI/W57FuH7EOBSaMjHjb+vODcg== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2017 17:26:40.5140 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2995 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:26:46 -0000 ----- Original Message ----- From: "Robert Wilton" Sent: Friday, March 17, 2017 2:04 PM > > Would 7950bis be allowed to have a normative reference to an > Informational RFC that defined the YANG datastores? No but yes but ... The rules say no but the exception is that the IESG can approve such a downref (and other kinds of downref) after which it is listed as an approved downref, on the IETF website, so the process need only be performed once for a given target RFC for a given type of downref. That said, I think that the rule is sound, and the question of why an Informational RFC should be suitable for a Normative Reference should be asked, at least once. Originally it meant that there was no need to reissue an historic RFC to upgrade its status to be what it probably should have been in the first place but now the process is far more widely used. And I think that revised datastores should be Standards Track! The SNMPv3 Architecture is INTERNET STANDARD which is the kind of model that I have in mind. Tom Petch > If we did a 7950bis document (and it isn't clear that one is actually > required to support the revised datastores draft) then does that mean we > would also need to have a new version of YANG? > > That would potentially seem like a backwards step. Also what would it > mean for an implementation that is aware of the new datastores but is > using a mix of YANG modules with different versions? > > I don't understand why the revised datastores draft should not be > standards track once the various appendices have been moved out, noting > that they are really only in the one draft at this stage because it > seemed like that would make it easier for folks to review and comment on. > > Is the only issue here which WG the draft is being worked on? > > Thanks, > Rob > > > On 17/03/2017 13:22, Mehmet Ersue wrote: > > I think YANG identities should be standardized with 7950bis. > > > > Mehmet > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Thursday, March 16, 2017 12:28 PM > >> To: Juergen Schoenwaelder ; > >> Mehmet Ersue > >> Cc: 'Kent Watsen' ; netmod@ietf.org > >> Subject: Re: [netmod] draft netmod charter update proposal > >> > >> Juergen, > >> > >> Thank you for the input. I think your point highlights how the technical > >> contents of a document drives the intended status of a document. > >> > >> Lou > >> > >> PS as a reminder to all, intended status of documents is *not* typically > >> included in charters and are not included in the distributed version. > >> > >> > >> > >> > >> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder > >> wrote: > >> > >>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: > >>> > >>>> That said different people including Netconf WG co-chairs think the DS > >>>> concept document is Informational in nature and should be published as > >> an > >>>> Informational concept to be used in and adopted for the needs in > > diverse > >>>> protocol WGs. This is as I think also important to avoid an overlapping > >>>> between NETCONF and NETMOD charters. > >>> The current datastore draft includes concrete YANG idenity definitions > >>> for datastores and origins and these definitions better be standards > >>> track. > >>> > >>> /js > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >>> Fax: +49 421 200 3103 > >>> > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Mar 17 15:51:29 2017 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 A704B12965B for ; Fri, 17 Mar 2017 15:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 qOsbjJYxZ1AY for ; Fri, 17 Mar 2017 15:51:22 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 35C59124B0A for ; Fri, 17 Mar 2017 15:51:18 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id u132so25867502wmg.0 for ; Fri, 17 Mar 2017 15:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=qoC2TOhY2xLAQARBRfYiW8Sq99iWSsS5GKjDCgzQhkQ=; b=ciLvaMDmbYlDxAC9qmVU1b8T/IuUryaXVAoj+MKCl9s28Jq4xh5P+Qnxf2jIB9uGG4 Xkxx9edl2awmJAI9/FWVd1Hd9nZaKd3q5LmzpTwY1MrWGzwC979AgJNDO5EMZdKkZrz3 +wF5+9Gm2aaFbBas0S7uohS1cPtcVc23shGjLzPNmVic4t8Q+wYVYDevTABlkAkVPugQ tlAtHuRqZx3mMKX5o2/ZzYK8F1uI7VbN58v7RHpH80Wrg3Eyv2n+Vb/0nTjlT0fyRfTR K3ha6ehsX2Fn6jAlMLh/dj9ddacrSiW3gGY94rqe9tMPkxI8K/fp5PkcPEvpwjTgLxn7 Tvng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=qoC2TOhY2xLAQARBRfYiW8Sq99iWSsS5GKjDCgzQhkQ=; b=O/1h1jK77ucOmn5ojPL3dAu/ZqgGosa3iaIAbk6UeHTIAkn7mnjpCbUNrrQBoesQ+a 49C+0mmng1TVdHv6ErPlbv7KvC6AgBkcvmdn0axsNXeg/FPU1N7tkdeEqGao+90z8e0Y B8si9GKL7G5fsZc3PieFLZ2uoDZld1dxo9hlJgeRzrZfdAzKEHaFFwT35ZOryrkvIFqd DiZJ/j5IUUyjssnVzKz1OdGt+EEyRF3SbxGoxw1svYFzrOwlTT8voBwqwpesc+6zxoBt KhhOClLDST54i0wkOv/1V5V39kbCGT+IemSmZIOnCqQlcJCOibQH5Rto992+0lORMSG6 hqiA== X-Gm-Message-State: AFeK/H0u6avSWdUWvPZhNQRuq69AadH3sBOhE+3LW2m5x8BDGkIjTk7W0adVk6DWZGp9lA== X-Received: by 10.28.20.148 with SMTP id 142mr444546wmu.134.1489791076483; Fri, 17 Mar 2017 15:51:16 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p5B342480.dip0.t-ipconnect.de. [91.52.36.128]) by smtp.gmail.com with ESMTPSA id l41sm11445093wre.23.2017.03.17.15.51.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 15:51:15 -0700 (PDT) From: "Mehmet Ersue" To: "'Lou Berger'" , "'Kent Watsen'" , References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <675654fd-1532-1755-621c-a3ecb06950e3@labn.net> <025a01d29e82$8549d070$8fdd7150$@gmail.com> In-Reply-To: Date: Fri, 17 Mar 2017 23:51:17 +0100 Message-ID: <02c901d29f70$fd0cbe30$f7263a90$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUooBvvnQPAGVQNXrAT+Tz94BQZmbIKCarq1AgAGbAcA= Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0203.58CC6863.00E7,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 22:51:29 -0000 Hi Lou, Kent, I promised to provide some minimal text which can be used as WG item description. I'm fine with any fine tuning. See below: a) Maintaining the data modeling language YANG. This effort entails periodically updating the specification to address new requirements as they arise. ADD b) Maintaining the guidelines for developing YANG models. This effort is primarily driven by updates made to the YANG specification. ADD c) Maintaining a conceptual framework in which YANG models are used. This effort entails describing the generic context that in YANG exists and how certain YANG statements interact in that context. An example of this is YANG's relationship with datastores. ADD . . . e) Maintaining YANG models used as basic YANG building blocks. This effort entails updating existing YANG models (ietf-yang-types and ietf-inet-types) as needed, as well as defining additional core YANG data models when necessary. ADD BTW: There is no topic description (in a)-f) covering YANG module classification. I assume it can be added with a sentence to a) or b). Thanks, Mehmet > -----Original Message----- > From: Mehmet Ersue > Sent: Thursday, March 16, 2017 11:59 PM > To: Lou Berger ; 'Kent Watsen' ; > netmod@ietf.org > Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' > > Subject: RE: [netmod] draft netmod charter update proposal > > > From: Lou Berger [mailto:lberger@labn.net] Mehmet, > > see below. > > On 3/16/2017 2:24 PM, Mehmet Ersue wrote: > > > Lou, > . . . > > > I actually provided a very simple proposal. You guys can fill the > > > idea with minimal text better than me. I'm fine whatever the text is. > > > If you think the high-level topic description a)-f) does already > > > define the WG item clearly you can simply say "this is achieved with > > > WG > > item XY". > > > If not, you can keep the high-level focus text but set additionally > > > the borders of the WG item with a few concrete words. > > > > I really can't tell for sure, but it feels to me that this comment > > boils down to a style comment and you have a preference for different > > contents in the charter. I'd like to be sensitive to this. As our > > style differs, having a concrete proposal on specific text changes > > would be really helpful in us (and the WG) evaluating the changes > > you'd like to see. Without such specific examples and think we're > > left with the charter as currently proposed. Perhaps someone else who > has similar feelings can chime in and provide proposed text. > > > > Anyone else have any comments or proposed changes? > I think the wording depends on the time period is for which the charter is > prepared. > I can try some text once I have time tomorrow. > > . . . > > > I think the DS draft provides a conceptual framework for diverse DS > > > usage scenarios to be used by many protocols, where IETF WGs may > > > actually decide using a subset of the DS framework for their purpose > > > and for their protocol standardization. > > > Based on this the conceptual framework cannot be standardized as it > > > is but the protocols using a consistent subset have to be standardized. > > > Following this consideration I think the intended status of the DS > > > draft should be changed to: Informational RFC If you agree please > > > indicate this change accordingly. > > > > I think Juergen's reply to your previous message highlights that there > > is a difference of opinion here based on the technical specifics of > > the draft. My position as chair is that I'll support whatever makes > > sense based on the document produced by the WG. Today the document > > authors believe PS is appropriate, once we have a version that is > > stabilizing for LC -- which hopefully will be the next version or two > > -- then will be a good time to revisit this. > There are indeed different opinions concerning the goal of the DS draft. > I agree with the document introduction and see it as a conceptual framework > covering many usage scenarios. > Such a conceptual framework describing possible solutions is informational in > nature and is not relevant for standardization. > > > >>> This is as I think also important to avoid an overlapping between > > >>> NETCONF and NETMOD charters. > > >> I don't follow this point. Certainly I'd hope that the protocol > > >> impact of revised DS are covered in a PS document, unless for some > > >> reason there are no "on-the-wire" changes needed. TI wouldn't > > >> expect that the document status of the base revised data store > > >> document would > > impact that. Do you? > > >> If so, how? > > > My comment is actually superfluous if you agree with my > > > considerations above. > > > The worst case would in my opinion happen if the DS conceptual > > > framework covering many high-level DS usage scenarios would be > > > attempted to standardize, which at the end would prescribe protocol > > > WGs what they should be standardizing. > > > > Yang presumes a certain set of functions for the protocols it operates over. > > I'm not sure why having a document that specifies this would be an issue. > This is again an interesting discussion which SHOULD be discussed in a joint > session. > I don't have a strong opinion but it can be seen differently. > > > > In such a case the conceptual framework would most likely cause a > > > competing situation with protocol WG's goals and documents and > > > cannot be adopted successfully. > > > > If a protocol doesn't provide full support for yang (requirements) it > > can't fully support all yang features. If your point is that when > > NetMod changes basic yang functions/operations that this might > > constrain the protocols (and related WGs) over which it operates, then > > I agree that this is the case. How could it be otherwise? > Usually modeling languages provide many language constructs and people > modeling models choose which one is best for their purpose. > The same applies to the DS concept framework. The protocol WGs would like > to have the freedom to choose the subset to adopt from the protocol pov. > > > Thanks, > > > > Lou > > > > > Thanks, > > > Mehmet > > > > > >>> PS: I expect that most of the Netconf WG member read also the > > Netmod > > >>> maillist and therefor skip sending to both ML. > > >>> > > >> Great. > > >> > > >> Thanks. > > >> Lou > > >>> Thanks, > > >>> Mehmet > > >>> > > >>>> -----Original Message----- > > >>>> From: Mehmet Ersue > > >>>> Sent: Thursday, March 9, 2017 7:36 PM > > >>>> To: Lou Berger ; 'Kent Watsen' > > >>>> ; netmod@ietf.org > > >>>> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' > > >>>> > > >>>> Subject: RE: [netmod] draft netmod charter update proposal > > >>>> > > >>>> Hi Lou, > > >>>> > > >>>>> The charters from the last couple of years don't have the > > >>>>> intended > > >>> status -- > > >>>> at least the ones we checked. > > >>>>> I actually feel pretty strongly about this (which of course can > > >>>>> be easily overruled by our AD). It's my experience that > > >>>>> premature discussions on intended status, i.e., before a > > >>>>> document is sufficiently > > >>>> mature, leads to process-focused arguments that detracts from > > >>>> making technical progress. While once a document is mature and > > >>>> core direction/content is fixed, it is generally obvious what > > >>>> status is > > >>> appropriate. > > >>>> The charters from the last couple of years have a short WG item > > >>> definition, > > >>>> which would be IMO sufficient. > > >>>> You are right the intended status is not available since a few > > >>>> years, but > > >>> IMO it > > >>>> is part of the target definition and would be very useful for the > > >>>> draft > > >>> authors > > >>>> and WG members to regard. > > >>>> > > >>>>>> It would be good to bring the high-level topics in relation to > > >>>>>> the WG > > >>>> items. > > >>>>> I'm sorry, I don't understand this last sentence can you rephrase it? > > >>>> What I meant is that the high-level topics a)-f) might be good as > > >>>> WG focus description but are not sufficient as draft target definition. > > >>>> If you think the high-level topic description is more or less the > > >>>> WG item definition, then we could simply write "this is achieved > > >>>> with WG > > > item > > >> XY". > > >>>> If not, we could keep the high-level focus text but set > > >>>> additionally the borders of the WG item with some concrete words. > > >>>> > > >>>>>> BTW: We agreed in diverse discussions that the DS concept is > > >>>> Informational in nature. > > >>>>>> I think this should be corrected in the draft. > > >>>>> So this sounds like an objection to a specific document. This > > >>>>> is a fair point to raise, but in our opinion it is not a charter > > >>>>> impacting point or discussion. If this is in fact the issue > > >>>>> you'd like to raise and discuss, lets do so under a document > > >>>>> specific thread, e.g., > > >>> "Subject: > > >>>> intended status of revised-datastore". > > >>>> > > >>>> I am actually raising this point since November meeting. There > > >>>> are > > >>> different > > >>>> threads where I explained why it is appropriate as Informational. > > >>>> The last thread I remember is at: > > >>>> > > >> > > > https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH1 > > >>>> 1xcY > > >>>> The recent position of NETCONF co-chairs is in > > >>>> > > >> > > > https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd > > >>>> 8qr5k > > >>>> > > >>>> Thank you for your consideration. > > >>>> > > >>>> Regards, > > >>>> Mehmet > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Lou Berger [mailto:lberger@labn.net] > > >>>>> Sent: Wednesday, March 8, 2017 11:28 PM > > >>>>> To: Mehmet Ersue ; 'Kent Watsen' > > >>>>> ; netmod@ietf.org > > >>>>> Subject: Re: [netmod] draft netmod charter update proposal > > >>>>> > > >>>>> Hi Mehmet, > > >>>>> > > >>>>> On 3/8/2017 4:47 PM, Mehmet Ersue wrote: > > >>>>>> Kent, > > >>>>>> > > >>>>>>> we understand that this is how NETCONF charters are > > >>>>>>> structured, but it is not our practice, > > >>>>>> AFAIK it was the NETMOD practice for the charters until today. > > >>>>> The charters from the last couple of years don't have the > > >>>>> intended status -- at least the ones we checked. > > >>>>> > > >>>>> I actually feel pretty strongly about this (which of course can > > >>>>> be easily overruled by our AD). It's my experience that > > >>>>> premature discussions on intended status, i.e., before a > > >>>>> document is sufficiently mature, leads to process-focused > > >>>>> arguments that detracts > > >>> from > > >>>> making technical progress. > > >>>>> While once a document is mature and core direction/content is > > >>>>> fixed, it is generally obvious what status is appropriate. > > >>>>> > > >>>>> > > >>>>>> I did not ask > > >>>>>> more than written in the current charter. > > >>>>>> It would be good to bring the high-level topics in relation to > > >>>>>> the WG > > >>>> items. > > >>>>> I'm sorry, I don't understand this last sentence can you rephrase it? > > >>>>> > > >>>>>>> as the information is available at the top of each draft, and > > >>>>>>> also because > > >>>>> this information need not be fixed when the milestone is added. > > >>>>> > > >>>>>> I believe a WG charter should be self-sufficient covering the > > >>>>>> target definition and intended status of the WG items. > > >>>>>> Otherwise one can change the target for a WG item by simply > > >>>>>> editing the draft abstract anytime. > > >>>>> Per IETF process, all it ever takes to make a change in document > > >>>>> status is WG consensus, and then IESG and IETF buy-in as part of > > >>>>> the > > >>>> publication process. > > >>>>>> BTW: We agreed in diverse discussions that the DS concept is > > >>>>>> Informational in nature. > > >>>>>> I think this should be corrected in the draft. > > >>>>> So this sounds like an objection to a specific document. This > > >>>>> is a fair point to raise, but in our opinion it is not a charter > > >>>>> impacting point or discussion. If this is in fact the issue > > >>>>> you'd like to raise and discuss, lets do so under a document > > >>>>> specific thread, e.g., > > >>> "Subject: > > >>>>> intended status of revised-datastore". > > >>>>> > > >>>>> Thanks, > > >>>>> Lou > > >>>>> > > >>>>>> Mehmet > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of > > Kent > > >>>>>>> Watsen > > >>>>>>> Sent: Wednesday, March 8, 2017 7:45 PM > > >>>>>>> To: netmod@ietf.org > > >>>>>>> Cc: netmod-chairs@ietf.org > > >>>>>>> Subject: Re: [netmod] draft netmod charter update proposal > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Hi NETMOD WG, > > >>>>>>> > > >>>>>>> Please find below draft-4 having the following change: > > >>>>>>> > > >>>>>>> - added "(e.g., I2RS, RTGWG)" to a sentence. > > >>>>>>> > > >>>>>>> Hi Sue, Lou and I looked at the proposed charter and found a > > >>>>>>> sentence that nicely describes our WG's intent to work with > > >>>>>>> and support other WGs (beyond NETCONF), but we felt that the > > >>>>>>> text could be made more clear by adding in the above-mentioned > > change. > > >>>>>>> Beyond this, and the existing a), > > >>>>>> b), > > >>>>>>> and c), we believe that the charter proposal covers our > > >>>>>>> support for I2RS, > > >>>>>> do > > >>>>>>> you agree? > > >>>>>>> > > >>>>>>> Hi Mehmet, regarding putting a short description and the > > >>>>>>> intended status > > >>>>>> for > > >>>>>>> each draft into the charter, we understand that this is how > > >>>>>>> NETCONF > > >>>>>> charters > > >>>>>>> are structured, but it is not our practice, as the information > > >>>>>>> is > > >>>>>> available at the > > >>>>>>> top of each draft, and also because this information need not > > >>>>>>> be fixed > > >>>>>> when > > >>>>>>> the milestone is added. > > >>>>>>> > > >>>>>>> All, Any other comments? > > >>>>>>> > > >>>>>>> Kent > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Network Modeling (NETMOD) > > >>>>>>> ------------------------- > > >>>>>>> > > >>>>>>> Charter > > >>>>>>> > > >>>>>>> Current Status: Active > > >>>>>>> > > >>>>>>> Chairs: > > >>>>>>> Lou Berger > > >>>>>>> Kent Watsen > > >>>>>>> > > >>>>>>> Operations and Management Area Directors: > > >>>>>>> Benoit Claise > > >>>>>>> Joel Jaeggli > > >>>>>>> > > >>>>>>> Operations and Management Area Advisor: > > >>>>>>> Benoit Claise > > >>>>>>> > > >>>>>>> Secretary: > > >>>>>>> Zitao (Michael) Wang > > >>>>>>> > > >>>>>>> Mailing Lists: > > >>>>>>> General Discussion: netmod@ietf.org > > >>>>>>> To Subscribe: > https://www.ietf.org/mailman/listinfo/netmod > > >>>>>>> Archive: > > >>> https://mailarchive.ietf.org/arch/browse/netmod/ > > >>>>>>> Description of Working Group: > > >>>>>>> > > >>>>>>> The Network Modeling (NETMOD) working group is responsible > > >>>>>>> for the YANG > > >>>>>>> data modeling language, and guidelines for developing YANG > > >> models. > > >>>>> The > > >>>>>>> NETMOD working group addresses general topics related to > > >>>>>>> the use of > > >>>>> the > > >>>>>>> YANG language and YANG models, for example, the mapping of > > >> YANG > > >>>>>>> modeled > > >>>>>>> data into various encodings. Finally, the NETMOD working > group > > >>>>>>> also defines core YANG models used as basic YANG building > > >>>>>>> blocks, > > >>>> and > > >>>>>>> YANG models that do not otherwise fall under the charter of > > >>>>>>> any > > >>> other > > >>>>>>> IETF working group. > > >>>>>>> > > >>>>>>> The NETMOD WG is responsible for: > > >>>>>>> > > >>>>>>> a) Maintaining the data modeling language YANG. This > > >>>>>>> effort > > >>> entails > > >>>>>>> periodically updating the specification to address new > > >>> requirements > > >>>>>>> as they arise. > > >>>>>>> > > >>>>>>> b) Maintaining the guidelines for developing YANG models. > > >>>>>>> This > > >>> effort > > >>>>>>> is primarily driven by updates made to the YANG specification. > > >>>>>>> > > >>>>>>> c) Maintaining a conceptual framework in which YANG models > > >>>>>>> are > > >>>> used. > > >>>>>>> This effort entails describing the generic context that > > >>>>>>> in > > > YANG > > >>>>>>> exists and how certain YANG statements interact in that > > >>> context. > > >>>>>>> An example of this is YANG's relationship with datastores. > > >>>>>>> > > >>>>>>> d) Maintaining encodings for YANG modeled data. This > > >>>>>>> effort > > >>> entails > > >>>>>>> updating encodings already defined by the NETMOD working > > >>>>>>> (XML > > >>>> and > > >>>>>>> JSON) to accommodate changes to the YANG specification, > > >>>>>>> and > > >>>>> defining > > >>>>>>> new encodings that are needed, and yet do not fall under > > >>>>>>> the > > >>> charter > > >>>>>>> of any other active IETF working group. > > >>>>>>> > > >>>>>>> e) Maintaining YANG models used as basic YANG building > blocks. > > >>> This > > >>>>>>> effort entails updating existing YANG models > > >>>>>>> (ietf-yang-types > > >>> and > > >>>>>>> ietf-inet-types) as needed, as well as defining > > >>>>>>> additional core > > >>> YANG > > >>>>>>> data models when necessary. > > >>>>>>> > > >>>>>>> f) Defining and maintaining YANG models that do not fall > > >>>>>>> under > > > the > > >>>>>>> charter of any other active IETF working group. > > >>>>>>> > > >>>>>>> The NETMOD working group consults with the NETCONF > working > > >>>> group > > >>>>> to > > >>>>>>> ensure that new requirements are understood and can be met > > >>>>>>> by > > >> the > > >>>>>>> protocols (e.g., NETCONF and RESTCONF) developed within > > >>>>>>> that > > >>>> working > > >>>>>>> group. The NETMOD working group coordinates with other > > >>>>>>> working > > >>>>> groups > > >>>>>>> (e.g., I2RS, RTGWG) on possible extensions to YANG to > > >>>>>>> address > > new > > >>>>>>> modeling requirements and, when needed, which group will > > >>>>>>> run > > the > > >>>>>>> process on a specific model. > > >>>>>>> > > >>>>>>> The NETMOD working group does not serve as a review team > > >>>>>>> for > > >>>> YANG > > >>>>>>> modules developed by other working groups. Instead, the > > >>>>>>> YANG > > >>>>> doctors, > > >>>>>>> as organized by the OPS area director responsible for network > > >>>>>>> management, will act as advisors for other working groups > > >>>>>>> and > > >>> provide > > >>>>>>> YANG reviews for the OPS area directors. > > >>>>>>> > > >>>>>>> Milestones: > > >>>>>>> > > >>>>>>> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for > > >>> publication > > >>>>>>> Mar 2017 - Submit > > >>>>>>> draft-ietf-netmod-yang-model-classification > > >>>>>>> to > > >>> IESG > > >>>>>>> for publication > > >>>>>>> Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for > > >>> publication > > >>>>>>> Apr 2017 - Submit draft-ietf-netmod-entity to IESG for > > > publication > > >>>>>>> Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG > > >>>>>>> for > > >>>>>> publication > > >>>>>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG > > >>>>>>> for > > >>>>>> publication > > >>>>>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to > > >>>>>>> IESG > > > for > > >>>>>>> publication > > >>>>>>> Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > > >>>>>>> publication > > >>>>>>> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to > > >>>>>>> IESG > > > for > > >>>>>>> publication > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> 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 dbannister@netflix.com Thu Mar 16 11:23:54 2017 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 F2374129876 for ; Thu, 16 Mar 2017 11:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 plQhyLK3KtgF for ; Thu, 16 Mar 2017 11:23:50 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 F3F7E129881 for ; Thu, 16 Mar 2017 11:23:48 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id f54so31464717uaa.1 for ; Thu, 16 Mar 2017 11:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WXOT9xabqD16feURRyeTJH0lpjtJVzBrct8Kw5R0INc=; b=OEQkzfIHfWSlupktjbJYOz3Jl0pNPzBiT79g2V4TgNqKi3vaCItshOSdjLmMAaftlN GSyV/jStFfxYZ1MEz3ol+2m4TtpJ1c0d7iuKOSX9uY1zfcNp6ZelJdNXvaO9C25Hm4sY TPRXj47U04bkhy2wk66LJrnaHwrS9QOOKcgV8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WXOT9xabqD16feURRyeTJH0lpjtJVzBrct8Kw5R0INc=; b=FztH9euF6T2nKlt0NYB5iD2XibHqttK0eQSTeXwU19GGHiZHUCI4KICxzxWHzq7+a/ cZKzQaFnxfqopG0/LZA6pFml8BC37K2mRAy4iGTShCIW4PkWCkJymFyndfy1iU9YLNpR CS1SjnsF6wUVSUkiPgsq1C7PjdyAa05TgcF8lfpT8Qv4HMXya8EAVcwsPmnwfdzt5xaN 4c2znjHgTYtYe0lPBIDV0xBSnScAhvSBIvgbAENtUOkPxOkvFOJ70XIQhFnUVDmlguol PzJBxVcQpx5Q55CE2zTKXfCdQ1deHRPxhTTeRxEbgHMB/XgCcBWsLgqRTH2ueBYK0Bc4 05rw== X-Gm-Message-State: AFeK/H0v5xhb+J0owlVfCtJuafb6JzEjMsz7rPhMu+FkDDnW7d1afVyOxz9abGO0wC2FwnU7gyPOiRlvno1AfMdP X-Received: by 10.176.24.218 with SMTP id d26mr4713811uah.117.1489688627878; Thu, 16 Mar 2017 11:23:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.33.72 with HTTP; Thu, 16 Mar 2017 11:23:47 -0700 (PDT) In-Reply-To: <4D50BFD4-0E59-4DF8-BEC9-0D9BE50F5BA6@juniper.net> References: <148939875845.17039.4017763838166134753.idtracker@ietfa.amsl.com> <4D50BFD4-0E59-4DF8-BEC9-0D9BE50F5BA6@juniper.net> From: David Bannister Date: Thu, 16 Mar 2017 14:23:47 -0400 Message-ID: To: Kent Watsen Cc: Dean Bogdanovic , NetMod WG Content-Type: multipart/alternative; boundary=f403043548507e13f4054add299c Archived-At: Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 01:35:42 -0000 --f403043548507e13f4054add299c Content-Type: text/plain; charset=UTF-8 There were no changes to the model so my concerns remain the same. Augmentation is not a scalable solution when dealing with a mutli-vendor or in some instances a multi-business-unit environment. The 'newco' example in the draft illustrates this problem. The IETF produces a 'standard' for an ACL draft which is so sparse in nature that it must be augmented by each vendor. In the best case this gives me a unique model per vendor because we know the vendors are not going to get together to define the missing pieces. The vendors will use a variety of mechanisms to complete the model from using a script to build their models from source code, handling the missing pieces as arbitrary code (anyxml), or everything as a string. Then there is the worse case where a vendor has no internal standardization (you know who you are) and their own product lines will not align into a common model. The object here, for me, is to get to a single model for all vendors barring a unique feature that belongs to one vendor in which case augmentation is acceptable. Could you add to this in the future and rev up the RFC? Sure. However, I am not sure what value that brings to the community. In its current form I would not ask any of my vendors to implement this draft. Instead I would push them towards the OpenConfig ACL model. On Tue, Mar 14, 2017 at 9:12 PM, Kent Watsen wrote: > Hi David, > > > > Can you please confirm that the additional examples address your concern? > And, if not, please > > explain if there is any reason why what you're looking for couldn't be > added or augmented in > > in the future. > > > > Thanks, > > Kent // shepherd > > > > On 3/13/17, 5:57 AM, "netmod on behalf of Dean Bogdanovic" < > netmod-bounces@ietf.org on behalf of ivandean@gmail.com> wrote: > > > > Here is the new version of the ACL draft. Since December and some > additional comments about the ACL model, I spoke with many operators and > how they use ACLs. I have also received lot of detailed ACL configurations. > In most cases, the model is easily adapted to the current use cases in > operations. But to answer the comments, the authors have added a detailed > example in the addendum section how the model can be extended and how this > model can be used. > > > > Cheers, > > > > Dean > > > > > > Begin forwarded message: > > > > *From: *internet-drafts@ietf.org > > *Subject: New Version Notification for draft-ietf-netmod-acl-model-10.txt* > > *Date: *March 13, 2017 at 10:52:38 AM GMT+1 > > *To: *, "Kiran Koushik" , > "Lisa Huang" , "Dean Bogdanovic" , > "Dana Blair" , "Kiran Agrahara Sreenivasa" < > kkoushik@cisco.com> > > > > > A new version of I-D, draft-ietf-netmod-acl-model-10.txt > has been successfully submitted by Dean Bogdanovic and posted to the > IETF repository. > > Name: draft-ietf-netmod-acl-model > Revision: 10 > Title: Network Access Control List (ACL) YANG Data Model > Document date: 2017-03-13 > Group: netmod > Pages: 32 > URL: https://www.ietf.org/internet-drafts/draft- > ietf-netmod-acl-model-10.txt > Status: https://datatracker.ietf.org/doc/draft-ietf- > netmod-acl-model/ > Htmlized: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-10 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf- > netmod-acl-model-10 > > Abstract: > This document describes a data model of Access Control List (ACL) > basic building blocks. > > Editorial Note (To be removed by RFC Editor) > > This draft contains many placeholder values that need to be replaced > with finalized values at the time of publication. This note > summarizes all of the substitutions that are needed. Please note > that no other RFC Editor instructions are specified anywhere else in > this document. > > Artwork in this document contains shorthand references to drafts in > progress. Please apply the following replacements > > o "XXXX" --> the assigned RFC value for this draft. > > o Revision date in model (Oct 12, 2016) needs to get updated with > the date the draft gets approved. The date also needs to get > reflected on the line with . > > > > > 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. > > The IETF Secretariat > > > --f403043548507e13f4054add299c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There were no changes to the model so my concerns remain t= he same.=C2=A0 Augmentation is not a scalable solution when dealing with a = mutli-vendor or in some instances a multi-business-unit environment.=C2=A0 = The 'newco' example in the draft illustrates this problem.=C2=A0 Th= e IETF produces a 'standard' for an ACL draft which is so sparse in= nature that it must be augmented by each vendor.=C2=A0 In the best case th= is gives me a unique model per vendor because we know the vendors are not g= oing to get together to define the missing pieces.=C2=A0 The vendors will u= se a variety of mechanisms to complete the model from using a script to bui= ld their models from source code, handling the missing pieces as arbitrary = code (anyxml), or everything as a string.=C2=A0 Then there is the worse cas= e where a vendor has no internal standardization (you know who you are) and= their own product lines will not align into a common model.=C2=A0 The obje= ct here, for me, is to get to a single model for all vendors barring a uniq= ue feature that belongs to one vendor in which case augmentation is accepta= ble. =C2=A0

Could you add to this in the future and rev = up the RFC?=C2=A0 Sure.=C2=A0 However, I am not sure what value that brings= to the community.=C2=A0 In its current form I would not ask any of my vend= ors to implement this draft.=C2=A0 Instead I would push them towards the Op= enConfig ACL model. =C2=A0

On Tue, Mar 14, 2017 at 9:12 PM, Kent Watsen <kwats= en@juniper.net> wrote:

Hi David,=

=C2=A0=

Can you please c= onfirm that the additional examples address your concern?=C2=A0 And, if not= , please

explain if there= is any reason why what you're looking for couldn't be added or aug= mented in

in the future.

=C2=A0=

Thanks,

Kent // shepherd=

=C2=A0=

On 3/13/17, 5:57 AM, "netmod on behalf of Dean = Bogdanovic" <netmod-bounces@ietf.org on behalf of ivandean@gmail.com<= /a>> wrote:

=C2=A0

Here is the new version of the ACL draft. Since Dece= mber and some additional comments about the ACL model, I spoke with many op= erators and how they use ACLs. I have also received lot of detailed ACL con= figurations. In most cases, the model is easily adapted to the current use cases in operations. But to answer th= e comments, the authors have added a detailed example in the addendum secti= on how the model can be extended and how this model can be used.

=C2=A0

Cheers,

=C2=A0

Dean

=C2=A0



Begin forwarded message:

=C2=A0

Subject: New Version Notification for draft-ietf-netmod-acl-model-10.txt

Date: March 13, 2017 at 10:52:38 AM GMT+1

To: <netmod-cha= irs@ietf.org>, "Kiran Koushik" <kkoushik@cisco.com>, "Lisa Huang" <lyihuang16@gmail.com>, "Dean Bogdanovic" <<= a href=3D"mailto:ivandean@gmail.com" target=3D"_blank">ivandean@gmail.com>, "Dana Blair" <dblair@cisco.com>, "Kiran Agrahara Sreenivasa&quo= t; <kkoushik@cisco= .com>

=C2=A0


A new version of I-D, draft-ietf-netmod-acl-model-10.txt
has been successfully submitted by Dean Bogdanovic and posted to the
IETF repository.

Name: draft-ietf= -netmod-acl-model
Revision: 10
Title: Network A= ccess Control List (ACL) YANG Data Model
Document date: 2= 017-03-13
Group: netmod Pages: 32
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-ietf-netmod-acl-model-10.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.i= etf.org/html/draft-ietf-netmod-acl-model-10
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-net= mod-acl-model-10

Abstract:
=C2=A0=C2=A0This document describes a data model of Access Control List (AC= L)
=C2=A0=C2=A0basic building blocks.

=C2=A0=C2=A0Editorial Note (To be removed by RFC Editor)

=C2=A0=C2=A0This draft contains many placeholder values that need to be rep= laced
=C2=A0=C2=A0with finalized values at the time of publication.=C2=A0 This no= te
=C2=A0=C2=A0summarizes all of the substitutions that are needed.=C2=A0 Plea= se note
=C2=A0=C2=A0that no other RFC Editor instructions are specified anywhere el= se in
=C2=A0=C2=A0this document.

=C2=A0=C2=A0Artwork in this document contains shorthand references to draft= s in
=C2=A0=C2=A0progress.=C2=A0 Please apply the following replacements

=C2=A0=C2=A0o =C2=A0"XXXX" --> the assigned RFC value for this= draft.

=C2=A0=C2=A0o =C2=A0Revision date in model (Oct 12, 2016) needs to get upda= ted with
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the date the draft gets approved.=C2=A0 The d= ate also needs to get
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0reflected on the line with <CODE BEGINS>= ;.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=C2=A0


--f403043548507e13f4054add299c-- From nobody Sat Mar 18 07:18:54 2017 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 3650E126C7B for ; Sat, 18 Mar 2017 07:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 lHet1q9OVWvx for ; Sat, 18 Mar 2017 07:18:49 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ACB712708C for ; Sat, 18 Mar 2017 07:18:49 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id k62so2144233vkb.1 for ; Sat, 18 Mar 2017 07:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g5+9EIWrc7OUdXn37bVvkpQtV+ULHcKAPeo/v9YP8CM=; b=NJE+N/vf1o2FiTvnhtCGjAjj8HDgFhPuAvEDIeZRHZ80JVZIJsKmGUgu8p7l9mNQIl iGiJeBd80USDLA7/VEcYPRkrpFMvJLuXoNpFnQvR2azX1EtznnSs7kAO99TT3YYp25It Rh5muqY2NAiAZQ8ikH1Nim5PgKTZ3Hsl/X5NM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g5+9EIWrc7OUdXn37bVvkpQtV+ULHcKAPeo/v9YP8CM=; b=BFLYuIjuHTFtC2rEyjJHzZ39JBOeqSyd7TuQrVGtQGSJkNeyHiLENZmdeRdCPElJR0 c13u1tszpOCvElJQoli7k7PMnYtRVN5sSwPUpeOeml5u3JEAF0qRct8rM3iT+GwvqTTA /+IWcWUjDeB38ns0OzM0a/ciKfKv8ktOwV5I9S+ID7Fv3dZKPuBWuxr/qKnIa6OIdUNC 5GvJ4urbh81RuskdLIfCJL+0KuCpV3fIlrnSBuIIkYacMuXsAbW6WOS2RunezAvHEPhZ EpCfaSbIawLg7ERP4iFrm1c3AxQUPOmwJdzvUrYWH2CRfvzwu52G8TC5w18js7l6pFmR 39Lg== X-Gm-Message-State: AFeK/H2pANffDTUWnvy96wLGkkdtFi88fhopuN2rJ3qRBxvO73TFrDZpFFx6NHZj+/46ZlEGRNtw211aNl5XNW82 X-Received: by 10.31.227.132 with SMTP id a126mr6826693vkh.74.1489846728475; Sat, 18 Mar 2017 07:18:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.33.72 with HTTP; Sat, 18 Mar 2017 07:18:48 -0700 (PDT) In-Reply-To: <4D50BFD4-0E59-4DF8-BEC9-0D9BE50F5BA6@juniper.net> References: <148939875845.17039.4017763838166134753.idtracker@ietfa.amsl.com> <4D50BFD4-0E59-4DF8-BEC9-0D9BE50F5BA6@juniper.net> From: David Bannister Date: Sat, 18 Mar 2017 10:18:48 -0400 Message-ID: To: Kent Watsen Cc: Dean Bogdanovic , NetMod WG Content-Type: multipart/alternative; boundary=001a114df5d805641b054b01f982 Archived-At: Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 14:18:53 -0000 --001a114df5d805641b054b01f982 Content-Type: text/plain; charset=UTF-8 (second try) There were no changes to the model so my concerns remain the same. Augmentation is not a scalable solution when dealing with a mutli-vendor or in some instances a multi-business-unit environment. The 'newco' example in the draft illustrates this problem. The IETF produces a 'standard' for an ACL draft which is so sparse in nature that it must be augmented by each vendor. In the best case this gives me a unique model per vendor because we know the vendors are not going to get together to define the missing pieces. The vendors will use a variety of mechanisms to complete the model from using a script to build their models from source code, handling the missing pieces as arbitrary code (anyxml), or everything as a string. Then there is the worse case where a vendor has no internal standardization (you know who you are) and their own product lines will not align into a common model. The object here, for me, is to get to a single model for all vendors barring a unique feature that belongs to one vendor in which case augmentation is acceptable. Could you add to this in the future and rev up the RFC? Sure. However, I am not sure what value that brings to the community. In its current form I would not ask any of my vendors to implement this draft. Instead I would push them towards the OpenConfig ACL model. On Tue, Mar 14, 2017 at 9:12 PM, Kent Watsen wrote: > Hi David, > > > > Can you please confirm that the additional examples address your concern? > And, if not, please > > explain if there is any reason why what you're looking for couldn't be > added or augmented in > > in the future. > > > > Thanks, > > Kent // shepherd > > > > On 3/13/17, 5:57 AM, "netmod on behalf of Dean Bogdanovic" < > netmod-bounces@ietf.org on behalf of ivandean@gmail.com> wrote: > > > > Here is the new version of the ACL draft. Since December and some > additional comments about the ACL model, I spoke with many operators and > how they use ACLs. I have also received lot of detailed ACL configurations. > In most cases, the model is easily adapted to the current use cases in > operations. But to answer the comments, the authors have added a detailed > example in the addendum section how the model can be extended and how this > model can be used. > > > > Cheers, > > > > Dean > > > > > > Begin forwarded message: > > > > *From: *internet-drafts@ietf.org > > *Subject: New Version Notification for draft-ietf-netmod-acl-model-10.txt* > > *Date: *March 13, 2017 at 10:52:38 AM GMT+1 > > *To: *, "Kiran Koushik" , > "Lisa Huang" , "Dean Bogdanovic" , > "Dana Blair" , "Kiran Agrahara Sreenivasa" < > kkoushik@cisco.com> > > > > > A new version of I-D, draft-ietf-netmod-acl-model-10.txt > has been successfully submitted by Dean Bogdanovic and posted to the > IETF repository. > > Name: draft-ietf-netmod-acl-model > Revision: 10 > Title: Network Access Control List (ACL) YANG Data Model > Document date: 2017-03-13 > Group: netmod > Pages: 32 > URL: https://www.ietf.org/internet-drafts/draft- > ietf-netmod-acl-model-10.txt > Status: https://datatracker.ietf.org/doc/draft-ietf- > netmod-acl-model/ > Htmlized: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-10 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf- > netmod-acl-model-10 > > Abstract: > This document describes a data model of Access Control List (ACL) > basic building blocks. > > Editorial Note (To be removed by RFC Editor) > > This draft contains many placeholder values that need to be replaced > with finalized values at the time of publication. This note > summarizes all of the substitutions that are needed. Please note > that no other RFC Editor instructions are specified anywhere else in > this document. > > Artwork in this document contains shorthand references to drafts in > progress. Please apply the following replacements > > o "XXXX" --> the assigned RFC value for this draft. > > o Revision date in model (Oct 12, 2016) needs to get updated with > the date the draft gets approved. The date also needs to get > reflected on the line with . > > > > > 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. > > The IETF Secretariat > > > --001a114df5d805641b054b01f982 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(second try)<= /div>There were no changes to the model so= my concerns remain the same.=C2=A0 Augmentation is not a scalable solution= when dealing with a mutli-vendor or in some instances a multi-business-uni= t environment.=C2=A0 The 'newco' example in the draft illustrates t= his problem.=C2=A0 The IETF produces a 'standard' for an ACL draft = which is so sparse in nature that it must be augmented by each vendor.=C2= =A0 In the best case this gives me a unique model per vendor because we kno= w the vendors are not going to get together to define the missing pieces.= =C2=A0 The vendors will use a variety of mechanisms to complete the model f= rom using a script to build their models from source code, handling the mis= sing pieces as arbitrary code (anyxml), or everything as a string.=C2=A0 Th= en there is the worse case where a vendor has no internal standardization (= you know who you are) and their own product lines will not align into a com= mon model.=C2=A0 The object here, for me, is to get to a single model for a= ll vendors barring a unique feature that belongs to one vendor in which cas= e augmentation is acceptable. =C2=A0
=
Could you add to this in the futu= re and rev up the RFC?=C2=A0 Sure.=C2=A0 However, I am not sure what value = that brings to the community.=C2=A0 In its current form I would not ask any= of my vendors to implement this draft.=C2=A0 Instead I would push them tow= ards the OpenConfig ACL model. =C2=A0

On Tue, Mar 14, 2017 at 9:12 PM, Kent Watse= n <kwatsen@juniper.net> wrote:

Hi David,=

=C2=A0=

Can you please c= onfirm that the additional examples address your concern?=C2=A0 And, if not= , please

explain if there= is any reason why what you're looking for couldn't be added or aug= mented in

in the future.

=C2=A0=

Thanks,

Kent // shepherd=

=C2=A0=

On 3/13/17, 5:57 AM, "netmod on behalf of Dean = Bogdanovic" <netmod-bounces@ietf.org on behalf of ivandean@gmail.com<= /a>> wrote:

=C2=A0

Here is the new version of the ACL draft. Since Dece= mber and some additional comments about the ACL model, I spoke with many op= erators and how they use ACLs. I have also received lot of detailed ACL con= figurations. In most cases, the model is easily adapted to the current use cases in operations. But to answer th= e comments, the authors have added a detailed example in the addendum secti= on how the model can be extended and how this model can be used.

=C2=A0

Cheers,

=C2=A0

Dean

=C2=A0



Begin forwarded message:

=C2=A0

Subject: New Version Notification for draft-ietf-netmod-acl-model-10.txt

Date: March 13, 2017 at 10:52:38 AM GMT+1

To: <netmod-cha= irs@ietf.org>, "Kiran Koushik" <kkoushik@cisco.com>, "Lisa Huang" <lyihuang16@gmail.com>, "Dean Bogdanovic" <<= a href=3D"mailto:ivandean@gmail.com" target=3D"_blank">ivandean@gmail.com>, "Dana Blair" <dblair@cisco.com>, "Kiran Agrahara Sreenivasa&quo= t; <kkoushik@cisco= .com>

=C2=A0


A new version of I-D, draft-ietf-netmod-acl-model-10.txt
has been successfully submitted by Dean Bogdanovic and posted to the
IETF repository.

Name: draft-iet= f-netmod-acl-model
Revision: 10 Title: Network = Access Control List (ACL) YANG Data Model
Document date: = 2017-03-13
Group: netmod Pages: 32
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-ietf-netmod-acl-model-10.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.i= etf.org/html/draft-ietf-netmod-acl-model-10
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-net= mod-acl-model-10

Abstract:
=C2=A0=C2=A0This document describes a data model of Access Control List (AC= L)
=C2=A0=C2=A0basic building blocks.

=C2=A0=C2=A0Editorial Note (To be removed by RFC Editor)

=C2=A0=C2=A0This draft contains many placeholder values that need to be rep= laced
=C2=A0=C2=A0with finalized values at the time of publication.=C2=A0 This no= te
=C2=A0=C2=A0summarizes all of the substitutions that are needed.=C2=A0 Plea= se note
=C2=A0=C2=A0that no other RFC Editor instructions are specified anywhere el= se in
=C2=A0=C2=A0this document.

=C2=A0=C2=A0Artwork in this document contains shorthand references to draft= s in
=C2=A0=C2=A0progress.=C2=A0 Please apply the following replacements

=C2=A0=C2=A0o =C2=A0"XXXX" --> the assigned RFC value for this= draft.

=C2=A0=C2=A0o =C2=A0Revision date in model (Oct 12, 2016) needs to get upda= ted with
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the date the draft gets approved.=C2=A0 The d= ate also needs to get
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0reflected on the line with <CODE BEGINS>= ;.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=C2=A0


--001a114df5d805641b054b01f982-- From nobody Sat Mar 18 12:23:42 2017 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 B4E2B129412 for ; Sat, 18 Mar 2017 12:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgIESRatTQq3 for ; Sat, 18 Mar 2017 12:23:38 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A690126C83 for ; Sat, 18 Mar 2017 12:23:38 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id u132so37238186wmg.0 for ; Sat, 18 Mar 2017 12:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=wQdUZ3TyDXvyl8YsiYEoXA/BXrdUv7oqV7uDbs9afYM=; b=rQ/swx1EHZqVJcLF0+mtUCmmZKz0AJZFjeJQsnMKzKuzzNrvRHwHXmAQZ7eYDWZcon Lz9AOQH/rPpuWnD+W95j2/anvUpLiQlU+5xSdeSCz+Zznb2cRVhXPplf4fxosaupwPM3 uDlw+1JxnSXwjHQD5zD7LwgYE8EwPzDzqBKISo8Y/xCrxJBGUHHmnmBXShjARpl4urTO YpJbmktgI8LoXr8oh9UvDEohDA37bIXx0BmWmFZ4BOQoijQFoXKGvkc1O4nsc5xyoJ78 d6C13P7mIYqNsIK4jiBsCX2aPO68MYIvgZlhJ71ktpko65YpwHQSDNAYcGc3WFJu4mGo A6Ww== 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=wQdUZ3TyDXvyl8YsiYEoXA/BXrdUv7oqV7uDbs9afYM=; b=XdtjtXOu1k1CqM1m/JXpzPsnpwDwlbNUhhj5GsK2pA4SGZ62uRBTmL+QZye+t1s0DT TTN7kXYAQjhYtuPTKG6XPo/dY/GdIR/jePa4W8DCEgqcCSkIy+5AFV9JqfStZjeSIujA nsfm4z26WLB0ZqS7NKNsJFT41QZ6Tn/r/niPeotJwV9zBdLBh5J+FKPfLCN3R1qC2bmn K6nYn4+Se7S10+4qOKOHrsuaIcUL/sFM2nrd9WZuO3fFnxCqJEFzTMrigE+EQ603TcyI y04/yQaz/loLnkGfIS0Mg8xmdGGsTZh73jkkbcLjU6lWDH5R21m2a2LMwBckPFYYQoBD flXg== X-Gm-Message-State: AFeK/H36PeGh96feL/l2TJ7X0sCdVMmPLIJiyGzco1rTmJ8gpExtMkYXZmqcCFjNRXErd/HLHWPXdoDplDd7zQ== X-Received: by 10.28.103.3 with SMTP id b3mr3273770wmc.99.1489865016908; Sat, 18 Mar 2017 12:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.166.37 with HTTP; Sat, 18 Mar 2017 12:23:36 -0700 (PDT) From: Andy Bierman Date: Sat, 18 Mar 2017 12:23:36 -0700 Message-ID: To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a114a91b218b53b054b063bef Archived-At: Subject: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 19:23:41 -0000 --001a114a91b218b53b054b063bef Content-Type: text/plain; charset=UTF-8 Hi, I like this draft -- even more than I like datastores. Looks like some thought went into the terminology section. One minor concern: sec. 4.1: On a traditional NETCONF implementation, and are always the same. The intended datastore is completely proprietary. Is that part of the architecture or are there any plans for the standards to have some purpose for the intended datastore? I want to support 2 datastores that don't fit your descriptions very well: factory: read-only config representing the values that a factory reset would use. Allows copy-config to support a factory config reload. library-config: needed as a bootstrap datastore with the module/bundle configuration. Like the ietf-yang-library, but the config does not exactly match the structure of the YANG library. Can vendors add datastores to a server? Or is this IANA-registered? And/or hard-wired in RFCs? Andy --001a114a91b218b53b054b063bef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I like this draft -- even more than= I like datastores.
Looks like some thought went into the termino= logy section.

One minor concern:

sec. 4.1:

   On a traditional NETCONF imple=
mentation, <running> and <intended> are
   always the same.

The intended datastore is completely propri= etary.
Is that part of the architecture or are there any plans fo= r the standards
to have some purpose for the intended datastore? = =C2=A0


I want to support 2 datastor= es that don't fit your descriptions very well:

factory: =C2=A0read-only config representing the values that a factory res= et
would use.=C2=A0 Allows copy-config to support a factory confi= g reload.

library-config: needed as a bootstrap da= tastore with the module/bundle
configuration. Like the ietf-yang-= library, but the config does not exactly match
the structure of t= he YANG library.

Can vendors add datastores to= a server?
Or is this IANA-registered?=C2=A0 And/or hard-wired in= RFCs?



Andy

--001a114a91b218b53b054b063bef-- From nobody Sun Mar 19 01:47:40 2017 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 A391F12947F for ; Sun, 19 Mar 2017 01:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkEYBZyaNjqy for ; Sun, 19 Mar 2017 01:47:37 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF6C124217 for ; Sun, 19 Mar 2017 01:47:37 -0700 (PDT) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 39A0A1AE0332; Sun, 19 Mar 2017 09:47:34 +0100 (CET) Date: Sun, 19 Mar 2017 09:47:33 +0100 (CET) Message-Id: <20170319.094733.1957440769000198080.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 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] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 08:47:38 -0000 Andy Bierman wrote: > Hi, > > I like this draft -- even more than I like datastores. > Looks like some thought went into the terminology section. > > One minor concern: > > sec. 4.1: > > On a traditional NETCONF implementation, and are > always the same. > > > The intended datastore is completely proprietary. > Is that part of the architecture or are there any plans for the standards > to have some purpose for the intended datastore? The idea was to have a defined place for the "intended configuration" in the common architecture, even if there are no current standard mechanism that affects it. If such mechanisms are added, they can be defined in terms of the datastores in this architecture. > I want to support 2 datastores that don't fit your descriptions very well: > > factory: read-only config representing the values that a factory reset > would use. Allows copy-config to support a factory config reload. > > library-config: needed as a bootstrap datastore with the module/bundle > configuration. Like the ietf-yang-library, but the config does not exactly > match > the structure of the YANG library. > > Can vendors add datastores to a server? > Or is this IANA-registered? And/or hard-wired in RFCs? The draft has a section about what is needed to define dynamic datastores. IMO this should be generalized to any datastore. The datastore names are identities, so vendors can define their own datastores. Currently there is no explicit mechanism for a server to advertise which datastores is supports, other that the advertisment of features in "ietf-datastore". Maybe we should add an explicit list of supported datastores (but this will be protocol-dependent, since some protocols might not expose all datastores). /martin From nobody Sun Mar 19 05:09:35 2017 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 19A1D126FB3 for ; Sun, 19 Mar 2017 05:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 NQsNQkq1bDKv for ; Sun, 19 Mar 2017 05:09:32 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0091.outbound.protection.outlook.com [104.47.40.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026D812025C for ; Sun, 19 Mar 2017 05:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GPsYdrAM/mr8nYWh2fj4HOD/EgQ9m5a76gVtfkrBt4o=; b=OiH8Q4PcjXzCJOU68LWjGrf4v//i3IoYQn7jYQ/eVu7xU9+pKwLLf4im+CAGpW2YXWA+QIVeRC6d3eSXMg7yTMohFamJKHG6SyVPPpO7pnsSR8EfRVG3WfCdJYeiM9DfAL7qsU0Zm2vhLAbkmj08F3feWYyg22Re4uHBXAjePUU= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Sun, 19 Mar 2017 12:09:29 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0991.010; Sun, 19 Mar 2017 12:09:29 +0000 From: Kent Watsen To: Martin Bjorklund CC: "andy@yumaworks.com" , "netmod@ietf.org" Thread-Topic: [netmod] some comments on revised-datastores-01 Thread-Index: AQHSoB0pC6yqRGsTNE2Jco/Jvjk1RKGb2quAgAA4bM8= Date: Sun, 19 Mar 2017 12:09:29 +0000 Message-ID: References: , <20170319.094733.1957440769000198080.mbj@tail-f.com> In-Reply-To: <20170319.094733.1957440769000198080.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tail-f.com; dkim=none (message not signed) header.d=none;tail-f.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [96.231.191.4] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:sBV8AdXANXja4Z4YO7kZN89I6E6MBCv8Ha/wVoBtaRObZJyxNGv4f/rggRsTvqTcUElO06Q65/0Au148l5aPDplotbY56fo5TfMFSQ3fVFs0Kl54xNOV2bLjn4/yBtLpH0aqOC4f5TNGCSQl+9CER+IrHMeh+QKHlfkbJmepN4LTzoDuhRaryC1hH50gAiFHEkfqQGTNU3eGgckoQulxe7JcFNaBSArcwUkfQXyY0/S7l2HN3hJ9xHhTzBwaaQHBfdRsi/fjYz4G1vO0euFwbMuX+4sw99adXUV0KLLB5CYst5cPPFXLDJOKUR2PftQTtyM1MhKypyFILFJ3jLuzrQ== x-ms-office365-filtering-correlation-id: d378dede-6e24-4ea2-cec3-08d46ec0cbcb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 025100C802 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39860400002)(39450400003)(39840400002)(3280700002)(2900100001)(3660700001)(2906002)(305945005)(6916009)(86362001)(7736002)(2950100002)(8936002)(8676002)(81166006)(33656002)(4326008)(77096006)(6246003)(99286003)(54906002)(38730400002)(110136004)(6116002)(102836003)(3846002)(53936002)(36756003)(66066001)(6512007)(230783001)(5660300001)(6436002)(189998001)(229853002)(6486002)(54356999)(6506006)(76176999)(50986999)(25786008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2017 12:09:29.6699 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 12:09:34 -0000 > Currently there is no explicit mechanism for a server to > advertise which datastores is supports, other that the advertisment of > features in "ietf-datastore". Maybe we should add an explicit list of > supported datastores (but this will be protocol-dependent, since some > protocols might not expose all datastores). The new dynamic datastores are (per this draft) advertised by being listed = in YANG Library. Only the "built in" datastores wouldn't have a module-ba= cking. =20 This is okay for the most part today as NETCONF has its capabilities and RE= STCONF has its unified datastore, but it does leave hanging in t= he wind. =20 Formally defining the built-in datastores as you suggest, using a module to= define their presence, would be nice from a consistency perspective.=20 K.=20 From nobody Sun Mar 19 09:37:10 2017 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 C55AC127BA3 for ; Sun, 19 Mar 2017 09:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0barWmEAJC4 for ; Sun, 19 Mar 2017 09:37:07 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 09988124C27 for ; Sun, 19 Mar 2017 09:37:06 -0700 (PDT) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id BFA721AE0332; Sun, 19 Mar 2017 17:37:02 +0100 (CET) Date: Sun, 19 Mar 2017 17:37:02 +0100 (CET) Message-Id: <20170319.173702.1332458451679178380.mbj@tail-f.com> To: kwatsen@juniper.net Cc: andy@yumaworks.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170319.094733.1957440769000198080.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 16:37:09 -0000 Kent Watsen wrote: > > > > > Currently there is no explicit mechanism for a server to > > advertise which datastores is supports, other that the advertisment of > > features in "ietf-datastore". Maybe we should add an explicit list of > > supported datastores (but this will be protocol-dependent, since some > > protocols might not expose all datastores). > > The new dynamic datastores are (per this draft) advertised by being > listed in YANG Library. Only the "built in" datastores wouldn't have > a module-backing. Actually, in the current draft, each module has a leaf-list of all datastores (not only dynamic) where the module is implemented. We have discussed various variations on this theme, but the current leaf-list is probably the simplest. > This is okay for the most part today as NETCONF has its capabilities > and RESTCONF has its unified datastore, but it does leave > hanging in the wind. > > Formally defining the built-in datastores as you suggest, using a > module to define their presence, would be nice from a consistency > perspective. /martin From nobody Sun Mar 19 11:11:40 2017 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 F267B1294A8 for ; Sun, 19 Mar 2017 11:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 e5CON3XldN8N for ; Sun, 19 Mar 2017 11:11:38 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0116.outbound.protection.outlook.com [104.47.33.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E9F128CB9 for ; Sun, 19 Mar 2017 11:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gH5S3Cs7zXlNr7trz2pcrafXbMr4Dh5imNQE9PvRzWk=; b=LBrh85HathYgrZhiIizR9AFjhFPz7WBvel9jfvSGlTjY4Hcs7p9Zvg0WC4ZDTHJRICRRdabfvmGwVsQsq+s3z4FIMo2hgOlk0Xnb91sxG1qsLsMuDVggR+rEu3sw2LiYybHd+yJMZWdLR9EM1R21QDplyhu2u5uW/oAWwk68KPI= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Sun, 19 Mar 2017 18:11:35 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0991.010; Sun, 19 Mar 2017 18:11:35 +0000 From: Kent Watsen To: Martin Bjorklund CC: "andy@yumaworks.com" , "netmod@ietf.org" Thread-Topic: [netmod] some comments on revised-datastores-01 Thread-Index: AQHSoB0pC6yqRGsTNE2Jco/Jvjk1RKGb2quAgAA4bM+AAErBAIAAGmtH Date: Sun, 19 Mar 2017 18:11:35 +0000 Message-ID: References: <20170319.094733.1957440769000198080.mbj@tail-f.com> , <20170319.173702.1332458451679178380.mbj@tail-f.com> In-Reply-To: <20170319.173702.1332458451679178380.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tail-f.com; dkim=none (message not signed) header.d=none;tail-f.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [96.231.191.4] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:UmKISI+NHmyQ5t02721zyRtOQqxGzWbF+xDeyXONWKDYW1md5qT8jGzkNAWL7wf5QmXC8ZuY60LWZfejVrkCBOK/Hy3Zai83+AzfkyESUJV45Ot5xY0z2gStBwtIOklNWkelZVfCJ0K8GLRtF00uLomYJcoZ9wCdneGBr24kJvJ64mf+h+2fnGMxRBk9LnKZxzjdEnLkhQMPHQeXQqcYKhARCySsQTcQWHVbqWzS0yPN0Zk9QLIfgr4j34UTVWDGjtjjdJbJXCjD1Tn0TqWAb/HIj67eD2Iy5TdBrUbIZipU5iz+MvRjSW6suhsnJF1eAsYVHvjKwnvvqFexVafA9g== x-ms-office365-filtering-correlation-id: 47cc861d-329e-4873-46c4-08d46ef36191 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 025100C802 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39860400002)(39450400003)(39840400002)(3280700002)(2900100001)(3660700001)(305945005)(2906002)(86362001)(7736002)(2950100002)(6916009)(8936002)(8676002)(81166006)(4326008)(33656002)(6246003)(77096006)(99286003)(54906002)(38730400002)(110136004)(6116002)(102836003)(3846002)(53936002)(36756003)(66066001)(5660300001)(230783001)(6436002)(93886004)(189998001)(229853002)(122556002)(6486002)(54356999)(6506006)(50986999)(76176999)(25786008)(6512007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2017 18:11:35.6079 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 18:11:40 -0000 >> The new dynamic datastores are (per this draft) advertised by being >> listed in YANG Library. Only the "built in" datastores wouldn't have >> a module-backing. >=20 > Actually, in the current draft, each module has a leaf-list of all > datastores (not only dynamic) where the module is implemented. >=20 > We have discussed various variations on this theme, but the current > leaf-list is probably the simplest. Wait, I think you're mixing things up. I'm not talking about using YANG Li= brary to identify which datastores a module can be accessed in, so much as = knowing which datastores are implemented in the first place. =20 For instance, assuming the "ephemeral" datastore example example in the dra= ft, a client knows a server implements it because ietf-ds-ephemeral is list= ed in YANG Library. And so it is with all dynamic datastores, but not so = for built-in (non-dynamic) datastores (e.g. intended) because there isn't a= module to advertise for them (yet). K.= From nobody Sun Mar 19 11:16:35 2017 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 8CD70128D40 for ; Sun, 19 Mar 2017 11:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 NsWjnba3h5Nx for ; Sun, 19 Mar 2017 11:16:30 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F11128CD5 for ; Sun, 19 Mar 2017 11:16:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6ACAF12CF; Sun, 19 Mar 2017 19:16:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nkkhvbPeyaVj; Sun, 19 Mar 2017 19:16:24 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 19 Mar 2017 19:16:27 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25F3920035; Sun, 19 Mar 2017 19:16:27 +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 xLp8UOe4y9oX; Sun, 19 Mar 2017 19:16:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ABE6F20033; Sun, 19 Mar 2017 19:16:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C6D473EEE58C; Sun, 19 Mar 2017 19:16:30 +0100 (CET) Date: Sun, 19 Mar 2017 19:16:30 +0100 From: Juergen Schoenwaelder To: Kent Watsen Cc: Martin Bjorklund , "netmod@ietf.org" Message-ID: <20170319181630.GA32188@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netmod@ietf.org" References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 18:16:33 -0000 On Sun, Mar 19, 2017 at 06:11:35PM +0000, Kent Watsen wrote: > > Wait, I think you're mixing things up. I'm not talking about using YANG Library to identify which datastores a module can be accessed in, so much as knowing which datastores are implemented in the first place. > > For instance, assuming the "ephemeral" datastore example example in the draft, a client knows a server implements it because ietf-ds-ephemeral is listed in YANG Library. And so it is with all dynamic datastores, but not so for built-in (non-dynamic) datastores (e.g. intended) because there isn't a module to advertise for them (yet). > Obviously, relying on module names does not work if a module defines multiple datastores. So either the set of datastores is identified from reading the whole yang-library list or we provide a separate list (and I think we should provide a separate list). /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 Sun Mar 19 12:49:12 2017 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 BE7FE126DFB for ; Sun, 19 Mar 2017 12:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 2l2dbYviyCg7 for ; Sun, 19 Mar 2017 12:49:08 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0103.outbound.protection.outlook.com [104.47.33.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E921B1293E4 for ; Sun, 19 Mar 2017 12:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YpkxdRyX/Af54/AwQapPEo0ivItcLeIjzPGvv2QVkC0=; b=KTvzuZJ2ebwVPURb+BIc0miqcjJze8wQF5TOnRs3xy25SyL9IRBNTyyy8Vm3IN27Ofwsanx98wOj8lM5iltlVgMGFepxpp3RV9m042BG7KKFgj9ObaVUVMueFsOrt/MQQKw44myNEchjgdaCzgBN1CRSpEjKnKnbnEYPzAeSHM4= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Sun, 19 Mar 2017 19:49:05 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0991.010; Sun, 19 Mar 2017 19:49:05 +0000 From: Kent Watsen To: Juergen Schoenwaelder CC: Martin Bjorklund , "netmod@ietf.org" Thread-Topic: [netmod] some comments on revised-datastores-01 Thread-Index: AQHSoB0pC6yqRGsTNE2Jco/Jvjk1RKGb2quAgAA4bM+AAErBAIAAGmtHgAABXwCAABnezA== Date: Sun, 19 Mar 2017 19:49:05 +0000 Message-ID: <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> , <20170319181630.GA32188@elstar.local> In-Reply-To: <20170319181630.GA32188@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [173.245.203.157] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:/O1HA1beiJ+0nlMvnRM+Op3hhAHWTGEVUvOdx7sLxSmgMqJBNmJnKiXvTeOH/IBSvh9g0TSD5/XiXWCwNdsMD4rnHPYwtyMfVnVmkDyHg9SddlwjoDVkdX+7fY4YeKi16zflwPyacxy+NajG9plrTXI4ZmzV+mspqQFLYM7vh+5LBnhYqJ45U+f3pD7o8/EmHsx3V7tukRtZ5B6Bays9lc68rQeB973UBAm9wy/d1dDTwnLoyibghTvq83H0wWWo3MCgJZRnrH7EQlXba97xt2KEGvKHimPct74clMQ2zwdZSrw+DMgEnFoPZYyu0xJqJavBXFgrGtjW24L9c5VrGw== x-ms-office365-filtering-correlation-id: 64c2449c-75a2-4a14-a012-08d46f010053 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 025100C802 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(39410400002)(305945005)(54906002)(99286003)(3660700001)(6246003)(86362001)(122556002)(25786008)(3280700002)(4326008)(110136004)(38730400002)(53936002)(83716003)(7736002)(2900100001)(2906002)(6512007)(82746002)(6436002)(6506006)(77096006)(6486002)(230783001)(189998001)(81166006)(93886004)(5660300001)(76176999)(54356999)(50986999)(8936002)(66066001)(36756003)(3846002)(6116002)(102836003)(33656002)(229853002)(6916009)(2950100002)(8676002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2017 19:49:05.5051 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 19:49:10 -0000 > Obviously, relying on module names does not work if a module defines > multiple datastores. So either the set of datastores is identified > from reading the whole yang-library list or we provide a separate list > (and I think we should provide a separate list). It seems okay for more than one datastore to be represented by a single mod= ule. Presumably the set of them come together as a package (all or none), = right? This could be a datastore-designer decision to make. =20 For instance, I2RS talks about priority-ordered planes of glass, so maybe t= hey have a single "ietf-ds-ephemeral" module defining a package of datastor= es like: plane-1, plane-2, ... plane-8. Yes, we could have a separate explicit list, but it'd be nice if we could r= euse what we have... K. = From nobody Sun Mar 19 23:27:25 2017 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 8EB4912968A for ; Sun, 19 Mar 2017 23:27:23 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 iFtu9HtzQbtI for ; Sun, 19 Mar 2017 23:27:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B24129683 for ; Sun, 19 Mar 2017 23:27:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4A0F3137B; Mon, 20 Mar 2017 07:27:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id H-mCJCxYspuT; Mon, 20 Mar 2017 07:27:18 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 20 Mar 2017 07:27:19 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0268120035; Mon, 20 Mar 2017 07:27:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id llFMJ73SzPXQ; Mon, 20 Mar 2017 07:27:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8AAE520033; Mon, 20 Mar 2017 07:27:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 533BE3EEED9C; Mon, 20 Mar 2017 07:27:23 +0100 (CET) Date: Mon, 20 Mar 2017 07:27:23 +0100 From: Juergen Schoenwaelder To: Kent Watsen Cc: Martin Bjorklund , "netmod@ietf.org" Message-ID: <20170320062722.GA32956@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netmod@ietf.org" References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> <20170319181630.GA32188@elstar.local> <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 06:27:23 -0000 On Sun, Mar 19, 2017 at 07:49:05PM +0000, Kent Watsen wrote: > > > Obviously, relying on module names does not work if a module defines > > multiple datastores. So either the set of datastores is identified > > from reading the whole yang-library list or we provide a separate list > > (and I think we should provide a separate list). > > It seems okay for more than one datastore to be represented by a single module. Presumably the set of them come together as a package (all or none), right? This could be a datastore-designer decision to make. > > For instance, I2RS talks about priority-ordered planes of glass, so maybe they have a single "ietf-ds-ephemeral" module defining a package of datastores like: plane-1, plane-2, ... plane-8. > > Yes, we could have a separate explicit list, but it'd be nice if we could reuse what we have... > Sorry, overloading is bad. The definition of an identity does in general not mean an implementation of an identity. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 20 01:46:58 2017 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 26D8E1296D4 for ; Mon, 20 Mar 2017 01:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 G47zdtBtfAMs for ; Mon, 20 Mar 2017 01:46:53 -0700 (PDT) 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 F08921296E0 for ; Mon, 20 Mar 2017 01:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17724; q=dns/txt; s=iport; t=1489999613; x=1491209213; h=from:to:cc:subject:date:message-id:mime-version; bh=HzTJldUZHZPlxcbqM3HJfJi1TRNyLpTKxv49gYlZIFk=; b=cqpqtmClj23BFTlUHjQrRD0SC1xMZ0X8mddi6QT88sXOB8pWkyEVqbIS XuJNHRku4NhombOxiiWIpTvBaNtuBrsEYRzvP1UaGEnoRZU/+vMGGvSTb FyuyEBuYXFl1eBQV54DSKIvzOT34kW3O795GUFkEPuFBrcy7bcnbcMozS M=; X-Files: image001.png, image002.gif : 4288, 134 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAQA3ls9Y/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jYYEKB41roW2FL4IOLoI+gzYCgw0/GAECAQEBAQEBAWsdC4U?= =?us-ascii?q?YCSAIATQCFRIBJQEBAR8JBRAGAgcMFBIBBA4EAQgGh2+CAw6wb4JsWopBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBDg+HRYZ/gR8RAVIIhScFkCaFXoNqAYE+gSABG4V?= =?us-ascii?q?oAXSLQYIEVIRUiE6BOpNXAR84Pj4IWBWHGHUBhzcNF4EKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,193,1486425600"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="400405576" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2017 08:46:51 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v2K8kpNr027309 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Mar 2017 08:46:51 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 20 Mar 2017 03:46:51 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1210.000; Mon, 20 Mar 2017 03:46:51 -0500 From: "Peter Kajsa -X (pkajsa - PANTHEON TECHNOLOGIES at Cisco)" To: "netmod@ietf.org" CC: "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" , "Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)" , "Igor Foltin -X (ifoltin - PANTHEON TECHNOLOGIES at Cisco)" , "Robert Varga (nite@hq.sk)" Thread-Topic: =?Windows-1252?Q?=93case=94_shorthand_?= Thread-Index: AdKhVh3/01AU0yljRTWqZcLXYbEIcQ== Date: Mon, 20 Mar 2017 08:46:51 +0000 Message-ID: <1d9289a1c5d74b84a9e3c2847b80f121@XCH-ALN-020.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.201.30] Content-Type: multipart/related; boundary="_005_1d9289a1c5d74b84a9e3c2847b80f121XCHALN020ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [netmod] =?windows-1252?q?=93case=94_shorthand?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 08:46:56 -0000 --_005_1d9289a1c5d74b84a9e3c2847b80f121XCHALN020ciscocom_ Content-Type: multipart/alternative; boundary="_000_1d9289a1c5d74b84a9e3c2847b80f121XCHALN020ciscocom_" --_000_1d9289a1c5d74b84a9e3c2847b80f121XCHALN020ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, RFC7950 section 7.9.2. says that if a =93case=94 statement is omitted (i.e.= =93case=94 shorthand) and implicit =93case=94 node is created, schema node= identifiers MUST always explicitly include the implicit =93case=94 node id= entifiers. So the following snippet from yang model (below) is valid for Ya= ng 1.1. However, is it also valid for Yang 1.0 ? RFC6020 is not clear about= this and there is no section saying that schema node identifiers MUST alwa= ys explicitly include the implicit =93case=94 node identifiers=85 choice my-choice { container implicit-case-container { } } augment "/my-choice/implicit-case-container" { leaf leaf-after-container { type empty; } } augment "/my-choice/implicit-case-container/implicit-case-container" { leaf leaf-inside-container { type empty; } } Thanks. [http://wwwin.cisco.com/c/dam/cec/organizations/gmcc/services-tools/signatu= retool/images/logo/logo_Cisco_Blue.png] Peter Kajsa Engineer - Software pkajsa@cisco.com Tel: Cisco Systems, Inc. Slovakia cisco.com [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before y= ou print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Please click here for Company Registration Information. --_000_1d9289a1c5d74b84a9e3c2847b80f121XCHALN020ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

 

RFC7950 section 7.9.2. says that if a =93case=94 sta= tement is omitted (i.e. =93case=94 shorthand) and implicit =93case=94 node = is created, schema node identifiers MUST always explicitly include the impl= icit =93case=94 node identifiers. So the following snippet from yang model (below) is valid for Yang 1.1. However, is it also= valid for Yang 1.0 ? RFC6020 is not clear about this and there is no secti= on saying that schema node identifiers MUST always explicitly include the i= mplicit =93case=94 node identifiers=85

 

    choice my-choice {

        container= implicit-case-container {

        }

    }

 

    augment "/my-choice/implicit= -case-container" {

        leaf leaf= -after-container {

        &nbs= p;   type empty;

        }

    }

 

    augment "/my-choice/implicit= -case-container/implicit-case-container" {

        leaf leaf= -inside-container {

        &nbs= p;   type empty;

        }

    }

 

Thanks.

3D"http://wwwin.cisco.com/c/dam/cec/organizations/gmcc/servic=

 

Peter Kajsa

Engineer - Software

pkajsa@cisco.com<= /span>

Tel:

Cisco Systems, Inc.=




Slovakia
cisco.com

 

3D"http://www.cisco.com/assets/swa/img/=Think before you print.

This email may contain confidential and = privileged material for the sole use of the intended recipient. Any review,= use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized = to receive for the recipient), please contact the sender by reply email and= delete all copies of this message.

Please click here for Company Registratio= n Information.

 

--_000_1d9289a1c5d74b84a9e3c2847b80f121XCHALN020ciscocom_-- --_005_1d9289a1c5d74b84a9e3c2847b80f121XCHALN020ciscocom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4288; creation-date="Mon, 20 Mar 2017 08:46:49 GMT"; modification-date="Mon, 20 Mar 2017 08:46:49 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAG4AAABJCAYAAADc8hN1AAAACXBIWXMAAAsTAAALEwEAmpwYAAAK T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3 AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+ 5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk 5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd 0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA 4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5 h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+ Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY /R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1 mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/ 0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5 hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9 rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7 vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO 32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21 e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i /suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8 IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq YAAAOpgAABdvkl/FRgAABetJREFUeNrsnX9olVUYxz/T/UJnM5rOyiB0M6EkRYvSsvXDKLZhUJSV hFCtBCMKpCzCrLCyIjAll0EWKYSYMbOWCW3p7OcMtfXDGaT5I0TXRltzm279cZ5L557ed/fevVfu +16eL1w4z7tznvuc873nnOc853lZzsDAAIroYZgOgRKnUOIUSpwSp1DiFEqcEqdQ4hRKnEKJU+IU SpxCiVPiFFFAbjqU5K3bny57pgFbgSLgPuCjEIzRXOBd4BRQCTSnQ2nfgklZNeOWAOcDo4AVIbHp WaAYKBX7dKn0gH0d3x0Smzqs8hklzhu9PuVM4nQIbVLnRL1KRdYSNxVoBOqAMQH0DAdqgZ3AbQFt qhQ9a4G8AHrGSL8agSsjcxxIEuuAy6X8FPDYEPXMA2qkPAsoGOLeky/HjVzRswN4L4A3XC3ld4BL s2nG5VvlkQH0lFrlHqBwiHoKgX5LLglg06hsXipt9/5UGvX0D1FPv6OrOwR9ywhx1wHjQrR/54lN eSGyqVRsCg1xW4AG4ABQFoIBKgJaxKYWkTONicBvYtOWsBBXZe1d1SEYpBlAuZTLRc40qq29vSos xHU5DkPYjjlhOK/2+oxXRokbcDb9TKM/gZxpmwbCQlxREq7+aKtcnCbXu9inD/kJZIAcx44gLv05 Pv20McJnvDJK3HGrvNunzi9W+ccA37XHKh8B/vGo83MCGWl30JL3BrDJ7o/f5eRun/HKaORkpkQz 9gJf+NS5G3gCaAdeCfBdnwELgMmY0Ndpjzp/ALPFCdgqsosz4po/LD+q+gA2vSozeDTwsk+dBuBe TPToraADnpOON1LTeAO+EbhDyi3AZSHYm3ZiQmIAmyz7AiHbbsA7fLywsODvsBiSG7KBWSoH+FHA AyGx6RHgbXHhn1HivHEEqAiZTT8A08M29fUiNaJQ4pQ4hRKnCKVzcgtwDRA7yBwVB2Aj8VGQ8Zgs 4hg+BI756LxLDtMlmDjgAYlmfMDgccrpwM3AFBmLdmAfsBk4PEi7W6UPsRuI/XLeq89G4q4F3uC/ vBMXB4AmZ1BXOX93iZuAiaT43QHW4R2JHwescX4YNkYCL3k8vwp4E5P45OeBLgS+yRbi5pL4PYA+ R+505C6PZb5RZqYfcjyejZfZOFig24vsOcC2BH2YBnwtdbdHnbhSH9KagD9lyZwCnJui3hsc0urk oHwSuFj0ehG33YO0fcCvwIXA1cBY5+8lPqTFVohZzvPPgfOAtigT97wj/wTciYlFxjCD1CPmlzjy GuBTKe8aZC+02/UAt2MC0bZed1yWOvK3wHygVeRyYAPxN+3LJOoSSa9yuLOPdMuvs8Wp9z1wKEXd 7tXQZkxi65xB2sx35HkOacjMc+2zA8ttmNuQVutZqzxrc9oMiypxY51l5xPx3NKBRmdmFWDim9sw STleuS8TrPJRknv/7iLis9fW4/3WTp/MOtsBKo0qce7N84k0679ejhFeBNXx/1Q4ewnsSPI7RqTQ h+MJ+h8Z4k4Sfz1zY5r198p+ORVYLjPNxuse9sQwieSylw8RnwBVlcB7tvfPE1ElrhP4zpLLgBeT nJ2pYA/wtOjfYT0vd/rY6Oy/m5IYl25nSb4CWOzRZgnxtwi7SEM2V6aIA3jBkZ+UfehBzNsyi4Ev 5XCbCiYCNzmufRnxyTrtxGdUrXR0zMbkozwuttTIPrzQqfecI68APpY99X4pL3fqLIv6Oa5eNu17 nMPsnAQH8ESYiXm7pgdzj1cIXODUWe8Qd0zIsXM+JgOvOe3cvJkGaVNjPauUjxdqndkdyRkHJkmm NkGdAkcuTCD3Wu0meJDWhHmdy8VaYFGKDgnAQ8DqJPq6CpOARDYQh3SmAngfk3XVJZ+/5Nf5u4eH 1ixnvGaPjf4gJuWtw9LVCXwFPIoJAvsFmFfLUrtSlsou69MsYSsvLBJPdgMmCB1rc1hmd8XZPHTb yNH/OxBN6H2cEqdQ4hRKnBKnUOIUSpwSp1DiFEqcQolT4hRKnEKJU+IUSpzi7OHfAQDopjMZobeD 3AAAAABJRU5ErkJggg== --_005_1d9289a1c5d74b84a9e3c2847b80f121XCHALN020ciscocom_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=134; creation-date="Mon, 20 Mar 2017 08:46:49 GMT"; modification-date="Mon, 20 Mar 2017 08:46:49 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhEgATAIEAAAAAAP///wCZAP///yH/C05FVFNDQVBFMi4wAwEBAAAh+QQBAAADACwAAAAA EgATAAAIRAADCBxIsKDBgwEECEB4UKFChgYfQiTocOHEhBUtTqx4ESNHiBkddpQ4MKTJkAJPqgSp MmPEliRLwny5smBLhCZZKgwIADs= --_005_1d9289a1c5d74b84a9e3c2847b80f121XCHALN020ciscocom_-- From nobody Mon Mar 20 02:10:38 2017 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 E8B5D1200F1 for ; Mon, 20 Mar 2017 02:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 5mO8RIqo3nXB for ; Mon, 20 Mar 2017 02:10:35 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5557F1296FB for ; Mon, 20 Mar 2017 02:10:34 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id DE2B01AE047A; Mon, 20 Mar 2017 10:10:32 +0100 (CET) Date: Mon, 20 Mar 2017 10:10:39 +0100 (CET) Message-Id: <20170320.101039.794440448037814282.mbj@tail-f.com> To: pkajsa@cisco.com Cc: netmod@ietf.org, ifoltin@cisco.com, mciglan@cisco.com From: Martin Bjorklund In-Reply-To: <1d9289a1c5d74b84a9e3c2847b80f121@XCH-ALN-020.cisco.com> References: <1d9289a1c5d74b84a9e3c2847b80f121@XCH-ALN-020.cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] =?utf-8?b?4oCcY2FzZeKAnSBzaG9ydGhhbmQ=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 09:10:37 -0000 IlBldGVyIEthanNhIC1YIChwa2Fqc2EgLSBQQU5USEVPTiBURUNITk9MT0dJRVMgYXQgQ2lzY28p IiA8cGthanNhQGNpc2NvLmNvbT4gd3JvdGU6DQo+IEhpLA0KPiANCj4gUkZDNzk1MCBzZWN0aW9u IDcuOS4yLiBzYXlzIHRoYXQgaWYgYSDigJxjYXNl4oCdIHN0YXRlbWVudCBpcyBvbWl0dGVkDQo+ IChpLmUuIOKAnGNhc2XigJ0gc2hvcnRoYW5kKSBhbmQgaW1wbGljaXQg4oCcY2FzZeKAnSBub2Rl IGlzIGNyZWF0ZWQsIHNjaGVtYQ0KPiBub2RlIGlkZW50aWZpZXJzIE1VU1QgYWx3YXlzIGV4cGxp Y2l0bHkgaW5jbHVkZSB0aGUgaW1wbGljaXQg4oCcY2FzZeKAnQ0KPiBub2RlIGlkZW50aWZpZXJz LiBTbyB0aGUgZm9sbG93aW5nIHNuaXBwZXQgZnJvbSB5YW5nIG1vZGVsIChiZWxvdykgaXMNCj4g dmFsaWQgZm9yIFlhbmcgMS4xLiBIb3dldmVyLCBpcyBpdCBhbHNvIHZhbGlkIGZvciBZYW5nIDEu MCA/IFJGQzYwMjANCj4gaXMgbm90IGNsZWFyIGFib3V0IHRoaXMgYW5kIHRoZXJlIGlzIG5vIHNl Y3Rpb24gc2F5aW5nIHRoYXQgc2NoZW1hDQo+IG5vZGUgaWRlbnRpZmllcnMgTVVTVCBhbHdheXMg ZXhwbGljaXRseSBpbmNsdWRlIHRoZSBpbXBsaWNpdCDigJxjYXNl4oCdDQo+IG5vZGUgaWRlbnRp ZmllcnPigKYNCg0KWWVzLCB0aGlzIHdvcmtzIHRoZSBzYW1lIHdheSBpbiBib3RoIFlBTkcgMSBh bmQgMS4xLiAgVGhlIG5ldyBzZW50ZW5jZQ0Kd2FzIGFkZGVkIGFzIGEgY2xhcmlmaWNhdGlvbiB0 byA3OTUwLg0KDQoNCg0KL21hcnRpbg0KDQoNCg0KPiANCj4gICAgIGNob2ljZSBteS1jaG9pY2Ug ew0KPiAgICAgICAgIGNvbnRhaW5lciBpbXBsaWNpdC1jYXNlLWNvbnRhaW5lciB7DQo+ICAgICAg ICAgfQ0KPiAgICAgfQ0KPiANCj4gICAgIGF1Z21lbnQgIi9teS1jaG9pY2UvaW1wbGljaXQtY2Fz ZS1jb250YWluZXIiIHsNCj4gICAgICAgICBsZWFmIGxlYWYtYWZ0ZXItY29udGFpbmVyIHsNCj4g ICAgICAgICAgICAgdHlwZSBlbXB0eTsNCj4gICAgICAgICB9DQo+ICAgICB9DQo+IA0KPiAgICAg YXVnbWVudCAiL215LWNob2ljZS9pbXBsaWNpdC1jYXNlLWNvbnRhaW5lci9pbXBsaWNpdC1jYXNl LWNvbnRhaW5lciIgew0KPiAgICAgICAgIGxlYWYgbGVhZi1pbnNpZGUtY29udGFpbmVyIHsNCj4g ICAgICAgICAgICAgdHlwZSBlbXB0eTsNCj4gICAgICAgICB9DQo+ICAgICB9DQo+IA0KPiBUaGFu a3MuDQo+IFtodHRwOi8vd3d3aW4uY2lzY28uY29tL2MvZGFtL2NlYy9vcmdhbml6YXRpb25zL2dt Y2Mvc2VydmljZXMtdG9vbHMvc2lnbmF0dXJldG9vbC9pbWFnZXMvbG9nby9sb2dvX0Npc2NvX0Js dWUucG5nXQ0KPiANCj4gDQo+IA0KPiBQZXRlciBLYWpzYQ0KPiBFbmdpbmVlciAtIFNvZnR3YXJl DQo+IHBrYWpzYUBjaXNjby5jb208bWFpbHRvOnBrYWpzYUBjaXNjby5jb20+DQo+IFRlbDoNCj4g DQo+IENpc2NvIFN5c3RlbXMsIEluYy4NCj4gDQo+IA0KPiANCj4gU2xvdmFraWENCj4gY2lzY28u Y29tDQo+IA0KPiANCj4gW2h0dHA6Ly93d3cuY2lzY28uY29tL2Fzc2V0cy9zd2EvaW1nL3RoaW5r YmVmb3JleW91cHJpbnQuZ2lmXVRoaW5rDQo+IGJlZm9yZSB5b3UgcHJpbnQuDQo+IA0KPiBUaGlz IGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBm b3IgdGhlDQo+IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcs IHVzZSwgZGlzdHJpYnV0aW9uIG9yDQo+IGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZQ0KPiBpbnRlbmRlZCByZWNpcGllbnQgKG9y IGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksDQo+IHBsZWFzZSBjb250 YWN0IHRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRo aXMNCj4gbWVzc2FnZS4NCj4gUGxlYXNlIGNsaWNrDQo+IGhlcmU8aHR0cDovL3d3dy5jaXNjby5j b20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPg0KPiBmb3Ig Q29tcGFueSBSZWdpc3RyYXRpb24gSW5mb3JtYXRpb24uDQo+IA0KPiANCg== From nobody Mon Mar 20 04:05:41 2017 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 08D99129BB8; Mon, 20 Mar 2017 04:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 T47IwWUJvlnT; Mon, 20 Mar 2017 04:05:37 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652AA129BAC; Mon, 20 Mar 2017 04:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1135; q=dns/txt; s=iport; t=1490007936; x=1491217536; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=2HV9421REjGhpp+2VvPr9iDKqYNgMjbiEKywP58zGgQ=; b=Z4/tMWTsyw36WfQL/M82F0eAEvb4d8621vgqoTNHCOjDUAzEkZS5cQfV c1dDpGh5/q31XGhjI09AoJra7+0StvLKpKYbGqC7yYKoPY43+MD2IKztZ MSoSQL0WLQrRgKK7rtlov+4R4Td0sRj0+zPMPVlqylRzhy5TbGv5wn+VU 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQCOts9Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqjlJzkGeVQ4IOKoV4AoNFGAECAQEBAQEBAWsohRYBBThRCw4?= =?us-ascii?q?KLlcGAQwIAQGJfA6zFopBAQEBAQEBAQEBAQEBAQEBAQEBGwWGToIFgmqKOQEEn?= =?us-ascii?q?E2GeYtKgXuIW4ZViFCCdogSHziBBCMWCBcVhxk/iigBAQE?= X-IronPort-AV: E=Sophos;i="5.36,193,1486425600"; d="scan'208";a="693112257" 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; 20 Mar 2017 11:05:34 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2KB5XOx030395; Mon, 20 Mar 2017 11:05:34 GMT To: Kent Watsen , Ladislav Lhotka , "t.petch" , NetMod WG Chairs , "netmod@ietf.org" References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <20170301080626.GC74969@elstar.local> <20170301094629.GA75542@elstar.local> <05eb01d2927b$a75d2da0$4001a8c0@gateway.2wire.net> <63B6599B-5295-4D88-AFA0-1A24890CF7C5@nic.cz> <94364DAA-43B4-464C-B824-B46CF1BE499C@juniper.net> <20170301204008.GB354@elstar.local> From: Benoit Claise Message-ID: <4db469a6-a468-ac07-f54c-35ba718396f8@cisco.com> Date: Mon, 20 Mar 2017 12:05:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170301204008.GB354@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 11:05:39 -0000 On 3/1/2017 9:40 PM, Juergen Schoenwaelder wrote: > On Wed, Mar 01, 2017 at 04:56:12PM +0000, Kent Watsen wrote: >> Hi Lada, >> >> I understand your intention here, but I'm inclined to agree with others >> that it's better to stick with the term we're using in the documents. >> I'm open to the idea of changing the term used in our RFCs, and I believe >> that such a change would likely have to begin with the YANG spec, from >> which it could flow into other drafts. With this in mind, I've added an >> item to the yang-next tracker: >> >> https://github.com/netmod-wg/yang-next/issues/17 >> >> and I plan to revert this change in the charter text. > Kent, > > there either is a decision and plan to change terminology everywhere > or this proposal is in my view a no go. Right now, we seem to use > consistent terminology everywhere - I do not want to loose this > property lightly. This consistency is an important feature of our documents set IMO. And adding a sentence, somewhere, sometime, is easy: "the term encoding is also known as representation or serialization" Regards, Benoit > > /js > From nobody Mon Mar 20 04:09:08 2017 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 7D4FA129BD4 for ; Mon, 20 Mar 2017 04:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 4whRRw7qrFEk for ; Mon, 20 Mar 2017 04:09:05 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A1E129BD7 for ; Mon, 20 Mar 2017 04:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5127; q=dns/txt; s=iport; t=1490008143; x=1491217743; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=7PwLnEN5afxOjKBMycF02+V+METypSxb2txWCAZjdtM=; b=VMpc5X3AGcGT3WAKx/mRbyWKDEP6YOlgTkNNyBDTPep5w+LmH2N+QheS 4HGrR6Jdn5H3wYHSN4BhGkz8C2J0FQNsKCc8YpfojczEKxvdxVXVhDpKk suWZUekdXYMj9T7f4lB0JbcqjQJKO6mSowiCpIbAcoun9ZbG3lcE15iGB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmAQBut89Y/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMngQsqYI1yc5BIH5AUhS+CDh8BCoUuSgKDRRgBAgEBAQEBAQF?= =?us-ascii?q?rKIUWAQEBAwEBbAsOAgsECgIILhsMMAYBDAYCAQGJfA6zFCuKFgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR0FhkmCBQiCYoR1JoUeBZxNkkOBe4hbhlWIUIJ2iBIfOIE?= =?us-ascii?q?EIxYIFxVBhFcdgWQ/NYlzAQEB?= X-IronPort-AV: E=Sophos;i="5.36,193,1486425600"; d="scan'208,217";a="650548552" 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; 20 Mar 2017 11:09:01 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2KB90h1031179; Mon, 20 Mar 2017 11:09:00 GMT To: Lou Berger , Juergen Schoenwaelder , Mehmet Ersue References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Cc: netmod@ietf.org From: Benoit Claise Message-ID: <34c4694e-3058-96f8-6daf-5ceacb882697@cisco.com> Date: Mon, 20 Mar 2017 12:09:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Content-Type: multipart/alternative; boundary="------------697B7E3BAE42B1C3F10646B8" Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 11:09:08 -0000 This is a multi-part message in MIME format. --------------697B7E3BAE42B1C3F10646B8 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Lou, In all my WGs, we consistently documented the intended status in the milestones, expressing the _intended _status at the time of the charter discussion Regards, Benoit > Juergen, > > Thank you for the input. I think your point highlights how the > technical contents of a document drives the intended status of a > document. > > Lou > > PS as a reminder to all, intended status of documents is *not* > typically included in charters and are not included in the distributed > version. > > > > > On March 16, 2017 2:44:53 AM Juergen Schoenwaelder > wrote: > >> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: >> >>> That said different people including Netconf WG co-chairs think the DS >>> concept document is Informational in nature and should be published >>> as an >>> Informational concept to be used in and adopted for the needs in >>> diverse >>> protocol WGs. This is as I think also important to avoid an overlapping >>> between NETCONF and NETMOD charters. >> >> The current datastore draft includes concrete YANG idenity definitions >> for datastores and origins and these definitions better be standards >> track. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > --------------697B7E3BAE42B1C3F10646B8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Lou,

In all my WGs, we consistently documented the intended status in the milestones, expressing the intended status at the time of the charter discussion

Regards, Benoit
Juergen,

Thank you for the input.  I think your point highlights how the technical  contents of a document drives the intended status of a document.

Lou

PS as a reminder to all, intended status of documents is *not* typically included in charters and are not included in the distributed version.




On March 16, 2017 2:44:53 AM Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote:

That said different people including Netconf WG co-chairs think the DS
concept document is Informational in nature and should be published as an
Informational concept to be used in and adopted for the needs in diverse
protocol WGs. This is as I think also important to avoid an overlapping
between NETCONF and NETMOD charters.

The current datastore draft includes concrete YANG idenity definitions
for datastores and origins and these definitions better be standards
track.

/js

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



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


--------------697B7E3BAE42B1C3F10646B8-- From nobody Mon Mar 20 04:14:30 2017 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 CDC8C129BF0 for ; Mon, 20 Mar 2017 04:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 GdF2c5hbI87u for ; Mon, 20 Mar 2017 04:14:27 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D19129BB7 for ; Mon, 20 Mar 2017 04:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1561; q=dns/txt; s=iport; t=1490008466; x=1491218066; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=SwIdlDxonw7aqk+v+dFqqpt1fzEteohSH4gdTKI+wGA=; b=IHorjomGwVRDuUOroCjPTFVW/BpyIHQR1MEoTtuuQ830hBzSy/mTS2AZ RtldRWvTQ9yJOkkgCnl/9TdGUvlUD4/NZDAQB5sQLpdk1EX72ZS6+VaPo cXQlIS3+yujW8PYLnd2YLXuExk0vWo8ciNFA7gEVOkH31X9bCV3trgKPJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BEAwDXuM9Y/xbLJq1dHAEBBAEBCgEBh?= =?us-ascii?q?FyEQooQc6Qbgg+CDolpGAECAQEBAQEBAWsohT8VdgImAl8NCAEBiXyge5AGgia?= =?us-ascii?q?KQQEBCAImgQuFQ4IFikSCXwWcTZJDilaGVYtGiBIfOIEEIxYIFxWHGT+KKAEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.36,193,1486425600"; d="scan'208";a="650548677" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Mar 2017 11:14:24 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2KBENkA012112 for ; Mon, 20 Mar 2017 11:14:24 GMT From: Benoit Claise To: NETMOD Working Group Message-ID: Date: Mon, 20 Mar 2017 12:14:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] NETCONF/NETMOD charters and the revised-datastores draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 11:14:29 -0000 Dear all, The NETMOD chairs, the NETCONF chairs, and I had a call regarding draft-ietf-netmod-revised-datastores & charters. First of, we must stress that this piece of work is an essential building block in the world of data model-driven management. We also believe we have the right set of people working on this. Good. So, in the end, the location (NETMOD or NETCONF) has been of lesser importance to me. I believe that we've been spending too much time debating where to develop this work, NETMOD or NETCONF. Now it's time to make a decision. While the NETMOD WG charter focuses on the YANG language developments & encodings & some generic YANG modules, while the NETCONF WG charter focuses on the protocol constructs, we've been having blurry boundaries at times. Ex: is the YANG library a generic YANG module or an element of YANG module discovery, replacing the NETCONF hello message? We now deal with a third aspect: the non-protocol specific aspects of YANG or the operating context of the YANG language. With the draft-ietf-netmod-revised-datastores in mind, data stores can be considered as views on YANG data models. After much discussion, the decisions are that the draft-ietf-netmod-revised-datastores should be worked in the NETMOD WG and that the targeted status of standard track is right (to be described in the milestone, as guideline). Unless there are new arguments, not yet brought up to the two lists, let's now devote our energy to the specifications work. Regards, Benoit (OPS AD). From nobody Mon Mar 20 05:39:14 2017 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 9FD8E129A44 for ; Mon, 20 Mar 2017 05:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t10Huhc1gNJ for ; Mon, 20 Mar 2017 05:39:09 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B54BD129A28 for ; Mon, 20 Mar 2017 05:39:08 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8639F1820044; Mon, 20 Mar 2017 13:38:27 +0100 (CET) From: Ladislav Lhotka To: Robert Wilton Cc: "netmod\@ietf.org" In-Reply-To: <77d0cd5a-2b83-1c40-c54a-a5c6212671b1@cisco.com> References: <18a2e042-919b-9468-2dc8-f751bd924125@cisco.com> <77d0cd5a-2b83-1c40-c54a-a5c6212671b1@cisco.com> Date: Mon, 20 Mar 2017 13:39:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Comments on draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 12:39:12 -0000 Robert Wilton writes: > On 17/03/2017 15:08, Ladislav Lhotka wrote: >>> On 17 Mar 2017, at 15:11, Robert Wilton wrote: >>> >>> >>> >>> On 17/03/2017 12:55, Ladislav Lhotka wrote: >>>> Hi Rob, >>>> >>>> thank you for reading the draft. >>>> >>>>> On 17 Mar 2017, at 13:30, Robert Wilton wrote: >>>>> >>>>> Hi Lada, >>>>> >>>>> I've had a quick scan of your YANG markup extension draft and I have a few comments: >>>>> >>>>> Allowing description, and similar descriptive statements, to use something other than text seems like it could be useful in some cases. >>>>> >>>>> I'm not sure that allowing the statements to use any text-like >>>>> media type is a good idea, this could increase the burden on tool >>>>> makers if each module author chooses their own preferred format. >>>>> >>>>> Instead, I think that it might be better to restrict it to a very small set of media types, that could be extended in future. I would think that initially just allowing plain text and one particular flavour of markdown would be a reasonable starting point. >>>> I agree although I am not sure that we can easily find an agreement on the particular flavour. So maybe we can leave it open and let the "market" decide. >>> I think that would be a mistake. How would device/tools vendors know which versions to spend time implementing? >> I would agree to have a fixed choice in 6087bis, but there may be niche communities or special cases that need something else, so YANG IMO shouldn't preclude it a priori. > I think that this idea works quite well as a YANG extension, and that > would be a better path than baking it into YANG at this time. > > I'm still not convinced that allowing an arbitrary encoding is a good idea. > The burden on tool makers wouldn't be much less if authors use only lightweight markups - for example, markdown and reStructuredText would still need two parsers. >> >>>>> I think that the only formats that should be allowed are those that are still readily readable as plain text, so that tools that don't want to parse the formatted text can still sensibly display the descriptive statements. I.e. I don't think that it would be helpful to allow things like text/xml since it isn't easy to read. >>>> Sure, and the draft says: >>>> >>>> It is RECOMMENDED to use only media types representing "lightweight" >>>> markup that is easy to read even in the unprocessed source form, such >>>> as "text/markdown". >>> I was proposing REQUIRED instead of RECOMMENDED. >> I usually write my modules in the YIN format with a very restricted set of HTML tags that are used in the text arguments: >> >> https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang#yin-schema-extensions > OK. I had assumed that nobody was using YIN ;-) I do, because the nxml mode of Emacs is so great. >> >> It would be useful to indicate "text/html" media type, and a YIN->YANG convertor could translate it e.g. to "text/markdown". > Isn't that just part of the YIN conversion to YANG. I.e. by the time the > file is YANG it would be text/markdown. That's how I do it now, but I assume modules in YIN syntax could possibly exist on their own. For example, if they are intended for HTML rendering, or including in formats like xml2rfc, then YIN could make sense. A YIN -> YANG conversion tool would change "text/html" e.g. to "text/markdown". Of course, it can be argued that one could use markdown right away in YIN descriptions but it it often handier to have everything in XML - validators (such as Emacs) or XSL processors can then also effectively work with contents of descriptions. > >> >>>>> Allowing this extension on particular descriptive statements may also be helpful. It seems plausible that the vast majority of these statements in a module might just be written in plain text with just a few of them using more advanced formatting like markdown. >>>> Yes, I was thinking about this. On the other hand, plain text is typically compatible with any markup format, so this would probably be useful only if somebody wanted to use multiple different markup formats in the same module, which sounds crazy. But we can discuss it. >>> I was only thinking of a mix of some plain text descriptions and some using markup. >>> >>> Tooling may choose to format raw text differently from markup text (e.g. converting lines into a paragraph). Also a markup processor would be extra work, and may not warn or error on the structure of a plain text description that doesn't conform to the markup rules. >> Actually, the design philosophy behind markdown is that there is no formal concept of validity and so processors should never complain. > But how does an implementation know what it needs to support so that it > works with all descriptions? I think that there would need to be a > based specification to be useful. >> >> On the other hand, it is conceivable that some descriptions may use a more specialized format. For example, we could use a media type (variant) for the top-level "contact" statements that we include in modules, and tools could then more easily extract this metadata. > I'm not sure ... this is just sounding like extra work/complexity, and > YANG is already pretty complex! In any case, tools can always leave the text as it is. I will include this possibility in open issues. Lada > > Thanks, > Rob > > >> >> So maybe we could really permit the "text-media-type" extension anywhere and apply some natural scoping rules. >> >> Lada >> >>>>> Finally, I have a concern that if more structured formatting in the comments is used then would that encourage model writers to produce more verbose comments, and if so that might possibly reduce the readability of the modules. Although, I guess ultimately one has to trust the model writers to do the right thing. >>>> Well, this draft doesn't permit anything above what module writers can do already now - the descriptions etc. have to be valid YANG strings as before. The only new thing is a piece of metadata that may be helpful for some tools but that can also be safely ignored. >>> Thanks, >>> Rob >>> >>>> Thanks, Lada >>>> >>>>> Thanks, >>>>> Rob >>>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>> >>>> >>>> >>>> >>>> >>>> . >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> >> >> >> >> . >> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Mar 20 05:49:11 2017 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 53998131468 for ; Mon, 20 Mar 2017 05:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIOgsjXxhccj for ; Mon, 20 Mar 2017 05:49:08 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 410F9131465 for ; Mon, 20 Mar 2017 05:49:06 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 276821820044; Mon, 20 Mar 2017 13:48:27 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , Robert Wilton Cc: "netmod\@ietf.org" In-Reply-To: References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> Date: Mon, 20 Mar 2017 13:49:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 12:49:10 -0000 Kent Watsen writes: > Hi Lada, > > I think some of what you're getting at is in these guidelines: > > https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-01#section-5 > > But you're thinking about something more generalized? Most likely yes - what I have in mind is something like datastore modelling mini-language. To some extent, NETCONF already does this via capabilities: server implementors can choose and advertize different variants of running-candidate-startup organization. Lada > > Kent // contributor > > > -----ORIGINAL MESSAGE----- > >> On 17 Mar 2017, at 15:46, Robert Wilton wrote: >> >> >> >> On 17/03/2017 14:32, Ladislav Lhotka wrote: >>>> On 17 Mar 2017, at 15:04, Robert Wilton wrote: >>>> >>>> Hi, >>>> >>>> Would 7950bis be allowed to have a normative reference to an Informational RFC that defined the YANG datastores? >>> My idea is that 7950bis should be made independent of any particular set of datastores, so such a normative reference shouldn't be needed. >> OK, if 70590bis was entirely datastore agnostic, then there would need to be a description of how YANG applies to a particular set of datastores (in particular the config: true|false statement), and which datastores are validated. Would that go in the revised > > I don't think that config true/false is necessarily tied to a particular set of datastores, it can be generalized to RW/RO. > >> datastores architecture or somewhere else? It wouldn't make sense to have to repeat this for every network configuration protocol. > > I think the structure of datastores and validation workflow could be supplied as extra info, see item #3 near the end of this message: > > https://www.ietf.org/mail-archive/web/netmod/current/msg17673.html > > Lada > >> >> Thanks, >> Rob >> >> >>> >>> Lada >>> >>>> If we did a 7950bis document (and it isn't clear that one is actually required to support the revised datastores draft) then does that mean we would also need to have a new version of YANG? >>>> >>>> That would potentially seem like a backwards step. Also what would it mean for an implementation that is aware of the new datastores but is using a mix of YANG modules with different versions? >>>> >>>> I don't understand why the revised datastores draft should not be standards track once the various appendices have been moved out, noting that they are really only in the one draft at this stage because it seemed like that would make it easier for folks to review and comment on. >>>> >>>> Is the only issue here which WG the draft is being worked on? >>>> >>>> Thanks, >>>> Rob >>>> >>>> >>>> On 17/03/2017 13:22, Mehmet Ersue wrote: >>>>> I think YANG identities should be standardized with 7950bis. >>>>> >>>>> Mehmet >>>>> >>>>>> -----Original Message----- >>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>> Sent: Thursday, March 16, 2017 12:28 PM >>>>>> To: Juergen Schoenwaelder ; >>>>>> Mehmet Ersue >>>>>> Cc: 'Kent Watsen' ; netmod@ietf.org >>>>>> Subject: Re: [netmod] draft netmod charter update proposal >>>>>> >>>>>> Juergen, >>>>>> >>>>>> Thank you for the input. I think your point highlights how the technical >>>>>> contents of a document drives the intended status of a document. >>>>>> >>>>>> Lou >>>>>> >>>>>> PS as a reminder to all, intended status of documents is *not* typically >>>>>> included in charters and are not included in the distributed version. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder >>>>>> wrote: >>>>>> >>>>>>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: >>>>>>> >>>>>>>> That said different people including Netconf WG co-chairs think the DS >>>>>>>> concept document is Informational in nature and should be published as >>>>>> an >>>>>>>> Informational concept to be used in and adopted for the needs in >>>>> diverse >>>>>>>> protocol WGs. This is as I think also important to avoid an overlapping >>>>>>>> between NETCONF and NETMOD charters. >>>>>>> The current datastore draft includes concrete YANG idenity definitions >>>>>>> for datastores and origins and these definitions better be standards >>>>>>> track. >>>>>>> >>>>>>> /js >>>>>>> >>>>>>> -- >>>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>>>> Fax: +49 421 200 3103 >>>>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> . >>>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>> >>> >>> >>> >>> >>> . > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Mar 20 05:58:23 2017 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 5D55D131466 for ; Mon, 20 Mar 2017 05:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6I-JJ1K6Qrsp for ; Mon, 20 Mar 2017 05:58:19 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C8086131465 for ; Mon, 20 Mar 2017 05:58:18 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8C3131820044; Mon, 20 Mar 2017 13:57:39 +0100 (CET) From: Ladislav Lhotka To: "t.petch" Cc: netmod@ietf.org In-Reply-To: <01b901d29f3f$91b85b20$4001a8c0@gateway.2wire.net> References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <01b901d29f3f$91b85b20$4001a8c0@gateway.2wire.net> Date: Mon, 20 Mar 2017 13:58:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 12:58:21 -0000 "t.petch" writes: > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "Robert Wilton" > Cc: > Sent: Friday, March 17, 2017 2:32 PM >> >> > On 17 Mar 2017, at 15:04, Robert Wilton wrote: >> > >> > Would 7950bis be allowed to have a normative reference to an > Informational RFC that defined the YANG datastores? >> >> My idea is that 7950bis should be made independent of any particular > set of datastores, so such a normative reference shouldn't be needed. > > Lada > > You say 'set of datastores' which I would agree with but I would propose > that the concept of a datastore, which could be a different term, just > semantically equivalent to that of 'datastore', is still needed for > validation. The scope of validation is a closed set of data and the > current term for that is datastore (as opposed to module, model or any > other unit of data).. Agreed, but I would suggest "data tree" as the subject of validation. Something more general than datastore is probably needed because already in RFC 7950 the tree that is validated sometimes consists of multiple (two) datastores and/or payloads of operations or notifications. Lada > > Tom Petch > > > > > > >> >> Lada >> >> > >> > If we did a 7950bis document (and it isn't clear that one is > actually required to support the revised datastores draft) then does > that mean we would also need to have a new version of YANG? >> > >> > That would potentially seem like a backwards step. Also what would > it mean for an implementation that is aware of the new datastores but is > using a mix of YANG modules with different versions? >> > >> > I don't understand why the revised datastores draft should not be > standards track once the various appendices have been moved out, noting > that they are really only in the one draft at this stage because it > seemed like that would make it easier for folks to review and comment > on. >> > >> > Is the only issue here which WG the draft is being worked on? >> > >> > Thanks, >> > Rob >> > >> > >> > On 17/03/2017 13:22, Mehmet Ersue wrote: >> >> I think YANG identities should be standardized with 7950bis. >> >> >> >> Mehmet >> >> >> >>> -----Original Message----- >> >>> From: Lou Berger [mailto:lberger@labn.net] >> >>> Sent: Thursday, March 16, 2017 12:28 PM >> >>> To: Juergen Schoenwaelder ; >> >>> Mehmet Ersue >> >>> Cc: 'Kent Watsen' ; netmod@ietf.org >> >>> Subject: Re: [netmod] draft netmod charter update proposal >> >>> >> >>> Juergen, >> >>> >> >>> Thank you for the input. I think your point highlights how the > technical >> >>> contents of a document drives the intended status of a document. >> >>> >> >>> Lou >> >>> >> >>> PS as a reminder to all, intended status of documents is *not* > typically >> >>> included in charters and are not included in the distributed > version. >> >>> >> >>> >> >>> >> >>> >> >>> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder >> >>> wrote: >> >>> >> >>>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: >> >>>> >> >>>>> That said different people including Netconf WG co-chairs think > the DS >> >>>>> concept document is Informational in nature and should be > published as >> >>> an >> >>>>> Informational concept to be used in and adopted for the needs in >> >> diverse >> >>>>> protocol WGs. This is as I think also important to avoid an > overlapping >> >>>>> between NETCONF and NETMOD charters. >> >>>> The current datastore draft includes concrete YANG idenity > definitions >> >>>> for datastores and origins and these definitions better be > standards >> >>>> track. >> >>>> >> >>>> /js >> >>>> >> >>>> -- >> >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany >> >>>> Fax: +49 421 200 3103 > >> >>>> >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod >> >> . >> >> >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Mar 20 06:55:16 2017 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 37CDE127011 for ; Mon, 20 Mar 2017 06:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 J0-rHhOi-Ti3 for ; Mon, 20 Mar 2017 06:55:10 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD05F12785F for ; Mon, 20 Mar 2017 06:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15107; q=dns/txt; s=iport; t=1490018109; x=1491227709; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=9AMswnjeKx+F24Rkt92BxePuSMiWOFX40feW1RhCHzM=; b=CXgN7IUnmqFtuEcdN6GLispqo2cPmAZs5vsZ4OVgGGd9ftyeiNzIzjxU TVGAn1djcRFnAaMwWsx+PaeEcJ0sY4je0IeDz6SfXShoNklUdXWgaGIKu 6JA/CT1Jqoy8GZiIw2j29GWHNpDIqNyfLfuz5E2PEdAxZVL17BIJ4eM+O w=; X-IronPort-AV: E=Sophos;i="5.36,194,1486425600"; d="scan'208";a="693116380" 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; 20 Mar 2017 13:55:08 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2KDt7wJ012894; Mon, 20 Mar 2017 13:55:08 GMT To: "Acee Lindem (acee)" , Ladislav Lhotka , "netmod@ietf.org" References: <33d0132e-750b-97ed-8bdb-0befeb1b81c3@cisco.com> <0400d1cb-30ce-e074-b707-202026161ebb@cisco.com> <12f97503-9801-56f5-650f-8accdab68e4c@cisco.com> From: Robert Wilton Message-ID: Date: Mon, 20 Mar 2017 13:55:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 13:55:14 -0000 Hi Acee, On 17/03/2017 17:18, Acee Lindem (acee) wrote: > Hi Rob, > > On 3/10/17, 9:46 AM, "netmod on behalf of Robert Wilton -X (rwilton - > ENSOFT LIMITED at Cisco)" rwilton@cisco.com> wrote: > >> Lada, >> >> Thanks for the comments, some further comments inline ... >> >> >> On 10/03/2017 14:09, Ladislav Lhotka wrote: >>> Hi Rob, >>> >>> please see inline. >>> >>> Robert Wilton writes: >>> >>>> Hi Lada, >>>> >>>> To pick up an old thread, I'm updating the interface model per your >>>> comments below, and I had a few questions that you might have an >>>> opinion on. >>>> >>>> On 22/12/2016 14:32, Robert Wilton wrote: >>>>> Hi Lada, >>>>> >>>>> Thanks for the review and comments. >>>>> >>>>> >>>>> On 21/12/2016 13:08, Ladislav Lhotka wrote: >>>>>> Hi, >>>>>> >>>>>> I think this is a very useful addition to ietf-interfaces. In >>>>>> general, >>>>>> the document is clearly written and YANG modules nicely designed. >>>>>> Here >>>>>> are my comments: >>>>>> >>>>>> *** Sec. 1 >>>>>> - "This document defines two YANG RFC 7950 [RFC7950] modules Š" >>>>>> looks weird. I'd suggest "Š YANG 1.1 [RFC7950] Š" instead. >>>>> OK. >>>> Fixed. >>>>>> *** Sec. 2 >>>>>> - first line: s/of of/of/ >>>> Fixed. >>>> >>>>>> *** Sec. 3.1 >>>>>> - If the "bandwidth" parameter is only used for tuning routing >>>>>> algorithms and has nothing to do with real bandwidth on the >>>>>> interface, I would suggest to use a different name >>>>>> (metric?). Perhaps it may indeed be better to leave this to >>>>>> routing protocol modules because they can also specify how >>>>>> exactly such a parameter is used. >>>>> Yes, possibility it would be better to define this as part of the >>>>> routing models. The idea here is that the bandwidth would span across >>>>> the routing protocols rather than be tied to a specific protocol. >>>> I think that we need a better name than just "bandwidth" since this >>>> leaf >>>> doesn't affect the actual bandwidth on the of the link, just the >>>> bandwidth that is reported to routing protocols to implicitly adjust >>>> their link metrics. Hence, I was considering renaming this to >>>> "reported-bandwidth"? >>> This looks like something for routing people to decide. > I believe this is referred to as maximum-reservable-bandwidth in RFC 3630. > > > 2.5.7. Maximum Reservable Bandwidth > > The Maximum Reservable Bandwidth sub-TLV specifies the maximum > bandwidth that may be reserved on this link, in this direction, in > IEEE floating point format. Note that this may be greater than the > maximum bandwidth (in which case the link may be oversubscribed). > This SHOULD be user-configurable; the default value should be the > Maximum Bandwidth. The units are bytes per second. > > Perhaps, reservable-bandwidth would suffice. I like that suggestion. I'll raise this on the rtgwg alias as well. > > > >>>> I also think that it would be good to follow up with the routing folks >>>> to see if this leaf would be better covered in a general routing model. >>>> Where do you think is the best place that I raise this, the routing >>>> area >>>> yang design team? >>> Maybe, or RTGWG? >> OK. I'll send an email that way, after I've published this next revision. >> >>>>>> *** Sec. 3.6 >>>>>> - The "l3-mtu" parameter is probably the same as "mtu" defined >>>>>> in >>>>>> ietf-ip. Again, I would suggest to leave the definition of >>>>>> MTU >>>>>> to each L3 protocol because there may be specific aspects and >>>>>> constraints. >>>>> The MTU being defined here is an "l2-mtu" parameter. I.e. the maximum >>>>> size of the L2 frames that can be sent/received. For some devices >>>>> this value is independent of a protocol specific L3 MTU that only >>>>> affects that particular protocol instance. >>>> I've updated the text to make it clear that it is only a L2 MTU >>>> configuration leaf, and if not configured, the system will >>>> automatically >>>> decide on the L2 MTU. >>> Shouldn't it have a "when" substatement to make it available only for >>> "layer-2" interfaces? >> It can apply to all interfaces that use a layer 2 encapsulation, i.e. >> most interfaces. > It seems that an L3 interface could still have an L2 MTU? Of course, the > IP or IPv6 MTU could not exceed the L2 MTU. Yes, an L3 interface still has a L2 MTU, and on some systems this configuration item can be used to indirectly control the IP/IPv6 protocol MTUs on the interface, or the MTUs of any sub-interfaces. Some network OSes control their MTU from an L2 perspective, i.e. you normally configure the L2 MTU, and the system works out what L2 payload size is available to the L3 protocols. Other network OSes control them MTU from an L3 perspective, i.e. you configure the L3 MTU, and the system calculates the L2 overhead, possibly with some extra slop space, to program into the Ethernet MAC chip to police the maximum size of frame that can be sent or received. Perhaps it would be beneficial to add some text to explain the relationships between the MTUs values for L2 and the protocols to the draft? Actually, it may be beneficial to cover the MTU relationship to sub-interfaces as well. > > > > >> The only interfaces that it wouldn't apply to are: >> - interfaces that are performing optical switching - but then I think >> that they are probably not really interfaces at all. >> - software interfaces that represent a tunnel endpoint that carriers >> L3 frames with no L2 encapsulation. Although in this case you could >> just regard them as having a 0 byte layer 2 overhead. >> >> >> >>>>>> *** Sec. 3.8 >>>>>> - I think that "transport-layer" is not a good name because in >>>>>> the >>>>>> ISO OSI model it denotes a particular layer (L4). How about >>>>>> "iso-osi-layer"? >>>> I agree that "transport-layer" is somewhat ambiguous. >>>> >>>> I was wondering whether "service-layer" or "service-type" would work? >>> This looks more like a business term, "iso-osi-layer" or just >>> "osi-layer" seems better to me, even if you include only layers >>> 1-3. Actually, the OSI model calls these three "media layers", but this >>> term isn't commonly used. >> The problem with osi-layer is that I don't think that the name really >> indicates what it means. > If we have trouble deciding on the semantics, perhaps the data node isn¹t > useful. Possibly, that may be the conclusion. In which case I think that this would end up being a vendor augmentation leaf that ends up being defined in similar ways for different vendors, reducing commonality of configuration. Some of our implementations, that I believe applies to other vendors as well, need to know what mode an interface or sub-interface is running in to optimize the forwarding resources. E.g. perhaps different microcode, or hardware path data structures. The other perceived benefit of this leaf is as a way of trying to ensure that features and the forwarding mode are consistently configured. E.g. the hardware may not be able to handle an L2 ACL applied to an interface/sub-interface that is forwarding at L3. This forwarding layer leaf would potentially offer a common way to police this via a MUST statement in the ACL module. The MUST statement could say, if this is an L2 ACL and the forwarding mode leaf exists then it must be in L2 mode. Thanks, Rob > > > Thanks, > Acee > > > >>>> Or perhaps it could be called "forwarding-mode"? >>> IMO, the layers are not only about forwarding. >> Agreed, but this configuration is to provide a constraint as to what >> services and forwarding paradigm can be enabled. >> >> E.g. an "l2 transport/service" would be connected to an L2VPN instance >> but not IP. >> An ACL applied to a "L2 transport/service" would filter on MAC >> addresses/VLAN Ids rather than IP header fields. >> >>>>>> - The type of "transport-layer" has three enums, namely >>>>>> "layer-[123]". I would suggest to use descriptive names >>>>>> ("physical-layer" etc.), include the remaining layers of the >>>>>> ISO >>>>>> OSI model, and maybe also define it as a typedef - or does >>>>>> this >>>>>> belong to ietf-inet-types? >>>> I'm not sure that defining the higher layers of the OSI model helps. >>>> Perhaps using identities would be a better choice? >>>> >>>> Perhaps: >>>> "physical-layer" >>>> "data-link-layer" >>>> "network-layer" >>>> >>>> But I prefer "layer-2" over "data-link-layer" since I think that term >>>> is much more widespread. I'm also not quite sure whether >>> OK. >>> >>>> "physical-layer" is actually the right term, I think that is probably >>>> really "below-layer-2" >>>> >>> In terms of the OSI model, there is only layer 1 (physical) below layer >>> 2. Or do you mean things like Ethernet-over-MPLS? I don't know how the >>> layer classification works in such convoluted cases. >> For layer-2, I think of carrying L2 frames over another service (e.g. >> IP, MPLS, or MAC-in-MAC). >> For layer-1, I was thinking of things like optical switching or OTN >> switching. But again it does come back to whether those are represented >> as interfaces. Although, even in the optical switching cases, I think >> that devices sometimes snoop the layer 2 frame statistics. >> >>>>>> - Is a leaf sufficient? I think some interfaces can be in >>>>>> multiple >>>>>> layers at the same time (e.g. an ATM interface is L3 but can >>>>>> also be L2 for Classical IP over ATM). Or is the idea that >>>>>> such >>>>>> an interface will be split into two entries of the >>>>>> "interface" >>>>>> list? >>>>> This needs some further thought/work. >>>> I think that using sub-interfaces is the cleanest way of doing this, so >>>> each sub-interface can be offering a service at a different layer. >>>> >>>> >>>>> The main idea here was to be able to label sub-interfaces as >>>>> supporting only L2 services or L3 services, since on some platforms >>>>> different types of interfaces get instantiated internally. >>> OK, I don't dare to give any suggestions here. >>> >>>>>> *** YANG modules >>>>>> - Descriptions are not consistently formatted. I think that the >>>>>> current BCP is to start description text on the same line as >>>>>> the >>>>>> "description" keyword only if it all fits on one line. >>>>>> - I don't have a strong opinion on this but it might increase >>>>>> readability if the number of augments is reduced. Perhaps at >>>>>> least augments that contain only one node could be made into >>>>>> one >>>>>> (and the "feature" and "when" statements moved to the nodes' >>>>>> definitions. >>>>> Yes, I'll fix these, probably using Martin's suggested approach. >>>> I've fixed the descriptions, and merged all the augments except for the >>>> sub-interface one (which is an if-feature conditional augment of a >>>> mandatory node). >>> Good. >>> >>>> I also have a question about the "encapsulation" container that is >>>> currently defined as: >>>> >>>> /* >>>> * Various types of interfaces support a configurable layer 2 >>>> * encapsulation, any that are supported by YANG should be >>>> * listed here. >>>> * >>>> * Different encapsulations can hook into the common encaps-type >>>> * choice statement. >>>> */ >>>> container encapsulation { >>>> when >>>> "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or >>>> derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or >>>> derived-from-or-self(if:type, 'ianaift:pos') or >>>> derived-from-or-self(if:type, 'ianaift:atmSubInterface') or >>>> derived-from-or-self(if:type, 'ethSubInterface')" { >>>> >>>> description >>>> "All interface types that can have a configurable L2 >>>> encapsulation"; >>>> /* >>>> * TODO - Should we introduce an abstract type to make this >>>> * extensible to new interface types, or vendor >>>> * specific interface types? >>>> */ >>>> } >>>> >>>> description >>>> "Holds the OSI layer 2 encapsulation associated with an >>>> interface"; >>>> choice encaps-type { >>>> description "Extensible choice of L2 encapsulations"; >>>> } >>>> } >>>> >>>> I was considering removing the when statement to generalize this, since >>>> the case statements can be constricted to suitable interface types >>>> using >>>> when statements anyway. E.g. I'm proposing to changing it to something >>>> like this: >>>> >>>> /* >>>> * Various types of interfaces support a configurable >>>> * encapsulation. >>>> * >>>> * Different encapsulations (often layer 2) can hook into the >>>> * common encaps-type choice statement. >>>> */ >>>> container encapsulation { >>>> description >>>> "Holds the encapsulation (often layer 2) associated with an >>>> interface"; >>>> choice encaps-type { >>>> description >>>> "Extensible choice of encapsulations"; >>>> } >>>> } >>>> >>>> Do you have a view on this? >>> This demonstrates that the IANA interface types are not very useful for >>> restricting the data model. As you indicate, multiple levels of the >>> interface hierarchy (abstract interface types) might be better, perhaps >>> you could also make use of multiple inheritance of identities, hence >>> allowing for arbitrary mixes of interface properties encoded in the >>> type. >> Yes, I think that the IANA interface types are a problem. >> >> Previously I was planning on writing up a draft with abstract types >> deriving from the IANA types, but I'm not sure whether this helps in the >> general case. >> >> It might be that we need to define a set of abstract types (e.g. >> physical interfaces, ethernet-like, sub-interface, logical interface, >> etc) and then update the type identities in iana-if-type.yang to derive > >from those base types (which I believe would be an allowed backwards >> compatible change). >> >> Thanks, >> Rob >> >> >>> Cheers, Lada >>> >>>> Thanks, >>>> Rob >>>> >>>> >>>>> Thanks again, >>>>> Rob >>>>> >>>>>> Lada >>>>>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Mar 20 07:05:34 2017 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 A117B127286 for ; Mon, 20 Mar 2017 07:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 rQKZwCZT0bl4 for ; Mon, 20 Mar 2017 07:05:12 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0122.outbound.protection.outlook.com [104.47.40.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1D9131492 for ; Mon, 20 Mar 2017 07:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0ay4hbSJtWOxU6CnLQ7UOKBrNt5P2ZALpg8Q2cUgApk=; b=HnU0IiKraY2+oUmuHOBgGVvD8gFpmIbLfXkuKswZmDT/BM1eCm/CYiy7xk4EsMzqOT2i31cjZWJ4Up/03lhVTCPnHNL6O8gx5MPLbR66iO+xpSTLF3ZaJF5TeKtjeRovimR5MrekOHwI9HoOZYXwK96JXuBSYz+79vQcJd/9ZS4= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Mon, 20 Mar 2017 14:05:09 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0991.011; Mon, 20 Mar 2017 14:05:09 +0000 From: Kent Watsen To: Juergen Schoenwaelder CC: Martin Bjorklund , "netmod@ietf.org" Thread-Topic: [netmod] some comments on revised-datastores-01 Thread-Index: AQHSoB0pC6yqRGsTNE2Jco/Jvjk1RKGb2quAgAA4bM+AAErBAIAAGmtHgAABXwCAABnezIAAsleAgAA81wA= Date: Mon, 20 Mar 2017 14:05:09 +0000 Message-ID: <79DEF6A3-F1AE-45C9-A88F-14796FEF884C@juniper.net> References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> <20170319181630.GA32188@elstar.local> <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> <20170320062722.GA32956@elstar.local> In-Reply-To: <20170320062722.GA32956@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:Cb6GOlhaeZBvk6/ZtFUXohAG528exmUlzkLORSGaEJmQy8DCQx2q42bGKehQXloJ6VMIfE2VclfZ7F57DC8I3OhBECsbZ0D9az3ULTM5mbe1+rf4xWyam6AWUBqbM9E8LkC5avjizrrDU9g/10WmpaFOBAp6oYCBGDOMnt3m9ZvtfE3qQGcdtBbwK/B+GSFEj7nsrYAYjk50tEXECEHGXEJWCdIy+GJoIMzJ1zYOCRWf47tDBn+G4oGzDlRQF7B8gw1AjUE88cT5LYOg6TNwQgrZIK6TvyuAh9UCxxeLCFUBzQtHD/TY/GAI7fJY1+hl09uSVYMSL4YYTLFeCwMhHA== x-ms-office365-filtering-correlation-id: 51f82941-4ee3-40d3-03dd-08d46f9a1e93 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39860400002)(50986999)(54356999)(76176999)(81166006)(93886004)(5660300001)(189998001)(6506006)(4001350100001)(8676002)(6486002)(230783001)(77096006)(229853002)(33656002)(6916009)(2950100002)(8936002)(66066001)(36756003)(102836003)(6116002)(3846002)(122556002)(3280700002)(25786008)(110136004)(38730400002)(4326008)(3660700001)(99286003)(305945005)(54906002)(86362001)(2906002)(6512007)(2900100001)(6436002)(53936002)(83506001)(7736002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4A156865214D2741B2C18A1B4B7A7493@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 14:05:09.3169 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 14:05:20 -0000 DQogDQo+PiBJdCBzZWVtcyBva2F5IGZvciBtb3JlIHRoYW4gb25lIGRhdGFzdG9yZSB0byBiZSBy ZXByZXNlbnRlZCBieSBhIHNpbmdsZQ0KPj4gbW9kdWxlLiAgUHJlc3VtYWJseSB0aGUgc2V0IG9m IHRoZW0gY29tZSB0b2dldGhlciBhcyBhIHBhY2thZ2UgKGFsbCBvcg0KPj4gbm9uZSksIHJpZ2h0 PyAgVGhpcyBjb3VsZCBiZSBhIGRhdGFzdG9yZS1kZXNpZ25lciBkZWNpc2lvbiB0byBtYWtlLg0K Pj4NCj4+IEZvciBpbnN0YW5jZSwgSTJSUyB0YWxrcyBhYm91dCBwcmlvcml0eS1vcmRlcmVkIHBs YW5lcyBvZiBnbGFzcywgc28gbWF5YmUNCj4+IHRoZXkgaGF2ZSBhIHNpbmdsZSAiaWV0Zi1kcy1l cGhlbWVyYWwiIG1vZHVsZSBkZWZpbmluZyBhIHBhY2thZ2Ugb2YgDQo+PiBkYXRhc3RvcmVzIGxp a2U6IHBsYW5lLTEsIHBsYW5lLTIsIC4uLiBwbGFuZS04Lg0KPj4gDQo+PiBZZXMsIHdlIGNvdWxk IGhhdmUgYSBzZXBhcmF0ZSBleHBsaWNpdCBsaXN0LCBidXQgaXQnZCBiZSBuaWNlIGlmIHdlIA0K Pj4gY291bGQgcmV1c2Ugd2hhdCB3ZSBoYXZlLi4uDQo+DQo+DQo+IFNvcnJ5LCBvdmVybG9hZGlu ZyBpcyBiYWQuIFRoZSBkZWZpbml0aW9uIG9mIGFuIGlkZW50aXR5IGRvZXMgaW4NCj4gZ2VuZXJh bCBub3QgbWVhbiBhbiBpbXBsZW1lbnRhdGlvbiBvZiBhbiBpZGVudGl0eS4NCg0KV2h5IGFyZSB5 b3UgbWVudGlvbmluZyBpZGVudGl0aWVzIGhlcmU/ICBZZXMsIHRoZSBtb2R1bGUgZGVmaW5lcyAN CmlkZW50aXRpZXMsIGJ1dCB0aGF0IGlzIGJlc2lkZSB0aGUgcG9pbnQgdG8gd2hhdCBJJ20gc2F5 aW5nLiAgSSdtDQpvbmx5IGRpc2N1c3NpbmcgdGhlIG1vZHVsZSAoZS5nLiBpZXRmLWkycnMtc29s dXRpb24pIHNob3dpbmcgdXANCmluIFlBTkcgTGlicmFyeSBhbmQgdXNpbmcgdGhlIGFnZS1vbGQg bG9naWMgb2YsIGlmIHRoZSBzZXJ2ZXINCmFkdmVydGlzZXMgaXQsIHRoZW4gaXQgbWVhbnMgdGhh dCBpdCBzdXBwb3J0cyBpdCwgd2hpY2ggaW4gdGhpcw0KY2FzZSBtZWFucyB0aGF0IGl0IHN1cHBv cnRzIGFsbCB0aGUgZGF0YXN0b3JlcyBkZWZpbmVkIGJ5IHRoZQ0KbW9kdWxlLg0KDQpLLg0KDQoN Cg== From nobody Mon Mar 20 07:17:36 2017 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 3619D131496 for ; Mon, 20 Mar 2017 07:17:35 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 FhK6SrsM4JSY for ; Mon, 20 Mar 2017 07:17:32 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74201294A3 for ; Mon, 20 Mar 2017 07:17:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3C77D6BA; Mon, 20 Mar 2017 15:17:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2MKhas4uAXBO; Mon, 20 Mar 2017 15:17:30 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 20 Mar 2017 15:17:31 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E942920035; Mon, 20 Mar 2017 15:17:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RbpiEf0L-nOD; Mon, 20 Mar 2017 15:17:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF54120033; Mon, 20 Mar 2017 15:17:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B09E13EEF54C; Mon, 20 Mar 2017 15:17:30 +0100 (CET) Date: Mon, 20 Mar 2017 15:17:29 +0100 From: Juergen Schoenwaelder To: Kent Watsen Cc: Martin Bjorklund , "netmod@ietf.org" Message-ID: <20170320141729.GA33652@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netmod@ietf.org" References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> <20170319181630.GA32188@elstar.local> <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> <20170320062722.GA32956@elstar.local> <79DEF6A3-F1AE-45C9-A88F-14796FEF884C@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79DEF6A3-F1AE-45C9-A88F-14796FEF884C@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 14:17:35 -0000 On Mon, Mar 20, 2017 at 02:05:09PM +0000, Kent Watsen wrote: > > Why are you mentioning identities here? Yes, the module defines > identities, but that is beside the point to what I'm saying. I'm > only discussing the module (e.g. ietf-i2rs-solution) showing up > in YANG Library and using the age-old logic of, if the server > advertises it, then it means that it supports it, which in this > case means that it supports all the datastores defined by the > module. > But this logic is already broken for the datastores defined in the revised datastores document. It defines an identity for startup but not all systems implement startup. End of proof. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 20 07:28:58 2017 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 DA3C8131497 for ; Mon, 20 Mar 2017 07:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 AUTuRFFJKqjJ for ; Mon, 20 Mar 2017 07:28:55 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0098.outbound.protection.outlook.com [104.47.36.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558E51294A3 for ; Mon, 20 Mar 2017 07:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=89Q7npQ10xDDqP+f+0/kGE5mkwuGxVxaFVjSDqUtJak=; b=YJNZPV4OA+eM3azK0U05rUP4KNhNmemcfG5SwbwXexpMu7qjRqe55vM0tyLy3N7ax6ZJwXX1XzihUKnQwQ0S9asgiECjaiI/dnZKSgav7R9IN7sX68KgKQEbDkgMr6hZDO/05XCA8Oww8nIGF2TYIEU9AQL1S6212A2KjWlne/Y= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Mon, 20 Mar 2017 14:28:54 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0991.011; Mon, 20 Mar 2017 14:28:54 +0000 From: Kent Watsen To: Juergen Schoenwaelder CC: Martin Bjorklund , "netmod@ietf.org" Thread-Topic: [netmod] some comments on revised-datastores-01 Thread-Index: AQHSoB0pC6yqRGsTNE2Jco/Jvjk1RKGb2quAgAA4bM+AAErBAIAAGmtHgAABXwCAABnezIAAsleAgAA81wCAAEaBgP//wCGA Date: Mon, 20 Mar 2017 14:28:53 +0000 Message-ID: <4FAE1F8E-5449-4761-9950-41956A1CB7CB@juniper.net> References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> <20170319181630.GA32188@elstar.local> <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> <20170320062722.GA32956@elstar.local> <79DEF6A3-F1AE-45C9-A88F-14796FEF884C@juniper.net> <20170320141729.GA33652@elstar.local> In-Reply-To: <20170320141729.GA33652@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:34HooxqL5nrXmJfg/OuUzKfTPPBfGvKKP2FMeIaXeUq9UmB0/haa+9dcUVxLD65i4TULCaI/HknFip3Wau9bsc8GFf5CqJF+BmCjHRVL8sAsWvxampA5/aX0jzn/m4JZ0SAkkwLz1PoE7/iQEd9r0hkHTlooO+95WfMvkOHkOJUimbLs2Ro1vVoiuhzU/ln7f8WsAX+8IA4lCE5QqxPjeAeEAihoPogYKm1kMwI/IzHG64OT6MGGyfxrCw36pzNr4gKt/q4RzAL+KsrvOoUzHX9xBwP+w+BdIQjfJMPj2dJjrIKcaXHJg+jT1+XHNY6LZuo0tjUPYZ18zaWNj2NXBQ== x-ms-office365-filtering-correlation-id: 98b5d079-217f-4248-556b-08d46f9d6fca x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39840400002)(33656002)(81166006)(8676002)(8936002)(83506001)(93886004)(66066001)(3280700002)(36756003)(189998001)(86362001)(4001350100001)(2906002)(54356999)(5660300001)(2900100001)(305945005)(122556002)(77096006)(229853002)(6506006)(6486002)(76176999)(6436002)(3660700001)(7736002)(50986999)(230783001)(54906002)(6512007)(53936002)(2950100002)(6916009)(110136004)(38730400002)(25786008)(6116002)(102836003)(3846002)(4326008)(99286003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 20 Mar 2017 14:28:53.9760 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 14:28:57 -0000 DQo+IEJ1dCB0aGlzIGxvZ2ljIGlzIGFscmVhZHkgYnJva2VuIGZvciB0aGUgZGF0YXN0b3JlcyBk ZWZpbmVkIGluIHRoZQ0KPiByZXZpc2VkIGRhdGFzdG9yZXMgZG9jdW1lbnQuIEl0IGRlZmluZXMg YW4gaWRlbnRpdHkgZm9yIHN0YXJ0dXAgYnV0DQo+IG5vdCBhbGwgc3lzdGVtcyBpbXBsZW1lbnQg c3RhcnR1cC4gRW5kIG9mIHByb29mLg0KDQpIYSBoYSwgeWVzIHByb2Zlc3Nvci4gIEJ1dCByZWNh bGwgdGhpcyBzdGFydGVkIGFzIGEgZGlzY3Vzc2lvbiByZWdhcmRpbmcNCndoYXQgdG8gZG8gZm9y IHRoZSBuZXcgZHluYW1pYyBkYXRhc3RvcmVzIChub3QgYnVpbHQtaW4gZGF0YXN0b3JlcykgYW5k DQp0aGVuIHNvbWVvbmUgc2FpZCBtYXliZSB3ZSBzaG91bGQgc3VwcG9ydCBvdGhlciBkYXRhc3Rv cmVzIHRvby4gIEknbSBub3QNCnN1cmUgd2UgbmVlZCB0byBkbyB0aGlzIGJ1dCwgaWYgd2UgZGlk LCB0aGVuIHdlIGNvdWxkIGNyZWF0ZSBtb2R1bGVzIGZvcg0KdGhlbSAoaS5lLiwgaWV0Zi1zdGFy dHVwKS4NCg0KSy4NCg0KDQo= From nobody Mon Mar 20 07:38:03 2017 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 B7FAC1274D2 for ; Mon, 20 Mar 2017 07:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 gmP4fhZOVOM7 for ; Mon, 20 Mar 2017 07:38:00 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD57131499 for ; Mon, 20 Mar 2017 07:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1019; q=dns/txt; s=iport; t=1490020679; x=1491230279; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=zJXV16Az7Z0GScc6hy71oq0b0c4jZpibMudsPV3rBdM=; b=GaCmzZqmtUK5fpsPXfYqNMfSP0HmctbId7jJWeQDTjuiZ6ztG9zMbCOR d+Uiiu8s0GqUruYa9s/i2EBzP7HS/mU4DAmvTaeIwnVmTge0RkIlz/x35 swvUGvGI6SdZoe4kVTcqD4RamK6v4IGDRyQiBM7B6Mdf1PNXnCBdXFyeS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQDH589Y/xbLJq1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQyKmCNcnOQaZVDgg4fC4UuSgKDShgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBAQE2NgsQCw4KLicwBgEMBgIBAYl0CA6peIpJAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBGAWGToIFgmqELYYMAQScTZJDilaGVYtGiBIfOIEEIxYIFxVBhFcdgWN?= =?us-ascii?q?ANYlzAQEB?= X-IronPort-AV: E=Sophos;i="5.36,194,1486425600"; d="scan'208";a="651575181" 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; 20 Mar 2017 14:37:57 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2KEburf025192; Mon, 20 Mar 2017 14:37:56 GMT To: Kent Watsen , Juergen Schoenwaelder References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> <20170319181630.GA32188@elstar.local> <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> <20170320062722.GA32956@elstar.local> <79DEF6A3-F1AE-45C9-A88F-14796FEF884C@juniper.net> <20170320141729.GA33652@elstar.local> <4FAE1F8E-5449-4761-9950-41956A1CB7CB@juniper.net> Cc: "netmod@ietf.org" From: Robert Wilton Message-ID: Date: Mon, 20 Mar 2017 14:37:56 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <4FAE1F8E-5449-4761-9950-41956A1CB7CB@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 14:38:02 -0000 On 20/03/2017 14:28, Kent Watsen wrote: >> But this logic is already broken for the datastores defined in the >> revised datastores document. It defines an identity for startup but >> not all systems implement startup. End of proof. > Ha ha, yes professor. But recall this started as a discussion regarding > what to do for the new dynamic datastores (not built-in datastores) and > then someone said maybe we should support other datastores too. I'm not > sure we need to do this but, if we did, then we could create modules for > them (i.e., ietf-startup). I also think that having the device advertise a single list of supported datatstores as part of YANG library might be a good idea. It seems like it is a straight forward way to make the information available in a way that is easy for clients to consume. Thanks, Rob > > K. > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Mar 20 07:43:40 2017 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 F328B1314A6 for ; Mon, 20 Mar 2017 07:43:37 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 2w9dOSR-t8JB for ; Mon, 20 Mar 2017 07:43:36 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6D81314A4 for ; Mon, 20 Mar 2017 07:43:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E02E7702; Mon, 20 Mar 2017 15:43:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MFMMJoVnDBSK; Mon, 20 Mar 2017 15:43:34 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 20 Mar 2017 15:43:34 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 943F320035; Mon, 20 Mar 2017 15:43:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id o_gYHNc3hVTO; Mon, 20 Mar 2017 15:43:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 499D520033; Mon, 20 Mar 2017 15:43:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 78D983EEF75C; Mon, 20 Mar 2017 15:43:38 +0100 (CET) Date: Mon, 20 Mar 2017 15:43:38 +0100 From: Juergen Schoenwaelder To: Kent Watsen Cc: Martin Bjorklund , "netmod@ietf.org" Message-ID: <20170320144335.GB33724@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netmod@ietf.org" References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> <20170319181630.GA32188@elstar.local> <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> <20170320062722.GA32956@elstar.local> <79DEF6A3-F1AE-45C9-A88F-14796FEF884C@juniper.net> <20170320141729.GA33652@elstar.local> <4FAE1F8E-5449-4761-9950-41956A1CB7CB@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FAE1F8E-5449-4761-9950-41956A1CB7CB@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 14:43:38 -0000 On Mon, Mar 20, 2017 at 02:28:53PM +0000, Kent Watsen wrote: > > > But this logic is already broken for the datastores defined in the > > revised datastores document. It defines an identity for startup but > > not all systems implement startup. End of proof. > > Ha ha, yes professor. But recall this started as a discussion regarding > what to do for the new dynamic datastores (not built-in datastores) and > then someone said maybe we should support other datastores too. I'm not > sure we need to do this but, if we did, then we could create modules for > them (i.e., ietf-startup). > I believe this is the wrong direction, even if we rewrite the module in the revised datastores document and split it into multiple modules. A simple list of implemented datastores is cheap. It is flexible. It does not require explanations and rules how definitions must be split into modules that finally must be remembered and checked still in 5-10 years from now. I firmly believe that these types of 'optimizations' lead to creeping complexity down the road. Lets not create CLRs how modules must be structued, named, etc. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 20 10:09:21 2017 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 9A90A1314F8 for ; Mon, 20 Mar 2017 10:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 UwMrMLrE1gj5 for ; Mon, 20 Mar 2017 10:09:17 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0107.outbound.protection.outlook.com [104.47.40.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD941314ED for ; Mon, 20 Mar 2017 10:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p7Tv+XC4tzn6N6aQv2GniozSBTIptZdn+B1hyr8Ml9E=; b=e3dJJXRlhwy2ojnqVQR7TWJ1MceBJ2e7yhAyIt5WSwuQ71BgH5UnF36nH08wAS48I35gbZtJE/f6eLoG1mHH3NOAN+yaWI/5HBKvG3EF8G0QsFnUe+OPPnPLvR75ODEwoY23C0+Mx+kNiIL5yoH8nt0C/w99iipXW4POYp4YHQA= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Mon, 20 Mar 2017 17:09:16 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0991.011; Mon, 20 Mar 2017 17:09:16 +0000 From: Kent Watsen To: Juergen Schoenwaelder CC: Martin Bjorklund , "netmod@ietf.org" Thread-Topic: [netmod] some comments on revised-datastores-01 Thread-Index: AQHSoB0pC6yqRGsTNE2Jco/Jvjk1RKGb2quAgAA4bM+AAErBAIAAGmtHgAABXwCAABnezIAAsleAgAA81wCAAEaBgP//wCGAgABHLQD//+WigA== Date: Mon, 20 Mar 2017 17:09:16 +0000 Message-ID: References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> <20170319181630.GA32188@elstar.local> <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> <20170320062722.GA32956@elstar.local> <79DEF6A3-F1AE-45C9-A88F-14796FEF884C@juniper.net> <20170320141729.GA33652@elstar.local> <4FAE1F8E-5449-4761-9950-41956A1CB7CB@juniper.net> <20170320144335.GB33724@elstar.local> In-Reply-To: <20170320144335.GB33724@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:FtSnnLZeEwi6mY478xwqlyQU8J/ILqW4X9miCYJFxB8G1buv+y6q5N3ymb7PvN8+1iR0MCa4YY3dQ/sR9DKHgZ+o+1Dlurq2rlT/MGo52UMLuQwscSTXs9DMUweOeAk8uAc60YbTXJjotEzxe9Uhqrri11Twu6HpqE5vHHEgKyk/VyfCmeL0QKq3LLkJTcefYPMIUDSzAVCSgK92d7NgQOEnh12OgQdQLLdMY6yAx4Owfm854CmRmd6MEyBjNXAzbWaoQco1aGEsSzfOOZ8eWfNKTN0purb2AxQpN2PDnEZyfJOT4UOuPSpqlKwWzB7PSMegoG5o928Hc1SmHYZvpQ== x-ms-office365-filtering-correlation-id: 11aec82b-c78b-4232-ad22-08d46fb3d70f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39840400002)(39450400003)(39410400002)(39850400002)(53936002)(102836003)(3846002)(6116002)(4001350100001)(36756003)(66066001)(4326008)(561944003)(33656002)(110136004)(38730400002)(77096006)(6246003)(99286003)(6486002)(6512007)(229853002)(122556002)(54356999)(76176999)(50986999)(6506006)(25786008)(6436002)(230783001)(5660300001)(189998001)(6916009)(86362001)(7736002)(2906002)(3660700001)(305945005)(2900100001)(83506001)(82746002)(3280700002)(83716003)(8676002)(2950100002)(8936002)(81166006)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 20 Mar 2017 17:09:16.3009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 17:09:20 -0000 DQo+IEkgYmVsaWV2ZSB0aGlzIGlzIHRoZSB3cm9uZyBkaXJlY3Rpb24sIGV2ZW4gaWYgd2UgcmV3 cml0ZSB0aGUgbW9kdWxlDQo+IGluIHRoZSByZXZpc2VkIGRhdGFzdG9yZXMgZG9jdW1lbnQgYW5k IHNwbGl0IGl0IGludG8gbXVsdGlwbGUgbW9kdWxlcy4NCj4gQSBzaW1wbGUgbGlzdCBvZiBpbXBs ZW1lbnRlZCBkYXRhc3RvcmVzIGlzIGNoZWFwLiBJdCBpcyBmbGV4aWJsZS4gSXQNCj4gZG9lcyBu b3QgcmVxdWlyZSBleHBsYW5hdGlvbnMgYW5kIHJ1bGVzIGhvdyBkZWZpbml0aW9ucyBtdXN0IGJl IHNwbGl0DQo+IGludG8gbW9kdWxlcyB0aGF0IGZpbmFsbHkgbXVzdCBiZSByZW1lbWJlcmVkIGFu ZCBjaGVja2VkIHN0aWxsIGluIDUtMTANCj4geWVhcnMgZnJvbSBub3cuIEkgZmlybWx5IGJlbGll dmUgdGhhdCB0aGVzZSB0eXBlcyBvZiAnb3B0aW1pemF0aW9ucycNCj4gbGVhZCB0byBjcmVlcGlu ZyBjb21wbGV4aXR5IGRvd24gdGhlIHJvYWQuIExldHMgbm90IGNyZWF0ZSBDTFJzIGhvdw0KPiBt b2R1bGVzIG11c3QgYmUgc3RydWN0dWVkLCBuYW1lZCwgZXRjLg0KDQpUaGF0J3MgYSBiZXR0ZXIg YW5zd2VyLiAgQXQgbGVhc3Qgbm93IEkgZ2V0IHRoZSBzZW5zZSB0aGF0IHlvdSBhY3R1YWxseQ0K dW5kZXJzdG9vZCB3aGF0IEkgd2FzIHNheWluZy4NCg0KQXMgZm9yIHlvdXIgcHJvcG9zYWwsIEkg YWdyZWUgd2l0aCB5b3UgdGhhdCBpdCB3b3VsZCBiZSBiZXN0IHRvIGhhdmUgYW4NCmV4cGxpY2l0 IGxpc3QuICBJIGFzc3VtZSB0aGF0IHRoaXMgd291bGQgYmUgYW5vdGhlciBwcm9wb3NlZCBjaGFu Z2UgdG8NCllBTkcgTGlicmFyeSAoaS5lLiwgU2VjdGlvbiBELjIgaW4gdGhlIHJldmlzZWQtZGF0 YXN0b3JlcyBkcmFmdCkuICBJdA0Kd2lsbCBiZSB0cmlja3kgdG8gZW5mb3JjZSB0aGUgdXNlIG9m IHRoaXMgdmVyc2lvbiBvZiBZQU5HIExpYnJhcnkgaW4gDQpSRVNUQ09ORiB3aXRob3V0IGEgLWJp cyBkb2N1bWVudC4uLg0KDQpLLg0KDQoNCg== From nobody Mon Mar 20 12:05:07 2017 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 358B7131692 for ; Mon, 20 Mar 2017 12:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 FPm_COhkxGs3 for ; Mon, 20 Mar 2017 12:05:04 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 DA61D1293D6 for ; Mon, 20 Mar 2017 12:05:03 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.19.173; From: "Susan Hares" To: "'Kent Watsen'" , "'Ladislav Lhotka'" , "'Robert Wilton'" Cc: References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> In-Reply-To: Date: Mon, 20 Mar 2017 15:00:05 -0400 Message-ID: <000801d2a1ac$3094ca30$91be5e90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUooBvvnQPAF+jVm3AXSML+0Bm+Ek1gGgPefFAdZ3URsChzyXlQFia/DuAXHgKmSgVm1mgA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 19:05:06 -0000 Kent and Lada: I agree that we need some parameters in yang. I agree with version 1 of the revised datastores. In my proposal regarding I2RS Yang, I tried to start suggesting some parameters for control plane datastores, and ephemeral control plane datastores. In this I also suggest a "validation" key word that will provide additional validation sequences for the control plane datastores. There may be better ways to do this in Yang, but I hope it is a start. https://datatracker.ietf.org/doc/draft-hares-i2nsf-capability-yang/ If we start with this yang, I thought it made the capabilities easier to define for NETCONF and RESTCONF. https://datatracker.ietf.org/doc/draft-hares-netconf-i2rs-netconf/ I welcome any change or fixes. I tried to make things concrete so it would help the discussion. Sue -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Friday, March 17, 2017 11:40 AM To: Ladislav Lhotka; Robert Wilton Cc: netmod@ietf.org Subject: Re: [netmod] draft netmod charter update proposal Hi Lada, I think some of what you're getting at is in these guidelines: https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-01#section- 5 But you're thinking about something more generalized? Kent // contributor -----ORIGINAL MESSAGE----- > On 17 Mar 2017, at 15:46, Robert Wilton wrote: > > > > On 17/03/2017 14:32, Ladislav Lhotka wrote: >>> On 17 Mar 2017, at 15:04, Robert Wilton wrote: >>> >>> Hi, >>> >>> Would 7950bis be allowed to have a normative reference to an Informational RFC that defined the YANG datastores? >> My idea is that 7950bis should be made independent of any particular set of datastores, so such a normative reference shouldn't be needed. > OK, if 70590bis was entirely datastore agnostic, then there would need > to be a description of how YANG applies to a particular set of > datastores (in particular the config: true|false statement), and which > datastores are validated. Would that go in the revised I don't think that config true/false is necessarily tied to a particular set of datastores, it can be generalized to RW/RO. > datastores architecture or somewhere else? It wouldn't make sense to have to repeat this for every network configuration protocol. I think the structure of datastores and validation workflow could be supplied as extra info, see item #3 near the end of this message: https://www.ietf.org/mail-archive/web/netmod/current/msg17673.html Lada > > Thanks, > Rob > > >> >> Lada >> >>> If we did a 7950bis document (and it isn't clear that one is actually required to support the revised datastores draft) then does that mean we would also need to have a new version of YANG? >>> >>> That would potentially seem like a backwards step. Also what would it mean for an implementation that is aware of the new datastores but is using a mix of YANG modules with different versions? >>> >>> I don't understand why the revised datastores draft should not be standards track once the various appendices have been moved out, noting that they are really only in the one draft at this stage because it seemed like that would make it easier for folks to review and comment on. >>> >>> Is the only issue here which WG the draft is being worked on? >>> >>> Thanks, >>> Rob >>> >>> >>> On 17/03/2017 13:22, Mehmet Ersue wrote: >>>> I think YANG identities should be standardized with 7950bis. >>>> >>>> Mehmet >>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Thursday, March 16, 2017 12:28 PM >>>>> To: Juergen Schoenwaelder ; >>>>> Mehmet Ersue >>>>> Cc: 'Kent Watsen' ; netmod@ietf.org >>>>> Subject: Re: [netmod] draft netmod charter update proposal >>>>> >>>>> Juergen, >>>>> >>>>> Thank you for the input. I think your point highlights how the >>>>> technical contents of a document drives the intended status of a document. >>>>> >>>>> Lou >>>>> >>>>> PS as a reminder to all, intended status of documents is *not* >>>>> typically included in charters and are not included in the distributed version. >>>>> >>>>> >>>>> >>>>> >>>>> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder >>>>> wrote: >>>>> >>>>>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: >>>>>> >>>>>>> That said different people including Netconf WG co-chairs think >>>>>>> the DS concept document is Informational in nature and should be >>>>>>> published as >>>>> an >>>>>>> Informational concept to be used in and adopted for the needs in >>>> diverse >>>>>>> protocol WGs. This is as I think also important to avoid an >>>>>>> overlapping between NETCONF and NETMOD charters. >>>>>> The current datastore draft includes concrete YANG idenity >>>>>> definitions for datastores and origins and these definitions >>>>>> better be standards track. >>>>>> >>>>>> /js >>>>>> >>>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>>> Fax: +49 421 200 3103 >>>>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> . >>>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> >> >> >> >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Mar 20 16:21:51 2017 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 010EF129412 for ; Mon, 20 Mar 2017 16:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTkzXEmV-cKU for ; Mon, 20 Mar 2017 16:21:47 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BA612940E for ; Mon, 20 Mar 2017 16:21:47 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id v203so131729wmg.0 for ; Mon, 20 Mar 2017 16:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mo2Rlus7zCMKKoyTeJcIa5svsgbykJAFMFon+Vkk6HE=; b=P2SwRFpIZJmxnM32kvsNciHqtcEGS8Ut1iLd8Ay9w0XOfxc7a3rfSuKwisPNPjBJtE KefX1P7xv0ImlawnPBHe8d6/wHKAzB9gB5opRKU6vxOgEc8C4QDCPYPo3iRtzKKd85r2 64SJQ9EOp0u+0ckXoOk6XSQdZ7RvwdX6NFKYb8AcMIsKfjv+rh7FgKe0NFzvKGwe8skC 0SXJdXO8JKvdPYAVL+jAGMcWZ4BzKymbwHZ0dIZzMJ3LZWrIMooCxsdBzko8uOJTcn59 QHaEI+MSQShaaphtePlb4h+OrH10HC/tEdwdbdg31h/XgnpK8nModq3RhA6FLo7Ks1D3 ZLmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mo2Rlus7zCMKKoyTeJcIa5svsgbykJAFMFon+Vkk6HE=; b=rylJAUhGwh3SK2KmQwDujBuOw5PxjQ4sR8ig0ZLkVZUgWmbs4Ql5ASlQEDrwCk/bmF 3qQlhLTHAPnf1CbjLrdBxnNLieVmsFRn49863JQUHLlPFoAlHdpk6pJuQdLxBnaFYmOP zxlOyvEhN39t9iF2sgHZtc4uvx3070LDRBFi1i0dCVVphslDauP5gj/8h0Ym5kmqmTMP enDHTpWnXN67baeO8S+dpwN0uQmPQrrY3qsdDq2bzvVUUZFl5ear3+cWIQV2QlHx9RLa U7VHIxjt9cxsMGruZjQmNMWYBcEcF6mOyU4rJHjALunvvPbRzCLv6nrFan28jtDUrFMU PMmA== X-Gm-Message-State: AFeK/H1xgjb++CgiltbXQMpHxEUfU09HDmwAbCDkafP3epMVtadWNCsXWOMaA20h32tQl+FVpctvoEo3jitmWg== X-Received: by 10.28.103.3 with SMTP id b3mr45839wmc.99.1490052106162; Mon, 20 Mar 2017 16:21:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.166.37 with HTTP; Mon, 20 Mar 2017 16:21:44 -0700 (PDT) In-Reply-To: References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> <20170319181630.GA32188@elstar.local> <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> <20170320062722.GA32956@elstar.local> <79DEF6A3-F1AE-45C9-A88F-14796FEF884C@juniper.net> <20170320141729.GA33652@elstar.local> <4FAE1F8E-5449-4761-9950-41956A1CB7CB@juniper.net> <20170320144335.GB33724@elstar.local> From: Andy Bierman Date: Mon, 20 Mar 2017 16:21:44 -0700 Message-ID: To: Kent Watsen Cc: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a114a91b27c4424054b31caec Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 23:21:50 -0000 --001a114a91b27c4424054b31caec Content-Type: text/plain; charset=UTF-8 Hi, Not sure I like the YANG module with all the datastore identities because it makes datastore discovery more complicated. I prefer the server advertise capabilities in the message. More importantly, all the existing NETCONF operations use a container with a choice in it to select the source and target for various operations. It is trivial for a YANG module to simply augment these choices with new leafs, rather than forcing all client and server implementations to duplicate these operations with identifyref leafs for these parameters. Andy On Mon, Mar 20, 2017 at 10:09 AM, Kent Watsen wrote: > > > I believe this is the wrong direction, even if we rewrite the module > > in the revised datastores document and split it into multiple modules. > > A simple list of implemented datastores is cheap. It is flexible. It > > does not require explanations and rules how definitions must be split > > into modules that finally must be remembered and checked still in 5-10 > > years from now. I firmly believe that these types of 'optimizations' > > lead to creeping complexity down the road. Lets not create CLRs how > > modules must be structued, named, etc. > > That's a better answer. At least now I get the sense that you actually > understood what I was saying. > > As for your proposal, I agree with you that it would be best to have an > explicit list. I assume that this would be another proposed change to > YANG Library (i.e., Section D.2 in the revised-datastores draft). It > will be tricky to enforce the use of this version of YANG Library in > RESTCONF without a -bis document... > > K. > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114a91b27c4424054b31caec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Not sure I like the YANG module wit= h all the datastore identities
because it makes datastore dis= covery more complicated.
I prefer the server advertise capabiliti= es in the <hello> message.

More importantly,= all the existing NETCONF operations use
a container with a choic= e in it to select the source and target for various operations.
I= t is trivial for a YANG module to simply augment these choices with new lea= fs,
rather than forcing all client and server implementations to = duplicate these operations
with identifyref leafs for these param= eters.


Andy



On Mon, Mar 20, 2017 at 10:09 AM, Kent Watsen <kwatsen@juniper.net&= gt; wrote:

> I believe this is the wrong direction, even if we rewrite the module > in the revised datastores document and split it into multiple modules.=
> A simple list of implemented datastores is cheap. It is flexible. It > does not require explanations and rules how definitions must be split<= br> > into modules that finally must be remembered and checked still in 5-10=
> years from now. I firmly believe that these types of 'optimization= s'
> lead to creeping complexity down the road. Lets not create CLRs how > modules must be structued, named, etc.

That's a better answer.=C2=A0 At least now I get the sense that you act= ually
understood what I was saying.

As for your proposal, I agree with you that it would be best to have an
explicit list.=C2=A0 I assume that this would be another proposed change to=
YANG Library (i.e., Section D.2 in the revised-datastores draft).=C2=A0 It<= br> will be tricky to enforce the use of this version of YANG Library in
RESTCONF without a -bis document...

K.


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

--001a114a91b27c4424054b31caec-- From nobody Mon Mar 20 19:50:14 2017 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 0665D1316EA for ; Mon, 20 Mar 2017 19:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EwICviu1ufm for ; Mon, 20 Mar 2017 19:50:08 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id E2D731316E9 for ; Mon, 20 Mar 2017 19:50:07 -0700 (PDT) Received: (qmail 8140 invoked by uid 0); 21 Mar 2017 02:50:05 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 21 Mar 2017 02:50:05 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id ySl11u00a2SSUrH01Sl4ql; Mon, 20 Mar 2017 20:45:05 -0600 X-Authority-Analysis: v=2.1 cv=H5NInYoi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=WiwZGfC6uLdNB0ikPj0A:9 a=pILNOxqGKmIA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=9ZYBcOd_X9kS2t7VFny2:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YQ6r99pcoZCx4c6fltxkH5ZsxOul2vOtJ9mtyBf6Uvk=; b=x987HWTUkZTxq8Vm+zf7lw36yc 1U1pWsLclfxnu53f8FqoIzcdEFtdZ54nYidAV+wEi84k2BMI/rdg2jrHGeTJgsD8BKTm6OQQoWAgo QKi7X+ecoqLpBdMwISMIbIxXW; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:52404 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cq9nB-0005Gc-CA; Mon, 20 Mar 2017 20:45:01 -0600 To: Benoit Claise , Juergen Schoenwaelder , Mehmet Ersue References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <34c4694e-3058-96f8-6daf-5ceacb882697@cisco.com> Cc: netmod@ietf.org From: Lou Berger Message-ID: <319592fc-41a8-14c9-fc6f-fb59326d5c2b@labn.net> Date: Mon, 20 Mar 2017 22:44:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <34c4694e-3058-96f8-6daf-5ceacb882697@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1cq9nB-0005Gc-CA X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:52404 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 02:50:10 -0000 Benoit, Okay - we'll add the intended status to the milestones. Lou On 3/20/2017 7:09 AM, Benoit Claise wrote: > Lou, > > In all my WGs, we consistently documented the intended status in the > milestones, expressing the _intended _status at the time of the > charter discussion > > Regards, Benoit >> Juergen, >> >> Thank you for the input. I think your point highlights how the >> technical contents of a document drives the intended status of a >> document. >> >> Lou >> >> PS as a reminder to all, intended status of documents is *not* >> typically included in charters and are not included in the >> distributed version. >> >> >> >> >> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder >> wrote: >> >>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote: >>> >>>> That said different people including Netconf WG co-chairs think the DS >>>> concept document is Informational in nature and should be published >>>> as an >>>> Informational concept to be used in and adopted for the needs in >>>> diverse >>>> protocol WGs. This is as I think also important to avoid an >>>> overlapping >>>> between NETCONF and NETMOD charters. >>> >>> The current datastore draft includes concrete YANG idenity definitions >>> for datastores and origins and these definitions better be standards >>> track. >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >>> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . >> > From nobody Tue Mar 21 01:04:23 2017 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 EAD3A129654 for ; Tue, 21 Mar 2017 01:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 kzQv7qQoa0BF for ; Tue, 21 Mar 2017 01:04:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0203012940E for ; Tue, 21 Mar 2017 01:04:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CE5AC8F4; Tue, 21 Mar 2017 09:04:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3mGVyhZHKEAd; Tue, 21 Mar 2017 09:04:18 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Mar 2017 09:04:18 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97C6520039; Tue, 21 Mar 2017 09:04:18 +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 fqaqzJY6Skgh; Tue, 21 Mar 2017 09:04:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B05120038; Tue, 21 Mar 2017 09:04:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 165893EF0716; Tue, 21 Mar 2017 09:04:23 +0100 (CET) Date: Tue, 21 Mar 2017 09:04:23 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: Robert Wilton , Mehmet Ersue , Lou Berger , netmod@ietf.org Message-ID: <20170321080422.GB35044@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , Robert Wilton , Mehmet Ersue , Lou Berger , netmod@ietf.org References: <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 08:04:22 -0000 On Fri, Mar 17, 2017 at 04:33:24PM +0100, Ladislav Lhotka wrote: > > I don't think that config true/false is necessarily tied to a particular set of datastores, it can be generalized to RW/RO. > I do not agree that config true/false just means read write and I certainly do not want semantics of statements to be changed. It is easy to create new statements if needed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 21 02:13:47 2017 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 5BBBD129477 for ; Tue, 21 Mar 2017 02:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 aisEnds0SjUO for ; Tue, 21 Mar 2017 02:13:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AD3124D68 for ; Tue, 21 Mar 2017 02:13:42 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:d20:8e4d:8768:16f6] (unknown [IPv6:2001:718:1a02:1:d20:8e4d:8768:16f6]) by mail.nic.cz (Postfix) with ESMTPSA id 59C93600D2; Tue, 21 Mar 2017 10:13:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490087621; bh=JxKZk3ACrkhPbU7xcycPe9Nr2Qoib+KqRCGr/xewmHg=; h=From:Date:To; b=hC7uhBrx8NHtZhKd7U2jDWc7qs/q/KZLnzVsa/qbeSxrA9lqWDFZOJmJKrU4onZak m1EoVt2TzBZwXp26+snsABqCVIp9Um+4EANlq3JyhanXtltc+UdkklO6LwHjjRAjdu R0N5JkkGW2bcA5+oy2PLiAZ4/baFaz5SLgspSVXc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170321080422.GB35044@elstar.local> Date: Tue, 21 Mar 2017 10:13:40 +0100 Cc: Robert Wilton , Mehmet Ersue , Lou Berger , netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0298C599-E206-4777-A95C-5F58E0D519AA@nic.cz> References: <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> <20170321080422.GB35044@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 09:13:46 -0000 > On 21 Mar 2017, at 09:04, Juergen Schoenwaelder = wrote: >=20 > On Fri, Mar 17, 2017 at 04:33:24PM +0100, Ladislav Lhotka wrote: >>=20 >> I don't think that config true/false is necessarily tied to a = particular set of datastores, it can be generalized to RW/RO. >>=20 >=20 > I do not agree that config true/false just means read write and I > certainly do not want semantics of statements to be changed. It is > easy to create new statements if needed. The revised-datastores draft changes the semantics of "configuration = data" - for example, the definition from RFC 6241 clearly won't apply to = the "running" datastore in the new datastore model. So a new definition = of configuration data will probably be needed, and this implicitly = changes the semantics of the "config" statement. BTW, we use rw/ro in tree diagrams. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 21 02:43:16 2017 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 46E41129508 for ; Tue, 21 Mar 2017 02:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 W1mYBTpqoxOL for ; Tue, 21 Mar 2017 02:43:13 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00F01294D3 for ; Tue, 21 Mar 2017 02:43:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A7C4F945; Tue, 21 Mar 2017 10:43:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4SFRYe7lI2vd; Tue, 21 Mar 2017 10:43:10 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Mar 2017 10:43:11 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5371A2003B; Tue, 21 Mar 2017 10:43:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GUdxMfheFi4q; Tue, 21 Mar 2017 10:43:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73C8520038; Tue, 21 Mar 2017 10:43:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9CDCD3EF0D08; Tue, 21 Mar 2017 10:43:14 +0100 (CET) Date: Tue, 21 Mar 2017 10:43:13 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: Robert Wilton , Mehmet Ersue , Lou Berger , netmod@ietf.org Message-ID: <20170321094313.GA35449@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , Robert Wilton , Mehmet Ersue , Lou Berger , netmod@ietf.org References: <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> <20170321080422.GB35044@elstar.local> <0298C599-E206-4777-A95C-5F58E0D519AA@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0298C599-E206-4777-A95C-5F58E0D519AA@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 09:43:15 -0000 On Tue, Mar 21, 2017 at 10:13:40AM +0100, Ladislav Lhotka wrote: > > The revised-datastores draft changes the semantics of "configuration data" - for example, the definition from RFC 6241 clearly won't apply to the "running" datastore in the new datastore model. Why would that be the case? > So a new definition of configuration data will probably be needed, and this implicitly changes the semantics of the "config" statement. > YANG defines the config statement as follows: The "config" statement takes as an argument the string "true" or "false". If "config" is "true", the definition represents configuration. Data nodes representing configuration are part of configuration datastores. I do not think it is the intend of the revised datastore model as written down in the I-D to change this. > BTW, we use rw/ro in tree diagrams. Which is a mis-nomer (tree diagrams were inherited from the SNMP world and somehow the rw/ro distinction was kept even though it is technically wrong). There are more details here, I will start a separate thread for this. Note that the diagrams in the revised datastore ID make a clear distinction between ct/cf and rw/ro. In particular, the ID notes that ct object may be rw in one datastore but ro in a different datastore. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 21 02:59:16 2017 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 85BDD127010 for ; Tue, 21 Mar 2017 02:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 tAT1NMKC66dy for ; Tue, 21 Mar 2017 02:59:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F591200F1 for ; Tue, 21 Mar 2017 02:59:13 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:d20:8e4d:8768:16f6] (unknown [IPv6:2001:718:1a02:1:d20:8e4d:8768:16f6]) by mail.nic.cz (Postfix) with ESMTPSA id D42D661FDE; Tue, 21 Mar 2017 10:59:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490090351; bh=VYrcZE5mGaL3plQzzQGz0+ABgCWKEAmT4OCK3g/h+no=; h=From:Date:To; b=or50vIxkLpjFpW1FtBTWQDXbA9uH52XuQ/1npnx4wvmWy0OZC0gBf/IMSiRwjTOeD qiHkh7O1ne2x7v26NXPRqEKzUrQSDOkGP5Cbh7WOzvqDvOLl7jtizr2xD0KghMVZXL f/kwj4K8yIsTD7ks4Ncj03rKk5DsleW56HG3i9rQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170321094313.GA35449@elstar.local> Date: Tue, 21 Mar 2017 10:59:11 +0100 Cc: Robert Wilton , Mehmet Ersue , Lou Berger , netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3B788B04-4728-45FC-86A7-33A9F4D5CF98@nic.cz> References: <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> <20170321080422.GB35044@elstar.local> <0298C599-E206-4777-A95C-5F58E0D519AA@nic.cz> <20170321094313.GA35449@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 09:59:15 -0000 > On 21 Mar 2017, at 10:43, Juergen Schoenwaelder = wrote: >=20 > On Tue, Mar 21, 2017 at 10:13:40AM +0100, Ladislav Lhotka wrote: >>=20 >> The revised-datastores draft changes the semantics of "configuration = data" - for example, the definition from RFC 6241 clearly won't apply to = the "running" datastore in the new datastore model. >=20 > Why would that be the case? RFC 6241: o configuration data: The set of writable data that is required to transform a system from its initial default state into its current state. If I understand revised-datastores correctly, this will no more be the = case for "running" because it may contain intermediate data that require = further processing (templates) and inactive data that are not used for = changing the device state. This may look like nit-picking but the fact is that we often use the = term configuration in the sense "you know it when you see it".=20 >=20 >> So a new definition of configuration data will probably be needed, = and this implicitly changes the semantics of the "config" statement. >>=20 >=20 > YANG defines the config statement as follows: >=20 > The "config" statement takes as an argument the string "true" or > "false". If "config" is "true", the definition represents > configuration. Data nodes representing configuration are part of > configuration datastores. If the "config" statement really carried some protocol-specific = semantics that isn't meaningful for all potential uses of YANG, it would = be better to remove it from core YANG and define it as an extension that = would be mandatory for configuration protocols that need it. Lada >=20 > I do not think it is the intend of the revised datastore model as > written down in the I-D to change this. >=20 >> BTW, we use rw/ro in tree diagrams. >=20 > Which is a mis-nomer (tree diagrams were inherited from the SNMP world > and somehow the rw/ro distinction was kept even though it is > technically wrong). There are more details here, I will start a > separate thread for this. >=20 > Note that the diagrams in the revised datastore ID make a clear > distinction between ct/cf and rw/ro. In particular, the ID notes that > ct object may be rw in one datastore but ro in a different datastore. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 21 03:00:38 2017 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 AEFC9127010 for ; Tue, 21 Mar 2017 03:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvjfc_CCqTo7 for ; Tue, 21 Mar 2017 03:00:35 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 445081200F1 for ; Tue, 21 Mar 2017 03:00:35 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 910D71AE0310; Tue, 21 Mar 2017 11:00:33 +0100 (CET) Date: Tue, 21 Mar 2017 11:00:39 +0100 (CET) Message-Id: <20170321.110039.248054157847225867.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20170321094313.GA35449@elstar.local> References: <20170321080422.GB35044@elstar.local> <0298C599-E206-4777-A95C-5F58E0D519AA@nic.cz> <20170321094313.GA35449@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 10:00:38 -0000 Juergen Schoenwaelder wrote: > On Tue, Mar 21, 2017 at 10:13:40AM +0100, Ladislav Lhotka wrote: > I do not agree that config true/false just means read write and I > certainly do not want semantics of statements to be changed. +1 [...] > > BTW, we use rw/ro in tree diagrams. > > Which is a mis-nomer (tree diagrams were inherited from the SNMP world > and somehow the rw/ro distinction was kept even though it is > technically wrong). Correct. Nowadays we are using ct vs. cf, so maybe we should use that in the trees. rw vs ro works better visually though - "t" and "f" look fairly similar. /martin From nobody Tue Mar 21 03:04:34 2017 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 5022712967A for ; Tue, 21 Mar 2017 03:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 bMwFilmb4nQf for ; Tue, 21 Mar 2017 03:04:30 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654ED129671 for ; Tue, 21 Mar 2017 03:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=991; q=dns/txt; s=iport; t=1490090669; x=1491300269; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=E0mDGBRPp5M0/YbPi1XPXXbQebNSm+go+ptg/5hni4A=; b=bHhPH2t8iORE68x+qzO3032wfKhHxx1bBYwMzNTJKzt4JwUnDp+OtMFt +3uPj512Fyg0yyUPbk0gCtnh2s/pK4JZhX6SICPsnfLv/dfRtj+sKVTsA 7cGeyoDS21PMHUlBzYmre1a/NyiB8Pgiz4gJhJRsQmetoEMe+pp0dDwCi M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAQC1+dBY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqYI1yc5BqlUSCDh8LhS5KAoNMGAECAQEBAQEBAWsohRYBAQE?= =?us-ascii?q?DAQE2NgsQCw4CCC4nMAYBDAYCAQGKAA6sOopPAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGAWGToIFgmqKOQEEnE6SRoF7iFwjhjOIVIJ4iBIfOIEEIxYIFxVBhldANYl?= =?us-ascii?q?BAQEB?= X-IronPort-AV: E=Sophos;i="5.36,198,1486425600"; d="scan'208";a="651593486" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2017 10:04:27 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2LA4Qj1013651; Tue, 21 Mar 2017 10:04:27 GMT To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de References: <20170321080422.GB35044@elstar.local> <0298C599-E206-4777-A95C-5F58E0D519AA@nic.cz> <20170321094313.GA35449@elstar.local> <20170321.110039.248054157847225867.mbj@tail-f.com> Cc: netmod@ietf.org From: Robert Wilton Message-ID: <044cac42-2fdc-49c9-163b-795258edd153@cisco.com> Date: Tue, 21 Mar 2017 10:04:27 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170321.110039.248054157847225867.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 10:04:33 -0000 On 21/03/2017 10:00, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Tue, Mar 21, 2017 at 10:13:40AM +0100, Ladislav Lhotka wrote: >> I do not agree that config true/false just means read write and I >> certainly do not want semantics of statements to be changed. > +1 > > [...] > >>> BTW, we use rw/ro in tree diagrams. >> Which is a mis-nomer (tree diagrams were inherited from the SNMP world >> and somehow the rw/ro distinction was kept even though it is >> technically wrong). > Correct. Nowadays we are using ct vs. cf, so maybe we should use that > in the trees. rw vs ro works better visually though - "t" and "f" > look fairly similar. Perhaps only mark the config false nodes? I.e. if it isn't specified it is config true. Rob > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Mar 21 03:09:18 2017 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 2B18C1242F7 for ; Tue, 21 Mar 2017 03:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 rutupFu9Nvvf for ; Tue, 21 Mar 2017 03:09:14 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 634DB1296BA for ; Tue, 21 Mar 2017 03:09:14 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:d20:8e4d:8768:16f6] (unknown [IPv6:2001:718:1a02:1:d20:8e4d:8768:16f6]) by mail.nic.cz (Postfix) with ESMTPSA id EFE1161FDE; Tue, 21 Mar 2017 11:09:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490090953; bh=wp4xpPUkNU5mqHhVbX/JOcd3/OJJ6xynR41Wnoms2gQ=; h=From:Date:To; b=Bw3abm1AtEHyV95ncilX4PNY1sy22SrMiyRObI9f6H04SGsnqSfAB2q6+u12cfvuJ JDhvIY1o5IfMyogkjBi0R9VN5xfeYoGeKXwHfNji0e2NPNbJnLCws+VtCcTT7N2ENo ILei+HuE+TXopKoCvQxh7gFAOQ3dCYXIwi8ncYzs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <044cac42-2fdc-49c9-163b-795258edd153@cisco.com> Date: Tue, 21 Mar 2017 11:09:12 +0100 Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= , =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170321080422.GB35044@elstar.local> <0298C599-E206-4777-A95C-5F58E0D519AA@nic.cz> <20170321094313.GA35449@elstar.local> <20170321.110039.248054157847225867.mbj@tail-f.com> <044cac42-2fdc-49c9-163b-795258edd153@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 10:09:16 -0000 > On 21 Mar 2017, at 11:04, Robert Wilton wrote: >=20 >=20 >=20 > On 21/03/2017 10:00, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> On Tue, Mar 21, 2017 at 10:13:40AM +0100, Ladislav Lhotka wrote: >>> I do not agree that config true/false just means read write and I >>> certainly do not want semantics of statements to be changed. >> +1 >>=20 >> [...] >>=20 >>>> BTW, we use rw/ro in tree diagrams. >>> Which is a mis-nomer (tree diagrams were inherited from the SNMP = world >>> and somehow the rw/ro distinction was kept even though it is >>> technically wrong). >> Correct. Nowadays we are using ct vs. cf, so maybe we should use = that >> in the trees. rw vs ro works better visually though - "t" and "f" >> look fairly similar. > Perhaps only mark the config false nodes? I.e. if it isn't specified = it is config true. And what about operations and notifications? Tree diagrams show "ro" but = config true/false doesn't really make sense for them. Lada >=20 > Rob >=20 >=20 >>=20 >>=20 >> /martin >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 21 03:25:35 2017 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 0C6841296C5 for ; Tue, 21 Mar 2017 03:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 51SdR0_aLFJV for ; Tue, 21 Mar 2017 03:25:32 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41A41296C8 for ; Tue, 21 Mar 2017 03:25:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 748E3793 for ; Tue, 21 Mar 2017 11:25:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id e-_Rcvpb8RBy for ; Tue, 21 Mar 2017 11:25:28 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 21 Mar 2017 11:25:29 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F10F120038 for ; Tue, 21 Mar 2017 11:25:28 +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 liORV6ZLai0m; Tue, 21 Mar 2017 11:25:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7BBA720036; Tue, 21 Mar 2017 11:25:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 451DE3EF0F43; Tue, 21 Mar 2017 11:25:33 +0100 (CET) Date: Tue, 21 Mar 2017 11:25:33 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20170321102533.GC35449@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 10:25:34 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, if we want to standardize tree diagrams, we may want to take a more critical look at them, in particular the flags (that were created ad-hoc and in resemblance to MIB tree diagrams). pyang --tree-help says: is one of: rw for configuration data ro for non-configuration data -x for rpcs and actions -n for notifications This is (a) incomlete and (b) somewhat confusing since ct does not equate to readwrite. I am attaching a sample yang file and here is the output pyang 1.7.1 produces: module: tree-sample +--rw config-true-container | +--rw param? string +--ro config-false-container | +--ro value? string +--rw inline-action | +---x action | +---- oops? string | +---w input | | +---w in? string | +--ro output | +--ro out? string +--rw inline-notification +---n notification +---- duration? string rpcs: +---x rpc +---w input | +---w in? string +--ro output | +--ro out? string +--ro oops? string notifications: +---n notification +--ro boom? string I think a better usage of two letter flags would have been this (since it more naturally aligns with what the YANG definition says): is one of: ct for configuration data cf for non-configuration data x- for rpcs and actions xi for rpc or action input xo for rpc or action output n- for notifications nt for notification tree (this is I think the term 7950 uses) module: tree-sample +--ct config-true-container | +--ct param? string +--cf config-false-container | +--cf value? string +--ct inline-action | +--x- action | +--xi input | | +--xi in? string | +--xo output | +--xo out? string +--ct inline-notification +--n- notification +--nt duration? string rpcs: +--x- rpc +--xi input | +--xi in? string +--ro output +--xo out? string notifications: +--n- notification +--nt boom? string (And I think the oops leafs should have triggered an error.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tree-sample.yang" module tree-sample { yang-version 1.1; prefix "tree"; container config-true-container { leaf param { type string; } config true; } container config-false-container { leaf value { type string; } config false; } container inline-action { action action { leaf oops { type string; } input { leaf in { type string; } } output { leaf out { type string; } } } } container inline-notification { notification notification { leaf duration { type string; } } } rpc rpc { input { leaf in { type string; } } output { leaf out { type string; } } leaf oops { type string; } } notification notification { leaf boom { type string; } } } --8t9RHnE3ZwKMSgU+-- From nobody Tue Mar 21 03:30:39 2017 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 E00EB12947D for ; Tue, 21 Mar 2017 03:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 tMyFINjkoOrP for ; Tue, 21 Mar 2017 03:30:37 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EBE21201F2 for ; Tue, 21 Mar 2017 03:30:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3E5BA936; Tue, 21 Mar 2017 11:30:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hCy6PmVU13HY; Tue, 21 Mar 2017 11:30:35 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Mar 2017 11:30:36 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id F271420038; Tue, 21 Mar 2017 11:30:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KaXyfNqLzvGN; Tue, 21 Mar 2017 11:30:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91A8E20036; Tue, 21 Mar 2017 11:30:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B0BE53EF104A; Tue, 21 Mar 2017 11:30:39 +0100 (CET) Date: Tue, 21 Mar 2017 11:30:39 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: Robert Wilton , Mehmet Ersue , Lou Berger , netmod@ietf.org Message-ID: <20170321103039.GA35688@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , Robert Wilton , Mehmet Ersue , Lou Berger , netmod@ietf.org References: <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> <20170321080422.GB35044@elstar.local> <0298C599-E206-4777-A95C-5F58E0D519AA@nic.cz> <20170321094313.GA35449@elstar.local> <3B788B04-4728-45FC-86A7-33A9F4D5CF98@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B788B04-4728-45FC-86A7-33A9F4D5CF98@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 10:30:39 -0000 On Tue, Mar 21, 2017 at 10:59:11AM +0100, Ladislav Lhotka wrote: > > If the "config" statement really carried some protocol-specific semantics that isn't meaningful for all potential uses of YANG, it would be better to remove it from core YANG and define it as an extension that would be mandatory for configuration protocols that need it. > YANG exists because we wanted to describe and manage configurations. And some people still want to do this. I understand that you want to turn YANG into a general purpose data modeling language. But I am not sure this is consensus. As of today, config true means what is defined in RFC 6020 and RFC 7950. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 21 03:36:29 2017 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 2D7BB129445 for ; Tue, 21 Mar 2017 03:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNjhp0Js5PwM for ; Tue, 21 Mar 2017 03:36:26 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8685B129483 for ; Tue, 21 Mar 2017 03:36:26 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 328D61AE0310; Tue, 21 Mar 2017 11:36:24 +0100 (CET) Date: Tue, 21 Mar 2017 11:36:29 +0100 (CET) Message-Id: <20170321.113629.1388013607646336532.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20170321102533.GC35449@elstar.local> References: <20170321102533.GC35449@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 10:36:28 -0000 Juergen Schoenwaelder wrote: > Hi, > > if we want to standardize tree diagrams, we may want to take a more > critical look at them, in particular the flags (that were created > ad-hoc and in resemblance to MIB tree diagrams). pyang --tree-help > says: > > is one of: > rw for configuration data > ro for non-configuration data > -x for rpcs and actions > -n for notifications > > This is (a) incomlete and (b) somewhat confusing since ct does not > equate to readwrite. I am attaching a sample yang file and here is the > output pyang 1.7.1 produces: > > module: tree-sample > +--rw config-true-container > | +--rw param? string > +--ro config-false-container > | +--ro value? string > +--rw inline-action > | +---x action > | +---- oops? string > | +---w input > | | +---w in? string > | +--ro output > | +--ro out? string > +--rw inline-notification > +---n notification > +---- duration? string > > rpcs: > +---x rpc > +---w input > | +---w in? string > +--ro output > | +--ro out? string > +--ro oops? string > > notifications: > +---n notification > +--ro boom? string > > I think a better usage of two letter flags would have been this (since > it more naturally aligns with what the YANG definition says): > > is one of: > ct for configuration data > cf for non-configuration data > x- for rpcs and actions > xi for rpc or action input > xo for rpc or action output > n- for notifications > nt for notification tree (this is I think the term 7950 uses) I'm fine with this, but perhaps use "no" for notification data - "t" means "true" in "ct". Also, in a grouping like this: grouping my-grouping { leaf param { type string; } } pyang prints this as: my-grouping +---- param? string i.e., w/o any flags. > (And I think the oops leafs should have triggered an error.) They did. To stderr. /martin From nobody Tue Mar 21 03:41:29 2017 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 51FBB1296D8 for ; Tue, 21 Mar 2017 03:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 4sp0toNYFqUw for ; Tue, 21 Mar 2017 03:41:27 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 183051296DA for ; Tue, 21 Mar 2017 03:41:27 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 41E51E301A1 for ; Tue, 21 Mar 2017 11:41:23 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 105E8E3009E for ; Tue, 21 Mar 2017 11:41:23 +0100 (CET) Received: from [10.193.71.135] (10.193.71.135) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 21 Mar 2017 11:41:22 +0100 To: References: <20170321102533.GC35449@elstar.local> From: Thomas Morin Organization: Orange Message-ID: Date: Tue, 21 Mar 2017 11:41:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170321102533.GC35449@elstar.local> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 10:41:28 -0000 Hi Juergen, (Just glancing through the list, and by chance reading this particular email) Juergen Schoenwaelder : > cf for non-configuration data I think using "cf" to mean "non-configuration" is likely to end up being misleading, because "cf" is in other contexts sometimes used as a shorthand for "configuration". -Thomas From nobody Tue Mar 21 03:44:20 2017 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 75019129483 for ; Tue, 21 Mar 2017 03:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 r_FSQoipjVmY for ; Tue, 21 Mar 2017 03:44:17 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07EEF124217 for ; Tue, 21 Mar 2017 03:44:17 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:d20:8e4d:8768:16f6] (unknown [IPv6:2001:718:1a02:1:d20:8e4d:8768:16f6]) by mail.nic.cz (Postfix) with ESMTPSA id 637AF6090C; Tue, 21 Mar 2017 11:44:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490093055; bh=dg4YyYxGwK2JWLsA5WBO0nb49Pp6tLEJhTJDPF17qzM=; h=From:Date:To; b=C8ueIO6ruoA9NwS5dNi6HnDI4Wyyr3Ljsq/Zap5FHKuLU52yT3tMtE4rktJGExqlE yioaLcdqxKP/i4iZ/WoeW6WQoSCfUvkLexUtJsDMHltkLa6AA6oJ6UA0frwW/mYfYw 6v5AZvjMHfnHrHtD35pr0UwlFpb9XOy0TiGDghFY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170321103039.GA35688@elstar.local> Date: Tue, 21 Mar 2017 11:44:15 +0100 Cc: Robert Wilton , Mehmet Ersue , Lou Berger , netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5796C093-A399-4A91-BA64-37043242AB1A@nic.cz> References: <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> <20170321080422.GB35044@elstar.local> <0298C599-E206-4777-A95C-5F58E0D519AA@nic.cz> <20170321094313.GA35449@elstar.local> <3B788B04-4728-45FC-86A7-33A9F4D5CF98@nic.cz> <20170321103039.GA35688@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 10:44:19 -0000 > On 21 Mar 2017, at 11:30, Juergen Schoenwaelder = wrote: >=20 > On Tue, Mar 21, 2017 at 10:59:11AM +0100, Ladislav Lhotka wrote: >>=20 >> If the "config" statement really carried some protocol-specific = semantics that isn't meaningful for all potential uses of YANG, it would = be better to remove it from core YANG and define it as an extension that = would be mandatory for configuration protocols that need it. >>=20 >=20 > YANG exists because we wanted to describe and manage configurations. = And ... and operations and notifications where config true/false is already = meaningless. > some people still want to do this. I understand that you want to turn = YANG > into a general purpose data modeling language. But I am not sure this = is In reality, YANG has already been used as such quite a few times (not by = me), mainly because it can define a schema of tree-like data in a = representation-independent way, and there is no adequate substitute. = Doing so in the current state of affairs means selectively ignoring some = parts of RFC 7950, and creatively interpreting other parts. This is IMO = not good. Lada > consensus. As of today, config true means what is defined in RFC 6020 > and RFC 7950. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 21 03:49:35 2017 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 24E23129676 for ; Tue, 21 Mar 2017 03:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 p1fYY8EqUGZx for ; Tue, 21 Mar 2017 03:49:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331A11293F3 for ; Tue, 21 Mar 2017 03:49:32 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:d20:8e4d:8768:16f6] (unknown [IPv6:2001:718:1a02:1:d20:8e4d:8768:16f6]) by mail.nic.cz (Postfix) with ESMTPSA id D195E6090C; Tue, 21 Mar 2017 11:49:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490093370; bh=UJz4e9shuKdcyJ1gBzNCz7VMIEQ/DSNa9zH9RXy6u8A=; h=From:Date:To; b=GemLrxzUmh6qEBfBcVHSc1CAf7M+4FtTpRmBV3KDwBbQpsDpkM5YwgLGG0ZAYjvuQ eRyNiOMMn9Mi6rJDiBAwgLS5Lpx0k1ewzXp1FS7JGw8Jh2CPRtcME1ohpaVKbeDeVQ T3NWQ7gQRMwTCRjjXWkRX9I3ZDKLqYVtZjBhCfE4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170321102533.GC35449@elstar.local> Date: Tue, 21 Mar 2017 11:49:30 +0100 Cc: netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <05D066C2-08AA-4140-9399-87654141F821@nic.cz> References: <20170321102533.GC35449@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 10:49:34 -0000 > On 21 Mar 2017, at 11:25, Juergen Schoenwaelder = wrote: >=20 > Hi, >=20 > if we want to standardize tree diagrams, we may want to take a more > critical look at them, in particular the flags (that were created > ad-hoc and in resemblance to MIB tree diagrams). pyang --tree-help > says: >=20 > is one of: > rw for configuration data > ro for non-configuration data > -x for rpcs and actions > -n for notifications >=20 > This is (a) incomlete and (b) somewhat confusing since ct does not > equate to readwrite. I am attaching a sample yang file and here is the > output pyang 1.7.1 produces: >=20 > module: tree-sample > +--rw config-true-container > | +--rw param? string > +--ro config-false-container > | +--ro value? string > +--rw inline-action > | +---x action > | +---- oops? string > | +---w input > | | +---w in? string > | +--ro output > | +--ro out? string > +--rw inline-notification > +---n notification > +---- duration? string >=20 > rpcs: > +---x rpc > +---w input > | +---w in? string > +--ro output > | +--ro out? string > +--ro oops? string >=20 > notifications: > +---n notification > +--ro boom? string >=20 > I think a better usage of two letter flags would have been this (since > it more naturally aligns with what the YANG definition says): >=20 > is one of: > ct for configuration data > cf for non-configuration data > x- for rpcs and actions > xi for rpc or action input > xo for rpc or action output > n- for notifications > nt for notification tree (this is I think the term 7950 uses) Inside notifications and operations, "cf" carries no information and = just clutters the output. My suggestion is to use "ct" or just "c" for = config=3Dtrue data and nothing elsewhere. Lada >=20 > module: tree-sample > +--ct config-true-container > | +--ct param? string > +--cf config-false-container > | +--cf value? string > +--ct inline-action > | +--x- action > | +--xi input > | | +--xi in? string > | +--xo output > | +--xo out? string > +--ct inline-notification > +--n- notification > +--nt duration? string >=20 > rpcs: > +--x- rpc > +--xi input > | +--xi in? string > +--ro output > +--xo out? string >=20 > notifications: > +--n- notification > +--nt boom? string >=20 > (And I think the oops leafs should have triggered an error.) >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 21 04:32:47 2017 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 B2CD21296FF for ; Tue, 21 Mar 2017 04:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 DmoC14kYq_A8 for ; Tue, 21 Mar 2017 04:32:45 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD42F1296FA for ; Tue, 21 Mar 2017 04:32:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B50A6AF5; Tue, 21 Mar 2017 12:32:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NjAbtr0sxtjv; Tue, 21 Mar 2017 12:32:42 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Mar 2017 12:32:43 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A47A20038; Tue, 21 Mar 2017 12:32:43 +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 AiSIAu7W7JLD; Tue, 21 Mar 2017 12:32:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D772820036; Tue, 21 Mar 2017 12:32:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1647B3EF11D9; Tue, 21 Mar 2017 12:32:46 +0100 (CET) Date: Tue, 21 Mar 2017 12:32:46 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: netmod@ietf.org Message-ID: <20170321113246.GA35771@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20170321102533.GC35449@elstar.local> <20170321.113629.1388013607646336532.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170321.113629.1388013607646336532.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 11:32:47 -0000 On Tue, Mar 21, 2017 at 11:36:29AM +0100, Martin Bjorklund wrote: > > I think a better usage of two letter flags would have been this (since > > it more naturally aligns with what the YANG definition says): > > > > is one of: > > ct for configuration data > > cf for non-configuration data > > x- for rpcs and actions > > xi for rpc or action input > > xo for rpc or action output > > n- for notifications > > nt for notification tree (this is I think the term 7950 uses) > > I'm fine with this, but perhaps use "no" for notification data - "t" > means "true" in "ct". I once had nd (notification data) but then in the last moment moved to nt since 7950 uses the term notification tree... > Also, in a grouping like this: > > grouping my-grouping { > leaf param { type string; } > } > > pyang prints this as: > > my-grouping > +---- param? string > > i.e., w/o any flags. > This makes sense, it just needs to get documented... > > (And I think the oops leafs should have triggered an error.) > > They did. To stderr. Oops, my fault. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 21 04:50:56 2017 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 E4F74129722 for ; Tue, 21 Mar 2017 04:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 KkSu-X6ud33h for ; Tue, 21 Mar 2017 04:50:53 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4110D129486 for ; Tue, 21 Mar 2017 04:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4323; q=dns/txt; s=iport; t=1490097052; x=1491306652; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=tFZnOemfEH/cShKl1VIttdoWepyc5zro1tx/CZ0QdAs=; b=YiP23dlwBNgqvZf56KczrTLoEpqBpalhzVma8z+JNwMvEfLCfO2O8Pvn dJps830RNJ2rMUkTGLbGQwMRbQBZL4xuXzpYUfHPPaDtjVK5Mdyqlpqod gnH6CoevMnQbPCvHjtoJTy203R9f1jTUHIO3/MTr2oGchszy+eOZfslJP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BnAQCZEtFY/xbLJq1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQyKmCNcnOQSx+VRIIOHwuFLkoCg04YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQECAQEBNi8HCw4CCxAILhsMMAYBDAYCAQGJeAgOrGCKUQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR0FhkmCBQiCYoR1CxuFHgWcTpJGileGVotMiBIfOIEEIxYIFxV?= =?us-ascii?q?BhldANYlBAQEB?= X-IronPort-AV: E=Sophos;i="5.36,198,1486425600"; d="scan'208";a="693138834" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2017 11:50:50 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2LBooqm007508; Tue, 21 Mar 2017 11:50:50 GMT To: Ladislav Lhotka , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= References: <20170321102533.GC35449@elstar.local> <05D066C2-08AA-4140-9399-87654141F821@nic.cz> Cc: netmod@ietf.org From: Robert Wilton Message-ID: <70eb5dec-2b98-5e14-0150-0ee3e55ae99f@cisco.com> Date: Tue, 21 Mar 2017 11:50:49 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <05D066C2-08AA-4140-9399-87654141F821@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 11:50:55 -0000 On 21/03/2017 10:49, Ladislav Lhotka wrote: >> On 21 Mar 2017, at 11:25, Juergen Schoenwaelder wrote: >> >> Hi, >> >> if we want to standardize tree diagrams, we may want to take a more >> critical look at them, in particular the flags (that were created >> ad-hoc and in resemblance to MIB tree diagrams). pyang --tree-help >> says: >> >> is one of: >> rw for configuration data >> ro for non-configuration data >> -x for rpcs and actions >> -n for notifications >> >> This is (a) incomlete and (b) somewhat confusing since ct does not >> equate to readwrite. I am attaching a sample yang file and here is the >> output pyang 1.7.1 produces: >> >> module: tree-sample >> +--rw config-true-container >> | +--rw param? string >> +--ro config-false-container >> | +--ro value? string >> +--rw inline-action >> | +---x action >> | +---- oops? string >> | +---w input >> | | +---w in? string >> | +--ro output >> | +--ro out? string >> +--rw inline-notification >> +---n notification >> +---- duration? string >> >> rpcs: >> +---x rpc >> +---w input >> | +---w in? string >> +--ro output >> | +--ro out? string >> +--ro oops? string >> >> notifications: >> +---n notification >> +--ro boom? string >> >> I think a better usage of two letter flags would have been this (since >> it more naturally aligns with what the YANG definition says): >> >> is one of: >> ct for configuration data >> cf for non-configuration data >> x- for rpcs and actions >> xi for rpc or action input >> xo for rpc or action output >> n- for notifications >> nt for notification tree (this is I think the term 7950 uses) > Inside notifications and operations, "cf" carries no information and just clutters the output. My suggestion is to use "ct" or just "c" for config=true data and nothing elsewhere. Do, we also actually need the 'xi', 'xo', or 'nt' at all? Would these be obvious from the paths anyway? I think that having less symbols on the diagram may make it easier to parse, and perhaps less likely for the lines to wrap. So I am suggesting perhaps just having: is one of: c for configuration data x for rpcs and actions n for notifications module: tree-sample +--c config-true-container | +--c param? string +--- config-false-container | +-- value? string +--c inline-action | +--x- action | +--x input | | +--x in? string | +--x output | +--x out? string +--c inline-notification +--n notification +--n duration? string etc. Rob > > Lada > >> module: tree-sample >> +--ct config-true-container >> | +--ct param? string >> +--cf config-false-container >> | +--cf value? string >> +--ct inline-action >> | +--x- action >> | +--xi input >> | | +--xi in? string >> | +--xo output >> | +--xo out? string >> +--ct inline-notification >> +--n- notification >> +--nt duration? string >> >> rpcs: >> +--x- rpc >> +--xi input >> | +--xi in? string >> +--ro output >> +--xo out? string >> >> notifications: >> +--n- notification >> +--nt boom? string >> >> (And I think the oops leafs should have triggered an error.) >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Mar 21 05:02:04 2017 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 43B4B1296DB for ; Tue, 21 Mar 2017 05:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 Tc6JJoBUTOpb for ; Tue, 21 Mar 2017 05:02:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539DE1297A5 for ; Tue, 21 Mar 2017 05:02:00 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:d20:8e4d:8768:16f6] (unknown [IPv6:2001:718:1a02:1:d20:8e4d:8768:16f6]) by mail.nic.cz (Postfix) with ESMTPSA id 7815C60190; Tue, 21 Mar 2017 13:01:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490097718; bh=VbztdLzJ5n0uWcsjco68YEkwrwXaVfEnk322tLYbCDs=; h=From:Date:To; b=rGKJ/Vw6eAHrwCeGulLSv30WZjlmPUyzx7lE6z2beiUC7qwWhc5Wnf1iqZiNTzgZ9 Phk86wRevqa9E+ImUgjwgeXwl0BtmEs30uHDtlC7YJ+cmAhvr9VRVdLYdfXQgEIRSY AM9PWiDLNiE9IceT3tV7oR/1KlUmYZql3ubPGpGw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <70eb5dec-2b98-5e14-0150-0ee3e55ae99f@cisco.com> Date: Tue, 21 Mar 2017 13:01:58 +0100 Cc: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170321102533.GC35449@elstar.local> <05D066C2-08AA-4140-9399-87654141F821@nic.cz> <70eb5dec-2b98-5e14-0150-0ee3e55ae99f@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 12:02:03 -0000 > On 21 Mar 2017, at 12:50, Robert Wilton wrote: >=20 >=20 >=20 > On 21/03/2017 10:49, Ladislav Lhotka wrote: >>> On 21 Mar 2017, at 11:25, Juergen Schoenwaelder = wrote: >>>=20 >>> Hi, >>>=20 >>> if we want to standardize tree diagrams, we may want to take a more >>> critical look at them, in particular the flags (that were created >>> ad-hoc and in resemblance to MIB tree diagrams). pyang --tree-help >>> says: >>>=20 >>> is one of: >>> rw for configuration data >>> ro for non-configuration data >>> -x for rpcs and actions >>> -n for notifications >>>=20 >>> This is (a) incomlete and (b) somewhat confusing since ct does not >>> equate to readwrite. I am attaching a sample yang file and here is = the >>> output pyang 1.7.1 produces: >>>=20 >>> module: tree-sample >>> +--rw config-true-container >>> | +--rw param? string >>> +--ro config-false-container >>> | +--ro value? string >>> +--rw inline-action >>> | +---x action >>> | +---- oops? string >>> | +---w input >>> | | +---w in? string >>> | +--ro output >>> | +--ro out? string >>> +--rw inline-notification >>> +---n notification >>> +---- duration? string >>>=20 >>> rpcs: >>> +---x rpc >>> +---w input >>> | +---w in? string >>> +--ro output >>> | +--ro out? string >>> +--ro oops? string >>>=20 >>> notifications: >>> +---n notification >>> +--ro boom? string >>>=20 >>> I think a better usage of two letter flags would have been this = (since >>> it more naturally aligns with what the YANG definition says): >>>=20 >>> is one of: >>> ct for configuration data >>> cf for non-configuration data >>> x- for rpcs and actions >>> xi for rpc or action input >>> xo for rpc or action output >>> n- for notifications >>> nt for notification tree (this is I think the term 7950 uses) >> Inside notifications and operations, "cf" carries no information and = just clutters the output. My suggestion is to use "ct" or just "c" for = config=3Dtrue data and nothing elsewhere. > Do, we also actually need the 'xi', 'xo', or 'nt' at all? Would these = be obvious from the paths anyway? Yes, "input" and "output" tells everything. >=20 > I think that having less symbols on the diagram may make it easier to = parse, and perhaps less likely for the lines to wrap. +1 >=20 > So I am suggesting perhaps just having: >=20 > is one of: > c for configuration data > x for rpcs and actions > n for notifications >=20 > module: tree-sample > +--c config-true-container > | +--c param? string > +--- config-false-container > | +-- value? string > +--c inline-action > | +--x- action > | +--x input > | | +--x in? string > | +--x output > | +--x out? string > +--c inline-notification > +--n notification > +--n duration? string >=20 I think the "x" and "n" is only needed next to the name of = rpc/action/notification. So my version would be: is one of: c for configuration data x for rpcs and actions n for notifications module: tree-sample +--c config-true-container | +--c param? string +--- config-false-container | +--- value? string +--c inline-action | +--x action | +--- input | | +--- in? string | +--- output | +--- out? string +--c inline-notification +--n notification +--- duration? string Lada > etc. >=20 > Rob >=20 >=20 >>=20 >> Lada >>=20 >>> module: tree-sample >>> +--ct config-true-container >>> | +--ct param? string >>> +--cf config-false-container >>> | +--cf value? string >>> +--ct inline-action >>> | +--x- action >>> | +--xi input >>> | | +--xi in? string >>> | +--xo output >>> | +--xo out? string >>> +--ct inline-notification >>> +--n- notification >>> +--nt duration? string >>>=20 >>> rpcs: >>> +--x- rpc >>> +--xi input >>> | +--xi in? string >>> +--ro output >>> +--xo out? string >>>=20 >>> notifications: >>> +--n- notification >>> +--nt boom? string >>>=20 >>> (And I think the oops leafs should have triggered an error.) >>>=20 >>> /js >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 21 06:16:19 2017 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 29B51129887 for ; Tue, 21 Mar 2017 06:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no 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 dxa_-GLpL3u8 for ; Tue, 21 Mar 2017 06:16:12 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 3F3F9129883 for ; Tue, 21 Mar 2017 06:16:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.19.173; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Kent Watsen'" Cc: References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> <20170319181630.GA32188@elstar.local> In-Reply-To: <20170319181630.GA32188@elstar.local> Date: Tue, 21 Mar 2017 09:11:14 -0400 Message-ID: <01c401d2a244$9ec40cd0$dc4c2670$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG1PX+MajibuVZNczJen6sKKO4mzQKRYuQPAo0/3dwBnjEZCwGuGnaSAPPjp22hjxeSwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 13:16:14 -0000 +1 to Juergen's point on a separate module list. Sue -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Sunday, March 19, 2017 2:17 PM To: Kent Watsen Cc: netmod@ietf.org Subject: Re: [netmod] some comments on revised-datastores-01 On Sun, Mar 19, 2017 at 06:11:35PM +0000, Kent Watsen wrote: > > Wait, I think you're mixing things up. I'm not talking about using YANG Library to identify which datastores a module can be accessed in, so much as knowing which datastores are implemented in the first place. > > For instance, assuming the "ephemeral" datastore example example in the draft, a client knows a server implements it because ietf-ds-ephemeral is listed in YANG Library. And so it is with all dynamic datastores, but not so for built-in (non-dynamic) datastores (e.g. intended) because there isn't a module to advertise for them (yet). > Obviously, relying on module names does not work if a module defines multiple datastores. So either the set of datastores is identified from reading the whole yang-library list or we provide a separate list (and I think we should provide a separate list). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 21 06:22:16 2017 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 95234129493 for ; Tue, 21 Mar 2017 06:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 PLECKhMRVuJO for ; Tue, 21 Mar 2017 06:22:13 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 57EAF12989D for ; Tue, 21 Mar 2017 06:22:13 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-05v.sys.comcast.net with SMTP id qJiNchQOaygj9qJjocvoyr; Tue, 21 Mar 2017 13:22:12 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-02v.sys.comcast.net with SMTP id qJjmca3YLgFBHqJjnc93fg; Tue, 21 Mar 2017 13:22:12 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2LDM9xZ030580; Tue, 21 Mar 2017 09:22:09 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2LDM8XV030576; Tue, 21 Mar 2017 09:22:08 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Ladislav Lhotka Cc: rwilton@cisco.com, netmod@ietf.org In-Reply-To: (lhotka@nic.cz) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 21 Mar 2017 09:22:07 -0400 Message-ID: <87a88evk74.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfHGaGdee0gyxPdeqh1eksqFoLxXOA0Yxq50hKFySNo61DpwssqTerrtNLr+2L59aorIX6vrzdmOVqimQFDUzB6UlpuKEVaqqZoA6hL4FPF+jnlub17Jj u2bdMPwWAz693IE0uZsvRi4vcdEIHtasnDNJNPNtSSFKXTEx0Rfx0d7HvdfcPExW2K0CONN1RCc+7uzdVRL09m0dAGdQZPShNW8= Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 13:22:15 -0000 Ladislav Lhotka writes: > I think the "x" and "n" is only needed next to the name of rpc/action/notification. So my version would be: > > is one of: > c for configuration data > x for rpcs and actions > n for notifications > > module: tree-sample > +--c config-true-container > | +--c param? string > +--- config-false-container > | +--- value? string > +--c inline-action > | +--x action > | +--- input > | | +--- in? string > | +--- output > | +--- out? string > +--c inline-notification > +--n notification > +--- duration? string Naively, it seems to me that "c" for configuration and "s" for state makes a great deal of sense. ("cf" for state ("config=false") is hazardous as "cf" is a natural contraction of "configuration".) config/state is a somewhat messy distinction as the transition between them can happen anywhere in the tree. For RPCs, actions, and notifications, using a flag only for their top nodes makes sense, because that makes it easy to find their top nodes, and any node under them can only be assessed based on where it is relative to the top node. One thing that threw me the first time I saw it is marking lists with "*". That doesn't match the generic use of "*", which is to mark the thing that is repeated. (Compare using "?" to mark an optional thing, which does match the generic usage.) But in the context of Yang, you don't want to flag the items in the list with "*", that would make the tree harder to read. I support having a rigid and consistent standard for indentation and where the descending lines are placed under the parent nodes -- consistency in formatting allows one to train one's eye to parse the diagram reflexively rather than having to pause and mentally group the items into a structure. Dale From nobody Tue Mar 21 06:24:31 2017 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 8DD4F129408 for ; Tue, 21 Mar 2017 06:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no 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 2Xii8k9Ehmr4 for ; Tue, 21 Mar 2017 06:24:28 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 1CAC9126D73 for ; Tue, 21 Mar 2017 06:24:28 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.19.173; From: "Susan Hares" To: "'Kent Watsen'" , "'Juergen Schoenwaelder'" Cc: References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> <20170319181630.GA32188@elstar.local> <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> <20170320062722.GA32956@elstar.local> <79DEF6A3-F1AE-45C9-A88F-14796FEF884C@juniper.net> <20170320141729.GA33652@elstar.local> <4FAE1F8E-5449-4761-9950-41956A1CB7CB@juniper.net> <20170320144335.GB33724@elstar.local> In-Reply-To: Date: Tue, 21 Mar 2017 09:19:29 -0400 Message-ID: <01de01d2a245$c5fc86f0$51f594d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKRYuQPsfUj8cjCteu4rA5epEpzywKNP93cAZ4xGQsBrhp2kgDz46dtAfyVlhgDI1wCpgFJmEJcAh/Z0joCDA8GdQJbGrlLAPJKKe6ffELlAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 13:24:29 -0000 Kent and Juergen: To summarize your messages: a) a global datastore list b) Each datastore contains a list of modules it contains (currently done) c) Each module contains a list of datastores it supports. Is this correct? Or did I misunderstand. Sue -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Monday, March 20, 2017 1:09 PM To: Juergen Schoenwaelder Cc: netmod@ietf.org Subject: Re: [netmod] some comments on revised-datastores-01 > I believe this is the wrong direction, even if we rewrite the module > in the revised datastores document and split it into multiple modules. > A simple list of implemented datastores is cheap. It is flexible. It > does not require explanations and rules how definitions must be split > into modules that finally must be remembered and checked still in 5-10 > years from now. I firmly believe that these types of 'optimizations' > lead to creeping complexity down the road. Lets not create CLRs how > modules must be structued, named, etc. That's a better answer. At least now I get the sense that you actually understood what I was saying. As for your proposal, I agree with you that it would be best to have an explicit list. I assume that this would be another proposed change to YANG Library (i.e., Section D.2 in the revised-datastores draft). It will be tricky to enforce the use of this version of YANG Library in RESTCONF without a -bis document... K. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 21 06:33:40 2017 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 552C21298BF for ; Tue, 21 Mar 2017 06:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcEtK36Fj89C for ; Tue, 21 Mar 2017 06:33:33 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1311298B7 for ; Tue, 21 Mar 2017 06:33:33 -0700 (PDT) Received: from [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360] (unknown [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id E4A5320088 for ; Tue, 21 Mar 2017 14:33:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1490103210; bh=+8hYKaaCJUklR9pRBbF1xoWyNeepTINilpZWLOFHf/Y=; h=From:Subject:To:Date; b=f1KuwkQEJLc+j4ZzfM1fShP+/DhSR2TNW65vyEbkrzR7MGmmzeLPYidznfCpjOx8F IY0VtiPH5jxml+FQ+Ox2wauu49sfsi1JuG7aafp4bE1GnRYZRHbQ4d+H+CUairW0FW +1RJHipWMZ10OuuGnGaxPs6fDELUwtix2VGsOfls= From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= To: "netmod@ietf.org" Message-ID: Date: Tue, 21 Mar 2017 14:32:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netmod] tree diagrams - prefixes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 13:33:36 -0000 Hi, I have another note regarding the standardization of tree diagrams - the = is not clearly defined. pyang --tree-help says: is the name of the node () means that the node is a choice node :() means that the node is a case node If the node is augmented into the tree from another module, its name is printed as :. pyang uses the prefix value from the import statement in the module being= printed. This approach can result in confusing output when e.g. module a= nd its submodule import a) same module with different prefixes or b) diff= erent modules with a same prefix. However, not even use of the prefix def= ined in the module itself solve the issue. YANG has no requirement for th= e module prefixes, so they can repeat in different modules. The solution I see here, and which is actually already used in JSON encod= ing of YANG modeled data, is using module names as prefixes. This approac= h is also implemented in yanglint (there was no standardization of the tr= ee format, so as developers we have decided to slightly modify the format= in comparison to what is printed by pyang). The price for the exactness = is the width of the output - prefixes used to be shorter than the full mo= dule names. Regards, Radek From nobody Tue Mar 21 06:43:57 2017 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 22CDF12948A for ; Tue, 21 Mar 2017 06:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKnkLlgeENdj for ; Tue, 21 Mar 2017 06:43:47 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8123B129408 for ; Tue, 21 Mar 2017 06:43:47 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 8F0701AE0310; Tue, 21 Mar 2017 14:43:46 +0100 (CET) Date: Tue, 21 Mar 2017 14:43:53 +0100 (CET) Message-Id: <20170321.144353.1304796463767741047.mbj@tail-f.com> To: worley@ariadne.com Cc: lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <87a88evk74.fsf@hobgoblin.ariadne.com> References: <87a88evk74.fsf@hobgoblin.ariadne.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] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 13:43:56 -0000 worley@ariadne.com (Dale R. Worley) wrote: > One thing that threw me the first time I saw it is marking lists with > "*". That doesn't match the generic use of "*", which is to mark the > thing that is repeated. Hmm, "*" was choosen b/c people are used to read it as "zero or more". So for example: +---c server* [name] +--c name string ... means zero or more "server" elements. Each indexed by "name". > (Compare using "?" to mark an optional thing, > which does match the generic usage.) But in the context of Yang, you > don't want to flag the items in the list with "*", that would make the > tree harder to read. What is an "item in the list"? /martin From nobody Tue Mar 21 06:52:53 2017 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 55179126DED for ; Tue, 21 Mar 2017 06:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 PYSF_o0wtRT9 for ; Tue, 21 Mar 2017 06:52:49 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307DD126DEE for ; Tue, 21 Mar 2017 06:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1999; q=dns/txt; s=iport; t=1490104369; x=1491313969; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=cZGKb2ilKtQLrpPYWXFgvVhR/OhJiEsF/fPbzn8bEcM=; b=VVPAI4ijS+Mku4nTgIb8Fc9Vd8Z209eyJQOZwDtxfVzp0ZKacKF5H6yX 4IQLF/9v3CQH8ypoyGnwbMnnu0r8HzhDeFegazgptd82OhjgWGm/bfjI+ 5nUWN0pVH2X/2FTIhUh6ffGFurRX263HJgbG6zK2rHbt8RO+n6q2SaiNO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAwDkLtFY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqYINiihBzkGyVRIIOHwuFLkoCg1EYAQIBAQEBAQEBayiFFgE?= =?us-ascii?q?BAQMBASEECwEFNhsJAhgCAiYCAicwBgEMBgIBAReJaQ6NBZ1bgWw6ilMBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYELhUOCBYJqh1qCXwEEj12Mc5JGileGVotNiBI?= =?us-ascii?q?fOIEEIxYIFxVBhldANYlBAQEB?= X-IronPort-AV: E=Sophos;i="5.36,198,1486425600"; d="scan'208";a="650577660" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2017 13:52:47 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2LDqkFp009093; Tue, 21 Mar 2017 13:52:47 GMT To: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= , "netmod@ietf.org" References: From: Robert Wilton Message-ID: <61bd410a-e600-2b83-57c4-058d999a9447@cisco.com> Date: Tue, 21 Mar 2017 13:52:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] tree diagrams - prefixes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 13:52:51 -0000 Hi Radek, I think that using the full module name might make the lines too long. Perhaps the tree output could separately list the prefix to module mapping, and ensure that the prefix names are unique in the diagram (e.g. adding a number to the prefix name if it clashes). Prefix to module map: if -> ietf-interfaces ip -> ietf-ip ip2 -> ietf-ip @ 2017-03-21 ... where, if no revision number is specified then the import is for any revision. Thanks, Rob On 21/03/2017 13:32, Radek KrejÄí wrote: > Hi, > > I have another note regarding the standardization of tree diagrams - the is not clearly defined. pyang --tree-help says: > > is the name of the node > () means that the node is a choice node > :() means that the node is a case node > > If the node is augmented into the tree from another module, its > name is printed as :. > > pyang uses the prefix value from the import statement in the module being printed. This approach can result in confusing output when e.g. module and its submodule import a) same module with different prefixes or b) different modules with a same prefix. However, not even use of the prefix defined in the module itself solve the issue. YANG has no requirement for the module prefixes, so they can repeat in different modules. > > The solution I see here, and which is actually already used in JSON encoding of YANG modeled data, is using module names as prefixes. This approach is also implemented in yanglint (there was no standardization of the tree format, so as developers we have decided to slightly modify the format in comparison to what is printed by pyang). The price for the exactness is the width of the output - prefixes used to be shorter than the full module names. > > Regards, > Radek > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Mar 21 06:55:09 2017 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 74D26129871 for ; Tue, 21 Mar 2017 06:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no 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 G7NwP7pIfcM9 for ; Tue, 21 Mar 2017 06:55:06 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 C5366129494 for ; Tue, 21 Mar 2017 06:55:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.19.173; From: "Susan Hares" To: "'Ladislav Lhotka'" , =?iso-8859-1?Q?'J=FCrgen_Sch=F6nw=E4lder'?= Cc: References: <02e701d29d93$0e770480$2b650d80$@gmail.com> <20170316064419.GA59114@elstar.local> <15ad6df64e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <000f01d29f21$8fe93c10$afbbb430$@gmail.com> <2748e6e6-5d16-05e9-0ce5-bc2b3a7e69cc@cisco.com> <562b9d03-dc1a-3741-8be7-c33afd7d74c4@cisco.com> <4D1DE368-9B3D-478B-BE06-C5ED9A88B8F8@nic.cz> <20170321080422.GB35044@elstar.local> <0298C599-E206-4777-A95C-5F58E0D519AA@nic.cz> <20170321094313.GA35449@elstar.local> <3B788B04-4728-45FC-86A7-33A9F4D5CF98@nic.cz> In-Reply-To: <3B788B04-4728-45FC-86A7-33A9F4D5CF98@nic.cz> Date: Tue, 21 Mar 2017 09:33:18 -0400 Message-ID: <01e001d2a247$b3f94040$1bebc0c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG++dA875RmoxzbDZSXLnl5Jx5YSAF+jVm3AXSML+0Bm+Ek1gGgPefFAdZ3URsChzyXlQFia/DuAYSBidACgeO4eALGZbsxAd2g6dKhIcwPkA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 13:55:07 -0000 Lada:=20 As dynamic control plane datastores start-up, these will need to go from = an initial state to a "current state". I2RS ephemeral dynamic control = plane datastores will have a model that comes up in a limited mode with the = I2RS agent's configuration. The rest of the configuration will be update = from a client over the network. You are correct that the RFC6241 definition = does not cover this state. The I2RS concept does cover "Config=3DTRUE" being = the test of configuration. I think this is the same test that applies = because configuration data can be updated even in the configuration datastore (intended to applied).=20 Good catch on the definition.=20 Sue=20 -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav = Lhotka Sent: Tuesday, March 21, 2017 5:59 AM To: J=FCrgen Sch=F6nw=E4lder Cc: netmod@ietf.org Subject: Re: [netmod] draft netmod charter update proposal > On 21 Mar 2017, at 10:43, Juergen Schoenwaelder wrote: >=20 > On Tue, Mar 21, 2017 at 10:13:40AM +0100, Ladislav Lhotka wrote: >>=20 >> The revised-datastores draft changes the semantics of "configuration data" - for example, the definition from RFC 6241 clearly won't apply to = the "running" datastore in the new datastore model. >=20 > Why would that be the case? RFC 6241: o configuration data: The set of writable data that is required to transform a system from its initial default state into its current state. If I understand revised-datastores correctly, this will no more be the = case for "running" because it may contain intermediate data that require = further processing (templates) and inactive data that are not used for changing = the device state. This may look like nit-picking but the fact is that we often use the = term configuration in the sense "you know it when you see it".=20 >=20 >> So a new definition of configuration data will probably be needed, = and this implicitly changes the semantics of the "config" statement. >>=20 >=20 > YANG defines the config statement as follows: >=20 > The "config" statement takes as an argument the string "true" or > "false". If "config" is "true", the definition represents > configuration. Data nodes representing configuration are part of > configuration datastores. If the "config" statement really carried some protocol-specific = semantics that isn't meaningful for all potential uses of YANG, it would be better = to remove it from core YANG and define it as an extension that would be mandatory for configuration protocols that need it. Lada >=20 > I do not think it is the intend of the revised datastore model as=20 > written down in the I-D to change this. >=20 >> BTW, we use rw/ro in tree diagrams. >=20 > Which is a mis-nomer (tree diagrams were inherited from the SNMP world = > and somehow the rw/ro distinction was kept even though it is=20 > technically wrong). There are more details here, I will start a=20 > separate thread for this. >=20 > Note that the diagrams in the revised datastore ID make a clear=20 > distinction between ct/cf and rw/ro. In particular, the ID notes that=20 > ct object may be rw in one datastore but ro in a different datastore. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 21 07:11:32 2017 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 C88C8129705 for ; Tue, 21 Mar 2017 07:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 yUKzyctwPG46 for ; Tue, 21 Mar 2017 07:11:23 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C2F1297E1 for ; Tue, 21 Mar 2017 07:11:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B670D69C; Tue, 21 Mar 2017 15:11:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4H-D6WROBzS7; Tue, 21 Mar 2017 15:11:19 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Mar 2017 15:11:20 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61A6520038; Tue, 21 Mar 2017 15:11:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rjZ3plMTGztA; Tue, 21 Mar 2017 15:11:20 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E526D20036; Tue, 21 Mar 2017 15:11:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 033B83EF201B; Tue, 21 Mar 2017 15:11:23 +0100 (CET) Date: Tue, 21 Mar 2017 15:11:23 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: Robert Wilton , netmod@ietf.org Message-ID: <20170321141123.GB35926@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , Robert Wilton , netmod@ietf.org References: <20170321102533.GC35449@elstar.local> <05D066C2-08AA-4140-9399-87654141F821@nic.cz> <70eb5dec-2b98-5e14-0150-0ee3e55ae99f@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 14:11:31 -0000 On Tue, Mar 21, 2017 at 01:01:58PM +0100, Ladislav Lhotka wrote: > > > On 21 Mar 2017, at 12:50, Robert Wilton wrote: > > > > > > So I am suggesting perhaps just having: > > > > is one of: > > c for configuration data > > x for rpcs and actions > > n for notifications > > > > module: tree-sample > > +--c config-true-container > > | +--c param? string > > +--- config-false-container > > | +-- value? string > > +--c inline-action > > | +--x- action > > | +--x input > > | | +--x in? string > > | +--x output > > | +--x out? string > > +--c inline-notification > > +--n notification > > +--n duration? string > > I think the "x" and "n" is only needed next to the name of rpc/action/notification. So my version would be: > > is one of: > c for configuration data > x for rpcs and actions > n for notifications > > module: tree-sample > +--c config-true-container > | +--c param? string > +--- config-false-container > | +--- value? string > +--c inline-action > | +--x action > | +--- input > | | +--- in? string > | +--- output > | +--- out? string > +--c inline-notification > +--n notification > +--- duration? string > Single character flags work for me as well. Since I have modules with pretty complex RPC inputs (more than a single page in RFC formatting), I think it is useful to be able to see that one is still starting at an RPC input tree and not a regular data tree or a notification tree. So I tend to like Rob's proposal a bit more. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 21 08:55:24 2017 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 7688C1294C8 for ; Tue, 21 Mar 2017 08:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 6tj3Nme9eRKU for ; Tue, 21 Mar 2017 08:55:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AAA41294B7 for ; Tue, 21 Mar 2017 08:55:21 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:84d4:35a4:2461:4431] (unknown [IPv6:2001:718:1a02:1:84d4:35a4:2461:4431]) by mail.nic.cz (Postfix) with ESMTPSA id 6648F603B3; Tue, 21 Mar 2017 16:55:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490111719; bh=R9TKs2LQSUgN0v/TEu9Xkv+ZfX7mwRpSybbVKDn7mEY=; h=From:Date:To; b=smIeYAKuSC7wfLL9Xm2kh7LyOrMtRuKwhazKRWD020NXzk8sQ7DBleacRW9vUUrSH kRlE4D1ffQwSZVbd8mQ6OeMOeVcNzyotghOEKxbP8w5GR+FpIkqmgNgOvNHmxz5zY8 8FZt7vGGv+P0xpsduIfZbIVepGb4gsooXXOt7w6Y= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170321141123.GB35926@elstar.local> Date: Tue, 21 Mar 2017 16:55:18 +0100 Cc: Robert Wilton , netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <628D63D4-0250-4150-BE2A-F90298499473@nic.cz> References: <20170321102533.GC35449@elstar.local> <05D066C2-08AA-4140-9399-87654141F821@nic.cz> <70eb5dec-2b98-5e14-0150-0ee3e55ae99f@cisco.com> <20170321141123.GB35926@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 15:55:23 -0000 > On 21 Mar 2017, at 15:11, Juergen Schoenwaelder = wrote: >=20 > On Tue, Mar 21, 2017 at 01:01:58PM +0100, Ladislav Lhotka wrote: >>=20 >>> On 21 Mar 2017, at 12:50, Robert Wilton wrote: >>>=20 >>>=20 >>> So I am suggesting perhaps just having: >>>=20 >>> is one of: >>> c for configuration data >>> x for rpcs and actions >>> n for notifications >>>=20 >>> module: tree-sample >>> +--c config-true-container >>> | +--c param? string >>> +--- config-false-container >>> | +-- value? string >>> +--c inline-action >>> | +--x- action >>> | +--x input >>> | | +--x in? string >>> | +--x output >>> | +--x out? string >>> +--c inline-notification >>> +--n notification >>> +--n duration? string >>=20 >> I think the "x" and "n" is only needed next to the name of = rpc/action/notification. So my version would be: >>=20 >> is one of: >> c for configuration data >> x for rpcs and actions >> n for notifications >>=20 >> module: tree-sample >> +--c config-true-container >> | +--c param? string >> +--- config-false-container >> | +--- value? string >> +--c inline-action >> | +--x action >> | +--- input >> | | +--- in? string >> | +--- output >> | +--- out? string >> +--c inline-notification >> +--n notification >> +--- duration? string >>=20 >=20 > Single character flags work for me as well. Since I have modules with > pretty complex RPC inputs (more than a single page in RFC formatting), > I think it is useful to be able to see that one is still starting at > an RPC input tree and not a regular data tree or a notification tree. Even with long RPC parameter lists the indentation should make it = obvious what belongs where. Another option might be to label every input = parameter with "xi" or "i" and output with "xo"/"o", and remove the = "input" and "output" nodes. This would make the output shorter and = narrower. > So I tend to like Rob's proposal a bit more. Note however that Rob's proposal doesn't distinguish input and output = parameters, all are labelled with "x". Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 21 09:18:58 2017 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 290EC1294BB for ; Tue, 21 Mar 2017 09:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 zd5b4XE3wAvV for ; Tue, 21 Mar 2017 09:18:50 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0090.outbound.protection.outlook.com [104.47.40.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF0D129B9E for ; Tue, 21 Mar 2017 09:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e0DhYT1gFX8BGLB2fV+6hm3LCNQjxox6WsFYbwMyzf8=; b=HmuEM0w4qJhcySQLMFz28LIqXCcUXCrLW55DyV7/9t3mfVHkY+9pcBQqFT5iYiJ+2k0NcBX9urfqHOUfFWQD0Hri7GA0PmT7c0+fB/v3ztiZr6i0JajCYoPUwtmBoU3t324sswhQopGziBHUFyv7SUMxxhdO7+k6fWM8Y89uiZ8= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Tue, 21 Mar 2017 16:17:47 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0991.013; Tue, 21 Mar 2017 16:17:46 +0000 From: Kent Watsen To: Susan Hares , 'Juergen Schoenwaelder' CC: "netmod@ietf.org" Thread-Topic: [netmod] some comments on revised-datastores-01 Thread-Index: AQHSoB0pC6yqRGsTNE2Jco/Jvjk1RKGb2quAgAA4bM+AAErBAIAAGmtHgAABXwCAABnezIAAsleAgAA81wCAAEaBgP//wCGAgABHLQD//+WigIABlTCA///uwYA= Date: Tue, 21 Mar 2017 16:17:46 +0000 Message-ID: <2DE21F4B-8F5F-473A-A268-42BFB053E490@juniper.net> References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> <20170319181630.GA32188@elstar.local> <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> <20170320062722.GA32956@elstar.local> <79DEF6A3-F1AE-45C9-A88F-14796FEF884C@juniper.net> <20170320141729.GA33652@elstar.local> <4FAE1F8E-5449-4761-9950-41956A1CB7CB@juniper.net> <20170320144335.GB33724@elstar.local> <01de01d2a245$c5fc86f0$51f594d0$@ndzh.com> In-Reply-To: <01de01d2a245$c5fc86f0$51f594d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: ndzh.com; dkim=none (message not signed) header.d=none;ndzh.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:CgbnWT4uf5O3m3dwGR8uX/4Fmwbhq5G2xXu6gFOCn+pZOeJiM8QkPndXDZ9xrjzylVDniL1M0h682NpOqxfk05zk0bVM/dr7ysctgtwassG/WyMWIsjxkhvkuAjc2TDgUfCe7KtGyiVU7m0J6EIXoKfKGiErp7NlRdOgHwyy/H5zqotURR0dwZGvA8CYsz1aZasg1jLAuTMGrmZNcjj3UyPUh6XdfulleG/zpQOaqszUKx8bjboYRt7gZjrErSyyXwqqvuRrXlgtc+/xqabp/HADZ+wSz8eKYOy7y9zp9MEjc4ulIe3KjBLpBuBI2m4Hiu1vzHgAYwM8zmS4gUbuaw== x-ms-office365-filtering-correlation-id: 1e104e9e-c576-46b4-ac19-08d47075d004 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39840400002)(39410400002)(39860400002)(39450400003)(51444003)(377454003)(13464003)(3660700001)(83506001)(82746002)(2906002)(2900100001)(3280700002)(305945005)(83716003)(86362001)(7736002)(8936002)(2950100002)(8676002)(25786009)(81166006)(33656002)(66066001)(561944003)(6306002)(6512007)(77096006)(99286003)(6246003)(38730400002)(4001350100001)(6116002)(3846002)(102836003)(53936002)(36756003)(230783001)(6436002)(5660300001)(93886004)(189998001)(4326008)(50986999)(76176999)(122556002)(229853002)(53546009)(6486002)(6506006)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 21 Mar 2017 16:17:46.8803 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:18:56 -0000 U3VlLA0KDQpJIHRoaW5rIHRoYXQgb25seSAoYykgaXMgImRvbmUiLCBhbmQgZXZlbiB0aGVuIG9u bHkgdG8gdGhlIHBvaW50IHRoYXQgYSBwcm9wb3NhbCBpcyBvZmZlcmVkIGluIHRoZSBhcHBlbmRp eCBELjIgaW4gdGhlIHJldmlzZWQtZGF0YXN0b3JlcyBkcmFmdC4NCg0KKGIpIGhhcyBuZXZlciBi ZWVuIGRpc2N1c3NlZC4NCg0KKGEpIGlzIHdoYXQgdGhpcyByZWNlbnQgZmxhcCBoYXMgYmVlbiBh Ym91dC4gIFdlJ2xsIHNlZSBpZiBpdCdzIGEgbGlzdCBvZiBkYXRhc3RvcmVzIG9yIGNhcGFiaWxp dGllcyBvciBzb21ldGhpbmcgZWxzZS4uLg0KDQpLZW50DQoNCg0KLS0tLS1PUklHSU5BTCBNRVNT QUdFLS0tLS0NCg0KS2VudCBhbmQgSnVlcmdlbjogDQoNClRvIHN1bW1hcml6ZSB5b3VyIG1lc3Nh Z2VzOiANCg0KYSkgYSBnbG9iYWwgZGF0YXN0b3JlIGxpc3QgDQpiKSBFYWNoIGRhdGFzdG9yZSBj b250YWlucyBhIGxpc3Qgb2YgbW9kdWxlcyBpdCBjb250YWlucyAoY3VycmVudGx5IGRvbmUpIA0K YykgRWFjaCBtb2R1bGUgY29udGFpbnMgYSBsaXN0IG9mIGRhdGFzdG9yZXMgaXQgc3VwcG9ydHMu IA0KDQpJcyB0aGlzIGNvcnJlY3Q/ICBPciBkaWQgSSBtaXN1bmRlcnN0YW5kLiANCg0KU3VlIA0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLZW50IFdhdHNlbg0KU2VudDogTW9uZGF5 LCBNYXJjaCAyMCwgMjAxNyAxOjA5IFBNDQpUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyDQpDYzog bmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gc29tZSBjb21tZW50cyBvbiBy ZXZpc2VkLWRhdGFzdG9yZXMtMDENCg0KDQo+IEkgYmVsaWV2ZSB0aGlzIGlzIHRoZSB3cm9uZyBk aXJlY3Rpb24sIGV2ZW4gaWYgd2UgcmV3cml0ZSB0aGUgbW9kdWxlIA0KPiBpbiB0aGUgcmV2aXNl ZCBkYXRhc3RvcmVzIGRvY3VtZW50IGFuZCBzcGxpdCBpdCBpbnRvIG11bHRpcGxlIG1vZHVsZXMu DQo+IEEgc2ltcGxlIGxpc3Qgb2YgaW1wbGVtZW50ZWQgZGF0YXN0b3JlcyBpcyBjaGVhcC4gSXQg aXMgZmxleGlibGUuIEl0IA0KPiBkb2VzIG5vdCByZXF1aXJlIGV4cGxhbmF0aW9ucyBhbmQgcnVs ZXMgaG93IGRlZmluaXRpb25zIG11c3QgYmUgc3BsaXQgDQo+IGludG8gbW9kdWxlcyB0aGF0IGZp bmFsbHkgbXVzdCBiZSByZW1lbWJlcmVkIGFuZCBjaGVja2VkIHN0aWxsIGluIDUtMTAgDQo+IHll YXJzIGZyb20gbm93LiBJIGZpcm1seSBiZWxpZXZlIHRoYXQgdGhlc2UgdHlwZXMgb2YgJ29wdGlt aXphdGlvbnMnDQo+IGxlYWQgdG8gY3JlZXBpbmcgY29tcGxleGl0eSBkb3duIHRoZSByb2FkLiBM ZXRzIG5vdCBjcmVhdGUgQ0xScyBob3cgDQo+IG1vZHVsZXMgbXVzdCBiZSBzdHJ1Y3R1ZWQsIG5h bWVkLCBldGMuDQoNClRoYXQncyBhIGJldHRlciBhbnN3ZXIuICBBdCBsZWFzdCBub3cgSSBnZXQg dGhlIHNlbnNlIHRoYXQgeW91IGFjdHVhbGx5DQp1bmRlcnN0b29kIHdoYXQgSSB3YXMgc2F5aW5n Lg0KDQpBcyBmb3IgeW91ciBwcm9wb3NhbCwgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGl0IHdvdWxk IGJlIGJlc3QgdG8gaGF2ZSBhbg0KZXhwbGljaXQgbGlzdC4gIEkgYXNzdW1lIHRoYXQgdGhpcyB3 b3VsZCBiZSBhbm90aGVyIHByb3Bvc2VkIGNoYW5nZSB0byBZQU5HDQpMaWJyYXJ5IChpLmUuLCBT ZWN0aW9uIEQuMiBpbiB0aGUgcmV2aXNlZC1kYXRhc3RvcmVzIGRyYWZ0KS4gIEl0IHdpbGwgYmUN CnRyaWNreSB0byBlbmZvcmNlIHRoZSB1c2Ugb2YgdGhpcyB2ZXJzaW9uIG9mIFlBTkcgTGlicmFy eSBpbiBSRVNUQ09ORg0Kd2l0aG91dCBhIC1iaXMgZG9jdW1lbnQuLi4NCg0KSy4NCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxp bmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0KDQoNCg0K From nobody Tue Mar 21 09:28:29 2017 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 30E2D129B9A for ; Tue, 21 Mar 2017 09:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Jt0rtbbbCJqy for ; Tue, 21 Mar 2017 09:28:25 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B52129B94 for ; Tue, 21 Mar 2017 09:28:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DEE0211FC; Tue, 21 Mar 2017 17:28:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HmsO8txpHi16; Tue, 21 Mar 2017 17:28:19 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Mar 2017 17:28:20 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96FB62002B; Tue, 21 Mar 2017 17:28:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hEt5s7gL_kGY; Tue, 21 Mar 2017 17:28:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A13C20038; Tue, 21 Mar 2017 17:28:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5E8F13EF24F7; Tue, 21 Mar 2017 17:28:23 +0100 (CET) Date: Tue, 21 Mar 2017 17:28:22 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: Robert Wilton , netmod@ietf.org Message-ID: <20170321162822.GA36653@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , Robert Wilton , netmod@ietf.org References: <20170321102533.GC35449@elstar.local> <05D066C2-08AA-4140-9399-87654141F821@nic.cz> <70eb5dec-2b98-5e14-0150-0ee3e55ae99f@cisco.com> <20170321141123.GB35926@elstar.local> <628D63D4-0250-4150-BE2A-F90298499473@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <628D63D4-0250-4150-BE2A-F90298499473@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:28:27 -0000 On Tue, Mar 21, 2017 at 04:55:18PM +0100, Ladislav Lhotka wrote: > > > > > Single character flags work for me as well. Since I have modules with > > pretty complex RPC inputs (more than a single page in RFC formatting), > > I think it is useful to be able to see that one is still starting at > > an RPC input tree and not a regular data tree or a notification tree. > > Even with long RPC parameter lists the indentation should make it obvious what belongs where. Another option might be to label every input parameter with "xi" or "i" and output with "xo"/"o", and remove the "input" and "output" nodes. This would make the output shorter and narrower. > I wrote multiple pages - indentation is difficult to follow over page boundaries. > > So I tend to like Rob's proposal a bit more. > > Note however that Rob's proposal doesn't distinguish input and output parameters, all are labelled with "x". > I know. At least I know I am still in an rpc/action definition. But yes, some of this may be personal preference. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 21 10:53:53 2017 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 BB48312967D for ; Tue, 21 Mar 2017 10:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no 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 GdjUnWDTPjA7 for ; Tue, 21 Mar 2017 10:53:50 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 49DA8129BDB for ; Tue, 21 Mar 2017 10:53:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.19.173; From: "Susan Hares" To: "'Kent Watsen'" , "'Juergen Schoenwaelder'" Cc: References: <20170319.094733.1957440769000198080.mbj@tail-f.com> <20170319.173702.1332458451679178380.mbj@tail-f.com> <20170319181630.GA32188@elstar.local> <17DE32B0-6B2A-4D55-98AC-C4B26FC4BC32@juniper.net> <20170320062722.GA32956@elstar.local> <79DEF6A3-F1AE-45C9-A88F-14796FEF884C@juniper.net> <20170320141729.GA33652@elstar.local> <4FAE1F8E-5449-4761-9950-41956A1CB7CB@juniper.net> <20170320144335.GB33724@elstar.local> <01de01d2a245$c5fc86f0$51f594d0$@ndzh.com> <2DE21F4B-8F5F-473A-A268-42BFB053E490@juniper.net> In-Reply-To: <2DE21F4B-8F5F-473A-A268-42BFB053E490@juniper.net> Date: Tue, 21 Mar 2017 13:48:48 -0400 Message-ID: <03de01d2a26b$65a6db40$30f491c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKRYuQPsfUj8cjCteu4rA5epEpzywKNP93cAZ4xGQsBrhp2kgDz46dtAfyVlhgDI1wCpgFJmEJcAh/Z0joCDA8GdQJbGrlLAPJKKe4A3WNLOQM0iMZ3n1v9/gA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] some comments on revised-datastores-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 17:53:52 -0000 Thank you for letting me know. =20 Sue=20 -----Original Message----- From: Kent Watsen [mailto:kwatsen@juniper.net]=20 Sent: Tuesday, March 21, 2017 12:18 PM To: Susan Hares; 'Juergen Schoenwaelder' Cc: netmod@ietf.org Subject: Re: [netmod] some comments on revised-datastores-01 Sue, I think that only (c) is "done", and even then only to the point that a = proposal is offered in the appendix D.2 in the revised-datastores draft. (b) has never been discussed. (a) is what this recent flap has been about. We'll see if it's a list = of datastores or capabilities or something else... Kent -----ORIGINAL MESSAGE----- Kent and Juergen:=20 To summarize your messages:=20 a) a global datastore list b) Each datastore contains a list of modules it contains (currently = done) c) Each module contains a list of datastores it supports.=20 Is this correct? Or did I misunderstand.=20 Sue=20 -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Monday, March 20, 2017 1:09 PM To: Juergen Schoenwaelder Cc: netmod@ietf.org Subject: Re: [netmod] some comments on revised-datastores-01 > I believe this is the wrong direction, even if we rewrite the module=20 > in the revised datastores document and split it into multiple modules. > A simple list of implemented datastores is cheap. It is flexible. It=20 > does not require explanations and rules how definitions must be split=20 > into modules that finally must be remembered and checked still in 5-10 = > years from now. I firmly believe that these types of 'optimizations' > lead to creeping complexity down the road. Lets not create CLRs how=20 > modules must be structued, named, etc. That's a better answer. At least now I get the sense that you actually = understood what I was saying. As for your proposal, I agree with you that it would be best to have an = explicit list. I assume that this would be another proposed change to = YANG Library (i.e., Section D.2 in the revised-datastores draft). It = will be tricky to enforce the use of this version of YANG Library in = RESTCONF without a -bis document... K. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 21 13:01:58 2017 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 9263412948D for ; Tue, 21 Mar 2017 13:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 si3mYrqij3AX for ; Tue, 21 Mar 2017 13:01:56 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0094.outbound.protection.outlook.com [104.47.32.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CFF51294B5 for ; Tue, 21 Mar 2017 13:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nruwbbRUKiPV2vRBuGcZIkAopDIrtt0PU4H3cMad/ok=; b=P6OIKK+51A0vD67OL+bx6m6CnTxZh7bN38VMNoJL5gsuysvNDxC/QV2CnWzCVCih5qoaqzAkdOdFrzLEnqt1EExSxyZbS7bz4v+HmIMAwHlByj3iiru9unDpsHJ6owxjt0SVeec4rHd5XCTtofAjw31HWLuTpAZRJrGVbtk5VmQ= Received: from BY2PR05CA055.namprd05.prod.outlook.com (10.141.250.45) by BLUPR0501MB1748.namprd05.prod.outlook.com (10.163.120.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Tue, 21 Mar 2017 20:01:52 +0000 Received: from BY2FFO11FD030.protection.gbl (2a01:111:f400:7c0c::166) by BY2PR05CA055.outlook.office365.com (2a01:111:e400:2c5f::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4 via Frontend Transport; Tue, 21 Mar 2017 20:01:52 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BY2FFO11FD030.mail.protection.outlook.com (10.1.14.211) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.977.7 via Frontend Transport; Tue, 21 Mar 2017 20:01:51 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 21 Mar 2017 13:01:51 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v2LK1oZE027560; Tue, 21 Mar 2017 13:01:50 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v2LJvkAA084577; Tue, 21 Mar 2017 15:57:47 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201703211957.v2LJvkAA084577@idle.juniper.net> To: Juergen Schoenwaelder CC: In-Reply-To: <20170321102533.GC35449@elstar.local> Date: Tue, 21 Mar 2017 15:57:46 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39410400002)(39840400002)(39850400002)(2980300002)(199003)(189002)(9170700003)(5660300001)(2950100002)(48376002)(53936002)(50466002)(54356999)(38730400002)(50986999)(110136004)(189998001)(7696004)(7126002)(77096006)(229853002)(53416004)(4326008)(86362001)(105596002)(305945005)(356003)(6916009)(8276002)(106466001)(47776003)(81166006)(1076002)(8676002)(8936002)(2810700001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1748; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD030; 1:c4TyQzcfCFq9MtPE7TgsGuYAuO1UNBYjG4T5krTgdlqSy4ZdrUJB35bjiEP7XnllYzpxxOgqyrIZTRHcN7CpC0Ph6kb7RxbIbo+1Nzchy9+CNVCC5D5Z81Pc2MDmBxw/TPjqdkKf5eejhVimh11SJ0VHUuqAVE8DiQhF6zSVr3V/6qj4GZi+vt7codmO/tz1ktDVrXI3Rtg0vQd0GUuQi0XIRtZdmw2Lt2dzN4QEBVyErv7vSGixydeX+9luRGEYH/jDSsHL2bn/iY0JfoQ6SkiU/lr+GYk4APxx/lN6ypLtcqvGNGCK5SCgF88q+5pET3v5F7xQvW3rxnHnLudMU2eH9ihQnQysqrt9ctrJ7AEs20I0p3/yRsgKRLbodKrj1zoT3AwaySYuUOVIzJFOAMw8eR+ZD+e0V2BZazFaHQu2xc7PlKZGUPtlMFDBQnym11jomo7vAjyXcLSlP22SAr07mcEbDAjFhJ7LwecyCrTes3o9rzMYTC1PY1j0xnwSZCZt6CrzqO8pNQfVXts58VpsxBMz1LKkAJ6sJAHIhJim2eT7chhYzWOpwLbKrLyJb2Xne+oCt9nw2yARR/Ai5w== X-MS-Office365-Filtering-Correlation-Id: 203ea599-7e5c-4f15-db73-08d470951df7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BLUPR0501MB1748; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1748; 3:xvugaTDPqcDBzIKFPUe2xEu/oXjbSJek8LvF1krDankZYDjqyab3MGmqcDusoceabo1HQXWg/xR46VlQMBwRHV88cDbpOZoATEhTk7lDr4DQK1J8K7566bSMrVlhlDYj9NTf1y4AmkmcT92h+hl0QTn5ouOIc6L+VswBwxTu1JQgznIbN9Wd8O+4Hsz8kU8HWuCWNZcGsKczqLBs/Lfb1CGUpvYS5VrigpP/iW+gmL0UPfPETbBFJBoXPQrRa8M3J9wWoKVa+MP2YONPRezWn+5O2M8CdiCT5+arm+TtNb/Gzxcvi9lBFY/7X8UU/Ot6W+Uv9EmEwpj1dFAf9JcOxj9LUCLbfM2aiynu7iCMYlc7cMP+LuN6hs+BwIZ77OMLu/zvsBybMbBbWV+0m89jWw==; 25:2t2cKZ+mfR4L1Utd4uxcxMyqF0sfYX2DYeAwNhl2cLMAN/Zv5GrhlGSm6A+oXJOVy5l9Bu5APnCsXQRy8VUknHjj5gNNl8l1XPc4flkqlqDF8/cmMxdT2y/316BAmyjfTavPcq8ST5DnoJSKcbFmH/fsFwrk5VnzFjjWvWtaJmhSvefALp9x0FwHJdr8j6N1MgivAL/lZhvQ2pqUGv2di6s4CDiLmoAKf1zJEdu6HeFMaR/3bveAKbBl+8bfsjc5g9oSanpamMuieAJrvUS3/P25d6vuArKvfNooPqbthYBmrVba53Wc9Ul6xnUd8GFSZ1MUqyvEImOAQIYv2xQ5kH7hDNbRrFHB8RNZeKaDeTQYOnHn1sWB4+ggPpctUZy4oprhGLbd1Q/dKobgEDa2y+VSrgMzh62MP/ahX0U3S8TLeSmDNsKv8dNvYshH1WApvgkCCMRJKACi8tpukvVQvw== X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1748; 31:NE2Gi4uSXvb21SbT78EZCErRDJItTuDD+7LtBptsmrsURukk1LQd/7eTcBhXIS/SAYB4UKehzcNdv/CjV2IYY8HV6o/6NO6QrMfmPvphZDT8KjVCVKZMa3mxbl9U6Ykff10fhvuzyU3LNPEm5RW0SLJZzLeft0GFWDXS65N0/oAImpr3XcUfsJn9AJ9jrgtiYJSimurPzytyTl3M6n7qby+2Dvh5Ek/RPERB7iRp8VbIvxV1/X08ieCQIpgDtjUB; 20:JYxl6RzbRQRs2RBrJTvViqXcx6e/OJfVf8eb08KfE6JghvYk5hfk1fmvRQJo8YkA/v1N16rRNaRksZTHKn3EcHXCvKTe0zBMjQx/xeGbneeVBaANU7AvFT2lqK2Igtr1BHf1G8t1mo8PMxJzS9/ZSWlTc8rS/+urgNdYuzb60nv+avy4/+cge8ofn/ldyII2bO7LN6+hcDApn5aUat+6FmfJHHjt87VBZ4gsTunOZduP5uv5Ktl34fNHBqv1GVn7Wg54XuCU9wxJiWIruRAMPk6j18W08OFTjQYUaCfMlf7uEQSQmdRvMNOJdWaLF6zR82cg4SO5f8YGxQh71ug9k+a7BxWelCEgjauDOkeCSmhG8LqRQNHTSem2g6oXQT6+huprMrL04/u4i9vftAD8C6VSaQ1Yi446fGBqpvqYkD0NYi3UTdYOjhPIDbtsmPB2OWfaHQydtc8kRpkJAdusyWT2wEYD1RuX8ChpVVnghFcrtCo5Pl0xqyRpz19uuwgP X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13017025)(13024025)(13015025)(5005006)(13018025)(13023025)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(20161123558025)(6072148); SRVR:BLUPR0501MB1748; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1748; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1748; 4:O6iD3ssE1RCVc9GTA7Zby2ohg9m8azPdm7f15oTw4yX4BRR2S2nvJ3VQgIn5OxENCpB1kp5XF4FDRuwjZxpyIdPNyKewGzSdK1z9RHgc7TuCTjiJnVoYB8tJ21JX1+MgNWo5VdPwCkgB76xImSGgplGW5NDRRAW8UKcDt8FR+SgXEMlEKrXGGkjBB9Yzpau3yRf/dTaw0RFkBH6T9SOoniF3XdQrlXj5QjK2lCr1fHMVjFLGFcHYb7qRZ8oFQqjb4jr7QAL9i6zJhEGhH8tvzXTXl2TVEE8pm4yQVdcl21oFnalLb6/jUHTLnvXPxWo3+fGp0k8EnUgMNtMwhgCnF4fJuY0ZMl0jujcUg/sPGPFJZehAjagbMA7IAwf8SFGNFTMhOvJszihEXB/u5ggB+0kpWm48CBeH8V3XB2y5UhK0g097PyFbTWPWgufuxzh23d+iHpZjIOcTlB1iguOmg/CElx775MjVS6wOjT9BqJwkXSzEY4MnGA+cDdbZQ0h3YpEh9Bqid2mxJ5ji5KeX51gH6QZpGPFquTXmWBdavBZitQfFQ9uw0zxe/bLlqcFTMQ+uT2Ss4Nd3MHDNAZahvHdXUgxmoWdaZjqcX4FFP3bysFRb49kSFmGoZG/z9chTPnKBuTmQH5diu1xoKfQ67pmQ3Fdn2VHI8gQR1xGgYPjft90V/zczBoRnGuReOxE1LCNwVeIwoWSUWa5tsjyAjg== X-Forefront-PRVS: 02530BD3AA X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB1748; 23:mxVfsZwN7kJv6RofavWopy/93b4y7wiHEzbuDFu?= =?us-ascii?Q?wIVeijievctySD/yNgYQzPq5rJVRJEEq01xMqgAevbWgu2B3fa54qOv9x0zc?= =?us-ascii?Q?lEkaKQikfWw9AU2hCCphihtjFf5j8g35/uqm+YXhSQNXgSbUaoVENMW3NoW6?= =?us-ascii?Q?Bd3M2On/gFxJD62Os/zOQ2w2hl1NaFcP20Flalrg+1Qg0VjwNHK4SiCcQeFJ?= =?us-ascii?Q?NU7343tl9vPWzOW09JHsBztFXX2v7EBf3rzslzatgAG7OfQL8vihATDtUXc8?= =?us-ascii?Q?bYhKX90YJPKPUQ/A2qG2xjsKPpjwpsHoC7ZI+X/I+KHShxGl8F9mExE9DMsO?= =?us-ascii?Q?uW3fYJmEsqKrN7VI/7+e4Ga1uSdTRrIz9bth2/ZXFnuZ3JnHVtYbYxPMpIWb?= =?us-ascii?Q?/F4+ZhE15vTUOzHdZomQtjimHYVz/mQcq3+LJiVbOh/rSJHVVStpLr3Y29f4?= =?us-ascii?Q?kQ2wZHLAoe3YbxjSY5W0nFgeL1SDLR8DvzWmWQ2dgjZgQJYYJJNUBNB4Exa6?= =?us-ascii?Q?FGW7WcRcGH7jS1jEjhagTiAhvWVMCchN1ebMKX/leIrtwApzoVwFmTkEN8zC?= =?us-ascii?Q?M4ugtP0Mgpy50dwwWplxKVClfS/GC7LRLV8G+pWzwTxKjdOWEyaRzoFbh0LI?= =?us-ascii?Q?jcFew+yCRgoDMRAq0Z22XZrztX5MBLcPK2TLspaVwcxwynrAvKfy+tRDQmOq?= =?us-ascii?Q?W0sgZH6XeO3OQseixOWfgA90NUTpi0TQ4xvEeUZ5rP6ayCZMU6/4Knk6Fbm8?= =?us-ascii?Q?mfQTodqs+c860GxWJ3cz9cfpsxAuDz9aIZYWlmvS7EwjMGoU4ziGMN4xFn1C?= =?us-ascii?Q?YEO5UohLjg3DSP1jyRrXKcp5oghpnFJJJp/0ZriKYzqI/wVDseWfxzJdUxWo?= =?us-ascii?Q?ZwFkdoTpCtdBcbiOKxz3sQhQoppH7QteKxwE+aGQAQTE8DX90RAuDwgyA1ab?= =?us-ascii?Q?iObPleExBsGK3THG5JVGKIe7rEURX76I4TEGWxLcP+KM6XB0uTwtnLdl9ZZ2?= =?us-ascii?Q?oDzOv34KlPBu+c/d1YCifY/rV?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1748; 6:0fomcFCu8VvgS1W761D+ELgI7N0IQ+VwEKdANEsvQ1JMe8w8OCJfomMeQ4ZmcPpKUmGOosQsnKL9fl7TUBBrJeH8se/z7TYdRep9WvQ8zrpveHSnYZDtwBfk/liNrLs3ZqT3Hut+TuRzn6kGcdGNTSSx0HCdFmx34Ul9W3eU3bgVxhO6ntRkq7nsVyQqc+T4T9MTq52ozmi4NFirFAzjNJ4Y7vhnEKQLavm+Uldnzq2HCsIMYaD1Zk2PjNBugwnKmY94n+CWufTk5p0Rqr0qaf5T8R8Zui//p6c72Wiv8ZIhNA0/ySL8aMiVSNOUtI6oSFOm0jjbklUWdsYyRDqWWKK8LX5z9fgEw7OF7mfM8Qeq+LZsJAYZoP/2hwxDba8nNLw0vUVhjAxEcglSirRf2f7xdb1yIbyuRzlER4Gq/bk=; 5:LLhYW5By8MBJFMvMPH0JtlH7YYX5x7PUJTwOvQWmaqck8cTkEhRed5a+1B5MTzEaZoMqbCindh3MVdvHyQzpjFPRwVTFM+oaV2oU72Ph6+XgxWIE3w1NQ/ktZUasShyCMgM5EROwe0AA21fCLvvvcQ==; 24:qiipACGNom/MsqY3Bd9z59sB6FfSSPuEg4PqBF8ltFqTe78vkmSv/hX8oCF9dmlB4sakGZLw3eosVl79YhA01zzWQR/FDgcoTrNE9aeivTY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1748; 7:uWhe2ItOSBUTGRMmCp208s82WJrcykrStXEzdHdpdfuy9eF7I1xr7vap6wQkbrcqMyIzVIYiT88EUjKldd6pqvVB3Wp32c9A8FmbgSbEPZa5BGm/kQISN5w4vcxmsvWCZwAg8j/k5qBYKD2ISmj9BfboczBcNzCyCZUkzuUK5fqqWA92/4cyX+DkOrQ5MqUaS71jvRLe8rWTVJaGDriqOUP7kxMuvY58c1ahMKyeHJobuHheu5YkWsSkhRALScL3M4PyurwiWeP60g81huxE1ajPHS3QYQcJk043lyK3I0MJDe9DjFroYEE50OGG5x1wUMKYW0XfX+I7g86NYVdZkQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2017 20:01:51.6779 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1748 Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 20:01:57 -0000 Juergen Schoenwaelder writes: > is one of: > rw for configuration data > ro for non-configuration data Given that these are really "config true" and "config false" and that ephemeral data may well be writable and "config false", should we change the names? Writable read-only data would be a mistake. "ct" and "cf"? "c" and "-"? Thanks, Phil From nobody Tue Mar 21 13:02:53 2017 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 06D6D128CD5 for ; Tue, 21 Mar 2017 13:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 3jEZW6bNdeNW for ; Tue, 21 Mar 2017 13:02:51 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 D9D32128D19 for ; Tue, 21 Mar 2017 13:02:50 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-03v.sys.comcast.net with SMTP id qPzTcABhsfuM3qPzWc0FSD; Tue, 21 Mar 2017 20:02:50 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-01v.sys.comcast.net with SMTP id qPzUcrfRTY10NqPzVcOkwZ; Tue, 21 Mar 2017 20:02:49 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2LK2mhC006726; Tue, 21 Mar 2017 16:02:48 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2LK2lep006723; Tue, 21 Mar 2017 16:02:47 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Martin Bjorklund Cc: lhotka@nic.cz, netmod@ietf.org In-Reply-To: <20170321.144353.1304796463767741047.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 21 Mar 2017 16:02:47 -0400 Message-ID: <87shm6tn2w.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCsWghXY4rMU50ySGktIGNmpevspepZdX6IdxT7Bw7U85xGFDqKA1HA305XcalBzqjUggfYxxGyRImISrCb3nxEp67WTnQb3Sb/fcfUrFFUcykrvSgxE 29b278f4bmVeRMldeznIZyjH1Q9oADFO88jFkIiMCab8rPW13QrcqRmjQnXtraqBTZRvIxAzF1jU6GJcSVp9uM//2LWV2Emn6zc= Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 20:02:52 -0000 Martin Bjorklund writes: > Hmm, "*" was choosen b/c people are used to read it as > "zero or more". So for example: > > +---c server* [name] > +--c name string > ... > > means zero or more "server" elements. Each indexed by "name". >From RFC 7223: module ietf-interfaces { ... container interfaces { ... list interface { key "name"; leaf name { type string; } leaf description { type string; } ... There is a top-level container node "interfaces", which contains a list node "interface", which contains a sequence of list elements which consist of groups of (a leaf "name", a leaf "description", etc.), which elements are indexed by the value of the "name" leaf. Dale From nobody Tue Mar 21 13:07:55 2017 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 02B5E127286 for ; Tue, 21 Mar 2017 13:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.677 X-Spam-Level: X-Spam-Status: No, score=-3.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 wx-622QNYzCO for ; Tue, 21 Mar 2017 13:07:51 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0104.outbound.protection.outlook.com [104.47.33.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B7E1294FF for ; Tue, 21 Mar 2017 13:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GSzarHHwhkHTyXoj7Df1HNCZULf8n/zad+peaLJwAs8=; b=aDmMYJuOej4zIsGvxGUK01lxtBeUbLzajz3rI/mPMPxe3PtWwtuHl4rTVfb58Z0pOJULdkteaQm0waDhDRnZIjn9KOq9bbxGkct+dMMZol9XytUU1C1FNzgx7F+hNIx/qy2MtcJa7ZMrhRqhYAUY0NVmXp9o2865u1OiduOE5Ks= Received: from CO2PR05CA0083.namprd05.prod.outlook.com (10.166.88.179) by BN1PR05MB309.namprd05.prod.outlook.com (10.141.63.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Tue, 21 Mar 2017 20:07:48 +0000 Received: from BY2FFO11FD005.protection.gbl (2a01:111:f400:7c0c::184) by CO2PR05CA0083.outlook.office365.com (2603:10b6:102:2::51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4 via Frontend Transport; Tue, 21 Mar 2017 20:07:48 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.977.7 via Frontend Transport; Tue, 21 Mar 2017 20:07:47 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 21 Mar 2017 13:07:46 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v2LK7klk028812; Tue, 21 Mar 2017 13:07:46 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v2LK3gbp084798; Tue, 21 Mar 2017 16:03:42 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201703212003.v2LK3gbp084798@idle.juniper.net> CC: Juergen Schoenwaelder , In-Reply-To: <201703211957.v2LJvkAA084577@idle.juniper.net> Date: Tue, 21 Mar 2017 16:03:41 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(2980300002)(199003)(189002)(9170700003)(356003)(8276002)(53936002)(77096006)(54906002)(50986999)(47776003)(81166006)(2906002)(86362001)(8676002)(106466001)(1076002)(8936002)(105596002)(53416004)(305945005)(50466002)(109986005)(38730400002)(110136004)(54356999)(4326008)(48376002)(558084003)(189998001)(229853002)(1671002)(5660300001)(2950100002)(2810700001)(7126002)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB309; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD005; 1:5TaJryDuKnzStvLO4aB2APpmTD0PesLPjI/sBM6uF6aT91G3ruQVSlF2Lavuk9veez9pj938HOdtEBlrpl4XfDK0BxkMhZ2pBhK34Kr33RjVZFaxCNjiLsA2erVoMTeW5Su2KG1qxtKKwAVRIluwBEcmY1ei68CfqHl3y7fLDonfuQmiOGcrtobsLp8Ik3fvxvBoszpL66og6BTAAAr9OOphsHo1052VxZTyXtAQ2kv/mQJs9HzsS4gIdtokbxXkZvMumzQ9N2/lBjiyZeMKjR+Lf0o3Endb8WtQtmJK4TmyBjg2IOGxf9JKgwOUvPYohDtImxTYhKToqi+NhZNUQVb210bywOVXqNoRn7wp58oDLezS8vigySmCl8e9GOPtEPdGjAXGx5OWYBmxLnuNYnf3OV/Svigq2Yufc3G/WVtMZ/xEepKQaRp+aPPsAa1fv9pA630MZ8gG+JG9++vig5GWo0lMtA7x9zcFApWdvh+Y+nF1Hb4+j9R6/DVfHIDK0Nz/0c85rav9jInMrieauLFWZGWTg+3DsP3h5V/N0f+u0GpoJYLh+IVsvWNWT8t3TbijdKQEm7Z/YgzNWuULWA== X-MS-Office365-Filtering-Correlation-Id: 5db3e3e5-e744-42ae-ea76-08d47095f20b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BN1PR05MB309; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 3:KQ29LZANimrElhneVrx9gS2DE8uYKrDwpxYPD3PBiyuHe6o+oVcy237LbcxARvkee9QpuoRG3OO4J2BWErapjavapjBFRIS8d/AEdPbP+KmLBlkCkjbedm/mFIM55RRKeDjtO+gAazr4MF/n6zItH1TnDJx8EXaQ0Tn2ZGuEBhGi8kavdQnpBpkYPo4q89snw1osSMTSe5UD25tIr8zVVPE84wEKP6jJz7mK8JGEVeVgIEFMFcxGjMwNDbjrpwWKO+Un+PhcWS/j9+uw9VdEb/jpJhVpWCJ4Xem08tJH1jnc0p2MtDr6YD7JAMdmt048wFZ1X0GX2EsKSAEOOe0EJwjxmhbJQey7qdiHx5LOmBT3fJeDzqK8Q251cf8tm1qNoCkrIH5F0Cqp2BCyAgoYzA==; 25:w4x+bYnLprNZwRblOALIiawc3ty5jb/CuIzscZTxjpN8DV9jPu4ExyQV0fxYab4hT1m4zbmWfwPWBe2GTGjpRcgXbzQ8yqM1mkNMTbMTHmgM6ZX/pFHuJKNf43n7YO4+8W/WNt/fmSHKkfU7zniFNXQkVvMcFAdWnByHWgLm++l65xb3OI4t1/7kGOisgC55QraREcTO3m/9LjgRjxiQxI5O9fVMZKPBQpA7LfX4cNFPSZkgydFAqFGw5WxPOxT7yVMncGuW1WqhnbASgVmJEEjeRhbA0sA7PGwFy54LK2R5AWkjFdyznZ/OFJjW2lUFIZhUFIMKv0cFxSEKdwwHVU3i5wuOpjI0mOb/EnnitGpX2NLLL+5SqXVWsCryL02Q1WLjS1cRv34PI4b3Qlpmd6TKAgnx4XH1El09JkMAmIOnCJirkGIgl1mWWIOY3mdwQIbV8w9QgxQQ8oDxJIsxzw== X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 31:CWud67ou3hMtjNmkfxpY/wD7uyYNglJB2KnV6dWa1qelVisOXRdjSO6B8Ao3HMDXmvitHTywZzzRYMYMNGQWRRTcjZP5Q7O3o5/Zopuf3F/g0CCJAXxQyi+l8VFlj3il9DqOBex+0JR9meiZFeqh1yPTghpUkmGlwxjM8GznnFdo8E1/EAkGz/8hTjYDNGjfQWPNPFPSTt//XoHTXdECCn/vnZpWkyCYJ6is8oSv726qnQnJp8w3vhpyOF3B4wfIh8+Z0u2ZZ3J6LZpQJbei6I9YGNHNEIRAP2lafIua02w=; 20:xNia8iMs1c39GMfWpE3A1x0ilREw9so7blVz6mATgi91MwsozpSdvy2EqVdAtjIzzsYREwhTWKF1I1E4hIqfwVhNkNWCnBtcFC4YE1Q7QW2XwpbrWIMECIKmGu93j9osXZXRaeotILnYhVKFCGxsjmwC5PfMGWWpbuhzDg68YzrjW9F8z/7xRP1qiTalxky+Gn3JPVTIdaR77di7a63IGw2C0oALImoof7DHcy7XWXNQp/ek0dmsMteSsOFR7NU7iLy1IirtkM/BUA1sCVKobzU5skVdNcbhYXL1LhUeigq6wiaKQQ3DRLoNmXNsgVa+PAqkbSglNJpwlwmWAJzVE04Q3vEsuAnIuNHIs21IBt2lnVR1vGsJuaGlmBHMgUNRCuYkXdHvi519JKrs7omPyAgM0XKh00ItkQzsw8hOfONjhrZP9Klk2i1dgNyE0wHhDPEnM/zbIyROeZzdyo2r4bz7giweiYu07OwIvSAlS8I797sk2iqQ7rFaRSdIs8+b X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13015025)(5005006)(13023025)(8121501046)(13017025)(13024025)(13018025)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:BN1PR05MB309; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB309; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 4:WVkj6Cu8V5h8q4UvRn/xoih/k342qvc+YRQyPvB44wjX+iKpk5s/XoD2QV/cCUKw4deYIyOBbJekDH8pJ/p4jtyhrkSUmV2sYo24mJV34liWxvrXWM7n43/1ckdWV9dPezx5AyGVS4mTcLCk2SXm+P8Z+MJPqkZC+SVDJUpOuDupgjfYCQh8UEGUtSXykPBe0HAbLT9tcCN6uCv8gXfnoQdJI6LFT42QL6Xc4GUvQqCFUVFMZVSB7hnI7OHfWktKfkdF+RRBoIrWMR+NrS9LLiLRAfTlWaODan/NyR7qydH3acnCFTA2c/sskgCSGxfU51a9tXqBn4GC4htKOyDLGyoswOLi/NkjE6461NO+cP9zDryVrqVUHi8IS8Og9rktXokc/NFECI2pM3ldTfOtI1FLmlQgP9cvOCQadOMOeXoYtuSxM1i6d4NdwN4pOwsUMpWqGDdOXf/JUc15iqK7DioBzcbUPQW7+AvLeRhASWgbEoCp/Dqi13nozK9S7OPVPLWHFz7SN61yOBIS+lCceQXtKJyeigOcnQzl31U04XOuld5xhChCNAer++b/B+IQqL1MuGPdD3acHZ7OiTGfXNwuwun+4ICoHSfY/DKYU5VA0c2rJFmscZ9P0JXKU4NRavaAyVrEyLk86tZsTdXkD6/PEd3dFmctLbk6mBwHCr4Ddb9YL3mLV658PVmeNic5wQyeOK3IQDzOQJBf13iNPA== X-Forefront-PRVS: 02530BD3AA X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB309; 23:7nEmV66Fcn6M0KiYymPQHXS3GFY0a0yfsXo2rrJNZT?= =?us-ascii?Q?AdURDFHTnEtL77+2RBcy9dVvDcOBMH1lEG/mUwbCKBhKdV0alJhe7WSTxDFD?= =?us-ascii?Q?LDiQRliZTkJr1DGmVTHK9oVmwISH6WThybu4p2ELinBJQzgSjN7RlSyJoPw9?= =?us-ascii?Q?n5xtXK0L6x5sgF/kdN3TRHpP3csZfWW5nOUY9KLsuZyDEw1ecB2L6MjU3q17?= =?us-ascii?Q?gY0krciOtUA1OO8Iw1N2GPc3G98v+JN0aGO42lpIMZv9K8RpB/tMTE7Z89CY?= =?us-ascii?Q?34PFBdFTpsExt2vBH0ZF02lZue5i7sBxUQF1HWiBQ6D2/FeELoLYp6SOopgx?= =?us-ascii?Q?k8ryEP5B2xfxTgr3ipBvBx7GZil6ehs83PUImq+4vb98lVZg/laKYGBGNKlP?= =?us-ascii?Q?gT3XwfsLe8OrlL03m4Gv7xETD9x7lnkWi06CLTYEDkN+M2Wf9fSOlPghU4cD?= =?us-ascii?Q?vxhg3g2ZVFcRCQrAAPWSh+Tmim3eiwHu+dp1zXxlJ5x3oES0sYANsgp0Eejy?= =?us-ascii?Q?OholePHJAQApijfjFR9rksj5Qee6VJKAZqQ85K+f4E4q0c2JnxYtbWBzT9Go?= =?us-ascii?Q?Yr/ZdFqNwog1YDdRU57zZJzwWq4HeZp3axuFprCLasMvr2xoOIgdAEpp6t7l?= =?us-ascii?Q?E43f/KwThuv5gx6pFIHtFn2uBlDPeppWJzbkgslV98u4kHB4mo6fZTx+VKdI?= =?us-ascii?Q?RZWxpeo5FtuG7fOSElk+VYaDFI2QrjffAmLYq0YT28r01PqK6cQwoizKvR+y?= =?us-ascii?Q?0djfkW1/1uT5YPOyilIplKiPszVemwHC+4sKEFnVh631Nr87hYKm12nT1/6B?= =?us-ascii?Q?bOULURJc/Ntei0yP4X53jJg1HHJNfcVRT3A09M59U1JOGDFVi5Vu78fBMsbr?= =?us-ascii?Q?0ofcME7nvc0fHCeCQjJTSUOVPlfGADthREPnaZAOgxZPxva76fBCnQzdbrl3?= =?us-ascii?Q?dq7q2cOXvMK3HR9uskNXDJy58zEa/dHvn/jBwkAP5VqQT/xFm/hGuvl1fzrE?= =?us-ascii?Q?qK7ZWDLCWLOUjd15c+953kjQo90DGs/PZz7imM24NDujFvraJMhszmrkaKZa?= =?us-ascii?Q?HMkKNkGSU27DVWAJ9QQLzs9Prw?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 6:HP9Ntv9nUdPLdYbN2A7WcdV7TR7aEIC3MEDV4q/mTV4PiaNuOqHrqtEofUY7ycvYW0YQlKzxtmH2dbRr3xs3bMBZaGWr4L0mo8Ic/RHPNgaxdiyRnCCimpnys34JhWvJslYBrvwV9O381M9Xxp/m5m0OE6FLpVMeu1q8QzHkrIaa9dOP7SxcEfDwoXbBzgNNzupLVNB4OFtOSU/7jrvU/zr5DSw15Zi7MFrUC5j/rehmmHRPBpk4leBxoMzgDVZiDkD/uA6p+JWpbVjXBen3Bh5Du64bxF/zUD/Kg3nt6cf+4A3SIgJ/oUUlHzWPyKI/6z44ZlAtLuBzKkRdH2i1mZqdh8Zrw3rj05GX8rBYEEU3kgEIY/NVPIuaFWeM47tWJj1erTI3mauYwwDeb9ypQhCTvwynLP0OeVFMGhAV7nM=; 5:PQbK3ZtodgB/Yduc4t9xrcRA5JaBxP5Y77oRLyUbZKsT67KHqbttIozUKzjiSaOZ+M7ErQqIgf+wNREtbYx1GFjlfqnVFtOhGAzf2bUBZwtnVTlDJxdj3LNJvWTwfMOYGJEWzAPaUhgpNkey7Y1XkA==; 24:8hX0amle5sVv4yXdI15zaLZlsISAxCcScwiDFJywnY67rG51ASUnn7kMipFg4sUhHTrI3r8w/Ko+usbj2SSh0T+VSK87BSwBvslREmi2OR4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB309; 7:DY9mdQzWTc8T4igeX6muaKhn7qQwP3GGkKGzkilWgiL5AztbARrrLAt/1lyTLvNSDxHuTGvg8GztYEOXrtOZmkM7f8IY6UTkTUovDweRCyqk97yrUO7Oo0gV7eMQVLWigegEKIpLd/ecCEAKkpnVlEPubu05zOB+HUikLFZmDu3UR6uVw7pIN1v9FPCjJTsggj/rYpEOw93gTWSlwTTotcVOsExeZZhskPVc+QaQw5DXLdB1aWFm35W44MxS41JLv6gAINZ3naJzooU3xdq2QZ+6C+AcKv2VUg8fjz2ZYBmwQjTNsdFVZD63RPPHjPK7gOukVoG1v7sZt1KnzR9l5g== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2017 20:07:47.4863 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB309 Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 20:07:53 -0000 Phil Shafer writes: >Juergen Schoenwaelder writes: >> is one of: Apologies. My brain's still in "low"..... Thanks, Phil From nobody Tue Mar 21 13:23:00 2017 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 EB33D129BE8 for ; Tue, 21 Mar 2017 13:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rdSpSyC76d0 for ; Tue, 21 Mar 2017 13:22:56 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CDAD71296D5 for ; Tue, 21 Mar 2017 13:22:55 -0700 (PDT) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 984DF1AE0310; Tue, 21 Mar 2017 21:22:54 +0100 (CET) Date: Tue, 21 Mar 2017 21:22:54 +0100 (CET) Message-Id: <20170321.212254.1381357367952499259.mbj@tail-f.com> To: worley@ariadne.com Cc: lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <87shm6tn2w.fsf@hobgoblin.ariadne.com> References: <20170321.144353.1304796463767741047.mbj@tail-f.com> <87shm6tn2w.fsf@hobgoblin.ariadne.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] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 20:22:59 -0000 worley@ariadne.com (Dale R. Worley) wrote: > Martin Bjorklund writes: > > Hmm, "*" was choosen b/c people are used to read it as > > "zero or more". So for example: > > > > +---c server* [name] > > +--c name string > > ... > > > > means zero or more "server" elements. Each indexed by "name". > > From RFC 7223: > > module ietf-interfaces { > ... > container interfaces { > ... > list interface { > key "name"; > > leaf name { > type string; > } > > leaf description { > type string; > } > ... > > There is a top-level container node "interfaces", which contains a list > node "interface", which contains a sequence of list elements which > consist of groups of (a leaf "name", a leaf "description", etc.), which > elements are indexed by the value of the "name" leaf. Aha, ok. This description is not a correct description of the YANG data tree (in which XPath expressions etc are evaluated). There is not a single "list node" called "interfaces". Look at an example of an XML instance document: eth0 ... eth1 ... This also reflects the data tree. /martin From nobody Wed Mar 22 08:21:28 2017 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 9F76C129494; Wed, 22 Mar 2017 08:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 4V_DVo-yr5ik; Wed, 22 Mar 2017 08:21:23 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC424126C22; Wed, 22 Mar 2017 08:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=97889; q=dns/txt; s=iport; t=1490196082; x=1491405682; h=from:subject:to:message-id:date:mime-version; bh=0mTDkIe4MNq8Xit2pqKRwH10RTRb5LkZXTfrz5mCyK4=; b=WSuOMmoy4BbtSrvzPPd8xdnBFaqfkstOrPe6upNyWudJZLaz6cj6Yh/a BwTSSQoneVGK6m+aTk5Bpvdq7unBr1OqhiL751kwdOBMrg2v1PYCaaPl9 yKm5/vMcLq7cP/Y++rDRfU/aKPMmHlQ9L9aNEZdVFA8CFH31XXNpqEXXf o=; X-Files: wilton_8023cf_ethernet_interface_statistics_3.pptx : 64597 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+BAC0ldJY/xbLJq1eHAEBBAEBCgEBg?= =?us-ascii?q?m6BRIRsig9zkFCQN4Mggg+CDiqJYhgBAgEBAQEBAQFrKIU/gTMCBFwJAwgBAYo?= =?us-ascii?q?ADqsagiYrihMBAQEHAQEBAQEBARIKBYZOggUIgVmFLxEBAoMggl8FnFGDeoMAi?= =?us-ascii?q?02KWYZWi02IEx84Pj4IJBYIFxWDB4QSQIgIgi4BAQE?= X-IronPort-AV: E=Sophos;i="5.36,205,1486425600"; d="xml'?pptx'72,48?scan'72,48,72,145,208,48,217?jpeg'72,48,72,145,208,48,217,145?rels'72,48,72,145,208,48,217,145"; a="650607418" 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; 22 Mar 2017 15:21:19 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2MFLI7c017221; Wed, 22 Mar 2017 15:21:18 GMT From: Robert Wilton To: netmod@ietf.org, ccamp@ietf.org Message-ID: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> Date: Wed, 22 Mar 2017 15:21:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------17B56203044C4D1245555027" Archived-At: Subject: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 15:21:27 -0000 This is a multi-part message in MIME format. --------------17B56203044C4D1245555027 Content-Type: multipart/alternative; boundary="------------2124FE2F2F59D8B40AFF3752" --------------2124FE2F2F59D8B40AFF3752 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm participating in the 802.3 task force (802.3cf) to produce standard YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3 Ethernet Working Group. As part of my involvement with that group, I want to highlight a couple of issues that arose in that forum that may be of interest to various WGs in IETF. This email, and accompanying slides, represents my personal views, and do not represent any formal IEEE position. However, both this email and the accompanying slides have been reviewed in an 802.3cf task force meeting, and there were no objections to the content, or my sending of this email to IETF. I also raised these issues (with an earlier set of slides) as part of the IETF/IEEE liaison meeting on 31st January, and the consensus was generally supportive of this approach, with the agreed next steps to contact the NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email): As part of that YANG modelling work, there is an aim to define a clean boundary of what manageability data should be specified within 802.3 and what belongs outside the 802.3 specifications. The definition that the task force is converging on is that everything related to Ethernet, covered by 802.3, that can be expressed in terms of the 802.3 clause 30 manageability definitions, should be modeled in 802.3. I.e. broadly everything that is covered by 802.3.1 today. But any manageability information that cannot be related to clause 30 definitions should be specified outside of 802.3. Note, where appropriate, additional clause 30 definitions may be added to fix any mistakes or glaring gaps. To this end, there are a couple of areas between IETF and 802.3 that don't necessarily look like they are entirely in the right place, in particular: 1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related content) some Ethernet specific statistics that would be better co-located with the Ethernet interface YANG model being defined in 802.3cp. Hence, the proposal is to subsume the appropriate Ethernet statistics from the RMON MIB into a single combined reference set defined in 802.3cp. 2) The RMON MIB also defines some Ethernet specific statistics that can't be defined as part of 802.3cf because they don't relate to 802.3 clause 30 registers, but are still widely supported by vendors, and should be modeled in YANG. The proposal is that definitions related to these counters could be added as part of the Ethernet-like module draft-ietf-netmod-intf-ext-yang-03 , or perhaps a related Ethernet module in the same draft. 3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced from RFC 7460), was originally specified in IETF, but ownership later transferred to 802.3 (via RFC 7448). Whilst working on the Power over Ethernet YANG model it has become clear that not all of the attributes defined in the MIB map to the underlying 802.3 clause 30 definitions. Further, it looks like parts of this YANG model would be better defined as extensions to the Entity YANG model being defined in NETMOD. The proposal is that the parts of the Power over Ethernet YANG model that can be directly related to clause 30 definitions (e.g. /pethPsePortTable/) should be defined in 802.3cf, but that the remaining parts (e.g., ///pethMainPseObjects /) can hopefully be standardized in IETF. Do you have any comments, or concerns, on the 3 proposals above? Regards, Rob Wilton --------------2124FE2F2F59D8B40AFF3752 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

I'm participating in the 802.3 task force (802.3cf) to produce standard YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3 Ethernet Working Group.

As part of my involvement with that group, I want to highlight a couple of issues that arose in that forum that may be of interest to various WGs in IETF.

This email, and accompanying slides, represents my personal views, and do not represent any formal IEEE position.  However, both this email and the accompanying slides have been reviewed in an 802.3cf task force meeting, and there were no objections to the content, or my sending of this email to IETF.

I also raised these issues (with an earlier set of slides) as part of the IETF/IEEE liaison meeting on 31st January, and the consensus was generally supportive of this approach, with the agreed next steps to contact the NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email):


As part of that YANG modelling work, there is an aim to define a clean boundary of what manageability data should be specified within 802.3 and what belongs outside the 802.3 specifications.

The definition that the task force is converging on is that everything related to Ethernet, covered by 802.3, that can be expressed in terms of the 802.3 clause 30 manageability definitions, should be modeled in 802.3.  I.e. broadly everything that is covered by 802.3.1 today.  But any manageability information that cannot be related to clause 30 definitions should be specified outside of 802.3.  Note, where appropriate, additional clause 30 definitions may be added to fix any mistakes or glaring gaps.


To this end, there are a couple of areas between IETF and 802.3 that don't necessarily look like they are entirely in the right place, in particular:

1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related content) some Ethernet specific statistics that would be better co-located with the Ethernet interface YANG model being defined in 802.3cp.  Hence, the proposal is to subsume the appropriate Ethernet statistics from the RMON MIB into a single combined reference set defined in 802.3cp.

2) The RMON MIB also defines some Ethernet specific statistics that can't be defined as part of 802.3cf because they don't relate to 802.3 clause 30 registers, but are still widely supported by vendors, and should be modeled in YANG.  The proposal is that definitions related to these counters could be added as part of the Ethernet-like module draft-ietf-netmod-intf-ext-yang-03, or perhaps a related Ethernet module in the same draft.

3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced from RFC 7460), was originally specified in IETF, but ownership later transferred to 802.3 (via RFC 7448).  Whilst working on the Power over Ethernet YANG model it has become clear that not all of the attributes defined in the MIB map to the underlying 802.3 clause 30 definitions.  Further, it looks like parts of this YANG model would be better defined as extensions to the Entity YANG model being defined in NETMOD.  The proposal is that the parts of the Power over Ethernet YANG model that can be directly related to clause 30 definitions (e.g. pethPsePortTable) should be defined in 802.3cf, but that the remaining parts (e.g., pethMainPseObjects ) can hopefully be standardized in IETF.


Do you have any comments, or concerns, on the 3 proposals above?

Regards,
Rob Wilton

--------------2124FE2F2F59D8B40AFF3752-- --------------17B56203044C4D1245555027 Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="wilton_8023cf_ethernet_interface_statistics_3.pptx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="wilton_8023cf_ethernet_interface_statistics_3.pptx" UEsDBBQABgAIAAAAIQBbRM7nJgIAACkWAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEmF1v2yAUhu8n7T9Y3E4xcbe13RSnF/u4 2keltj+A4pOEjS8ByZp/P4yTzquSJilG3ETGcN7zEORzXjG5ehC8WIGxTMkaVeUYFSCpapic 1+ju9uvoEhXWEdkQriTUaA0WXU1fv5rcrjXYwkdLW6OFc/ojxpYuQBBbKg3Sz8yUEcT5oZlj TehvMgd8Nh6fY6qkA+lGrtVA08lnmJEld8WXB/+6I/mlYY6KT93CNleNmGgFwgTeGWOA2ycx RGvOKHF+Hq9k84RstKEqfWRYYxdM2zd+wZ4M7cz+BJu4n/7vNKyB4poY94MIvwpr7bA2YH1c WFs+r7QDVc1mjEKj6FL4kLIvJvh/w1IQJreb2AdjuX/5nVjnj74/qIYm62kfxbShScNxCsFZ doK32QneZSd4n53gPDvBRXaCy+wEH7ITVOP8CPmrYpW/LFZ56qJUDuy2Y/YGg59JT/sQUxt5 bZS2KfxEED5EsGLwJwnBo/AhAuc9J3S/8UcRZA5mJPccbtyaw+C77kkf9Ul8I2u1dJsPoxuk qRGd9kuZ0hSNOKY0VSSOKY3fimNK48DimNJ4sjimNC4tjimNb4tjSuPk4pgSebtIqJyVvNdV 44v3UV012J6bzuf9e07jroL0y4AGb2WxQIP3sVigwZvYcUA+OvhFTJWB0xG2V4Ft9Eh7ITCO Pe/CHjN66eg9Q3vL2EBzam66tE6J6PSdzI7kOFz0Tv8CAAD//wMAUEsDBBQABgAIAAAAIQBH vxrQEQEAAHUDAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAArJPbSsQwEIbvBd8h5H6b7npAZNO9EWHvROoDjMm0jTYHkqnsvr2h4KFQq+BeZuaf j28Sst0dbM/eMCbjneTrouQMnfLauFbyp/p+dcNZInAaeu9Q8iMmvqvOz7aP2APlodSZkFim uCR5RxRuhUiqQwup8AFd7jQ+WqB8jK0IoF6hRbEpy2sRvzN4NWGyvZY87vUFZ/Ux4P/YwiKB BgKhfMRViHk6ksm7sBpiiyS59uohl9OYKDKZi3mhzWmFqBvsswPTz6h89oqXgO1PQuu/C/mm MQrvvBosOprzmia+nEIgESKmXBzTSzd0dUohNSTy9pcnGzNLSpenVMIDodOol6UghA8jMfks 1TsAAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVs cy9zbGlkZTUueG1sLnJlbHOMz70KwjAQB/Bd8B3C7SbVQUSauoggOIk+wJFc22CbhFwU+/Zm tODgeF+/P1cf3uMgXpTYBa9hLSsQ5E2wznca7rfTageCM3qLQ/CkYSKGQ7Nc1FcaMJcj7l1k URTPGvqc414pNj2NyDJE8mXShjRiLmXqVETzwI7Upqq2Kn0b0MxMcbYa0tmuQdymSP/YoW2d oWMwz5F8/hGheHCWLjiFZy4spo6yBim/+7OljSwRoJpazd5tPgAAAP//AwBQSwMEFAAGAAgA AAAhAEv1Pey9AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVsc4zP vQrCMBAH8F3wHcLtJtVBRJq6iCA4iT7AkVzbYJuEXBT79ma04OB4X78/Vx/e4yBelNgFr2Et KxDkTbDOdxrut9NqB4IzeotD8KRhIoZDs1zUVxowlyPuXWRRFM8a+pzjXik2PY3IMkTyZdKG NGIuZepURPPAjtSmqrYqfRvQzExxthrS2a5B3KZI/9ihbZ2hYzDPkXz+EaF4cJYuOIVnLiym jrIGKb/7s6WNLBGgmlrN3m0+AAAA//8DAFBLAwQUAAYACAAAACEAS/U97L0AAAA3AQAAIAAA AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqI IDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6i0Pw pGEihkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9G9DM THG2GtLZrkHcpkj/2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4A AAD//wMAUEsDBBQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTYueG1sLnJlbHOMz70KwjAQB/Bd8B3C7SbVQUSauoggOIk+wJFc22CbhFwU+/ZmtODg eF+/P1cf3uMgXpTYBa9hLSsQ5E2wznca7rfTageCM3qLQ/CkYSKGQ7Nc1FcaMJcj7l1kURTP Gvqc414pNj2NyDJE8mXShjRiLmXqVETzwI7Upqq2Kn0b0MxMcbYa0tmuQdymSP/YoW2doWMw z5F8/hGheHCWLjiFZy4spo6yBim/+7OljSwRoJpazd5tPgAAAP//AwBQSwMEFAAGAAgAAAAh ANgDgmvWAAAAzgEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc6yRMWvE MAyF90L/g9FeO7mhlHLOLeXg4Kb2+gOMrSSmiWwsXWn+fd2lJHBDh456evreA+0PX/OkPrFw TGSh1Q0oJJ9CpMHC++X48ASKxVFwUyK0sCDDobu/27/i5KQe8Rgzq0ohtjCK5Gdj2I84O9Yp I9VNn8rspI5lMNn5Dzeg2TXNoylrBnQbpjoFC+UUdqAuS8a/sFPfR48vyV9nJLkRYSgJ8tsU A1aqKwOKBa1X8trS6soHc7tW+5+1+Cfu7JZ0lU2vlb4x/TYzmy903wAAAP//AwBQSwMEFAAG AAgAAAAhAEv1Pey9AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMy54bWwucmVs c4zPvQrCMBAH8F3wHcLtJtVBRJq6iCA4iT7AkVzbYJuEXBT79ma04OB4X78/Vx/e4yBelNgF r2EtKxDkTbDOdxrut9NqB4IzeotD8KRhIoZDs1zUVxowlyPuXWRRFM8a+pzjXik2PY3IMkTy ZdKGNGIuZepURPPAjtSmqrYqfRvQzExxthrS2a5B3KZI/9ihbZ2hYzDPkXz+EaF4cJYuOIVn LiymjrIGKb/7s6WNLBGgmlrN3m0+AAAA//8DAFBLAwQUAAYACAAAACEAS/U97L0AAAA3AQAA IAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU4LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m1UFE mrqIIDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6 i0PwpGEihkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9 G9DMTHG2GtLZrkHcpkj/2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYpv/uzpY0sEaCaWs3e bT4AAAD//wMAUEsDBBQABgAIAAAAIQDf02QoZwEAALEKAAAfAAgBcHB0L19yZWxzL3ByZXNl bnRhdGlvbi54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAALyW32qDMBSH7wd7B8n9jNrWtqPamzHoxWBs3QNkevzDNJEk6+bbL7RDVLrD LkIu8zM5+fhOQtztv9vGO4FUteAJCf2AeMAzkde8TMjb8fFuQzylGc9ZIzgkpAdF9untze4F GqbNIlXVnfJMFa4SUmnd3VOqsgpapnzRATdfCiFbps1QlrRj2QcrgUZBEFM5rkHSSU3vkCdE HnKz/7Hv4D+1RVHUGTyI7LMFrq9sQVVT52AKMlmCTsh5+JuufVON0OsQ4cIRRRihGFZlaLN2 hHEeXsIQg3ClAjWxdgQRo+2IXJ0KtCGhVRmnGr6epTD3cUAZIozCmQtURWyTopOgZiqGCKWw ruKJKQ1yJuQSTmagcqy6QTq0Qt3Yl/PHOQkwjJUjiiXqwioFFxrU/KCMwskM/BYFjuxsUYqt 1ceOvTfwqvsGRrd5FGIkS0c6FhiEVRsIxAbtiSsV4eCCTn400x8AAAD//wMAUEsDBBQABgAI AAAAIQDERtlQ1wAAAM4BAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEzLnhtbC5yZWxz rJFBS8QwEIXvgv8hzN2kW0RENt2LCAuedP0BIZm2YduZkMmK/ffGg9DCHjx4nDdvvvdg9oev eVKfmCUyWdjpBhSS5xBpsPBxerl7BCXFUXATE1pYUODQ3d7s33BypR7JGJOoSiGxMJaSnowR P+LsRHNCqpue8+xKHfNgkvNnN6Bpm+bB5DUDug1THYOFfAwtqNOS8C9s7vvo8Zn9ZUYqVyIM cUF5n2LASnV5wGJB65W8ttzrygdzvdbuP2vJT9yrW/hSNr1W+sbU/jYzmy903wAAAP//AwBQ SwMEFAAGAAgAAAAhAK05BGDXAAAAzgEAACEAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTIu eG1sLnJlbHOskUFLxDAQhe+C/yHM3aRbQUQ23YsIC550/QEhmbZh25mQyYr998aD0MIePHic N2++92D2h695Up+YJTJZ2OkGFJLnEGmw8HF6uXsEJcVRcBMTWlhQ4NDd3uzfcHKlHskYk6hK IbEwlpKejBE/4uxEc0Kqm57z7Eod82CS82c3oGmb5sHkNQO6DVMdg4V8DC2o05LwL2zu++jx mf1lRipXIgxxQXmfYsBKdXnAYkHrlby23OvKB3O91u4/a8lP3Ktb+FI2vVb6xtT+NjObL3Tf AAAA//8DAFBLAwQUAAYACAAAACEAI/NwpNYAAADOAQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMv c2xpZGUxMS54bWwucmVsc6yRMWvEMAyF90L/g9FeO5ehlHLOLaVw0Km9/gBhK4lpYhnLd1z+ fd2lJHBDh456evreA+0P13lSF8oSOFrY6QYURcc+xMHC5+n14QmUFIweJ45kYSGBQ3d/t3+n CUs9kjEkUZUSxcJYSno2RtxIM4rmRLFues4zljrmwSR0XziQaZvm0eQ1A7oNUx29hXz0LajT kugvbO774OiF3XmmWG5EmMiF5GMKnioV80DFgtYreW1pdeWDuV1r95+15CfuDRc+l02vlb4x /TYzmy903wAAAP//AwBQSwMEFAAGAAgAAAAhADMOHgTAAAAANwEAACEAAABwcHQvc2xpZGVz L19yZWxzL3NsaWRlMTAueG1sLnJlbHOMz71qwzAQB/C90HcQt1eyM7SlWM5SCoZMJX2AQzrb IrIkdHKI374abejQ8b5+f647PxYv7pTZxaChlQ0ICiZaFyYNP9evl3cQXDBY9DGQho0Yzv3z U/dNHks94tklFlUJrGEuJX0oxWamBVnGRKFOxpgXLLXMk0pobjiROjXNq8p7A/qDKQarIQ+2 BXHdEv3HjuPoDH1Gsy4Uyh8Rir2zdMEtrqWymCcqGqTc9w9Lb7JGgOo7dXi3/wUAAP//AwBQ SwMEFAAGAAgAAAAhADMOHgTAAAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlOS54 bWwucmVsc4zPvWrDMBAH8L3QdxC3V7IztKVYzlIKhkwlfYBDOtsisiR0cojfvhpt6NDxvn5/ rjs/Fi/ulNnFoKGVDQgKJloXJg0/16+XdxBcMFj0MZCGjRjO/fNT900eSz3i2SUWVQmsYS4l fSjFZqYFWcZEoU7GmBcstcyTSmhuOJE6Nc2rynsD+oMpBqshD7YFcd0S/ceO4+gMfUazLhTK HxGKvbN0wS2upbKYJyoapNz3D0tvskaA6jt1eLf/BQAA//8DAFBLAwQUAAYACAAAACEAS/U9 7L0AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU3LnhtbC5yZWxzjM+9CsIwEAfw XfAdwu0m1UFEmrqIIDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53 Gu6302oHgjN6i0PwpGEihkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE 88CO1Kaqtip9G9DMTHG2GtLZrkHcpkj/2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYpv/uz pY0sEaCaWs3ebT4AAAD//wMAUEsDBBQABgAIAAAAIQDH38VwJgMAAM4PAAAUAAAAcHB0L3By ZXNlbnRhdGlvbi54bWzsl99u2jAUxu8n7R0i3040/0NAhAraMU3qJlS6B3ATA1GdOLINhU57 9x0bBwyppkq75QrH3/Hn459l4zO63VXU2RIuSlZnyL/xkEPqnBVlvcrQr6dZL0WOkLguMGU1 ydCeCHQ7/vxp1AwbTgSpJZYw1AGbWgxxhtZSNkPXFfmaVFjcsIbUoC0Zr7CET75yC45fwb6i buB5iVvhskZmPP/IeLZcljm5Z/mmgukPJpxQnYdYl41o3ZqPuNmrOE9J4C1ZbJ4FkTNWSwF0 0BiWLWjxAwtJ+PfiQciLHqcsMhT4UT9KwyQCdnyoekDxkTseue8Nr5kk4l99lklsXN4bA87n 7UMycWJlEajxZ3LfTjK8lEMvtuSoK0eWrJM7lz1LTrqyb8n9rhxYctqVQ0sedBY2OKPvdfT4 TNfbc6andu5+F1w6sPUOuWBgL87X6A7bb2/S4s3Jdxka+FHkKVj5PkNJGqf6Q+4bOHEi54TU 0c7MoHfeDDtGqmGth44qyBJvqHwiO7mQe0rGI6z65nNuWo9z7lCsDvnbunf3U2dnh9At9RuI qTB/yBBMgekKLgiKHIh5ws+Lt3ZGWKWkOoTgh3rKX9RBcdRxrM0nSGuYCs78fFPn8nCQjlkI cPJT5fNCuLqD4AhqXTBaFrOSUv2hTjC5o9zZYphN7g7n6SJKz6q5LXEO7L5UdY9KFYmHBF8I BB+EXFwIuTjheFQ43CMPgyY4oYnivkr4ykdDMXzCE58WwpWPgmL4RCc+ftj3kyuglooBFFuA 0iDV2V8BKSoGUHICFARpov8FroAUFQOobwHqR+H1jj5SMYDSEyBF53pJH6kYQAMLUBL3r5f0 kYp+yXafmM0Q2uZtCy1nw8sM/f46m8ymQRj2vCSc9aJgGvdS+NPrDe5n4Sz2pxPfm/xRlZUf qxfxt01ZEDBpazg/7lRxVZlzJthS3uSsMuWg27BXwhtW6orQDw413MF1pSz1oxy2hPESyj3w ZPwNOQ0Tql5LFGsVmlO9+4Kvno+UJ9EknJj3exuiW9r3coqgNYU/rf8w1W0Lh0YOUNvftssu X8d/AQAA//8DAFBLAwQUAAYACAAAACEA9fuVaIUDAADsCwAAFQAAAHBwdC9zbGlkZXMvc2xp ZGUxLnhtbLRWzW4TMRC+I/EOoz2BRLvpbpqWihSVkFRF/VOaCnF0vE5jsWtbtpsmfQHEG3AD cePEE/A4gHgLxvZuQkMKobSXtdc/8803M/7sJ0/HRQ4jpg2XohmtrdYiYILKjIuzZnTa66xs RmAsERnJpWDNaMJM9HT7/r0nasvkGeBuYbZIMxpaq7bi2NAhK4hZlYoJnBtIXRCLv/oszjS5 QKtFHie1WiMuCBdRuV8vs18OBpyy55KeF0zYYESznFj03Ay5MpU1tYw1pZlBM373FZe2kRk9 yTPXGtXTjLmeGO1qdaKOtZ8+HB1r4BnGKwJBCgxLFJcT5TL/K0a+E89tP6u6ZGs80IVrkRuM mxEGf+K+sRtjYws0DNLZKB0eLVhLh+0Fq+MKIP4F1LEKzv1OJ6nofPvw5sfHd7A2pVU5bNS+ pK8NCImEHP/Ab7oikHatGoKdKLRFre5xm7NyaZj3nZlDZcDs+JnMJg6nj21AFHLn3MoBt4HQ bCI39sROcuYDoNzHD2vkkhNXvUysnJ5EQHK77/8vhyutQ6zmy2aUYr4jyLi2PlZgCtvKGRHT gNrtzVqymoKDtB44GL8pQmm0bYdMC2Zvze4iz/eEZXpAKINXO4e70CPmNXSkpux2yYR8eCP9 /zHlknorwX3gU0YHDwHlCroHR4dwsPfsTkP9oNtpQdpI1x/Oodw8IvMw/x+ehY7v5EbCsbxg GiTKP0wr09XMPBsmsmOiSXcKXoJNwUtnrk2w8ie+Ot5xpUHXK1FaKdHXt59LMUpuQ4zMeT+I EaKMZ1v+XZR0cQeylNT/mriu7MNLnlspruQoxPguAFvcULkA69/yWa/y+f39p69fPkJ6JZm/ 3Za/JmHBPZnWN9frjU1/A64nyWNXclfuzHRjfSOpN8Jd2Kg30jRkemZJaWN3mSzAdZqRZtRG bpyM9k2Z02pJSTB4NF8NcKEJ1p7Ax5Hfb5Sri84ydYEWMSlnwl+Rwf/lMvfHfCW1tQ14QQSk tUew1+514r12uw05J9xIcTM1/CNgwZjFd9315Xg3PE9VRizLINmADuuDo31D1VpGq3wTHoNO Ycr3Ic31AVFHIw+HD028d1t+SGFASjGaLUGjvMAJ3xNYZl6ZSDgpPVE9KLNzfA5zkbEBF9yi UuFL1RKNRSoYKjUeJJmxnlczW3SltKWGeUvO82Da9Uo45zw6/BMAAP//AwBQSwMEFAAGAAgA AAAhABhrJVzMAwAAKQkAABUAAABwcHQvc2xpZGVzL3NsaWRlNS54bWy0VkuP2zYQvhfofxjo 1AL1SpYfaxvxBmvHXiywL6ydQ4+sRK2ISCRB0q8UBXJpc8opl/YW9NBT0XsP/TNBt0X/RYcU ZXfjXTRB04tIkcOZ75sZzvDR43VZwJIqzQQfBs2DKADKE5EyfjMMns6njV4A2hCekkJwOgw2 VAePjz795JEc6CIFPM31gAyD3Bg5CEOd5LQk+kBIynEvE6okBn/VTZgqskKtZRHGUdQNS8J4 4M+r9zkvsowl9IlIFiXlplKiaEEMItc5k7rWJt9Hm1RUoxp3+g6kI2SWzIrUjlrOFaV2xpcn Ss7klXLbF8srBSxFfwXASYluCUK/4cXcL1+6SfjO8Zt6SgbrTJV2RG6wHgbo/I39hnaNrg0k 1WKyW03yy3tkk3xyj3RYGwj/YdSyqsDt04lrOn+8efnXj99Dc0urBqzlmUieaeACCVn+Fb+t REXajjIHs5GoyzBTUC9XbbrJDo33llmPRLqxRr7CsTLHMWLHCyMyZio+u61Cm5nZFNTxl/bj lhVSKYhNXsobT2cBkMKcuf/neWN8EUDKlHEOAl2acUEJ33rRHE1MThWnBnpRfNCCL48vTuDt i9dwfX55AeenIwvBOCDOGOXpFVHkemvT29ja9Bi2NisS0rmg5hvWEXk4Lq06LrfffXv7y6+3 r978/turP3/+CeL/FiCWrnciD8TmnjRtdw7xvrj8a3ajyM7vZGyv1W3Fh3GVie1O3Ol3W+/m Y6X6X6MOmeBmlpACyffjTmXpg/PgZPSBeTATJYVtMrgqQ1NbBw3ThiUaiKKQ0oxxXGYcUHKb I/DZ9XQMca/Z//xOulSBrz8W3rLw3v8omC8zkEQhukVBMG24oVjiDDDt0NVkGrMdiRslFvJh jB8B0zxH89YnqaCav33xgwHBi4133b6HU2LIF4DdBsSKY1PCsg4rYrPZgFGEa2brNQoaAaeT yaS6p/8rBWchyWAlFtjvCvaMWuOegCsQ2FZA24QR2R1XQyIWNgoasNksmVjoLfO9pLmHwn6J cEPdkfCynWnjZ7BQbBh8PRr1u/G4N2qMmu1po/2kf9g4nnY7jWmn1W6PR73jcWvyje1wzfYg UdQ1v9O6iePiXuMsWaKEFpk5SETpO3AoxYoqKZhrws3Id/IlwWyOW81e1O23orYvKoitHh1a W4p8c00KdU7k5dLFCI2hp8ZuSeIrwVetnQg6g5W44WbcM8d8d5rmvO7G6QLfEow7LzNDA7B3 AG/FMOAUXzlYR0VK51VfKq+FMB6n02Q9Xqm2M2/OOh0B/w0AAP//AwBQSwMEFAAGAAgAAAAh AJJ1fsJzBAAAbwwAABUAAABwcHQvc2xpZGVzL3NsaWRlNC54bWzkV81uGzcQvhfoOxB7SgBL u/qXjMiBpUiOAccxLOfQI83laolwSYKkZKlFj21PuecY5NBT0XsPfZu6Rd+iQy5Xsh3bTZz0 VAMWKXI4Px+/GY6ePF0VHC2pNkyKYdSoJxGigsiUifkwenU2rfUjZCwWKeZS0GG0piZ6uvf1 V0/UruEpgtPC7OJhlFurduPYkJwW2NSlogL2MqkLbOGrnsepxhegteBxM0m6cYGZiMJ5/THn ZZYxQp9JsiiosKUSTTm24LnJmTKVNvUx2pSmBtT409dc2oPIyIynbjTqTFPqZmJ5oNVMnWi/ fbw80YilgFeEBC4AligOG0HMfxVLP4lvHJ9XU7y7ynThRogNrYYRgL92n7FboyuLSLlItqsk f3mLLMknt0jHlYH4ilEXVench+E0q3D+fPfT3+/fosYmrMpho44keW2QkBCQi7+MbyNRBu1G lSO7VqDLMstpkCs3/WTrTUDLrkYyXTsj5zCW5gTc2P7CyoxZlElhZwRzUDlI4C9EuBXmxs7s mlOPiHIffllDcBw7OlNRezWLEOb2yH//Nq+NjyOUMm09ZMgUdswpFhtc7d7E5lQLalE/adZb yFm03m6p+/MNjDleGIpaCRph8nqu5UKkN6xQkZ5gjU83doLejZ1gd2OnREZ5pCtY4+ri777+ VnX9lz/+cPnrb5dv3v3x+5u/fvkZNT+PByxdbUXuoMAt2dDu9CAtPc0b3SRx82uJ0W91W81e syR8u9PsDLqtm7QvVX8SufodRy7ExUyRU5ouiCsR4MKDOXcwejAlZIYOJ5NJIB8zCAvEhAVG Yo4KLPCcumKI9k8OIQQNZniQLWu2Tg0islCcYZDacDmlSyilpn6NZyVjvlwUz8H6BdYUMbDv 3SxLtQuq9LFYGLvd9c7DHjiJsFJaKs2wpUhhbf0hsoHlkZFFteEsSOU0Y/54B7EMmYVSUlt4 a65A9N/GOgtobyG+cjmFTCk36BGtz+todvziZAd9s3988Ni7fqGZtVQgK7fx3eOrcm4uuUsn T+bFFIjrC22GCZB3LBeaUY2O6UUEAAlpYBFSp5e0kgGMzaQD/+2kDbvMknyKC8Zd+gwgjXKs DbWbsM4XY1jxy8NIVkWl5P0XwOwKsbdkDVj9a5m9zdq5f4/vtekY9yDd92pFUvA18r0IdReZ McohlpRmTNAUEvb/drVnOV0jArXqnLryc+5g2IHalcJ7UeZ5gMhXABACcNLr0Nzy6n2qJ3c9 gX6oGjt4TI6MDTMECA+j70ajQbc57o9qo0Z7Wms/G/Rq+9NupzbttNrt8ai/P25NvneNYqO9 SzT1Ze2w6oVh8YP+s2BESyMzWwc0QiMbK3lBtZLM97KNJDTESwwM6DUavUG/1eyENxNcq0bv rHtpQ4tKuH6B1culhwxswdsw9ksK6l94lLcigAUrYMPPRAgc6qjXdCaqnjZdAC2Y8ARmlkbA bUhRDfwRFH4rQJsAaXpWdnfFqZQ2+Ok1OcBL1W4WzDnMweF/AAAA//8DAFBLAwQUAAYACAAA ACEA/9xu/wAEAAASCgAAFQAAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbLRWzW7jNhC+F+g7DHTK AmvLkn/iGOssbK8dBHCcIPEeemQkyiJCkSpJO/YWPbY97b3HRQ89Fb330LdpWvQtOqQke50f YBfNXsQROZyZb2b4ka9erzMOK6o0k6LvBfWGB1REMmZi0ffezie1rgfaEBETLgXtexuqvdfH X3/1Ku9pHgPuFrpH+l5qTN7zfR2lNCO6LnMqcC2RKiMGf9XCjxW5RasZ98NGo+NnhAmv3K8+ Zb9MEhbRNzJaZlSYwoiinBiMXKcs15W1/FOs5YpqNON274V0jMiiKx7bUedzRamVxOpE5Vf5 hXLLs9WFAhZjvjwQJMO0eH65UKq5X7Fygn9v+6ISSW+dqMyOiA3WfQ+Tv7Ff387RtYGomIx2 s1F6/ohulI4f0fYrB/5HTi2qIriHcMIKzt8ffvr3l58h2MKqAtb5VEY3GoREQBZ/gW+rUYC2 Y56C2eRoyzDDaalXLDphF02ZLbMeynhjnVzjWLgTWLHB0siEmQLPbolrc2U2nDr8uf24aYVQ OLHNS0Xt7ZUHhJup+3+X1kYzD2KmjEsQ6MyMOCVim0VzPDYpVYIa6DbCehO+GcxOYE70DUyk iqgNwLgwnCsq4guiyOXWY+lh67GMYOuxgJC7BFRo/aoeT1elWVXl7scf7n7/4+79h7/+fP/P b79C+P/Kw+L1TuWJyjzSpK32IZ4W131Bp9Gw8l6/dpudZngYFn3Yaofto07zfjcWpr9IzU+G n1nz0/F4XNQ7SoBpiGnCBBIVbJvBtUEmY8p1b68HimpWH4wiI2q6yxBfcUcRTMRINdalQ7qc IZOWvVDgegYU4/qiDtdEs2gXNxOGqoRE9CVcyFuqQCLRb5dx8nyGn3SDmwiHKRM3cD44g4OP DACKkDClDWSM0xdPw38GDAPg0oBMIJIYuTBwSzQgUa+YXGq+KSpDYxvWiig7CWenQw0H1IK/ dzo/Nx6qlCvWU6zA2c19AngGyBYA1OByMoKw02l/2fzOU7zzipRhN1CQii2YIHw/tafj+eQl XC8N6OW1pt8usRKoYRQRmtnrEtWMhN2xgYMVIw7CYavVfVEHmMnbfYuVaj2oP4LwIR26obp7 kVim2pQSLBXre98Nh0edcNQd1oZBa1JrvTk6rA0mnXZt0m62WqNhdzBqjr+3d3nQ6kWKumv+ tHqu4OSDJ0LGIiW1TEw9kln51vBze2pyydxzI2iUb5YVscc6DJph0AjaJX9iaNXogrWsW74i Iq7OSH6+chVEX3goR24qR5YpCXqngrlgGS44SZTAc1LcCXNRPTviJbarJRZLVoZ6gO8ZQxSy jKB4yvHKQL6aFxdwdimlKeN0lmzCC9NWKt3ZnGPA/wEAAP//AwBQSwMEFAAGAAgAAAAhAPv2 3z7QAwAAIgkAABUAAABwcHQvc2xpZGVzL3NsaWRlMi54bWy0VktvGzcQvhfofyD2HGml1cO2 EDmwZDkI4DpG7PwAZjnyEuGSBEnJUosCubQ55Z5DCwQ99FT03kP/TFC36L/o8LFS/EINNAUE cXZ2OO/5Zh8/WdWCLMFYruQ467Y7GQFZKsblxTh7eX7U2s2IdVQyKpSEcbYGmz3Z//KLx3pk BSN4W9oRHWeVc3qU57asoKa2rTRIfDdXpqYOH81Fzgy9RK21yItOZ5jXlMss3TcPua/mc17C oSoXNUgXlRgQ1KHntuLaNtr0Q7RpAxbVhNvXXNrHyMozwfxp9bkB8JRcPjX6TJ+a8PpkeWoI Z5ivjEhaY1qyPL1IYuFRLgOR37h+0ZB0tJqb2p8YG1mNM0z+2v/nngcrR8rILLfcsnp+h2xZ ze6QzhsD+SdGfVTRudvhFE04f354+/dP70l3E1bjsNXHqnxtiVQYkI8/xreRiEH7U1fErTXq ctwJSHLxZSC23qRsudVEsbU38grPaE5ixQ4WTs25i/FsXwnrztxaQIhf+7/ANhiKoL55QbZe nmWECnccnr+uWtOTjDBuXEgQsbWbCqByk0W3f8htKSivwXhjLpgMakGyU2roi432pG2jPVnb aI/u6hBsE1ne5P7+CvSaClx9/93Vr79dvfvwx+/v/vrlZ1L8t1JwttqK3FOFOxqyP9jByQid 1h12Op6+1pu7vWGv2Cliz/UHxWBv2LvZeVH1Z6gv6iE1NceheFwyHF9PBo2LE0SnlPN4/3Y3 PJ1cr48v8Mc3Pxw4IqB0CwSER8Sua60sp0hBzSU1yFOGAFuUASqoIKVaGOtlqfRe8CVnC2Qn QEGEQ25EGpQn+Hs2m80Shhpmia2oEBjIayAcs4gdaIirqCMVt95WBYYsOVx6SbVAjH0FaFNa zsAAQ1EgGvE6+BLl1Dwq+MQbQ53Xg2wZbgSH0EmMzbv1iMBKY2KCjyFCLh0YjCEiYlQJwfUb k/Aveb1rqtof3/x4TUucjP+xrA3+N0lvcwAIuM+1ydlmym27crX4XL7dAonk3YMh6D7ECEez inD2jq1LFFkYPs6+mUz2hsV0d9KadPtHrf7h3k7r4Gg4aB0Nev3+dLJ7MO3NvvWrrdsflQZC jZ812xuZtzZmzUujrJq7dqnqtHpzrS6xRxQP27fbSSt8SQXiVlH0OzvdohPHP/jWnMFbj0xp q5bCfEX182XIGRrDxpsGlsbhSSC2FcFkcJzEi0DJFLmmETfPZbOG2QI/InyF5lxyBxnBcXTU YLkk4OcNwqpicB4XUv1CKZf8DJp8xqNqTyVzPuno8D8AAAD//wMAUEsDBBQABgAIAAAAIQCK N+s3jwQAAHIPAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTYueG1szFdLbxs3EL4X6H8g9pQAkVZv y0LkwJIlw4BfsJRDjzSX6yXMJQmSkqUUBXJpc8opl/YW9NBT0XsP/TNB3aL/okPurmTLdmLX QhpAWI74mJnvm+Fjnr+YpRxNqTZMim5QLVcCRAWRERNn3eDleFhqB8hYLCLMpaDdYE5N8GLr 66+eq47hEYLVwnRwN0isVZ0wNCShKTZlqaiAsVjqFFv4q8/CSOML0JrysFaptMIUMxHk6/V9 1ss4ZoTuSDJJqbCZEk05tuC5SZgyhTZ1H21KUwNq/OprLm0BMjLikWuNGmtKnSSmu1qN1LH2 w4fTY41YBHwFSOAUaAnCfCCf5v+KqRfCleVnhYg7s1inrgVsaNYNgPy5+4auj84sIlknWfaS 5OiWuSQZ3DI7LAyEV4w6VJlzN+HUCjh/vX/zz88/ouoCVuGwUfuSnBskJABy+DN8ixkZaNeq BNm5Al2WWU7zedmgF5be5GzZWU9Gc2fkFNrMnICIbU+sjJnN8CyHuLEjO+fU41fu47s1QOHY JS8VpZejAGFu9/3/V0mpfxigiGnrCUImtX1OsViwaLcGNqFaUIvalVq5jr7ZPtxFH16/QycH R4fI2bfei8zS480d7PVWlFIRHWONTxZqczULtbmZhdqMFuVJLRgMixjfHel6EenLH76//O33 y7fv//zj7d+//oJqjws5i2bLKXdE+5bEbzQ3YAf6jK62KhUnX9sD7XqrXtuoZbndaNaam636 aoZnqj+ZRyiWwo4I5gB+s9Z0VrkYKXJCowlxpwG4UKlkDjw44XZ7D8yAHSk+vP7JIgUqkBQo ojETcEpeTUA4tkApRzLO8hCyBi0SlciJsHB8d64lUpYSxcd5OOV5XNbi9pHgc2QTaSh8sUVY U2QmSkltaYRO52giIqr53CFZ2VOE4wksq1dyrP74Rk8uEkYSlOI5OqUIwg4bgUZP/39QlgHz cM3QKRbWRSiVgEygBOvoAmZ8Vg89gyRGSksFbprMTyNTumTZX4kQhJhRHhkPwhMNXUygvcF4 iE6GfWCclWl5Fa6Q9hmCdCNYeBFiYZmLKCbnyEpYPhisxvHzBmmc0Bw+5ogZ5xSOIkBAUydD ++lz2hk99Zf3R00xt7FiTKgp/SeVVGvfc4tqmkdrXa6WODunLjUnnD67HwEf1WcToBZ+D9OU Lz6lbttfSbp1oYQXZGzXHgtGbby2OKzbOcgRiOoX6x5skS+XO7hF1ubbHBY8fluhJ3tw26cI 7no8gaNXuzvd7zWf2k9Xd8qN1+BDT8y7noa+KWob4Gnf2FxCE826wbe93mar1m/3Sr1qY1hq 7GxulLaHrWZp2Kw3Gv1ee7tfH3znaqVqo0M09WXUXlEOQueNEixlREsjY1smMs1ruVDJC6qV ZL6cq1bymnCK3Y1RbTfq7Vqjnb8lwbWi9c66F2hepRGuD7A6mnrKwBac2n3fpeAcyh+ryynA BUthwEsiB65w9j4ei6KsiyaQV0zkbxQawL0KZbC23UBQKJfh+QzvgHFW4KQnUtrcT6/JEZ6p dlJuznEODv8LAAD//wMAUEsDBBQABgAIAAAAIQCeqE+h3wMAAJgJAAAVAAAAcHB0L3NsaWRl cy9zbGlkZTcueG1svFZLj+NEEL4j8R9KPoG0GSfOY5JoM6NJJjMaaV5MskIce9vtcbN2d6u7 nQcIicsupz1x4bjiwAlx58CfQQyIf0F1206Yl9gVq724y/2oqu+rz11+ur/KM1gwbbgUo6C1 0wyACSpjLq5HwbP5UaMfgLFExCSTgo2CNTPB/t7HHz1VQ5PFgKeFGZJRkFqrhmFoaMpyYnak YgLXEqlzYvFVX4exJkv0mmdh1Gz2wpxwEVTn9ducl0nCKTuUtMiZsKUTzTJiMXOTcmVqb+pt vCnNDLrxp2+ltIfI6CyL3WjUXDPmLLE41mqmLrVfPl9cauAx8hWAIDnSEoTVQrXNv4qFN8I7 x69rkwxXic7diNhgNQqQ/LV7hm6OrSzQcpJuZ2l68cBemk4f2B3WAcJ/BXWoyuTuw4lqOH++ +e7vH3+A1gZWnbBRp5K+MCAkAnL4S3ybHSVoN6oU7FqhL8ttxqp95aI3ttlUbNnVWMZrF+Q5 jmU4gRU7KKxMuC3xbJcyY2d2nTGPX7mHn9YIJSNOvEw0ns0CIJk99e9fpY3JeQAx19YTBCa3 k4wRsWHR7k1tyrRgFvrNaKcNXxycH8Pv334PnxXMeJ25HKzPxEdjIr4kmlxtglZBNkGrJDZB SxTKc1ADDuuSPF6Ydl2Ym1cvb3759eb1mz9+e/3Xzz9B9P8qxOPVdssjxXlAp53uLn4wXoCt XrPp7FuS7bd77Wg3KqXY6UbdQa99V5Cl6/8sO2RipugViwvqCoABm80y3Dur4Xj8jmo4MUDE Gq89IEuiGcjEvYNCjwasBCoF3pwWUDRwdXZxDmcnYzfvZLN/SyllzeuHS2qRVcS/n0wTMBKW KacpfH78BM6n87OLww+eg025gaXUL2BJDDAkB2Kk74ljSHiaNh+Yv7lZjBwWwmL7cQb2ky8L Y+E5g4wlFmRhdx6H8B5SPpRsU+JPFNGW0yIjOltDomUOJ9P50aeQkgXzdacyd53HgNSu9BSB oO1wIWqilJaEph+Yc+DInoid6nRxJxVYcOJJL9WAwgCsypJl2UOs3r+Q/FA3QPy0T42tLCg0 HwVfj8eDXjTpjxvjVueo0Tkc7DYOjnrdxlG33elMxv2DSXv6jWuorc6QauZ77Un9z4CT9/p0 zqmWRiZ2B7muGn6o5JJpJbnv+a1m9eOwII7IQXcQtVpR1KuuMMytHn227uKrejnN9BlRFwvP OgZD0U38lMKfkuqO3G5BMniOC94SFXJUiPc0F3Xzjwv8deEiZgkX3LIAZY0/S9qOAuHUj7e2 jNm8bIP5lZS2ytN7coyXrp1VhXOkY8L/AAAA//8DAFBLAwQUAAYACAAAACEAgV48ThMFAACL EQAAFQAAAHBwdC9zbGlkZXMvc2xpZGU4LnhtbNRYvW4jNxDuA+QdmK18wEmrf8vGyQdLlg0D /hEsXZGS2qW0jLkkQ3JlyUGANEmq65PukCJVkD5FXiaIE+QtMuTuyrItO5YtHxAVWopLznzz cWY4ozdvpzFDE6I0FbzllYslDxEeiJDycct7N9gvND2kDeYhZoKTljcj2nu78+knb+S2ZiGC 3Vxv45YXGSO3fV8HEYmxLgpJOLwbCRVjAz/V2A8VvgCpMfMrpVLDjzHlXrZfPWa/GI1oQPZE kMSEm1SIIgwbQK4jKnUuTT5GmlREgxi3+wakHbAs6LPQPrUcKELsiE8OlOzLnnKvTyY9hWgI fHmI4xho8fzsRbbM/eQTN/BvbR/nQ7w9HanYPsE2NG15QP7Mfvt2jkwNCtLJ4Ho2iE6XrA2i 7pLVfq7AX1BqrUrB3TWnkpvz14fv//npB1Sem5UD1vJIBOcacQEGWftT++YrUqPtU0bIzCTI MtQwkq1LX7rBNZqMLTNti3BmlQzhmarjcGK7iREjatBIcNMPMAORWyX4ZBZeL2ba9M2MEceI tF9uWoFxDFt3Jrzwru8hzMyR+30ZFTonHgqpMo4ypGPTYQTzOa9mp2siojgxqFmqFKvo892T A6vVON1O/vCZWqwNqYhHydGXLa9mzX8Yd09cEIUERDaam7BxC/nTFRKlnPMvVdxdm5ol4l/d Ek542MMKn83FZ+Lm4jN1c6Ep49J5Ye5yfh4U94dGNQ+Nq+++vfr1t6v3H/78/f3fv/yMKs+L ERpOr5fcEx5LMkWtvlmxXIFJ5UapZMc3kkaz2qhWNitpMqjVK/WtRvV2SkhFrxR4my7wEON9 GZyRMAls+oS88eR4PGivGI99GlOG4Uy0TshrNEwMohyBhyNF7DVG7HbicH12w1XSQ18fEJcP imUUJErBRcJmSFxw7ZD8p/8/rOyZwbWyJej4sI02hKJjyjEDQx6lYjGg7PKz/c6KG5dhqTYq 5dshvgYTU0cJBdH8j29+NCjCE+KOKuEhUWwGdQkKGE7AfaolFJIR5dTVFcgIpBMphTKgkSEx QtQU73csaWFOWBbSa8E+AJi9ftfv7SEHg/K0jgF4j8joT3Y1SUzU06QHKgd4yMj6D+UV0pFI oIgckpRyEtpYdoEVjD46x9LdmPawIQQ+IsnHUHUC0afDLyBt6Zfw/ZfFfyIMhcrccdWBq0IJ 9tIOw4VZ1WnWoP7QICYEXOyMnhOkRUxsOrBZZNFbhsQmE0VsrFpsGn2ZUEMgvQhNwLMwo2ML GhKL3drlUB/PbAp+jaDLcnNYaxFQbLdnr23ZiWIRErZw36SaQrj2GDQ4joaT7uD4dO+B/LQG GnpKSDAFGczOLYALaqIUdmIioXROyiJ06P1GxtmXInRplQBxI4SlBIHKmoskVma+//92iy6e UZ7W8sN2HEEptWEpAPY0HTpX0MKuSvtrFdLLxVN89cAx3ql6V0V8XwnsHnnTC8XkkTbZCCWK tryv2u2tRqXTbBfa5dp+oba3tVnY3W/UC/v1aq3WaTd3O9Xu17aJLte2A0VcTBzm/xPA5J3e PKaBElqMTDEQcdbk+y4XS0Fdn18uZX8WTDAk/VqzUas0641aVjMDtPzpwNpKO2vfA6aOsTyd uNMFXYaojpuS4LdZUX69BLiA2pKP3YhnhoNHOkkDnvf7YQJ+RXlWIxAPQh3OT5mWx20BCm0C uMAg7XzjMyFMhtNJsoSnou0oU2c5B8D/AgAA//8DAFBLAwQUAAYACAAAACEAwi7AuZ8HAABS mgAAFgAAAHBwdC9zbGlkZXMvc2xpZGUxMy54bWzsXcluGzcYvhfoOxBzKFLU8mi3rUYuLCUq AniDLT8ANUNJhGfIAUkpUoIc255y7zHooaei9x566bM0LfoWJTmjNbJsOZJlS78NaEazcPn+ 7fs55Oj5d70wQF0iJOWs7GR20w4izOM+Za2yc1WvpfYdJBVmPg44I2WnT6Tz3eGXXzyPSjLw kb6byRIuO22lopLrSq9NQix3eUSYPtfkIsRKfxUt1xf4tS41DNxsOl10Q0yZk9wv7nI/bzap R15wrxMSpuJCBAmw0i2XbRrJQWnRXUqLBJG6GHv3RJMOdc+8y8A3WxnVBSFmj3W/F9FldC7s 6dPuuUDU13g5iOFQw+K4yYnkMvuVde2OO3V7a7CLS72mCM1W9w31yo4Gv28+XXOM9BTy4oPe 6KjXPptxrdd+OeNqd1CBO1ap6VXcuE+7kx10558PP/33y88oM+zWoMEyOubetUSM6w6Z/sf9 G14Rd9psozZS/UiXpagKSHJdfNLujFqToKV6Fe73TSUNvY2rY1piRx3Fm1ShJmfq0sOBLvIg rf+SHo4uDqS6VP2AWEQi82EPC925ABt1Jix1dekgHKhj+/1NO1U9dZBPhbKQIRmqakAwG+Kq DvfT2d0ceqnaRDCiUE1ofFxTr7K1xzUsWA0RwqrOjOrO2/3PLHxGoajKO0xpG58quvGZZRv0 F2ijfFN2chktuPmtfVblYYMy4qN7ITGrljmAW8kG9JosrbJZAjh5VUHah6KLk7NT8+XrqdoI 88+xwBfD+pLyh/Ul9c+oL5ZDZK1qYELuwMhvNvXcwNQ//vjDx9//+Pj+w99/vv/3t19R9vNs nvq90SU3mPsMz5cv7GVNt3SXMsV02uxPOMH9XDGX3cvGzi1fyBYOirlpFxcXfZMjSdzI7U4j aWCjc6oDXoJufOjuOpHJm840rNLN1gxbt44+zHrJJva0KKo6kPEA60AWYcalPqKBqKSL6QO9 zabz6Zz51Gep8to1HNLAgHGgQWljIYkahQ48VuqRoDhAV4zqqE7QyeUnpedt6fH/dOm5/Fjp qUx2P4k3cvnNNrYQ46wO620qkZd4LYQFQRoo7PvUhGukONJWe3/3MFs6s5wESGmelChRzSUL AcC/K/gpaozDFC8NQVdUKurJ3Ql5xIFh1X4N5DTXSMBC1oT80D5Sxj6IOzSY+/F3iBzLEw1J 8imwjTUJwG2aRNYaRhw4SmsIHCCvO8sLaQKcUlzhIMU9RZREo7+EJxfzO0umxCCSuSbkoroR yLLzEDCKu0pAEI/QLvFRo680Cwblfzjon7U499E3qIH9ybEsiByPN3IA7V2zLKJrNT0GD4bw cIYAnAk4E3CmhDNBMIBgsMXBALz+wycLoO1rEgBkaU8iS4OQDCF5ix9oa33lQqaa3nBwG7K0 dWVpxTz6KlDflleUJgD+t7ghUPcnmwuAy78z8qtwMYD4PMQzhcz+jnlqA0q/LhFUL6qICw0t bTGzkuW2qeDTohibCr5mUawIqRECkKhCogpSgET1cSaqQienkKiuOVEFV7RpySpgf/dgbBIo VMwDhQQKCRQS/DZQyCdGIVsUDzjkGIUEWgO0ZrtpTUvTmpOLK5iz8LjjOO+oGxYlDb0ZpMMP JxAbOWB+7VploARmMqRKLX2KLeA+d4qbXQIGy5KeYPAoA9mFXBDWJQFtAtoEtGllK5MA/4eN AID3XKe/Yqa68U94xsKn9t4nuI+kokGAGgRJHhLUIowI6iHKoo5yNdfUG+MKuJAopFJS1rrX u9Lg2dryn63dBtmT1s8F3/+2PYa7rNez3YrYg+eDj/PtadujWaBAt7G9Rd8yvj26s+JX4m0T L6Ns8Jhb9sMGXzS73mhW8NeHT/+npgCsBLQNCoJWtdZgok/bKkGdHgaYjeMMQQSZzE268xah VRuWbjP1azQI7BfRalQDgbo4KDu12tiv4Uxc9mQBNdOaU6h+9uJsB4X4mqDj81cIoybBqiPI Kt5xD05/Oznq4lORwfODAo2yRfvcyv4qzYKPT7YguwGleRB3vAGacv/1k1s0qLnoogAIVKA9 I59zU6AC+gz0GegzeKU10Wcakon3siPkE4+GOLjXOjhQLlCusZBnlOuZJB5nvtxBRVCmWxDz d6PJsTXQpiE265ikB6xpQ1mTWfoCzggiG4w6LnssCc2cSrEaWwPz2pxgdbNFwYRvmPANxAeI DxCfRzJeBGELXM1Cv/U4HFEEzZlc8wy0GGjxoxhChVHTzdGZyYFSyJ8gfwJSsyRg3i3btDbD mtyopHoV7vftroyPyKguCDl8HpVITx1LleyhjqBl522lclDMVvcrqUomX0vlXxzspY5qxUKq Vsjl89XK/lE19/KdhifK5EueINgMDL3yUS8MmCzpg2WnrVRUcl3ptUmI5W5IPcElb6pdj4cu bzapR9yIvyYi4pQpN5vOpN0QU+bEk/Z1dzOFvcLenn3fhGvbNtja1upd7zLwTbO9QJzg6Kxr Za4rU0RU7aGIslZ899glGgwa6hN2jyU9j7A949UZon6sAx0deSnzSZMyqoiDBJEKCw00I10i HMS4T+pafmVHhRecq6SdtiSDeFy02UuqM6DrBv8PAAD//wMAUEsDBBQABgAIAAAAIQDqJDIV NAcAAJ3SAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTEyLnhtbOydTW/cRBjH70h8h5EPCERTv+xL sks3KLtNEKhpqyT9ALP2bNaqPWPNzKabIiQuwIkTF46IAyfEnQNfBlEQ34JnbG/eWyK1jQP+ p9La65d5eeZ55vn/7K197+NlnrEjoU2q5MgL7wYeEzJWSSoPR96Tg521DY8Zy2XCMyXFyDsW xvt489137hVDkyWMzpZmyEfe3Npi6Psmnoucm7uqEJL2zZTOuaWv+tBPNH9GpeaZHwVB3895 Kr36fH2d89VslsbivooXuZC2KkSLjFtquZmnhVmVVlyntEILQ8WUZ59r0ib1LN7PErc0xYEW wq3Jo090sV881uXuh0ePNUsTspfHJM/JLJ5f76gPK7/Ko3LFv3D64WqVD5cznbsl9Y0tRx4Z /9h9+m6bWFoWVxvj063x/NEVx8bz7SuO9lcV+Gcqdb2qGne5O9GqO3/+8M3fP37PwpNurRps igcqfmqYVNQh1/+qfydHVJ12y2LO7HFBZdnUZqI+rtpZrpy2praWXY5VcuwqmdKyqk7SiG0t rJqlls2UtPsxz6jIQUB/dQ9PD86M3bfHmSgtUriPcrOmzmXcubOQa0/2PcYz+6D8/ny+Nnno sSTVtjQZM7mdZILLE7vaze1laiy5LdvbffSQ7X46Ztt2LrQUZG61kJYix7XClm0p65u+Zq2u T1UR1yrHPKdxWydzvLof7+8ozbSYCU3hLVix0IUywjAls+M7LBGzVIqEpZLt7UxYtBEOPrjQ LSGTx1zzvZP21PWftKdu3xXtqTpVlAO/GmV/5Ycv98bOyhtffP3Vi19+ffHtD3/89u1fP//E otdzyzRZnh7yEo+8Iji7vfXIdYu6FPaDwK2fi9ONTr8TrUdV/HV7UW/Q71yMwqrol/l67en/ 7td1A6eLhzQn19atNl3fZ8Ku68y0nMOu9pyybpogZRnIMx7TUExorlUZp7m24JIciI6LgnHQ Dwa0jIJu0HGftDe18XyH52nmjDEgo8y5NsKezm78TKlbOuUZeyJTSjyC7e5fKr1bll79u1h6 p3um9LUw2qinRPPmm+1iobKz3WQX4uN1LS+0LrdgBK47AsJNxPuUws19rYrtI0rnF+dihMON hcP5vzc7DjD9q0w/qXRIJ4LzNzQCdxjzfeZmIZYsBLOKTB4/ZWpGisuohY7FxYnpkppCSLyB ATm16kpxvm3BhGGARvpvaKRHsRXQR7dFH0EjQSO1USMdKEstnx5bYdj7h0ol7EM25cm/XmxC NEAeQR5BHr01efT4KcTRbRJHkEeQR22VR0gLDQ9GgWTQYDIAF4ALwAVIALeCC8Za8STmxgIQ bgkggAvABe3kglIXITc0PCJTlw0QD9BGgGNgGbAMUw+mnpvHst1FZlNgGbAMWAbPbwzL4PM3 Z/G3jsAw/6vMn0P8NDwCuOzw/9P+MDquNOBKA4YBVxpu7ZWGyd5kK0sP5bbW6tKzHpCAG7jU AOrClYa2XWnod9l7mf1ohMxwC0QpYqGpJFDFQNgLN+64n4cySs4+d9kZmABMACYgGTSGCU9k 4h6i+FzghiRuSAIT4Pn/gxuSSAigg/8aHRAp36nuEhMbgApABaACJIHmHrpVPlkdUHB7ni4B KgAVgAqQEEAFraGCQ6KC6pYBuABcAC5AGmicC3Y0P3RvMQIU3JZHzoELwAXgAiQEcEHr7hbU PyQCFAAKAAXIAY1BwWd8Or38OklkhOaeQg0oABQACpAQAAUtvFkALAAWAAuQBRr/D8gqy1KT UhVIC3i5MbAAzt8EFpzMQkwYm+bcCggjCCMII0xDjbyqr9+t3meMvIy83PYHg7i36QLY8LA6 SCJIIkii9kqinlVhtH5eF0ESQRK1ThL12O9ffscoFiCNII0gjSCNII3aLY2oWquiXu+cNoI0 gjRqkTSCu2Peb4HlSf9TZZjcb9DmDrbg8A0Zn1QNKBeUC8oF5ULttJtyo17fql4YgnJBua2+ AUCBAL8HALTD+DThw9lv0N6ALcAWYAuwBdhqNWz1wsiqMIg6Z2kLeRiw1TbYokCA3wO22mF8 N+HD20FboC3QFmgLtIVMe0M/4AyiLuFWL9w4g1vIw6CtttGWCwQ4PnCrJbhFEz68HbgF3AJu 3Qxu+cXQLscqOS5XTbXFFAdaiM17xVAs7QNj6zW20OnI+3w8HvSjycZ4bRx2d9a69wfra1s7 /d7aTq/T7U7GG1uTzvYXZP8i7A5jLWgMlPw0Ycs8k2ZIG0fe3Npi6Psmnoucm7t5Gmtl1Mze jVXuq9ksjYVfqGdCFyqV1o+CMPBznkqPHfFs5EXBejToD4JB2auyaatl2VhajfezxLU6zvQu Lx4dlT5FdZGkm5SbilQeVmefOYRskea0o1yTdccLXu6JDyRLk8rHFhTgqUzELJWpFR7Twliu yc5SHAntMUmOcEDDN/JsvqeUrdtZluQMXhXt1urqnM2pwf8AAAD//wMAUEsDBBQABgAIAAAA IQAHqYv8LwYAAOVxAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTExLnhtbOxdT2/bNhS/D9h3IHTK sNnyvzh2UKeI3bgokKVdkx52ZCTaJiqRAkk7dosBu2w79b7DDsUOOw2777AvM6wb9i32SElx Ejtx0Nir4z4dLEqiyPd+en9+oiTzwcNxHJERU5pL0fLKxZJHmAhkyEW/5b046RYaHtGGipBG UrCWN2Hae7j36ScPkl0dhQTOFnqXtryBMcmu7+tgwGKqizJhAo71pIqpgU3V90NFz6DVOPIr pVLdjykXXna+us35stfjAXskg2HMhEkbUSyiBiTXA57ovLXkNq0limloxp19SaQ90Cw4jkK7 1smJYsyWxOixSo6TZ8odPho9U4SHgJdHBI0BFs/PDmTV3KYYuYJ/5fR+XqS7456K7Rp0I+OW B+BP7K9v97GxIUG6M5juDQZP59QNBgdzavt5B/6FTq1WqXCz6lRydf5++8O/P/9Iyudq5QLr 5FAGLzUREhSy+qf6nddIlbbrZEDMJIG2DDcRy+qlB11hKk2Glhm3ZTixnZzCOu1OwBXbHxrZ 44b0pDDHAY2gyWYJlkzDaeVIm2MziZhDJLE/brcC5SJqzZmJwotjj9DIHLrtV4NC58gjIVfG QUZ0bDoRo+IcV7P35OCkS7gwTPVowMjX+0ePrT8Yrg0PtBXAODFcV6d37NCqkzZxq3b0K7hk O4DEzSpsdaUiivWYAs9mRXIA7j4hB2bAlGDmgnI0OqMTTQZUEzio2WdX1GMifEYVfX4uVybH uVyZnHPkSpVL3LXPL7Sfm+L1BlnNDfLd99+9++33d2/e/vXHm39+/YVU7maZPBxPq1xjlHP8 s7a9U7FqgUrleqlky5dctVGtVys7ldQFa9uV7Wa9etUR06avM/fM2BebNrRCYqoO3UXnIoRY ZouuveERhOoM8fT8WXt63J5vT+WaVfDUhbb5VuXkAQcQzr+t4bS8DoRgGVEIwQkVUsMeAKdd qpeasK6UaqWq/YWj3ASDLo15ZAFqAlADqjRzoqeBTC+/VWu+KQxmj3xeKFyx6rtiw5RyezYG IyWXjNDmWM81kT8NbeiZd8IWFnROdM73N6CQ6wA4IhdDbiYFw2NmbQoN6mbYJqD3bkgNK8BN nkNtEev76ExsisCdQj0CuSQgMeRhzsScuRQD4qIgA8OMfmhtKV9cTgjk0I4M1GukRbaMNDRa di69CiNox8MujyK3ofqnnUiREY1A9U6zfT7ic6navYW+L2X4wfDsdjvTEbTNwHPVxnlvgTmd GKa/QB68ACYuArSga1yrBz24w5dHhJHCIYVDCrcGFG4oeEC1QStagFXy0lx9ZId2lGGT3QDM UH/LU5E8LAAPHBDt6v/h5RiUPjJ2tCWkIaGSiQ+XXiofKShSUKSg60ZBT5WkIZJQjPd3J6FI Qd9rmM86H9oVklAMSivgR9kyFC+FPBM4DIocFDno2nHQeBgZHAjFcI8c9ANBFyMHRQ6KQWll HPTPb39C5onME5nnujFP++kBVeHFtygvMohqBRgEK/aLmAMWgPmVPEY7mw+Nv985dM/B8Nsz zAGYA9YuB7in09e/Rz/NAV1FY2atA6qjK6Mroyuv3/uUbpgfrWjRHbuSRi75nv3+jx2iZ93w pfFMNnyR+hpxtpTy2+KysiJ+cbseX9ziuO2GUq2VMS0kVxvjPnJo5nxjfPkB25rcBt37Ox8M VfOxwTiFceo2cWq1H9Lh09kNu9PDLIZZDLMYZrE1y2Kr/hYH89hm5THMYpjFMIthFluvLLbq t/kxi2EWwyyGWQyzGGax1WWx2TeDLz8GxziFcQrjFMapDx2nZt9eRY+6zWtMy54sYTNeMpqd 5cut8tn02NgcapOVyFDxlve63W7WK51Gu9Au17qF2qPmTmG/W98udLertVqn3djvVA++sbPz lWu7gWJu4r4n+QSEsHNm0r+YB0pq2TPFQMbZ7IF+Is+YSiR3EwiWS9kshO4/sSuNRm2nsVOv bWfzgoFs+dpJa2cTyyYGDCL1JU2ejtw1h87AFDpuV8JFP5t4bFoFwOAxHHAlkWme0HSusxOR zyQYDiGw2kTf44Ib5hHFtKEKgBZsxJRHhAzZSTqnXvxcSpPJ6VqyiKdN21LWnQUdBP4PAAD/ /wMAUEsDBBQABgAIAAAAIQCDYyo7yAIAAMcFAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTkueG1s jFRRb9owEH6ftP/g+XUKgQCBoKZVoaWa1LVVoT/Ac0zx5tiWbSh02n/f2U5KuyKtL/Hl7nz3 3Xe+Oznb1QJtmbFcyRL3Ol2MmKSq4vKxxA/LeTLGyDoiKyKUZCXeM4vPTj9/OtETKyoEt6Wd kBKvndOTNLV0zWpiO0ozCbaVMjVx8Gse08qQJ4haizTrdvO0Jlzi5r75yH21WnHKLhTd1Ey6 GMQwQRwgt2uubRtNfySaNsxCmHD7DaRTqIwuROVPq5eGMS/J7ZXRC31ngvlme2cQr4AvjCSp gRacNobGLfzKbRDSf64/tiKZ7Fam9ifUhnYlBvL3/pt6Hds5RKOSHrR0fXvEl64vj3inbYL0 VVJfVQT3vpy8LWcJyadqh4YvdXln5Hag9FW/K+8Q+2hhWV4UoyILkLO8nxe97G2RWZGPs8E4 gh/3u+D+pgIy0ca6K6Zq5IUSG0Yd9nqyvbYuurYuXi3VnAsR4UVQeuLhV3tv/QEn1PNkCDwW CQ8bI+PETAnPnHew+nzjIEQTOfp7g7Bu4faCBfTaf4LaQDRB/MwwmTwsMCLCXYf/53Uyu4EZ ei7xYNyF9lTcuNAhZGs3E4zINql/yxK5vWYrQqELX+ufiXANDybmd6fLNZG/0F5tvni1i8bA pazuiCH3L1Ca1C9QGmhHoPw3+yF2ZDrw2vIZKG6OdmCgsdCXRkIbw0v8ezot8mw2nibT3mCe DC6KUXI+z4fJfNgfDGbT8fmsf/nHD2BvMKGGhdn81u4YUL6b65pTo6xauQ5VdbMgUq2emNGK hx3R6zaLZkugt8Os2x+NilEeqgrQ2jOATQ+jT4X5TvTtNjALuRwzs6DSsMPi7VcuwAWvwRAk 2RSuSRyvpWx3RbWBTcdlxVZccucfHYPdauA5SwY7GKZPVWwJHSixq++Viuw3kTzhMbSXmnSe cwD8FwAA//8DAFBLAwQUAAYACAAAACEAynDQukkCAACpBAAAFgAAAHBwdC9zbGlkZXMvc2xp ZGUxMC54bWyMVNtSGzEMfe9M/8Hj107YXCBtMixMSQsvFJgmfIDrdRK3vo2thISvr2TvNlDy wMtaluSjc2R5zy931rCtikl7V/PBSZ8z5aRvtFvV/HFx3fvCWQLhGmG8UzXfq8QvLz5+OA/T ZBqGp12aipqvAcK0qpJcKyvSiQ/KYWzpoxWA27iqmiieENWaatjvjysrtOPt+fie83651FJ9 83JjlYMCEpURgMzTWofUoYX3oIWoEsLk068oXaAyOTcNrSksolJkue1NDPPwEHP4bvsQmW6w X5w5YbEtvGoDbVreum02qv+OrzpTTHfLaGlFbWxXc2z+nr4V+dQOmCxOefDK9f2RXLn+fiS7 6gpUL4qSqkLurZxxJ2eBxa/8jp3900XJDHboJNVv5B2wjwobfh6MTk/HmfJwPBpPBsPXIkeT yaA/nBTyk+FoNHqtQExDTHCjvGVk1DwqCZz8YnuboKR2KeR2/lobU+gVUmFK9Js9RX/hinqe osBhcTjYnEUwM2+oc5SQwtcNIESLXPIpYBLMYW9UZh/ok90R0YygN6Nc73HOmTBwm/fP697s Dt/Qc83PTvt4PY2OkG+IJQszo4TritIsOwb7oJZC4i18sr97Bto+xFIfLq6E/LMJbG50oxJF oMRLC7LgTmjW3i5lkqvDcEsTf4hwv82w+EpAxVl2BXylpXEvUhBUWwxky2HLyQiiDNDCda+h 2eBb1q5RS+00UFsV/j0iXphT+JfB+fKNWqDCmoP96X1R1yIR8wJNVluOyCPhvwAAAP//AwBQ SwMEFAAGAAgAAAAhAIviYs/UAAAAwAEAACoAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90 ZXNTbGlkZTQueG1sLnJlbHOskMFqwzAMhu+DvYPRfXbSwhijTi+j0EMvpXsAYSuJWSIbyx3r 29ewDRroYYcd9Uv69KHN9mue1CdlCZEttLoBReyiDzxYeD/tnl5ASUH2OEUmCxcS2HaPD5sj TVjqkowhiaoUFgtjKenVGHEjzSg6JuLa6WOesdQyDyah+8CBzKppnk2+ZUC3YKq9t5D3fgXq dEn0F3bs++DoLbrzTFzunDAyBU8ViHmgYkHr7+Sn0a51JYK5L9L+pwjHQnJAKZQXOjf5Yqj9 NTOLv3dXAAAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0mrYOINHUR wcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39No3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0Fsfg ScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHLEMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7 M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qFxdRT1iDld3+2VMsSAapt1Ozd9gMA AP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0My54bWwucmVsc4zPvQrCMBAH8F3wHcLtJq2DiDR1EcHBRfQBjuTa Btsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn9BbH4EnDmxj27XLR XGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo9G1AOzPFyWpIJ1uD uL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD//wMAUEsD BBQABgAIAAAAIQDV0ZLxvAAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlk ZUxheW91dDExLnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujb m9GCg+N9/f5cs39No3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0FsfgScObGPbtctFcaMRcjnhw kUVRPGsYco47pdgMNCHLEMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4eu c4YOwTwm8vlHhOLRWTojZ0qFxdRT1iDld3+2VMsSAapt1Ozd9gMAAP//AwBQSwMEFAAGAAgA AAAhAEqvdTnSAAAAvwEAACoAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTEu eG1sLnJlbHOskLFqAzEMhvdC38Foj32XIZQSX5ZSyJClpA9gbN2dyZ1sLCUkb19DS8lBhg4d 9Uv69KHt7jpP6oKFYyILrW5AIfkUIg0WPo/vqxdQLI6CmxKhhRsy7Lrnp+0HTk7qEo8xs6oU YgujSH41hv2Is2OdMlLt9KnMTmpZBpOdP7kBzbppNqbcM6BbMNU+WCj7sAZ1vGX8Czv1ffT4 lvx5RpIHJwxPMWAFujKgWND6O/lptLoCwTz2aP/Tg5IgHxwLloXNXb4Y+jUzi7d3XwAAAP// AwBQSwMEFAAGAAgAAAAhANZx+pzTAAAAwAEAACoAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMv bm90ZXNTbGlkZTIueG1sLnJlbHOskLFqAzEMhvdC38Foj32XIZQSX5ZSyJClpA8gbN2dyZ1s LCckb19DS8lBhg4d9Uv69KHt7jpP6kJZQmQLrW5AEbvoAw8WPo/vqxdQUpA9TpHJwo0Edt3z 0/aDJix1ScaQRFUKi4WxlPRqjLiRZhQdE3Ht9DHPWGqZB5PQnXAgs26ajcn3DOgWTLX3FvLe r0Edb4n+wo59Hxy9RXeeicuDE0am4KkCMQ9ULGj9nfw02lZXIpjHIu1/inAsJAeUQnmhc5cv hn7NzOLv3RcAAAD//wMAUEsDBBQABgAIAAAAIQAFKBYL0wAAAMABAAAqAAAAcHB0L25vdGVz U2xpZGVzL19yZWxzL25vdGVzU2xpZGUzLnhtbC5yZWxzrJDBasMwDIbvg72D0X12ksMYo04v Y9BDL6V7AGEriWliG0sb7dvXsA0a6GGHHfVL+vShzfa8zOqLCocULbS6AUXRJR/iaOHj+P70 AooFo8c5RbJwIYZt//iwOdCMUpd4CplVpUS2MInkV2PYTbQg65Qp1s6QyoJSyzKajO6EI5mu aZ5NuWVAv2KqnbdQdr4Ddbxk+gs7DUNw9Jbc50JR7pwwPAdPFYhlJLGg9Xfy02g7XYlg7ou0 /ykSkxDvkYXKSucmXw21v2Zm9ff+CgAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3AQAA LQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMC54bWwucmVsc4zPvQrC MBAH8F3wHcLtJq2DiDR1EcHBRfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDI m2Cd7zXcrsfVFgRn9BbH4EnDmxj27XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5 lKlXEc0de1Lrqtqo9G1AOzPFyWpIJ1uDuL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg 5Xd/tlTLEgGqbdTs3fYDAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDkueG1sLnJlbHOMz70KwjAQB/Bd8B3C 7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H 1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS 66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIB qm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0mrYOINHUR wcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39No3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0Fsfg ScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHLEMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7 M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qFxdRT1iDld3+2VMsSAapt1Ozd9gMA AP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc4zPvQrCMBAH8F3wHcLtJq2DiDR1EcHBRfQBjuTa Btsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn9BbH4EnDmxj27XLR XGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo9G1AOzPFyWpIJ1uD uL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD//wMAUEsD BBQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlk ZUxheW91dDUueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub 0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCR RVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65z hg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAA ACEA1dGS8bwAAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2 LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5c s39No3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47 pdgMNCHLEMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm8vlH hOLRWTojZ0qFxdRT1iDld3+2VMsSAapt1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8 AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54bWwucmVs c4zPvQrCMBAH8F3wHcLtJq2DiDR1EcHBRfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIX vIZaViDIm2Cd7zXcrsfVFgRn9BbH4EnDmxj27XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJ l0kX0oS5lKlXEc0de1Lrqtqo9G1AOzPFyWpIJ1uDuL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dK hcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAAADcBAAAs AAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHOMz70KwjAQ B/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtg ne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJF9KEuZSp VxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3 f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEANOf50xoHAAD2LwAAIQAAAHBwdC9z bGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOxaW28bRRR+R+I/rJZH5Np7X1t1qjghUClt o6b9AeP12F6ynl12x8YJQipSpVCJqEJAQbQSpSrwEtQnVGgLD/yUqknaf8GZy9prx84Fx1KS Woq8s2fOzJw533fOXDYXL3VbgdLBceKHpKxqFwqqgokX1nzSKKs3byzlXFVJKCI1FIQEl9V1 nKiX5t5952JUSoLaFZRQHCvQB0lKqKw2KY1K+XziNXELJRfCCBOoq4dxC1F4jRv5Wow+hb5b QV4vFOx8C/lEle3jo7QP63Xfw4uh125hQkUnMQ4QBfuTph8laW/RUXqLYpxAN7z1gElzMD9v NaixZ7Uhfq/juuLXuuClQkEDDVTiPeOFIFY6KCir1Yam5ucu5qWyLLHGSXQjxpiVSOfDOFqN VmI+wtXOSgx9QpeqQlAL/Ms64BVSjb+SDi/kh5o30iIqdetxiz3BPQpYCCius988k+EuVTwh 9PpSr3lthK7X/GCEdj4dIJ8ZlM1KGLd/Ono6nd2Hm28e/bCz9fDV31t7278q3EFcM7U8iZZD by1RSAgzY44QE+1piNmzZ9RU6HoEnVKfBljqiUpe6Js10iem5QC+fLK6Y9qGO+gdV9eLNqtn s9Y00ygUBueOSlGc0A9x2FJYoazG2KOcBqiznFChmqpwk4QhUYl2K2FtnWlW4QkugniD9s0w 3lCV4DJJympRM00Ym/IXbqmqxNma6kANDRbCgGOEiAf9lFWPxtwWAuyeb9Ow7kuLxJCsKkjo Kl0PMJ92xH64OAaDAsTCfaOZW7gKXQZ0mb9jkru5CuHfogsBRqRHEjq3s/Xdzubz3d8f7zy+ vffi3ut/vt59srV350sB9+7Dpzsv7rLBKTeBD4NJbQXF6Poho0k3cv+lfuOuPJhwRo9w9zZ3 H2z3CaefBOGYD1UZ+5PwTgOCsfJ44pmWbhVt4/QT79hcixjwHd6WC0+eexz5EdwTfBo2gwM5 gRl729uvnn219+y3I4zFSTjhWH/eOdpYnDuTjbVz//7RxjJPwoffDo817Vxh9nLF97/sPvip nyu46ybNFTUKU92AIENBXeYMDv//zRm2YcHfUM7QNcPo5QzDtjTdOmNrFZ9OmiV4uRNojFgo aABFAm5sDdcZB5g7NeYPDkkY+LUlPwhGbMBoV+zLqE+okDhWfxnvKYu3fj/5dCRelIaIcsZA Tv16UOMc+swyCq5eWFjKVVy3kDM1t5grmvpibtEp6PPOQmXeMQqfqyknEMXUb+Elv9GO8bW2 gOL4ESP2gyxU9ILm5PW8ZvUjp852q9OOHSuNnTc///H69o/92OGpYNLYqQMxONqftFEMBwsZ P2I5PE78GJpuHhxAbtE61wGU7gdPXwhNl6B2StC9L57s3dmEDcLO3ad9mnKUJ6UpHHyvtluj mMqj4FhMtS3LeLtT/WnlaS/VFxaKgEHBzS0ZZjFnVuzF3LztzucWFzWnqFXMecup9FJ9AkNh AuyYNMO/vPXXey9vPZtCfucPcR/BiC5vObwgvoIipdrQYPWlGsynC6XaGpSqDZ3JdCbTmQxK yPMwoaAhC6lETyU9HSOVGKnETCVmKrFSiZVK7FQCAd0MfLIGxGQPVamHwUdCkJZETENULqP1 sE0v14D3QxJxK6GZjukatlkErpaYJL5ckzcS43QtxutUVx4mx+pqGV25mRyrq2d05eI5VtfI 6MoMNlbXzOjah+haGV3nEF07o8uvTg7QdTK6xUN03SwWPAoOUB4ALk3V+4GnXR7KCS+zy6ID FkkF8sENVF3dkDlN5DGexDBaJpV4jd/OsRtGIl+hqgmh5pPGSpt4lNWLlcSrsFs/XlrxZFrq paRebbV9NSTiZJzJemLoNRyza9ijZkDZdVaLG8qTUR15kJDeb32cC6hcU9BQBUby2i8ZqvAS 2ffIbDno1YivH/tc3ELxMqxYpl5kE/MJpEVwVS4VpPv8afsfXNlfFjIYLIWwcPQnPR/7CIyJ fOo1l1DLD9hqC7HkNVGcYNpL0NX2Aki4uKy+vPVISDM4itV8GjiScTiScTiSg3HkRb2PlQPQ sHzXw0p3LYcJzgdW3+zDSnfPAFYMIImV0ccqvaHOgKW7fJ94XgNLn1qCPEGwGEISLDMDlrz3 Pa9gjYgszs1TDhZDSIJl9cHSC5bDATiXYP37/GxixQCSWNkZrCzN5NC8PVnwLIDFEJJgORmw io7GF9wZWKcJLIaQBMsd3rfPwDplYDGEJFjFDFiua5/n/cUZBYshJP4JqH8+jkohbeK4d1qG FisCUjm77KVer1OpMni0ngq82XvYs3A6Gn2STb+fzvwz+vSYOmHmnzEHNsNhZ7aZg8YdkjRX d7n1MweNOZnwBXjmoPGnAccUV6UzB43ZgYO5syR90K7XtpxZkh7caWY3l/zLb/ohTHwnE/+v P/cfAAAA//8DAFBLAwQUAAYACAAAACEA0EajxC8EAAD3EAAAIQAAAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQxLnhtbMyYW28bRRTH35H4Dqvlebv3i606lS+Yl5BEdfoBprtje8Xs 7DI7NnYrpCJVCnmIqj4UEEIioLZPrfKEqtLCh6mw3X4L5rIXBwJNaSL8kp2ZnTnzO+c/Z3w2 V6/NEqRMIcnjFLdU84qhKhCHaRTjUUu9sd/XAlXJKcARQCmGLXUOc/Xa1ocfXM2aOYq2wTyd UIXZwHkTtNQxpVlT1/NwDBOQX0kziNm7YUoSQFmXjPSIgC+Y7QTplmF4egJirBbryXnWp8Nh HMJeGk4SiKk0QiAClPHn4zjLS2vZeaxlBObMjFh9GonOM+YtjSmCqiKmkSkbMNUt5nk4QJGC QcIGlscHb37+bvH8xeqrk9XhgXidZ/sEQt7C009INsj2iFi1M90jShxxK8VqVS9eFNNEF09F Q//L8lHZBM3ZkCT8yYKhzFoq02zO/+p8DM6oEsrBsB4Nx7tnzA3HH58xWy830Nc25V5JuL+7 Y5XuyGAoZuVWCZxn22n4Wa7glDnE/Zf+VTOk0/yZjYvQh5Tsi+iXoeDvRaMGOjMaXuAGhnTT Mm3DsdzTgfF933L4BO6w6fiGIWesuy1NZ00666TRnK++yZ5CFtBEOR3QOYKik/E/AoOwaCDA 0+bWWOvuqApAdFv0IdZuDFgaJbSLIMBV+OnW4ujB4uDF8unDxcO7q5ffvP79/vLkaHX4tQzk 8vjZ4uU9DkYFntgG4mgPEHD9LbtJhzLhTemFcOzfpbRLKReHJ4Wa1kWomU9uSjXZLrN6yflV NW3f9ApZ7SDwWKqeltVjmgrdhay+a/HZ/0VW0Z4ik81VEkC2RXLEOGL3hGgCNMLieKrCwGSH 3YvCQASH14sApSiO+jFCosOvH9hFRJkCxK6UGb9DmKQxpnLEd40KtZose7UdvbavV3wFqlWj Oq7PI7OBvByy4LVr3obpiFzcPF4OWfA6NW91DDcPmFMWwO4acGAFIi02D5hTFsBeDWxZgcet bSAwpyyA/TVg37E3NOc4ZQEc1MCcdkOTjlMWwI01YM/1NzTpOKVsr/16XE5NUP0i/w9lgVNV eN8+Wv7w4+Lo+I/fjlZPHiv2RRQHEWWBuMXqdYCGZYEgpfjHCkHses7qbMiKde7Ebdc2Asvo 9rUOuxI1xwwaWsOxelrPN6y23+20fdv4siz9I0AhjRPYj0cTAncnVJyXdxdUwnKtLMP0dUs3 3Vo6hnb54rmleG9++uX13e9r8ZyLEG/IUlCo9/kEEApJKeBbSrx3EfByw+OV4ZFfcCzlFvee 1UES3wbvXf6iaGeSnBknUV5f8EE3ug3TZodd69tOQ3M6Xk9re0Fb6/VMv2F2nLbrd6qDnrPb DWJG977n+9Wd5x+9uvPrJZxu8ZDf1DzQA26XPRH5FGS7UyEK+8BnQe2KoSzGo0KTegq3Uf7D YutPAAAA//8DAFBLAwQUAAYACAAAACEAaaJfIRUBAADHBwAALAAAAHBwdC9zbGlkZU1hc3Rl cnMvX3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzxNVNasMwEAXgfaF3MLOPJTuJk5TI2YRC oKuSHkBY4x9qS0ZSSn37ipZCDGFoIaCNwJL15uNttD98Dn3ygdZ1RgvIUg4J6sqoTjcC3s7P iy0kzkutZG80CpjQwaF8fNi/Yi99uOTabnRJSNFOQOv9+MSYq1ocpEvNiDqc1MYO0odP27BR Vu+yQZZzXjB7nQHlLDM5KQH2pML88zTiX7JNXXcVHk11GVD7GyOY6zuFL3IyFx9ipW3QC0jT 6/3ZT9s0jAB2W7aMKVtSsk1M2YaSZfk9aT7cxRnqe+dnzSjHXRn/bSgnG4opIzsrYsoKsrO4 pZGtrWPS1mRrPGprnLKtYtJWlGwXU7b7lbHZ81t+AQAA//8DAFBLAwQUAAYACAAAACEAl7FW YIIEAAAUEgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5LnhtbLyYyW7bRhjH 7wX6DgR7ZrgvMmIHllT34tpG5DzAmBxJRLl1OFKlBAVSIICTgxv00LRoA9Qt0p5S5FSkS5qH CSI5eYt+M9wkR3Zkme5FHA5nfjPf9h9S12+MwkAYYpL6cbQuqtcUUcCRG3t+1FsXb+1vSY4o pBRFHgriCK+LY5yKNzY+/OB6spYG3jYaxwMqACNK19C62Kc0WZPl1O3jEKXX4gRH8KwbkxBR uCU92SPoC2CHgawpiiWHyI/EfD5ZZn7c7foubsfuIMQRzSAEB4jC/tO+n6QFLVmGlhCcAobP nt8SHSdgbeK7+yNR4MPIEDpUcQMsdzuBJ0QohI7Jjy9PHhy+/vPr6fHh21++54/TZJ9gzFrR 8BOSdJI9wmftDPeI4HuMks8W5fxBPozfRkPekE9N7xVNtDbqkpBdwRnCaF2EmI3Zr8z68IgK btbpVr1uf3fBWLf/8YLRcrGAPLMosyrb3LvmaIU5mQ8EtTSr2HCabMfuZ6kQxWAQsz+zrxyR Gc2uST93PfVpgPNx2UPeqHaz0BWq3dA0x+FGGg6EUznlFtNwLEPJzTUty9ad0zZn6GSNjpqx N2aTD+AKtqLI7ceQpQcZMkhph44DzNvDQE3YkKAHZRSIrM/D3ZvQld4GDylsyYPC8nJ81p7h JOyHG0ZgaoBYFd7uS60dEdB0m9/jSLrVgaoMaSvAKCqjSTcmR99ODv+Z/v5k8uTeyYtHb15+ M312dPLgfhaX6fHzyYuHbEXK1+XL4MjbQwSxjZ63WrbrhPun8At31fmZoReZkZXJ5Oj49b9H J09/E7Q6UgSqU4RlWNgvlSiWqtm2eU6eGKrKkmnZRDkzO0JEtnmt+ZEHssOafNZgB7SVz5rJ GV0rVyyzhTe1CmWYNhu1FE+rLMghOU+veA3V4EYvxWMjSx6D5Dyj4qm6rbISXA7IiqQEMkoO NGeADgRtNSCj5ECrAkISWLw4Lw5klBxozwBtg0duBSCj5ECnAjLa8kGZAzJKDmzMAC3TXjEo jLJYs65WR4zyhHl0OH38tNIRvQ4dYVUrcmv7KOjmksIVamVJMXU4WbKj5QxNcRS4yxb53yRF nSvZy0uKOidRl5cUdS7ZapCURs2KMserQVDmeDXoyRyvBjmZ49WgJnO8s8WE0WFA+WZT/wsR l5EFL0SriJNZitN3v04f/1SJk1GHOHn0HWlSMyeeqU181XMVhN9wV3fhS4YZccfUFUdTWltS E8pBMlSnITUMrS21bUXbtFvNTVtXviy+izxEMfVDvOX3BgTvDiiP+cUjlG2W+V9TVFvWZNWs wgFbu/qTxSqC9/bnP97c+6EKHn8fvGzwupRk0ft8gAjFpAjge95XLxLAq3WPXbjn5Ktn8AIP NTR5+LxyklWHk9LA2xmEC/30nkN4pURXWg1Vh2SXtnSjIRlNqy1tWs6m1G7DAa42jU3TbpaJ ngY+qBrs7rL5/eruXx+9uvv3FWQ3v2R/ODBHdxgXrgH5FCW7Qx6UEKXg1BbvSvyol8ekGsIY xb85G/8BAAD//wMAUEsDBBQABgAIAAAAIQDgI+eTwQQAAO8SAAAhAAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDgueG1szFhdb9tUGL5H4j9Y5tqzj79TrZ2ahHLTtRXtfsCpfZIY /IV9EpIhpCENSiXKhAQDsUkUNOCmsCu0rQx+zNQk27/gnGOfJHXTxmlaiZv49fFznvf7PXZu 3uoGvtBBSepF4bIIbiiigEIncr2wuSze2VmTbFFIMQxd6EchWhZ7KBVvrbz91s14KfXdddiL 2lggHGG6BJfFFsbxkiynTgsFML0RxSgkzxpREkBMbpOm7CbwY8Id+LKqKKYcQC8U8/1Jmf1R o+E5qB457QCFOCNJkA8xsT9teXHK2eIybHGCUkLDdp82Cfdi4m20+8FOVxQYLOmQBSCuEM+d bd8VQhiQhf4Xn/f/fHHy/OvB4d6bX35gj9N4J0GISmHnvSTejrcStmujs5UInktZ8t2inD/I Yew27DBBLmxvchEudRtJQK8kGEJ3WSQ569Ffma6hLhacbNEZrzqtzSlYp/XuFLTMFcgTSqlX mXFn3VG5O1kMBDByixucxuuR82EqhBFxiPqf+TdCZE7Ta9zKQ4897KMclz1kwtiaqaHQDYsk kfmoWppiFIKiKYqtAS1zFgBTzRGTLmfM8RLuViO3R3fvkitxFYZOKyJFuptx+inexj0fMbnj g5hC/CbpIl+kay5qvE+W0rvEFIXatMsdH+EzeYInpj/Mr4Rs9SFtwrstqbYhEmq8zu5RKN3Z Jk0Z4JqPYDhKJl7pH3zX3/t78MeT/pP7w5cPX//7zeDpwXD/yywtg8Nn/ZcPqEbM9DI1KHS3 YAKpoRdpy6yOWXx4XFioLi4MjRdG1iX9g8OTfw6GR78J6mIV4rndMaR8cWiGZdCEn1cdBgDA os9pdRi2oQFSKiWr47ySKFSCRquzUANMVM9iVXsSywFE1KZg9UksBxBRn4Kl1TjCcgARjVlY DiCiOQvLAUS0ZmE5gIj2LCwHELEyC5sBpvUYbVYCGDXP1ffcw73B46MpPZf1UdEMVswLmDE8 Ojo5/mp4/HsJXaz5FtT1fL+cLtY/i+nqP3pUTpd+FTH8tqjrumekPjo8WcWMZyQL3aKnKB1O IuuMFvQbYjY5WQFc9lgFumaArMnOOVd1swIUc+HJKQQwWWdvJl7okpc0KrJd7Q3yJsp2TTQ+ ODUAC4M1p+JelOI7NagLwzfnqwCdai3Hd2owFQZ0zgc0C5hlCSsXDHHOZ6s2PUPm5ysM+pxP VW2TvcnMzVc4DDifpbPzcH6+woGR81Gy0gk5xVc4VDifaViXy8f/9+CZbzgZo+H0/a+Dxz+N hxObtYsOJxefGU0gC+K5s4lpvXCCsBsW6gb5SKNOfGJoiq0qtTWpStpB0oFdkSq6WpfqlqKu WrXqKnkX/JR/8rkQI+wFaM1rthO02cYs5/NnKDOWxl9VgCWrMjDG6SCmXf/JYvLkvfn5r9f3 fxwnz7iK5DVwkmXvozZMMEp4Ame8ls+TwOsNj8XDM/zs6XB/j/RQ/8GzcZDMqwhS6rsb7WBq nGYcwpcqdKVWARopdmlN0yuSXjXr0qppr0r1OrAqoKqvGlZ1VOip75GpRqxbtL5f3Xvxzqt7 x9dQ3eyS/ZdCA71NecnVT27DeLPDkhLAlAS1xpZiL2zmORlDKAf/o2rlPwAAAP//AwBQSwME FAAGAAgAAAAhAFusJgjEAgAADAcAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0 Ny54bWy0VUtv00AQviPxH6zl7PqRtHmoSZUH4VLairQ/YGuvY6v2etndhKQIqUhIiEPFDQRC Ag4gISFxQoiK/pmKNvAvmF3bCY8iKpFePLvjmdn5vm+8Xl0bJ7ExIlxEKW0gZ8lGBqFe6kd0 0EA72z2zigwhMfVxnFLSQBMi0Frz6pVVVhexv44n6VAaUIOKOm6gUEpWtyzhhSTBYillhMK7 IOUJlrDlA8vn+A7UTmLLte0VK8ERRXk+v0h+GgSRR7qpN0wIlVkRTmIsoX8RRkwU1dhFqjFO BJTR2b+2JCcM0O7GmO4hQ4fxETgc1ATkXj/2DYoTcEzfHU2fHWuvYNucELWioxuc9dkW18Eb oy1uRL5KzpOQlb/Iw/SWjvTC+i19UCxxfRzwRFngwBg3EEg1UU9L+chYGl7m9OZeL9w8J9YL r58TbRUHWD8dqlBlzf0Jxy3gnD19c/bi5enhq6/Hh9P3bw1nhq/oXLD11NsTBk0BmSIiAzqL yNAry8Kcel/C4O2DiDgOEJwH3TpZn0WwXszbzGmU43bqT9Shu2C1E9djIftyEhO9YeoRgIIK xN3lkl117U7PbFertll2qjWzVna7Zrdiu61Kp92qlOx7xTz4WBIZJaQXDYacbA4lUrU4EAKD Ah/Mfmh2NpCBY7mu94SaO33AkchOTDCdKZA1i+uy6dpOxXItZ1nxL7UK0JpWlPpbmONb/yie Kcc0HQV2q5Dt7+KVCvG+v/747cHzuXjuIsQLJM/Uuz3EXBJeCFjkLkDAy6WnXNAzvf9h+ujh 9MuT08ef5iSVFkES3J8bw+RcnrQICx50u1NzSjDsZq9Urpnl9krXbK1UW2a361RqTrvcWq60 Z4Mu4sgnFLr73/k+Ofh87eTg6BKmW5vsxlVE91VdsDG/idnmSIsCtz6Q2tEuBn+dXJN5iKpR /MWaPwAAAP//AwBQSwMEFAAGAAgAAAAhAEmehN0EAwAAgQgAACEAAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0Ni54bWy0VstuEzEU3SPxDyOzHuaRpHmoSZUHYVOairQfYGacZITH YzxOSIqQilRUuogqFjyEkCiosAJ1hSpo4WOqJmn/AtuTSQoUUUG6GdvX917fc861PPMLXR9r HcRCLyB5YF03gYaIE7geaebB6kpVzwAt5JC4EAcE5UEPhWChcPXKPM2F2F2EvaDNNZGDhDmY By3Oac4wQqeFfBheDygiYq8RMB9ysWRNw2XwvsjtY8M2zTnDhx4B43h2kfig0fAcVAmcto8I j5IwhCEX9Yctj4ZxNnqRbJShUKRR0T+XxHtUoOUex6hGcA9oypV1hNECBYHeqWNXI9AXhuOD x8OdzdN3L9VGSFcYQnJGOjcZrdNlpvyXOstM81wZP44Dxnhj7KaWpKMmxi/hzXgKc90G8+Uo qNC6eSAU68mvIW2oyzUnMjpTq9OqnePrtG6c423EBxhnDpWoouJ+h2PHcCIONGsCKy44pIuB czfUSCAASfwRvolHBFqOtHWW+LFftKkm02rGbPFuKXB78pA7YlRGmMMhr/MeRmpB5UeVwUTB GMq+Xmvp5SWgQcwX1RoRfbUu+tznZYwgmTDEC4P+s8HmwfDT7mB3Y3T4/OT70+Fef7T1JMI6 3NkfHG5LyrgiTh2DiLsMGbz9l9MiqqkCFqMwYp7/zHZiwvaL98PXbwb9neNv/dHHD5o9C9pd LlhYEzcH4gYQ54nesKKumIkMDXFlJIgHqYSZsc1yVS9lMqaetDJZPZu0K3olbdrFdLlUTCfM h/EldCFH3PNR1Wu2Gaq1Ofg3NaNipVa2aaUN27BSU+lEaZcvXjIW7/Tt55ONV1PxErMQr8FZ pN69NmQcsVjAOHYGAl4uPamYntGjvdHWprhvg+39KUnJWZAkHq2ltn8uT+oGzbjRzXLWSohm 16uJZFZPluYqenEuU9QrFSudtUrJYipdmjR6iD0XEVHd//b30fqXa0frXy+hu9UQvW+S6LrM K0bMbkFa6yhRxFMrSC0rExVP/ViTqYvMEf86FH4AAAD//wMAUEsDBBQABgAIAAAAIQCsQobX 9wQAAM4cAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDUueG1s7Fldb9tUGL5H 4j9Y5jqzj79TrZ2ahHJT2mrtfsBpfNIY/IV9kiZDSEMblEpUE9IYiE2ioAE3hV6hsTL2Y6Yl 6f4F5xzbcZI6qZuk0i5yEx+fvOd5vx+/cW7eajk210RBaHnuMg9uiDyH3KpnWu7eMn9nZ61g 8FyIoWtC23PRMt9GIX9r5f33bvpLoW2uw7bXwBzBcMMluMzXMfaXBCGs1pEDwxuej1zyXc0L HIjJbbAnmAHcJ9iOLUiiqAkOtFw+Ph/kOe/ValYVVbxqw0EujkACZENM7A/rlh8maH4eND9A IYFhp4dNwm2feIv3vZ3Wzr63ufsJzzHhoEm2Ab9C/K9u2ybnQodsdE8fnb+6z3ZDfydAiK7c 5keBv+1vBUx4o7kVcJZJD8eHeCH+IhZjt26TLYSR43vJEi61aoFDryQSXGuZJwlr00+B7qEW 5qrRZjXdrdY3M2Sr9Q8zpIVEgTCglHoVGXfRHSlxp3t88PbXHznQdysxOPTXveqnIed6xCHq f+RfXyJyml79ehJ3C9solou+ZIvUmjhauFXyzDZVskuubBMu2SHexm0bsXXTBrEZJqrdjmI7 sE3XA+I+/WDSAXHPhrQJ7tYL5Q2egzZeZ/fILdzZJk3h4LKNoNuPJ17pHH3fOfi3++ezzrMH vZePz1991z096h1+E0Wme/y88/Ih1YiZXqYGueYWDODtS7RFVvssDInPQpKV8bmR+7l5fNB9 etI5On7z31Hv5HdOmkeSaMh5oqeVio/JVUbZKqpOuo3VI1BlFQB5uIIVURGBYUSVqclFXWM2 D5ZnhHyxCDjoVuseYZPdCDKjHjgHBuus8C3XJARAlwygsUFYjp2KyoUL75ISV6ilu4mbQ1VF llIKmHiVC1W8iEqhYlQ5RS0ChVmQBxUYF1EpVIyqpKhA1oGWG5ZJDsNSrBhWHYA1JIPZMC0s xYphtRRWkgyNBWxaWIoVw+oDsLoi585YFizFimGNFJZi5k9ZBizFimGLA7Caqs+UMoqVTXpU CRHos9n8SZBRUAYJTkNsSkJsna+/6vz1IiU2xiLTExuNWx3atZjWIsqZktYkoCuGrk6gNbmo AtIseXnt8odbylbjeCqLg8axTxazjOOUrNobRxQTZUe6f6LsSEtPlB3p04myI803Ufbd7ahR M1jlz2BG7+Tkzdm3vbM/cuhijTOjrn8O8+mKB4dZdHWePMmnS5lHDB+N6rruMVAdNwYyd+Yz BtLO+KwBA4yCmDxZXq5GnpqiipI6cSgEOqHUxVC4GAoXQ+FiKBymOW3cUMhmsNmGwmFqY7w5 NbWNGwxTalsMhovBcDEYLgbD6x4M9f5g+MNv3ac/p4ypzWMwNHE0Fg78oAZRg8zwUpfdsNjX bJM58bkqi4YkltcKJTJjFBRgFAtFRaoUKroorerl0qoui18kb/RNiBG2HLRm7TUCtNnA7GF5 9ZRFxtJcSSLQBUkAapo6Ytr1J89Ikvf2l7/PH/yUJk+fR/JqOMga6sElb3qvksDrDU8xCU/v y9Pe4QHhx87D52mQ2MN11iCFtrnRcDLjdMmro6kKXSwXgUyKvbAmK8WCUtIqhVXNWC1UKkAv gpKyquqlfqGHtkXGQWLdrPX9+t6LD17fO7uG6maX6N8yGuhtikuudvAx9DebLCkODElQy2zL t9y9OCepCMVI/odc+R8AAP//AwBQSwMEFAAGAAgAAAAhAJkgJKcIBAAA3hIAACEAAABwcHQv c2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWzsWMlu20YYvhfoOxDsmeEiiqSEyIGWuhfH NqrkASbkSGI7XDocKVKKAimQ1jUQwwjQpkUToE7gthe3ORVJ3LQPE5hS8hadGWokLzKoRDLQ gy+an8Nv/uX7Fwx19Vo/QFIP4sSPwoqsX9FkCYZu5PlhuyLfvLGqOLKUEBB6AEUhrMgDmMjX Vj784GpcTpC3BgZRl0hUR5iUQUXuEBKXVTVxOzAAyZUohiF914pwAAh9xG3Vw+A21R0g1dA0 Sw2AH8rj83ie81Gr5buwEbndAIYkU4IhAoT6n3T8OBHa4nm0xRgmVA0/fdIlMohptOR2tHHr M1niONyjO7q8QkN3m8iTQhDQjaMX+8O93fTbb9I/X/J3SXwDQ8iksPcJjpvxJuZH1nubWPI9 pmJ8VFbHL8Yw/hj2uKCeOt4WIij3WzhgK6VC6ldkmrEB+1XZHuwTyc023emu29mYgXU7H89A q8KAeswoiypz7mw4hghnuLf19ulPkj4JSzicxGuR+3kihRENiMWfxTdBZEGzNe4I4n2C4BiX veTC1JsxW6Rfi7wBM3KLrnwTlFFCmmSAIH+I2Q93A1OHEWB1faej1NdlCSCyxp9hqNxs0joP SB1BEE4YIivpzg/p1t/DP/bT/XujVw/f/Ptg+GxntP1dFutw73n6apdRRjhx3AwMvU2Awac5 1jKqYx6YiEIVPJ/PdkGwnVVcurN39M/O6OA3yViM9uQO7ReAWjK10p+Cz+F+RhmaRZu2D68v 3dI0Jp+oSFMrOBYDsEozi0axZBVO11umOierXO4hfeyGB1uMaua/4WRG1RMAKhozsOZxrABQ sTADqx3HCgAVzbNY/YQPAkDFYh5WAKho5WEFgIp2HlYAqOjkYQWAiqU8bAZg8rHE8G6LWen3 0KSNlt99D7eGjw9mdF/WUafd4MW8gBujg4Ojw/ujw9/nsMXbcEFbL7bns8X7ZzFb6aNH89ky l8Hh96dtXfS0NM+blpy6pU1LnvR3m5aW6VyOy8txeTkuL8fl/2dcFidX+R9/HT7+ZToueTiL 3uk9Ip+5ZmYNspQ7fot+krEgviwWNDpb66tKzXE0xdSdklIyjYbSsDWjatdrVbugfSW+8DxA IPEDuOq3uxhudIn8finLnGW5MjTdVg1VL05TR127+ORZInlvn/z15t7P0+QVl5G8FsFZ9r7o AkwgFgnM+VB4lwReLD22oGf09bPR9hadj+nu8ylJ1jJISpC33g1m8pRzRXivQtfqJb1Ai11Z LZglxaxZDaVqOVWl0dDtkl4zq0W7Nin0BPkeDKl3i9b367svP3p99/ACqpsv2Z8njOgm00tX hK+DeKPHkxKAhJJa51uxH7bHOZlCmA7xv9TKfwAAAP//AwBQSwMEFAAGAAgAAAAhAHYfGYtq BAAAMBEAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54bWzMmFuP20QUgN+R +A+WeXZ9jZ1EzVa5sPCw7K5I+wNm7UliMR6b8SQkRUgFVVqKtKp4oCBUiQUVnor6hCqg8GMq kmz/BXPGdpxd0iXbvWhf4pnxmXO+c5mLc/PWOCLKCLM0jGlDNW8YqoKpHwch7TfUO7c3taqq pBzRAJGY4oY6wal6a+Ptt24m9ZQEW2gSD7kidNC0jhrqgPOkruupP8ARSm/ECabiXS9mEeKi y/p6wNAnQndEdMswXD1CIVXz+Wyd+XGvF/q4E/vDCFOeKWGYIC7400GYpIW2ZB1tCcOpUCNn H0fik0R4m2L/fYwCVZGCbCSGTHVD+O53SaBQFImBo6++mB3uv/rpO/kiTW4zjKFFR++xpJvs Mim/PdplShjA/HyequcvcjHZpSPZ0E9M7xdNVB/3WARPEQhl3FBFvibwq8MYHnPFzwb9ctQf 7KyQ9QfvrpDWCwP6klHwKoP7rztW4U4WA8VcuFUAp8lW7H+UKjQWDoH/mX8LicxpeCaDPOw8 5ATnctlL2ShpVobCsyzbtKWPjmO4NeNEVDzPsxwj99a0XcvwKid9zlQndT5uxcEEZu+Jp/AV UX8QiwrlmU6S8i6fECzbI2ImIEL6YgkRFcYC3PtQDKV3BYsBNvdk5n0kIoAIyc3mM7P2ksYE fqSLTCghCNbi3YHW3laFEb4l+5hqd7pibUa8TTCii7zyjenBN9P9P2e/Ppk+uT9/8ejo769n zw7mD77MMjQ7fD598RAscmlXmsE02EUMAfJp1jLqREaqiJAM2uk1Yi9q5NH+7PHT6cHhP38d zJ/+olgXUSyQIFXYGZfib1QzVs1wPdE+pWYqhmFWvTPXzN7rayZCbEuuwJAGYiOCplQw3Ba7 rZy1VEkWVJKMUkzCYDMkRHZge8NtwpQRIqJAx7BDieyGlGcjXgXmZdAL4axX6tELS8cLUzat ktSpeBaEYx1cs3qFuMCY49olbs10ZPbWwnWvEBcYc1ynxDVtT1KsxwueXRUvQOa8lSXeqlWF JF8/XoDMed2S17KqrtyNrx0vQOa83hKv59jrL7er5AXInLda8gLs+uvtKnkBMuetLfG6Fe96 rjeAXH0tAHohsDjvL/6aIA/pFdeENzn6ncXR/+3Ps8c/lEe/PGfPe/QHXJWpGSDSK64AWaxf eweQVk+e1MeOZ9mRoe6JOz448WnFNqqW0d7UWmK70xyzWtNqjtXROp5hNb12q+nZxmfFN0OA OOZhhDfD/pDhnSGXBXH2DGWwEH/LMD3d0s1KmQ6Bdvn3tkqRvFc//nZ0//syec5FJK/HWZa9 j4eIccyKBP7PJe4sCbzc8LhFeOafP5s/2BdraPrweRkk+W1x3iCJb+ztYbQyTvLyfMGFbrRr pi2KXdu0nZrmtNyO1nSrTa3TMb2a2XKaFa+1KPRUbF+YCrrz1vfLe7+/8/LeH5dQ3fKRfZBD oLugVzwJ+wAlOyOZlAilIqhtOZSEtJ/npBQBHcU/HRv/AgAA//8DAFBLAwQUAAYACAAAACEA Klx3QGADAACzCwAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnhtbLRWW0/U QBR+N/E/NPW5tN0LewkL2Yv4gkBc+AFDO8tW2+k4nV13MSaYoEgCIRpFIySiQX1BeTIIoj+G 0F34F85M211FjBt3eenczpxzvu87M52RsYZjS3VIPMtFOVkf0mQJIsM1LTSfk2dnxpW0LHkU IBPYLoI5uQk9eWz06pURnPVscwI03RqVmA/kZUFOrlKKs6rqGVXoAG/IxRCxtYpLHEDZkMyr JgH3mG/HVmOaNqw6wEJyuJ/0st+tVCwDllyj5kBEAycE2oCy/L2qhb3IG+7FGybQY27E7t9T ok3M0Lpzt2VJGJE6G+ryKMNtlG1TQsBhE63t5bN3r/xnq/7jR/7nA7Hs4RkCIe+h+g2Cy3ia iF2T9WkiWSb3Eu6W1XAhNBNDVBcd9dz2+agLso0KcXjLqJAaOZkp1uRflc/BBpWMYNLozhrV qQtsjer1C6zVKID6S1COKkjuTzixCE5AhqR3YEUJe3jCNe54EnIZII4/wNexCEDzFldD4qlF bRjaBYui080mZIs2Cq7Z5EHmWCsmQdb2aJk2bSgGmH9EGoQlbANe1wtVpTgpS8CmE2IMkTJb ZnXu0KINAeowREf9tRf+8rfWpx1/Z6l9tHH642lrb6298iTA2tre94/WOWVUECfCQGROAwJu /SNaQDUWwCIUasTz39mOR2wHFeevbZ98X2vvfpBi/dFumY2uyQAYxxx+3e5QOXgFNpZbW7sX KBCwej4NAa2PNNq7uyeHq+3Djz3EElL0GevrSm+x4v3H8jc3e4uVGASHz8/HuuwTk+jcTy/f t7bedE+MoK7fi8qkDOoC+9cAuyKHpyi4RwdyjCrsV8NB3E/GtXRMK44rhXRaUxJ6OqNkErGS UkppsXyqWMin4tqD6LdlAgqp5cBxa75G4FSNyv8nWZAs1yqm6Sk1purJrnQstcsXLxmJd/b2 y+nS6654ohb7Fa9CSaDe3RogFJJIwAHeg5dLz3BET/vhXntlmd2P/vp+l6TkIEhiz7zJmnMh T+KiG3Cha8WMHmfFrozHExklURguKfnhdF4plfRURi8k8slUoVPonm2ZELHs+q3v48WDa8eL h5dQ3aIJXoSc6DL3y1qb3AR4qi5EYY9TRmpRTGH2OA416ZpwH9Fje/QnAAAA//8DAFBLAwQU AAYACAAAACEAQzqI3MwDAADNDAAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQx MS54bWy0V1uP00YUfkfqf7DcZ+NL7NiJyKJcurxsd1fN0vepPdlY2OPpeBISqkpQIYWVuqAi uluxiG4r2j6wiJdW0C3tj0FrB/4FM+M4gRAgJZsXz+3MuXzfOTPjc+d7YSB1IYn9CFVk/awm SxC5keej7Yp8cWtVcWQppgB5IIgQrMh9GMvnVz45cw6X48BbA/2oQyWmA8VlUJHblOKyqsZu G4YgPhthiNhaKyIhoGxItlWPgMtMdxiohqYV1RD4SB7tJ/Psj1ot34WNyO2EENFMCYEBoMz/ uO3jONeG59GGCYyZGrH7TZdoH7NoGTB0y6cBrCJvqydLQp502YourzAI3GbgSQiEbCK5/93w 4M/05u3kxn56OHj5608nT2+me4P03pEQjfEWgZD3UPcCwU28SYSG9e4mkXyPaxxpktXRwkhM DFFXdNSp7dt5F5R7LRLyliEk9SoyI7LPvyqfgz0qudmkO5l12xszZN32ZzOk1dyA+ppRHlXm 3NvhGHk4w4d7DJUMEkkfB5e7HeO1yL0USyhiYXEUsijHElnovMXtESuUMyJLEfEZdxlJo12Z qOhMPJwJT7FolEwtC9ywzWLBeRMpQ7Nssc4RsBxLtwxrGodMNS7TXi3y+nz3V6xl8XOPKjIE X448A+Ugpk3aD6AYYP4RThEmHABealfaSn1dlkBA18QYIuVik5VeSOsBBGjMDl1Jdn9MBv+k jx4kD64Pn+29+O+H9PHucOdGhnB6+CR5dou7SYWzwgxE3iYg4IsPWMvCwyK2PCYR5vuZLkwx vTdIHu0nu4cn/+4Oj36XjNOgnAM7xTiz3Ztsnp9507KN9xBf1PSSs0ziMWehG4wZPf1EEIfO jETIyJ12QyC4gBvDo6OT4++Hx3/MYUvkwoK2nu7MZ6uwuK3k4GA+W+ZpYHhn2tayC9fMCzfd /y299/OkZAV0i5asx0o0vsJuYRC08mLNrpJ3VquwOl1U7yijFrt5eRDfWAXNMbT6qlJzHE0x daeklEyjoTRszaja9VrVLmjf5he6ByikfghX/e0OgRsdKn8cZZmznCtD023VUHVrQh1zbfnk WTl5L3/568X1uxPyRC4uSl6Lkoy9rzuAUEhyAj9w3P4fApcLT3F8KV17PNwZsPMxufVkApI4 0hcFiT2A1zvhTJzEQXfKia7VS3qBJbuyWjBLilkrNpRq0akqjYZul/SaWbXs2jjR48D3IGLe LZrfz6/+/enzq8dLyG7RZI9iDnST62VtQD4HeKMrSGHPdgZqXUxh9tsw4mQiwnXkvyErrwAA AP//AwBQSwMEFAAGAAgAAAAhAD5PseWBAwAA6gsAACIAAABwcHQvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0MTAueG1stFbLbtNAFN0j8Q+WWRvbeTQPNa3yoGxKW5GW/WBPEgt7PIwnISlC AqlSqNRQUUGKaCUKKrAgFSsElMfHoDqBv2BmHCdQWhFIuvE8fOfee86585ierTu2VIPEs1yU kfWLmixBZLimhcoZeWV5TknKkkcBMoHtIpiRG9CTZ2fOn5vGac8250HDrVKJ+UBeGmTkCqU4 raqeUYEO8C66GCL2r+QSB1A2JGXVJOAW8+3YakTTplQHWEjuryejrHdLJcuABdeoOhDRwAmB NqAsf69iYS/0hkfxhgn0mBux+veUaAMztIwYulyXJWFHamxGl2cYdKNomxICDpvo7jV/vHji b2303rS7D7a67aZ/sC2MPLxMIOQ9VLtMcBEvEbF2obZEJMvkvvo+ZLX/o28mhqgmOuqx5eWw C9L1EnF4yziR6hmZSdfgX5XPwTqVjGDSGM4alcUTbI3KpROs1TCA+ktQjipI7k84kRBOQImk D2CFCXt43jVueBJyGSCOP8A3sAhA8xZX+gpQi9qwbxf8FJ1hNn22aD3nmg0e5DprxSRI2x4t 0oYNxQDzj0iDsIRtwAt8taLkF2QJ2HRejCFSVoqs4B2atyFAA4bojN967Dc/dQ/2/f213uf2 968Pu29bvfX7Adbu3nv/8yanjAriRBiIzCVAwNW/RAuoxgJYiEINeT6d7WjI9q9157f2jr60 ep1XUmQS5HMqZcklFtsjwWaQWez6cPG/KMJPGeYFgmvczyn6YE5WzR4QP3m92s3ubucEvQIN jqchgI6RRq/TOTrc6B2+HiGWkGzMWB/WR4sVHT+Wv7MzWqzYJDh8dDzWWe+v2OA0237Z3X02 3FmCunF3lsl2krfKrihgl8I9FZy6EznmSux64iBux6NaMqLl55RcMqkpMT2ZUlKxSEEpJLRI NpHPZRNR7U5425mAQmo5cM4qVwlcrFL5/yQLkuVaRTQ9oUZUPT6UjqV29uLFQ/F+PH/3fe3p UDxRi+OKV6IkUO9mFRAKSSjg/5yKpwh4tvRMDe6Oe2976012Pvqb74ckxSdBEnsdLlSdE3kS B92EC13Lp/QoK3ZlLhpLKbHcVEHJTiWzSqGgJ1J6LpaNJ3KDQvdsy4SIZTdufX+7+/HCt7uH Z1Ddognej5zoIvfLWptcAXixJkRhb1pGal5MYfam7msyNOE+wjf6zE8AAAD//wMAUEsDBBQA BgAIAAAAIQDTYVDJywIAABEHAAAfAAAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xpZGUxLnht bKxVUVPiMBB+v5n7D5m819JSq3QEhxZwnPGQEf0BMQ20c2mSSwKCjv/9krQFPfHkwZcm3WR3 v2+/7fbiclNRsCZSlZz1YXDSgYAwzPOSLfvw4X7inUOgNGI5opyRPtwSBS8HP39ciIRxTRQw /kwlqA8LrUXi+woXpELqhAvCzNmCywpp8yqXfi7Rk4lbUT/sdGK/QiWDjb88xp8vFiUmI45X FWG6DiIJRdpgV0UpVBtNHBNNSKJMGOf9DtLAcMNzmttViXtJiN2x9ZUUczGT7ni6nklQ5qZi EDBUmcJAvzlorrlXtnYb/x/3ZbtFyWYhK7sabmDTh6b8W/v0rY1sNMC1Ee+tuLg9cBcX4wO3 /TaB/yapZVWD+0gnbOnMaZkTcF2hJQEzijApOM2JBMGOZ8tAiRuOfyvAuGFYF4Tfcd3ssgKx JRkqQbAz1dXYudclsqsogN4Kk1nR/LpaNhfrU7fZg29rWtP4nEy3JTN1nfqWRvg1ja+RPvJ8 C02mzf7653hFojepcbC5rKMzooQqPddbStyLcKqzfIYkujMkKLJfIWHeVQpBXkrtdAWq0hkl iO1Fdo7u4bjIo31RogfARtAujvP+EsAup78ndYQc0fvemq6qR6PEW1W636GK6R8T2jB97sM/ KyQ1ka1INfRvUWlBc0fqJQqHo24wGnujaBh60agz9npnw9SLe/FkMo7DcDTJXuEOm2HODLr3 Kj0XXjaFAFF90xb8YX5AqxqjFSvYa7awk+qAaoeD/kc7t7TjzsyeG6WbHVjJ0lBN014cZuep lwbRxFDtnXnDSXzqTU67UZSl58OsO3614zOIEiyJm6zXeTuTg+jDVK5KLLniC32CedWMd1/w JyIFL92EDzrNb2KNqBGwdxp34zjoxI2QBlu7OrS2NZrJjan8hcTt2rWRSWbaIHMmYX5BTRft r9hesENi8BcAAP//AwBQSwMEFAAGAAgAAAAhAJDCExS7AgAAkAYAAB8AAABwcHQvbm90ZXNT bGlkZXMvbm90ZXNTbGlkZTIueG1srFXbbuIwEH1faf/B8nuaCykLUaEiAapKXYpK+wGuY0i0 ju21DYWu+u9rOwnQLd32oS94Mp7bOTMeLi63FQUbIlXJ2QCGZwEEhGGel2w1gA/3U68HgdKI 5YhyRgZwRxS8HH7/diESxjVRwPgzlaABLLQWie8rXJAKqTMuCDN3Sy4rpM2nXPm5RE8mbkX9 KAi6foVKBht/+Rl/vlyWmIw5XleE6TqIJBRpU7sqSqHaaOIz0YQkyoRx3q9KGhpseEFzeypx LwmxEttcSbEQc+muZ5u5BGVuGIOAocoQA/3mojFzn2zjBP8f91UromS7lJU9DTawHUBD/87+ +lZHthrgWokPWlzcnrDFxeSEtd8m8I+SWlR1cW/hRC2cBS1zAq4rtCJgThEmBac5kSDc42wR KHHD8S8FGDcIa0L4HdeNlBWIrchICYKdqmZj715TZE9RAL0TJrOi+XW1agzrWyccim85rWG8 D6bTgpm5ST2GEX0M4+NKH3m+gybT9mD+fr0i0dvUONhc1tEpUUKVXugdJe5DuK6zfI4kujMg KLKvkDDvKoUgL6U+6qtwadqYn2Ajft3a2bp6NEQck9L5ClJM+0xoszSeB/D3GklNZMtRXfqX kLSkuQP1J45G4044nnjjeBR58TiYeP0fo9Tr9rvT6aQbReNp9gL3tRnkzFRnQ8g9wc+Fl80g QFTftIQ/LAyCSmeUILZ/Y3WNKNHDMLQt0K4RS7spTrTtdNT/NM8d7boxb/9G6UYCa1karGna 70ZZL/XSMJ4arP0f3mjaPfem5504ztLeKOtMXuz6CuMES+I223Xe7sQwfrMVqxJLrvhSn2Fe NevVF/yJSMFLt2HDoFnTG0QHsBfEvX436LSNNKW1pyvWjkazODGVP5G43bgxMrnMGGROJcw/ QDNFBxM7C/aNDv8CAAD//wMAUEsDBBQABgAIAAAAIQAuFn2QNAMAAKAHAAAfAAAAcHB0L25v dGVzU2xpZGVzL25vdGVzU2xpZGUzLnhtbKxV23LiOBB936r9B5We1xgbxwPUkCkwMJuqJJMN yQcIWcaulSWtJAjM1Pz7tGQ75EI2eZgX62J165zuo+7PX/Y1RzumTSXFBEe9PkZMUJlXYjPB 93fLYIiRsUTkhEvBJvjADP5y/ucfn9VYSMsMAnthxmSCS2vVOAwNLVlNTE8qJuBfIXVNLCz1 Jsw1eQC/NQ/jfj8Na1IJ3Nrrj9jLoqgom0u6rZmwjRPNOLGA3ZSVMp039RFvSjMDbrz1M0jn wI2ueO5Go+40Y24mdl+1Wqkb7X9f7240qnKIGEaC1BAYHLY/2mN+KXZ+Er4w33RTMt4XunYj cEP7CYbwH9w3dHtsbxFtNulxl5bfTpyl5eLE6bC7IHxyqWPVgHtNJ+7orHiVM3RRkw1DN5xQ VkqeM42iR54dA6MuJf3XICGBYRMQeSttO8tKIjZsahSjfquJxqN5EyI3qhLZg4KbDc8v6k17 sPnrJ0fwXUwbGm+TGXRkrr1Sn9KI36fxPtK1zA8Ybtofj7+NV43tfgYG7i5n6DfJmBu7sgfO /EK5j0ejgQIn7g0yEXydYZRX2vqsIlPbjDMiHlNvz9PkLxSdRUNUCcq3OXBNXOqtF0Dj76TT NTGMV+5Z99+5Aa0PlqFltuoh9DcUCIZsCc8HUbkVFqoHyllRicq/RCQYy5GVaM1QDZWkqJql 2SoltUXDftyL/kFQU8BcFNVmq8maM3R1dx9e3d73XkBnIr8hmty+GZFG58qHvYvxB9SRPJf6 9bZegzCeimTwO0QCcgbXENTvE/zflmiIVqeZBvpvEU3Bc0/qRxJP54NovgjmyTQOknl/EYw+ TWdBOkqXy0Uax/Nl9hM/YgPmAtA9V8f3MsiuMSLcXnYBv1+dkEWD0SUrio9JK1zlPJG2017/ J3l+6Mov1MJLY9sZ2uoKuM5mozTOhrNgFiVL4Dr6FEyX6VmwPBskSTYbTrPB4qcr51Eyppr5 Sn+Rdz0iSl51ibqiWhpZ2B6VddtuQiUfmFay8h0n6rdta0f4BJ/Fo0GaDtMukQCtGz1YJ422 kVCur4j6tvMygrtABpnfUtARWxUdjzgtuJp1/gsAAP//AwBQSwMEFAAGAAgAAAAhAHyj5e4k AwAACQgAAB8AAABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTQueG1srFXbTuMwEH1faf/B yntIm4ZCKwpq03aFxE0UPsA40ybCsb22W1pW/PuOnYRyKQsr8RI7tmd8zszxzNHJuuRkBdoU UgyC9l4rICCYzAqxGAS3N9PwMCDGUpFRLgUMgg2Y4OT4548j1RfSgiFoL0yfDoLcWtWPIsNy KKnZkwoE7s2lLqnFX72IMk0f0G/Jo7jV6kYlLURQ2+uv2Mv5vGAwlmxZgrCVEw2cWsRu8kKZ xpv6ijelwaAbb/0K0jFyYzOeudGoGw3gZmL1S6uZutJ++2J1pUmRYcQCImiJgQmieqM+5n/F yk+iN+aLZkr767ku3YjcyHoQYPg37hu5NVhbwqpFtl1l+eWOsyyf7DgdNRdELy51rCpw7+nE DZ0ZLzIgpyVdALnilEEueQaatJ95NgyMOpPs3hAhkWEVEHktbT1LcyoWMDQKmF+qovFsXoXI jSondqPwZsOz03JRH6x2/WQLvolpReNjMp2GzIVX6ksa8ec0Pkd6J7NNgDett8c/xqv6dj1C A3eXM/SLtM+NndkNB/+j3Mej0UiBU/cGQYS/RgHJCm19VokpbcqBiufU2+NTEUpmwZrQSkt5 VIjQpd56AVT+PnEKWvuE7XCu7q35T287vEQeGaHcyC85u6MGeOEqTusTz6QQjC9RrIqye4wB 0cCgWEFGHgqby6UllOCjZzmWHnI+TAnNMnz6Zu8NDhDZFdX0+kNa1XtSPr1NLr+gwuT1k7pY lncowJdi7HyHGPHZoGuM0OMg+L2k2oJutFlB/xZxznnmSf1J4uG40x5PwnEyjMNk3JqEvYPh KOz2utPppBvH42n6FDxjQ+YC0b1O9WMephcBasKeNQG/ne3IcYXRJavd2SZt7ir0jrTt9vqP 5PmhKfNYc8+MrWdkqQvkOhr1unF6OApH7WSKXHsH4XDa3Q+n+50kSUeHw7QzeXJto530mQbf UU6zphe1k3fdqCyYlkbO7R6TZd3WIiUfQCtZ+M7WbtXtcUU5FrKD1kGvE8dJk0nE1owerdNG 3bEY1+dUXa68jvAy1EHqlxTqv5bR9ogTgyuOx38BAAD//wMAUEsDBBQABgAIAAAAIQC0z1gZ uQAAACQBAAAsAAAAcHB0L25vdGVzTWFzdGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJl bHOMz8EKwjAMBuC74DuU3G23HURk7S4i7CrzAUqXdcWtLW0V9/YWdnHgwUsgCf8XUjfveSIv DNE4y6GkBRC0yvXGag737no4AYlJ2l5OziKHBSM0Yr+rbzjJlENxND6SrNjIYUzJnxmLasRZ Ruo82rwZXJhlym3QzEv1kBpZVRRHFr4NEBuTtD2H0PYlkG7x+I/thsEovDj1nNGmHydYylnM oAwaEwdK18laK5o9YKJmm9/EBwAA//8DAFBLAwQUAAYACAAAACEAAFdemycGAAC2HgAAIQAA AHBwdC9ub3Rlc01hc3RlcnMvbm90ZXNNYXN0ZXIxLnhtbOxZW2sbRxR+L/Q/LNvHokh70e5K RA6SbKUBJzFx8gNGuyNp8d46O/KtBFIacA01odCm0ASaQnp5cMlDKWkuzY8JkZT+i565rFaS TWPHdmmIMGjPnjlz5pxvvzl7dnz+wmYYKOuYpH4c1VTtXElVcOTGnh91a+qN662CoyopRZGH gjjCNXULp+qFhQ8/OJ9Uo5ji9DJKKSYKeInSKqqpPUqTarGYuj0covRcnOAIxjoxCRGFW9It egRtgPcwKOqlklUMkR+pcj45yvy40/FdvBi7/RBHVDghOEAUMkh7fpJm3pKjeEsITsENnz0V 0gJk6K4GHru2u+L3Gu4ovrcJOJVKGligKveMmwFR1lFQU9tdTS0unC9KYymxyWlynWDMpGj9 IklWkxXCV7iyvkLAJ7hUlQiFgDBzwAekGb+N1rlQnJnezURU3eyQkF0BHgUihOe4xX6LTIc3 qeIKpZtr3d7VQ2zd3tIh1sVsgeLEoiwrEdzBdPQsnb9//GN0f3ew9+DVX3uj/Z8VDhC3zCJP k+XYXUuVKIbMGBAi0bGFyJ5dk55CtxJw2vMI0HK7pn7aRwT4J6cIOy7kER4dHr1ia05Jpm2W bSDDVO6ompCUXsRxqDChphLsUk4DtL6cUmGamfA4xOpJlW42Ym+LWbbhChDBjoP5vZhsq0pw KUprakUzTVia8hu+uKqQyZH21AgNmnEwziBI6SrdCjCX1wMNllVQ0IUdHfD4PNy5BiqGmJZn JS2FPOEh4aBE3goiiE0LECsG271C84oKbukyv8dR4caq9JTwbLMseeL/Tg8jo8fwu5+G93/I 6aGfBj08qsp9emxiGI5jWprxvtCDvC09OoHHH+RnFcsxrLpuFpa0ll0A7JYKFdNpFhqVsgWh 2RXbat1UsweDKKZ+iFt+t0/w1b6Ah7yBY0oa0maAUTROSJRFVKULekmzi3pRK7MoKY+1w4r2 WRPYzAg8ePJs9Pmj0e7O4N6LwRd3ciYbb2YySNdiKqVmD6LC9TQB1hyN5mngXQq7kup84xyL 6ppmGiXGZ6Cz5ZQZtaf4Ligu+W6YeoXdnIDwCDqGlh8EgpKRssHYZoNPjk0c+B4bzdzm79QA uWty3QkrRsrov9pFCopc8FNTXcrfNfmGEHQ8e76Vx3x7uDP8/decZuZpFEwG2PQLVZCKc/hY pJJEYpwyDfibJVXZdCymFEUUKChp9/+uooK8JKz3adzxZRBilcPJwCos1M9xweJmx69zdGGw 9+1g59nwt4eDh7dHz+++fvH18NHeaPfL4d2d4f394YPHg+d38tInirWIYCoMToIThDHa33/1 9KvR01+OsBavRCdc68/do63FCXqytQb37h1tLb7TTorhN7NrnXXhsCYa8de3v88LR/k0CkeH zjTiom5wqN6iIXegfOiafKjvdN81fmO039EO3c54I7obqD2DO49z9linwR5oYK70w8MIxMn5 1o37+0ijk3fypl5fNLTFpcKiWdcL5mIJOnm73ihYFavVWrJ0fbHVHHfyKTRiOIKHd9IG/uWt Jx+9vPX0DNp3fslOXYAF8BClpPSJDwk3GhVLbzqNQkMzW5BwxS7UW1a50CobptlsOPWmsXST HQRpZtUlmJ8RXfKy0yXNPHC+FPouidO4Q8+5cSgPqopJvIFJEvv8rEoryQMv3tqaJd0xSppm Z5sFYsuuPFq2f+QZlBuQyyhR2l0NSgaFLwa6CZK3BlK7qzOdznQ604GEXBdHFCykkGn0TDO2 MTKNkWnMTGNmmnKmKWcaK9PA+6UX+NEagMEuqtKJg0+EIpNEqeDHhQfIGyKyLIgui6ECFL6O 2qvbcmuI7cBNMFqOGmSNfy+x875I3sIQ+3byo+5KPxIfT4ftBWUNE3bGyeQDnxwzB3kA7sFP Doiarcp3QAe5sAs+DqNCQGWdQTMDGMkTtXRmwE2lbxHh9Bblop5DIyvVHB8OisTHyPHJQJjj w0CR+Jg5Pppha9YcoAwVCVB5AiBHd3hfMAeIoSIBsnKAdN2x+DnQHCCGigTIngDINo15jR6j IgFycoAYOvMiPUZFAlSZAMgq2/MiPUZFfPFN9IvZrfhv88I/AAAA//8DAFBLAwQUAAYACAAA ACEA5um0iekFAABdGwAAFAAAAHBwdC90aGVtZS90aGVtZTEueG1s7FlNbxNHGL5X6n8Y7R38 ETskEQ6KHRtaCESJoeI43h3vDp7dWc2ME3yr4FipUlVacalU9dJD1RYJpFYq/TWhVJRK/IW+ M7te79jjYhpQkSCHeGb2eb8//M76/IXbMUNHREjKk5ZXO1v1EEl8HtAkbHnX+70zGx6SCicB ZjwhLW9CpHdh+8MPzuMtFZGYIKBP5BZueZFS6ValIn04xvIsT0kCz4ZcxFjBVoSVQOBj4Buz Sr1aXa/EmCYeSnAMbK8Nh9Qn6Mmvvz377r63PeXeZfAvUVIf+Ewcat7EIjHYYFTTH3IiO0yg I8xaHggK+HGf3FYeYlgqeNDyqubPq2yfrxRETC2hLdH1zF9OlxMEo7qhE+GgIKz1Gpvndgv+ BsDUIq7b7Xa6tYKfAWDfB0szXcrYRm+j1p7yLIGy5SLvTrVZbdj4Ev+1Bfxmu91ublp4A8qW jQX8RnW9sVO38AaULZuL+rd3Op11C29A2XJ9Ad87t7nesPEGFDGajBbQOp5FZArIkLNLTvgG wDemCTBDVUrZldEnalmuxfgWFz0AmOBiRROkJikZYh9wHczoQFAtAG8RXHqSHfly4UjLQtIX NFUt7+MUQ0nMIC8e//ji8UP04vGDkzuPTu78cnL37smdnx2El3ASlgmff//F3998iv56+O3z e1+58bKM/+Onz578/qUbqMrAp18/+PPRg6f3P3/2wz0HfEfgQRnepzGR6Co5Rgc8BtscAshA vBpFP8K0TLGThBInWNM40F0VWeirE8ywA9cmtgdvCOgCLuDF8S1L4cNIjFUecgt4OYot4B7n rM2F06bLWlbZC+MkdAsX4zLuAOMjl+zOXHy74xTSmbpYdiJiqbnPIOQ4JAlRSD/jI0IcZDcp tfy6R33BJR8qdJOiNqZOl/TpwMqmGdElGkNcJi4FId6Wb/ZuoDZnLva75MhGQlVg5mJJmOXG i3iscOzUGMesjLyCVeRS8nAifMvhUkGkQ8I46gZEShfNNTGx1L0M3cMd9j02iW2kUHTkQl7B nJeRu3zUiXCcOnWmSVTGfiRHkKIY7XPlVILbFaL3EAecLA33DUqscL+8tq/T0FJpliD6yVjk rdtqwjFN3nfklTvyjqDOkpjvw8tw8923w0VA3/7mu4vHyT6BfH/fe9/33nex9y6r51U77qzJ mtF5OiAbfvHSaXlIGTtUE0auSNOeJSgd9ODQbAxRMZynESxzcRYuFNiskeDqE6qiwwinIKZm JIQyZx1KlHIJVwJz7ORt7pUUjDdnzellENBY7fEgO14rXxILNmYXmovoVNCaZrCqsLVzpxNW y4ArSqsZ1RalFSY7pZmP3JtQDQjrdwC19XomGjIGMxJov2cMpmF57SGSEQ5IHiNt96IhNeO3 FdymL3yrS9vUbE8hbZUglcU1loibRu80UZoymEVJ1+1cObLE3qFj0KpZb3rIx2nLG8I0Bcs4 BX5SNyDMwqTl+So35aXFPG+wOy1r1aUGWyJSIdUullFGZR5N36EkM/3rzYb2w+sxwNGNVtNi baP2P2phPsqhJcMh8dWSk9k2f8bHiojDKDhGAzYWBxj01qkK9gRUwneGyTW9EVCh5gns7MrP q2D+XU1eHZilEc57ki7RqYUZ3KwLHcyupF6xm9P9P5piSv41mVJO43fMFJ25MLauBeZSBWOA wEjnaMvjQkUculAaUb8nYHAwskAvBGWhVUJMv3rWupKjWd/KeGRNLozUAQ2RoNDpVCQI2Ve5 nS9hVsu7Yl4ZOaO8zxTqyjT7HJAjwvq6ete1/R6Kpt0kd4TBzQfN3ufOGIS6UN/WySdLm1cd D2aCMvpVhZWafumrYPN0KrziV23WsRbE1Zsrf9WmcPlA+h80bip8Nptv+/wAoo+KiRJBIp7J Bg+kSzFbDUDn7DCTplm92TFqFoJC7hscPkvOLsalOWf/u7j/7ux8Zfm6nEcOV1cWS1SPR9OL jNkt/ALFB7dA9i5clMZMyeyN0m24anamvx0An0yiId3+BwAA//8DAFBLAwQUAAYACAAAACEA 5um0iekFAABdGwAAFAAAAHBwdC90aGVtZS90aGVtZTIueG1s7FlNbxNHGL5X6n8Y7R38ETsk EQ6KHRtaCESJoeI43h3vDp7dWc2ME3yr4FipUlVacalU9dJD1RYJpFYq/TWhVJRK/IW+M7te 79jjYhpQkSCHeGb2eb8//M76/IXbMUNHREjKk5ZXO1v1EEl8HtAkbHnX+70zGx6SCicBZjwh LW9CpHdh+8MPzuMtFZGYIKBP5BZueZFS6ValIn04xvIsT0kCz4ZcxFjBVoSVQOBj4BuzSr1a Xa/EmCYeSnAMbK8Nh9Qn6Mmvvz377r63PeXeZfAvUVIf+Ewcat7EIjHYYFTTH3IiO0ygI8xa HggK+HGf3FYeYlgqeNDyqubPq2yfrxRETC2hLdH1zF9OlxMEo7qhE+GgIKz1Gpvndgv+BsDU Iq7b7Xa6tYKfAWDfB0szXcrYRm+j1p7yLIGy5SLvTrVZbdj4Ev+1Bfxmu91ublp4A8qWjQX8 RnW9sVO38AaULZuL+rd3Op11C29A2XJ9Ad87t7nesPEGFDGajBbQOp5FZArIkLNLTvgGwDem CTBDVUrZldEnalmuxfgWFz0AmOBiRROkJikZYh9wHczoQFAtAG8RXHqSHfly4UjLQtIXNFUt 7+MUQ0nMIC8e//ji8UP04vGDkzuPTu78cnL37smdnx2El3ASlgmff//F3998iv56+O3ze1+5 8bKM/+Onz578/qUbqMrAp18/+PPRg6f3P3/2wz0HfEfgQRnepzGR6Co5Rgc8BtscAshAvBpF P8K0TLGThBInWNM40F0VWeirE8ywA9cmtgdvCOgCLuDF8S1L4cNIjFUecgt4OYot4B7nrM2F 06bLWlbZC+MkdAsX4zLuAOMjl+zOXHy74xTSmbpYdiJiqbnPIOQ4JAlRSD/jI0IcZDcptfy6 R33BJR8qdJOiNqZOl/TpwMqmGdElGkNcJi4FId6Wb/ZuoDZnLva75MhGQlVg5mJJmOXGi3is cOzUGMesjLyCVeRS8nAifMvhUkGkQ8I46gZEShfNNTGx1L0M3cMd9j02iW2kUHTkQl7BnJeR u3zUiXCcOnWmSVTGfiRHkKIY7XPlVILbFaL3EAecLA33DUqscL+8tq/T0FJpliD6yVjkrdtq wjFN3nfklTvyjqDOkpjvw8tw8923w0VA3/7mu4vHyT6BfH/fe9/33nex9y6r51U77qzJmtF5 OiAbfvHSaXlIGTtUE0auSNOeJSgd9ODQbAxRMZynESxzcRYuFNiskeDqE6qiwwinIKZmJIQy Zx1KlHIJVwJz7ORt7pUUjDdnzellENBY7fEgO14rXxILNmYXmovoVNCaZrCqsLVzpxNWy4Ar SqsZ1RalFSY7pZmP3JtQDQjrdwC19XomGjIGMxJov2cMpmF57SGSEQ5IHiNt96IhNeO3Fdym L3yrS9vUbE8hbZUglcU1loibRu80UZoymEVJ1+1cObLE3qFj0KpZb3rIx2nLG8I0Bcs4BX5S NyDMwqTl+So35aXFPG+wOy1r1aUGWyJSIdUullFGZR5N36EkM/3rzYb2w+sxwNGNVtNibaP2 P2phPsqhJcMh8dWSk9k2f8bHiojDKDhGAzYWBxj01qkK9gRUwneGyTW9EVCh5gns7MrPq2D+ XU1eHZilEc57ki7RqYUZ3KwLHcyupF6xm9P9P5piSv41mVJO43fMFJ25MLauBeZSBWOAwEjn aMvjQkUculAaUb8nYHAwskAvBGWhVUJMv3rWupKjWd/KeGRNLozUAQ2RoNDpVCQI2Ve5nS9h Vsu7Yl4ZOaO8zxTqyjT7HJAjwvq6ete1/R6Kpt0kd4TBzQfN3ufOGIS6UN/WySdLm1cdD2aC MvpVhZWafumrYPN0KrziV23WsRbE1Zsrf9WmcPlA+h80bip8Nptv+/wAoo+KiRJBIp7JBg+k SzFbDUDn7DCTplm92TFqFoJC7hscPkvOLsalOWf/u7j/7ux8Zfm6nEcOV1cWS1SPR9OLjNkt /ALFB7dA9i5clMZMyeyN0m24anamvx0An0yiId3+BwAA//8DAFBLAwQKAAAAAAAAACEAgVCb sk4WAABOFgAAFwAAAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVn/9j/4AAQSkZJRgABAQEAYABg AAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsKCwsNDhIQDQ4RDgsLEBYQ ERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQUFBQUFBQUFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCADAAQADASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQID AAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6 Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QA HwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5 OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOk paanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oA DAMBAAIRAxEAPwD9U6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAK+bv2sPi1dfC7xF4Q/tfxnqvw/8BX1rfm71vw/YwXl819Es ckEJjlhm2wmIXLFljPzIoZkB5+ka8k+JHwl8T6t8TtJ8feDfEOk6ZrVnpE+iS2niDS5L+0eC WVJS8YjnhaOTdGATkh1wCBtBpDPLvAvjb4k/FzUvAvg3UPGM3hHU/wDhCo/FGsax4dgspp7y Wa4MNqimSOaFV2xySSCMEFioVgo5mh8deLvGX7L/APwsHV/iXdeAr7w/ZapDqN1pGn2bRXd5 ZXM1t5zrcRS/I7QZ8qPaSZMBugGt4X/ZX1/4VxeFr/wD4x0608RabpV1o+oT61orXFnewz3j Xm6OCKeIw+VNJL5ah2UI+w5wGqPVf2T/ABDDoXw70TQPHmnR6N4UaW+n0/xF4efUINV1SSVp jfTLFeW/KyvI6Rncis+7kqhVv+v69AR7H8MtU8S+JvhD4W1HxDCmjeLtQ0O1n1CLyfltbx4F aQeWT/DIT8pPbGa8W+A/xQ1LXv2gPEPhOy+IuofEHw5Y+H4729fXrC2srqz1BrjYqwJHBAzw NGHJJR1VlQb8sRXsUXhrx3JJZTXXjexWSPSLm0uYbLQhHBNfuyGG8UPPI6LEquvk72D78lhg VynhP4O+LLj4tad8QPHnibR9Y1LR9KudI0y18P6PJp8QS4kieaWYyXEzOx8hAqAhV+Y8k5D+ 1cn7Njk/jl8avGPwT8d6lYJH/btr4w02O28EWxgULBrodYTaSMq5McgljuNzklVguecAAYnj b4y+O/AXxI8O2516LVfBvgsaTpfjy+ks4Ua/u9RzEswKr+58hjbTsqbRsuueAMe5fEf4Zj4g 654A1E6j9g/4RTXxrnl+R5n2rFpc23lZ3DZ/x87t2G+5jHOR5lqH7E3gLxZoXjRPF9nbeJfE 3im7v7q58QyWxjng88ssCxLvbaIIvKRTnnyg3GcBba/1/W/3Ie+n9f1/mY/jb48eK/h/+1Te 2WoXcMnwotLDRrLUYjAgfTrvUJbxIL0y43eX5ltHC4Y7R56txtaq2l/Gfxx4wh0Dwhp2sxad 4h8R+M/FOm/281nFI2naXpl9cJ+6iI2PNsW3iVnDD5mdg5GD6Jov7O0Nx/wlY8Zayvi+PxR4 W0rw1qyPZ/ZxObRLpZbj/WNgym6LbeqFOGbORyfhX9ka+8GfDXwnpen+Prmbxz4W1rUNb0/x beaesnnSXk0z3EVzb+Z+9jkSYq+10JZVdShAFPv/AF1F2/rodb8DfFGnapr3iLStO+L8vxN+ wpEZrPUILRbzT3LSKSXtooVZGKEANGSCh+Y9B7DXlXw0+FvijRfiR4h8d+MvEOk6vreraXZa Oltoely2VtBBbS3Eqk+bPMzuzXL5OVAAAx3r1Wjoh9QooopAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFAHI/Fn4kWfwi+HWueMNQs7rULPSYRM9rZ7POlyyqFXeyrnLDqQKw/APxsh8W eJte8Na34b1XwR4i0Wyg1O4sdaltZFazmaVUnSW3mkjK7oZFILAgryMEGsr9rrw1qXjD9m/x 3o+j2F3qmpXVkqw2diGM8uJUJCBed2AcY54rwiHwt4l0G++J/iH4e+BPE+r6Jf8AhNYJ9O+J Am1CfUtSjnHkrGt3K1zLFHA9wTEzhGZkCYZmNIfQ+tNJ+I3hTXtBvNc0zxPo2o6LZlhc6laa hFLbQFRlt8isVXA65PFNl+JXhCDwnH4ok8VaJH4Zk+5rTajCLNudvE27YeQR16ivjrw/8Nbz Xv8Ahc154qsPGLeGdbsvDM1jqWn+DhY3klza3V05kj00RsziJ1t96yxFmQAFWXaS/wAQeHfi B4o034YeJNf0zXNC0XRdS12Gefwt4She+kWUxrZajLpM8Nw0bOiXCuFjMimbOFV2AYj7dtNS tdQ0+K/s7iK8s5oxNFPbuHSRCMhlYHBBHQiuJ8I/HDwn4n+F3hzx5eapa+GtG1vSodXiGt3U Vu0MMqoQZCX2jBkRSQSMsBnkVmfs7+C7LwP8H7PS9Mk16a0kuL27jHiOxjsrtWmuZZWBt444 1hTc7FIwi7VKjA6Dxn4D/Ba/S8/Z+/4S3wiZIvDvwwuNPuV1O0DrY6gz6cojYMCFlMa3A9cB /en/AF+Yv6/FH0FrXxo8F+H/ABh4b8M33iCxg1XxDay3mnIZ02TRIYxu3ZwN3mLs/v4bGcGt uLxx4cn8US+Gotf0uTxHFH50mkLexm7RMZ3GHdvAwRzjFfIfgH4YXPgm4/Z51LxH4CvryDRr fXtGuhDozXstgZbqNtP8xEVmSJVjba5G2PcCSoOaqfCP4O31n440bTvGF34/i8S6T4vvNbC2 vhi0/sud2uZ3W5/tVbTe0csUgDI1x5mGKFcACktWPofSHxi/aG8KfCfwH4k1z+1dK1bVNJsz cpoqanDHNOxcxxqeSUUyAqW2nG1uCRitjw38UdL/ALP8PWvinxB4U03xPrCk29hputJPFdfO QptmkWN5QQB0Tg5HOMn50uvgHM37HHjTSB4JSTxfqes6pfNbvZK11Oz6xK0UnIycwCMg/wBw DtXP/tTeD/GHiHUvHfhTw54Jk0+xS009tC/4R/wjHONVEe2SR5dQOEt2hcFUiG2TCgpv3gAQ H2VqHjfw7pHiCx0K+1/S7LXL4brTTLi8jjubgdMxxFtzjg9AaLbxx4cvPE1x4ct9f0ufxDbx +bNpMd7G13EnHzNEG3gcjkjvXg3hmwt/CXxu+IVt4s+H+reItS8ReJ7LUtF16DQzfWotFtrW OLdc4KW/2aWKZ9rspGd6Bi1eY/Av4N32neL/AArp/jC78fxeK9B8R3uqssXhm0TSpZne4JuD qiWgaSKaOU5Vrgud+1l44F0B6XPpr4jfGGXwb4v0Twlonhi+8X+KNVs7nUksbO4gtkitIHiS SV5JnVc7541VRkkk5wATVu1+NnhZvGmkeDtQvV0XxbqOlrqi6NfyxrNCpZE8lyrsvm7pANik 5wSCQM1w/wC0tpPhPXZNHi8Q+GPG9xqtlHLcaL4m8D2NzLe6fO3yskc1tloywC5Eq+SwA3E4 wPPfBPhfxRpXxa+Eniv4leEJdX8TXvgltL1DVLLSBdC31cXNs6NcvCjLA3lh8ynCAq4VsYBS /r8R/wBfkfSdr8SfCN9eavaW3inRbi70dS+pW8OoQvJZKOpmUNmMD/axXO+E/jjoXxE0Hwbr vhDb4h0bxHOsRuIrqGJ7JWtpJw0sbuHLYRQY1BcbtxGFJr5k+DXg/wAYeLvjB8PdX8ReDptI s7XSNXsNc0hfCMelaZpjzJERZxyHLXcRaPiQbo22gggttGx8D/AupWPw0/Zu0mDwXqmhan4Q 8QCLxKlxpL2m2WPRL+B7gsVAmjaSSJRMpZWLqAfSl5+RL8j6L8XfHnwB4K8N+Kdbv/Fely2v hiJpdWhs7uOee1KgnY0asWDnBAUjJPArW0/x5ba14k02x0uOHU9IvtPnvk1q1voHhDRyxx+U ED+YxPmMd6qVXZgkEgH4yuPhnrWtfCH4u/D7wt4O1XVfCreD706NN4o8Mf2bqtvqLu7JYJK6 r9sXkssoU7WVcyOWyPQ/H3gnWviMzXXw98Oaj4Ztr74W+JdG09brTn0prTUJ7iy8mJo3VDC7 tHIwJAyAW6c1N+v9dSrf193+Z9F2nxQ8G6hp2raha+LdCubDSW2ajdQ6lC8Vkw6iZg2Iz/vY ra0XW9O8SaXbanpN/a6pptyu+C8splmhlX1V1JDD3Br5c1jT/BPjb4Px6dB8N/GngeXSk0om 60/wY5ubW4tpPNgiEDRMbyOKSP5gqSRkPkNk5Hs/7O974i1D4T6XN4o0S30HVTPdj7Pb2B08 Swi5l8m4a1LMYHmj2StGSSrSMDzwK7knpNFFFIYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQBh+Or6fS/BPiC8tZDDc2+n3EsUi9VdY2II+hFcVoPizWbW+l0t mIu7i+W3gj1eUO1uv2YyliyD5w+07QCf4snjaPTZ4I7qGSGaNZoZFKPHIoZWUjBBB6giqt7o em6ksi3en2t0sgVXWaBXDBSSoORzjccemTQB5pb/ABG1NtSvdUVLc2qabZSy2MlyxyTc3MTm AYwd2FIYjnEY75G78QNb1HRNUit7a7eEaxaGxtDgEQ3ZlRUce+2VmPtDXWyaBpk1xbzyabaP PbhRDK0ClogudoU4yMZOMdMmrNxZwXTQtNBHM0L+ZE0iBijYI3LnocEjI9TQB5lonjHUdWW1 uJpnZbWex0q5jjfYPtvmEXJOOoGY+OnJqpoHjrW9MsTPc3EN7ZwaJZ3Kx3BIkaWSWWMu0nJx lVLEg4UcDOc+qLpdnGrBbSBQ032hgI1GZc53nj72R161G2haazRsdPtSY4mhQmBfljb7yDjh T3HSgDj/APhNtbk1ddGittOfUBeNbNceY/kYFuJgQAM7ucFc+hzziur8M6wfEXhvStVMXkG+ tYrkxbt2zegbGe+M1NZ6Lp+mxQxWlhbWscJLRJDCqCMkYJUAcE57VZt7eK1gjhhjSGGNQiRx qFVVAwAAOgAoAkooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooA5nxhqF3DfaBp1tdtpy6leNDLdxqpdVWGSTau4FQzFAMkHjOOcGsi+8S6h4fv9 RtbcT67JaWto7SysDhXluVZykUeSVEQB2gk4HAwa7TUNMs9XtWtr60gvbZiCYbiMSISDkHBG OtUpPCOhTWv2Z9F097faqeS1qhTapYqMYxgF3I9NzepoA5pviNcNY6pqdvZ2dxpliUi8wXbB 5ZGijkUr+7wI/wB6o3HnGWx2O/4c1y61K61OyvraGC80+VEc20pkjcOgcEEqCDzggj0PerEn hfRpbprl9IsXuGi8gytbIWMe3bszjO3bxjpjirOm6TY6LbfZ9Psrext9xbyraJY1yepwABmg C3RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBk eJfFFn4Utbe6v1mFtNcxWpljTcsbSOI0Lc8KXZRkZ656Akc9pHxe0XXlZbC31Ca5FtJd/Znt /Kby0ELHLSFUBKXML4LZ2uM4PFdDr3hXTvE0mnPqEczvp9yLu2MNzLDtkClcnYy7htZgVbII Ygg5rEtfhB4Ts40jh02RYVtZ7Iw/bZzG8MwVZEdS+HBVEX5gcLGgGAigAEx+KHh63s9Kub28 OmR6law3cH21fLwspARW7K2WAIPTmqOufGzwboHh+DW59Zhm0ya8FiLiA7lWTyjNg+n7pS47 sCu0MWUHS8UfDHwz4zvI7nWtLW/mjMZjaSWQBCm/btAYAcSODj7wOGyAMTt4B0H+y105bDy7 DzIpWt4ppESQxxLEiuAw3psRFKNlSFGQaAMC/wDjp4R0rxVqWgXt+bS80+ZYLmSQDyoybdrg FiD8vyLxkAsThQcHF1fjJ4KlkaODxJp9zMIPtIjhnUlo/JMwYHOMeWN/Xpg9609c8A+H/Elr c22paZFdRXFwbuQFmUmYw+T5gIIIYR8AjBHBGCM1VX4W+FVh8o6PC6GPyjvd2JXyjDgknJ/d krk88+tC8wIv+Fu+DBCkp8S6eI383a5mAB8qITSc+0ZD+6nI45rZ03xVo+sRl7PUbedRJ5Jw 4BEmSPLIPR8qw29eOlYdx8HfBt1fWd3LoUDXFpG0MLb3AVGgWAggNg/ulCDOcDOMZOdnR/CO laGb421om69v31KYuoObhsAuOODhQOPTPUkkA5ax+Pfge6uL+GfXbbTpLO+uNPcXsioGlhYr JtOSOCMYOCNyZA3rnTt/i54NvMCDxFYysZRCESTLb95TGOv3wUz03jb97imaj8HfB2rXf2m5 0OF5yZizLJIm/wA0sZdwVhuDFskHOdqf3Fxan+GPhi41KLUH0mMXkcnmiVJHQsfOefDYYbl8 2RnKtlS2Dj5VwAO8I/Enwz46bZoer299OLaG7e3GVmjilQOjMjAMuVZTgjI3LnqK6aub8K/D vw94Jurm40XT/sUtxFFDKRNI4ZY0CJwzEAhVVcjkhVBzgY6SgAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigD//2VBLAwQUAAYACAAAACEA+jG7OiwCAAAxBQAAEQAAAHBw dC9wcmVzUHJvcHMueG1srJTbitswFEXfC/2H4HfFkixfSTJItgKFTill+gGqLSemsmUkZWZK 6b9XcS6dEAJDiV8ko3NZex+hxcNrr2bP0thOD8sAzWEwk0Otm27YLIPvT2uQBTPrxNAIpQe5 DH5JGzysPn5YjMVopJWDE86nfjUzX2iwhVgGW+fGIgxtvZW9sHM9ysGftdr0wvlfswkbI158 g16FGMIk7EU3BMd885583bZdLStd73oPcChipJpI7LYb7ana+J5qb3VcIK28SLvVL17cfvki jJmCvE/T2TExnOJUQ5Watr5DqcxqIXyAdX47exZqGRjZBP48/BcwFvLVfbbuuJvtTLcMfvMS JSmrKpChDANCWQooL0vAGYERjyhjUfpn3x+RQgkrzb7DUS4iV4L7rjba6tbNa90fnQtH/SLN qLvJPARPckVhzebHmXi9hv47QL9pNmnwvJfYeF0xnMAUoDQjgHDOAEvzDKScxVmUcF5l9IS9 d/NRNp0onVH2LvAHYnR0eKI7rJO/4WmQe+ZamUezu1Jbljk7qT3H3BhRmpQ8JxQkMCoBQQQD lnvBSYWiFHomis8jajpbC9N86sVG8qZzlXDijopPwFfzqCJEYYIp8EOggEQ4B3R/qxijWZwk GMYInhllK3bKTYzV2N0RD+ObgOsq5mtKKwB5yQGJIw7yLEKAJAxHjPslIgfAuKi3wrgnI+qf /tn4Jlvmr2Jzxoz/BxPfdPHy3ly+cqu/AAAA//8DAFBLAwQUAAYACAAAACEAZVlfHa8BAACC BAAAEQAAAHBwdC92aWV3UHJvcHMueG1sxFTBbuIwEL2v1H+wfG+dhC2EiFBVqnrqYSXYvVu2 Ca4c2/I4FPr1O0mgDTSquPXmmXnz5r2x7MXDvjZkpwJoZ0ua3iWUKCuc1LYq6d/1821OCURu JTfOqpIeFNCH5c2vhS92Wr39CQQJLBS8pNsYfcEYiK2qOdw5ryzWNi7UPGIYKiYDf0Pi2rAs Saas5trSY3+4pt9tNlqoJyeaWtnYkwRleETxsNUeTmz+GjYfFCBN130maYnmbAs0/zqLbYzY 6IKSL2oTCbzjqu6n2YQS3kT3KF8biCVNKBtC1853yHw2z+5HkOzrFDBaqs9QrIwcRP2R7HhY CW7wMtJOKrTBcsEL2BO8wxnOklhLuiGYPXzNso8uX7igK23JHotpnlJyKOk0O4KOI1tY1aC0 F4gfZ4KNuD7ctAvvlHgHJc3S6XEJPaRP5vlp6CdJSz5w1wo69+6aaLQdLmOwpnPHk8mY4/Ps uOOks3s7m/+eXzpmIxKsiwrWah+vUdUOHpF1kf5O1wkw1DQiAVyIKvycpMv5VdBy5bnAl04E ds7wZeEvIg6nY0/Rfx/L/wAAAP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAAABMAAABw cHQvdGFibGVTdHlsZXMueG1sDMxJDoIwGEDhvYl3aP59LUNRJBTCICt36gEqlCHpQGijEuPd Zfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA1nHdcWm0YLAKC3m236U8cU95c6sUV+vQ pmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h705UkgecdieKTBtSJnsE3qoIgorTAp8vl iGlIA1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAwQUAAYACAAAACEAtKgOzcMCAACWBQAA EwAIAWRvY1Byb3BzL2N1c3RvbS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAC0lEtvo0gURveW/B8sVjNCbiieJrLTsgGDCTgktuPHJiLF00AV pgBjWvPfh9ZMp5VF92JG2ZRUulffufeUVNOvbZ6NmqAkCUYzCnxhqVGAIPYTFM2o3XY5nlAj UnnI9zKMghl1Cwj19X44mLolLoKySgIy6iMQmVFxVRV3DENgHOQe+dKXUV8JcZl7VX8tIwaH YQIDDcM6D1DFcCwrMbAmFc7HxXsc9U/eXVP910gfw+/TkZftrejz7qf/ht9GYV4l/oz6pomq pomsOOZ0RR0DFizGCq/IY3bCstyCU5fKXP+LGhXfmzlqhLy8X/2VY4H4mpPXYqW9ypzIC3yf 3VR3WXElVXn/B/fnfN4eSW1CGsGXo5vLssGeQVxs31y5i2xW5VuQwihJ665bBPGWvp6YByS+ mRcTHzJC6IqXJitZbYeDYlVY5nOmJdqx6FoPSaZJEMsz+4XN70rnGWro0D+Trc0D18VER0Vq pvSeW64arjUs2m4eaRK+KcNByy+d+txcTl2NE8kjTFFWsh490E4Kn4iy4ysHMBI4ka3hlw3T RPFBublhIy9U+rZqFKzoj3Jw9YYDMd2Bi603T+uNtjFXOzCZMj/XnzI/NP9P4fxvhIMPxret AZkQwPiwVK7qvjUMosNJjGrgLZ0jHxaGDUxLcFPVSCcbaNT7uU5ehoOjP0cJ7gLTjJwVTdvc 42LL7E/Oxb5tOu4EdGkTVXJwi+gO0rQO/Dip9765h3RKH9TSsTbC2tn5l+HgogtF3K2tZWy4 ErfGpdAJ4JJIOyNwz1zKPDXggtfg5O7szpSPNjpnV9by357PoWgV1pPjP17X1rafiTWNI8oj svSLB4d2tU9RK7yrLQPPxyi7ffD5KUzxnQljD0XB5xOld2JYZ9kYYlSVOPt8rvyDS8LMiz7w gDDhAC/056/IzM8P9f5vAAAA//8DAFBLAwQUAAYACAAAACEAdGTryFYDAAC+CAAAEAAIAWRv Y1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAC0VsFu4zYQvRfoPwx0coDGku2skQ1oLbKO3QSoE3etbNEjI40sIjQpkLQT99R7 j3vpuR/Qc4GiP1NsD/2LjqRYllNh0bSoLx7ODN88DjkzYm8eVxI2aKzQauT1uoEHqGKdCLUc ebfR9PjUA+u4SrjUCkfeFq33Jvz8MzY3OkfjBFogCGVHXuZcfub7Ns5wxW2XzIosqTYr7mhp lr5OUxHjhY7XK1TO7wfB0MdHhyrB5DivAb0K8Wzj/i1oouOCn30fbXPCC1mkHZeRWGE4POn1 XzN/r2DfaJPYsBeckrqS2XmeSxFzR0kJZyI22urUwU0ZCeb6Ac1cC+WY33SklKAlCuVqWjIM b9SxjQ2igkWmH6BzcjY4Yn6LI5tzw5eG51lBhZg01mwhRYKkHzD/SWTX2tHfCfMrgV2KJEH1 ZA2Yf7Bms9lYirw07ES2iLnEMWUpTLm0SNC1gl0iL17AnAtDnht3tsHYaQNWfEdvYOjBHbdY 5HbkbbgRXDmvcqsWpSxz60w41cpZuLWYML9WlmLTtymLk3BYOpDwSccKK6KHgS/A7r0Au0wf RMJJtC8JMWiPUS7KRJJ8mOIqxk1Kt+5aMt4PmikvWVQJrwidUwAJt0pQ4SLMFk2utfTHzz98 /O1Dq6nc32oZcynujGi3aWW15AeZaRjXRqCBa3xotT/V0sdffv3zpx9bPU6DfncAE5ehUejg Sjk0Kac9355ffwkRt/dAtUPrTukZp0dAbQrezW6uYXb1FjrvpmMYDAevjqBzLq2u6hY0Nbs9 aoF11Br+QthYcmoQptVcI1Q0n3H6J1vGkq8twiCAtzy+Xxq9Vgc18slQv3//oT7p/7/p6zXa ole1X3XbrrZcd+Z60p7rfUeFZmv8z75Xk2gK4vDh2MKfThNb6NBdgcEUDY087MKE6G73fPcb uXzgWwsZt0BGi+2nmDwWuGq5f4I1VEyXS2DPQ0K+Nrm2NEK1ktsvIMFUKEwoMhSPt3/ae90e 6lltTA1foT/PtjCuA4316q4EK72kuMeSUrNEDrAPmtOzdvSVUPf2No/0BXe4GxeHSrbIuMGE xnA9TmoFu6S2RRTIf5xxtcRk5/N3QzF631efI2HvVTegXzlld7pieO6+E8K/AAAA//8DAFBL AwQUAAYACAAAACEAsjKuOI8BAADQAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfJJfT8MgFMXfTfwOhCd9 6CjrnEo6TPyzxMSp0ZrNvSG9bsQWGkC7fXtpt1WNxje45/DLveeSnq3KAn2AdcroEaa9GCPQ 0uRKL0b4KRtHJxg5L3QuCqNhhNfg8Bnf30tlxaSxcG9NBdYrcCiQtGOyGuGl9xUjxMkllML1 gkMH8dXYUvhwtQtSCfkmFkD6cTwkJXiRCy9IA4yqjoi3yFx2yOrdFi0glwQKKEF7R2iPki+v B1u6Px+0yjdnqfy6gj+tO7Fzr5zqjHVd9+qktYb+KZlNbh7bUSOlm6wkYJ7mknnlC+BTY9/Q fSF0Srpao0oLwhvL58t3oRdrodHBs9CHrWunNSkXwvlJWMirgvx8zR/MS0gHTVXhjUbRDB3Y entGV7ePd+MM3VxPrrOrSyQ8ulBOmsD8zWnQFj5Us3jePzptPV0h3ea46QRyFOZnm7R2yjS5 uMzGmPdjOoxoHPVPMjpgyYDFdN4M8eP9F7DctvA/8TiKkyg+zShlg4Ql34k7AG87/vkH+ScA AAD//wMAUEsBAi0AFAAGAAgAAAAhAFtEzucmAgAAKRYAABMAAAAAAAAAAAAAAAAAAAAAAFtD b250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAR78a0BEBAAB1AwAACwAAAAAAAAAA AAAAAABfBAAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAAAA AAAAAAAAAAChBwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHNQSwECLQAUAAYA CAAAACEAS/U97L0AAAA3AQAAIAAAAAAAAAAAAAAAAACcCAAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAAAAAAAAAAAA AACXCQAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIueG1sLnJlbHNQSwECLQAUAAYACAAAACEA S/U97L0AAAA3AQAAIAAAAAAAAAAAAAAAAACSCgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTYu eG1sLnJlbHNQSwECLQAUAAYACAAAACEA2AOCa9YAAADOAQAAIAAAAAAAAAAAAAAAAACNCwAA cHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0A AAA3AQAAIAAAAAAAAAAAAAAAAAChDAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMueG1sLnJl bHNQSwECLQAUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAAAAAAAAAAAAAACcDQAAcHB0L3Ns aWRlcy9fcmVscy9zbGlkZTgueG1sLnJlbHNQSwECLQAUAAYACAAAACEA39NkKGcBAACxCgAA HwAAAAAAAAAAAAAAAACXDgAAcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVsc1BLAQIt ABQABgAIAAAAIQDERtlQ1wAAAM4BAAAhAAAAAAAAAAAAAAAAAEMRAABwcHQvc2xpZGVzL19y ZWxzL3NsaWRlMTMueG1sLnJlbHNQSwECLQAUAAYACAAAACEArTkEYNcAAADOAQAAIQAAAAAA AAAAAAAAAABZEgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEyLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhACPzcKTWAAAAzgEAACEAAAAAAAAAAAAAAAAAbxMAAHBwdC9zbGlkZXMvX3JlbHMv c2xpZGUxMS54bWwucmVsc1BLAQItABQABgAIAAAAIQAzDh4EwAAAADcBAAAhAAAAAAAAAAAA AAAAAIQUAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTAueG1sLnJlbHNQSwECLQAUAAYACAAA ACEAMw4eBMAAAAA3AQAAIAAAAAAAAAAAAAAAAACDFQAAcHB0L3NsaWRlcy9fcmVscy9zbGlk ZTkueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAAAAAAAAAAAAAACB FgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTcueG1sLnJlbHNQSwECLQAUAAYACAAAACEAx9/F cCYDAADODwAAFAAAAAAAAAAAAAAAAAB8FwAAcHB0L3ByZXNlbnRhdGlvbi54bWxQSwECLQAU AAYACAAAACEA9fuVaIUDAADsCwAAFQAAAAAAAAAAAAAAAADUGgAAcHB0L3NsaWRlcy9zbGlk ZTEueG1sUEsBAi0AFAAGAAgAAAAhABhrJVzMAwAAKQkAABUAAAAAAAAAAAAAAAAAjB4AAHBw dC9zbGlkZXMvc2xpZGU1LnhtbFBLAQItABQABgAIAAAAIQCSdX7CcwQAAG8MAAAVAAAAAAAA AAAAAAAAAIsiAABwcHQvc2xpZGVzL3NsaWRlNC54bWxQSwECLQAUAAYACAAAACEA/9xu/wAE AAASCgAAFQAAAAAAAAAAAAAAAAAxJwAAcHB0L3NsaWRlcy9zbGlkZTMueG1sUEsBAi0AFAAG AAgAAAAhAPv23z7QAwAAIgkAABUAAAAAAAAAAAAAAAAAZCsAAHBwdC9zbGlkZXMvc2xpZGUy LnhtbFBLAQItABQABgAIAAAAIQCKN+s3jwQAAHIPAAAVAAAAAAAAAAAAAAAAAGcvAABwcHQv c2xpZGVzL3NsaWRlNi54bWxQSwECLQAUAAYACAAAACEAnqhPod8DAACYCQAAFQAAAAAAAAAA AAAAAAApNAAAcHB0L3NsaWRlcy9zbGlkZTcueG1sUEsBAi0AFAAGAAgAAAAhAIFePE4TBQAA ixEAABUAAAAAAAAAAAAAAAAAOzgAAHBwdC9zbGlkZXMvc2xpZGU4LnhtbFBLAQItABQABgAI AAAAIQDCLsC5nwcAAFKaAAAWAAAAAAAAAAAAAAAAAIE9AABwcHQvc2xpZGVzL3NsaWRlMTMu eG1sUEsBAi0AFAAGAAgAAAAhAOokMhU0BwAAndIAABYAAAAAAAAAAAAAAAAAVEUAAHBwdC9z bGlkZXMvc2xpZGUxMi54bWxQSwECLQAUAAYACAAAACEAB6mL/C8GAADlcQAAFgAAAAAAAAAA AAAAAAC8TAAAcHB0L3NsaWRlcy9zbGlkZTExLnhtbFBLAQItABQABgAIAAAAIQCDYyo7yAIA AMcFAAAVAAAAAAAAAAAAAAAAAB9TAABwcHQvc2xpZGVzL3NsaWRlOS54bWxQSwECLQAUAAYA CAAAACEAynDQukkCAACpBAAAFgAAAAAAAAAAAAAAAAAaVgAAcHB0L3NsaWRlcy9zbGlkZTEw LnhtbFBLAQItABQABgAIAAAAIQCL4mLP1AAAAMABAAAqAAAAAAAAAAAAAAAAAJdYAABwcHQv bm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA 1dGS8bwAAAA3AQAALAAAAAAAAAAAAAAAAACzWQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDIueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAAAA AAAAAAAAAAC5WgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJl bHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALQAAAAAAAAAAAAAAAAC/WwAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDExLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh AEqvdTnSAAAAvwEAACoAAAAAAAAAAAAAAAAAxlwAAHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9u b3Rlc1NsaWRlMS54bWwucmVsc1BLAQItABQABgAIAAAAIQDWcfqc0wAAAMABAAAqAAAAAAAA AAAAAAAAAOBdAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTIueG1sLnJlbHNQ SwECLQAUAAYACAAAACEABSgWC9MAAADAAQAAKgAAAAAAAAAAAAAAAAD7XgAAcHB0L25vdGVz U2xpZGVzL19yZWxzL25vdGVzU2xpZGUzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG8 AAAANwEAAC0AAAAAAAAAAAAAAAAAFmAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVM YXlvdXQxMC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAA AAAAAB1hAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc1BL AQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAAAAAAACNiAABwcHQvc2xpZGVM YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLx vAAAADcBAAAsAAAAAAAAAAAAAAAAACljAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRl TGF5b3V0NC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAA AAAAAC9kAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc1BL AQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAAAAAAADVlAABwcHQvc2xpZGVM YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ni54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLx vAAAADcBAAAsAAAAAAAAAAAAAAAAADtmAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRl TGF5b3V0Ny54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAA AAAAAEFnAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwucmVsc1BL AQItABQABgAIAAAAIQA05/nTGgcAAPYvAAAhAAAAAAAAAAAAAAAAAEdoAABwcHQvc2xpZGVN YXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEA0EajxC8EAAD3EAAAIQAA AAAAAAAAAAAAAACgbwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsBAi0A FAAGAAgAAAAhAGmiXyEVAQAAxwcAACwAAAAAAAAAAAAAAAAADnQAAHBwdC9zbGlkZU1hc3Rl cnMvX3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAJexVmCCBAAA FBIAACEAAAAAAAAAAAAAAAAAbXUAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5Lnht bFBLAQItABQABgAIAAAAIQDgI+eTwQQAAO8SAAAhAAAAAAAAAAAAAAAAAC56AABwcHQvc2xp ZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54bWxQSwECLQAUAAYACAAAACEAW6wmCMQCAAAMBwAA IQAAAAAAAAAAAAAAAAAufwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcueG1sUEsB Ai0AFAAGAAgAAAAhAEmehN0EAwAAgQgAACEAAAAAAAAAAAAAAAAAMYIAAHBwdC9zbGlkZUxh eW91dHMvc2xpZGVMYXlvdXQ2LnhtbFBLAQItABQABgAIAAAAIQCsQobX9wQAAM4cAAAhAAAA AAAAAAAAAAAAAHSFAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NS54bWxQSwECLQAU AAYACAAAACEAmSAkpwgEAADeEgAAIQAAAAAAAAAAAAAAAACqigAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDQueG1sUEsBAi0AFAAGAAgAAAAhAHYfGYtqBAAAMBEAACEAAAAAAAAA AAAAAAAA8Y4AAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQzLnhtbFBLAQItABQABgAI AAAAIQAqXHdAYAMAALMLAAAhAAAAAAAAAAAAAAAAAJqTAABwcHQvc2xpZGVMYXlvdXRzL3Ns aWRlTGF5b3V0Mi54bWxQSwECLQAUAAYACAAAACEAQzqI3MwDAADNDAAAIgAAAAAAAAAAAAAA AAA5lwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnhtbFBLAQItABQABgAIAAAA IQA+T7HlgQMAAOoLAAAiAAAAAAAAAAAAAAAAAEWbAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRl TGF5b3V0MTAueG1sUEsBAi0AFAAGAAgAAAAhANNhUMnLAgAAEQcAAB8AAAAAAAAAAAAAAAAA Bp8AAHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlMS54bWxQSwECLQAUAAYACAAAACEAkMIT FLsCAACQBgAAHwAAAAAAAAAAAAAAAAAOogAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xpZGUy LnhtbFBLAQItABQABgAIAAAAIQAuFn2QNAMAAKAHAAAfAAAAAAAAAAAAAAAAAAalAABwcHQv bm90ZXNTbGlkZXMvbm90ZXNTbGlkZTMueG1sUEsBAi0AFAAGAAgAAAAhAHyj5e4kAwAACQgA AB8AAAAAAAAAAAAAAAAAd6gAAHBwdC9ub3Rlc1NsaWRlcy9ub3Rlc1NsaWRlNC54bWxQSwEC LQAUAAYACAAAACEAtM9YGbkAAAAkAQAALAAAAAAAAAAAAAAAAADYqwAAcHB0L25vdGVzTWFz dGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAAFdemycG AAC2HgAAIQAAAAAAAAAAAAAAAADbrAAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3RlcjEu eG1sUEsBAi0AFAAGAAgAAAAhAObptInpBQAAXRsAABQAAAAAAAAAAAAAAAAAQbMAAHBwdC90 aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAObptInpBQAAXRsAABQAAAAAAAAAAAAA AAAAXLkAAHBwdC90aGVtZS90aGVtZTIueG1sUEsBAi0ACgAAAAAAAAAhAIFQm7JOFgAAThYA ABcAAAAAAAAAAAAAAAAAd78AAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVnUEsBAi0AFAAGAAgA AAAhAPoxuzosAgAAMQUAABEAAAAAAAAAAAAAAAAA+tUAAHBwdC9wcmVzUHJvcHMueG1sUEsB Ai0AFAAGAAgAAAAhAGVZXx2vAQAAggQAABEAAAAAAAAAAAAAAAAAVdgAAHBwdC92aWV3UHJv cHMueG1sUEsBAi0AFAAGAAgAAAAhANj9jY+sAAAAtgAAABMAAAAAAAAAAAAAAAAAM9oAAHBw dC90YWJsZVN0eWxlcy54bWxQSwECLQAUAAYACAAAACEAtKgOzcMCAACWBQAAEwAAAAAAAAAA AAAAAAAQ2wAAZG9jUHJvcHMvY3VzdG9tLnhtbFBLAQItABQABgAIAAAAIQB0ZOvIVgMAAL4I AAAQAAAAAAAAAAAAAAAAAAzfAABkb2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgAAAAhALIy rjiPAQAA0AIAABEAAAAAAAAAAAAAAAAAmOMAAGRvY1Byb3BzL2NvcmUueG1sUEsFBgAAAABJ AEkA4RUAAF7mAAAAAA== --------------17B56203044C4D1245555027-- From nobody Wed Mar 22 08:26:04 2017 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 70697127337 for ; Wed, 22 Mar 2017 08:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 IybVVRtR4pje for ; Wed, 22 Mar 2017 08:26:00 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291AB127097 for ; Wed, 22 Mar 2017 08:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1960; q=dns/txt; s=iport; t=1490196360; x=1491405960; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Y0t0ObovfOtStYeC3hICk/i7WHvx9Sc7Ipd8bHC2ujs=; b=DtZ/qRa9CjtDp4C0EqPUpDNG5QmnOfLkBa7QDLZ4P8yqkNgonJJHTfgQ 1SVEF/BcUIx6mIzYEu000xqPvq+y393GlKx8mqPx1Llq1Bw5EPd/SMFrp MeYV3L/IG85E7iDEi3H9DRGV4p2Lg4F24DxKVLJrdYcbUUs0A9XaMAbff w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAQArl9JY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDKBCo1xc5BQH5VHgg4fC4UuSgKDaBgBAgEBAQEBAQFrKIUWAQE?= =?us-ascii?q?BAwEBNjYLEAsOCi4nMAYBDAYCAQGKAA6tRIo+AQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHYZOggUIgmKDF4EnhXsBBJxRhnqLTYF7VIRWgzSGVotNiBMfOIEEJBYIFxU?= =?us-ascii?q?YKYZZPzWKAQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,205,1486425600"; d="scan'208";a="693171339" 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; 22 Mar 2017 15:25:51 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2MFPpRY018117; Wed, 22 Mar 2017 15:25:51 GMT To: Martin Bjorklund , netmod@ietf.org, "timothy.carey@alcatel-lucent.com" , "wlupton@broadband-forum.org" References: <148939103369.17026.5784133761974804877@ietfa.amsl.com> <20170313.084651.1144668331995785992.mbj@tail-f.com> Cc: David Sinicrope From: Benoit Claise Message-ID: <1ecba9d5-d9de-f967-0061-2a89822406bd@cisco.com> Date: Wed, 22 Mar 2017 16:25:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170313.084651.1144668331995785992.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 15:26:02 -0000 Tim, William, Are we good from a Broadband Forum point of view? I remember some discussions during the last IETF meeting regarding this entity YANG module. Regards, Benoit > Hi, > > This version addresses the comments from Bart and Juergen. > > I think that this document is now ready for WGLC. > > > /martin > > > internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the NETCONF Data Modeling Language of the IETF. >> >> Title : A YANG Data Model for Hardware Management >> Authors : Andy Bierman >> Martin Bjorklund >> Jie Dong >> Dan Romascanu >> Filename : draft-ietf-netmod-entity-03.txt >> Pages : 40 >> Date : 2017-03-13 >> >> Abstract: >> This document defines a YANG data model for the management of >> hardware on a single server. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-netmod-entity-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-03 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Wed Mar 22 10:36:02 2017 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 C13C2129B95 for ; Wed, 22 Mar 2017 10:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 M70UdLrAGCsF for ; Wed, 22 Mar 2017 10:35:59 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 4ECFF129B97 for ; Wed, 22 Mar 2017 10:35:59 -0700 (PDT) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2MHRxMY022126 for ; Wed, 22 Mar 2017 10:35:56 -0700 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 29b9vj62ny-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 22 Mar 2017 10:35:56 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Mar 2017 11:35:53 -0600 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Mar 2017 18:35:52 +0100 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1210.000; Wed, 22 Mar 2017 18:35:52 +0100 From: William Ivory To: "netmod@ietf. org netmod@ietf.org netmod@ietf. org (netmod@ietf.org)" CC: Nick Brown Thread-Topic: Interaction of 'when' and 'default' statements Thread-Index: AdKjMZ0ImM/a65bBTgeHa23x/dyvHw== Date: Wed, 22 Mar 2017 17:35:28 +0000 Deferred-Delivery: Wed, 22 Mar 2017 17:30:25 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.212.188] Content-Type: multipart/alternative; boundary="_000_ae8d8d4e64e34dc8bb21fac7d90eb2c0EMEAWPEXMB12corpbrocade_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-22_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703220147 Archived-At: Subject: [netmod] Interaction of 'when' and 'default' statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 17:36:01 -0000 --_000_ae8d8d4e64e34dc8bb21fac7d90eb2c0EMEAWPEXMB12corpbrocade_ Content-Type: text/plain; charset="us-ascii" Hi, I'm looking for clarification of the 'when' and 'default' statements on a leaf. For example, if a leaf has a 'default', can it also have a 'when' statement that could cause it to disappear if the 'when' condition evaluates to false? Section 8.3 or RFC 6020 isn't clear on how evaluation of constraints should be done here, and neither the section on the 'when' statement nor the 'default' section have any cross-references. Thanks, William --_000_ae8d8d4e64e34dc8bb21fac7d90eb2c0EMEAWPEXMB12corpbrocade_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I’m looking for clarification of the ‘when’ and R= 16;default’ statements on a leaf.  For example, if a leaf has a = ‘default’, can it also have a ‘when’ statement that= could cause it to disappear if the ‘when’ condition evaluates = to false?  Section 8.3 or RFC 6020 isn’t clear on how evaluation of constraints should be done here= , and neither the section on the ‘when’ statement nor the ̵= 6;default’ section have any cross-references.
 
Thanks,
 
William
 
 --_000_ae8d8d4e64e34dc8bb21fac7d90eb2c0EMEAWPEXMB12corpbrocade_-- From nobody Wed Mar 22 10:52:46 2017 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 97E2D129B72 for ; Wed, 22 Mar 2017 10:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 mIgVJgSt-31Q for ; Wed, 22 Mar 2017 10:52:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EF8EB129BCD for ; Wed, 22 Mar 2017 10:52:43 -0700 (PDT) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id EC3931AE05F4; Wed, 22 Mar 2017 18:52:42 +0100 (CET) Date: Wed, 22 Mar 2017 18:52:42 +0100 (CET) Message-Id: <20170322.185242.1479962682961917887.mbj@tail-f.com> To: wivory@Brocade.com Cc: netmod@ietf.org, brownn@Brocade.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Interaction of 'when' and 'default' statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 17:52:45 -0000 William Ivory wrote: > Hi, > > I'm looking for clarification of the 'when' and 'default' statements > on a leaf. For example, if a leaf has a 'default', can it also have a > 'when' statement that could cause it to disappear if the 'when' > condition evaluates to false? Yes, and in that case the default doesn't apply. > Section 8.3 or RFC 6020 isn't clear on > how evaluation of constraints should be done here, and neither the > section on the 'when' statement nor the 'default' section have any > cross-references. If the "when" expression evaluates to false, it's like if the whole node doesn't exist. A client can't set it etc. /martin From nobody Wed Mar 22 10:56:02 2017 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 16071129B77 for ; Wed, 22 Mar 2017 10:56:01 -0700 (PDT) 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 Fsw9mRlzlBkp for ; Wed, 22 Mar 2017 10:55:59 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (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 92946127A91 for ; Wed, 22 Mar 2017 10:55:59 -0700 (PDT) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2MHlM8Z029472; Wed, 22 Mar 2017 10:55:57 -0700 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 29baajeh2b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 22 Mar 2017 10:55:57 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Mar 2017 11:55:54 -0600 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Mar 2017 18:55:52 +0100 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1210.000; Wed, 22 Mar 2017 18:55:52 +0100 From: William Ivory To: Martin Bjorklund CC: "netmod@ietf.org" , Nick Brown Thread-Topic: [netmod] Interaction of 'when' and 'default' statements Thread-Index: AdKjMZ0ImM/a65bBTgeHa23x/dyvH///9jcA///vxyA= Date: Wed, 22 Mar 2017 17:55:31 +0000 Deferred-Delivery: Wed, 22 Mar 2017 17:52:25 +0000 Message-ID: References: <20170322.185242.1479962682961917887.mbj@tail-f.com> In-Reply-To: <20170322.185242.1479962682961917887.mbj@tail-f.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.212.188] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-22_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703220152 Archived-At: Subject: Re: [netmod] Interaction of 'when' and 'default' statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 17:56:01 -0000 Hi Martin, Thanks. Can you point me at the part of RFC 6020 that explicitly states that 'when' wins over 'default'? William -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: 22 March 2017 17:53 To: William Ivory Cc: netmod@ietf.org; Nick Brown Subject: Re: [netmod] Interaction of 'when' and 'default' statements William Ivory wrote: > Hi, > > I'm looking for clarification of the 'when' and 'default' statements > on a leaf. For example, if a leaf has a 'default', can it also have a > 'when' statement that could cause it to disappear if the 'when' > condition evaluates to false? Yes, and in that case the default doesn't apply. > Section 8.3 or RFC 6020 isn't clear on how evaluation of constraints > should be done here, and neither the section on the 'when' statement > nor the 'default' section have any cross-references. If the "when" expression evaluates to false, it's like if the whole node doesn't exist. A client can't set it etc. /martin From nobody Wed Mar 22 10:59:09 2017 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 8D95F12869B for ; Wed, 22 Mar 2017 10:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iImixN_PqN6R for ; Wed, 22 Mar 2017 10:59:05 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0108.outbound.protection.outlook.com [104.47.0.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E978E127871 for ; Wed, 22 Mar 2017 10:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sqPCWobKLmWazr/kNWF1KunaI+pBVDX8OCTA49Fsw3Y=; b=VVc+ZF8dXS3M2ESNC4eiNUndzorQq3gOa1swVRY4kE5lVJqhuCcJUf1xDy9YjCR1yTo/palIIZIzvhKYxixj8U2hg5ae8yDIy1mUDCfPuptN5eBUhm33T7U2uhfP/1Ge84xCS9McK+wLdtS2wK+9Ij4l+vXUS5wtp+N+BrgXwZc= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0626.eurprd07.prod.outlook.com (10.160.54.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 22 Mar 2017 17:59:02 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) with mapi id 15.01.0991.013; Wed, 22 Mar 2017 17:59:01 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: William Ivory , Martin Bjorklund CC: Nick Brown , "netmod@ietf.org" Thread-Topic: [netmod] Interaction of 'when' and 'default' statements Thread-Index: AdKjMZ0ImM/a65bBTgeHa23x/dyvH///9jcA///vxyD//9228A== Date: Wed, 22 Mar 2017 17:59:01 +0000 Message-ID: References: <20170322.185242.1479962682961917887.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: Brocade.com; dkim=none (message not signed) header.d=none;Brocade.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.7] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0626; 7:fpv0TFOJ9Iv9aIB6JOEg9V6f1mkv4E33SjQdoQmCeiH1Dzq1+2UmD6LZUX8sUAlP5C7VAgBo6KWwl+2J3wb7gNrWDeLpyKwXshu7AVRh0BHTq8X+cq7ZnIKj2zLg1W1cFdO/cWJqvWBa55goV1vBi6eVgvt0jkeDGtVPUzwDcjyb3I9NiXkI4hEUK/u3ug4WSEZ/MFThJnzgNKsaC15I/bHF7fmYsMqqWIu6Bq96esTe7OvPwCQsCzsn2R6iJNK1myXkj7Zx424PsYc6dI0HHgiyfEhrFJuJ2L4yigD8pPndVzmtcJniY7S6uEiVHfx1+CaryVofPf793Cz4vbDOhA== x-ms-office365-filtering-correlation-id: 0015c843-82a9-4d43-6f0c-08d4714d1f59 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:AM2PR07MB0626; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:AM2PR07MB0626; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0626; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39860400002)(39850400002)(39840400002)(39410400002)(39450400003)(24454002)(13464003)(189998001)(3846002)(53936002)(50986999)(33656002)(2900100001)(2950100002)(54356999)(76176999)(6246003)(99936001)(6116002)(102836003)(38730400002)(8676002)(122556002)(5660300001)(229853002)(3280700002)(2906002)(81166006)(305945005)(3660700001)(8936002)(7736002)(6436002)(6506006)(54906002)(99286003)(55016002)(9686003)(86362001)(6306002)(66066001)(25786009)(77096006)(53546009)(4326008)(74316002)(7696004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0626; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0538_01D2A33E.5D53AB70" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 17:59:01.5485 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0626 Archived-At: Subject: Re: [netmod] Interaction of 'when' and 'default' statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 17:59:07 -0000 ------=_NextPart_000_0538_01D2A33E.5D53AB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit William, The when clause determines whether the node will be instantiated or not. Only when it is instantiated (when condition evaluates to true), the default property comes into the picture. At least, that is how I interpret it. Best regards - Vriendelijke groeten, Bart Bogaert -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of William Ivory Sent: 22 March 2017 18:56 To: Martin Bjorklund Cc: Nick Brown ; netmod@ietf.org Subject: Re: [netmod] Interaction of 'when' and 'default' statements Hi Martin, Thanks. Can you point me at the part of RFC 6020 that explicitly states that 'when' wins over 'default'? William -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: 22 March 2017 17:53 To: William Ivory Cc: netmod@ietf.org; Nick Brown Subject: Re: [netmod] Interaction of 'when' and 'default' statements William Ivory wrote: > Hi, > > I'm looking for clarification of the 'when' and 'default' statements > on a leaf. For example, if a leaf has a 'default', can it also have a > 'when' statement that could cause it to disappear if the 'when' > condition evaluates to false? Yes, and in that case the default doesn't apply. > Section 8.3 or RFC 6020 isn't clear on how evaluation of constraints > should be done here, and neither the section on the 'when' statement > nor the 'default' section have any cross-references. If the "when" expression evaluates to false, it's like if the whole node doesn't exist. A client can't set it etc. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0538_01D2A33E.5D53AB70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjIxNzU4NTlaMCMGCSqGSIb3DQEJBDEWBBQsXBSs Ao6QJh7LsIwO+nFby5c5zjCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAEzAA3kjMu1YC1B8tamcx2uZ6OXCHmvwprApKUkyFirtHQg6MdQR7v6rsRkt rPbt4OMi6//OxENjKHpXaH+Il/FPbmmclmGGuPST40yIDN9g8kEWvQd6O15INGdYZjGz4ID7H8zN Vu4/27zW7Ep5qlvxcAZTaRo8FXmB1fZA7wbK6Jlsr8xvx/zdJ+xmxgX5azKVl1i2s/Zk8JgB1bnu SBcpyK5iwdrCeCiwuPAoPEK+xdtpQL3smc6O3k87BRZNrCenKbGaNm4wazL31mfbc3wTuF1BgoaA 74fy7annkru6xmjre4EK05MLBmzz2e8xtIwCv5ykhPBuOVIzGaVlCFEAAAAAAAA= ------=_NextPart_000_0538_01D2A33E.5D53AB70-- From nobody Wed Mar 22 11:23:07 2017 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 1A993129BCC for ; Wed, 22 Mar 2017 11:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 bw1tSXmsgXpH for ; Wed, 22 Mar 2017 11:23:03 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 45E30129BCF for ; Wed, 22 Mar 2017 11:23:03 -0700 (PDT) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 6F53F1AE05F8; Wed, 22 Mar 2017 19:23:00 +0100 (CET) Date: Wed, 22 Mar 2017 19:23:00 +0100 (CET) Message-Id: <20170322.192300.1698563417511122835.mbj@tail-f.com> To: wivory@Brocade.com Cc: netmod@ietf.org, brownn@Brocade.com From: Martin Bjorklund In-Reply-To: References: <20170322.185242.1479962682961917887.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Interaction of 'when' and 'default' statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 18:23:05 -0000 William Ivory wrote: > Hi Martin, > > Thanks. Can you point me at the part of RFC 6020 that explicitly > states that 'when' wins over 'default'? Section 7.6.1 of RFC 7950 says: Note that if the leaf or any of its ancestors has a "when" condition or "if-feature" expression that evaluates to "false", then the default value is not in use. /martin > > William > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: 22 March 2017 17:53 > To: William Ivory > Cc: netmod@ietf.org; Nick Brown > Subject: Re: [netmod] Interaction of 'when' and 'default' statements > > William Ivory wrote: > > Hi, > > > > I'm looking for clarification of the 'when' and 'default' statements > > on a leaf. For example, if a leaf has a 'default', can it also have a > > 'when' statement that could cause it to disappear if the 'when' > > condition evaluates to false? > > Yes, and in that case the default doesn't apply. > > > Section 8.3 or RFC 6020 isn't clear on how evaluation of constraints > > should be done here, and neither the section on the 'when' statement > > nor the 'default' section have any cross-references. > > If the "when" expression evaluates to false, it's like if the whole node doesn't exist. A client can't set it etc. > > > /martin > From nobody Wed Mar 22 12:49:12 2017 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 1E5D2129AA2 for ; Wed, 22 Mar 2017 12:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 6MJV86z5orQs for ; Wed, 22 Mar 2017 12:49:09 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 C85F9128BA2 for ; Wed, 22 Mar 2017 12:49:09 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-04v.sys.comcast.net with SMTP id qmEdc3WtascBPqmFpckp8i; Wed, 22 Mar 2017 19:49:09 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-06v.sys.comcast.net with SMTP id qmFncGqqReyvGqmFoctLKk; Wed, 22 Mar 2017 19:49:09 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2MJn7ah022742 for ; Wed, 22 Mar 2017 15:49:07 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2MIQrES013202; Wed, 22 Mar 2017 14:26:53 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 22 Mar 2017 14:26:53 -0400 Message-ID: <87shm5rwuq.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfEwJzLVMwbBw7efr4y1I3iHVuazUnbc5iCehQRrxD1XdSA/OajNwZIwzDmgJe7/UKDtgE5I3wjvYfkYLCOd/lzSpEqlzCyj9Gzzc91+dGFT3hVPyXAwY imNGilgByH/Cr76BLEJRjnVhNLDSs0JvH6YggqnxI8FzgyinZrPH9EIT Archived-At: Subject: [netmod] uses and augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 19:49:11 -0000 I've got a couple of questions about the interaction of "uses" and "augment". I hope that these have straightforward answers that the old hands can tell me easily enough. 1. Augmenting a grouping I notice that "augment" is not allowed to target a "grouping", despite that naively seems to be an operation that a module designer might like to do. I expect that there is a reason why this is not allowed. For example: module foo { ... grouping target { leaf address { type inet:ip-address; description "Target IP address."; } leaf port { type inet:port-number; description "Target port number."; } } } module bar { ... import foo { ... } augment "/foo:target" { leaf new-leaf { type string; } } } module baz { ... import foo { ... } container main { uses foo:target; } } giving an effective schema: container main { leaf address { type inet:ip-address; description "Target IP address."; } leaf port { type inet:port-number; description "Target port number."; } leaf new-leaf { type string; } } This construct seems to be well-defined to me, other than that it's not immediately clear what namespace baz:main/new-leaf is in. (For some reason, I reflexively think that it's in bar's namespace, not baz's, but I can't state any reasoning for that.) 2. "augment" as a substatement of "uses" In section 7.17: The "augment" statement allows a module or submodule ... to add to the nodes from a grouping in a "uses" statement. When I first read this, I took it to mean that an "augment" substatement adds a peer node to the set of nodes 'from a grouping in a "uses" statement'. But I suspect that it is intended to mean that an "augment" only adds nodes *under* one of the nodes from the grouping. There's an ambiguity that could be fixed by better wording. 7.17 also says: If the "augment" statement is a substatement to the "uses" statement, the descendant form (defined by the rule "descendant-schema-nodeid" in Section 14) MUST be used. My understanding is that "descendant-schema-nodeid" is an XPath expression, and that the "context node" for its evaluation is the node to which the "uses" statement adds nodes -- but that doesn't seem to be stated anywhere. (Those last two I should have caught in my Gen-ART review!) Thanks for any information, Dale From nobody Wed Mar 22 13:22:13 2017 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 9EBEB128B4E for ; Wed, 22 Mar 2017 13:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CenfHRxEEnfH for ; Wed, 22 Mar 2017 13:22:08 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3858128BB6 for ; Wed, 22 Mar 2017 13:22:07 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id t189so47948200wmt.1 for ; Wed, 22 Mar 2017 13:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Ls1G5pbxG0QKFIFTSZCXjqEKMX3oLK4ngW+8uWh5evg=; b=c/9eV1R7Z6QP+qoyUPap2Tv1plZQhPH5B9Ia78ght40rzudE2A+f2tIhy78Rsj7jff ZzNM3prNJtu+U7YGiqIWltMCpOrRqL/lBUGjK13WPl6z5sPQ4VtetbkZ8fu/Q/Voml7b YFHqT5luFwwN1y9ful0/UWcxTyPcnagwA96lQri5cYDhUOwwFKpSbAclkyj/IUEILr7L eRoZkd9zrHmQcxUYhDfhvm5+OK3CW+Y9mXGfFTPDL3ys458NdqgL3FRc/3SuBigvhnGQ sHbcEI+0yD+a2i2C8gTeqaBYqLkzaW04K/Yg4ZlyxS1JCdnqudK071IXuJrnv4B/XnME q3Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Ls1G5pbxG0QKFIFTSZCXjqEKMX3oLK4ngW+8uWh5evg=; b=cj4NxUCKaZFGNTMk+ldcc+ciCE7vWR6/kO94NpZWvJn29xbYDX7rut9Fv7/In6EtXo 9yjnK3zRbJrIOhMIpARQZ+7qO8wgqOLhtZmdhaFrSap1AbYByWLS3ZnWdKthg1VXPE5f UtJzWtLf4DaffbeY9k9IQ5dZa+awh/RZqlNVpcOjb6jqt0/rWOFY1Onaat2/VhjOLx2Q z/B+uXR2/X5Ciuq1Nv7ZsZOQ/zgd5x9QlBw8LhSQvJbVba+K/RVyMNEzReSHV849YeQR iG//VTN8kr5KWPDisyivZtoHGbbj0mtsnB+vklnhWFXEh9SEonG6kf6jNO1yQGLD910i Vmeg== X-Gm-Message-State: AFeK/H1KAWNrvAHPAZWoTiGC5QdbeK9ESE9j+rwn6SiBk6rigq0vSV1HHjaBCyQY9o/72Q== X-Received: by 10.28.16.149 with SMTP id 143mr9149544wmq.42.1490214125979; Wed, 22 Mar 2017 13:22:05 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p5DCC67DF.dip0.t-ipconnect.de. [93.204.103.223]) by smtp.gmail.com with ESMTPSA id c8sm3086638wrd.57.2017.03.22.13.22.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 13:22:05 -0700 (PDT) From: "Mehmet Ersue" To: "'Lou Berger'" , "'Kent Watsen'" , References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <675654fd-1532-1755-621c-a3ecb06950e3@labn.net> <025a01d29e82$8549d070$8fdd7150$@gmail.com> In-Reply-To: Date: Wed, 22 Mar 2017 21:22:07 +0100 Message-ID: <007201d2a349$fa8c3b40$efa4b1c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUooBvvnQPAGVQNXrAT+Tz94BQZmbIKCarq1AgAGbAcCABgfQEA== Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0208.58D2DCED.000A,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:22:12 -0000 Hi Kent, Lou, as I see 7950bis has not been mentioned in the charter text and the milestones. As you know NETCONF and RESTCONF revisions are dependent on the timing of 7950bis. How is this essential deliverable and its timing going to be addressed in the charter? Mehmet > -----Original Message----- > From: Mehmet Ersue > Sent: Friday, March 17, 2017 11:51 PM > To: Lou Berger ; 'Kent Watsen' ; > netmod@ietf.org > Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' > > Subject: RE: [netmod] draft netmod charter update proposal > > Hi Lou, Kent, > > I promised to provide some minimal text which can be used as WG item > description. > I'm fine with any fine tuning. > > See below: > > a) Maintaining the data modeling language YANG. This effort entails > periodically updating the specification to address new requirements > as they arise. ADD 7950./> > > b) Maintaining the guidelines for developing YANG models. This effort > is primarily driven by updates made to the YANG specification. ADD continuous effort has been recently addressed with a revision of RFC 6087./> > > c) Maintaining a conceptual framework in which YANG models are used. > This effort entails describing the generic context that in YANG > exists and how certain YANG statements interact in that context. > An example of this is YANG's relationship with datastores. ADD revised datastore draft will provide a conceptual framework for the handling > of datastores, which can be adopted by other WGs for their usage > scenario./> > > . . . > > e) Maintaining YANG models used as basic YANG building blocks. This > effort entails updating existing YANG models (ietf-yang-types and > ietf-inet-types) as needed, as well as defining additional core YANG > data models when necessary. ADD the models for Syslog, ACL and Common Interface Extensions as well as the > model for hardware management. The Schema mount draft will provide a > mechanism to combine YANG modules into the schema defined in other > YANG modules./> > > BTW: There is no topic description (in a)-f) covering YANG module > classification. > I assume it can be added with a sentence to a) or b). > > Thanks, > Mehmet > > > -----Original Message----- > > From: Mehmet Ersue > > Sent: Thursday, March 16, 2017 11:59 PM > > To: Lou Berger ; 'Kent Watsen' > > ; netmod@ietf.org > > Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' > > > > Subject: RE: [netmod] draft netmod charter update proposal > > > > > From: Lou Berger [mailto:lberger@labn.net] Mehmet, > > > see below. > > > On 3/16/2017 2:24 PM, Mehmet Ersue wrote: > > > > Lou, > > . . . > > > > I actually provided a very simple proposal. You guys can fill the > > > > idea with minimal text better than me. I'm fine whatever the text is. > > > > If you think the high-level topic description a)-f) does already > > > > define the WG item clearly you can simply say "this is achieved > > > > with WG > > > item XY". > > > > If not, you can keep the high-level focus text but set > > > > additionally the borders of the WG item with a few concrete words. > > > > > > I really can't tell for sure, but it feels to me that this comment > > > boils down to a style comment and you have a preference for > > > different contents in the charter. I'd like to be sensitive to > > > this. As our style differs, having a concrete proposal on specific > > > text changes would be really helpful in us (and the WG) evaluating > > > the changes you'd like to see. Without such specific examples and > > > think we're left with the charter as currently proposed. Perhaps > > > someone else who > > has similar feelings can chime in and provide proposed text. > > > > > > Anyone else have any comments or proposed changes? > > I think the wording depends on the time period is for which the > > charter is prepared. > > I can try some text once I have time tomorrow. > > > > . . . > > > > I think the DS draft provides a conceptual framework for diverse > > > > DS usage scenarios to be used by many protocols, where IETF WGs > > > > may actually decide using a subset of the DS framework for their > > > > purpose and for their protocol standardization. > > > > Based on this the conceptual framework cannot be standardized as > > > > it is but the protocols using a consistent subset have to be standardized. > > > > Following this consideration I think the intended status of the DS > > > > draft should be changed to: Informational RFC If you agree please > > > > indicate this change accordingly. > > > > > > I think Juergen's reply to your previous message highlights that > > > there is a difference of opinion here based on the technical > > > specifics of the draft. My position as chair is that I'll support > > > whatever makes sense based on the document produced by the WG. > > > Today the document authors believe PS is appropriate, once we have a > > > version that is stabilizing for LC -- which hopefully will be the > > > next version or two > > > -- then will be a good time to revisit this. > > There are indeed different opinions concerning the goal of the DS draft. > > I agree with the document introduction and see it as a conceptual > > framework covering many usage scenarios. > > Such a conceptual framework describing possible solutions is > > informational in nature and is not relevant for standardization. > > > > > >>> This is as I think also important to avoid an overlapping > > > >>> between NETCONF and NETMOD charters. > > > >> I don't follow this point. Certainly I'd hope that the protocol > > > >> impact of revised DS are covered in a PS document, unless for > > > >> some reason there are no "on-the-wire" changes needed. TI > > > >> wouldn't expect that the document status of the base revised data > > > >> store document would > > > impact that. Do you? > > > >> If so, how? > > > > My comment is actually superfluous if you agree with my > > > > considerations above. > > > > The worst case would in my opinion happen if the DS conceptual > > > > framework covering many high-level DS usage scenarios would be > > > > attempted to standardize, which at the end would prescribe > > > > protocol WGs what they should be standardizing. > > > > > > Yang presumes a certain set of functions for the protocols it operates > over. > > > I'm not sure why having a document that specifies this would be an issue. > > This is again an interesting discussion which SHOULD be discussed in a > > joint session. > > I don't have a strong opinion but it can be seen differently. > > > > > > In such a case the conceptual framework would most likely cause a > > > > competing situation with protocol WG's goals and documents and > > > > cannot be adopted successfully. > > > > > > If a protocol doesn't provide full support for yang (requirements) > > > it can't fully support all yang features. If your point is that > > > when NetMod changes basic yang functions/operations that this might > > > constrain the protocols (and related WGs) over which it operates, > > > then I agree that this is the case. How could it be otherwise? > > Usually modeling languages provide many language constructs and people > > modeling models choose which one is best for their purpose. > > The same applies to the DS concept framework. The protocol WGs would > > like to have the freedom to choose the subset to adopt from the protocol > pov. > > > > > Thanks, > > > > > > Lou > > > > > > > Thanks, > > > > Mehmet > > > > > > > >>> PS: I expect that most of the Netconf WG member read also the > > > Netmod > > > >>> maillist and therefor skip sending to both ML. > > > >>> > > > >> Great. > > > >> > > > >> Thanks. > > > >> Lou > > > >>> Thanks, > > > >>> Mehmet > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Mehmet Ersue > > > >>>> Sent: Thursday, March 9, 2017 7:36 PM > > > >>>> To: Lou Berger ; 'Kent Watsen' > > > >>>> ; netmod@ietf.org > > > >>>> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' > > > >>>> > > > >>>> Subject: RE: [netmod] draft netmod charter update proposal > > > >>>> > > > >>>> Hi Lou, > > > >>>> > > > >>>>> The charters from the last couple of years don't have the > > > >>>>> intended > > > >>> status -- > > > >>>> at least the ones we checked. > > > >>>>> I actually feel pretty strongly about this (which of course > > > >>>>> can be easily overruled by our AD). It's my experience that > > > >>>>> premature discussions on intended status, i.e., before a > > > >>>>> document is sufficiently > > > >>>> mature, leads to process-focused arguments that detracts from > > > >>>> making technical progress. While once a document is mature and > > > >>>> core direction/content is fixed, it is generally obvious what > > > >>>> status is > > > >>> appropriate. > > > >>>> The charters from the last couple of years have a short WG item > > > >>> definition, > > > >>>> which would be IMO sufficient. > > > >>>> You are right the intended status is not available since a few > > > >>>> years, but > > > >>> IMO it > > > >>>> is part of the target definition and would be very useful for > > > >>>> the draft > > > >>> authors > > > >>>> and WG members to regard. > > > >>>> > > > >>>>>> It would be good to bring the high-level topics in relation > > > >>>>>> to the WG > > > >>>> items. > > > >>>>> I'm sorry, I don't understand this last sentence can you rephrase > it? > > > >>>> What I meant is that the high-level topics a)-f) might be good > > > >>>> as WG focus description but are not sufficient as draft target > definition. > > > >>>> If you think the high-level topic description is more or less > > > >>>> the WG item definition, then we could simply write "this is > > > >>>> achieved with WG > > > > item > > > >> XY". > > > >>>> If not, we could keep the high-level focus text but set > > > >>>> additionally the borders of the WG item with some concrete words. > > > >>>> > > > >>>>>> BTW: We agreed in diverse discussions that the DS concept is > > > >>>> Informational in nature. > > > >>>>>> I think this should be corrected in the draft. > > > >>>>> So this sounds like an objection to a specific document. This > > > >>>>> is a fair point to raise, but in our opinion it is not a > > > >>>>> charter impacting point or discussion. If this is in fact the > > > >>>>> issue you'd like to raise and discuss, lets do so under a > > > >>>>> document specific thread, e.g., > > > >>> "Subject: > > > >>>> intended status of revised-datastore". > > > >>>> > > > >>>> I am actually raising this point since November meeting. There > > > >>>> are > > > >>> different > > > >>>> threads where I explained why it is appropriate as Informational. > > > >>>> The last thread I remember is at: > > > >>>> > > > >> > > > > > > https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH1 > > > >>>> 1xcY > > > >>>> The recent position of NETCONF co-chairs is in > > > >>>> > > > >> > > > > > > https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd > > > >>>> 8qr5k > > > >>>> > > > >>>> Thank you for your consideration. > > > >>>> > > > >>>> Regards, > > > >>>> Mehmet > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Lou Berger [mailto:lberger@labn.net] > > > >>>>> Sent: Wednesday, March 8, 2017 11:28 PM > > > >>>>> To: Mehmet Ersue ; 'Kent Watsen' > > > >>>>> ; netmod@ietf.org > > > >>>>> Subject: Re: [netmod] draft netmod charter update proposal > > > >>>>> > > > >>>>> Hi Mehmet, > > > >>>>> > > > >>>>> On 3/8/2017 4:47 PM, Mehmet Ersue wrote: > > > >>>>>> Kent, > > > >>>>>> > > > >>>>>>> we understand that this is how NETCONF charters are > > > >>>>>>> structured, but it is not our practice, > > > >>>>>> AFAIK it was the NETMOD practice for the charters until today. > > > >>>>> The charters from the last couple of years don't have the > > > >>>>> intended status -- at least the ones we checked. > > > >>>>> > > > >>>>> I actually feel pretty strongly about this (which of course > > > >>>>> can be easily overruled by our AD). It's my experience that > > > >>>>> premature discussions on intended status, i.e., before a > > > >>>>> document is sufficiently mature, leads to process-focused > > > >>>>> arguments that detracts > > > >>> from > > > >>>> making technical progress. > > > >>>>> While once a document is mature and core direction/content is > > > >>>>> fixed, it is generally obvious what status is appropriate. > > > >>>>> > > > >>>>> > > > >>>>>> I did not ask > > > >>>>>> more than written in the current charter. > > > >>>>>> It would be good to bring the high-level topics in relation > > > >>>>>> to the WG > > > >>>> items. > > > >>>>> I'm sorry, I don't understand this last sentence can you rephrase > it? > > > >>>>> > > > >>>>>>> as the information is available at the top of each draft, > > > >>>>>>> and also because > > > >>>>> this information need not be fixed when the milestone is added. > > > >>>>> > > > >>>>>> I believe a WG charter should be self-sufficient covering the > > > >>>>>> target definition and intended status of the WG items. > > > >>>>>> Otherwise one can change the target for a WG item by simply > > > >>>>>> editing the draft abstract anytime. > > > >>>>> Per IETF process, all it ever takes to make a change in > > > >>>>> document status is WG consensus, and then IESG and IETF buy-in > > > >>>>> as part of the > > > >>>> publication process. > > > >>>>>> BTW: We agreed in diverse discussions that the DS concept is > > > >>>>>> Informational in nature. > > > >>>>>> I think this should be corrected in the draft. > > > >>>>> So this sounds like an objection to a specific document. This > > > >>>>> is a fair point to raise, but in our opinion it is not a > > > >>>>> charter impacting point or discussion. If this is in fact the > > > >>>>> issue you'd like to raise and discuss, lets do so under a > > > >>>>> document specific thread, e.g., > > > >>> "Subject: > > > >>>>> intended status of revised-datastore". > > > >>>>> > > > >>>>> Thanks, > > > >>>>> Lou > > > >>>>> > > > >>>>>> Mehmet > > > >>>>>> > > > >>>>>>> -----Original Message----- > > > >>>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of > > > Kent > > > >>>>>>> Watsen > > > >>>>>>> Sent: Wednesday, March 8, 2017 7:45 PM > > > >>>>>>> To: netmod@ietf.org > > > >>>>>>> Cc: netmod-chairs@ietf.org > > > >>>>>>> Subject: Re: [netmod] draft netmod charter update proposal > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Hi NETMOD WG, > > > >>>>>>> > > > >>>>>>> Please find below draft-4 having the following change: > > > >>>>>>> > > > >>>>>>> - added "(e.g., I2RS, RTGWG)" to a sentence. > > > >>>>>>> > > > >>>>>>> Hi Sue, Lou and I looked at the proposed charter and found a > > > >>>>>>> sentence that nicely describes our WG's intent to work with > > > >>>>>>> and support other WGs (beyond NETCONF), but we felt that > the > > > >>>>>>> text could be made more clear by adding in the > > > >>>>>>> above-mentioned > > > change. > > > >>>>>>> Beyond this, and the existing a), > > > >>>>>> b), > > > >>>>>>> and c), we believe that the charter proposal covers our > > > >>>>>>> support for I2RS, > > > >>>>>> do > > > >>>>>>> you agree? > > > >>>>>>> > > > >>>>>>> Hi Mehmet, regarding putting a short description and the > > > >>>>>>> intended status > > > >>>>>> for > > > >>>>>>> each draft into the charter, we understand that this is how > > > >>>>>>> NETCONF > > > >>>>>> charters > > > >>>>>>> are structured, but it is not our practice, as the > > > >>>>>>> information is > > > >>>>>> available at the > > > >>>>>>> top of each draft, and also because this information need > > > >>>>>>> not be fixed > > > >>>>>> when > > > >>>>>>> the milestone is added. > > > >>>>>>> > > > >>>>>>> All, Any other comments? > > > >>>>>>> > > > >>>>>>> Kent > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Network Modeling (NETMOD) > > > >>>>>>> ------------------------- > > > >>>>>>> > > > >>>>>>> Charter > > > >>>>>>> > > > >>>>>>> Current Status: Active > > > >>>>>>> > > > >>>>>>> Chairs: > > > >>>>>>> Lou Berger > > > >>>>>>> Kent Watsen > > > >>>>>>> > > > >>>>>>> Operations and Management Area Directors: > > > >>>>>>> Benoit Claise > > > >>>>>>> Joel Jaeggli > > > >>>>>>> > > > >>>>>>> Operations and Management Area Advisor: > > > >>>>>>> Benoit Claise > > > >>>>>>> > > > >>>>>>> Secretary: > > > >>>>>>> Zitao (Michael) Wang > > > >>>>>>> > > > >>>>>>> Mailing Lists: > > > >>>>>>> General Discussion: netmod@ietf.org > > > >>>>>>> To Subscribe: > > https://www.ietf.org/mailman/listinfo/netmod > > > >>>>>>> Archive: > > > >>> https://mailarchive.ietf.org/arch/browse/netmod/ > > > >>>>>>> Description of Working Group: > > > >>>>>>> > > > >>>>>>> The Network Modeling (NETMOD) working group is > > > >>>>>>> responsible for the YANG > > > >>>>>>> data modeling language, and guidelines for developing > > > >>>>>>> YANG > > > >> models. > > > >>>>> The > > > >>>>>>> NETMOD working group addresses general topics related to > > > >>>>>>> the use of > > > >>>>> the > > > >>>>>>> YANG language and YANG models, for example, the mapping > > > >>>>>>> of > > > >> YANG > > > >>>>>>> modeled > > > >>>>>>> data into various encodings. Finally, the NETMOD working > > group > > > >>>>>>> also defines core YANG models used as basic YANG building > > > >>>>>>> blocks, > > > >>>> and > > > >>>>>>> YANG models that do not otherwise fall under the charter > > > >>>>>>> of any > > > >>> other > > > >>>>>>> IETF working group. > > > >>>>>>> > > > >>>>>>> The NETMOD WG is responsible for: > > > >>>>>>> > > > >>>>>>> a) Maintaining the data modeling language YANG. This > > > >>>>>>> effort > > > >>> entails > > > >>>>>>> periodically updating the specification to address new > > > >>> requirements > > > >>>>>>> as they arise. > > > >>>>>>> > > > >>>>>>> b) Maintaining the guidelines for developing YANG models. > > > >>>>>>> This > > > >>> effort > > > >>>>>>> is primarily driven by updates made to the YANG > specification. > > > >>>>>>> > > > >>>>>>> c) Maintaining a conceptual framework in which YANG > > > >>>>>>> models are > > > >>>> used. > > > >>>>>>> This effort entails describing the generic context > > > >>>>>>> that in > > > > YANG > > > >>>>>>> exists and how certain YANG statements interact in > > > >>>>>>> that > > > >>> context. > > > >>>>>>> An example of this is YANG's relationship with datastores. > > > >>>>>>> > > > >>>>>>> d) Maintaining encodings for YANG modeled data. This > > > >>>>>>> effort > > > >>> entails > > > >>>>>>> updating encodings already defined by the NETMOD > > > >>>>>>> working (XML > > > >>>> and > > > >>>>>>> JSON) to accommodate changes to the YANG > > > >>>>>>> specification, and > > > >>>>> defining > > > >>>>>>> new encodings that are needed, and yet do not fall > > > >>>>>>> under the > > > >>> charter > > > >>>>>>> of any other active IETF working group. > > > >>>>>>> > > > >>>>>>> e) Maintaining YANG models used as basic YANG building > > blocks. > > > >>> This > > > >>>>>>> effort entails updating existing YANG models > > > >>>>>>> (ietf-yang-types > > > >>> and > > > >>>>>>> ietf-inet-types) as needed, as well as defining > > > >>>>>>> additional core > > > >>> YANG > > > >>>>>>> data models when necessary. > > > >>>>>>> > > > >>>>>>> f) Defining and maintaining YANG models that do not fall > > > >>>>>>> under > > > > the > > > >>>>>>> charter of any other active IETF working group. > > > >>>>>>> > > > >>>>>>> The NETMOD working group consults with the NETCONF > > working > > > >>>> group > > > >>>>> to > > > >>>>>>> ensure that new requirements are understood and can be > > > >>>>>>> met by > > > >> the > > > >>>>>>> protocols (e.g., NETCONF and RESTCONF) developed within > > > >>>>>>> that > > > >>>> working > > > >>>>>>> group. The NETMOD working group coordinates with other > > > >>>>>>> working > > > >>>>> groups > > > >>>>>>> (e.g., I2RS, RTGWG) on possible extensions to YANG to > > > >>>>>>> address > > > new > > > >>>>>>> modeling requirements and, when needed, which group will > > > >>>>>>> run > > > the > > > >>>>>>> process on a specific model. > > > >>>>>>> > > > >>>>>>> The NETMOD working group does not serve as a review team > > > >>>>>>> for > > > >>>> YANG > > > >>>>>>> modules developed by other working groups. Instead, the > > > >>>>>>> YANG > > > >>>>> doctors, > > > >>>>>>> as organized by the OPS area director responsible for network > > > >>>>>>> management, will act as advisors for other working groups > > > >>>>>>> and > > > >>> provide > > > >>>>>>> YANG reviews for the OPS area directors. > > > >>>>>>> > > > >>>>>>> Milestones: > > > >>>>>>> > > > >>>>>>> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for > > > >>> publication > > > >>>>>>> Mar 2017 - Submit > > > >>>>>>> draft-ietf-netmod-yang-model-classification > > > >>>>>>> to > > > >>> IESG > > > >>>>>>> for publication > > > >>>>>>> Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for > > > >>> publication > > > >>>>>>> Apr 2017 - Submit draft-ietf-netmod-entity to IESG for > > > > publication > > > >>>>>>> Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG > > > >>>>>>> for > > > >>>>>> publication > > > >>>>>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG > > > >>>>>>> for > > > >>>>>> publication > > > >>>>>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to > > > >>>>>>> IESG > > > > for > > > >>>>>>> publication > > > >>>>>>> Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for > > > >>>>>>> publication > > > >>>>>>> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to > > > >>>>>>> IESG > > > > for > > > >>>>>>> publication > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> _______________________________________________ > > > >>>>>>> netmod mailing list > > > >>>>>>> netmod@ietf.org > > > >>>>>>> https://www.ietf.org/mailman/listinfo/netmod > > > >>>>>> _______________________________________________ > > > >>>>>> netmod mailing list > > > >>>>>> netmod@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/netmod > > > >>>>>> > > > >>> > > > >>> > > > > > > > > From nobody Wed Mar 22 13:24:16 2017 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 B1C8312894A for ; Wed, 22 Mar 2017 13:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 FIAyVXIP76HW for ; Wed, 22 Mar 2017 13:24:12 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 81848128BB6 for ; Wed, 22 Mar 2017 13:24:12 -0700 (PDT) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 92F231AE05F8; Wed, 22 Mar 2017 21:24:11 +0100 (CET) Date: Wed, 22 Mar 2017 21:24:11 +0100 (CET) Message-Id: <20170322.212411.1191940569571241434.mbj@tail-f.com> To: worley@ariadne.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <87shm5rwuq.fsf@hobgoblin.ariadne.com> References: <87shm5rwuq.fsf@hobgoblin.ariadne.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] uses and augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:24:16 -0000 worley@ariadne.com (Dale R. Worley) wrote: > I've got a couple of questions about the interaction of "uses" and > "augment". I hope that these have straightforward answers that the old > hands can tell me easily enough. > > 1. Augmenting a grouping > > I notice that "augment" is not allowed to target a "grouping", despite > that naively seems to be an operation that a module designer might like > to do. I expect that there is a reason why this is not allowed. There were lots of debate over this one when we first designed YANG. The main reason for not allowing this is that it can easily have unintended consequences. Module A uses a grouping G b/c it fits the purpose. Later someone augments G with some nodes; at this point it is not at all clear that the additional nodes are suitable for module A. [...] > 2. "augment" as a substatement of "uses" > > In section 7.17: > > The "augment" statement allows a module or submodule ... to add to > the nodes from a grouping in a "uses" statement. > > When I first read this, I took it to mean that an "augment" substatement > adds a peer node to the set of nodes 'from a grouping in a "uses" > statement'. But I suspect that it is intended to mean that an "augment" > only adds nodes *under* one of the nodes from the grouping. There's an > ambiguity that could be fixed by better wording. Ok. Well, if you want to add a sibling node to the nodes in the grouping it is trivial: grouping foo { leaf a { ... } } uses foo; leaf b { ... } gives you: leaf a { ... } leaf b { ... } > 7.17 also says: > > If the "augment" statement is a substatement to the > "uses" statement, the descendant form (defined by the rule > "descendant-schema-nodeid" in Section 14) MUST be used. > > My understanding is that "descendant-schema-nodeid" is an XPath > expression, and that the "context node" for its evaluation is the node > to which the "uses" statement adds nodes -- but that doesn't seem to be > stated anywhere. Well, the syntax of descendant-schema-nodeid looks like an XPath path expression in abbreviated form, but it is not defined in terms of XPath, hence there is no text about any XPath context. See also section 6.5 /martin > (Those last two I should have caught in my Gen-ART review!) > > Thanks for any information, > > Dale > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Mar 22 13:28:12 2017 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 DF58112894A for ; Wed, 22 Mar 2017 13:28:10 -0700 (PDT) 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 BXuLK0o_chlf for ; Wed, 22 Mar 2017 13:28:09 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B096128BB6 for ; Wed, 22 Mar 2017 13:28:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 0453F1E56A7; Wed, 22 Mar 2017 13:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PBXjJSa-gsZQ; Wed, 22 Mar 2017 13:27:52 -0700 (PDT) Received: from [172.18.0.61] (unknown [208.184.163.248]) by c8a.amsl.com (Postfix) with ESMTPSA id 761961E5693; Wed, 22 Mar 2017 13:27:52 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=windows-1252 From: William Lupton In-Reply-To: <1ecba9d5-d9de-f967-0061-2a89822406bd@cisco.com> Date: Wed, 22 Mar 2017 15:28:03 -0500 Cc: Martin Bjorklund , netmod@ietf.org, "timothy.carey@alcatel-lucent.com" , David Sinicrope Content-Transfer-Encoding: quoted-printable Message-Id: <675D646B-80F2-40C3-BC6A-AC162F194BA1@broadband-forum.org> References: <148939103369.17026.5784133761974804877@ietfa.amsl.com> <20170313.084651.1144668331995785992.mbj@tail-f.com> <1ecba9d5-d9de-f967-0061-2a89822406bd@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:28:11 -0000 Yes thanks. We are good with it. W. > On 22 Mar 2017, at 10:25, Benoit Claise wrote: >=20 > Tim, William, >=20 > Are we good from a Broadband Forum point of view? > I remember some discussions during the last IETF meeting regarding = this entity YANG module. >=20 > Regards, Benoit >> Hi, >>=20 >> This version addresses the comments from Bart and Juergen. >>=20 >> I think that this document is now ready for WGLC. >>=20 >>=20 >> /martin >>=20 >>=20 >> internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the NETCONF Data Modeling Language of = the IETF. >>>=20 >>> Title : A YANG Data Model for Hardware Management >>> Authors : Andy Bierman >>> Martin Bjorklund >>> Jie Dong >>> Dan Romascanu >>> Filename : draft-ietf-netmod-entity-03.txt >>> Pages : 40 >>> Date : 2017-03-13 >>>=20 >>> Abstract: >>> This document defines a YANG data model for the management of >>> hardware on a single server. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ >>>=20 >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-netmod-entity-03 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-entity-03 >>>=20 >>>=20 >>> 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. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . >>=20 >=20 From nobody Wed Mar 22 13:48:12 2017 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 8822712778D for ; Wed, 22 Mar 2017 13:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 rcnnp-FYwQ-t for ; Wed, 22 Mar 2017 13:48:07 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0126.outbound.protection.outlook.com [104.47.36.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7019A128DE5 for ; Wed, 22 Mar 2017 13:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Bv8HnvW/zB9RedEmM0pFj54kSVOikwEnci0BDIHFqFs=; b=A54AWDmmBarvPO1SrgQe4XYU5tBbMCzjtOODxsP7WYDiFsOEg4jiXmpL807RHB2wBV8UNjI9M5EWTtCdP/n0yw5ImXYaXpO1TdCdJg3p2tSCuT1l5P8oPYmRme4vNVbkHbHq9m1stXHXk7kRNjqYflVy2MG0ojzDbq2YvRZ3p88= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 22 Mar 2017 20:48:05 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0991.013; Wed, 22 Mar 2017 20:48:05 +0000 From: Kent Watsen To: Mehmet Ersue , 'Lou Berger' , "netmod@ietf.org" Thread-Topic: [netmod] draft netmod charter update proposal Thread-Index: AQHSjWtMgvd1I9y/IUSjVG5c54oSBgFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUooBvvnQPAGVQNXrAT+Tz94BQZmbIKCarq1AgAGbAcCABgfQEIBTnMIA Date: Wed, 22 Mar 2017 20:48:05 +0000 Message-ID: <142D20A9-8A20-4D2E-8B2F-BDE7514A28B1@juniper.net> References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <675654fd-1532-1755-621c-a3ecb06950e3@labn.net> <025a01d29e82$8549d070$8fdd7150$@gmail.com> <007201d2a349$fa8c3b40$efa4b1c0$@gmail.com> In-Reply-To: <007201d2a349$fa8c3b40$efa4b1c0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:t3F9a9JGB3Y2A76fzj5BYMBahCas2lJxw8Hn5T+QabhRRCKItxHhYcf/5V22h0ghO8MC9TVDWe8ThWWAa9tQCd7CadOJPjjPq5aKyJLK38VvYXYEoKXR4F3/p6mm1UEQYoPhfYCSsNnwdy2SIeoZsRNajDen/KuHkKy8h2h2xY3ZzVasce05K8zr0MSQkFX+DuhC/5TkzIwgxb52/Dey+TvAY5LS5Kz2KatipTVQG5CV5O35jRvD3+gaGpCbS8iKqQAg+tVJxf4b75jPKF/vxkjV4uK34UnPMrbO4/41cisrJ7nq27J8mClNS3GyxecD+xB63BM5vFDH9QmwcHbbSA== x-ms-office365-filtering-correlation-id: 18f0dcef-2aca-44b1-e57a-08d47164bd9b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35073007944872)(138986009662008)(100405760836317)(95692535739014)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39840400002)(39860400002)(39850400002)(51744003)(24454002)(51444003)(377454003)(13464003)(45074003)(15650500001)(2906002)(76176999)(54356999)(33656002)(561944003)(345774005)(5660300001)(50986999)(4001350100001)(2950100002)(93886004)(3846002)(6116002)(122556002)(102836003)(189998001)(3660700001)(86362001)(2501003)(66066001)(39060400002)(36756003)(38730400002)(4326008)(53936002)(3280700002)(6246003)(53546009)(229853002)(54906002)(99286003)(53946003)(8936002)(8676002)(81166006)(6306002)(6512007)(6506006)(82746002)(6486002)(6436002)(83506001)(83716003)(7736002)(77096006)(25786009)(305945005)(2900100001)(502464002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5149AEAE91A34946BE6A28BB4488E8E0@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 20:48:05.5149 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:48:12 -0000 SGkgTWVobWV0LA0KDQpGcm9tIGEgY2hhcnRlciBwZXJzcGVjdGl2ZSwgd2UgaGF2ZToNCg0KIGEp IE1haW50YWluaW5nIHRoZSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIFlBTkcuICBUaGlzIGVmZm9y dCANCiAgICBlbnRhaWxzIHBlcmlvZGljYWxseSB1cGRhdGluZyB0aGUgc3BlY2lmaWNhdGlvbiB0 byBhZGRyZXNzDQogICAgbmV3IHJlcXVpcmVtZW50cyBhcyB0aGV5IGFyaXNlLg0KDQpGcm9tIGEg bWlsZXN0b25lIHBlcnNwZWN0aXZlLCB5b3UgYXJlIGNvcnJlY3QgdGhhdCB3ZSBkb24ndCBoYXZl IGENCm1pbGVzdG9uZSBmb3IgNzk1MGJpcyBhcyBvZiB5ZXQuICBXZSBkbywgaG93ZXZlciwgaGF2 ZSBhICJZQU5HIE5leHQiDQpkaXNjdXNzaW9uIG9uIHRoZSBhZ2VuZGEsIHdoaWNoIG1heSBvciBt YXkgbm90IGxlYWQgdG8gdGhlIGNyZWF0aW9uDQpvZiBhIG1pbGVzdG9uZSBmb3IgaXQuDQoNCkFz IGZvciBORVRDT05GL1JFU1RDT05GIHJldmlzaW9ucyBkZXBlbmRpbmcgb24gYSA3OTUwYmlzLCBp ZiB0aGF0IA0KaXMgdHJ1ZSwgdGhlbiBpdCB3aWxsIGxpa2VseSBmb3JjZSB1cyB0byBjcmVhdGUg dGhlIG1pbGVzdG9uZSBpbiANCnRoZSBuZWFyLXRlcm0gZm9yIGl0LiAgVGhhdCB3aXRoc3RhbmRp bmcsIEkgdGhpbmsgdGhhdCBORVRDT05GIFdHDQpjb3VsZCB0YWtlIHRoZSBsZWFkIGJ5IG1vdmlu Zy9jb3B5aW5nIHRoZSBORVRDT05GLXNwZWNpZmljIHBhcnRzDQpmcm9tIFJGQzc5NTAgaW50byBh biByZmM2MjQxYmlzLiAgSXQgd291bGQgYmUgbmljZSBpZiB3ZSBjb3VsZA0KZGVjb3VwbGUgdGhl IHJlZmFjdG9yaW5nIG9mIHRoZXNlIGRvY3VtZW50cyBhY3Jvc3Mgb3VyIFdHcy4NCg0KS2VudCAv LyBjby1jaGFpciBoYXQNCg0KDQoNCi0tLS0tT1JJR0lOQUwgTUVTU0FHRS0tLS0tDQpIaSBLZW50 LCBMb3UsDQoNCmFzIEkgc2VlIDc5NTBiaXMgaGFzIG5vdCBiZWVuIG1lbnRpb25lZCBpbiB0aGUg Y2hhcnRlciB0ZXh0IGFuZCB0aGUNCm1pbGVzdG9uZXMuDQpBcyB5b3Uga25vdyBORVRDT05GIGFu ZCBSRVNUQ09ORiByZXZpc2lvbnMgYXJlIGRlcGVuZGVudCBvbiB0aGUgdGltaW5nIG9mDQo3OTUw YmlzLg0KSG93IGlzIHRoaXMgZXNzZW50aWFsIGRlbGl2ZXJhYmxlIGFuZCBpdHMgdGltaW5nIGdv aW5nIHRvIGJlIGFkZHJlc3NlZCBpbg0KdGhlIGNoYXJ0ZXI/DQoNCk1laG1ldA0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1laG1ldCBFcnN1ZQ0KPiBTZW50OiBGcmlk YXksIE1hcmNoIDE3LCAyMDE3IDExOjUxIFBNDQo+IFRvOiBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxh Ym4ubmV0PjsgJ0tlbnQgV2F0c2VuJyA8a3dhdHNlbkBqdW5pcGVyLm5ldD47DQo+IG5ldG1vZEBp ZXRmLm9yZw0KPiBDYzogJ0Jlbm9pdCBDbGFpc2UnIDxiY2xhaXNlQGNpc2NvLmNvbT47ICdNYWhl c2ggSmV0aGFuYW5kYW5pJw0KPiA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQo+IFN1YmplY3Q6 IFJFOiBbbmV0bW9kXSBkcmFmdCBuZXRtb2QgY2hhcnRlciB1cGRhdGUgcHJvcG9zYWwNCj4gDQo+ IEhpIExvdSwgS2VudCwNCj4gDQo+IEkgcHJvbWlzZWQgdG8gcHJvdmlkZSBzb21lIG1pbmltYWwg dGV4dCB3aGljaCBjYW4gYmUgdXNlZCBhcyBXRyBpdGVtDQo+IGRlc2NyaXB0aW9uLg0KPiBJJ20g ZmluZSB3aXRoIGFueSBmaW5lIHR1bmluZy4NCj4gDQo+IFNlZSBiZWxvdzoNCj4gDQo+ICAgIGEp IE1haW50YWluaW5nIHRoZSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIFlBTkcuICBUaGlzIGVmZm9y dCBlbnRhaWxzDQo+ICAgICAgIHBlcmlvZGljYWxseSB1cGRhdGluZyB0aGUgc3BlY2lmaWNhdGlv biB0byBhZGRyZXNzIG5ldyByZXF1aXJlbWVudHMNCj4gICAgICAgYXMgdGhleSBhcmlzZS4gQURE PFRoaXMgd29yayBpcyBwbGFubmVkIHRvIGFkZHJlc3Mgd2l0aCBhIHJldmlzaW9uDQpvZiBSRkMN Cj4gNzk1MC4vPg0KPiANCj4gICAgYikgTWFpbnRhaW5pbmcgdGhlIGd1aWRlbGluZXMgZm9yIGRl dmVsb3BpbmcgWUFORyBtb2RlbHMuICBUaGlzIGVmZm9ydA0KPiAgICAgICBpcyBwcmltYXJpbHkg ZHJpdmVuIGJ5IHVwZGF0ZXMgbWFkZSB0byB0aGUgWUFORyBzcGVjaWZpY2F0aW9uLg0KQUREPFRo aXMNCj4gY29udGludW91cyBlZmZvcnQgaGFzIGJlZW4gcmVjZW50bHkgYWRkcmVzc2VkIHdpdGgg YSByZXZpc2lvbiBvZiBSRkMNCjYwODcuLz4NCj4gDQo+ICAgIGMpIE1haW50YWluaW5nIGEgY29u Y2VwdHVhbCBmcmFtZXdvcmsgaW4gd2hpY2ggWUFORyBtb2RlbHMgYXJlIHVzZWQuDQo+ICAgICAg IFRoaXMgZWZmb3J0IGVudGFpbHMgZGVzY3JpYmluZyB0aGUgZ2VuZXJpYyBjb250ZXh0IHRoYXQg aW4gWUFORw0KPiAgICAgICBleGlzdHMgYW5kIGhvdyBjZXJ0YWluIFlBTkcgc3RhdGVtZW50cyBp bnRlcmFjdCBpbiB0aGF0IGNvbnRleHQuDQo+ICAgICAgIEFuIGV4YW1wbGUgb2YgdGhpcyBpcyBZ QU5HJ3MgcmVsYXRpb25zaGlwIHdpdGggZGF0YXN0b3Jlcy4gQUREPFRoZQ0KPiByZXZpc2VkIGRh dGFzdG9yZSBkcmFmdCB3aWxsIHByb3ZpZGUgYSBjb25jZXB0dWFsIGZyYW1ld29yayBmb3IgdGhl DQpoYW5kbGluZw0KPiBvZiBkYXRhc3RvcmVzLCB3aGljaCBjYW4gYmUgYWRvcHRlZCBieSBvdGhl ciBXR3MgZm9yIHRoZWlyIHVzYWdlDQo+IHNjZW5hcmlvLi8+DQo+IA0KPiAuIC4gLg0KPiANCj4g ICAgZSkgTWFpbnRhaW5pbmcgWUFORyBtb2RlbHMgdXNlZCBhcyBiYXNpYyBZQU5HIGJ1aWxkaW5n IGJsb2Nrcy4gIFRoaXMNCj4gICAgICAgZWZmb3J0IGVudGFpbHMgdXBkYXRpbmcgZXhpc3Rpbmcg WUFORyBtb2RlbHMgKGlldGYteWFuZy10eXBlcyBhbmQNCj4gICAgICAgaWV0Zi1pbmV0LXR5cGVz KSBhcyBuZWVkZWQsIGFzIHdlbGwgYXMgZGVmaW5pbmcgYWRkaXRpb25hbCBjb3JlIFlBTkcNCj4g ICAgICAgZGF0YSBtb2RlbHMgd2hlbiBuZWNlc3NhcnkuIEFERDxUaGUgV0cgd2lsbCBmaW5hbGl6 ZSBvbmdvaW5nIHdvcmsgb24NCj4gdGhlIG1vZGVscyBmb3IgU3lzbG9nLCBBQ0wgYW5kIENvbW1v biBJbnRlcmZhY2UgRXh0ZW5zaW9ucyBhcyB3ZWxsIGFzIHRoZQ0KPiBtb2RlbCBmb3IgaGFyZHdh cmUgbWFuYWdlbWVudC4gVGhlIFNjaGVtYSBtb3VudCBkcmFmdCB3aWxsIHByb3ZpZGUgYQ0KPiBt ZWNoYW5pc20gdG8gY29tYmluZSBZQU5HIG1vZHVsZXMgaW50byB0aGUgc2NoZW1hIGRlZmluZWQg aW4gb3RoZXINCj4gWUFORyBtb2R1bGVzLi8+DQo+IA0KPiBCVFc6IFRoZXJlIGlzIG5vIHRvcGlj IGRlc2NyaXB0aW9uIChpbiBhKS1mKSBjb3ZlcmluZyBZQU5HIG1vZHVsZQ0KPiBjbGFzc2lmaWNh dGlvbi4NCj4gSSBhc3N1bWUgaXQgY2FuIGJlIGFkZGVkIHdpdGggYSBzZW50ZW5jZSB0byBhKSBv ciBiKS4NCj4gDQo+IFRoYW5rcywNCj4gTWVobWV0DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogTWVobWV0IEVyc3VlDQo+ID4gU2VudDogVGh1cnNkYXksIE1h cmNoIDE2LCAyMDE3IDExOjU5IFBNDQo+ID4gVG86IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5u ZXQ+OyAnS2VudCBXYXRzZW4nDQo+ID4gPGt3YXRzZW5AanVuaXBlci5uZXQ+OyBuZXRtb2RAaWV0 Zi5vcmcNCj4gPiBDYzogJ0Jlbm9pdCBDbGFpc2UnIDxiY2xhaXNlQGNpc2NvLmNvbT47ICdNYWhl c2ggSmV0aGFuYW5kYW5pJw0KPiA+IDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCj4gPiBTdWJq ZWN0OiBSRTogW25ldG1vZF0gZHJhZnQgbmV0bW9kIGNoYXJ0ZXIgdXBkYXRlIHByb3Bvc2FsDQo+ ID4NCj4gPiA+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSBNZWht ZXQsDQo+ID4gPiAgICBzZWUgYmVsb3cuDQo+ID4gPiBPbiAzLzE2LzIwMTcgMjoyNCBQTSwgTWVo bWV0IEVyc3VlIHdyb3RlOg0KPiA+ID4gPiBMb3UsDQo+ID4gLiAuIC4NCj4gPiA+ID4gSSBhY3R1 YWxseSBwcm92aWRlZCBhIHZlcnkgc2ltcGxlIHByb3Bvc2FsLiBZb3UgZ3V5cyBjYW4gZmlsbCB0 aGUNCj4gPiA+ID4gaWRlYSB3aXRoIG1pbmltYWwgdGV4dCBiZXR0ZXIgdGhhbiBtZS4gSSdtIGZp bmUgd2hhdGV2ZXIgdGhlIHRleHQNCmlzLg0KPiA+ID4gPiBJZiB5b3UgdGhpbmsgdGhlIGhpZ2gt bGV2ZWwgdG9waWMgZGVzY3JpcHRpb24gYSktZikgZG9lcyBhbHJlYWR5DQo+ID4gPiA+IGRlZmlu ZSB0aGUgV0cgaXRlbSBjbGVhcmx5IHlvdSBjYW4gc2ltcGx5IHNheSAidGhpcyBpcyBhY2hpZXZl ZA0KPiA+ID4gPiB3aXRoIFdHDQo+ID4gPiBpdGVtIFhZIi4NCj4gPiA+ID4gSWYgbm90LCB5b3Ug Y2FuIGtlZXAgdGhlIGhpZ2gtbGV2ZWwgZm9jdXMgdGV4dCBidXQgc2V0DQo+ID4gPiA+IGFkZGl0 aW9uYWxseSB0aGUgYm9yZGVycyBvZiB0aGUgV0cgaXRlbSB3aXRoIGEgZmV3IGNvbmNyZXRlIHdv cmRzLg0KPiA+ID4NCj4gPiA+IEkgcmVhbGx5IGNhbid0IHRlbGwgZm9yIHN1cmUsIGJ1dCBpdCBm ZWVscyB0byBtZSB0aGF0IHRoaXMgY29tbWVudA0KPiA+ID4gYm9pbHMgZG93biB0byBhIHN0eWxl IGNvbW1lbnQgYW5kIHlvdSBoYXZlIGEgcHJlZmVyZW5jZSBmb3INCj4gPiA+IGRpZmZlcmVudCBj b250ZW50cyBpbiB0aGUgY2hhcnRlci4gIEknZCBsaWtlIHRvIGJlIHNlbnNpdGl2ZSB0bw0KPiA+ ID4gdGhpcy4gIEFzIG91ciBzdHlsZSBkaWZmZXJzLCBoYXZpbmcgYSBjb25jcmV0ZSBwcm9wb3Nh bCBvbiBzcGVjaWZpYw0KPiA+ID4gdGV4dCBjaGFuZ2VzIHdvdWxkIGJlIHJlYWxseSBoZWxwZnVs IGluIHVzIChhbmQgdGhlIFdHKSBldmFsdWF0aW5nDQo+ID4gPiB0aGUgY2hhbmdlcyB5b3UnZCBs aWtlIHRvIHNlZS4gIFdpdGhvdXQgc3VjaCBzcGVjaWZpYyBleGFtcGxlcyBhbmQNCj4gPiA+IHRo aW5rIHdlJ3JlIGxlZnQgd2l0aCB0aGUgY2hhcnRlciBhcyBjdXJyZW50bHkgcHJvcG9zZWQuICBQ ZXJoYXBzDQo+ID4gPiBzb21lb25lIGVsc2Ugd2hvDQo+ID4gaGFzIHNpbWlsYXIgZmVlbGluZ3Mg Y2FuIGNoaW1lIGluIGFuZCBwcm92aWRlIHByb3Bvc2VkIHRleHQuDQo+ID4gPg0KPiA+ID4gQW55 b25lIGVsc2UgaGF2ZSBhbnkgY29tbWVudHMgb3IgcHJvcG9zZWQgY2hhbmdlcz8NCj4gPiBJIHRo aW5rIHRoZSB3b3JkaW5nIGRlcGVuZHMgb24gdGhlIHRpbWUgcGVyaW9kIGlzIGZvciB3aGljaCB0 aGUNCj4gPiBjaGFydGVyIGlzIHByZXBhcmVkLg0KPiA+IEkgY2FuIHRyeSBzb21lIHRleHQgb25j ZSBJIGhhdmUgdGltZSB0b21vcnJvdy4NCj4gPg0KPiA+IC4gLiAuDQo+ID4gPiA+IEkgdGhpbmsg dGhlIERTIGRyYWZ0IHByb3ZpZGVzIGEgY29uY2VwdHVhbCBmcmFtZXdvcmsgZm9yIGRpdmVyc2UN Cj4gPiA+ID4gRFMgdXNhZ2Ugc2NlbmFyaW9zIHRvIGJlIHVzZWQgYnkgbWFueSBwcm90b2NvbHMs IHdoZXJlIElFVEYgV0dzDQo+ID4gPiA+IG1heSBhY3R1YWxseSBkZWNpZGUgdXNpbmcgYSBzdWJz ZXQgb2YgdGhlIERTIGZyYW1ld29yayBmb3IgdGhlaXINCj4gPiA+ID4gcHVycG9zZSBhbmQgZm9y IHRoZWlyIHByb3RvY29sIHN0YW5kYXJkaXphdGlvbi4NCj4gPiA+ID4gQmFzZWQgb24gdGhpcyB0 aGUgY29uY2VwdHVhbCBmcmFtZXdvcmsgY2Fubm90IGJlIHN0YW5kYXJkaXplZCBhcw0KPiA+ID4g PiBpdCBpcyBidXQgdGhlIHByb3RvY29scyB1c2luZyBhIGNvbnNpc3RlbnQgc3Vic2V0IGhhdmUg dG8gYmUNCnN0YW5kYXJkaXplZC4NCj4gPiA+ID4gRm9sbG93aW5nIHRoaXMgY29uc2lkZXJhdGlv biBJIHRoaW5rIHRoZSBpbnRlbmRlZCBzdGF0dXMgb2YgdGhlIERTDQo+ID4gPiA+IGRyYWZ0IHNo b3VsZCBiZSBjaGFuZ2VkIHRvOiBJbmZvcm1hdGlvbmFsIFJGQyBJZiB5b3UgYWdyZWUgcGxlYXNl DQo+ID4gPiA+IGluZGljYXRlIHRoaXMgY2hhbmdlIGFjY29yZGluZ2x5Lg0KPiA+ID4NCj4gPiA+ IEkgdGhpbmsgSnVlcmdlbidzIHJlcGx5IHRvIHlvdXIgcHJldmlvdXMgbWVzc2FnZSBoaWdobGln aHRzIHRoYXQNCj4gPiA+IHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBvZiBvcGluaW9uIGhlcmUgYmFz ZWQgb24gdGhlIHRlY2huaWNhbA0KPiA+ID4gc3BlY2lmaWNzIG9mIHRoZSBkcmFmdC4gIE15IHBv c2l0aW9uIGFzIGNoYWlyIGlzIHRoYXQgSSdsbCBzdXBwb3J0DQo+ID4gPiB3aGF0ZXZlciBtYWtl cyBzZW5zZSBiYXNlZCBvbiB0aGUgZG9jdW1lbnQgcHJvZHVjZWQgYnkgdGhlIFdHLg0KPiA+ID4g VG9kYXkgdGhlIGRvY3VtZW50IGF1dGhvcnMgYmVsaWV2ZSBQUyBpcyBhcHByb3ByaWF0ZSwgb25j ZSB3ZSBoYXZlIGENCj4gPiA+IHZlcnNpb24gdGhhdCBpcyBzdGFiaWxpemluZyBmb3IgTEMgLS0g d2hpY2ggaG9wZWZ1bGx5IHdpbGwgYmUgdGhlDQo+ID4gPiBuZXh0IHZlcnNpb24gb3IgdHdvDQo+ ID4gPiAtLSB0aGVuIHdpbGwgYmUgYSBnb29kIHRpbWUgdG8gcmV2aXNpdCB0aGlzLg0KPiA+IFRo ZXJlIGFyZSBpbmRlZWQgZGlmZmVyZW50IG9waW5pb25zIGNvbmNlcm5pbmcgdGhlIGdvYWwgb2Yg dGhlIERTIGRyYWZ0Lg0KPiA+IEkgYWdyZWUgd2l0aCB0aGUgZG9jdW1lbnQgaW50cm9kdWN0aW9u IGFuZCBzZWUgaXQgYXMgYSBjb25jZXB0dWFsDQo+ID4gZnJhbWV3b3JrIGNvdmVyaW5nIG1hbnkg dXNhZ2Ugc2NlbmFyaW9zLg0KPiA+IFN1Y2ggYSBjb25jZXB0dWFsIGZyYW1ld29yayBkZXNjcmli aW5nIHBvc3NpYmxlIHNvbHV0aW9ucyBpcw0KPiA+IGluZm9ybWF0aW9uYWwgaW4gbmF0dXJlIGFu ZCBpcyBub3QgcmVsZXZhbnQgZm9yIHN0YW5kYXJkaXphdGlvbi4NCj4gPg0KPiA+ID4gPj4+IFRo aXMgaXMgYXMgSSB0aGluayBhbHNvIGltcG9ydGFudCB0byBhdm9pZCBhbiBvdmVybGFwcGluZw0K PiA+ID4gPj4+IGJldHdlZW4gTkVUQ09ORiBhbmQgTkVUTU9EIGNoYXJ0ZXJzLg0KPiA+ID4gPj4g SSBkb24ndCBmb2xsb3cgdGhpcyBwb2ludC4gIENlcnRhaW5seSBJJ2QgaG9wZSB0aGF0IHRoZSBw cm90b2NvbA0KPiA+ID4gPj4gaW1wYWN0IG9mIHJldmlzZWQgRFMgYXJlIGNvdmVyZWQgaW4gYSBQ UyBkb2N1bWVudCwgdW5sZXNzIGZvcg0KPiA+ID4gPj4gc29tZSByZWFzb24gdGhlcmUgYXJlIG5v ICJvbi10aGUtd2lyZSIgY2hhbmdlcyBuZWVkZWQuICBUSQ0KPiA+ID4gPj4gd291bGRuJ3QgZXhw ZWN0IHRoYXQgdGhlIGRvY3VtZW50IHN0YXR1cyBvZiB0aGUgYmFzZSByZXZpc2VkIGRhdGENCj4g PiA+ID4+IHN0b3JlIGRvY3VtZW50IHdvdWxkDQo+ID4gPiBpbXBhY3QgdGhhdC4gIERvIHlvdT8N Cj4gPiA+ID4+IElmIHNvLCBob3c/DQo+ID4gPiA+IE15IGNvbW1lbnQgaXMgYWN0dWFsbHkgc3Vw ZXJmbHVvdXMgaWYgeW91IGFncmVlIHdpdGggbXkNCj4gPiA+ID4gY29uc2lkZXJhdGlvbnMgYWJv dmUuDQo+ID4gPiA+IFRoZSB3b3JzdCBjYXNlIHdvdWxkIGluIG15IG9waW5pb24gaGFwcGVuIGlm IHRoZSBEUyBjb25jZXB0dWFsDQo+ID4gPiA+IGZyYW1ld29yayBjb3ZlcmluZyBtYW55IGhpZ2gt bGV2ZWwgRFMgdXNhZ2Ugc2NlbmFyaW9zIHdvdWxkIGJlDQo+ID4gPiA+IGF0dGVtcHRlZCB0byBz dGFuZGFyZGl6ZSwgd2hpY2ggYXQgdGhlIGVuZCB3b3VsZCBwcmVzY3JpYmUNCj4gPiA+ID4gcHJv dG9jb2wgV0dzIHdoYXQgdGhleSBzaG91bGQgYmUgc3RhbmRhcmRpemluZy4NCj4gPiA+DQo+ID4g PiBZYW5nIHByZXN1bWVzIGEgY2VydGFpbiBzZXQgb2YgZnVuY3Rpb25zIGZvciB0aGUgcHJvdG9j b2xzIGl0IG9wZXJhdGVzDQo+IG92ZXIuDQo+ID4gPiBJJ20gbm90IHN1cmUgd2h5IGhhdmluZyBh IGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoaXMgd291bGQgYmUgYW4NCmlzc3VlLg0KPiA+IFRo aXMgaXMgYWdhaW4gYW4gaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiB3aGljaCBTSE9VTEQgYmUgZGlz Y3Vzc2VkIGluIGENCj4gPiBqb2ludCBzZXNzaW9uLg0KPiA+IEkgZG9uJ3QgaGF2ZSBhIHN0cm9u ZyBvcGluaW9uIGJ1dCBpdCBjYW4gYmUgc2VlbiBkaWZmZXJlbnRseS4NCj4gPg0KPiA+ID4gPiBJ biBzdWNoIGEgY2FzZSB0aGUgY29uY2VwdHVhbCBmcmFtZXdvcmsgd291bGQgbW9zdCBsaWtlbHkg Y2F1c2UgYQ0KPiA+ID4gPiBjb21wZXRpbmcgc2l0dWF0aW9uIHdpdGggcHJvdG9jb2wgV0cncyBn b2FscyBhbmQgZG9jdW1lbnRzIGFuZA0KPiA+ID4gPiBjYW5ub3QgYmUgYWRvcHRlZCBzdWNjZXNz ZnVsbHkuDQo+ID4gPg0KPiA+ID4gSWYgYSBwcm90b2NvbCBkb2Vzbid0IHByb3ZpZGUgZnVsbCBz dXBwb3J0IGZvciB5YW5nIChyZXF1aXJlbWVudHMpDQo+ID4gPiBpdCBjYW4ndCBmdWxseSBzdXBw b3J0IGFsbCB5YW5nIGZlYXR1cmVzLiAgSWYgeW91ciBwb2ludCBpcyB0aGF0DQo+ID4gPiB3aGVu IE5ldE1vZCBjaGFuZ2VzIGJhc2ljIHlhbmcgZnVuY3Rpb25zL29wZXJhdGlvbnMgdGhhdCB0aGlz IG1pZ2h0DQo+ID4gPiBjb25zdHJhaW4gdGhlIHByb3RvY29scyAoYW5kIHJlbGF0ZWQgV0dzKSBv dmVyIHdoaWNoIGl0IG9wZXJhdGVzLA0KPiA+ID4gdGhlbiBJIGFncmVlIHRoYXQgdGhpcyBpcyB0 aGUgY2FzZS4gSG93IGNvdWxkIGl0IGJlIG90aGVyd2lzZT8NCj4gPiBVc3VhbGx5IG1vZGVsaW5n IGxhbmd1YWdlcyBwcm92aWRlIG1hbnkgbGFuZ3VhZ2UgY29uc3RydWN0cyBhbmQgcGVvcGxlDQo+ ID4gbW9kZWxpbmcgbW9kZWxzIGNob29zZSB3aGljaCBvbmUgaXMgYmVzdCBmb3IgdGhlaXIgcHVy cG9zZS4NCj4gPiBUaGUgc2FtZSBhcHBsaWVzIHRvIHRoZSBEUyBjb25jZXB0IGZyYW1ld29yay4g VGhlIHByb3RvY29sIFdHcyB3b3VsZA0KPiA+IGxpa2UgdG8gaGF2ZSB0aGUgZnJlZWRvbSB0byBj aG9vc2UgdGhlIHN1YnNldCB0byBhZG9wdCBmcm9tIHRoZSBwcm90b2NvbA0KPiBwb3YuDQo+ID4N Cj4gPiA+IFRoYW5rcywNCj4gPiA+DQo+ID4gPiBMb3UNCj4gPiA+DQo+ID4gPiA+IFRoYW5rcywN Cj4gPiA+ID4gTWVobWV0DQo+ID4gPiA+DQo+ID4gPiA+Pj4gUFM6IEkgZXhwZWN0IHRoYXQgbW9z dCBvZiB0aGUgTmV0Y29uZiBXRyBtZW1iZXIgcmVhZCBhbHNvIHRoZQ0KPiA+ID4gTmV0bW9kDQo+ ID4gPiA+Pj4gbWFpbGxpc3QgYW5kIHRoZXJlZm9yIHNraXAgc2VuZGluZyB0byBib3RoIE1MLg0K PiA+ID4gPj4+DQo+ID4gPiA+PiBHcmVhdC4NCj4gPiA+ID4+DQo+ID4gPiA+PiBUaGFua3MuDQo+ ID4gPiA+PiBMb3UNCj4gPiA+ID4+PiBUaGFua3MsDQo+ID4gPiA+Pj4gTWVobWV0DQo+ID4gPiA+ Pj4NCj4gPiA+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+Pj4gRnJv bTogTWVobWV0IEVyc3VlDQo+ID4gPiA+Pj4+IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCA5LCAyMDE3 IDc6MzYgUE0NCj4gPiA+ID4+Pj4gVG86IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+OyAn S2VudCBXYXRzZW4nDQo+ID4gPiA+Pj4+IDxrd2F0c2VuQGp1bmlwZXIubmV0PjsgbmV0bW9kQGll dGYub3JnDQo+ID4gPiA+Pj4+IENjOiAnQmVub2l0IENsYWlzZScgPGJjbGFpc2VAY2lzY28uY29t PjsgJ01haGVzaCBKZXRoYW5hbmRhbmknDQo+ID4gPiA+Pj4+IDxtamV0aGFuYW5kYW5pQGdtYWls LmNvbT4NCj4gPiA+ID4+Pj4gU3ViamVjdDogUkU6IFtuZXRtb2RdIGRyYWZ0IG5ldG1vZCBjaGFy dGVyIHVwZGF0ZSBwcm9wb3NhbA0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+PiBIaSBMb3UsDQo+ID4g PiA+Pj4+DQo+ID4gPiA+Pj4+PiBUaGUgY2hhcnRlcnMgZnJvbSB0aGUgbGFzdCBjb3VwbGUgb2Yg eWVhcnMgZG9uJ3QgaGF2ZSB0aGUNCj4gPiA+ID4+Pj4+IGludGVuZGVkDQo+ID4gPiA+Pj4gc3Rh dHVzIC0tDQo+ID4gPiA+Pj4+IGF0IGxlYXN0IHRoZSBvbmVzIHdlIGNoZWNrZWQuDQo+ID4gPiA+ Pj4+PiBJIGFjdHVhbGx5IGZlZWwgcHJldHR5IHN0cm9uZ2x5IGFib3V0IHRoaXMgKHdoaWNoIG9m IGNvdXJzZQ0KPiA+ID4gPj4+Pj4gY2FuIGJlIGVhc2lseSBvdmVycnVsZWQgYnkgb3VyIEFEKS4g IEl0J3MgbXkgZXhwZXJpZW5jZSB0aGF0DQo+ID4gPiA+Pj4+PiBwcmVtYXR1cmUgZGlzY3Vzc2lv bnMgb24gaW50ZW5kZWQgc3RhdHVzLCBpLmUuLCBiZWZvcmUgYQ0KPiA+ID4gPj4+Pj4gZG9jdW1l bnQgaXMgc3VmZmljaWVudGx5DQo+ID4gPiA+Pj4+IG1hdHVyZSwgbGVhZHMgdG8gcHJvY2Vzcy1m b2N1c2VkIGFyZ3VtZW50cyB0aGF0IGRldHJhY3RzIGZyb20NCj4gPiA+ID4+Pj4gbWFraW5nIHRl Y2huaWNhbCBwcm9ncmVzcy4gIFdoaWxlIG9uY2UgYSBkb2N1bWVudCBpcyBtYXR1cmUgYW5kDQo+ ID4gPiA+Pj4+IGNvcmUgZGlyZWN0aW9uL2NvbnRlbnQgaXMgZml4ZWQsIGl0IGlzIGdlbmVyYWxs eSBvYnZpb3VzIHdoYXQNCj4gPiA+ID4+Pj4gc3RhdHVzIGlzDQo+ID4gPiA+Pj4gYXBwcm9wcmlh dGUuDQo+ID4gPiA+Pj4+IFRoZSBjaGFydGVycyBmcm9tIHRoZSBsYXN0IGNvdXBsZSBvZiB5ZWFy cyBoYXZlIGEgc2hvcnQgV0cgaXRlbQ0KPiA+ID4gPj4+IGRlZmluaXRpb24sDQo+ID4gPiA+Pj4+ IHdoaWNoIHdvdWxkIGJlIElNTyBzdWZmaWNpZW50Lg0KPiA+ID4gPj4+PiBZb3UgYXJlIHJpZ2h0 IHRoZSBpbnRlbmRlZCBzdGF0dXMgaXMgbm90IGF2YWlsYWJsZSBzaW5jZSBhIGZldw0KPiA+ID4g Pj4+PiB5ZWFycywgYnV0DQo+ID4gPiA+Pj4gSU1PIGl0DQo+ID4gPiA+Pj4+IGlzIHBhcnQgb2Yg dGhlIHRhcmdldCBkZWZpbml0aW9uIGFuZCB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bCBmb3INCj4gPiA+ ID4+Pj4gdGhlIGRyYWZ0DQo+ID4gPiA+Pj4gYXV0aG9ycw0KPiA+ID4gPj4+PiBhbmQgV0cgbWVt YmVycyB0byByZWdhcmQuDQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+Pj4gSXQgd291bGQgYmUgZ29v ZCB0byBicmluZyB0aGUgaGlnaC1sZXZlbCB0b3BpY3MgaW4gcmVsYXRpb24NCj4gPiA+ID4+Pj4+ PiB0byB0aGUgV0cNCj4gPiA+ID4+Pj4gaXRlbXMuDQo+ID4gPiA+Pj4+PiBJJ20gc29ycnksIEkg ZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIGxhc3Qgc2VudGVuY2UgY2FuIHlvdQ0KcmVwaHJhc2UNCj4g aXQ/DQo+ID4gPiA+Pj4+IFdoYXQgSSBtZWFudCBpcyB0aGF0IHRoZSBoaWdoLWxldmVsIHRvcGlj cyBhKS1mKSBtaWdodCBiZSBnb29kDQo+ID4gPiA+Pj4+IGFzIFdHIGZvY3VzIGRlc2NyaXB0aW9u IGJ1dCBhcmUgbm90IHN1ZmZpY2llbnQgYXMgZHJhZnQgdGFyZ2V0DQo+IGRlZmluaXRpb24uDQo+ ID4gPiA+Pj4+IElmIHlvdSB0aGluayB0aGUgaGlnaC1sZXZlbCB0b3BpYyBkZXNjcmlwdGlvbiBp cyBtb3JlIG9yIGxlc3MNCj4gPiA+ID4+Pj4gdGhlIFdHIGl0ZW0gZGVmaW5pdGlvbiwgdGhlbiB3 ZSBjb3VsZCBzaW1wbHkgd3JpdGUgInRoaXMgaXMNCj4gPiA+ID4+Pj4gYWNoaWV2ZWQgd2l0aCBX Rw0KPiA+ID4gPiBpdGVtDQo+ID4gPiA+PiBYWSIuDQo+ID4gPiA+Pj4+IElmIG5vdCwgd2UgY291 bGQga2VlcCB0aGUgaGlnaC1sZXZlbCBmb2N1cyB0ZXh0IGJ1dCBzZXQNCj4gPiA+ID4+Pj4gYWRk aXRpb25hbGx5IHRoZSBib3JkZXJzIG9mIHRoZSBXRyBpdGVtIHdpdGggc29tZSBjb25jcmV0ZSB3 b3Jkcy4NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4+PiBCVFc6IFdlIGFncmVlZCBpbiBkaXZlcnNl IGRpc2N1c3Npb25zIHRoYXQgdGhlIERTIGNvbmNlcHQgaXMNCj4gPiA+ID4+Pj4gSW5mb3JtYXRp b25hbCBpbiBuYXR1cmUuDQo+ID4gPiA+Pj4+Pj4gSSB0aGluayB0aGlzIHNob3VsZCBiZSBjb3Jy ZWN0ZWQgaW4gdGhlIGRyYWZ0Lg0KPiA+ID4gPj4+Pj4gU28gdGhpcyBzb3VuZHMgbGlrZSBhbiBv YmplY3Rpb24gdG8gYSBzcGVjaWZpYyBkb2N1bWVudC4gIFRoaXMNCj4gPiA+ID4+Pj4+IGlzIGEg ZmFpciBwb2ludCB0byByYWlzZSwgYnV0IGluIG91ciBvcGluaW9uIGl0IGlzIG5vdCBhDQo+ID4g PiA+Pj4+PiBjaGFydGVyIGltcGFjdGluZyBwb2ludCBvciBkaXNjdXNzaW9uLiAgSWYgdGhpcyBp cyBpbiBmYWN0IHRoZQ0KPiA+ID4gPj4+Pj4gaXNzdWUgeW91J2QgbGlrZSB0byByYWlzZSBhbmQg ZGlzY3VzcywgbGV0cyBkbyBzbyB1bmRlciBhDQo+ID4gPiA+Pj4+PiBkb2N1bWVudCBzcGVjaWZp YyB0aHJlYWQsIGUuZy4sDQo+ID4gPiA+Pj4gIlN1YmplY3Q6DQo+ID4gPiA+Pj4+IGludGVuZGVk IHN0YXR1cyBvZiByZXZpc2VkLWRhdGFzdG9yZSIuDQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+IEkg YW0gYWN0dWFsbHkgcmFpc2luZyB0aGlzIHBvaW50IHNpbmNlIE5vdmVtYmVyIG1lZXRpbmcuIFRo ZXJlDQo+ID4gPiA+Pj4+IGFyZQ0KPiA+ID4gPj4+IGRpZmZlcmVudA0KPiA+ID4gPj4+PiB0aHJl YWRzIHdoZXJlIEkgZXhwbGFpbmVkIHdoeSBpdCBpcyBhcHByb3ByaWF0ZSBhcyBJbmZvcm1hdGlv bmFsLg0KPiA+ID4gPj4+PiBUaGUgbGFzdCB0aHJlYWQgSSByZW1lbWJlciBpcyBhdDoNCj4gPiA+ ID4+Pj4NCj4gPiA+ID4+DQo+ID4gPg0KPiA+DQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvbmV0bW9kLzFqdV9DYW1VUG56Q0NlcW1sRlI1SkgxDQo+ID4gPiA+Pj4+IDF4 Y1kNCj4gPiA+ID4+Pj4gVGhlIHJlY2VudCBwb3NpdGlvbiBvZiBORVRDT05GIGNvLWNoYWlycyBp cyBpbg0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4NCj4gPiA+DQo+ID4NCj4gaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRjb25mL29NQll3cjVHTXNtQmZvdEtKXzJfY2QNCj4g PiA+ID4+Pj4gOHFyNWsNCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gVGhhbmsgeW91IGZvciB5b3Vy IGNvbnNpZGVyYXRpb24uDQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+IFJlZ2FyZHMsDQo+ID4gPiA+ Pj4+IE1laG1ldA0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiA+ID4+Pj4+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4u bmV0XQ0KPiA+ID4gPj4+Pj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCA4LCAyMDE3IDExOjI4IFBN DQo+ID4gPiA+Pj4+PiBUbzogTWVobWV0IEVyc3VlIDxtZXJzdWVAZ21haWwuY29tPjsgJ0tlbnQg V2F0c2VuJw0KPiA+ID4gPj4+Pj4gPGt3YXRzZW5AanVuaXBlci5uZXQ+OyBuZXRtb2RAaWV0Zi5v cmcNCj4gPiA+ID4+Pj4+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBkcmFmdCBuZXRtb2QgY2hhcnRl ciB1cGRhdGUgcHJvcG9zYWwNCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiBIaSBNZWhtZXQsDQo+ ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gT24gMy84LzIwMTcgNDo0NyBQTSwgTWVobWV0IEVyc3Vl IHdyb3RlOg0KPiA+ID4gPj4+Pj4+IEtlbnQsDQo+ID4gPiA+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4g d2UgdW5kZXJzdGFuZCB0aGF0IHRoaXMgaXMgaG93IE5FVENPTkYgY2hhcnRlcnMgYXJlDQo+ID4g PiA+Pj4+Pj4+IHN0cnVjdHVyZWQsIGJ1dCBpdCBpcyBub3Qgb3VyIHByYWN0aWNlLA0KPiA+ID4g Pj4+Pj4+IEFGQUlLIGl0IHdhcyB0aGUgTkVUTU9EIHByYWN0aWNlIGZvciB0aGUgY2hhcnRlcnMg dW50aWwgdG9kYXkuDQo+ID4gPiA+Pj4+PiBUaGUgY2hhcnRlcnMgZnJvbSB0aGUgbGFzdCBjb3Vw bGUgb2YgeWVhcnMgZG9uJ3QgaGF2ZSB0aGUNCj4gPiA+ID4+Pj4+IGludGVuZGVkIHN0YXR1cyAt LSBhdCBsZWFzdCB0aGUgb25lcyB3ZSBjaGVja2VkLg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ IEkgYWN0dWFsbHkgZmVlbCBwcmV0dHkgc3Ryb25nbHkgYWJvdXQgdGhpcyAod2hpY2ggb2YgY291 cnNlDQo+ID4gPiA+Pj4+PiBjYW4gYmUgZWFzaWx5IG92ZXJydWxlZCBieSBvdXIgQUQpLiAgSXQn cyBteSBleHBlcmllbmNlIHRoYXQNCj4gPiA+ID4+Pj4+IHByZW1hdHVyZSBkaXNjdXNzaW9ucyBv biBpbnRlbmRlZCBzdGF0dXMsIGkuZS4sIGJlZm9yZSBhDQo+ID4gPiA+Pj4+PiBkb2N1bWVudCBp cyBzdWZmaWNpZW50bHkgbWF0dXJlLCBsZWFkcyB0byBwcm9jZXNzLWZvY3VzZWQNCj4gPiA+ID4+ Pj4+IGFyZ3VtZW50cyB0aGF0IGRldHJhY3RzDQo+ID4gPiA+Pj4gZnJvbQ0KPiA+ID4gPj4+PiBt YWtpbmcgdGVjaG5pY2FsIHByb2dyZXNzLg0KPiA+ID4gPj4+Pj4gV2hpbGUgb25jZSBhIGRvY3Vt ZW50IGlzIG1hdHVyZSBhbmQgY29yZSBkaXJlY3Rpb24vY29udGVudCBpcw0KPiA+ID4gPj4+Pj4g Zml4ZWQsIGl0IGlzIGdlbmVyYWxseSBvYnZpb3VzIHdoYXQgc3RhdHVzIGlzIGFwcHJvcHJpYXRl Lg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+Pj4gSSBkaWQgbm90IGFzaw0K PiA+ID4gPj4+Pj4+IG1vcmUgdGhhbiB3cml0dGVuIGluIHRoZSBjdXJyZW50IGNoYXJ0ZXIuDQo+ ID4gPiA+Pj4+Pj4gSXQgd291bGQgYmUgZ29vZCB0byBicmluZyB0aGUgaGlnaC1sZXZlbCB0b3Bp Y3MgaW4gcmVsYXRpb24NCj4gPiA+ID4+Pj4+PiB0byB0aGUgV0cNCj4gPiA+ID4+Pj4gaXRlbXMu DQo+ID4gPiA+Pj4+PiBJJ20gc29ycnksIEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIGxhc3Qgc2Vu dGVuY2UgY2FuIHlvdQ0KcmVwaHJhc2UNCj4gaXQ/DQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4+ PiBhcyB0aGUgaW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlIGF0IHRoZSB0b3Agb2YgZWFjaCBkcmFm dCwNCj4gPiA+ID4+Pj4+Pj4gYW5kIGFsc28gYmVjYXVzZQ0KPiA+ID4gPj4+Pj4gdGhpcyBpbmZv cm1hdGlvbiBuZWVkIG5vdCBiZSBmaXhlZCB3aGVuIHRoZSBtaWxlc3RvbmUgaXMgYWRkZWQuDQo+ ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4+IEkgYmVsaWV2ZSBhIFdHIGNoYXJ0ZXIgc2hvdWxkIGJl IHNlbGYtc3VmZmljaWVudCBjb3ZlcmluZyB0aGUNCj4gPiA+ID4+Pj4+PiB0YXJnZXQgZGVmaW5p dGlvbiBhbmQgaW50ZW5kZWQgc3RhdHVzIG9mIHRoZSBXRyBpdGVtcy4NCj4gPiA+ID4+Pj4+PiBP dGhlcndpc2Ugb25lIGNhbiBjaGFuZ2UgdGhlIHRhcmdldCBmb3IgYSBXRyBpdGVtIGJ5IHNpbXBs eQ0KPiA+ID4gPj4+Pj4+IGVkaXRpbmcgdGhlIGRyYWZ0IGFic3RyYWN0IGFueXRpbWUuDQo+ID4g PiA+Pj4+PiBQZXIgSUVURiBwcm9jZXNzLCBhbGwgaXQgZXZlciB0YWtlcyB0byBtYWtlIGEgY2hh bmdlIGluDQo+ID4gPiA+Pj4+PiBkb2N1bWVudCBzdGF0dXMgaXMgV0cgY29uc2Vuc3VzLCBhbmQg dGhlbiBJRVNHIGFuZCBJRVRGIGJ1eS1pbg0KPiA+ID4gPj4+Pj4gYXMgcGFydCBvZiB0aGUNCj4g PiA+ID4+Pj4gcHVibGljYXRpb24gcHJvY2Vzcy4NCj4gPiA+ID4+Pj4+PiBCVFc6IFdlIGFncmVl ZCBpbiBkaXZlcnNlIGRpc2N1c3Npb25zIHRoYXQgdGhlIERTIGNvbmNlcHQgaXMNCj4gPiA+ID4+ Pj4+PiBJbmZvcm1hdGlvbmFsIGluIG5hdHVyZS4NCj4gPiA+ID4+Pj4+PiBJIHRoaW5rIHRoaXMg c2hvdWxkIGJlIGNvcnJlY3RlZCBpbiB0aGUgZHJhZnQuDQo+ID4gPiA+Pj4+PiBTbyB0aGlzIHNv dW5kcyBsaWtlIGFuIG9iamVjdGlvbiB0byBhIHNwZWNpZmljIGRvY3VtZW50LiAgVGhpcw0KPiA+ ID4gPj4+Pj4gaXMgYSBmYWlyIHBvaW50IHRvIHJhaXNlLCBidXQgaW4gb3VyIG9waW5pb24gaXQg aXMgbm90IGENCj4gPiA+ID4+Pj4+IGNoYXJ0ZXIgaW1wYWN0aW5nIHBvaW50IG9yIGRpc2N1c3Np b24uICBJZiB0aGlzIGlzIGluIGZhY3QgdGhlDQo+ID4gPiA+Pj4+PiBpc3N1ZSB5b3UnZCBsaWtl IHRvIHJhaXNlIGFuZCBkaXNjdXNzLCBsZXRzIGRvIHNvIHVuZGVyIGENCj4gPiA+ID4+Pj4+IGRv Y3VtZW50IHNwZWNpZmljIHRocmVhZCwgZS5nLiwNCj4gPiA+ID4+PiAiU3ViamVjdDoNCj4gPiA+ ID4+Pj4+IGludGVuZGVkIHN0YXR1cyBvZiByZXZpc2VkLWRhdGFzdG9yZSIuDQo+ID4gPiA+Pj4+ Pg0KPiA+ID4gPj4+Pj4gVGhhbmtzLA0KPiA+ID4gPj4+Pj4gTG91DQo+ID4gPiA+Pj4+Pg0KPiA+ ID4gPj4+Pj4+IE1laG1ldA0KPiA+ID4gPj4+Pj4+DQo+ID4gPiA+Pj4+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+Pj4+Pj4+IEZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1v ZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiA+IEtlbnQNCj4gPiA+ID4+Pj4+ Pj4gV2F0c2VuDQo+ID4gPiA+Pj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggOCwgMjAxNyA3 OjQ1IFBNDQo+ID4gPiA+Pj4+Pj4+IFRvOiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiA+ID4+Pj4+Pj4g Q2M6IG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmcNCj4gPiA+ID4+Pj4+Pj4gU3ViamVjdDogUmU6IFtu ZXRtb2RdIGRyYWZ0IG5ldG1vZCBjaGFydGVyIHVwZGF0ZSBwcm9wb3NhbA0KPiA+ID4gPj4+Pj4+ Pg0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+ Pj4+PiBIaSBORVRNT0QgV0csDQo+ID4gPiA+Pj4+Pj4+DQo+ID4gPiA+Pj4+Pj4+IFBsZWFzZSBm aW5kIGJlbG93IGRyYWZ0LTQgaGF2aW5nIHRoZSBmb2xsb3dpbmcgY2hhbmdlOg0KPiA+ID4gPj4+ Pj4+Pg0KPiA+ID4gPj4+Pj4+PiAgLSBhZGRlZCAiKGUuZy4sIEkyUlMsIFJUR1dHKSIgdG8gYSBz ZW50ZW5jZS4NCj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4gSGkgU3VlLCBMb3UgYW5kIEkg bG9va2VkIGF0IHRoZSBwcm9wb3NlZCBjaGFydGVyIGFuZCBmb3VuZCBhDQo+ID4gPiA+Pj4+Pj4+ IHNlbnRlbmNlIHRoYXQgbmljZWx5IGRlc2NyaWJlcyBvdXIgV0cncyBpbnRlbnQgdG8gd29yayB3 aXRoDQo+ID4gPiA+Pj4+Pj4+IGFuZCBzdXBwb3J0IG90aGVyIFdHcyAoYmV5b25kIE5FVENPTkYp LCBidXQgd2UgZmVsdCB0aGF0DQo+IHRoZQ0KPiA+ID4gPj4+Pj4+PiB0ZXh0IGNvdWxkIGJlIG1h ZGUgbW9yZSBjbGVhciBieSBhZGRpbmcgaW4gdGhlDQo+ID4gPiA+Pj4+Pj4+IGFib3ZlLW1lbnRp b25lZA0KPiA+ID4gY2hhbmdlLg0KPiA+ID4gPj4+Pj4+PiBCZXlvbmQgdGhpcywgYW5kIHRoZSBl eGlzdGluZyBhKSwNCj4gPiA+ID4+Pj4+PiBiKSwNCj4gPiA+ID4+Pj4+Pj4gYW5kIGMpLCB3ZSBi ZWxpZXZlIHRoYXQgdGhlIGNoYXJ0ZXIgcHJvcG9zYWwgY292ZXJzIG91cg0KPiA+ID4gPj4+Pj4+ PiBzdXBwb3J0IGZvciBJMlJTLA0KPiA+ID4gPj4+Pj4+IGRvDQo+ID4gPiA+Pj4+Pj4+IHlvdSBh Z3JlZT8NCj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4gSGkgTWVobWV0LCByZWdhcmRpbmcg cHV0dGluZyBhIHNob3J0IGRlc2NyaXB0aW9uIGFuZCB0aGUNCj4gPiA+ID4+Pj4+Pj4gaW50ZW5k ZWQgc3RhdHVzDQo+ID4gPiA+Pj4+Pj4gZm9yDQo+ID4gPiA+Pj4+Pj4+IGVhY2ggZHJhZnQgaW50 byB0aGUgY2hhcnRlciwgd2UgdW5kZXJzdGFuZCB0aGF0IHRoaXMgaXMgaG93DQo+ID4gPiA+Pj4+ Pj4+IE5FVENPTkYNCj4gPiA+ID4+Pj4+PiBjaGFydGVycw0KPiA+ID4gPj4+Pj4+PiBhcmUgc3Ry dWN0dXJlZCwgYnV0IGl0IGlzIG5vdCBvdXIgcHJhY3RpY2UsIGFzIHRoZQ0KPiA+ID4gPj4+Pj4+ PiBpbmZvcm1hdGlvbiBpcw0KPiA+ID4gPj4+Pj4+IGF2YWlsYWJsZSBhdCB0aGUNCj4gPiA+ID4+ Pj4+Pj4gdG9wIG9mIGVhY2ggZHJhZnQsIGFuZCBhbHNvIGJlY2F1c2UgdGhpcyBpbmZvcm1hdGlv biBuZWVkDQo+ID4gPiA+Pj4+Pj4+IG5vdCBiZSBmaXhlZA0KPiA+ID4gPj4+Pj4+IHdoZW4NCj4g PiA+ID4+Pj4+Pj4gdGhlIG1pbGVzdG9uZSBpcyBhZGRlZC4NCj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ ID4+Pj4+Pj4gQWxsLCBBbnkgb3RoZXIgY29tbWVudHM/DQo+ID4gPiA+Pj4+Pj4+DQo+ID4gPiA+ Pj4+Pj4+IEtlbnQNCj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4N Cj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4gTmV0d29yayBNb2RlbGluZyAoTkVUTU9EKQ0K PiA+ID4gPj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+Pj4+Pj4+DQo+ ID4gPiA+Pj4+Pj4+IENoYXJ0ZXINCj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4gQ3VycmVu dCBTdGF0dXM6IEFjdGl2ZQ0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+Pj4+PiBDaGFpcnM6DQo+ ID4gPiA+Pj4+Pj4+ICAgIExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQo+ID4gPiA+Pj4+ Pj4+ICAgIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0Pg0KPiA+ID4gPj4+Pj4+Pg0K PiA+ID4gPj4+Pj4+PiBPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50IEFyZWEgRGlyZWN0b3JzOg0K PiA+ID4gPj4+Pj4+PiAgICBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4NCj4gPiA+ ID4+Pj4+Pj4gICAgSm9lbCBKYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPg0KPiA+ID4gPj4+Pj4+ Pg0KPiA+ID4gPj4+Pj4+PiBPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50IEFyZWEgQWR2aXNvcjoN Cj4gPiA+ID4+Pj4+Pj4gICAgQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+DQo+ID4g PiA+Pj4+Pj4+DQo+ID4gPiA+Pj4+Pj4+IFNlY3JldGFyeToNCj4gPiA+ID4+Pj4+Pj4gICAgWml0 YW8gKE1pY2hhZWwpIFdhbmcgPHdhbmd6aXRhb0BodWF3ZWkuY29tPg0KPiA+ID4gPj4+Pj4+Pg0K PiA+ID4gPj4+Pj4+PiBNYWlsaW5nIExpc3RzOg0KPiA+ID4gPj4+Pj4+PiAgICBHZW5lcmFsIERp c2N1c3Npb246IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gPj4+Pj4+PiAgICBUbyBTdWJzY3JpYmU6 DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPiA+ ID4+Pj4+Pj4gICAgQXJjaGl2ZToNCj4gPiA+ID4+PiBodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvYnJvd3NlL25ldG1vZC8NCj4gPiA+ID4+Pj4+Pj4gRGVzY3JpcHRpb24gb2YgV29y a2luZyBHcm91cDoNCj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4gICAgVGhlIE5ldHdvcmsg TW9kZWxpbmcgKE5FVE1PRCkgd29ya2luZyBncm91cCBpcw0KPiA+ID4gPj4+Pj4+PiByZXNwb25z aWJsZSBmb3IgdGhlIFlBTkcNCj4gPiA+ID4+Pj4+Pj4gICAgZGF0YSBtb2RlbGluZyBsYW5ndWFn ZSwgYW5kIGd1aWRlbGluZXMgZm9yIGRldmVsb3BpbmcNCj4gPiA+ID4+Pj4+Pj4gWUFORw0KPiA+ ID4gPj4gbW9kZWxzLg0KPiA+ID4gPj4+Pj4gVGhlDQo+ID4gPiA+Pj4+Pj4+ICAgIE5FVE1PRCB3 b3JraW5nIGdyb3VwIGFkZHJlc3NlcyBnZW5lcmFsIHRvcGljcyByZWxhdGVkIHRvDQo+ID4gPiA+ Pj4+Pj4+IHRoZSB1c2Ugb2YNCj4gPiA+ID4+Pj4+IHRoZQ0KPiA+ID4gPj4+Pj4+PiAgICBZQU5H IGxhbmd1YWdlIGFuZCBZQU5HIG1vZGVscywgZm9yIGV4YW1wbGUsIHRoZSBtYXBwaW5nDQo+ID4g PiA+Pj4+Pj4+IG9mDQo+ID4gPiA+PiBZQU5HDQo+ID4gPiA+Pj4+Pj4+IG1vZGVsZWQNCj4gPiA+ ID4+Pj4+Pj4gICAgZGF0YSBpbnRvIHZhcmlvdXMgZW5jb2RpbmdzLiAgRmluYWxseSwgdGhlIE5F VE1PRCB3b3JraW5nDQo+ID4gZ3JvdXANCj4gPiA+ID4+Pj4+Pj4gICAgYWxzbyBkZWZpbmVzIGNv cmUgWUFORyBtb2RlbHMgdXNlZCBhcyBiYXNpYyBZQU5HIGJ1aWxkaW5nDQo+ID4gPiA+Pj4+Pj4+ IGJsb2NrcywNCj4gPiA+ID4+Pj4gYW5kDQo+ID4gPiA+Pj4+Pj4+ICAgIFlBTkcgbW9kZWxzIHRo YXQgZG8gbm90IG90aGVyd2lzZSBmYWxsIHVuZGVyIHRoZSBjaGFydGVyDQo+ID4gPiA+Pj4+Pj4+ IG9mIGFueQ0KPiA+ID4gPj4+IG90aGVyDQo+ID4gPiA+Pj4+Pj4+ICAgIElFVEYgd29ya2luZyBn cm91cC4NCj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4gVGhlIE5FVE1PRCBXRyBpcyByZXNw b25zaWJsZSBmb3I6DQo+ID4gPiA+Pj4+Pj4+DQo+ID4gPiA+Pj4+Pj4+ICAgIGEpIE1haW50YWlu aW5nIHRoZSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIFlBTkcuICBUaGlzDQo+ID4gPiA+Pj4+Pj4+ IGVmZm9ydA0KPiA+ID4gPj4+IGVudGFpbHMNCj4gPiA+ID4+Pj4+Pj4gICAgICAgcGVyaW9kaWNh bGx5IHVwZGF0aW5nIHRoZSBzcGVjaWZpY2F0aW9uIHRvIGFkZHJlc3MgbmV3DQo+ID4gPiA+Pj4g cmVxdWlyZW1lbnRzDQo+ID4gPiA+Pj4+Pj4+ICAgICAgIGFzIHRoZXkgYXJpc2UuDQo+ID4gPiA+ Pj4+Pj4+DQo+ID4gPiA+Pj4+Pj4+ICAgIGIpIE1haW50YWluaW5nIHRoZSBndWlkZWxpbmVzIGZv ciBkZXZlbG9waW5nIFlBTkcgbW9kZWxzLg0KPiA+ID4gPj4+Pj4+PiBUaGlzDQo+ID4gPiA+Pj4g ZWZmb3J0DQo+ID4gPiA+Pj4+Pj4+ICAgICAgIGlzIHByaW1hcmlseSBkcml2ZW4gYnkgdXBkYXRl cyBtYWRlIHRvIHRoZSBZQU5HDQo+IHNwZWNpZmljYXRpb24uDQo+ID4gPiA+Pj4+Pj4+DQo+ID4g PiA+Pj4+Pj4+ICAgIGMpIE1haW50YWluaW5nIGEgY29uY2VwdHVhbCBmcmFtZXdvcmsgaW4gd2hp Y2ggWUFORw0KPiA+ID4gPj4+Pj4+PiBtb2RlbHMgYXJlDQo+ID4gPiA+Pj4+IHVzZWQuDQo+ID4g PiA+Pj4+Pj4+ICAgICAgIFRoaXMgZWZmb3J0IGVudGFpbHMgZGVzY3JpYmluZyB0aGUgZ2VuZXJp YyBjb250ZXh0DQo+ID4gPiA+Pj4+Pj4+IHRoYXQgaW4NCj4gPiA+ID4gWUFORw0KPiA+ID4gPj4+ Pj4+PiAgICAgICBleGlzdHMgYW5kIGhvdyBjZXJ0YWluIFlBTkcgc3RhdGVtZW50cyBpbnRlcmFj dCBpbg0KPiA+ID4gPj4+Pj4+PiB0aGF0DQo+ID4gPiA+Pj4gY29udGV4dC4NCj4gPiA+ID4+Pj4+ Pj4gICAgICAgQW4gZXhhbXBsZSBvZiB0aGlzIGlzIFlBTkcncyByZWxhdGlvbnNoaXAgd2l0aA0K ZGF0YXN0b3Jlcy4NCj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4gICAgZCkgTWFpbnRhaW5p bmcgZW5jb2RpbmdzIGZvciBZQU5HIG1vZGVsZWQgZGF0YS4gIFRoaXMNCj4gPiA+ID4+Pj4+Pj4g ZWZmb3J0DQo+ID4gPiA+Pj4gZW50YWlscw0KPiA+ID4gPj4+Pj4+PiAgICAgICB1cGRhdGluZyBl bmNvZGluZ3MgYWxyZWFkeSBkZWZpbmVkIGJ5IHRoZSBORVRNT0QNCj4gPiA+ID4+Pj4+Pj4gd29y a2luZyAoWE1MDQo+ID4gPiA+Pj4+IGFuZA0KPiA+ID4gPj4+Pj4+PiAgICAgICBKU09OKSB0byBh Y2NvbW1vZGF0ZSBjaGFuZ2VzIHRvIHRoZSBZQU5HDQo+ID4gPiA+Pj4+Pj4+IHNwZWNpZmljYXRp b24sIGFuZA0KPiA+ID4gPj4+Pj4gZGVmaW5pbmcNCj4gPiA+ID4+Pj4+Pj4gICAgICAgbmV3IGVu Y29kaW5ncyB0aGF0IGFyZSBuZWVkZWQsIGFuZCB5ZXQgZG8gbm90IGZhbGwNCj4gPiA+ID4+Pj4+ Pj4gdW5kZXIgdGhlDQo+ID4gPiA+Pj4gY2hhcnRlcg0KPiA+ID4gPj4+Pj4+PiAgICAgICBvZiBh bnkgb3RoZXIgYWN0aXZlIElFVEYgd29ya2luZyBncm91cC4NCj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ ID4+Pj4+Pj4gICAgZSkgTWFpbnRhaW5pbmcgWUFORyBtb2RlbHMgdXNlZCBhcyBiYXNpYyBZQU5H IGJ1aWxkaW5nDQo+ID4gYmxvY2tzLg0KPiA+ID4gPj4+IFRoaXMNCj4gPiA+ID4+Pj4+Pj4gICAg ICAgZWZmb3J0IGVudGFpbHMgdXBkYXRpbmcgZXhpc3RpbmcgWUFORyBtb2RlbHMNCj4gPiA+ID4+ Pj4+Pj4gKGlldGYteWFuZy10eXBlcw0KPiA+ID4gPj4+IGFuZA0KPiA+ID4gPj4+Pj4+PiAgICAg ICBpZXRmLWluZXQtdHlwZXMpIGFzIG5lZWRlZCwgYXMgd2VsbCBhcyBkZWZpbmluZw0KPiA+ID4g Pj4+Pj4+PiBhZGRpdGlvbmFsIGNvcmUNCj4gPiA+ID4+PiBZQU5HDQo+ID4gPiA+Pj4+Pj4+ICAg ICAgIGRhdGEgbW9kZWxzIHdoZW4gbmVjZXNzYXJ5Lg0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+ Pj4+PiAgICBmKSBEZWZpbmluZyBhbmQgbWFpbnRhaW5pbmcgWUFORyBtb2RlbHMgdGhhdCBkbyBu b3QgZmFsbA0KPiA+ID4gPj4+Pj4+PiB1bmRlcg0KPiA+ID4gPiB0aGUNCj4gPiA+ID4+Pj4+Pj4g ICAgICAgY2hhcnRlciBvZiBhbnkgb3RoZXIgYWN0aXZlIElFVEYgd29ya2luZyBncm91cC4NCj4g PiA+ID4+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4gICAgVGhlIE5FVE1PRCB3b3JraW5nIGdyb3VwIGNv bnN1bHRzIHdpdGggdGhlIE5FVENPTkYNCj4gPiB3b3JraW5nDQo+ID4gPiA+Pj4+IGdyb3VwDQo+ ID4gPiA+Pj4+PiB0bw0KPiA+ID4gPj4+Pj4+PiAgICBlbnN1cmUgdGhhdCBuZXcgcmVxdWlyZW1l bnRzIGFyZSB1bmRlcnN0b29kIGFuZCBjYW4gYmUNCj4gPiA+ID4+Pj4+Pj4gbWV0IGJ5DQo+ID4g PiA+PiB0aGUNCj4gPiA+ID4+Pj4+Pj4gICAgcHJvdG9jb2xzIChlLmcuLCBORVRDT05GIGFuZCBS RVNUQ09ORikgZGV2ZWxvcGVkIHdpdGhpbg0KPiA+ID4gPj4+Pj4+PiB0aGF0DQo+ID4gPiA+Pj4+ IHdvcmtpbmcNCj4gPiA+ID4+Pj4+Pj4gICAgZ3JvdXAuICBUaGUgTkVUTU9EIHdvcmtpbmcgZ3Jv dXAgY29vcmRpbmF0ZXMgd2l0aCBvdGhlcg0KPiA+ID4gPj4+Pj4+PiB3b3JraW5nDQo+ID4gPiA+ Pj4+PiBncm91cHMNCj4gPiA+ID4+Pj4+Pj4gICAgKGUuZy4sIEkyUlMsIFJUR1dHKSBvbiBwb3Nz aWJsZSBleHRlbnNpb25zIHRvIFlBTkcgdG8NCj4gPiA+ID4+Pj4+Pj4gYWRkcmVzcw0KPiA+ID4g bmV3DQo+ID4gPiA+Pj4+Pj4+ICAgIG1vZGVsaW5nIHJlcXVpcmVtZW50cyBhbmQsIHdoZW4gbmVl ZGVkLCB3aGljaCBncm91cCB3aWxsDQo+ID4gPiA+Pj4+Pj4+IHJ1bg0KPiA+ID4gdGhlDQo+ID4g PiA+Pj4+Pj4+ICAgIHByb2Nlc3Mgb24gYSBzcGVjaWZpYyBtb2RlbC4NCj4gPiA+ID4+Pj4+Pj4N Cj4gPiA+ID4+Pj4+Pj4gICAgVGhlIE5FVE1PRCB3b3JraW5nIGdyb3VwIGRvZXMgbm90IHNlcnZl IGFzIGEgcmV2aWV3IHRlYW0NCj4gPiA+ID4+Pj4+Pj4gZm9yDQo+ID4gPiA+Pj4+IFlBTkcNCj4g PiA+ID4+Pj4+Pj4gICAgbW9kdWxlcyBkZXZlbG9wZWQgYnkgb3RoZXIgd29ya2luZyBncm91cHMu IEluc3RlYWQsIHRoZQ0KPiA+ID4gPj4+Pj4+PiBZQU5HDQo+ID4gPiA+Pj4+PiBkb2N0b3JzLA0K PiA+ID4gPj4+Pj4+PiAgICBhcyBvcmdhbml6ZWQgYnkgdGhlIE9QUyBhcmVhIGRpcmVjdG9yIHJl c3BvbnNpYmxlIGZvcg0KbmV0d29yaw0KPiA+ID4gPj4+Pj4+PiAgICBtYW5hZ2VtZW50LCB3aWxs IGFjdCBhcyBhZHZpc29ycyBmb3Igb3RoZXIgd29ya2luZyBncm91cHMNCj4gPiA+ID4+Pj4+Pj4g YW5kDQo+ID4gPiA+Pj4gcHJvdmlkZQ0KPiA+ID4gPj4+Pj4+PiAgICBZQU5HIHJldmlld3MgZm9y IHRoZSBPUFMgYXJlYSBkaXJlY3RvcnMuDQo+ID4gPiA+Pj4+Pj4+DQo+ID4gPiA+Pj4+Pj4+IE1p bGVzdG9uZXM6DQo+ID4gPiA+Pj4+Pj4+DQo+ID4gPiA+Pj4+Pj4+ICAgIERvbmUgICAgIC0gU3Vi bWl0IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzYwODdiaXMgdG8gSUVTRyBmb3INCj4gPiA+ID4+PiBw dWJsaWNhdGlvbg0KPiA+ID4gPj4+Pj4+PiAgICBNYXIgMjAxNyAtIFN1Ym1pdA0KPiA+ID4gPj4+ Pj4+PiBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLW1vZGVsLWNsYXNzaWZpY2F0aW9uDQo+ID4gPiA+ Pj4+Pj4+IHRvDQo+ID4gPiA+Pj4gSUVTRw0KPiA+ID4gPj4+Pj4+PiAgICAgICAgICAgICAgIGZv ciBwdWJsaWNhdGlvbg0KPiA+ID4gPj4+Pj4+PiAgICBNYXIgMjAxNyAtIFN1Ym1pdCBkcmFmdC1p ZXRmLW5ldG1vZC1hY2wtbW9kZWwgdG8gSUVTRyBmb3INCj4gPiA+ID4+PiBwdWJsaWNhdGlvbg0K PiA+ID4gPj4+Pj4+PiAgICBBcHIgMjAxNyAtIFN1Ym1pdCBkcmFmdC1pZXRmLW5ldG1vZC1lbnRp dHkgdG8gSUVTRyBmb3INCj4gPiA+ID4gcHVibGljYXRpb24NCj4gPiA+ID4+Pj4+Pj4gICAgQXBy IDIwMTcgLSBTdWJtaXQgZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsIHRvIElFU0cNCj4g PiA+ID4+Pj4+Pj4gZm9yDQo+ID4gPiA+Pj4+Pj4gcHVibGljYXRpb24NCj4gPiA+ID4+Pj4+Pj4g ICAgT2N0IDIwMTcgLSBTdWJtaXQgZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50IHRvIElF U0cNCj4gPiA+ID4+Pj4+Pj4gZm9yDQo+ID4gPiA+Pj4+Pj4gcHVibGljYXRpb24NCj4gPiA+ID4+ Pj4+Pj4gICAgT2N0IDIwMTcgLSBTdWJtaXQgZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRh c3RvcmVzIHRvDQo+ID4gPiA+Pj4+Pj4+IElFU0cNCj4gPiA+ID4gZm9yDQo+ID4gPiA+Pj4+Pj4+ ICAgICAgICAgICAgICAgcHVibGljYXRpb24NCj4gPiA+ID4+Pj4+Pj4gICAgRGVjIDIwMTcgLSBT dWJtaXQgZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZyB0byBJRVNHDQpmb3INCj4gPiA+ ID4+Pj4+Pj4gICAgICAgICAgICAgICBwdWJsaWNhdGlvbg0KPiA+ID4gPj4+Pj4+PiAgICBEZWMg MjAxNyAtIFN1Ym1pdCBkcmFmdC1pZXRmLW5ldG1vZC1zdWItaW50Zi12bGFuLXlhbmcgdG8NCj4g PiA+ID4+Pj4+Pj4gSUVTRw0KPiA+ID4gPiBmb3INCj4gPiA+ID4+Pj4+Pj4gICAgICAgICAgICAg ICBwdWJsaWNhdGlvbg0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+Pj4+ Pg0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+ Pj4+Pg0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPj4+Pj4+PiBu ZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiA+Pj4+Pj4+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4g Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+ ID4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gPiA+Pj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gPj4+Pj4+IG5ldG1vZEBp ZXRmLm9yZw0KPiA+ID4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQo+ID4gPiA+Pj4+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+DQo+ ID4gPiA+DQoNCg0KDQoNCg== From nobody Wed Mar 22 14:08:50 2017 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 6D752128BBB for ; Wed, 22 Mar 2017 14:08:49 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 HdPOLMxJBsUL for ; Wed, 22 Mar 2017 14:08:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4820120326 for ; Wed, 22 Mar 2017 14:08:46 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D194865E7; Wed, 22 Mar 2017 21:41:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3ARyiMrRvYVS; Wed, 22 Mar 2017 21:41:32 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 22 Mar 2017 21:41:33 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A2F52006D; Wed, 22 Mar 2017 21:41:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hFlJyDXnuiGw; Wed, 22 Mar 2017 21:41:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4796620576; Wed, 22 Mar 2017 21:40:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 760043EF539C; Wed, 22 Mar 2017 21:40:36 +0100 (CET) Date: Wed, 22 Mar 2017 21:40:35 +0100 From: Juergen Schoenwaelder To: "Dale R. Worley" Cc: netmod@ietf.org Message-ID: <20170322204035.GA39086@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Dale R. Worley" , netmod@ietf.org References: <87shm5rwuq.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87shm5rwuq.fsf@hobgoblin.ariadne.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] uses and augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 21:08:49 -0000 On Wed, Mar 22, 2017 at 02:26:53PM -0400, Dale R. Worley wrote: > I've got a couple of questions about the interaction of "uses" and > "augment". I hope that these have straightforward answers that the old > hands can tell me easily enough. > > 1. Augmenting a grouping > > I notice that "augment" is not allowed to target a "grouping", despite > that naively seems to be an operation that a module designer might like > to do. I expect that there is a reason why this is not allowed. > > For example: > > module foo { > ... > grouping target { > leaf address { > type inet:ip-address; > description "Target IP address."; > } > leaf port { > type inet:port-number; > description "Target port number."; > } > } > } > > module bar { > ... > import foo { > ... > } > augment "/foo:target" { > leaf new-leaf { > type string; > } > } > } > > module baz { > ... > import foo { > ... > } > container main { > uses foo:target; > } > } > > giving an effective schema: > > container main { > leaf address { > type inet:ip-address; > description "Target IP address."; > } > leaf port { > type inet:port-number; > description "Target port number."; > } > leaf new-leaf { > type string; > } > } This is not at all clear. You only import 'foo' - so why would the augment of /foo:target (which is not exactly defined either) done in 'bar' apply to uses foo:target in baz? In short, it is unclear where the augmentation of the grouping applies and where not. Augments are restricted to things that have a well defined name in the data tree because this makes it clear what is being augmented. One would have to create additional language constructs to make augmentations of groupings work. /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 Mar 22 16:13:35 2017 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 1ABE11293FC for ; Wed, 22 Mar 2017 16:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 zCfhQZOFuSdg for ; Wed, 22 Mar 2017 16:13:32 -0700 (PDT) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E526126C83 for ; Wed, 22 Mar 2017 16:13:32 -0700 (PDT) From: Alex Campbell To: Martin Bjorklund , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt Thread-Index: AQHSm82U7fMEhsdyh0uMYFKEptI+naGS2bGAgA6vL7k= Date: Wed, 22 Mar 2017 23:13:30 +0000 Message-ID: <1490224410506.79597@Aviatnet.com> References: <148939103369.17026.5784133761974804877@ietfa.amsl.com>, <20170313.084651.1144668331995785992.mbj@tail-f.com> In-Reply-To: <20170313.084651.1144668331995785992.mbj@tail-f.com> Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 23:13:34 -0000 Hi,=0A= =0A= In the description of /hardware-state/component, which describes the proced= ure for matching newly added hardware components with pre-configured entrie= s in /hardware/component:=0A= =0A= What happens if hardware-config is supported, and there is no entry with ma= tching values for the nodes 'class', 'parent', and 'parent-rel-pos'? (i.e. = step 1's condition is not true)=0A= Why is mfg-name treated specially - and not, for example, serial-num?=0A= Why is it recommended for implementations to warn about a mfg-name mismatch= , but not a class mismatch?=0A= =0A= =0A= =0A= ________________________________________=0A= From: netmod on behalf of Martin Bjorklund =0A= Sent: Monday, 13 March 2017 8:46 p.m.=0A= To: netmod@ietf.org=0A= Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-03.txt=0A= =0A= Hi,=0A= =0A= This version addresses the comments from Bart and Juergen.=0A= =0A= I think that this document is now ready for WGLC.=0A= =0A= =0A= /martin=0A= =0A= =0A= internet-drafts@ietf.org wrote:=0A= >=0A= > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories.=0A= > This draft is a work item of the NETCONF Data Modeling Language of the IE= TF.=0A= >=0A= > Title : A YANG Data Model for Hardware Management=0A= > Authors : Andy Bierman=0A= > Martin Bjorklund=0A= > Jie Dong=0A= > Dan Romascanu=0A= > Filename : draft-ietf-netmod-entity-03.txt=0A= > Pages : 40=0A= > Date : 2017-03-13=0A= >=0A= > Abstract:=0A= > This document defines a YANG data model for the management of=0A= > hardware on a single server.=0A= >=0A= >=0A= > The IETF datatracker status page for this draft is:=0A= > https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/=0A= >=0A= > There's also a htmlized version available at:=0A= > https://tools.ietf.org/html/draft-ietf-netmod-entity-03=0A= >=0A= > A diff from the previous version is available at:=0A= > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-entity-03=0A= >=0A= >=0A= > Please note that it may take a couple of minutes from the time of submiss= ion=0A= > until the htmlized version and diff are available at tools.ietf.org.=0A= >=0A= > Internet-Drafts are also available by anonymous FTP at:=0A= > ftp://ftp.ietf.org/internet-drafts/=0A= >=0A= > _______________________________________________=0A= > netmod mailing list=0A= > netmod@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/netmod=0A= >=0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Wed Mar 22 18:26:07 2017 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 7B9A8128AB0; Wed, 22 Mar 2017 18:26:05 -0700 (PDT) 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 b3X8v-_dXp4X; Wed, 22 Mar 2017 18:26:03 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 B6DCA12422F; Wed, 22 Mar 2017 18:26:02 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id g2so33204758pge.2; Wed, 22 Mar 2017 18:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=WSY9TzEyy4Xz04WNJfN81CqF4ysbCwhXMLx5RU0KreU=; b=Q9u8GSXOQos+3iGs31+s9wjHIoHRX9te4Yu+MKA4UWsnNDeP1K0Q0bWwedpZsfHyGO ay5yxmhrfu/HMwIhIlEsvPFut4uF3MeYiF6G3iPVQrc2xc2OaHSxCyt7L1ccq5BoDkok VkEx2FW6mHQpf4gAKwfnvZrnwa4k44q9Wu8GtUToXbPRm8dT36p9u3p5OfAztmLzlkHx 7rMVIk4dZbd9jNegntL0OTPrBXxu3GOnyAUyGE+7+R+/oyq/0FCJ5C7uaYuMspjDGnAd BM298stJyVp4+Iu4OaJ7USOCGN/YlAiRF/XlNb8GtrcEWhvdWQ7vG++icAgL/jaUajjw 411g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=WSY9TzEyy4Xz04WNJfN81CqF4ysbCwhXMLx5RU0KreU=; b=Wv/U8V7J7XRnE8c5JYJcr/TgqB8KKjXyrzjDwm2bVt6ZtNumowhRPYVuDUfnBFVlfo iZnGyBUn+B4dgkc8VuaHyGPTdX2WSVK21UpWfDRuNP3QwsQ0/535O7PZexwUSaHkFcWm phAuj8Wm7bznOE6M9/NkjXhlgzh0x8LuRE9BNtItkIC9h8cNmwoYYSOS5xxLLSgJU9w8 GIKc8CjqTupLeyz4ebT4YjwvgH4b0CU/SbeAduL3kJR9Rl4h1KjCWiQNbNwXT4b6/bbs HmO0EXFWFRICoeGgs/g1mS3pAZ0HrNN35ufRHpXv7B9kJHrgE5zW0fyQm+ytYT1OxkhC TW/g== X-Gm-Message-State: AFeK/H2rrUiUqXDEJmZCGBo2KKAedHVKlvFuvdomu/3TTejz32WYBZr2MxYzJewSKOfPkA== X-Received: by 10.99.61.201 with SMTP id k192mr14750631pga.68.1490232362160; Wed, 22 Mar 2017 18:26:02 -0700 (PDT) Received: from ?IPv6:2602:306:cf77:df90:8934:e85:444c:1d55? ([2602:306:cf77:df90:8934:e85:444c:1d55]) by smtp.gmail.com with ESMTPSA id t187sm6139194pfb.116.2017.03.22.18.26.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Mar 2017 18:26:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5887CB5C-9DD9-44C7-9EAC-80FD39F8A88F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> Date: Wed, 22 Mar 2017 18:26:00 -0700 Cc: NetMod WG , ccamp@ietf.org Message-Id: <06F5F172-8C4A-4272-9815-DECE13CB4F19@gmail.com> References: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 01:26:05 -0000 --Apple-Mail=_5887CB5C-9DD9-44C7-9EAC-80FD39F8A88F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 22, 2017, at 8:21 AM, Robert Wilton wrote: >=20 > Hi, >=20 > I'm participating in the 802.3 task force (802.3cf) to produce = standard YANG models for Ethernet interfaces and protocols covered by = the IEEE 802.3 Ethernet Working Group. >=20 > As part of my involvement with that group, I want to highlight a = couple of issues that arose in that forum that may be of interest to = various WGs in IETF. >=20 > This email, and accompanying slides, represents my personal views, and = do not represent any formal IEEE position. However, both this email and = the accompanying slides have been reviewed in an 802.3cf task force = meeting, and there were no objections to the content, or my sending of = this email to IETF. >=20 > I also raised these issues (with an earlier set of slides) as part of = the IETF/IEEE liaison meeting on 31st January, and the consensus was = generally supportive of this approach, with the agreed next steps to = contact the NETMOD and CCAMP chairs, which I have done, and the WGs = (hence this email): >=20 > As part of that YANG modelling work, there is an aim to define a clean = boundary of what manageability data should be specified within 802.3 and = what belongs outside the 802.3 specifications. >=20 > The definition that the task force is converging on is that everything = related to Ethernet, covered by 802.3, that can be expressed in terms of = the 802.3 clause 30 manageability definitions, should be modeled in = 802.3. I.e. broadly everything that is covered by 802.3.1 today. But = any manageability information that cannot be related to clause 30 = definitions should be specified outside of 802.3. Note, where = appropriate, additional clause 30 definitions may be added to fix any = mistakes or glaring gaps. >=20 > To this end, there are a couple of areas between IETF and 802.3 that = don't necessarily look like they are entirely in the right place, in = particular: >=20 > 1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet = related content) some Ethernet specific statistics that would be better = co-located with the Ethernet interface YANG model being defined in = 802.3cp. Hence, the proposal is to subsume the appropriate Ethernet = statistics from the RMON MIB into a single combined reference set = defined in 802.3cp. > 2) The RMON MIB also defines some Ethernet specific statistics that = can't be defined as part of 802.3cf because they don't relate to 802.3 = clause 30 registers, but are still widely supported by vendors, and = should be modeled in YANG. The proposal is that definitions related to = these counters could be added as part of the Ethernet-like module = draft-ietf-netmod-intf-ext-yang-03 = , or = perhaps a related Ethernet module in the same draft. >=20 > 3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced = from RFC 7460), was originally specified in IETF, but ownership later = transferred to 802.3 (via RFC 7448). Whilst working on the Power over = Ethernet YANG model it has become clear that not all of the attributes = defined in the MIB map to the underlying 802.3 clause 30 definitions. = Further, it looks like parts of this YANG model would be better defined = as extensions to the Entity YANG model being defined in NETMOD. The = proposal is that the parts of the Power over Ethernet YANG model = that can be directly related to clause 30 definitions (e.g. = pethPsePortTable) should be defined in 802.3cf, but that the remaining = parts (e.g., pethMainPseObjects ) can hopefully be standardized in IETF. >=20 >=20 > Do you have any comments, or concerns, on the 3 proposals above? >=20 Having sat on some of the meeting with Robert in IEEE, I would agree = that the three proposals is the cleanest approach to splitting the work. = It would have ideal that there was one model each for Ethernet interface = and all the statistics, and one for POE, but ... > Regards, > Rob Wilton > = ______________________= _________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_5887CB5C-9DD9-44C7-9EAC-80FD39F8A88F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Mar 22, 2017, at 8:21 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,

I'm participating in the 802.3 task force (802.3cf) to produce standard YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3 Ethernet Working Group.

As part of my involvement with that group, I want to highlight a couple of issues that arose in that forum that may be of interest to various WGs in IETF.

This email, and accompanying slides, represents my personal views, and do not represent any formal IEEE position.  However, both this email and the accompanying slides have been reviewed in an 802.3cf task force meeting, and there were no objections to the content, or my sending of this email to IETF.

I also raised these issues (with an earlier set of slides) as part of the IETF/IEEE liaison meeting on 31st January, and the consensus was generally supportive of this approach, with the agreed next steps to contact the NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email):


As part of that YANG modelling work, there is an aim to define a clean boundary of what manageability data should be specified within 802.3 and what belongs outside the 802.3 specifications.

The definition that the task force is converging on is that everything related to Ethernet, covered by 802.3, that can be expressed in terms of the 802.3 clause 30 manageability definitions, should be modeled in 802.3.  I.e. broadly everything that is covered by 802.3.1 today.  But any manageability information that cannot be related to clause 30 definitions should be specified outside of 802.3.  Note, where appropriate, additional clause 30 definitions may be added to fix any mistakes or glaring gaps.


To this end, there are a couple of areas between IETF and 802.3 that don't necessarily look like they are entirely in the right place, in particular:

1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related content) some Ethernet specific statistics that would be better co-located with the Ethernet interface YANG model being defined in 802.3cp.  Hence, the proposal is to subsume the appropriate Ethernet statistics from the RMON MIB into a single combined reference set defined in 802.3cp.

2) The RMON MIB also defines some Ethernet specific statistics that can't be defined as part of 802.3cf because they don't relate to 802.3 clause 30 registers, but are still widely supported by vendors, and should be modeled in YANG.  The proposal is that definitions related to these counters could be added as part of the Ethernet-like module draft-ietf-netmod-intf-ext-yang-03, or perhaps a related Ethernet module in the same draft.

3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced from RFC 7460), was originally specified in IETF, but ownership later transferred to 802.3 (via RFC 7448).  Whilst working on the Power over Ethernet YANG model it has become clear that not all of the attributes defined in the MIB map to the underlying 802.3 clause 30 definitions.  Further, it looks like parts of this YANG model would be better defined as extensions to the Entity YANG model being defined in NETMOD.  The proposal is that the parts of the Power over Ethernet YANG model that can be directly related to clause 30 definitions (e.g. pethPsePortTable) should be defined in 802.3cf, but that the remaining parts (e.g., pethMainPseObjects ) can hopefully be standardized in IETF.


Do you have any comments, or concerns, on the 3 proposals above?

Having sat on some of the meeting with Robert in IEEE, I would agree that the three proposals is the cleanest approach to splitting the work. It would have ideal that there was one model each for Ethernet interface and all the statistics, and one for POE, but ...

Regards,
Rob Wilton

<wilton_8023cf_ethernet_interface_statistics_3.pptx>_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--Apple-Mail=_5887CB5C-9DD9-44C7-9EAC-80FD39F8A88F-- From nobody Wed Mar 22 20:52:05 2017 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 186591200C5; Wed, 22 Mar 2017 20:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEowF-o9c3qs; Wed, 22 Mar 2017 20:52:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABD912943D; Wed, 22 Mar 2017 20:51:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJJ83541; Thu, 23 Mar 2017 03:51:56 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 23 Mar 2017 03:51:54 +0000 Received: from DGGEML501-MBX.china.huawei.com ([169.254.1.113]) by DGGEML403-HUB.china.huawei.com ([::1]) with mapi id 14.03.0301.000; Thu, 23 Mar 2017 11:51:49 +0800 From: Fatai Zhang To: Robert Wilton , "netmod@ietf.org" , "ccamp@ietf.org" Thread-Topic: [CCAMP] 802.3 Ethernet YANG (802.3cp) and IETF overlap Thread-Index: AQHSoyAYBWBt1hJkSUO4LYN/Xe3kVaGhxBPg Date: Thu, 23 Mar 2017 03:51:49 +0000 Message-ID: References: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> In-Reply-To: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.162.94] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF8AB4F71F7DGGEML501MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58D3465D.0235, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.113, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a62860596de641a107b26a9b5662162f Archived-At: Subject: [netmod] =?utf-8?b?562U5aSNOiBbQ0NBTVBdIDgwMi4zIEV0aGVybmV0IFlB?= =?utf-8?q?NG_=28802=2E3cp=29_and_IETF_overlap?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 03:52:04 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF8AB4F71F7DGGEML501MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iLA0KDQpUaGFua3MgZm9yIHNoYXJpbmcgdGhlIGluZm9ybWF0aW9uLg0KDQpJIHRoaW5r IHlvdSBhcmUgdGFsa2luZyBhYm91dCB0d28gdHlwZXMgb2YgWWFuZyBtb2RlbHMsIG9uZSBpcyBF dGhlcm5ldCBzcGVjaWZpYyBzdGF0aXN0aWNzLCBhbmQgdGhlIG90aGVyIG9uZSBpcyBQb3dlciBv dmVyIEV0aGVybmV0Lg0KDQpJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIEkgdGhpbmsg eW91ciBwcm9wb3NhbHMgYXJlIHRoYXQgc29tZSBwYXJ0IG9mIGVhY2ggb2YgdGhlbSBzaG91bGQg YmUgZGVmaW5lZCBpbiA4MDIuM2NwIG9yIDgwMi4zY2YsIGFuZCB0aGUgbGVmdCBwYXJ0IG9mIGVh Y2ggb2YgdGhlbSBzaG91bGQgYmUgZGVmaW5lZCBpbiBJRVRGLg0KSSBhbSBhIGxpdHRsZSBjb25j ZXJuZWQgdGhhdCBob3cgcGVvcGxlIGNhbiBkaXN0aW5ndWlzaCBhbmQganVkZ2Ugd2hpY2ggcGFy dCAoZS5nLiwgb2YgRXRoZXJuZXQgc3BlY2lmaWMgc3RhdGlzdGljcyBvciBQb3dlciBvdmVyIEV0 aGVybmV0KSBzaG91bGQgYmUgZGVmaW5lZCBpbiBJRUVFIG9yIElFRlQ/DQpGb3IgZXhhbXBsZSwg cmVnYXJkaW5nIEV0aGVybmV0IHNwZWNpZmljIHN0YXRpc3RpY3MsIGhvdyBwZW9wbGUgY2FuIGV4 YWN0bHkga25vdyB3aGljaCBpbmZvcm1hdGlvbiBjb3VsZCBiZSBiZXR0ZXIgY28tbG9jYXRlZCBp biA4MDIuM2NwIGFuZCB3aGljaCBkb27igJl0ICByZWxhdGUgdG8gODAyLjM/DQpJIHRoaW5rIGRp ZmZlcmVudCBwZW9wbGUgbWlnaHQgaGF2ZSBkaWZmZXJlbnQgdW5kZXJzdGFuZGluZyBhbmQgdGhl biBpdCB3aWxsIGJyaW5nIGNvbmZ1c2lvbiB0byB0aGUgaW5kdXN0cnkuDQoNCkhvdyBhYm91dCBh bGxvdyBJRVRGIGRlZmluZSBZYW5nIG1vZGVscyBmb3IgZXZlcnl0aGluZyBvZiBFdGhlcm5ldCBz cGVjaWZpYyBzdGF0aXN0aWNzIHNpbmNlIFJNT04gTUlCIHdhcyBhbHJlYWR5IGRlZmluZWQgYnkg SUVURiBhbmQgSUVFRSBkZWZpbmUgWWFuZyBtb2RlbHMgZm9yIGV2ZXJ5dGhpbmcgb2YgUG93ZXIg b3ZlciBFdGhlcm5ldCAoc2luY2Ugb3duZXJzaGlwIGFscmVhZHkgdHJhbnNmZXJyZWQgdG8gODAy LjMpPyAgSSBwZXJzb25hbGx5IHRoaW5rIHRoaXMgc2ltcGxlIGFwcHJvYWNoIGNvdWxkIG1ha2Ug b3VyIGxpZmUgZWFzaWVyLCDimLoNCg0KSnVzdCBzb21lIGxvdWQgdGhpbmtpbmfigKYNCg0KDQoN Cg0KVGhhbmtzDQoNCkZhdGFpDQoNCuWPkeS7tuS6ujogQ0NBTVAgW21haWx0bzpjY2FtcC1ib3Vu Y2VzQGlldGYub3JnXSDku6PooaggUm9iZXJ0IFdpbHRvbg0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0 M+aciDIy5pelIDIzOjIxDQrmlLbku7bkuro6IG5ldG1vZEBpZXRmLm9yZzsgY2NhbXBAaWV0Zi5v cmcNCuS4u+mimDogW0NDQU1QXSA4MDIuMyBFdGhlcm5ldCBZQU5HICg4MDIuM2NwKSBhbmQgSUVU RiBvdmVybGFwDQoNCg0KSGksDQoNCkknbSBwYXJ0aWNpcGF0aW5nIGluIHRoZSA4MDIuMyB0YXNr IGZvcmNlICg4MDIuM2NmKSB0byBwcm9kdWNlIHN0YW5kYXJkIFlBTkcgbW9kZWxzIGZvciBFdGhl cm5ldCBpbnRlcmZhY2VzIGFuZCBwcm90b2NvbHMgY292ZXJlZCBieSB0aGUgSUVFRSA4MDIuMyBF dGhlcm5ldCBXb3JraW5nIEdyb3VwLg0KDQpBcyBwYXJ0IG9mIG15IGludm9sdmVtZW50IHdpdGgg dGhhdCBncm91cCwgSSB3YW50IHRvIGhpZ2hsaWdodCBhIGNvdXBsZSBvZiBpc3N1ZXMgdGhhdCBh cm9zZSBpbiB0aGF0IGZvcnVtIHRoYXQgbWF5IGJlIG9mIGludGVyZXN0IHRvIHZhcmlvdXMgV0dz IGluIElFVEYuDQoNClRoaXMgZW1haWwsIGFuZCBhY2NvbXBhbnlpbmcgc2xpZGVzLCByZXByZXNl bnRzIG15IHBlcnNvbmFsIHZpZXdzLCBhbmQgZG8gbm90IHJlcHJlc2VudCBhbnkgZm9ybWFsIElF RUUgcG9zaXRpb24uICBIb3dldmVyLCBib3RoIHRoaXMgZW1haWwgYW5kIHRoZSBhY2NvbXBhbnlp bmcgc2xpZGVzIGhhdmUgYmVlbiByZXZpZXdlZCBpbiBhbiA4MDIuM2NmIHRhc2sgZm9yY2UgbWVl dGluZywgYW5kIHRoZXJlIHdlcmUgbm8gb2JqZWN0aW9ucyB0byB0aGUgY29udGVudCwgb3IgbXkg c2VuZGluZyBvZiB0aGlzIGVtYWlsIHRvIElFVEYuDQoNCkkgYWxzbyByYWlzZWQgdGhlc2UgaXNz dWVzICh3aXRoIGFuIGVhcmxpZXIgc2V0IG9mIHNsaWRlcykgYXMgcGFydCBvZiB0aGUgSUVURi9J RUVFIGxpYWlzb24gbWVldGluZyBvbiAzMXN0IEphbnVhcnksIGFuZCB0aGUgY29uc2Vuc3VzIHdh cyBnZW5lcmFsbHkgc3VwcG9ydGl2ZSBvZiB0aGlzIGFwcHJvYWNoLCB3aXRoIHRoZSBhZ3JlZWQg bmV4dCBzdGVwcyB0byBjb250YWN0IHRoZSBORVRNT0QgYW5kIENDQU1QIGNoYWlycywgd2hpY2gg SSBoYXZlIGRvbmUsIGFuZCB0aGUgV0dzIChoZW5jZSB0aGlzIGVtYWlsKToNCg0KDQoNCkFzIHBh cnQgb2YgdGhhdCBZQU5HIG1vZGVsbGluZyB3b3JrLCB0aGVyZSBpcyBhbiBhaW0gdG8gZGVmaW5l IGEgY2xlYW4gYm91bmRhcnkgb2Ygd2hhdCBtYW5hZ2VhYmlsaXR5IGRhdGEgc2hvdWxkIGJlIHNw ZWNpZmllZCB3aXRoaW4gODAyLjMgYW5kIHdoYXQgYmVsb25ncyBvdXRzaWRlIHRoZSA4MDIuMyBz cGVjaWZpY2F0aW9ucy4NCg0KVGhlIGRlZmluaXRpb24gdGhhdCB0aGUgdGFzayBmb3JjZSBpcyBj b252ZXJnaW5nIG9uIGlzIHRoYXQgZXZlcnl0aGluZyByZWxhdGVkIHRvIEV0aGVybmV0LCBjb3Zl cmVkIGJ5IDgwMi4zLCB0aGF0IGNhbiBiZSBleHByZXNzZWQgaW4gdGVybXMgb2YgdGhlIDgwMi4z IGNsYXVzZSAzMCBtYW5hZ2VhYmlsaXR5IGRlZmluaXRpb25zLCBzaG91bGQgYmUgbW9kZWxlZCBp biA4MDIuMy4gIEkuZS4gYnJvYWRseSBldmVyeXRoaW5nIHRoYXQgaXMgY292ZXJlZCBieSA4MDIu My4xIHRvZGF5LiAgQnV0IGFueSBtYW5hZ2VhYmlsaXR5IGluZm9ybWF0aW9uIHRoYXQgY2Fubm90 IGJlIHJlbGF0ZWQgdG8gY2xhdXNlIDMwIGRlZmluaXRpb25zIHNob3VsZCBiZSBzcGVjaWZpZWQg b3V0c2lkZSBvZiA4MDIuMy4gIE5vdGUsIHdoZXJlIGFwcHJvcHJpYXRlLCBhZGRpdGlvbmFsIGNs YXVzZSAzMCBkZWZpbml0aW9ucyBtYXkgYmUgYWRkZWQgdG8gZml4IGFueSBtaXN0YWtlcyBvciBn bGFyaW5nIGdhcHMuDQoNCg0KDQpUbyB0aGlzIGVuZCwgdGhlcmUgYXJlIGEgY291cGxlIG9mIGFy ZWFzIGJldHdlZW4gSUVURiBhbmQgODAyLjMgdGhhdCBkb24ndCBuZWNlc3NhcmlseSBsb29rIGxp a2UgdGhleSBhcmUgZW50aXJlbHkgaW4gdGhlIHJpZ2h0IHBsYWNlLCBpbiBwYXJ0aWN1bGFyOg0K DQoxKSBUaGUgUk1PTiBNSUIgKFJGQyAyODE5KSBkZWZpbmVzIChhbG9uZyB3aXRoIG90aGVyIG5v bi1FdGhlcm5ldCByZWxhdGVkIGNvbnRlbnQpIHNvbWUgRXRoZXJuZXQgc3BlY2lmaWMgc3RhdGlz dGljcyB0aGF0IHdvdWxkIGJlIGJldHRlciBjby1sb2NhdGVkIHdpdGggdGhlIEV0aGVybmV0IGlu dGVyZmFjZSBZQU5HIG1vZGVsIGJlaW5nIGRlZmluZWQgaW4gODAyLjNjcC4gIEhlbmNlLCB0aGUg cHJvcG9zYWwgaXMgdG8gc3Vic3VtZSB0aGUgYXBwcm9wcmlhdGUgRXRoZXJuZXQgc3RhdGlzdGlj cyBmcm9tIHRoZSBSTU9OIE1JQiBpbnRvIGEgc2luZ2xlIGNvbWJpbmVkIHJlZmVyZW5jZSBzZXQg ZGVmaW5lZCBpbiA4MDIuM2NwLg0KDQoyKSBUaGUgUk1PTiBNSUIgYWxzbyBkZWZpbmVzIHNvbWUg RXRoZXJuZXQgc3BlY2lmaWMgc3RhdGlzdGljcyB0aGF0IGNhbid0IGJlIGRlZmluZWQgYXMgcGFy dCBvZiA4MDIuM2NmIGJlY2F1c2UgdGhleSBkb24ndCByZWxhdGUgdG8gODAyLjMgY2xhdXNlIDMw IHJlZ2lzdGVycywgYnV0IGFyZSBzdGlsbCB3aWRlbHkgc3VwcG9ydGVkIGJ5IHZlbmRvcnMsIGFu ZCBzaG91bGQgYmUgbW9kZWxlZCBpbiBZQU5HLiAgVGhlIHByb3Bvc2FsIGlzIHRoYXQgZGVmaW5p dGlvbnMgcmVsYXRlZCB0byB0aGVzZSBjb3VudGVycyBjb3VsZCBiZSBhZGRlZCBhcyBwYXJ0IG9m IHRoZSBFdGhlcm5ldC1saWtlIG1vZHVsZSBkcmFmdC1pZXRmLW5ldG1vZC1pbnRmLWV4dC15YW5n LTAzPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLWlu dGYtZXh0LXlhbmcvPiwgb3IgcGVyaGFwcyBhIHJlbGF0ZWQgRXRoZXJuZXQgbW9kdWxlIGluIHRo ZSBzYW1lIGRyYWZ0Lg0KDQozKSBUaGUgUG93ZXItRXRoZXJuZXQgTUlCIChkZWZpbmVkIGluIFJG QyAzNjIxLCBidXQgYWxzbyByZWZlcmVuY2VkIGZyb20gUkZDIDc0NjApLCB3YXMgb3JpZ2luYWxs eSBzcGVjaWZpZWQgaW4gSUVURiwgYnV0IG93bmVyc2hpcCBsYXRlciB0cmFuc2ZlcnJlZCB0byA4 MDIuMyAodmlhIFJGQyA3NDQ4KS4gIFdoaWxzdCB3b3JraW5nIG9uIHRoZSBQb3dlciBvdmVyIEV0 aGVybmV0IFlBTkcgbW9kZWwgaXQgaGFzIGJlY29tZSBjbGVhciB0aGF0IG5vdCBhbGwgb2YgdGhl IGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiB0aGUgTUlCIG1hcCB0byB0aGUgdW5kZXJseWluZyA4MDIu MyBjbGF1c2UgMzAgZGVmaW5pdGlvbnMuICBGdXJ0aGVyLCBpdCBsb29rcyBsaWtlIHBhcnRzIG9m IHRoaXMgWUFORyBtb2RlbCB3b3VsZCBiZSBiZXR0ZXIgZGVmaW5lZCBhcyBleHRlbnNpb25zIHRv IHRoZSBFbnRpdHkgWUFORyBtb2RlbCBiZWluZyBkZWZpbmVkIGluIE5FVE1PRC4gIFRoZSBwcm9w b3NhbCBpcyB0aGF0IHRoZSBwYXJ0cyBvZiB0aGUgUG93ZXIgb3ZlciBFdGhlcm5ldCBZQU5HIG1v ZGVsIHRoYXQgY2FuIGJlIGRpcmVjdGx5IHJlbGF0ZWQgdG8gY2xhdXNlIDMwIGRlZmluaXRpb25z IChlLmcuIHBldGhQc2VQb3J0VGFibGUpIHNob3VsZCBiZSBkZWZpbmVkIGluIDgwMi4zY2YsIGJ1 dCB0aGF0IHRoZSByZW1haW5pbmcgcGFydHMgKGUuZy4sIHBldGhNYWluUHNlT2JqZWN0cyApIGNh biBob3BlZnVsbHkgYmUgc3RhbmRhcmRpemVkIGluIElFVEYuDQoNCg0KDQpEbyB5b3UgaGF2ZSBh bnkgY29tbWVudHMsIG9yIGNvbmNlcm5zLCBvbiB0aGUgMyBwcm9wb3NhbHMgYWJvdmU/DQoNClJl Z2FyZHMsDQpSb2IgV2lsdG9uDQo= --_000_F82A4B6D50F9464B8EBA55651F541CF8AB4F71F7DGGEML501MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9 kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWu i+S9kzsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBSb2Is PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3Igc2hhcmluZyB0 aGUgaW5mb3JtYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhp bmsgeW91IGFyZSB0YWxraW5nIGFib3V0IHR3byB0eXBlcyBvZiBZYW5nIG1vZGVscywgb25lIGlz IEV0aGVybmV0IHNwZWNpZmljIHN0YXRpc3RpY3MsIGFuZCB0aGUgb3RoZXIgb25lIGlzIFBvd2Vy IG92ZXIgRXRoZXJuZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIG15 IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgSSB0aGluayB5b3VyIHByb3Bvc2FscyBhcmUgdGhh dCBzb21lIHBhcnQgb2YgZWFjaCBvZiB0aGVtIHNob3VsZCBiZSBkZWZpbmVkIGluIDgwMi4zY3Ag b3IgODAyLjNjZiwgYW5kIHRoZSBsZWZ0DQogcGFydCBvZiBlYWNoIG9mIHRoZW0gc2hvdWxkIGJl IGRlZmluZWQgaW4gSUVURi4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIGFtIGEgbGl0dGxlIGNvbmNlcm5lZCB0aGF0IGhvdyBwZW9wbGUgY2FuIGRpc3Rpbmd1 aXNoIGFuZCBqdWRnZSB3aGljaCBwYXJ0IChlLmcuLCBvZiBFdGhlcm5ldCBzcGVjaWZpYyBzdGF0 aXN0aWNzIG9yIFBvd2VyIG92ZXIgRXRoZXJuZXQpIHNob3VsZA0KIGJlIGRlZmluZWQgaW4gSUVF RSBvciBJRUZUPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZv ciBleGFtcGxlLCByZWdhcmRpbmcgRXRoZXJuZXQgc3BlY2lmaWMgc3RhdGlzdGljcywgaG93IHBl b3BsZSBjYW4gZXhhY3RseSBrbm93IHdoaWNoIGluZm9ybWF0aW9uIGNvdWxkIGJlIGJldHRlciBj by1sb2NhdGVkIGluIDgwMi4zY3AgYW5kIHdoaWNoDQogZG9u4oCZdCAmbmJzcDtyZWxhdGUgdG8g ODAyLjM/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGlu ayBkaWZmZXJlbnQgcGVvcGxlIG1pZ2h0IGhhdmUgZGlmZmVyZW50IHVuZGVyc3RhbmRpbmcgYW5k IHRoZW4gaXQgd2lsbCBicmluZyBjb25mdXNpb24gdG8gdGhlIGluZHVzdHJ5Lg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvdyBhYm91dCBhbGxvdyBJRVRGIGRlZmluZSBZ YW5nIG1vZGVscyBmb3IgZXZlcnl0aGluZyBvZiBFdGhlcm5ldCBzcGVjaWZpYyBzdGF0aXN0aWNz IHNpbmNlIFJNT04gTUlCIHdhcyBhbHJlYWR5IGRlZmluZWQgYnkgSUVURiBhbmQgSUVFRSBkZWZp bmUNCiBZYW5nIG1vZGVscyBmb3IgZXZlcnl0aGluZyBvZiBQb3dlciBvdmVyIEV0aGVybmV0IChz aW5jZSBvd25lcnNoaXAgYWxyZWFkeSB0cmFuc2ZlcnJlZCB0byA4MDIuMyk/ICZuYnNwO0kgcGVy c29uYWxseSB0aGluayB0aGlzIHNpbXBsZSBhcHByb2FjaCBjb3VsZCBtYWtlIG91ciBsaWZlIGVh c2llciwNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SnVzdCBzb21lIGxvdWQgdGhpbmtpbmfigKY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQt YWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1 c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3Rl eHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3Rp Znk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVy LWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3Jh cGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZhdGFp PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjp3aW5kb3d0ZXh0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3 aW5kb3d0ZXh0Ij4gQ0NBTVAgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFu PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPuS7o+ih qCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjp3aW5kb3d0ZXh0Ij5Sb2JlcnQgV2lsdG9uPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPuWPkemAgeaXtumXtDxzcGFuIGxh bmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPiAyMDE3PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVT Ij4zPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yMjwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJF Ti1VUyI+DQogMjM6MjE8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gbmV0bW9kQGlldGYub3JnOyBjY2FtcEBp ZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBbQ0NBTVBdIDgwMi4zIEV0aGVybmV0IFlBTkcgKDgwMi4z Y3ApIGFuZCBJRVRGIG92ZXJsYXA8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkknbSBwYXJ0aWNpcGF0aW5nIGlu IHRoZSA4MDIuMyB0YXNrIGZvcmNlICg4MDIuM2NmKSB0byBwcm9kdWNlIHN0YW5kYXJkIFlBTkcg bW9kZWxzIGZvciBFdGhlcm5ldCBpbnRlcmZhY2VzIGFuZCBwcm90b2NvbHMgY292ZXJlZCBieSB0 aGUgSUVFRSA4MDIuMyBFdGhlcm5ldCBXb3JraW5nIEdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBwYXJ0IG9mIG15IGludm9sdmVtZW50IHdpdGgg dGhhdCBncm91cCwgSSB3YW50IHRvIGhpZ2hsaWdodCBhIGNvdXBsZSBvZiBpc3N1ZXMgdGhhdCBh cm9zZSBpbiB0aGF0IGZvcnVtIHRoYXQgbWF5IGJlIG9mIGludGVyZXN0IHRvIHZhcmlvdXMgV0dz IGluIElFVEYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlRo aXMgZW1haWwsIGFuZCBhY2NvbXBhbnlpbmcgc2xpZGVzLCByZXByZXNlbnRzIG15IHBlcnNvbmFs IHZpZXdzLCBhbmQgZG8gbm90IHJlcHJlc2VudCBhbnkgZm9ybWFsIElFRUUgcG9zaXRpb24uJm5i c3A7IEhvd2V2ZXIsIGJvdGggdGhpcyBlbWFpbCBhbmQgdGhlIGFjY29tcGFueWluZyBzbGlkZXMg aGF2ZSBiZWVuIHJldmlld2VkIGluIGFuIDgwMi4zY2YgdGFzayBmb3JjZSBtZWV0aW5nLCBhbmQg dGhlcmUgd2VyZQ0KIG5vIG9iamVjdGlvbnMgdG8gdGhlIGNvbnRlbnQsIG9yIG15IHNlbmRpbmcg b2YgdGhpcyBlbWFpbCB0byBJRVRGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIj5JIGFsc28gcmFpc2VkIHRoZXNlIGlzc3VlcyAod2l0aCBhbiBlYXJsaWVyIHNl dCBvZiBzbGlkZXMpIGFzIHBhcnQgb2YgdGhlIElFVEYvSUVFRSBsaWFpc29uIG1lZXRpbmcgb24g MzFzdCBKYW51YXJ5LCBhbmQgdGhlIGNvbnNlbnN1cyB3YXMgZ2VuZXJhbGx5IHN1cHBvcnRpdmUg b2YgdGhpcyBhcHByb2FjaCwgd2l0aCB0aGUgYWdyZWVkIG5leHQgc3RlcHMgdG8gY29udGFjdCB0 aGUgTkVUTU9EIGFuZCBDQ0FNUA0KIGNoYWlycywgd2hpY2ggSSBoYXZlIGRvbmUsIGFuZCB0aGUg V0dzIChoZW5jZSB0aGlzIGVtYWlsKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiPkFzIHBhcnQgb2YgdGhhdCBZQU5HIG1vZGVsbGluZyB3b3JrLCB0aGVyZSBpcyBhbiBh aW0gdG8gZGVmaW5lIGEgY2xlYW4gYm91bmRhcnkgb2Ygd2hhdCBtYW5hZ2VhYmlsaXR5IGRhdGEg c2hvdWxkIGJlIHNwZWNpZmllZCB3aXRoaW4gODAyLjMgYW5kIHdoYXQgYmVsb25ncyBvdXRzaWRl IHRoZSA4MDIuMyBzcGVjaWZpY2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIGRlZmluaXRpb24gdGhhdCB0aGUgdGFzayBmb3JjZSBpcyBjb252 ZXJnaW5nIG9uIGlzIHRoYXQgZXZlcnl0aGluZyByZWxhdGVkIHRvIEV0aGVybmV0LCBjb3ZlcmVk IGJ5IDgwMi4zLCB0aGF0IGNhbiBiZSBleHByZXNzZWQgaW4gdGVybXMgb2YgdGhlIDgwMi4zIGNs YXVzZSAzMCBtYW5hZ2VhYmlsaXR5IGRlZmluaXRpb25zLCBzaG91bGQgYmUgbW9kZWxlZCBpbiA4 MDIuMy4mbmJzcDsgSS5lLiBicm9hZGx5IGV2ZXJ5dGhpbmcNCiB0aGF0IGlzIGNvdmVyZWQgYnkg ODAyLjMuMSB0b2RheS4mbmJzcDsgQnV0IGFueSBtYW5hZ2VhYmlsaXR5IGluZm9ybWF0aW9uIHRo YXQgY2Fubm90IGJlIHJlbGF0ZWQgdG8gY2xhdXNlIDMwIGRlZmluaXRpb25zIHNob3VsZCBiZSBz cGVjaWZpZWQgb3V0c2lkZSBvZiA4MDIuMy4mbmJzcDsgTm90ZSwgd2hlcmUgYXBwcm9wcmlhdGUs IGFkZGl0aW9uYWwgY2xhdXNlIDMwIGRlZmluaXRpb25zIG1heSBiZSBhZGRlZCB0byBmaXggYW55 IG1pc3Rha2VzIG9yIGdsYXJpbmcNCiBnYXBzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyI+VG8gdGhpcyBlbmQsIHRoZXJlIGFyZSBhIGNvdXBsZSBvZiBhcmVhcyBiZXR3 ZWVuIElFVEYgYW5kIDgwMi4zIHRoYXQgZG9uJ3QgbmVjZXNzYXJpbHkgbG9vayBsaWtlIHRoZXkg YXJlIGVudGlyZWx5IGluIHRoZSByaWdodCBwbGFjZSwgaW4gcGFydGljdWxhcjo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+MSkgVGhlIFJNT04gTUlCIChSRkMg MjgxOSkgZGVmaW5lcyAoYWxvbmcgd2l0aCBvdGhlciBub24tRXRoZXJuZXQgcmVsYXRlZCBjb250 ZW50KSBzb21lIEV0aGVybmV0IHNwZWNpZmljIHN0YXRpc3RpY3MgdGhhdCB3b3VsZCBiZSBiZXR0 ZXIgY28tbG9jYXRlZCB3aXRoIHRoZSBFdGhlcm5ldCBpbnRlcmZhY2UgWUFORyBtb2RlbCBiZWlu ZyBkZWZpbmVkIGluIDgwMi4zY3AuJm5ic3A7IEhlbmNlLCB0aGUgcHJvcG9zYWwNCiBpcyB0byBz dWJzdW1lIHRoZSBhcHByb3ByaWF0ZSBFdGhlcm5ldCBzdGF0aXN0aWNzIGZyb20gdGhlIFJNT04g TUlCIGludG8gYSBzaW5nbGUgY29tYmluZWQgcmVmZXJlbmNlIHNldCBkZWZpbmVkIGluIDgwMi4z Y3AuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjIpIFRoZSBS TU9OIE1JQiBhbHNvIGRlZmluZXMgc29tZSBFdGhlcm5ldCBzcGVjaWZpYyBzdGF0aXN0aWNzIHRo YXQgY2FuJ3QgYmUgZGVmaW5lZCBhcyBwYXJ0IG9mIDgwMi4zY2YgYmVjYXVzZSB0aGV5IGRvbid0 IHJlbGF0ZSB0byA4MDIuMyBjbGF1c2UgMzAgcmVnaXN0ZXJzLCBidXQgYXJlIHN0aWxsIHdpZGVs eSBzdXBwb3J0ZWQgYnkgdmVuZG9ycywgYW5kIHNob3VsZCBiZSBtb2RlbGVkIGluIFlBTkcuJm5i c3A7DQogVGhlIHByb3Bvc2FsIGlzIHRoYXQgZGVmaW5pdGlvbnMgcmVsYXRlZCB0byB0aGVzZSBj b3VudGVycyBjb3VsZCBiZSBhZGRlZCBhcyBwYXJ0IG9mIHRoZSBFdGhlcm5ldC1saWtlIG1vZHVs ZQ0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1u ZXRtb2QtaW50Zi1leHQteWFuZy8iPjxzcGFuIHN0eWxlPSJjb2xvcjojM0QyMkIzO3RleHQtZGVj b3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLW5ldG1vZC1pbnRmLWV4dC15YW5nLTAzPC9zcGFuPjwv YT4sIG9yIHBlcmhhcHMgYSByZWxhdGVkIEV0aGVybmV0IG1vZHVsZSBpbiB0aGUgc2FtZSBkcmFm dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+MykgVGhlIFBv d2VyLUV0aGVybmV0IE1JQiAoZGVmaW5lZCBpbiBSRkMgMzYyMSwgYnV0IGFsc28gcmVmZXJlbmNl ZCBmcm9tIFJGQyA3NDYwKSwgd2FzIG9yaWdpbmFsbHkgc3BlY2lmaWVkIGluIElFVEYsIGJ1dCBv d25lcnNoaXAgbGF0ZXIgdHJhbnNmZXJyZWQgdG8gODAyLjMgKHZpYSBSRkMgNzQ0OCkuJm5ic3A7 IFdoaWxzdCB3b3JraW5nIG9uIHRoZSBQb3dlciBvdmVyIEV0aGVybmV0IFlBTkcgbW9kZWwgaXQg aGFzDQogYmVjb21lIGNsZWFyIHRoYXQgbm90IGFsbCBvZiB0aGUgYXR0cmlidXRlcyBkZWZpbmVk IGluIHRoZSBNSUIgbWFwIHRvIHRoZSB1bmRlcmx5aW5nIDgwMi4zIGNsYXVzZSAzMCBkZWZpbml0 aW9ucy4mbmJzcDsgRnVydGhlciwgaXQgbG9va3MgbGlrZSBwYXJ0cyBvZiB0aGlzIFlBTkcgbW9k ZWwgd291bGQgYmUgYmV0dGVyIGRlZmluZWQgYXMgZXh0ZW5zaW9ucyB0byB0aGUgRW50aXR5IFlB TkcgbW9kZWwgYmVpbmcgZGVmaW5lZCBpbiBORVRNT0QuJm5ic3A7IFRoZQ0KIHByb3Bvc2FsIGlz IHRoYXQgdGhlIHBhcnRzIG9mIHRoZSBQb3dlciBvdmVyIEV0aGVybmV0IFlBTkcgbW9kZWwgdGhh dCBjYW4gYmUgZGlyZWN0bHkgcmVsYXRlZCB0byBjbGF1c2UgMzAgZGVmaW5pdGlvbnMgKGUuZy4N CjxpPnBldGhQc2VQb3J0VGFibGU8L2k+KSBzaG91bGQgYmUgZGVmaW5lZCBpbiA4MDIuM2NmLCBi dXQgdGhhdCB0aGUgcmVtYWluaW5nIHBhcnRzIChlLmcuLA0KPGk+cGV0aE1haW5Qc2VPYmplY3Rz IDwvaT4pIGNhbiBob3BlZnVsbHkgYmUgc3RhbmRhcmRpemVkIGluIElFVEYuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5EbyB5b3UgaGF2ZSBhbnkgY29tbWVudHMsIG9y IGNvbmNlcm5zLCBvbiB0aGUgMyBwcm9wb3NhbHMgYWJvdmU/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPGJyPg0KUm9iIFdpbHRvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F82A4B6D50F9464B8EBA55651F541CF8AB4F71F7DGGEML501MBXchi_-- From nobody Thu Mar 23 00:56:57 2017 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 DB4DC1317B6; Thu, 23 Mar 2017 00:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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=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 wlZo_syLZ5kr; Thu, 23 Mar 2017 00:56:44 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 05DCC1317C0; Thu, 23 Mar 2017 00:56:44 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id p64so173416844qke.1; Thu, 23 Mar 2017 00:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gJr8Bb6jjp49dGxftBkjCACZhzalQhfdpBRlSCKlL2Q=; b=DqD06Vkd+4j9uK8jzceCglXoGu7EhwjczBKW3cfVTRM24Mns+WOjKFn6+wZ91prURT sgKyLHbCndQcm8Amm9//c21mOrt/hWxrsD1wOhOc6w3THYsBoBnVo7nAV00dRrUcjjkq E2FSNKehvZSSzO0DpxSshOT9JEYpXF6oZR0dEUi0xdnJLhg+GQcpc7U5nmDpVNY1Y6XH FJK2SYVaZmukYlRo67rmslQpMfezGDRgr7q+j+3sJlnf7128vqSBNDOFROIGjwCcV3UX MMMzQ20N2zZzchOMDNcSo6Vq5o+a+QrFoBBOnD4qtNOs3TGd1dpgVi4XbaSVCO/Hai7w eEhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gJr8Bb6jjp49dGxftBkjCACZhzalQhfdpBRlSCKlL2Q=; b=AbATf6cbho77PNcus1UshGZ5539nvOUM1pcTigTQelNvo47UtYRKGEVEwxLMIL2XPx KTxOmZ90bwHoPbJiRR2ikTMaQtO1nqLzXf8Xke0xqwOVFNKBPqe94UIJssB4sqItexRl LICE7u3oAB8qL/zBebkMmYHPrZQGpNHf5mtqaDxXDzPFqzx9fJWN9seyW96AXJS/hulZ mJBaxbEr8BcPwad3g3guLL1MKurhEV633gJlPIns9XrMfjaJNFkxOBJm5vFGyrQKF0VH LT/lSCV5VqExXq7mh0kMfBgFF4vYwIH52hvEjkbjgp8zBLhY5yJBmiC2JQanBMqcXnlD gCoA== X-Gm-Message-State: AFeK/H0UiQhlEMI8EpPSZcPBiCWX545w+g04iUfGe7ut8v9ECKOg7sbgv7/BsxEDVL19LncnzkyHE0WZdtzKAQ== X-Received: by 10.55.140.199 with SMTP id o190mr942139qkd.46.1490255803130; Thu, 23 Mar 2017 00:56:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.41.170 with HTTP; Thu, 23 Mar 2017 00:56:42 -0700 (PDT) In-Reply-To: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> References: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> From: Dan Romascanu Date: Thu, 23 Mar 2017 09:56:42 +0200 Message-ID: To: Robert Wilton Cc: netmod@ietf.org, ccamp@ietf.org Content-Type: multipart/alternative; boundary=001a114f8cfcc52a78054b6137db Archived-At: Subject: Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 07:56:47 -0000 --001a114f8cfcc52a78054b6137db Content-Type: text/plain; charset=UTF-8 Hi, I largely agree with the proposals of the team. I have only one comment / clarification related to the RMON objects which are proposed to be transferred under IEEE 802.3cp. As far as I remember there are some differences between the definitions in the RMON MIB for some of the objects and the Clause 30 definitions. What is the approach that you propose to take? Include in IEEE 802.3cp only those objects that strictly conform to Clause 30 definitions, or modify / add definitions in Clause 30 in order to accommodate all the RMON statistics? If the later approach is to be taken - is IEEE 802.3cp chartered to make changes or add new definitions in Clause 30 of IEEE 802.3? Regards, Dan On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton wrote: > Hi, > > I'm participating in the 802.3 task force (802.3cf) to produce standard > YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3 > Ethernet Working Group. > > As part of my involvement with that group, I want to highlight a couple of > issues that arose in that forum that may be of interest to various WGs in > IETF. > > This email, and accompanying slides, represents my personal views, and do > not represent any formal IEEE position. However, both this email and the > accompanying slides have been reviewed in an 802.3cf task force meeting, > and there were no objections to the content, or my sending of this email to > IETF. > > I also raised these issues (with an earlier set of slides) as part of the > IETF/IEEE liaison meeting on 31st January, and the consensus was generally > supportive of this approach, with the agreed next steps to contact the > NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email): > > > As part of that YANG modelling work, there is an aim to define a clean > boundary of what manageability data should be specified within 802.3 and > what belongs outside the 802.3 specifications. > > The definition that the task force is converging on is that everything > related to Ethernet, covered by 802.3, that can be expressed in terms of > the 802.3 clause 30 manageability definitions, should be modeled in 802.3. > I.e. broadly everything that is covered by 802.3.1 today. But any > manageability information that cannot be related to clause 30 definitions > should be specified outside of 802.3. Note, where appropriate, additional > clause 30 definitions may be added to fix any mistakes or glaring gaps. > > > To this end, there are a couple of areas between IETF and 802.3 that don't > necessarily look like they are entirely in the right place, in particular: > > 1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related > content) some Ethernet specific statistics that would be better co-located > with the Ethernet interface YANG model being defined in 802.3cp. Hence, > the proposal is to subsume the appropriate Ethernet statistics from the > RMON MIB into a single combined reference set defined in 802.3cp. > > 2) The RMON MIB also defines some Ethernet specific statistics that can't > be defined as part of 802.3cf because they don't relate to 802.3 clause 30 > registers, but are still widely supported by vendors, and should be modeled > in YANG. The proposal is that definitions related to these counters could > be added as part of the Ethernet-like module draft-ietf-netmod-intf-ext- > yang-03 > , or > perhaps a related Ethernet module in the same draft. > > 3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced from > RFC 7460), was originally specified in IETF, but ownership later > transferred to 802.3 (via RFC 7448). Whilst working on the Power over > Ethernet YANG model it has become clear that not all of the attributes > defined in the MIB map to the underlying 802.3 clause 30 definitions. > Further, it looks like parts of this YANG model would be better defined as > extensions to the Entity YANG model being defined in NETMOD. The proposal > is that the parts of the Power over Ethernet YANG model that can be > directly related to clause 30 definitions (e.g. *pethPsePortTable*) > should be defined in 802.3cf, but that the remaining parts (e.g., *pethMainPseObjects > *) can hopefully be standardized in IETF. > > > Do you have any comments, or concerns, on the 3 proposals above? > > Regards, > Rob Wilton > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a114f8cfcc52a78054b6137db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I largely agree with = the proposals of the team.

I have only one comment / clarific= ation related to the RMON objects which are proposed to be transferred unde= r IEEE 802.3cp. As far as I remember there are some differences between the= definitions in the RMON MIB for some of the objects and the Clause 30 defi= nitions. What is the approach that you propose to take? Include in IEEE 802= .3cp only those objects that strictly conform to Clause 30 definitions, or = modify / add definitions in Clause 30 in order to accommodate all the RMON = statistics? If the later approach is to be taken - is IEEE 802.3cp chartere= d to make changes or add new definitions in Clause 30 of IEEE 802.3?
Regards,

Dan

<= br>
On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilto= n <rwilton@cisco.com> wrote:
=20 =20 =20

Hi,

I'm participating in the 802.3 task force (802.3cf) to produce standard YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3 Ethernet Working Group.

As part of my involvement with that group, I want to highlight a couple of issues that arose in that forum that may be of interest to various WGs in IETF.

This email, and accompanying slides, represents my personal views, and do not represent any formal IEEE position.=C2=A0 However, both this email and the accompanying slides have been reviewed in an 802.3cf task force meeting, and there were no objections to the content, or my sending of this email to IETF.

I also raised these issues (with an earlier set of slides) as part of the IETF/IEEE liaison meeting on 31st January, and the consensus was generally supportive of this approach, with the agreed next steps to contact the NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email):


As part of that YANG modelling work, there is an aim to define a clean boundary of what manageability data should be specified within 802.3 and what belongs outside the 802.3 specifications.

The definition that the task force is converging on is that everything related to Ethernet, covered by 802.3, that can be expressed in terms of the 802.3 clause 30 manageability definitions, should be modeled in 802.3.=C2=A0 I.e. broadly everythin= g that is covered by 802.3.1 today.=C2=A0 But any manageability information that cannot be related to clause 30 definitions should be specified outside of 802.3.=C2=A0 Note, where appropriate, additional clause 30 definitions may be added to fix any mistakes or glaring gaps.


To this end, there are a couple of areas between IETF and 802.3 that don't necessarily look like they are entirely in the right place, in particular:

1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related content) some Ethernet specific statistics that would be better co-located with the Ethernet interface YANG model being defined in 802.3cp.=C2=A0 Hence, the proposal is to subsume the appropriate Ethernet statistics from the RMON MIB into a single combined reference set defined in 802.3cp.

2) The RMON MIB also defines some Ethernet specific statistics that can't be defined as part of 802.3cf because they don't r= elate to 802.3 clause 30 registers, but are still widely supported by vendors, and should be modeled in YANG.=C2=A0 The proposal is that definitions related to these counters could be added as part of the Ethernet-like module draft-ietf-netmod-intf-= ext-yang-03, or perhaps a related Ethernet module in the same draft.

3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced from RFC 7460), was originally specified in IETF, but ownership later transferred to 802.3 (via RFC 7448).=C2=A0 Whilst working on the Power over Ethernet YANG model it has become clear that not all of the attributes defined in the MIB map to the underlying 802.3 clause 30 definitions.=C2=A0 Further, it looks like parts of this YANG model would be better defined as extensions to the Entity YANG model being defined in NETMOD.=C2=A0 The proposal is that the parts of the Power over Ethernet YANG model that can be directly related to clause 30 definitions (e.g. pethPsePortTable) should be defined in 802.3cf, but that the remaining parts (e.g., pethMainPseObjects ) can hopefully be standardized in IETF.


Do you have any comments, or concerns, on the 3 proposals above?

Regards,
Rob Wilton


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

--001a114f8cfcc52a78054b6137db-- From nobody Thu Mar 23 07:44:01 2017 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 A5EB8129484 for ; Thu, 23 Mar 2017 07:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 i_p1ShvHinXe for ; Thu, 23 Mar 2017 07:43:58 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 55A2F126CE8 for ; Thu, 23 Mar 2017 07:43:58 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-01v.sys.comcast.net with SMTP id r3xHcLMqcO3Qor3y1cmN34; Thu, 23 Mar 2017 14:43:57 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-15v.sys.comcast.net with SMTP id r3xzcwDRMXTPjr3y0cFuBd; Thu, 23 Mar 2017 14:43:57 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2NEhta3009272; Thu, 23 Mar 2017 10:43:55 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2NEhs2V009268; Thu, 23 Mar 2017 10:43:54 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Martin Bjorklund Cc: wivory@Brocade.com, brownn@Brocade.com, netmod@ietf.org In-Reply-To: <20170322.192300.1698563417511122835.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 23 Mar 2017 10:43:54 -0400 Message-ID: <87o9wsqcid.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCYPaSVV3o+JpoZhJil2Dq4zSeR3ecPlSFfIkKF6HCg5/VAiMCumLhWmCpRCGz+eHGef185DD20Wim3Q41k+yVzRzRV0ClHhbvGiT7AcmgfWIxz7vdVc vML+cWpJF3ckmfEld6Ks/FCZFdE0pCQzew6evuyiqWtmIeIkCaMsdXvbmKabmMfkAADYOhg8CRi9oPPlQRT1iFVhT+JjK6XqXmwoZspzLNffwjZMUtE2tlut LsOYc59PAxcdZdBNH1yAeg== Archived-At: Subject: Re: [netmod] Interaction of 'when' and 'default' statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 14:44:00 -0000 Martin Bjorklund writes: > William Ivory wrote: >> Thanks. Can you point me at the part of RFC 6020 that explicitly >> states that 'when' wins over 'default'? > > Section 7.6.1 of RFC 7950 says: > > Note that if the leaf or any of its ancestors has a "when" condition > or "if-feature" expression that evaluates to "false", then the > default value is not in use. Or perhaps more to the point, beware that RFC 6020 does *not* have that paragraph. Dale From nobody Thu Mar 23 07:47:48 2017 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 129B3129702 for ; Thu, 23 Mar 2017 07:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dvngYb5RkB9s for ; Thu, 23 Mar 2017 07:47:45 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 5EDF31294CF for ; Thu, 23 Mar 2017 07:47:45 -0700 (PDT) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2NEh468012048; Thu, 23 Mar 2017 07:47:40 -0700 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 29b9vjbpjn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 23 Mar 2017 07:47:40 -0700 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Mar 2017 08:47:39 -0600 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Mar 2017 15:47:37 +0100 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1210.000; Thu, 23 Mar 2017 15:47:37 +0100 From: William Ivory To: "Dale R. Worley" , Martin Bjorklund CC: Nick Brown , "netmod@ietf.org" Thread-Topic: [netmod] Interaction of 'when' and 'default' statements Thread-Index: AdKjMZ0ImM/a65bBTgeHa23x/dyvH///9jcA///vxyCAABiwAIABVR4A///uvzA= Date: Thu, 23 Mar 2017 14:47:12 +0000 Deferred-Delivery: Thu, 23 Mar 2017 14:47:01 +0000 Message-ID: <773e1d84ad714ef7913565771bd05ea6@EMEAWP-EXMB12.corp.brocade.com> References: <20170322.192300.1698563417511122835.mbj@tail-f.com> <87o9wsqcid.fsf@hobgoblin.ariadne.com> In-Reply-To: <87o9wsqcid.fsf@hobgoblin.ariadne.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.212.188] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-23_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703230125 Archived-At: Subject: Re: [netmod] Interaction of 'when' and 'default' statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 14:47:47 -0000 Yes, I'd noticed that. Does this make the behaviour 'undefined' in YANG 1.0? William -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com] Sent: 23 March 2017 14:44 To: Martin Bjorklund Cc: William Ivory ; Nick Brown ; netmod@ietf.org Subject: Re: [netmod] Interaction of 'when' and 'default' statements Martin Bjorklund writes: > William Ivory wrote: >> Thanks. Can you point me at the part of RFC 6020 that explicitly >> states that 'when' wins over 'default'? > > Section 7.6.1 of RFC 7950 says: > > Note that if the leaf or any of its ancestors has a "when" condition > or "if-feature" expression that evaluates to "false", then the > default value is not in use. Or perhaps more to the point, beware that RFC 6020 does *not* have that paragraph. Dale From nobody Thu Mar 23 07:59:32 2017 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 C67FF120727; Thu, 23 Mar 2017 07:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 XwTZYq8lNYcL; Thu, 23 Mar 2017 07:59:22 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0466712025C; Thu, 23 Mar 2017 07:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29124; q=dns/txt; s=iport; t=1490281161; x=1491490761; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to; bh=UdrcNXMlcTU8EMf7JhFqHWVX8JNRCSLPdjVuRfTgu3I=; b=TDQXAg2ZqgFqM1a1TCTCSggA8mB8dBrh6Lt+VsgJORm4weHUyqTBkOPo P9qWbr+QhAK/KmLPuagisN323A/J3iIUrD6Hqwx2YLWBC6wmDTnzucIyv 7uczt4SkCp/uLlh3e0gb/234Z/bNYh5ziecE9xkS3Xf0v9zYNMbPWeoiu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DsAQCy4dNY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm45gQuBC4Niig9zkD0fkzqCD4IOKoV4AoNUGAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEjCkUHBQsJAhggBwMCAkYRBgEJAwYCAQEViWUIDo0HnVuCJiuKE?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhk6CBQiBWYEJhCYRAQJQglCCXwWJI4Y?= =?us-ascii?q?7jHeGe4tPilmGVotPiBMfOD4+CCQWCBcVhRYgMoExQDWHW4IuAQEB?= X-IronPort-AV: E=Sophos;i="5.36,210,1486425600"; d="scan'208,217";a="693195630" 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; 23 Mar 2017 14:59:18 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2NExIj4014561; Thu, 23 Mar 2017 14:59:18 GMT To: Fatai Zhang , "netmod@ietf.org" , "ccamp@ietf.org" References: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> From: Robert Wilton Message-ID: <89c90309-9870-7cd5-ed7c-d44ac09c646a@cisco.com> Date: Thu, 23 Mar 2017 14:59:17 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7DCE83EAEF471DE8C136BC85" Archived-At: Subject: Re: [netmod] =?utf-8?b?562U5aSNOiBbQ0NBTVBdIDgwMi4zIEV0aGVybmV0IFlB?= =?utf-8?q?NG_=28802=2E3cp=29_and_IETF_overlap?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 14:59:25 -0000 This is a multi-part message in MIME format. --------------7DCE83EAEF471DE8C136BC85 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Fatai, Thanks for the comments/review. Sorry, one correction in my email. The 802.3 YANG project is only 802.3cf. Sometimes I have managed to mangle the name together with the 802.1 YANG project (802.1cp) ... On 23/03/2017 03:51, Fatai Zhang wrote: > > Hi Rob, > > Thanks for sharing the information. > > I think you are talking about two types of Yang models, one is > Ethernet specific statistics, and the other one is Power over Ethernet. > We are trying to convert various MIBs that contain Ethernet related functionality to YANG. Generally the MIBS were defined in IETF. Some of them have been transferred to IEEE for ownership. In the process of converting the content from MIBs to YANG we are taking the opportunity to refine the contents to better meet current requirements. E.g. CSMA/CD collision counters are generally not of relevance on any current Ethernet hardware. > If my understanding is correct, I think your proposals are that some > part of each of them should be defined in 802.3cp or 802.3cf, and the > left part of each of them should be defined in IETF. > Basically, yes, that is correct. > I am a little concerned that how people can distinguish and judge > which part (e.g., of Ethernet specific statistics or Power over > Ethernet) should be defined in IEEE or IEFT? > A lot of the 802.3 Ethernet specification concerns functionality that is baked into the hardware. The 820.3 specification defines (via Clause 30) an internal management API for configuration and retrieval of operational parameters from the hardware. So, the 802.3cf plan is that all of the Ethernet related parts of YANG, or MIB, modules that just represent the values defined in clause 30 are expected to published as part of the 802.3 Ethernet YANG modules. However, 802.3cf do not want their standard YANG models to map to parameters that are not covered by clause 30 (excepting a few more obvious omissions) because that might mean that the YANG module cannot be fully supported by current devices (e.g. if they don't have the actual hardware present to provide the necessary counters). So, the proposal is that some parts of the Ethernet statistics get standardized in IETF instead (probably via NETMOD). Concretely, my desire is for the following bits would be standardized in IETF: 1) Histogram packet statistics (from RMON) (because vendors often support Ethernet frames up to 9k bytes, but the formal 802.3 specification only goes up to 2k). To be added to draft-ietf-netmod-intf-ext-yang-04 2) Some counters that more generally apply to Ethernet-like interfaces (e.g. LAG, IRB, or Pseudo-wire head-end interfaces). This would include the number of packets dropped because they don't match the destination MAC address filter. To be added to draft-ietf-netmod-intf-ext-yang-04. 3) The parts of power management that relate to power supplies rather than Ethernet interfaces. Yan has submitted a draft to NETMOD for this, draft-zhuang-netmod-yang-poe-management-01. I've not reviewed this draft yet, but it may be that it should augment the entity YANG model (draft-ietf-netmod-entity-03). > For example, regarding Ethernet specific statistics, how people can > exactly know which information could be better co-located in 802.3cp > and which don’t relate to 802.3? > > I think different people might have different understanding and then > it will bring confusion to the industry. > Possibly this will be true, but once these base models are standardized, I'm not sure that they are likely to evolve particularly quickly. I would think that if the work is being done in 802.3 then any associated YANG would be standardized there, similarly for IETF. > How about allow IETF define Yang models for everything of Ethernet > specific statistics since RMON MIB was already defined by IETF and > IEEE define Yang models for everything of Power over Ethernet (since > ownership already transferred to 802.3)? I personally think this > simple approach could make our life easier, J > I think that this approach may hit some of the issues above (particularly the relationship to hardware and clause 30 registers). Thanks, Rob > Just some loud thinking… > > Thanks > > Fatai > > *å‘件人:*CCAMP [mailto:ccamp-bounces@ietf.org] *代表 *Robert Wilton > *å‘é€æ—¶é—´:*2017å¹´3月22æ—¥23:21 > *收件人:*netmod@ietf.org; ccamp@ietf.org > *主题:*[CCAMP] 802.3 Ethernet YANG (802.3cp) and IETF overlap > > Hi, > > I'm participating in the 802.3 task force (802.3cf) to produce > standard YANG models for Ethernet interfaces and protocols covered by > the IEEE 802.3 Ethernet Working Group. > > As part of my involvement with that group, I want to highlight a > couple of issues that arose in that forum that may be of interest to > various WGs in IETF. > > This email, and accompanying slides, represents my personal views, and > do not represent any formal IEEE position. However, both this email > and the accompanying slides have been reviewed in an 802.3cf task > force meeting, and there were no objections to the content, or my > sending of this email to IETF. > > I also raised these issues (with an earlier set of slides) as part of > the IETF/IEEE liaison meeting on 31st January, and the consensus was > generally supportive of this approach, with the agreed next steps to > contact the NETMOD and CCAMP chairs, which I have done, and the WGs > (hence this email): > > As part of that YANG modelling work, there is an aim to define a clean > boundary of what manageability data should be specified within 802.3 > and what belongs outside the 802.3 specifications. > > The definition that the task force is converging on is that everything > related to Ethernet, covered by 802.3, that can be expressed in terms > of the 802.3 clause 30 manageability definitions, should be modeled in > 802.3. I.e. broadly everything that is covered by 802.3.1 today. But > any manageability information that cannot be related to clause 30 > definitions should be specified outside of 802.3. Note, where > appropriate, additional clause 30 definitions may be added to fix any > mistakes or glaring gaps. > > To this end, there are a couple of areas between IETF and 802.3 that > don't necessarily look like they are entirely in the right place, in > particular: > > 1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet > related content) some Ethernet specific statistics that would be > better co-located with the Ethernet interface YANG model being defined > in 802.3cp. Hence, the proposal is to subsume the appropriate Ethernet > statistics from the RMON MIB into a single combined reference set > defined in 802.3cp. > > 2) The RMON MIB also defines some Ethernet specific statistics that > can't be defined as part of 802.3cf because they don't relate to 802.3 > clause 30 registers, but are still widely supported by vendors, and > should be modeled in YANG. The proposal is that definitions related > to these counters could be added as part of the Ethernet-like module > draft-ietf-netmod-intf-ext-yang-03 > , > or perhaps a related Ethernet module in the same draft. > > 3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced > from RFC 7460), was originally specified in IETF, but ownership later > transferred to 802.3 (via RFC 7448). Whilst working on the Power over > Ethernet YANG model it has become clear that not all of the attributes > defined in the MIB map to the underlying 802.3 clause 30 definitions. > Further, it looks like parts of this YANG model would be better > defined as extensions to the Entity YANG model being defined in > NETMOD. The proposal is that the parts of the Power over Ethernet > YANG model that can be directly related to clause 30 definitions (e.g. > /pethPsePortTable/) should be defined in 802.3cf, but that the > remaining parts (e.g., /pethMainPseObjects /) can hopefully be > standardized in IETF. > > Do you have any comments, or concerns, on the 3 proposals above? > > Regards, > Rob Wilton > --------------7DCE83EAEF471DE8C136BC85 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Fatai,

Thanks for the comments/review.

Sorry, one correction in my email.  The 802.3 YANG project is only 802.3cf.  Sometimes I have managed to mangle the name together with the 802.1 YANG project (802.1cp) ...


On 23/03/2017 03:51, Fatai Zhang wrote:

Hi Rob,

 

Thanks for sharing the information.

 

I think you are talking about two types of Yang models, one is Ethernet specific statistics, and the other one is Power over Ethernet.

We are trying to convert various MIBs that contain Ethernet related functionality to YANG.  Generally the MIBS were defined in IETF.  Some of them have been transferred to IEEE for ownership.

In the process of converting the content from MIBs to YANG we are taking the opportunity to refine the contents to better meet current requirements.  E.g. CSMA/CD collision counters are generally not of relevance on any current Ethernet hardware.

 

If my understanding is correct, I think your proposals are that some part of each of them should be defined in 802.3cp or 802.3cf, and the left part of each of them should be defined in IETF.

Basically, yes, that is correct.


I am a little concerned that how people can distinguish and judge which part (e.g., of Ethernet specific statistics or Power over Ethernet) should be defined in IEEE or IEFT?

A lot of the 802.3 Ethernet specification concerns functionality that is baked into the hardware.  The 820.3 specification defines (via Clause 30) an internal management API for configuration and retrieval of operational parameters from the hardware.

So, the 802.3cf plan is that all of the Ethernet related parts of YANG, or MIB, modules that just represent the values defined in clause 30 are expected to published as part of the 802.3 Ethernet YANG modules.

However, 802.3cf do not want their standard YANG models to map to parameters that are not covered by clause 30 (excepting a few more obvious omissions) because that might mean that the YANG module cannot be fully supported by current devices (e.g. if they don't have the actual hardware present to provide the necessary counters).

So, the proposal is that some parts of the Ethernet statistics get standardized in IETF instead (probably via NETMOD).

Concretely, my desire is for the following bits would be standardized in IETF:
  1) Histogram packet statistics (from RMON) (because vendors often support Ethernet frames up to 9k bytes, but the formal 802.3 specification only goes up to 2k).  To be added to draft-ietf-netmod-intf-ext-yang-04
  2) Some counters that more generally apply to Ethernet-like interfaces (e.g. LAG, IRB, or Pseudo-wire head-end interfaces).  This would include the number of packets dropped because they don't match the destination MAC address filter.  To be added to draft-ietf-netmod-intf-ext-yang-04.
  3) The parts of power management that relate to power supplies rather than Ethernet interfaces.  Yan has submitted a draft to NETMOD for this, draft-zhuang-netmod-yang-poe-management-01.  I've not reviewed this draft yet, but it may be that it should augment the entity YANG model (draft-ietf-netmod-entity-03).



For example, regarding Ethernet specific statistics, how people can exactly know which information could be better co-located in 802.3cp and which don’t  relate to 802.3?

I think different people might have different understanding and then it will bring confusion to the industry.

Possibly this will be true, but once these base models are standardized, I'm not sure that they are likely to evolve particularly quickly.  I would think that if the work is being done in 802.3 then any associated YANG would be standardized there, similarly for IETF.

 

How about allow IETF define Yang models for everything of Ethernet specific statistics since RMON MIB was already defined by IETF and IEEE define Yang models for everything of Power over Ethernet (since ownership already transferred to 802.3)?  I personally think this simple approach could make our life easier, J

I think that this approach may hit some of the issues above (particularly the relationship to hardware and clause 30 registers).

Thanks,
Rob


 

Just some loud thinking…

 

 

 

 

Thanks

 

Fatai

 

å‘件人: CCAMP [mailto:ccamp-bounces@ietf.org] 代表 Robert Wilton
å‘é€æ—¶é—´: 2017å¹´3月22æ—¥ 23:21
收件人: netmod@ietf.org; ccamp@ietf.org
主题: [CCAMP] 802.3 Ethernet YANG (802.3cp) and IETF overlap

 

Hi,

I'm participating in the 802.3 task force (802.3cf) to produce standard YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3 Ethernet Working Group.

As part of my involvement with that group, I want to highlight a couple of issues that arose in that forum that may be of interest to various WGs in IETF.

This email, and accompanying slides, represents my personal views, and do not represent any formal IEEE position.  However, both this email and the accompanying slides have been reviewed in an 802.3cf task force meeting, and there were no objections to the content, or my sending of this email to IETF.

I also raised these issues (with an earlier set of slides) as part of the IETF/IEEE liaison meeting on 31st January, and the consensus was generally supportive of this approach, with the agreed next steps to contact the NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email):

 

As part of that YANG modelling work, there is an aim to define a clean boundary of what manageability data should be specified within 802.3 and what belongs outside the 802.3 specifications.

The definition that the task force is converging on is that everything related to Ethernet, covered by 802.3, that can be expressed in terms of the 802.3 clause 30 manageability definitions, should be modeled in 802.3.  I.e. broadly everything that is covered by 802.3.1 today.  But any manageability information that cannot be related to clause 30 definitions should be specified outside of 802.3.  Note, where appropriate, additional clause 30 definitions may be added to fix any mistakes or glaring gaps.

 

To this end, there are a couple of areas between IETF and 802.3 that don't necessarily look like they are entirely in the right place, in particular:

1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related content) some Ethernet specific statistics that would be better co-located with the Ethernet interface YANG model being defined in 802.3cp.  Hence, the proposal is to subsume the appropriate Ethernet statistics from the RMON MIB into a single combined reference set defined in 802.3cp.

2) The RMON MIB also defines some Ethernet specific statistics that can't be defined as part of 802.3cf because they don't relate to 802.3 clause 30 registers, but are still widely supported by vendors, and should be modeled in YANG.  The proposal is that definitions related to these counters could be added as part of the Ethernet-like module draft-ietf-netmod-intf-ext-yang-03, or perhaps a related Ethernet module in the same draft.

3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced from RFC 7460), was originally specified in IETF, but ownership later transferred to 802.3 (via RFC 7448).  Whilst working on the Power over Ethernet YANG model it has become clear that not all of the attributes defined in the MIB map to the underlying 802.3 clause 30 definitions.  Further, it looks like parts of this YANG model would be better defined as extensions to the Entity YANG model being defined in NETMOD.  The proposal is that the parts of the Power over Ethernet YANG model that can be directly related to clause 30 definitions (e.g. pethPsePortTable) should be defined in 802.3cf, but that the remaining parts (e.g., pethMainPseObjects ) can hopefully be standardized in IETF.

 

Do you have any comments, or concerns, on the 3 proposals above?

Regards,
Rob Wilton


--------------7DCE83EAEF471DE8C136BC85-- From nobody Thu Mar 23 08:36:17 2017 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 944C81201F2; Thu, 23 Mar 2017 08:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 U4f5CIL6-xd5; Thu, 23 Mar 2017 08:36:12 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9546A126D74; Thu, 23 Mar 2017 08:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37431; q=dns/txt; s=iport; t=1490283371; x=1491492971; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=71M7WSerlwPztRvwd/dbx8v8iiVBKElFmx8KWzBVIxM=; b=JucD7fmO70rkt3gwAhCoBHBhLqMgQ6oEwi0q8FQ2frCNU+2Fd5cLTD7X G8dux3/bl6FRJ1Y5AeDjwD43A883Lz0UR1Aji1YsE4AeVjvadLT3ms/o+ y/vKfpH+uTPhQgaosK5r4CWON37lL9VfJqPHayB9R7sHGYg5sYo0K4ZwG M=; X-Files: 802.3_YANG_Relationships.xlsx : 14474 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DtAQC/6tNY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDKBC4Niig9zkD0fkBmFMIIOHwEKhS5KAoNUGAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEBASFLBAcFCwsOCicDAgICJR8RBgoDBgIBAYl6CA6qW4ImK4oSA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBDgoFhk6CBQiBWYEJhCYRAQIxFYJagl8FiTG?= =?us-ascii?q?TJIN6ggx1gymIJoF7hSqDNIZWi0+IEx84Pj4IJBYIFxVBgkaBWYI5QDWHW4IuA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.36,210,1486425600"; d="xml'?bin'?scan'208,217,72,48?xlsx'208,217,72,48,72,48?rels'208,217,72,48,72,48"; a="653475043" 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; 23 Mar 2017 15:36:09 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2NFa8ZR024605; Thu, 23 Mar 2017 15:36:08 GMT To: Dan Romascanu References: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> Cc: netmod@ietf.org, ccamp@ietf.org From: Robert Wilton Message-ID: Date: Thu, 23 Mar 2017 15:36:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------F08A968F0841B474EFF50C27" Archived-At: Subject: Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:36:15 -0000 This is a multi-part message in MIME format. --------------F08A968F0841B474EFF50C27 Content-Type: multipart/alternative; boundary="------------75A50E9C81C32DB9625B2AC0" --------------75A50E9C81C32DB9625B2AC0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Dan, On 23/03/2017 07:56, Dan Romascanu wrote: > Hi, > > I largely agree with the proposals of the team. > > I have only one comment / clarification related to the RMON objects > which are proposed to be transferred under IEEE 802.3cp. As far as I > remember there are some differences between the definitions in the > RMON MIB for some of the objects and the Clause 30 definitions. Unfortunately, yes there are differences. > What is the approach that you propose to take? I'm trying to rationalize them all together (at least for the parts of the MIB that we want to carry forward into YANG). Please see attached for a spreadsheet that shows the relationship between the proposed 802.3 YANG counters, the existing MIBs (IFMIB, RMON, and ETHERNET-LIKE), and 802.3 clause 30. This doesn't yet cover the counters that I plan on adding to draft-ietf-netmod-intf-ext-yang-04 (Drop due to invalid destination MAC, of RMON style histogram counters). There will also be some text added to the 802.3cf draft that should explain the relationship, possibly some of it may be lifted directly from 802.3.1. > Include in IEEE 802.3cp only those objects that strictly conform to > Clause 30 definitions, or modify / add definitions in Clause 30 in > order to accommodate all the RMON statistics? If the later approach is > to be taken - is IEEE 802.3cp chartered to make changes or add new > definitions in Clause 30 of IEEE 802.3? A bit of both - mostly the former approach, but with a few missing counters hopefully added to clause 30. Specifically, I hoping that the following counters can be added to clause 30: Row 17: In PFC frames (used in ETHERLIKE MIB dot3HCInPFCFrames) Row 18: Out PFC frames (used in ETHERLIKE MIB dot3HCOutPFCFrames) Row 19: Total Octets received (good & bad) (used in RMON MIB etherStatsOctets) Row 25: Frames dropped as being too short. (combined value of two RMON MIB counters (etherStatsUndersizePkts + etherStatsFragments)) I think that in principal there is some support for adding these to clause 30, and the appropriate folks in 802.3 will work out the easiest/best mechanism to achieve this. Thanks, Rob > > Regards, > > Dan > > > On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton > wrote: > > Hi, > > I'm participating in the 802.3 task force (802.3cf) to produce > standard YANG models for Ethernet interfaces and protocols covered > by the IEEE 802.3 Ethernet Working Group. > > As part of my involvement with that group, I want to highlight a > couple of issues that arose in that forum that may be of interest > to various WGs in IETF. > > This email, and accompanying slides, represents my personal views, > and do not represent any formal IEEE position. However, both this > email and the accompanying slides have been reviewed in an 802.3cf > task force meeting, and there were no objections to the content, > or my sending of this email to IETF. > > I also raised these issues (with an earlier set of slides) as part > of the IETF/IEEE liaison meeting on 31st January, and the > consensus was generally supportive of this approach, with the > agreed next steps to contact the NETMOD and CCAMP chairs, which I > have done, and the WGs (hence this email): > > > As part of that YANG modelling work, there is an aim to define a > clean boundary of what manageability data should be specified > within 802.3 and what belongs outside the 802.3 specifications. > > The definition that the task force is converging on is that > everything related to Ethernet, covered by 802.3, that can be > expressed in terms of the 802.3 clause 30 manageability > definitions, should be modeled in 802.3. I.e. broadly everything > that is covered by 802.3.1 today. But any manageability > information that cannot be related to clause 30 definitions should > be specified outside of 802.3. Note, where appropriate, > additional clause 30 definitions may be added to fix any mistakes > or glaring gaps. > > > To this end, there are a couple of areas between IETF and 802.3 > that don't necessarily look like they are entirely in the right > place, in particular: > > 1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet > related content) some Ethernet specific statistics that would be > better co-located with the Ethernet interface YANG model being > defined in 802.3cp. Hence, the proposal is to subsume the > appropriate Ethernet statistics from the RMON MIB into a single > combined reference set defined in 802.3cp. > > 2) The RMON MIB also defines some Ethernet specific statistics > that can't be defined as part of 802.3cf because they don't relate > to 802.3 clause 30 registers, but are still widely supported by > vendors, and should be modeled in YANG. The proposal is that > definitions related to these counters could be added as part of > the Ethernet-like module draft-ietf-netmod-intf-ext-yang-03 > , > or perhaps a related Ethernet module in the same draft. > > 3) The Power-Ethernet MIB (defined in RFC 3621, but also > referenced from RFC 7460), was originally specified in IETF, but > ownership later transferred to 802.3 (via RFC 7448). Whilst > working on the Power over Ethernet YANG model it has become clear > that not all of the attributes defined in the MIB map to the > underlying 802.3 clause 30 definitions. Further, it looks like > parts of this YANG model would be better defined as extensions to > the Entity YANG model being defined in NETMOD. The proposal is > that the parts of the Power over Ethernet YANG model that can be > directly related to clause 30 definitions (e.g. > /pethPsePortTable/) should be defined in 802.3cf, but that the > remaining parts (e.g., ///pethMainPseObjects /) can hopefully be > standardized in IETF. > > > Do you have any comments, or concerns, on the 3 proposals above? > > Regards, > Rob Wilton > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --------------75A50E9C81C32DB9625B2AC0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Dan,


On 23/03/2017 07:56, Dan Romascanu wrote:
Hi,

I largely agree with the proposals of the team.

I have only one comment / clarification related to the RMON objects which are proposed to be transferred under IEEE 802.3cp. As far as I remember there are some differences between the definitions in the RMON MIB for some of the objects and the Clause 30 definitions.
Unfortunately, yes there are differences.

What is the approach that you propose to take?
I'm trying to rationalize them all together (at least for the parts of the MIB that we want to carry forward into YANG).

Please see attached for a spreadsheet that shows the relationship between the proposed 802.3 YANG counters, the existing MIBs (IFMIB, RMON, and ETHERNET-LIKE), and 802.3 clause 30.  This doesn't yet cover the counters that I plan on adding to draft-ietf-netmod-intf-ext-yang-04 (Drop due to invalid destination MAC, of RMON style histogram counters).

There will also be some text added to the 802.3cf draft that should explain the relationship, possibly some of it may be lifted directly from 802.3.1.



Include in IEEE 802.3cp only those objects that strictly conform to Clause 30 definitions, or modify / add definitions in Clause 30 in order to accommodate all the RMON statistics? If the later approach is to be taken - is IEEE 802.3cp chartered to make changes or add new definitions in Clause 30 of IEEE 802.3?

A bit of both - mostly the former approach, but with a few missing counters hopefully added to clause 30. 

Specifically, I hoping that the following counters can be added to clause 30:
 Row 17: In PFC frames (used in  ETHERLIKE MIB dot3HCInPFCFrames)
 Row 18: Out PFC frames (used in ETHERLIKE MIB dot3HCOutPFCFrames)
 Row 19: Total Octets received (good & bad) (used in RMON MIB etherStatsOctets)
 Row 25: Frames dropped as being too short. (combined value of two RMON MIB counters (etherStatsUndersizePkts + etherStatsFragments))

I think that in principal there is some support for adding these to clause 30, and the appropriate folks in 802.3 will work out the easiest/best mechanism to achieve this.

Thanks,
Rob



Regards,

Dan


On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,

I'm participating in the 802.3 task force (802.3cf) to produce standard YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3 Ethernet Working Group.

As part of my involvement with that group, I want to highlight a couple of issues that arose in that forum that may be of interest to various WGs in IETF.

This email, and accompanying slides, represents my personal views, and do not represent any formal IEEE position.  However, both this email and the accompanying slides have been reviewed in an 802.3cf task force meeting, and there were no objections to the content, or my sending of this email to IETF.

I also raised these issues (with an earlier set of slides) as part of the IETF/IEEE liaison meeting on 31st January, and the consensus was generally supportive of this approach, with the agreed next steps to contact the NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email):


As part of that YANG modelling work, there is an aim to define a clean boundary of what manageability data should be specified within 802.3 and what belongs outside the 802.3 specifications.

The definition that the task force is converging on is that everything related to Ethernet, covered by 802.3, that can be expressed in terms of the 802.3 clause 30 manageability definitions, should be modeled in 802.3.  I.e. broadly everything that is covered by 802.3.1 today.  But any manageability information that cannot be related to clause 30 definitions should be specified outside of 802.3.  Note, where appropriate, additional clause 30 definitions may be added to fix any mistakes or glaring gaps.


To this end, there are a couple of areas between IETF and 802.3 that don't necessarily look like they are entirely in the right place, in particular:

1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related content) some Ethernet specific statistics that would be better co-located with the Ethernet interface YANG model being defined in 802.3cp.  Hence, the proposal is to subsume the appropriate Ethernet statistics from the RMON MIB into a single combined reference set defined in 802.3cp.

2) The RMON MIB also defines some Ethernet specific statistics that can't be defined as part of 802.3cf because they don't relate to 802.3 clause 30 registers, but are still widely supported by vendors, and should be modeled in YANG.  The proposal is that definitions related to these counters could be added as part of the Ethernet-like module draft-ietf-netmod-intf-ext-yang-03, or perhaps a related Ethernet module in the same draft.

3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced from RFC 7460), was originally specified in IETF, but ownership later transferred to 802.3 (via RFC 7448).  Whilst working on the Power over Ethernet YANG model it has become clear that not all of the attributes defined in the MIB map to the underlying 802.3 clause 30 definitions.  Further, it looks like parts of this YANG model would be better defined as extensions to the Entity YANG model being defined in NETMOD.  The proposal is that the parts of the Power over Ethernet YANG model that can be directly related to clause 30 definitions (e.g. pethPsePortTable) should be defined in 802.3cf, but that the remaining parts (e.g., pethMainPseObjects ) can hopefully be standardized in IETF.


Do you have any comments, or concerns, on the 3 proposals above?

Regards,
Rob Wilton


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



--------------75A50E9C81C32DB9625B2AC0-- --------------F08A968F0841B474EFF50C27 Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="802.3_YANG_Relationships.xlsx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="802.3_YANG_Relationships.xlsx" UEsDBBQABgAIAAAAIQBBN4LPbgEAAAQFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsVMluwjAQvVfqP0S+Vomhh6qqCBy6HFsk 6AeYeJJYJLblGSj8fSdmUVWxCMElUWzPWybzPBit2iZZQkDjbC76WU8kYAunja1y8T39SJ9F gqSsVo2zkIs1oBgN7+8G07UHTLjaYi5qIv8iJRY1tAoz58HyTulCq4g/QyW9KuaqAvnY6z3J wlkCSyl1GGI4eINSLRpK3le8vFEyM1Ykr5tzHVUulPeNKRSxULm0+h9J6srSFKBdsWgZOkMf QGmsAahtMh8MM4YJELExFPIgZ4AGLyPdusq4MgrD2nh8YOtHGLqd4662dV/8O4LRkIxVoE/V sne5auSPC/OZc/PsNMilrYktylpl7E73Cf54GGV89W8spPMXgc/oIJ4xkPF5vYQIc4YQad0A 3rrtEfQcc60C6Anx9FY3F/AX+5QOjtQ4OI+c2gCXd2EXka469QwEgQzsQ3Jo2PaMHPmr2w7d naJBH+CW8Q4b/gIAAP//AwBQSwMEFAAGAAgAAAAhALVVMCP0AAAATAIAAAsACAJfcmVscy8u cmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACskk1PwzAMhu9I/IfI99Xd kBBCS3dBSLshVH6ASdwPtY2jJBvdvyccEFQagwNHf71+/Mrb3TyN6sgh9uI0rIsSFDsjtnet hpf6cXUHKiZylkZxrOHEEXbV9dX2mUdKeSh2vY8qq7iooUvJ3yNG0/FEsRDPLlcaCROlHIYW PZmBWsZNWd5i+K4B1UJT7a2GsLc3oOqTz5t/15am6Q0/iDlM7NKZFchzYmfZrnzIbCH1+RpV U2g5abBinnI6InlfZGzA80SbvxP9fC1OnMhSIjQS+DLPR8cloPV/WrQ08cudecQ3CcOryPDJ gosfqN4BAAD//wMAUEsDBBQABgAIAAAAIQCBPpSX8wAAALoCAAAaAAgBeGwvX3JlbHMvd29y a2Jvb2sueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACsUk1LxDAQvQv+hzB3m3YVEdl0LyLsVesPCMm0KdsmITN+9N8bKrpdWNZLLwNv hnnvzcd29zUO4gMT9cErqIoSBHoTbO87BW/N880DCGLtrR6CRwUTEuzq66vtCw6acxO5PpLI LJ4UOOb4KCUZh6OmIkT0udKGNGrOMHUyanPQHcpNWd7LtOSA+oRT7K2CtLe3IJopZuX/uUPb 9gafgnkf0fMZCUk8DXkA0ejUISv4wUX2CPK8/GZNec5rwaP6DOUcq0seqjU9fIZ0IIfIRx9/ KZJz5aKZu1Xv4XRC+8opv9vyLMv072bkycfV3wAAAP//AwBQSwMEFAAGAAgAAAAhANqnnk49 AgAAngQAAA8AAAB4bC93b3JrYm9vay54bWysVE2PmzAQvVfqf7B8T/gIZLMIWG0SqkaqqtU2 u7nk4hgTrBib2qZJtOp/7wBLmzaXrdoLM7aH55n3ZhzfnSqBvjFtuJIJ9sYuRkxSlXO5T/DT +sNohpGxROZEKMkSfGYG36Xv38VHpQ87pQ4IAKRJcGltHTmOoSWriBmrmkk4KZSuiIWl3jum 1ozkpmTMVsLxXXfqVIRL3CNE+i0Yqig4ZUtFm4pJ24NoJoiF9E3JazOgVfQtcBXRh6YeUVXV ALHjgttzB4pRRaPVXipNdgLKPnnhgAzuFXTFqVZGFXYMUE6f5FW9nut4Xl9yGhdcsOeedkTq +jOp2lsERoIYm+XcsjzBU1iqI/ttQzf1vOECTr0g8F3spD+leNAoZwVphF2DCAM8BIYT3/fb SCjqXlimJbFsoaQFDl/Z/1e+OuxFqUAd9Mi+NlwzaIqWtjSGL6ER2ZkHYkvUaJHgRbR9MlD+ Vh+5sEpuB0nNdgONhfJXhc12lWXZ9oJ7ci3sX7BPaEuDAzz0ufb+n5ykcdvZz5wdzS922yU6 bbjM1THBMCfnC//YbW94bkvg2/cDOO/3PjK+L22Cw6kbdHdfQHezAFd0FsmuB7608+HB0LV2 1cqMkY44OHqVex3C8BslgoLmrekCQz/0ugh2sp+MTWOwQDdP8IsXuPc37m0wcrNJOApmt/5o Fkz80SJY+ll4ky2zefj9/3Y4qB4Nj0SbZUm0XWtCD/C0PLJiTgx0fF8Q5AlCDFk7w1/pDwAA AP//AwBQSwMEFAAGAAgAAAAhAFn1rAd/CAAARiIAABQAAAB4bC9zaGFyZWRTdHJpbmdzLnht bMxa23LbOBJ9T1X+AaOHWWciSr7UZLMZWykPLW+08S2WXJN9hEhI4gYEGAJ04vmR+aD9sekG SEomQErObqWmKuWKgQbQ6Mvp06CP335NOblnuUqkOOkdDPZ7hIlIxolYnvTuZufB6x5RmoqY cinYSe+Bqd7b0fNnx0ppAmuFOumttM7eDIcqWrGUqoHMmICZhcxTquHXfDlUWc5orFaM6ZQP D/f3Xw1TmogeiWQh9Env8BWcW4jkc8FCO3Lw88+90bFKRsd69O/Tq38SM87y46EeHQ9x3M4l Isg+aRVktFCsOSkL3TFbL11E7QvdOVimpaY8kJFmWnkUstOolmeS5bnMg0UEKncJFCJGp/zO usWkcV2LlLHbpYwL7ljGTEVSaPCCx6iMsdf7hwHTK5YLpoNEaJYvaOTsU0+oAKJEs2E9MKwW DxdcfgnwrFzyofHTEGUTpZPIY6HypJ03XET/63Y5TZlRv0UlphdrCyiyd3sekr8fHh69cN3b qrwnElrjBxIhosqGrmfdPJc07hJICw6m7dghTlRE87g1PH0Thfgk5BfItlxq6QhgpvnvgzNd F8L57huhRPeVUKLtTjhncu6bQi1bPXRFhrBbB+ohnUvu8RXPkkDnVKhEA8D67GokktSLXVtW 49Xalu+SmCmNou7bGWg1YqX72+DXyLCvmsFNpWiFUxALWqWSVtQJOFvS6OEJ6bYGn0ZyDyOV 0iCK25AZYOczCzRTuvUSkeQ8wWsGCqqki6111VkLmvDNOkRjtoAgZY5anr3Y14gpldx7I6Y+ UgUc4Nh3B5sMAQBAnrA8UOAyR26t+QowUS7BiM2tQpmmTDglDjnBG5VBqTjpQdFXLL9nvdH4 c5HcUw7y5HLyK7mneULnnO2pF33S3HhyjiLJYiLuEMNuPFVyLfJrhYXdYpcVInaLnbXg4vq8 MVZvJ403VLYoeeMFyUrsutDXXu6wIbD17rDJTpcHuZ1uD3Lbrg8i/vvfXl5fGceatJtCcVf+ C3oEfR6pxfbWG95VhAgXkJdkPXOe06UJRacej2fvxrcXk/djo1ws9dG7cCJuzkNYkjLHjT5x uPOT5CdiXKHgkw75hlXGzrcsYoAFFzeTyyTKpWJAtGLgKIkg1f+1JK9IPMhIIpQGGk7kgqQb wjuZzRw2w0qWJvq7n2YO9pdQn9MalulYDWTeEnKsTKZmCmD2PmZe84hgq2irSqc8WQoMVX8a ta47D6ctiYdlA/o1pt4QCx4nBNnp4etXR31Sp1E1ePCPPnl8yAmZjMdjAmR/cDQ4aELxlSRx krNIE1YDeP/5M8UYxFJpuLZOxr0MZB42aTYtyJDU+bgebSrgboL56Nnl8fD2bULbjkCNsYB9 nUHPy1StVcv89o1N6E0/jGfAIHb1sl1juERYcYtdwcOsNQAP9OLbVp+V3KPMbuAWHqbqesKc PK7ISH30DqhqVl4APXnyotCSlilyli2laKN0XJdNslM5/kXnc+iygYS418MWVRkvzKS8kGKp hjZg3Ykdo2KCTTTAyyWNKiC1d6ijzhimVezpx5TFYcspj6R2jXDT8Pg2nm7MNDbzc0MPJwhv QwOVdv+md/bQD8YLDTwFVlBP1ZD5AqxrVrwLO9aUkxurdsEQzmdIY9sZrJ8FDejN6d10fHka hjrnNtOriNBuD+ATL33m9AtrNCchR5wkR/skpYIuGdT9+X8Ay5vaDuidUEWWyRzOLnGwbfsB 3cwIfwYO6HQXKBvQHVFrrzw0XLHo0xQKEda7MvJekgFtBIHDZqzK6kIqfVawmYT8Ast/BBpj Nmmawy9+G937pTfC/azI4eIlRDnbtnCnptydSDS8iorySZbkWHk9jSHd2K+D39A1P9xNapNF OncYf5yNr6aT66tHodsWLNQv3hHpV1IT6IThSTIGgkGiKoLfOpp0V4/Sh78lelUVN/C3v7CV sqdzE/8mQj5OsTA5hYxurz50SwWmncyg5CLEPLFBC94np+FFn8icfJBTEucyc3RCi9Es4/Dc B0Dk2Okc1i4KzklcAD342idbkgEQlIoHskqW8PBLOLtnnNj3gsHzZ7jZivJFvRm4iMaxoeUE opZyJcFtES+QSe09vivubJHOY2mcfOxRHHHN7eQ22OcJ5mlG0RlYNINQiwtGoEkqn7hq8zfF r+ADiDuG2QrfMCDzMWThwZwo6C1JxuEJpA/1iCnxNw0QrKNVc7Gn8nW29B75zta+hFh8RbGm rzL1+r1bBOqTt4kC5bMexkhZmEbaxOaGJefQZOIMGgWCpuqrCMCGDafm8eWnGJ/Ff2gOzvDj CxFFCtQNW9lSBWhTsBGGKme9UD+Akr2llDHEdUxAL7c82Bq9gUrX7yH69g5ek5+qkH006exw A89cBbhcr6iGH4mCLBExhxzAturgQ6Uh5CkEHLx8acadt0xq1Vh7qNThv39USqynGhrk8I3M T61mqAyEJ4frbyRnnd/0AUxY5nf5Dgeb4b8b+DEfwke23+GxjsOHwYMe/AaYBO6EGE/hdc+M 5OfQSFmRkPJknicotwDX8wc7fIgD5tMgswMQFTLHwaE5RY9+5PoX40Qg2tMVwPCPS/0LEYBs UQFvokLDVr6qYAMDFK0/B6IlRuum1fKdASEhFWTOSER5VOCzKJgDAaoZ6WDyp3GN9YKyR6ho Sa3ad7alPwwIWrhmbsbEVlE0tKPqd3B5i5p1iWhwtYp8lXHf9Lh/t2mREvw6Sjr54/NnLoMk L82oy3TB3X8tx3b51VX1e+TyN7hQj8qkU+3lqfoM0qwF/49a1CeqmCumsZa01KFKwUd1wGET TAFRByKB5cl+Cy3ZEJbBqiQ6r87+6EVe52XCxPleguD2hSETKytFBaM2xx1O6LACbIWw9dtO CjySQ/g7kNGfAAAA//8DAFBLAwQUAAYACAAAACEAO20yS8EAAABCAQAAIwAAAHhsL3dvcmtz aGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzhI/BisIwFEX3A/5DeHuT1oUMQ1M3IrhV5wNi +toG25eQ9xT9e7McZcDl5XDP5Tab+zypG2YOkSzUugKF5GMXaLDwe9otv0GxOOrcFAktPJBh 0y6+mgNOTkqJx5BYFQuxhVEk/RjDfsTZsY4JqZA+5tlJiXkwyfmLG9Csqmpt8l8HtC9Ote8s 5H1Xgzo9Uln+7I59Hzxuo7/OSPLPhEk5kGA+okg5yEXt8oBiQet39p5rfQ4Epm3My/P2CQAA //8DAFBLAwQUAAYACAAAACEAi4JuWJMGAACOGgAAEwAAAHhsL3RoZW1lL3RoZW1lMS54bWzs Wc+LGzcUvhf6Pwxzd/xrZmwv8QZ7bGfb7CYh66TkqLVlj7KakRnJuzEhUJJjoVCall4KvfVQ 2gYS6CX9a7ZNaVPIv9AnzdgjreVumm4gLVnDMqP59PTpvTffkzQXL92NqXOEU05Y0narFyqu g5MRG5Nk2nZvDgelputwgZIxoizBbXeBuXtp+/33LqItEeEYO9A/4Vuo7UZCzLbKZT6CZsQv sBlO4NmEpTEScJtOy+MUHYPdmJZrlUpQjhFJXCdBMZi9NpmQEXaG0qS7vTTep3CbCC4bRjTd l6ax0UNhx4dVieALHtLUOUK07cI4Y3Y8xHeF61DEBTxouxX155a3L5bRVt6Jig19tX4D9Zf3 yzuMD2tqzHR6sBrU83wv6KzsKwAV67h+ox/0g5U9BUCjEcw046Lb9Lutbs/PsRoou7TY7jV6 9aqB1+zX1zh3fPkz8AqU2ffW8INBCF408AqU4X2LTxq10DPwCpThgzV8o9LpeQ0Dr0ARJcnh GrriB/VwOdsVZMLojhXe8r1Bo5YbL1CQDavskkNMWCI25VqM7rB0AAAJpEiQxBGLGZ6gEWRx iCg5SImzS6YRJN4MJYxDc6VWGVTq8F/+PHWlPIK2MNJ6S17AhK81ST4OH6VkJtruh2DV1SAv n33/8tkT5+WzxycPnp48+Onk4cOTBz9mtoyOOyiZ6h1ffPvZn19/7Pzx5JsXj76w47mO//WH T375+XM7ECZbeOH5l49/e/r4+Vef/v7dIwu8k6IDHT4kMebOVXzs3GAxzE15wWSOD9J/1mMY IWL0QBHYtpjui8gAXl0gasN1sem8WykIjA14eX7H4LofpXNBLCNfiWIDuMcY7bLU6oArcizN w8N5MrUPns513A2EjmxjhygxQtufz0BZic1kGGGD5nWKEoGmOMHCkc/YIcaW2d0mxPDrHhml jLOJcG4Tp4uI1SVDcmAkUtFph8QQl4WNIITa8M3eLafLqG3WPXxkIuGFQNRCfoip4cbLaC5Q bDM5RDHVHb6LRGQjub9IRzquzwVEeoopc/pjzLmtz7UU5qsF/QqIiz3se3QRm8hUkEObzV3E mI7sscMwQvHMypkkkY79gB9CiiLnOhM2+B4z3xB5D3FAycZw3yLYCPfZQnATdFWnVCSIfDJP LbG8jJn5Pi7oBGGlMiD7hprHJDlT2k+Juv9O1LOqdFrUOymxvlo7p6R8E+4/KOA9NE+uY3hn 1gvYO/1+p9/u/16/N73L56/ahVCDhherdbV2jzcu3SeE0n2xoHiXq9U7h/I0HkCj2laoveVq KzeL4DLfKBi4aYpUHydl4iMiov0IzWCJX1Ub0SnPTU+5M2McVv6qWW2J8Snbav8wj/fYONux Vqtyd5qJB0eiaK/4q3bYbYgMHTSKXdjKvNrXTtVueUlA9v0nJLTBTBJ1C4nGshGi8Hck1MzO hUXLwqIpzS9DtYziyhVAbRUVWD85sOpqu76XnQTApgpRPJZxyg4FltGVwTnXSG9yJtUzABYT ywwoIt2SXDdOT84uS7VXiLRBQks3k4SWhhEa4zw79aOT84x1qwipQU+6Yvk2FDQazTcRayki p7SBJrpS0MQ5brtB3YfTsRGatd0J7PzhMp5B7nC57kV0CsdnI5FmL/zrKMss5aKHeJQ5XIlO pgYxETh1KInbrpz+KhtoojREcavWQBDeWnItkJW3jRwE3QwynkzwSOhh11qkp7NbUPhMK6xP VffXB8uebA7h3o/Gx84Bnac3EKSY36hKB44JhwOgaubNMYETzZWQFfl3qjDlsqsfKaocytoR nUUoryi6mGdwJaIrOupu5QPtLp8zOHTdhQdTWWD/ddU9u1RLz2miWdRMQ1Vk1bSL6Zsr8hqr oogarDLpVtsGXmhda6l1kKjWKnFG1X2FgqBRKwYzqEnG6zIsNTtvNamd44JA80SwwW+rGmH1 xOtWfuh3OmtlgViuK1Xiq08f+tcJdnAHxKMH58BzKrgKJXx7SBEs+rKT5Ew24BW5K/I1Ilw5 85S03XsVv+OFNT8sVZp+v+TVvUqp6XfqpY7v16t9v1rpdWv3obCIKK762WeXAZxH0UX+8UW1 r32AiZdHbhdGLC4z9YGlrIirDzDV2uYPMA4B0bkX1AateqsblFr1zqDk9brNUisMuqVeEDZ6 g17oN1uD+65zpMBepx56Qb9ZCqphWPKCiqTfbJUaXq3W8RqdZt/r3M+XMTDzTD5yX4B7Fa/t vwAAAP//AwBQSwMEFAAGAAgAAAAhAEc4U/FmAwAAyA4AAA0AAAB4bC9zdHlsZXMueG1sxFdb b9owFH6ftP8Q+T3NhYQBSlKV0kiVtmlSmbRXkzhg1ZcoMS1s2n/fcW6ka+kV2hewT+zvfD43 HwenG86MG1KUVIoQOSc2MohIZErFMkQ/57E5QkapsEgxk4KEaEtKdBp9/hSUasvI1YoQZQCE KEO0UiqfWFaZrAjH5YnMiYAvmSw4VjAtllaZFwSnpd7EmeXa9tDimApUI0x48hwQjovrdW4m kudY0QVlVG0rLGTwZHK5FLLACwZUN46Hkxa7mtyD5zQpZCkzdQJwlswympD7LMfW2AKkKMik UKWRyLVQIfIBWmuYXAt5K2L9CQzYrIqC8rdxgxlIHGRFQSKZLAwFlgFilURgTuoV55jRRUH1 sgxzyra12NWCypjNOk7haFpoaR41myhY6FXvpKvTYx/3TK2e8fuoGR1LTeWoEjxFGevixtUh AoIogPhVpBAxTIxmPN/mECACUq12dLXuidXLAm8d1+9tsCqFEBuySCG124jVmmtRFDCSKYic gi5X+l/JHH4XUinIgyhIKV5KgZkOtnbHM3ZCpYCiECK1gqRug56KlGxIGqKhV1GslTyso1EG JksIY1ca7VfW8dfJtckMseYxV5eACMVKp0I7BGM1w5prPdFn6KPV2H3Y0atwjU3WKdjHygWC D7Pqdhs4z9lWl4+mMOzDGhwQyzsglnbCoc7o7MECeWvtu/aqZ9Mqzp+w3z6eh8De5+dj8obz 3LXJs6zw4oh8gYXf7L1a1xmjS8FJnRBRALdjPTVuC5zPyaZNFGuTvaYePBpJR9X97Gj4CDu8 r9V3sXrAs+6Lv3uZ0lbbD4k3qJW6Uv2fVx9vB92HHIhZdeHCFdu7x+/c4t19bOg2OETf9SOB 9QraYk2ZouKBGxww082uJ6g6UaUb/qpb6LSAz1OS4TVT8+5jiHbjbySlaw7VsFn1g95IVUGE aDf+qtsjZ6j7Fqg7X0vouuHfWBc0RH8upl/Gs4vYNUf2dGR6A+KbY386M33vfDqbxWPbtc// 9t4fb3h9VK8kKHaONykZvFGK5rAN+audLES9SU2/6rqAdp/72B3aZ75jm/HAdkxviEfmaDjw zdh33NnQm174sd/j7r+Ou2NbjlM/8TR5f6IoJ4yK1leth/pScBJMHzmE1XrC2j1Bo38AAAD/ /wMAUEsDBBQABgAIAAAAIQBtxK6lWAoAAOQ4AAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEu eG1srFvbbuM4En0fYP/B0PvYoi6+BHEGkyiGG5gZLLb38qzYSiK0bXklpdM9Xz/Fm0UWS5Tc mZc4to+OWIelqiPSuv3l2/Ew+VrUTVmd1gGbhsGkOO2qfXl6WQf/+ffm52Uwadr8tM8P1alY B9+LJvjl7h8/3b5X9ZfmtSjaCTCcmnXw2rbnm9ms2b0Wx7yZVufiBN88V/Uxb+Ft/TJrznWR 78VBx8MsCsP57JiXp0Ay3NRjOKrn53JXZNXu7VicWklSF4e8hfE3r+W50WzH3Ri6Y15/eTv/ vKuOZ6B4Kg9l+12QBpPj7ubTy6mq86cDxP2NJflOc4s3Dv2x3NVVUz23U6CbyYG6Ma9mqxkw 3d3uS4iAyz6pi+d18Cu72abzYHZ3KwT6b1m8N8b/kzZ/+lwcil1b7GGegklbnX8rntuH4nDg B8O8/VlVx8+7nI92Yb79g08BgPiHfNaequoLp/8ERCEMpBG0fCD5ri2/FpIyiwDe/F+Mjf8P A5tdRmb+r0e5ETP9z3qyL57zt0P7r+p9W5Qvry0MN5kmoB2X8Gb/PSuaHcwdnHwac9pddQAO +Ds5ljwHQfr8m3h9L/ft6zqIVtPFYhEn8SINJru3pq2O/5PfMHW8PDJSR8KrOjJNxh0ZqyPh VZ8zNo5s2u9cVQZfe04PIYqBw6s+/WrKwpUY9jgKiE9QwKuiiNPpfJ6E8wg+GscxVxzwqjiS xTSOozBmnMQNYCYnQExulrf53W1dvU/gaoSZaM45v7bZDbDB6+V4OdkCQk4rzCdn+JVTiMNg uhvIta93LLydfYX82SnIPQFhNuRBQniOX2gQS0ZA0simeSQwLETn2rjDSTvIDJS5yANphuSB mZfyGvLw/I+WUyijXqE42ToAgk6oORJKQvilf9FygYRSEAuztDEZgVkhzCPFk3RyWjLARTFC Bm/wnGIgeAnxBq8gFmaFgicwaYzShOKJUb5tiCHHPXkCk/pRgTjFgEAS4hVIQUxMhK8jApMm SCACwxyBiCH3CcRLm11nqAvJm0GcYkAgCfEKpCCWQKg+ZAQmTZFABMYViBhyn0C8+H5QIFm/ vfVFQrwCKYglEKqyGYFJUSl7JDDQnGwVNySoq3hWEVqMrsXLea8X0U2Lkw0kk4R4tVIQSytU ajICk6Ka/khgWIK1IkHd2SytuKP/YDZxigGFJMSrkIJYCqFakxGYFHcrAsMiBNqQoK49WAqt /s7OzskGtJIQr1YKYmmFkiAjMClqgI8EhiW4uZGgnu7GXdlH00lwDGikMF6RNMZSCdWejALN kQKPFMgt4dS4+2o4g0F9WCfOMaSTxPh1UhhLJ1R3MjFgcPgmaI664SMFInQixt2r0zhb7b/r GOGm2Qg7rTGWTthPU6C5c+tBOWrHMykqq0v36vQ3+G5+QzuYTyOct+KxUiXC1psCzbH3pkCu M6BRXeuwijlz/Tc4C/I+jYXh4I2aoFsHQNF/p6Yw0JT7b9UUhk/5BYQTIqNAc2zHKRCLurJn q4HMtv86AnAXAcrpe0Y4ajSfDxoDSdQRoXsyCrN0LiB1Moso7Mq2HSQyzP4gral0giRcsROk wphjw66YEZilk/0EaNXjUZhpeYdWFzjYM5GEm0VJ9iBOJ5fAunTFE6l4TB3m2KxpIiu1WI+t Z6ZXHQwSAJ4gCUPqBKkwZgDYkIohISHm2GVp0LggTbs5GCSAPUESThK5xAemMGaQ2ElqjNX7 8V2uBvUFKVYANxzVDTjtuWLFYrO+KQENxKrxiGrMj+uXQ7DK1fLLkhmWQ2OspMVLZtzjYiuE 72kpIpag9NnYA45R4mw7Er7ebq02mv5RKTRmXdEygri6RYRZdARSGKvyxtgtaibrdLGzrkhx JUjJjeayz4hQ2w7lSGVayCukMlsxc6Qi/KIjlcJYjQAvIEWkFcStQKNsDZxsIk7IEqT6tuNy lDJN5BVKWaNylCIco6OUwlhK4bXISIHsnMLOQKNspfACCYlylboMy1HKdJFKqSSegv7+ZX3L yztKEYu2jlIKY4bnXHzEiuzKqU8EEQudq+qCchQwneNQm+I7TZ66TDhHJ27C8DlbGcRC6xyv n4mdMyje1oiMPR3ZpmgUmrCtRol9S7s8m5bziivJaz4jwnw6OlGeEfcvYil15VxHBBELUV3a 6iERCiBDOnbjy2tNI8KaOgoQi58LvOqjicxassJ3UhpklZKwyzp7xq/xppHXm/Jvub+wnBLe 2iO8KUucSqBQA22Y5HK8yAXllIJrHGvkdaz828HQCceK13czTTQQOUHF8A7gVnO5SR6bq51D RZCD+4ugoBqYdI2x2iSecw3yR05RMby1t+1QeM7jH/Of/DCPBiP8pzgxMt8LRwPCWK6cjV3K fYaIaqvPR0w+8pX+PW2vm4xdN2ks9ImW9KAx5uTHeF2BAq3wnRoFgh+m2BVm26GcuUc20R+4 1xzGrjl0AyfMYYy3zjSR5YucwAkmxnBP66icwAnXN+KmK/a6Pv4tKnmuBIRZi/FShCayJMBt nQIxhm8kaBS6ddl2KEeoa8xh7DWH/NtBeQhzGONFDE1kyYNbPgVi+OZv26GcwH/M98Ve38e/ HZSAsGsxdj2ayJLAKYuU8cM/09pQVIw5GXLhcoT6MXsYe+0h/xYLhX8TpTFWGcV3EhRo6eQK sb7Jwr6fRV1jD2OvPeTfDkZJWDq8upRpIisd8NYnBWKsu7jsH38hJwjDhAxwNlf8DUN6Mv8V ITFmMuAlqIdYeTuz8eKt7YwCLfCuJgVirGdHJUGWECSAubhOAsEhjrt4pQQN6l5hTDdt/CRP WgaF4ZsNHRHunBpkNqkl7pwUiEU9vyhJkDf0TrcAD8UqnZo/VuXmrFhxi1Qn4xuGF0GWeGWE ArGwZzsxucYECvBQrNIK+mNVdtGKFfc7dTI7VrwaQoFY2HN1J9f4PgEeilX6MX+syrNZseLG pk5mx4pXmykQYz37aQmyev4clvbMrNru9Sox/liVzbNixfc2YmRox2mJd5woEDN+3WlV7eQa tybAQ/Mq/Zg/VuXZrFhxH1Yns+Z1hTsUBWKsZ5kmQQbNP6/SvvjnVWL8sSobZMWKfxAhRobm dYVbEQViUd8vja/ZE06km/HHKjH+WJUrMmM1tvlEY8rUyex5dWoT5a+iHn+VIH81crlRHMaz mT94wh9RuFefrC6fPKhPrE3zJd7G0SDzXmbRl4OdS4pu4JIfN9b7RBqayBiZsjimD3JHpkDW yHqqXtqZFzEy39VxL8DwNEM3HvUJKKXlzPRHqXhiyNzBTDuXcI0K4jDzrJn6xFrRX/ZsLKdd ux4RoGyzIkCrYKZdIxzBIhuYu36Udi1mBItsDQRLV7xHsMiiS7B0ZXEEiyxnBot8FEw+LXTO X4rf8/qlPDWTAzySxh/sggSt5bNf4n94WE18CqN5qlp4fku/e4UHAgu4CvmjYJPnqmr1G8gn zvu5aN/Ok3N+LurP5Z/wDBbkdlWX8PiYeOJvHZyruq3zsoXz3ZT7dVB/2ouHwmaX5xPv/gIA AP//AwBQSwMEFAAGAAgAAAAhAFhktkVKAQAAawIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAISSUU/DIBSF 3038Dw3vLaWbbmnaLlGzJ5cYrZnxDeFuIxZoAO3276XtVqsz8RHOuR/n3JAt9rIKPsFYoVWO SBSjABTTXKhtjp7LZThHgXVUcVppBTk6gEWL4vIiY3XKtIEHo2swToANPEnZlNU52jlXpxhb tgNJbeQdyosbbSR1/mi2uKbsnW4BJ3F8jSU4yqmjuAWG9UBERyRnA7L+MFUH4AxDBRKUs5hE BH97HRhp/xzolJFTCneofadj3DGbs14c3HsrBmPTNFEz6WL4/AS/rO6fuqqhUO2uGKAi4yxl BqjTpnjUb35FwVpUTqsMj5R2ixW1buUXvhHAbw6/zecGT+6K9HjggY+W9kVOynpye1cuUZHE ZBbGJJyQklylJEnj+Wv7/o/5Nmp/IY8p/iUmYTIryTSdJh46Ip4ARYbPvkfxBQAA//8DAFBL AwQUAAYACAAAACEAkljOPcAFAAAwIgAAJwAAAHhsL3ByaW50ZXJTZXR0aW5ncy9wcmludGVy U2V0dGluZ3MxLmJpbuxZW2/bNhQ+ToOsRTe0uwF9zPbeIGldryh2gS3btQ3bUiV5LbYOmmLR lhpJFCgqTvbUnzHslwzYSx/7I/Yn9jJgL+vOoaxEddK0RXcpFtGQSZ7Dy+HHj+QRNYMABDC4 DhI4JPC6obYOG7+C/Yn27PE7NbgEP12uX/SgBlfgwdoarOH/Bcw1of7aLb+4Qm2pWsOYno9R 8AzDao12fzz5FJ5urF8yrv3+xY/js0y485yyBhcwn/dTO4pJUvT9asMh68qB6pd/fyMoVVNv jEB5bp9uAFgje0CNXoWfN3pgwCYMwYUUV4uAAf5LlNThBtyCbUwZoKG+geX7cZLJVhBDVzdH lj4xtQ6YHas9HMIkDgRLKWWylIeZDHgMje1tLwlAFwGLpatEhm7aZrNvQ8/IxSZHDdu5vQ1d N0wZtLMkZAfwdce0+1pzCIabMGEFPzBo1mHEvMC1DxPMZJKDxsMQK4M+Bj2TS9uUpmf0I3fO LD+YSdBnM+yO5Hnj1tQNg3gOtsgYtcHFiHsMbtR3kwRsdiCbaSt0p3tLi2wb84GM3CS1mJSq pk01sE9shyEEtubzYMryFntGCytbgccMEcSqfD60gdG524nd3ZBBi6USrIhz6R9Zokrfy9A2 eXhX8CwB456KnR00/9jOkT7WtZ6pjzrOSG93UGe0hwoUjB1DGzZINBh24in3qPWJ3b2NogHf bU6nPMtNwrzeamqa7ah4TDPS4iLW4zZBihm9nVdqHWJNfZ8JgUOCQWugo/zBaNgNQjZJmQd+ Ek0TN2lsHUQhqizpJoSvniSc1Png0SS0zHDT1PZxcHO/AMuKXCGXE4O1QmbgxGGPp+h1z1tR jtwYActrtwM35PO+ZFGKTE2lyKZEuX7b2d5xuk2t09bvj6+PdVO3mzbBllfuMuaVGVqUJIYW pDpVX4wTxhxJUDRXtoVIEoL6Z2m6UoRGoguPCejss5hyaTcQSAtqKTm2zea2cA93CjgUS/S4 hcwhiqV5wfDwCGZLCjeY+1ItHMOV/rGGxR7yYpJiX1rkgTYx+4pZOLcp6NJnwlF2QFfwWDoa R4UzEzxyCCRMH20AashE85cWGpgap8lwcSmkgLle28AJx7nCTK9NE+WGIdKEcrRSKR5zeVJB ayBOs4gJLUslj9QAc1gMqxkG8zjCbYZYiYP6Zmgt4s+IjUSvXrbr6DEtVtw/5jFPZTCVnIcp 2OaEqHBUysqQtUK6sSeRpbhUUx8XqVqjKyUNwT1kWKQYeLIhzWfTvRkXnggQxSzxcFWdUop2 n2S5TbjTKdIko+k5YZdiSorGhcEpzVg+X0QM//J6hmUxsY8bUuooukypF9XuI76La2S1dVwu TDoWrpQbjZtOC+NbO3Wnp/K33tLz17iG59HE6F2F95WFdMaRV1I+68jXoUCyGmrJfyMPqPCv KH4VDy73/nJfjPwxCtQmHqVvFApbX+Z7bcK3EKMXG+PZ/N1bOh+VWf8cAtX8n292NdEvD9BD D6tFdi4RoHcvYzny4qx48uSJkhRxGZhLmKFy3gm0Hn91FoCr59AaCi6UhKedUybchz6+H9qg w5kXERV3/6cIfI4+VKZu2SLcoyTuVFP4sprtc4ZA7mMXvvZxTDCUdWVYVveT75dlizJlPaWv 4EN3ohTK6fIdaSEv64v2zF/eg/pFUE9F0AoBQuBD5NMHL3sBq6B6DoEKrooQr4sA+aLEG0O9 y8TqG4On0vvqu8Mm+HjDkSr5DFMCNuEmfoPYRX+Cvke4+A0vqWCvEPiPEbDhEHnIkJF0G7fA +B56v+Tz7mHaWn49i5GvkSrlK3azf9XqAHv77d3jLh9hcoscomXYw/jPy8/nn5XyEar+OCNP 96bX8XI1TcIFXzTqW+xADfBFPuDfKV/1787y9z4qHVTrsK4GrMEdeIjvrAHOn4f7zAL3nIf4 JHi7slD5Bn773MJZO8CnCucFgb8AAAD//wMAUEsDBBQABgAIAAAAIQA1+6khkwEAAB4DAAAQ AAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAJySTW/bMAyG7wP2HwzdGzndB4ZAVjGkG3rYsABO27Mm07FQWTJE1oj3 60fbSOp0O/XGjxevHlJUN8fWZz0kdDEUYr3KRQbBxsqFQyHu99+vvogMyYTK+BigEAOguNHv 36ldih0kcoAZWwQsREPUbaRE20BrcMXtwJ06ptYQp+kgY107C7fRPrcQSF7n+WcJR4JQQXXV nQ3F7Ljp6a2mVbQjHz7sh46Btfradd5ZQzyl/ulsihhryr4dLXgll03FdCXY5+Ro0LmSy1SV 1njYsrGujUdQ8qWg7sCMS9sZl1CrnjY9WIopQ/eH13Ytst8GYcQpRG+SM4EYa5TNyRT7Dinp x5iesAEgVJIFc3EKl9pl7D7q9STg4FI4Gswg3LhE3DvygL/qnUn0H+L1knhimHlnnHLkm99c 8k0j80uvvLex7UwY9NahjVk5IEHLw53K6ocLT3jf7eOtITjt9rKoysYkqPg7zrs/F9QdrzX5 0WTbmHCA6qT5tzFewsN87nr9aZV/yPmTFzUlXw5b/wUAAP//AwBQSwECLQAUAAYACAAAACEA QTeCz24BAAAEBQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQIt ABQABgAIAAAAIQC1VTAj9AAAAEwCAAALAAAAAAAAAAAAAAAAAKcDAABfcmVscy8ucmVsc1BL AQItABQABgAIAAAAIQCBPpSX8wAAALoCAAAaAAAAAAAAAAAAAAAAAMwGAAB4bC9fcmVscy93 b3JrYm9vay54bWwucmVsc1BLAQItABQABgAIAAAAIQDap55OPQIAAJ4EAAAPAAAAAAAAAAAA AAAAAP8IAAB4bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAAACEAWfWsB38IAABGIgAAFAAA AAAAAAAAAAAAAABpCwAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAAACEAO20y S8EAAABCAQAAIwAAAAAAAAAAAAAAAAAaFAAAeGwvd29ya3NoZWV0cy9fcmVscy9zaGVldDEu eG1sLnJlbHNQSwECLQAUAAYACAAAACEAi4JuWJMGAACOGgAAEwAAAAAAAAAAAAAAAAAcFQAA eGwvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQBHOFPxZgMAAMgOAAANAAAAAAAA AAAAAAAAAOAbAAB4bC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAG3ErqVYCgAA5DgAABgA AAAAAAAAAAAAAAAAcR8AAHhsL3dvcmtzaGVldHMvc2hlZXQxLnhtbFBLAQItABQABgAIAAAA IQBYZLZFSgEAAGsCAAARAAAAAAAAAAAAAAAAAP8pAABkb2NQcm9wcy9jb3JlLnhtbFBLAQIt ABQABgAIAAAAIQCSWM49wAUAADAiAAAnAAAAAAAAAAAAAAAAAIAsAAB4bC9wcmludGVyU2V0 dGluZ3MvcHJpbnRlclNldHRpbmdzMS5iaW5QSwECLQAUAAYACAAAACEANfupIZMBAAAeAwAA EAAAAAAAAAAAAAAAAACFMgAAZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADAAMACYDAABONQAA AAA= --------------F08A968F0841B474EFF50C27-- From nobody Thu Mar 23 09:41:14 2017 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 756A1129ACC; Thu, 23 Mar 2017 09:41:06 -0700 (PDT) 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 9fqAIQvR2ZK2; Thu, 23 Mar 2017 09:41:03 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 9158C129A58; Thu, 23 Mar 2017 09:40:40 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id n21so180421682qta.1; Thu, 23 Mar 2017 09:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Twp1LPRX+0L978OV8gesPMcVA95lbu943UKYt/O6Zas=; b=miGm32MiMu8fWBoGuqvWwytsj/NH+M+g0ItXBL0Wz77+dZ1dQkIQ8XGNEydNFMUBYd QOAt/RUyaqm9yShhWK3Gz6J2kC4vj9Wmp5nJw51AhxUBjUrJmeZQOCaosemUzdicAqgP 324+CuX7I46hNadaonNqIH45EE9zkX8JAHl/rBOkvx2R8b30BbsEUmNUCXN9ZvcxhZn0 +f5Hb+pFiA+sLkzbbiHQGO6cYZyuhpaF/PsKbzW8kOLfU9g2UElM63SKCMg23YnoP538 G+gJ8OTImERHIILvjGGNyopwf37QBLDAAmNd6uZ37JtUwx1DGynv4Wcmk1KNn+oZ2V0B Wl8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Twp1LPRX+0L978OV8gesPMcVA95lbu943UKYt/O6Zas=; b=tMocEk3mvYNZB0Qb54aJTOL/yCJ85SXyu0LKUM2hJBJUaehzK/BfF3TkeLHqmAEkYZ FwT0QEmxtVTMsUix5tkh6ekHzLRGi2dzQPiYF9MT7V/8KWBjIQ+DR/wZR8EGSsBMelHU NYRnczPAwLMue8Yrcw+FatG3wYPkfPrt+HEy8gu2LMzn4wVEwkzUOngkngf1v38h+8TD fD/KZ6zFraX3m/Q+Oe5vDisnZ87nHTR7VZwkB3hiwVlWrxn+gZDduuPYFp34+acfLxoJ 3HTS+1y9rMD7UAi3tnnDh63z35qNys0gHAjcW86RxHgu8yhVDj3H5H4wgqnIa8waFoDp 1XIg== X-Gm-Message-State: AFeK/H0QLvWJ7BfTfgpM3p1CDvCiXR6Ry3jps1IBU/0kYpWM5Abmn7/aZhDcYUTFkF0DQK8GeMNq74Uzmyd4cA== X-Received: by 10.200.51.199 with SMTP id d7mr3197651qtb.94.1490287239579; Thu, 23 Mar 2017 09:40:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.41.170 with HTTP; Thu, 23 Mar 2017 09:40:39 -0700 (PDT) In-Reply-To: References: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> From: Dan Romascanu Date: Thu, 23 Mar 2017 18:40:39 +0200 Message-ID: To: Robert Wilton Cc: netmod@ietf.org, ccamp@ietf.org, Russ Housley Content-Type: multipart/alternative; boundary=001a114541de87afe1054b688981 Archived-At: Subject: Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 16:41:07 -0000 --001a114541de87afe1054b688981 Content-Type: text/plain; charset=UTF-8 Hi Robert, Thank you for the answer. If the current IEEE 802.3 project (cp) is not chartered to make changes in Clause 30 - these cannot be done, and you need a new project for this purpose. Take this into consideration, as this may become a dependency and a gating issue for the project timelines. I suggest that you discuss this with the IEEE 802.3 chair David Law. I am also copying Russ who is now in charge with the IETF - IEEE relationship to make sure that he is aware about the issue. Regards, Dan On Thu, Mar 23, 2017 at 5:36 PM, Robert Wilton wrote: > Hi Dan, > > On 23/03/2017 07:56, Dan Romascanu wrote: > > Hi, > > I largely agree with the proposals of the team. > > I have only one comment / clarification related to the RMON objects which > are proposed to be transferred under IEEE 802.3cp. As far as I remember > there are some differences between the definitions in the RMON MIB for some > of the objects and the Clause 30 definitions. > > Unfortunately, yes there are differences. > > What is the approach that you propose to take? > > I'm trying to rationalize them all together (at least for the parts of the > MIB that we want to carry forward into YANG). > > Please see attached for a spreadsheet that shows the relationship between > the proposed 802.3 YANG counters, the existing MIBs (IFMIB, RMON, and > ETHERNET-LIKE), and 802.3 clause 30. This doesn't yet cover the counters > that I plan on adding to draft-ietf-netmod-intf-ext-yang-04 (Drop due to > invalid destination MAC, of RMON style histogram counters). > > There will also be some text added to the 802.3cf draft that should > explain the relationship, possibly some of it may be lifted directly from > 802.3.1. > > > > Include in IEEE 802.3cp only those objects that strictly conform to Clause > 30 definitions, or modify / add definitions in Clause 30 in order to > accommodate all the RMON statistics? If the later approach is to be taken - > is IEEE 802.3cp chartered to make changes or add new definitions in Clause > 30 of IEEE 802.3? > > > A bit of both - mostly the former approach, but with a few missing > counters hopefully added to clause 30. > > Specifically, I hoping that the following counters can be added to clause > 30: > Row 17: In PFC frames (used in ETHERLIKE MIB dot3HCInPFCFrames) > Row 18: Out PFC frames (used in ETHERLIKE MIB dot3HCOutPFCFrames) > Row 19: Total Octets received (good & bad) (used in RMON MIB > etherStatsOctets) > Row 25: Frames dropped as being too short. (combined value of two RMON > MIB counters (etherStatsUndersizePkts + etherStatsFragments)) > > I think that in principal there is some support for adding these to clause > 30, and the appropriate folks in 802.3 will work out the easiest/best > mechanism to achieve this. > > Thanks, > Rob > > > > Regards, > > Dan > > > On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton wrote: > >> Hi, >> >> I'm participating in the 802.3 task force (802.3cf) to produce standard >> YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3 >> Ethernet Working Group. >> >> As part of my involvement with that group, I want to highlight a couple >> of issues that arose in that forum that may be of interest to various WGs >> in IETF. >> >> This email, and accompanying slides, represents my personal views, and do >> not represent any formal IEEE position. However, both this email and the >> accompanying slides have been reviewed in an 802.3cf task force meeting, >> and there were no objections to the content, or my sending of this email to >> IETF. >> >> I also raised these issues (with an earlier set of slides) as part of the >> IETF/IEEE liaison meeting on 31st January, and the consensus was generally >> supportive of this approach, with the agreed next steps to contact the >> NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email): >> >> >> As part of that YANG modelling work, there is an aim to define a clean >> boundary of what manageability data should be specified within 802.3 and >> what belongs outside the 802.3 specifications. >> >> The definition that the task force is converging on is that everything >> related to Ethernet, covered by 802.3, that can be expressed in terms of >> the 802.3 clause 30 manageability definitions, should be modeled in 802.3. >> I.e. broadly everything that is covered by 802.3.1 today. But any >> manageability information that cannot be related to clause 30 definitions >> should be specified outside of 802.3. Note, where appropriate, additional >> clause 30 definitions may be added to fix any mistakes or glaring gaps. >> >> >> To this end, there are a couple of areas between IETF and 802.3 that >> don't necessarily look like they are entirely in the right place, in >> particular: >> >> 1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related >> content) some Ethernet specific statistics that would be better co-located >> with the Ethernet interface YANG model being defined in 802.3cp. Hence, >> the proposal is to subsume the appropriate Ethernet statistics from the >> RMON MIB into a single combined reference set defined in 802.3cp. >> >> 2) The RMON MIB also defines some Ethernet specific statistics that can't >> be defined as part of 802.3cf because they don't relate to 802.3 clause 30 >> registers, but are still widely supported by vendors, and should be modeled >> in YANG. The proposal is that definitions related to these counters could >> be added as part of the Ethernet-like module >> draft-ietf-netmod-intf-ext-yang-03 >> , or >> perhaps a related Ethernet module in the same draft. >> >> 3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced from >> RFC 7460), was originally specified in IETF, but ownership later >> transferred to 802.3 (via RFC 7448). Whilst working on the Power over >> Ethernet YANG model it has become clear that not all of the attributes >> defined in the MIB map to the underlying 802.3 clause 30 definitions. >> Further, it looks like parts of this YANG model would be better defined as >> extensions to the Entity YANG model being defined in NETMOD. The proposal >> is that the parts of the Power over Ethernet YANG model that can be >> directly related to clause 30 definitions (e.g. *pethPsePortTable*) >> should be defined in 802.3cf, but that the remaining parts (e.g., *pethMainPseObjects >> *) can hopefully be standardized in IETF. >> >> >> Do you have any comments, or concerns, on the 3 proposals above? >> >> Regards, >> Rob Wilton >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > > --001a114541de87afe1054b688981 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robert,

Thank you for= the answer.

If the current IEEE 802.3 project (cp) is not ch= artered to make changes in Clause 30 - these cannot be done, and you need a= new project for this purpose. Take this into consideration, as this may be= come a dependency and a gating issue for the project timelines. I suggest t= hat you discuss this with the IEEE 802.3 chair David Law. I am also copying= Russ who is now in charge with the IETF - IEEE relationship to make sure t= hat he is aware about the issue.

Regards,

Dan

On Thu, Mar = 23, 2017 at 5:36 PM, Robert Wilton <rwilton@cisco.com> wrote= :
=20 =20 =20

Hi Dan,


On 23/03/2017 07:5= 6, Dan Romascanu wrote:
=20
Hi,

I largely agree with the proposals of the team.

I have only one comment / clarification related to the RMON objects which are proposed to be transferred under IEEE 802.3cp. As far as I remember there are some differences between the definitions in the RMON MIB for some of the objects and the Clause 30 definitions.
 Unfortunately, yes there are differences.

What is the approach that you propose to take?
 I'm trying to rationalize them all together (at least for the parts of the MIB that we want to carry forward into YANG).

Please see attached for a spreadsheet that shows the relationship between the proposed 802.3 YANG counters, the existing MIBs (IFMIB, RMON, and ETHERNET-LIKE), and 802.3 clause 30.=C2=A0 This doesn't y= et cover the counters that I plan on adding to draft-ietf-netmod-intf-ext-yang-04 (Drop due to invalid destinatio= n MAC, of RMON style histogram counters).

There will also be some text added to the 802.3cf draft that should explain the relationship, possibly some of it may be lifted directly from 802.3.1.



Include in IEEE 802.3cp only those objects that strictly conform to Clause 30 definitions, or modify / add definitions in Clause 30 in order to accommodate all the RMON statistics? If the later approach is to be taken - is IEEE 802.3cp chartered to make changes or add new definitions in Clause 30 of IEEE 802.3?

A bit of both - mostly the former approach, but with a few missing counters hopefully added to clause 30.=C2=A0

Specifically, I hoping that the following counters can be added to clause 30:
=C2=A0Row 17: In PFC frames (used in=C2=A0 ETHERLIKE MIB dot3HCInPFCFra= mes)
=C2=A0Row 18: Out PFC frames (used in ETHERLIKE MIB dot3HCOutPFCFrames)
=C2=A0Row 19: Total Octets received (good & bad) (used in RMON MIB etherStatsOctets)
=C2=A0Row 25: Frames dropped as being too short. (combined value of two RMON MIB counters (etherStatsUndersizePkts + etherStatsFragments))

I think that in principal there is some support for adding these to clause 30, and the appropriate folks in 802.3 will work out the easiest/best mechanism to achieve this.

Thanks,
Rob



Regards,

Dan


On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,

I'm participating in the 802.3 task force (802.3cf) to produce standard YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3 Ethernet Working Group.

As part of my involvement with that group, I want to highlight a couple of issues that arose in that forum that may be of interest to various WGs in IETF.

This email, and accompanying slides, represents my personal views, and do not represent any formal IEEE position.=C2=A0 However, both this email and the accompanyi= ng slides have been reviewed in an 802.3cf task force meeting, and there were no objections to the content, or my sending of this email to IETF.

I also raised these issues (with an earlier set of slides) as part of the IETF/IEEE liaison meeting on 31st January, and the consensus was generally supportive of this approach, with the agreed next steps to contact the NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email):


As part of that YANG modelling work, there is an aim to define a clean boundary of what manageability data should be specified within 802.3 and what belongs outside the 802.3 specifications.

The definition that the task force is converging on is that everything related to Ethernet, covered by 802.3, that can be expressed in terms of the 802.3 clause 30 manageability definitions, should be modeled in 802.3.=C2= =A0 I.e. broadly everything that is covered by 802.3.1 today.=C2=A0 But any manageability information that cannot = be related to clause 30 definitions should be specified outside of 802.3.=C2=A0 Note, where appropriate, additional clause 30 definitions may be added to fix any mistakes or glaring gaps.


To this end, there are a couple of areas between IETF and 802.3 that don't necessarily look like they are entirely in the right place, in particular:

1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related content) some Ethernet specific statistics that would be better co-located with the Ethernet interface YANG model being defined in 802.3cp.=C2= =A0 Hence, the proposal is to subsume the appropriate Ethernet statistics from the RMON MIB into a single combined reference set defined in 802.3cp.

2) The RMON MIB also defines some Ethernet specific statistics that can't be defined as part of 802.3cf because they don't relate to 802.3 clause 30 registers, but are still widely supported by vendors, and should be modeled in YANG.=C2=A0 The proposal is that definitions related to these counters could be added as part of the Ethernet-like module draft-ietf-netmod= -intf-ext-yang-03, or perhaps a related Ethernet module in the same draft.

3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced from RFC 7460), was originally specified in IETF, but ownership later transferred to 802.3 (via RFC 7448).=C2=A0 Whilst working on the Power over Ethernet YANG model it has become clear that not all of the attributes defined in the MIB map to the underlying 802.3 clause 30 definitions.=C2=A0 Further, it looks like parts of this YANG model would be better defined as extensions to the Entity YANG model being defined in NETMOD.=C2=A0 The proposal is that the parts of the Power over Ethernet YANG model that can be directly related to clause 30 definitions (e.g. pethPsePortTable) should be defined in 802.3cf, but that the remaining parts (e.g., pethMainPseObjects ) can hopefully be standardized in IETF.


Do you have any comments, or concerns, on the 3 proposals above?

Regards,
Rob Wilton


_______________________________________________
netmod mailing list
netmod@iet= f.org
https://www.ietf.org/mailman/listinfo/n= etmod




--001a114541de87afe1054b688981-- From nobody Thu Mar 23 10:04:57 2017 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 8A33C129951 for ; Thu, 23 Mar 2017 10:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Lnwm6MUn5mSN for ; Thu, 23 Mar 2017 10:04:52 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 7B3171299B8 for ; Thu, 23 Mar 2017 10:04:51 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id u1so17775208wra.2 for ; Thu, 23 Mar 2017 10:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Hu9gl+3GLjcNb3S5OSBpvewv/0mRlCjP9Oz1JMn1mlM=; b=AxdPgXi1VEEkRijgpea8L1RHIX8vrscnO65fiwaYM9bhhfftw3gcGuObv436cRW7PH TmLzmG6+rroN58uzYNhXjfIGvvzFLr+xmbQS0XXmZH7TxOW/udcj8A5hxh6q35twrYs3 Dh2PBoJ0p2nkFFKCOCKJhbNM6jvRH0b0FyL9x/NjQMYL2qUdWPzX8LTyBuz9Bd5WU7DZ Gz2rmaq+8vYJBhxx/joplwG9++B0HQGlN5TgW08eeXeAsD58KssEvM2lUqlT29w8k6OP tw4FtGbLCrffviAcirDzTiO4SveCR5fCayCnl1qa3rbUPo+95yxQusW8E89nxSNd0q/f fu6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Hu9gl+3GLjcNb3S5OSBpvewv/0mRlCjP9Oz1JMn1mlM=; b=julVMpPIzSyhBjDE2+xArs1SeawVsrencZQNrgRZY7J1g9axh2rgbU2iy5Y9jlooBD cqY0zOXqEhLgKPVngC6bnfWZMryOeQnUVVgqBSMWHDCmTkE+WlQ85tzoESSEEzx9WS2S AmxTcQSyOCkLxZ+/ZAC+PRLsUQx3jAQvvoLzpJ7ZrpZxXJ57bvlb6GeyUstc+1AfUF9b UowyRAM7SUVvJ5AGtaKAXT0o/4CnHhwY+/3sqMq6fpVHAj7KaT+S5Ftqwpq/ytZPJDL2 MPUJzLg6sAKmkTpmFS6kIWlA+KQmSofbYBZq0+mc4xZAsSE0DMZZzVyJzEchidUqsX40 scFA== X-Gm-Message-State: AFeK/H2Va65z996ySGrVAtkOx9LJMs/O8aJpodKSXWwXODR8xpOiq46rgmspbqh2EL5zog== X-Received: by 10.223.165.17 with SMTP id i17mr3830121wrb.70.1490288689817; Thu, 23 Mar 2017 10:04:49 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p5B3429B7.dip0.t-ipconnect.de. [91.52.41.183]) by smtp.gmail.com with ESMTPSA id 11sm6534268wrb.10.2017.03.23.10.04.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 10:04:49 -0700 (PDT) From: "Mehmet Ersue" To: "'Kent Watsen'" , "'Lou Berger'" , References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <675654fd-1532-1755-621c-a3ecb06950e3@labn.net> <025a01d29e82$8549d070$8fdd7150$@gmail.com> <007201d2a349$fa8c3b40$efa4b1c0$@gmail.com> <142D20A9-8A20-4D2E-8B2F-BDE7514A28B1@juniper.net> In-Reply-To: <142D20A9-8A20-4D2E-8B2F-BDE7514A28B1@juniper.net> Date: Thu, 23 Mar 2017 18:04:50 +0100 Message-ID: <017c01d2a3f7$96201420$c2603c60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUooBvvnQPAGVQNXrAT+Tz94BQZmbIAI0gOzfAhWybtiggwer4A== Content-Language: de X-AVK-Virus-Check: AVA 25.11068;244D8A0E X-AVK-Spam-Check: 1; str=0001.0A0C0208.58D40030.0301,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 17:04:55 -0000 Hi Kent, > We do, however, have a "YANG Next" discussion on the agenda, which may = or may not lead to the creation of a milestone for it. It would be good to extend the charter proposal after this discussion = with agreed goals for 7950bis. We also need to know what exactly is going to be separated from 7950. = E.g. one of the topics we discussed on the maillist was guidance on = using YANG with specific protocols. This can be done in the protocol = document. > > > > >>>>>>> Oct 2017 - Submit = draft-ietf-netmod-revised-datastores > > > > >>>>>>> to IESG Another question is whether this should be earlier, e.g. August. As it is a high-priority topic needed at least by 2 WGs, we were saying = that revised-datastores should be finalized within 4 months and = NC/RC-bis will take another 4-5 months. Thanks, Mehmet > -----Original Message----- > From: Kent Watsen [mailto:kwatsen@juniper.net] > Sent: Wednesday, March 22, 2017 9:48 PM > To: Mehmet Ersue ; 'Lou Berger' ; > netmod@ietf.org > Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' > > Subject: Re: [netmod] draft netmod charter update proposal >=20 > Hi Mehmet, >=20 > From a charter perspective, we have: >=20 > a) Maintaining the data modeling language YANG. This effort > entails periodically updating the specification to address > new requirements as they arise. >=20 > From a milestone perspective, you are correct that we don't have a > milestone for 7950bis as of yet. We do, however, have a "YANG Next" > discussion on the agenda, which may or may not lead to the creation of = a > milestone for it. >=20 > As for NETCONF/RESTCONF revisions depending on a 7950bis, if that is = true, > then it will likely force us to create the milestone in the near-term = for it. That > withstanding, I think that NETCONF WG could take the lead by > moving/copying the NETCONF-specific parts from RFC7950 into an = rfc6241bis. > It would be nice if we could decouple the refactoring of these = documents > across our WGs. >=20 > Kent // co-chair hat >=20 >=20 >=20 > -----ORIGINAL MESSAGE----- > Hi Kent, Lou, >=20 > as I see 7950bis has not been mentioned in the charter text and the > milestones. > As you know NETCONF and RESTCONF revisions are dependent on the timing > of 7950bis. > How is this essential deliverable and its timing going to be addressed = in the > charter? >=20 > Mehmet >=20 > > -----Original Message----- > > From: Mehmet Ersue > > Sent: Friday, March 17, 2017 11:51 PM > > To: Lou Berger ; 'Kent Watsen' > > ; netmod@ietf.org > > Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' > > > > Subject: RE: [netmod] draft netmod charter update proposal > > > > Hi Lou, Kent, > > > > I promised to provide some minimal text which can be used as WG item > > description. > > I'm fine with any fine tuning. > > > > See below: > > > > a) Maintaining the data modeling language YANG. This effort = entails > > periodically updating the specification to address new = requirements > > as they arise. ADD > revision > of RFC > > 7950./> > > > > b) Maintaining the guidelines for developing YANG models. This = effort > > is primarily driven by updates made to the YANG specification. > ADD > continuous effort has been recently addressed with a revision of RFC > 6087./> > > > > c) Maintaining a conceptual framework in which YANG models are = used. > > This effort entails describing the generic context that in = YANG > > exists and how certain YANG statements interact in that = context. > > An example of this is YANG's relationship with datastores. > > ADD > for the > handling > > of datastores, which can be adopted by other WGs for their usage > > scenario./> > > > > . . . > > > > e) Maintaining YANG models used as basic YANG building blocks. = This > > effort entails updating existing YANG models (ietf-yang-types = and > > ietf-inet-types) as needed, as well as defining additional = core YANG > > data models when necessary. ADD > work on the models for Syslog, ACL and Common Interface Extensions = as > > well as the model for hardware management. The Schema mount draft = will > > provide a mechanism to combine YANG modules into the schema defined > in > > other YANG modules./> > > > > BTW: There is no topic description (in a)-f) covering YANG module > > classification. > > I assume it can be added with a sentence to a) or b). > > > > Thanks, > > Mehmet > > > > > -----Original Message----- > > > From: Mehmet Ersue > > > Sent: Thursday, March 16, 2017 11:59 PM > > > To: Lou Berger ; 'Kent Watsen' > > > ; netmod@ietf.org > > > Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' > > > > > > Subject: RE: [netmod] draft netmod charter update proposal > > > > > > > From: Lou Berger [mailto:lberger@labn.net] Mehmet, > > > > see below. > > > > On 3/16/2017 2:24 PM, Mehmet Ersue wrote: > > > > > Lou, > > > . . . > > > > > I actually provided a very simple proposal. You guys can fill > > > > > the idea with minimal text better than me. I'm fine whatever = the > > > > > text > is. > > > > > If you think the high-level topic description a)-f) does = already > > > > > define the WG item clearly you can simply say "this is = achieved > > > > > with WG > > > > item XY". > > > > > If not, you can keep the high-level focus text but set > > > > > additionally the borders of the WG item with a few concrete = words. > > > > > > > > I really can't tell for sure, but it feels to me that this = comment > > > > boils down to a style comment and you have a preference for > > > > different contents in the charter. I'd like to be sensitive to > > > > this. As our style differs, having a concrete proposal on > > > > specific text changes would be really helpful in us (and the WG) > > > > evaluating the changes you'd like to see. Without such specific > > > > examples and think we're left with the charter as currently > > > > proposed. Perhaps someone else who > > > has similar feelings can chime in and provide proposed text. > > > > > > > > Anyone else have any comments or proposed changes? > > > I think the wording depends on the time period is for which the > > > charter is prepared. > > > I can try some text once I have time tomorrow. > > > > > > . . . > > > > > I think the DS draft provides a conceptual framework for = diverse > > > > > DS usage scenarios to be used by many protocols, where IETF = WGs > > > > > may actually decide using a subset of the DS framework for = their > > > > > purpose and for their protocol standardization. > > > > > Based on this the conceptual framework cannot be standardized = as > > > > > it is but the protocols using a consistent subset have to be > standardized. > > > > > Following this consideration I think the intended status of = the > > > > > DS draft should be changed to: Informational RFC If you agree > > > > > please indicate this change accordingly. > > > > > > > > I think Juergen's reply to your previous message highlights that > > > > there is a difference of opinion here based on the technical > > > > specifics of the draft. My position as chair is that I'll = support > > > > whatever makes sense based on the document produced by the WG. > > > > Today the document authors believe PS is appropriate, once we = have > > > > a version that is stabilizing for LC -- which hopefully will be > > > > the next version or two > > > > -- then will be a good time to revisit this. > > > There are indeed different opinions concerning the goal of the DS = draft. > > > I agree with the document introduction and see it as a conceptual > > > framework covering many usage scenarios. > > > Such a conceptual framework describing possible solutions is > > > informational in nature and is not relevant for standardization. > > > > > > > >>> This is as I think also important to avoid an overlapping > > > > >>> between NETCONF and NETMOD charters. > > > > >> I don't follow this point. Certainly I'd hope that the > > > > >> protocol impact of revised DS are covered in a PS document, > > > > >> unless for some reason there are no "on-the-wire" changes > > > > >> needed. TI wouldn't expect that the document status of the > > > > >> base revised data store document would > > > > impact that. Do you? > > > > >> If so, how? > > > > > My comment is actually superfluous if you agree with my > > > > > considerations above. > > > > > The worst case would in my opinion happen if the DS conceptual > > > > > framework covering many high-level DS usage scenarios would be > > > > > attempted to standardize, which at the end would prescribe > > > > > protocol WGs what they should be standardizing. > > > > > > > > Yang presumes a certain set of functions for the protocols it > > > > operates > > over. > > > > I'm not sure why having a document that specifies this would be = an > issue. > > > This is again an interesting discussion which SHOULD be discussed = in > > > a joint session. > > > I don't have a strong opinion but it can be seen differently. > > > > > > > > In such a case the conceptual framework would most likely = cause > > > > > a competing situation with protocol WG's goals and documents = and > > > > > cannot be adopted successfully. > > > > > > > > If a protocol doesn't provide full support for yang = (requirements) > > > > it can't fully support all yang features. If your point is that > > > > when NetMod changes basic yang functions/operations that this > > > > might constrain the protocols (and related WGs) over which it > > > > operates, then I agree that this is the case. How could it be = otherwise? > > > Usually modeling languages provide many language constructs and > > > people modeling models choose which one is best for their purpose. > > > The same applies to the DS concept framework. The protocol WGs = would > > > like to have the freedom to choose the subset to adopt from the > > > protocol > > pov. > > > > > > > Thanks, > > > > > > > > Lou > > > > > > > > > Thanks, > > > > > Mehmet > > > > > > > > > >>> PS: I expect that most of the Netconf WG member read also = the > > > > Netmod > > > > >>> maillist and therefor skip sending to both ML. > > > > >>> > > > > >> Great. > > > > >> > > > > >> Thanks. > > > > >> Lou > > > > >>> Thanks, > > > > >>> Mehmet > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Mehmet Ersue > > > > >>>> Sent: Thursday, March 9, 2017 7:36 PM > > > > >>>> To: Lou Berger ; 'Kent Watsen' > > > > >>>> ; netmod@ietf.org > > > > >>>> Cc: 'Benoit Claise' ; 'Mahesh = Jethanandani' > > > > >>>> > > > > >>>> Subject: RE: [netmod] draft netmod charter update proposal > > > > >>>> > > > > >>>> Hi Lou, > > > > >>>> > > > > >>>>> The charters from the last couple of years don't have the > > > > >>>>> intended > > > > >>> status -- > > > > >>>> at least the ones we checked. > > > > >>>>> I actually feel pretty strongly about this (which of = course > > > > >>>>> can be easily overruled by our AD). It's my experience = that > > > > >>>>> premature discussions on intended status, i.e., before a > > > > >>>>> document is sufficiently > > > > >>>> mature, leads to process-focused arguments that detracts = from > > > > >>>> making technical progress. While once a document is mature > > > > >>>> and core direction/content is fixed, it is generally = obvious > > > > >>>> what status is > > > > >>> appropriate. > > > > >>>> The charters from the last couple of years have a short WG > > > > >>>> item > > > > >>> definition, > > > > >>>> which would be IMO sufficient. > > > > >>>> You are right the intended status is not available since a > > > > >>>> few years, but > > > > >>> IMO it > > > > >>>> is part of the target definition and would be very useful = for > > > > >>>> the draft > > > > >>> authors > > > > >>>> and WG members to regard. > > > > >>>> > > > > >>>>>> It would be good to bring the high-level topics in = relation > > > > >>>>>> to the WG > > > > >>>> items. > > > > >>>>> I'm sorry, I don't understand this last sentence can you > rephrase > > it? > > > > >>>> What I meant is that the high-level topics a)-f) might be > > > > >>>> good as WG focus description but are not sufficient as = draft > > > > >>>> target > > definition. > > > > >>>> If you think the high-level topic description is more or = less > > > > >>>> the WG item definition, then we could simply write "this is > > > > >>>> achieved with WG > > > > > item > > > > >> XY". > > > > >>>> If not, we could keep the high-level focus text but set > > > > >>>> additionally the borders of the WG item with some concrete > words. > > > > >>>> > > > > >>>>>> BTW: We agreed in diverse discussions that the DS concept > > > > >>>>>> is > > > > >>>> Informational in nature. > > > > >>>>>> I think this should be corrected in the draft. > > > > >>>>> So this sounds like an objection to a specific document. > > > > >>>>> This is a fair point to raise, but in our opinion it is = not > > > > >>>>> a charter impacting point or discussion. If this is in = fact > > > > >>>>> the issue you'd like to raise and discuss, lets do so = under > > > > >>>>> a document specific thread, e.g., > > > > >>> "Subject: > > > > >>>> intended status of revised-datastore". > > > > >>>> > > > > >>>> I am actually raising this point since November meeting. > > > > >>>> There are > > > > >>> different > > > > >>>> threads where I explained why it is appropriate as = Informational. > > > > >>>> The last thread I remember is at: > > > > >>>> > > > > >> > > > > > > > > > > https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH1 > > > > >>>> 1xcY > > > > >>>> The recent position of NETCONF co-chairs is in > > > > >>>> > > > > >> > > > > > > > > > > https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd > > > > >>>> 8qr5k > > > > >>>> > > > > >>>> Thank you for your consideration. > > > > >>>> > > > > >>>> Regards, > > > > >>>> Mehmet > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: Lou Berger [mailto:lberger@labn.net] > > > > >>>>> Sent: Wednesday, March 8, 2017 11:28 PM > > > > >>>>> To: Mehmet Ersue ; 'Kent Watsen' > > > > >>>>> ; netmod@ietf.org > > > > >>>>> Subject: Re: [netmod] draft netmod charter update proposal > > > > >>>>> > > > > >>>>> Hi Mehmet, > > > > >>>>> > > > > >>>>> On 3/8/2017 4:47 PM, Mehmet Ersue wrote: > > > > >>>>>> Kent, > > > > >>>>>> > > > > >>>>>>> we understand that this is how NETCONF charters are > > > > >>>>>>> structured, but it is not our practice, > > > > >>>>>> AFAIK it was the NETMOD practice for the charters until = today. > > > > >>>>> The charters from the last couple of years don't have the > > > > >>>>> intended status -- at least the ones we checked. > > > > >>>>> > > > > >>>>> I actually feel pretty strongly about this (which of = course > > > > >>>>> can be easily overruled by our AD). It's my experience = that > > > > >>>>> premature discussions on intended status, i.e., before a > > > > >>>>> document is sufficiently mature, leads to process-focused > > > > >>>>> arguments that detracts > > > > >>> from > > > > >>>> making technical progress. > > > > >>>>> While once a document is mature and core direction/content > > > > >>>>> is fixed, it is generally obvious what status is = appropriate. > > > > >>>>> > > > > >>>>> > > > > >>>>>> I did not ask > > > > >>>>>> more than written in the current charter. > > > > >>>>>> It would be good to bring the high-level topics in = relation > > > > >>>>>> to the WG > > > > >>>> items. > > > > >>>>> I'm sorry, I don't understand this last sentence can you > rephrase > > it? > > > > >>>>> > > > > >>>>>>> as the information is available at the top of each = draft, > > > > >>>>>>> and also because > > > > >>>>> this information need not be fixed when the milestone is = added. > > > > >>>>> > > > > >>>>>> I believe a WG charter should be self-sufficient covering > > > > >>>>>> the target definition and intended status of the WG = items. > > > > >>>>>> Otherwise one can change the target for a WG item by = simply > > > > >>>>>> editing the draft abstract anytime. > > > > >>>>> Per IETF process, all it ever takes to make a change in > > > > >>>>> document status is WG consensus, and then IESG and IETF > > > > >>>>> buy-in as part of the > > > > >>>> publication process. > > > > >>>>>> BTW: We agreed in diverse discussions that the DS concept > > > > >>>>>> is Informational in nature. > > > > >>>>>> I think this should be corrected in the draft. > > > > >>>>> So this sounds like an objection to a specific document. > > > > >>>>> This is a fair point to raise, but in our opinion it is = not > > > > >>>>> a charter impacting point or discussion. If this is in = fact > > > > >>>>> the issue you'd like to raise and discuss, lets do so = under > > > > >>>>> a document specific thread, e.g., > > > > >>> "Subject: > > > > >>>>> intended status of revised-datastore". > > > > >>>>> > > > > >>>>> Thanks, > > > > >>>>> Lou > > > > >>>>> > > > > >>>>>> Mehmet > > > > >>>>>> > > > > >>>>>>> -----Original Message----- > > > > >>>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf > Of > > > > Kent > > > > >>>>>>> Watsen > > > > >>>>>>> Sent: Wednesday, March 8, 2017 7:45 PM > > > > >>>>>>> To: netmod@ietf.org > > > > >>>>>>> Cc: netmod-chairs@ietf.org > > > > >>>>>>> Subject: Re: [netmod] draft netmod charter update = proposal > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> Hi NETMOD WG, > > > > >>>>>>> > > > > >>>>>>> Please find below draft-4 having the following change: > > > > >>>>>>> > > > > >>>>>>> - added "(e.g., I2RS, RTGWG)" to a sentence. > > > > >>>>>>> > > > > >>>>>>> Hi Sue, Lou and I looked at the proposed charter and = found > > > > >>>>>>> a sentence that nicely describes our WG's intent to work > > > > >>>>>>> with and support other WGs (beyond NETCONF), but we felt > > > > >>>>>>> that > > the > > > > >>>>>>> text could be made more clear by adding in the > > > > >>>>>>> above-mentioned > > > > change. > > > > >>>>>>> Beyond this, and the existing a), > > > > >>>>>> b), > > > > >>>>>>> and c), we believe that the charter proposal covers our > > > > >>>>>>> support for I2RS, > > > > >>>>>> do > > > > >>>>>>> you agree? > > > > >>>>>>> > > > > >>>>>>> Hi Mehmet, regarding putting a short description and the > > > > >>>>>>> intended status > > > > >>>>>> for > > > > >>>>>>> each draft into the charter, we understand that this is > > > > >>>>>>> how NETCONF > > > > >>>>>> charters > > > > >>>>>>> are structured, but it is not our practice, as the > > > > >>>>>>> information is > > > > >>>>>> available at the > > > > >>>>>>> top of each draft, and also because this information = need > > > > >>>>>>> not be fixed > > > > >>>>>> when > > > > >>>>>>> the milestone is added. > > > > >>>>>>> > > > > >>>>>>> All, Any other comments? > > > > >>>>>>> > > > > >>>>>>> Kent > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> Network Modeling (NETMOD) > > > > >>>>>>> ------------------------- > > > > >>>>>>> > > > > >>>>>>> Charter > > > > >>>>>>> > > > > >>>>>>> Current Status: Active > > > > >>>>>>> > > > > >>>>>>> Chairs: > > > > >>>>>>> Lou Berger > > > > >>>>>>> Kent Watsen > > > > >>>>>>> > > > > >>>>>>> Operations and Management Area Directors: > > > > >>>>>>> Benoit Claise > > > > >>>>>>> Joel Jaeggli > > > > >>>>>>> > > > > >>>>>>> Operations and Management Area Advisor: > > > > >>>>>>> Benoit Claise > > > > >>>>>>> > > > > >>>>>>> Secretary: > > > > >>>>>>> Zitao (Michael) Wang > > > > >>>>>>> > > > > >>>>>>> Mailing Lists: > > > > >>>>>>> General Discussion: netmod@ietf.org > > > > >>>>>>> To Subscribe: > > > https://www.ietf.org/mailman/listinfo/netmod > > > > >>>>>>> Archive: > > > > >>> https://mailarchive.ietf.org/arch/browse/netmod/ > > > > >>>>>>> Description of Working Group: > > > > >>>>>>> > > > > >>>>>>> The Network Modeling (NETMOD) working group is > > > > >>>>>>> responsible for the YANG > > > > >>>>>>> data modeling language, and guidelines for developing > > > > >>>>>>> YANG > > > > >> models. > > > > >>>>> The > > > > >>>>>>> NETMOD working group addresses general topics related > > > > >>>>>>> to the use of > > > > >>>>> the > > > > >>>>>>> YANG language and YANG models, for example, the > mapping > > > > >>>>>>> of > > > > >> YANG > > > > >>>>>>> modeled > > > > >>>>>>> data into various encodings. Finally, the NETMOD > > > > >>>>>>> working > > > group > > > > >>>>>>> also defines core YANG models used as basic YANG > > > > >>>>>>> building blocks, > > > > >>>> and > > > > >>>>>>> YANG models that do not otherwise fall under the > > > > >>>>>>> charter of any > > > > >>> other > > > > >>>>>>> IETF working group. > > > > >>>>>>> > > > > >>>>>>> The NETMOD WG is responsible for: > > > > >>>>>>> > > > > >>>>>>> a) Maintaining the data modeling language YANG. This > > > > >>>>>>> effort > > > > >>> entails > > > > >>>>>>> periodically updating the specification to address > > > > >>>>>>> new > > > > >>> requirements > > > > >>>>>>> as they arise. > > > > >>>>>>> > > > > >>>>>>> b) Maintaining the guidelines for developing YANG = models. > > > > >>>>>>> This > > > > >>> effort > > > > >>>>>>> is primarily driven by updates made to the YANG > > specification. > > > > >>>>>>> > > > > >>>>>>> c) Maintaining a conceptual framework in which YANG > > > > >>>>>>> models are > > > > >>>> used. > > > > >>>>>>> This effort entails describing the generic context > > > > >>>>>>> that in > > > > > YANG > > > > >>>>>>> exists and how certain YANG statements interact in > > > > >>>>>>> that > > > > >>> context. > > > > >>>>>>> An example of this is YANG's relationship with > datastores. > > > > >>>>>>> > > > > >>>>>>> d) Maintaining encodings for YANG modeled data. This > > > > >>>>>>> effort > > > > >>> entails > > > > >>>>>>> updating encodings already defined by the NETMOD > > > > >>>>>>> working (XML > > > > >>>> and > > > > >>>>>>> JSON) to accommodate changes to the YANG > > > > >>>>>>> specification, and > > > > >>>>> defining > > > > >>>>>>> new encodings that are needed, and yet do not fall > > > > >>>>>>> under the > > > > >>> charter > > > > >>>>>>> of any other active IETF working group. > > > > >>>>>>> > > > > >>>>>>> e) Maintaining YANG models used as basic YANG = building > > > blocks. > > > > >>> This > > > > >>>>>>> effort entails updating existing YANG models > > > > >>>>>>> (ietf-yang-types > > > > >>> and > > > > >>>>>>> ietf-inet-types) as needed, as well as defining > > > > >>>>>>> additional core > > > > >>> YANG > > > > >>>>>>> data models when necessary. > > > > >>>>>>> > > > > >>>>>>> f) Defining and maintaining YANG models that do not > > > > >>>>>>> fall under > > > > > the > > > > >>>>>>> charter of any other active IETF working group. > > > > >>>>>>> > > > > >>>>>>> The NETMOD working group consults with the NETCONF > > > working > > > > >>>> group > > > > >>>>> to > > > > >>>>>>> ensure that new requirements are understood and can = be > > > > >>>>>>> met by > > > > >> the > > > > >>>>>>> protocols (e.g., NETCONF and RESTCONF) developed = within > > > > >>>>>>> that > > > > >>>> working > > > > >>>>>>> group. The NETMOD working group coordinates with = other > > > > >>>>>>> working > > > > >>>>> groups > > > > >>>>>>> (e.g., I2RS, RTGWG) on possible extensions to YANG to > > > > >>>>>>> address > > > > new > > > > >>>>>>> modeling requirements and, when needed, which group > > > > >>>>>>> will run > > > > the > > > > >>>>>>> process on a specific model. > > > > >>>>>>> > > > > >>>>>>> The NETMOD working group does not serve as a review > > > > >>>>>>> team for > > > > >>>> YANG > > > > >>>>>>> modules developed by other working groups. Instead, = the > > > > >>>>>>> YANG > > > > >>>>> doctors, > > > > >>>>>>> as organized by the OPS area director responsible for > network > > > > >>>>>>> management, will act as advisors for other working > > > > >>>>>>> groups and > > > > >>> provide > > > > >>>>>>> YANG reviews for the OPS area directors. > > > > >>>>>>> > > > > >>>>>>> Milestones: > > > > >>>>>>> > > > > >>>>>>> Done - Submit draft-ietf-netmod-rfc6087bis to = IESG for > > > > >>> publication > > > > >>>>>>> Mar 2017 - Submit > > > > >>>>>>> draft-ietf-netmod-yang-model-classification > > > > >>>>>>> to > > > > >>> IESG > > > > >>>>>>> for publication > > > > >>>>>>> Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG > > > > >>>>>>> for > > > > >>> publication > > > > >>>>>>> Apr 2017 - Submit draft-ietf-netmod-entity to IESG = for > > > > > publication > > > > >>>>>>> Apr 2017 - Submit draft-ietf-netmod-syslog-model to > > > > >>>>>>> IESG for > > > > >>>>>> publication > > > > >>>>>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to > > > > >>>>>>> IESG for > > > > >>>>>> publication > > > > >>>>>>> Oct 2017 - Submit = draft-ietf-netmod-revised-datastores > > > > >>>>>>> to IESG > > > > > for > > > > >>>>>>> publication > > > > >>>>>>> Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to > > > > >>>>>>> IESG > for > > > > >>>>>>> publication > > > > >>>>>>> Dec 2017 - Submit = draft-ietf-netmod-sub-intf-vlan-yang > > > > >>>>>>> to IESG > > > > > for > > > > >>>>>>> publication > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> _______________________________________________ > > > > >>>>>>> netmod mailing list > > > > >>>>>>> netmod@ietf.org > > > > >>>>>>> https://www.ietf.org/mailman/listinfo/netmod > > > > >>>>>> _______________________________________________ > > > > >>>>>> netmod mailing list > > > > >>>>>> netmod@ietf.org > > > > >>>>>> https://www.ietf.org/mailman/listinfo/netmod > > > > >>>>>> > > > > >>> > > > > >>> > > > > > > > > > > >=20 >=20 >=20 From nobody Thu Mar 23 10:45:46 2017 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 0B5EC129B09; Thu, 23 Mar 2017 10:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 0qQM6ULmeTw9; Thu, 23 Mar 2017 10:45:34 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1D4129B55; Thu, 23 Mar 2017 10:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24670; q=dns/txt; s=iport; t=1490291129; x=1491500729; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=sU0IFJP3oIFPK5FvL+9kfs/BPuYUY4zcOTCtyXZGvS0=; b=RLI5bcM1gVYjjE0STalNWUv8i8TVbjfOyGSWCB3JwdUV8HTdH6efWU9/ uikv+xDSZjsywv5zPIGx0TXxnbfczRK5MLuyyvcxpnELyJiua1OxkdtYQ 0mjJI/bc7me6aYmKGauRfzdDutgEYZhiU7+KQUNgZKGFpXmO8mY90picP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAQDICNRY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDKBC4Niig9zkFyVSYIOHwEKhS5KAoNVGAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEBASFLBAcQCw4KIAcDAgInHxEGCgMGAgEBiXoIDqokgiYrihIBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYZOggWBYYEJhCYRAQJGglqCXwWJMYxYhkyGe4M?= =?us-ascii?q?piCaBe4UqgzSGVotPiBMfOD4+CCQWCBcVQYQfgjlANYdbgi4BAQE?= X-IronPort-AV: E=Sophos;i="5.36,210,1486425600"; d="scan'208,217";a="651656564" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2017 17:45:27 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2NHjQZ3017666; Thu, 23 Mar 2017 17:45:26 GMT To: Dan Romascanu References: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> Cc: netmod@ietf.org, ccamp@ietf.org, Russ Housley From: Robert Wilton Message-ID: Date: Thu, 23 Mar 2017 17:45:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------67BA97E327E9B410164DC730" Archived-At: Subject: Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 17:45:37 -0000 This is a multi-part message in MIME format. --------------67BA97E327E9B410164DC730 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Dan, Thanks for the advice. Thankfully, David Law has been attending the 802.3cf task meetings, so he very much aware of the proposal to add new definitions to clause 30, and has offered to help find the best way through the 802.3 process to achieve the right technical goals. Thanks, Rob On 23/03/2017 16:40, Dan Romascanu wrote: > Hi Robert, > > Thank you for the answer. > > If the current IEEE 802.3 project (cp) is not chartered to make > changes in Clause 30 - these cannot be done, and you need a new > project for this purpose. Take this into consideration, as this may > become a dependency and a gating issue for the project timelines. I > suggest that you discuss this with the IEEE 802.3 chair David Law. I > am also copying Russ who is now in charge with the IETF - IEEE > relationship to make sure that he is aware about the issue. > > Regards, > > Dan > > > On Thu, Mar 23, 2017 at 5:36 PM, Robert Wilton > wrote: > > Hi Dan, > > > On 23/03/2017 07:56, Dan Romascanu wrote: >> Hi, >> >> I largely agree with the proposals of the team. >> >> I have only one comment / clarification related to the RMON >> objects which are proposed to be transferred under IEEE 802.3cp. >> As far as I remember there are some differences between the >> definitions in the RMON MIB for some of the objects and the >> Clause 30 definitions. > Unfortunately, yes there are differences. > >> What is the approach that you propose to take? > I'm trying to rationalize them all together (at least for the > parts of the MIB that we want to carry forward into YANG). > > Please see attached for a spreadsheet that shows the relationship > between the proposed 802.3 YANG counters, the existing MIBs > (IFMIB, RMON, and ETHERNET-LIKE), and 802.3 clause 30. This > doesn't yet cover the counters that I plan on adding to > draft-ietf-netmod-intf-ext-yang-04 (Drop due to invalid > destination MAC, of RMON style histogram counters). > > There will also be some text added to the 802.3cf draft that > should explain the relationship, possibly some of it may be lifted > directly from 802.3.1. > > > >> Include in IEEE 802.3cp only those objects that strictly conform >> to Clause 30 definitions, or modify / add definitions in Clause >> 30 in order to accommodate all the RMON statistics? If the later >> approach is to be taken - is IEEE 802.3cp chartered to make >> changes or add new definitions in Clause 30 of IEEE 802.3? > > A bit of both - mostly the former approach, but with a few missing > counters hopefully added to clause 30. > > Specifically, I hoping that the following counters can be added to > clause 30: > Row 17: In PFC frames (used in ETHERLIKE MIB dot3HCInPFCFrames) > Row 18: Out PFC frames (used in ETHERLIKE MIB dot3HCOutPFCFrames) > Row 19: Total Octets received (good & bad) (used in RMON MIB > etherStatsOctets) > Row 25: Frames dropped as being too short. (combined value of two > RMON MIB counters (etherStatsUndersizePkts + etherStatsFragments)) > > I think that in principal there is some support for adding these > to clause 30, and the appropriate folks in 802.3 will work out the > easiest/best mechanism to achieve this. > > Thanks, > Rob > > >> >> Regards, >> >> Dan >> >> >> On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton > > wrote: >> >> Hi, >> >> I'm participating in the 802.3 task force (802.3cf) to >> produce standard YANG models for Ethernet interfaces and >> protocols covered by the IEEE 802.3 Ethernet Working Group. >> >> As part of my involvement with that group, I want to >> highlight a couple of issues that arose in that forum that >> may be of interest to various WGs in IETF. >> >> This email, and accompanying slides, represents my personal >> views, and do not represent any formal IEEE position. >> However, both this email and the accompanying slides have >> been reviewed in an 802.3cf task force meeting, and there >> were no objections to the content, or my sending of this >> email to IETF. >> >> I also raised these issues (with an earlier set of slides) as >> part of the IETF/IEEE liaison meeting on 31st January, and >> the consensus was generally supportive of this approach, with >> the agreed next steps to contact the NETMOD and CCAMP chairs, >> which I have done, and the WGs (hence this email): >> >> >> As part of that YANG modelling work, there is an aim to >> define a clean boundary of what manageability data should be >> specified within 802.3 and what belongs outside the 802.3 >> specifications. >> >> The definition that the task force is converging on is that >> everything related to Ethernet, covered by 802.3, that can be >> expressed in terms of the 802.3 clause 30 manageability >> definitions, should be modeled in 802.3. I.e. broadly >> everything that is covered by 802.3.1 today. But any >> manageability information that cannot be related to clause 30 >> definitions should be specified outside of 802.3. Note, >> where appropriate, additional clause 30 definitions may be >> added to fix any mistakes or glaring gaps. >> >> >> To this end, there are a couple of areas between IETF and >> 802.3 that don't necessarily look like they are entirely in >> the right place, in particular: >> >> 1) The RMON MIB (RFC 2819) defines (along with other >> non-Ethernet related content) some Ethernet specific >> statistics that would be better co-located with the Ethernet >> interface YANG model being defined in 802.3cp. Hence, the >> proposal is to subsume the appropriate Ethernet statistics >> from the RMON MIB into a single combined reference set >> defined in 802.3cp. >> >> 2) The RMON MIB also defines some Ethernet specific >> statistics that can't be defined as part of 802.3cf because >> they don't relate to 802.3 clause 30 registers, but are still >> widely supported by vendors, and should be modeled in YANG. >> The proposal is that definitions related to these counters >> could be added as part of the Ethernet-like module >> draft-ietf-netmod-intf-ext-yang-03 >> , >> or perhaps a related Ethernet module in the same draft. >> >> 3) The Power-Ethernet MIB (defined in RFC 3621, but also >> referenced from RFC 7460), was originally specified in IETF, >> but ownership later transferred to 802.3 (via RFC 7448). >> Whilst working on the Power over Ethernet YANG model it has >> become clear that not all of the attributes defined in the >> MIB map to the underlying 802.3 clause 30 definitions. >> Further, it looks like parts of this YANG model would be >> better defined as extensions to the Entity YANG model being >> defined in NETMOD. The proposal is that the parts of the >> Power over Ethernet YANG model that can be directly related >> to clause 30 definitions (e.g. /pethPsePortTable/) should be >> defined in 802.3cf, but that the remaining parts (e.g., >> ///pethMainPseObjects /) can hopefully be standardized in IETF. >> >> >> Do you have any comments, or concerns, on the 3 proposals above? >> >> Regards, >> Rob Wilton >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> > > --------------67BA97E327E9B410164DC730 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Dan,

Thanks for the advice.  Thankfully, David Law has been attending the 802.3cf task meetings, so he very much aware of the proposal to add new definitions to clause 30, and has offered to help find the best way through the 802.3 process to achieve the right technical goals.

Thanks,
Rob


On 23/03/2017 16:40, Dan Romascanu wrote:
Hi Robert,

Thank you for the answer.

If the current IEEE 802.3 project (cp) is not chartered to make changes in Clause 30 - these cannot be done, and you need a new project for this purpose. Take this into consideration, as this may become a dependency and a gating issue for the project timelines. I suggest that you discuss this with the IEEE 802.3 chair David Law. I am also copying Russ who is now in charge with the IETF - IEEE relationship to make sure that he is aware about the issue.

Regards,

Dan


On Thu, Mar 23, 2017 at 5:36 PM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Dan,


On 23/03/2017 07:56, Dan Romascanu wrote:
Hi,

I largely agree with the proposals of the team.

I have only one comment / clarification related to the RMON objects which are proposed to be transferred under IEEE 802.3cp. As far as I remember there are some differences between the definitions in the RMON MIB for some of the objects and the Clause 30 definitions.
 Unfortunately, yes there are differences.

What is the approach that you propose to take?
 I'm trying to rationalize them all together (at least for the parts of the MIB that we want to carry forward into YANG).

Please see attached for a spreadsheet that shows the relationship between the proposed 802.3 YANG counters, the existing MIBs (IFMIB, RMON, and ETHERNET-LIKE), and 802.3 clause 30.  This doesn't yet cover the counters that I plan on adding to draft-ietf-netmod-intf-ext-yang-04 (Drop due to invalid destination MAC, of RMON style histogram counters).

There will also be some text added to the 802.3cf draft that should explain the relationship, possibly some of it may be lifted directly from 802.3.1.



Include in IEEE 802.3cp only those objects that strictly conform to Clause 30 definitions, or modify / add definitions in Clause 30 in order to accommodate all the RMON statistics? If the later approach is to be taken - is IEEE 802.3cp chartered to make changes or add new definitions in Clause 30 of IEEE 802.3?

A bit of both - mostly the former approach, but with a few missing counters hopefully added to clause 30. 

Specifically, I hoping that the following counters can be added to clause 30:
 Row 17: In PFC frames (used in  ETHERLIKE MIB dot3HCInPFCFrames)
 Row 18: Out PFC frames (used in ETHERLIKE MIB dot3HCOutPFCFrames)
 Row 19: Total Octets received (good & bad) (used in RMON MIB etherStatsOctets)
 Row 25: Frames dropped as being too short. (combined value of two RMON MIB counters (etherStatsUndersizePkts + etherStatsFragments))

I think that in principal there is some support for adding these to clause 30, and the appropriate folks in 802.3 will work out the easiest/best mechanism to achieve this.

Thanks,
Rob



Regards,

Dan


On Wed, Mar 22, 2017 at 5:21 PM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,

I'm participating in the 802.3 task force (802.3cf) to produce standard YANG models for Ethernet interfaces and protocols covered by the IEEE 802.3 Ethernet Working Group.

As part of my involvement with that group, I want to highlight a couple of issues that arose in that forum that may be of interest to various WGs in IETF.

This email, and accompanying slides, represents my personal views, and do not represent any formal IEEE position.  However, both this email and the accompanying slides have been reviewed in an 802.3cf task force meeting, and there were no objections to the content, or my sending of this email to IETF.

I also raised these issues (with an earlier set of slides) as part of the IETF/IEEE liaison meeting on 31st January, and the consensus was generally supportive of this approach, with the agreed next steps to contact the NETMOD and CCAMP chairs, which I have done, and the WGs (hence this email):


As part of that YANG modelling work, there is an aim to define a clean boundary of what manageability data should be specified within 802.3 and what belongs outside the 802.3 specifications.

The definition that the task force is converging on is that everything related to Ethernet, covered by 802.3, that can be expressed in terms of the 802.3 clause 30 manageability definitions, should be modeled in 802.3.  I.e. broadly everything that is covered by 802.3.1 today.  But any manageability information that cannot be related to clause 30 definitions should be specified outside of 802.3.  Note, where appropriate, additional clause 30 definitions may be added to fix any mistakes or glaring gaps.


To this end, there are a couple of areas between IETF and 802.3 that don't necessarily look like they are entirely in the right place, in particular:

1) The RMON MIB (RFC 2819) defines (along with other non-Ethernet related content) some Ethernet specific statistics that would be better co-located with the Ethernet interface YANG model being defined in 802.3cp.  Hence, the proposal is to subsume the appropriate Ethernet statistics from the RMON MIB into a single combined reference set defined in 802.3cp.

2) The RMON MIB also defines some Ethernet specific statistics that can't be defined as part of 802.3cf because they don't relate to 802.3 clause 30 registers, but are still widely supported by vendors, and should be modeled in YANG.  The proposal is that definitions related to these counters could be added as part of the Ethernet-like module draft-ietf-netmod-intf-ext-yang-03, or perhaps a related Ethernet module in the same draft.

3) The Power-Ethernet MIB (defined in RFC 3621, but also referenced from RFC 7460), was originally specified in IETF, but ownership later transferred to 802.3 (via RFC 7448).  Whilst working on the Power over Ethernet YANG model it has become clear that not all of the attributes defined in the MIB map to the underlying 802.3 clause 30 definitions.  Further, it looks like parts of this YANG model would be better defined as extensions to the Entity YANG model being defined in NETMOD.  The proposal is that the parts of the Power over Ethernet YANG model that can be directly related to clause 30 definitions (e.g. pethPsePortTable) should be defined in 802.3cf, but that the remaining parts (e.g., pethMainPseObjects ) can hopefully be standardized in IETF.


Do you have any comments, or concerns, on the 3 proposals above?

Regards,
Rob Wilton


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





--------------67BA97E327E9B410164DC730-- From nobody Thu Mar 23 13:28:30 2017 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 8EDD5131648 for ; Thu, 23 Mar 2017 13:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 sD1BVTyNwcvO for ; Thu, 23 Mar 2017 13:28:27 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0111.outbound.protection.outlook.com [104.47.38.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6A1129C06 for ; Thu, 23 Mar 2017 13:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Oh0s4Dv4NySgDFCKo7OqMV904D6Yf8nznm2W3UosRxk=; b=BkMUejXgjnQXw/RfxnIRhbyIDxIMVKFQob9jX5fC3UWYqh9rBIY+J8ZGxBm/ehX9+/oF3UKko2sLOzohp+4FzxbGqU/xrwW79jYXStvMAQoYc5He+1M8VGKiGZrImc//BbVZ2Y94wS36L4IzKgnkBtUmA4WY1JHP/Mt4e6R4+0U= Received: from CO2PR05CA044.namprd05.prod.outlook.com (10.141.241.172) by BLUPR0501MB1745.namprd05.prod.outlook.com (10.163.120.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Thu, 23 Mar 2017 20:28:18 +0000 Received: from BL2FFO11OLC006.protection.gbl (2a01:111:f400:7c09::158) by CO2PR05CA044.outlook.office365.com (2a01:111:e400:1429::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2 via Frontend Transport; Thu, 23 Mar 2017 20:28:18 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; Brocade.com; dkim=none (message not signed) header.d=none;Brocade.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11OLC006.mail.protection.outlook.com (10.173.160.95) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.977.7 via Frontend Transport; Thu, 23 Mar 2017 20:28:17 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 23 Mar 2017 13:28:13 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v2NKSBf8007136; Thu, 23 Mar 2017 13:28:12 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v2NKO4i7024020; Thu, 23 Mar 2017 16:24:05 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201703232024.v2NKO4i7024020@idle.juniper.net> To: William Ivory CC: "Dale R. Worley" , Martin Bjorklund , Nick Brown , "netmod@ietf.org" In-Reply-To: <773e1d84ad714ef7913565771bd05ea6@EMEAWP-EXMB12.corp.brocade.com> Date: Thu, 23 Mar 2017 16:24:04 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39410400002)(39840400002)(39860400002)(2980300002)(199003)(189002)(9170700003)(6246003)(50466002)(7126002)(4326008)(5660300001)(2810700001)(48376002)(53936002)(6916009)(2906002)(8676002)(2950100002)(77096006)(50986999)(7696004)(86362001)(47776003)(54356999)(5003940100001)(1076002)(105596002)(106466001)(110136004)(8936002)(54906002)(356003)(8276002)(229853002)(305945005)(53416004)(76506005)(81166006)(189998001)(38730400002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1745; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC006; 1:B5HkzJe0Iw6VZmBtMrfWJ+PKpUAWFDwijUtjydNsA+lGkvFF6syXm/FMEQ1irvBja52tAXw2PEAxM43ng9/VxijBw8HncK9n1RIC3I8sZTuRXI9kUorCTEQI+ht8CbZpj0ecCJG3TauVniiJfPM2NCKFuEHX7S6S01t391z1P5BbQaty3Bo3zXFxqM2KgfOOdqtj4vmSWkKwTx65xece3LCmcE7pJfBqU8jir/88IdZQC5mZvBhauVUtSxz8Xyf9ohlHmRdHLwZd6eKtmKKAHs4VuG0+7IS8ZT3Jxx/fkH/+xudZkcDm0uBt1V8x6f80RqyGaPX+zPKmqYCNGSVogo2+KIN55h+F9YaWWpW6vOaBN/+KcF550mXXvo9Jb1Gzyl2P0w6p9sTfy7OLOo0u49H7o1Gdtz15CusCCteOsPQ/hwvI0Ty8mRIloi85q4ZtBlDWRv+oK+OFXbbCLEw1V8S6Nk+yIrCGO/JlH9viIjOXVglsz74zR50jsi6MEUK81zpLsmd8pa9HTexRFAf+lOQlEC9vcETsPFhgvYjtqy57kjAuHg1uLQzHTrVh988I X-MS-Office365-Filtering-Correlation-Id: 9c1fcf20-5646-45ed-12c6-08d4722b23c0 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BLUPR0501MB1745; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1745; 3:xmDR4gS+poXvCSpISXt6cVulocRCZVGfijz5rOrArMlfaqP1i8Tm2Kw+Wtgs09AkS58y0RHeD/ccl9WvN0TnnhqEoPFI+p1q7D0hDVdYO6zUuubYKnJBqnFIEvRrvPxlz713gi34YJBpFWZJ/YjVgjwNMzdoyAwR0OabWuAeY3sapBHSqA0qwgyy5iOQxgVZplfAJQEHAqNCmAvgPSqFvKolQypNcwwJojuC3kHIWlbt+PyoTe6MrJsifGhoc8E+1b7dDDiDTz1nGhzsN4hdDleKysbyFCwg/8K30TDSNKGlu+B9vGU2GJEu2bN6AIt3UXETfIKyPmpjvz75KJ5IP5HTX9z1sNOGRjoNSz0EJo8BUEt8bK3z3KLLm6Jva9tBLivZ/ETuXDiSlPD5PLP24w==; 25:txigkAbUr/hxyTNTLZBodtdiVK19WTzSsWHd5NPapOe3YK9j9t+C9aD9t2Lh70CLth/aPkhJJWmkTTfZvDue59W028ECQTqUEW0AEBFns6UqmpMMMNvJ3O8/1bY6YsYqT9h5Dtshl1hys3Ae0h+Ggw5huKqBz04YeNzpaywt01mCZuaWw2WDZHJkbrcu2YmW5/4JhHCRozs6eRSnWUD5PG35v6/nQ394al0zILbs5mvLhTsHiTs4+BtiAcRND/7pXxZxMjLaZFLsKHgKaT8AtV+SpYwdS5OYFYlenzk96sNPz50Jlet7dKAp4mm6tqilpBhorUY0JgAWMZPxfuhAlGh1FzH2rxGawj45pdjcFicXaXrKeOtWe8qxdj5iV7Vy/GNT+PGQkE8CCtivB2lZVOq6GjxynjlVajb8JOyj0uXKToVXNCKsMsALEdoJ2mINLsioyVpEs5R3gQMaUD3ElA== X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1745; 31:lvvwP4kzqO+OgwSM10jTRQCFwN9796EwZcDzyJu+f5OOZ9z8niQrUcoqqQPBSyIM4IB7fw4PbsgiuN1KqrmsaM5PP+CWh3mZupS/VzEKVBk2ihWhtPSWY9aBKLeE8ZE4GnA7l13iTa5Yw/wM71k+kA1U4GEel9JKuF90mLbQBKvFfR24agqPnCFj05Lb60OTGnwlVl1GT+Ge0/wpe+beAq0peNePbdwt7tHNCbrzaBZkYKHrJaF67kN6Ud4yRhA7Uy/du0cHojPYebGe1FN9ng==; 20:VwAxUVAPTgLUn9ZKDJKy9TuqyhoIelYW8QEeWzDyy/zXpIiO/yV1yMKajwcqsjp11st3uv1AFyPSgsAI8IE04KKbdqfgsDjK+OhsctFDn8oMQAkWc4EXJjdSPAfbMXx7c6s1kkGkLYwASvYXx5O0smsPgeLyT5vm9mrftrC2gvtcqZjR8nVuLuaYEtbweoWKglsMfEeSNEOJsQyIkJazT/eGJOAoTxrl96pXd+oLR3xLLAK8IihlSimzYaqiySQ8xga56VrcWuoyIpyZXZ+rdNE9v1vRB/VS60j5tVc9EqACERyHO5pN/xe80I/LROQKAa1cpEfngz3dE6Gdv3jQm+kJzq3BOy5ThkYTbPvlxlb4Wxlj69fBVcNJZQCisbfYPZ92ywVWmdZfwFSF8HEK/2h6WcqiWhxWjDVXpW7SczN3lqJfxzmavgnB27i+YANg0tzCuxLAFo3TSo10cQZhAM4B1hESvzPPypFtbHW74erfozJoG2jcp/5gKwMqbnZq X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13018025)(13023025)(8121501046)(13024025)(13015025)(13017025)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(6072148); SRVR:BLUPR0501MB1745; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1745; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1745; 4:GoE92lvC57+j/Pu7Hk2uGBLyXwE/RzFK1MgITm9XYhimmAbjyTmlNx/ItlcO1FV7+Qd9GUaVN9tP70Opvm3w8gksIvGWxUJx+v59if46gnLr71QOzpxFtV2BjW7Z/n6/NZ/knPZK+wDUZ7Lok7t/IDsjxxqWGmflHxrD6f4Qxnec8cPAUIEImgkBr3f1BG/0u1bYMUuVD79orfFn9V83KTvMAXSLEeMyQ7I651EFRlvke1UhtBuXPodewttoFy2JcrIkPNSEmGrq3Nl1OFNWQrTzY738yA36PCTWO5+tj6dtPHHEVF141jrlbYsCh5poB2/UMchie/47tQhTRnojsE8w9z9EkL0zMK7pLOYH/GxRQpEITnuSbdzCIHGJtCZ5zvIMn1MKKlQei1KWR0FIYdy0XN2HMwlKCGv+5OML2BjlRONXQURPpdbntzhcse/gailil68Zwo3fRP73AB27/dLNPpc4+lIysxiEVavpSxULU3b4PgSk8L5WFPQ/bHRwjawqu0s7NLw7UBTO+64Vpj0lfTnrjzH0713cg+5WR4gAhmcNgDylj2wJMqflhh/FdSzwpl6PdlRtZAEf31ooDI7T3LyC8k0kxD7oCrPM56eyB0gwdzy6+hM2l3vZ9vR20Rl7LwwjNahODV9u+0LYGZX98taD8XvB3fYUijS7K5DMnASyDzwM47dM6p/KSLc7XyJ2WA9qM5o3ln52R6reGg== X-Forefront-PRVS: 0255DF69B9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB1745; 23:43DvPemg3nQeSw90mwAGeXcl5ZvQK/Eun4f43OB?= =?us-ascii?Q?nj9SwZB48e03TT+YD7tF/osE2w193N2yyO0DXtZ0309hTVsasqoUJho7V0LW?= =?us-ascii?Q?CtLHImPcNWt7UselynvOjNdMG3T8xIeP8Sv8u7KoKlskYpRAPc2Y5PtV2DSQ?= =?us-ascii?Q?JvWOFswR4K1HD5+LpDPWrWAqn6F57uyjNYrrdzjYhiSZRR+B65bz2VsIU+NB?= =?us-ascii?Q?JN7BqgRJI17z9RsjBqhFRT2sPFqZqoDwlrbI4hXoIBXkdy2QehMQSTAyFUQt?= =?us-ascii?Q?q00TAfGy50AhS8peicLcC4w44E5pgFC2tj25gBPObwWoLAO9NbsLvczgxdgF?= =?us-ascii?Q?FeqnQG1SOVTSbtVjqo4cC7F3NbMXLM4ESeBkUzs8rFYXZ2a8tW1bKtkrLtuP?= =?us-ascii?Q?GqZTYG0SfLztOZOhekqIUgRvIiKlwz17D6A0JWaYeodWSdWMjxgz/MBwAzoH?= =?us-ascii?Q?/UlWAQ1kmt0gGCSvdK4OalRohUH9tm0HBr7Qw+NjhAqnBWzUue8v45xpdOd5?= =?us-ascii?Q?v1+VspBODlNBf7giG50CVmG9wojSFUSzhQ+Pt4Twe+iuUo/t2owoA5WawQKC?= =?us-ascii?Q?CqcQjb4aG7nFyIiaTLDM0VOTsKwF3qoqh2VovM09+dCu4OujyK8EyI2qiXrU?= =?us-ascii?Q?CLoppW+zADsZv/uLJSzfmbd2AJyYGm2jVSdIIFemHEX0VOBp1lnT2ef4Qmr1?= =?us-ascii?Q?pq+VhqBjn9mMg9nL5JApuzEFHY5UovXgSfqkJMfbLjhgHNghWovsD9zrSCcb?= =?us-ascii?Q?drws/+N0cQSk3KmP13w7b60E+HOGhQUBd63gQG6ZTim8VZYCo+/+DsbzZw1E?= =?us-ascii?Q?2q2iGfpF8bLRu6a2pMzZ8EpVl63GKJ1qpTG/oRcY33D9gqoznfR/yLHtf+Hy?= =?us-ascii?Q?TyZigOIV5mqtf+89wcJyvcCWGsDlAWlgRtFDIlHX5J8EEHJwgEQN2V3GSfpY?= =?us-ascii?Q?zL1512DH/Dqkgt5anJ7ttx3ROpM6axsb9ZZhp8Avla/4F4zZacE8JpT8Gktn?= =?us-ascii?Q?7QywrWniE1HBLGQMhrLMys/7J4fVfNg5NbXeSBWyg6SJbztp3IuudmG9UAhU?= =?us-ascii?Q?Wvxsb14TlOmuBppdZH+G+/jDrZMfK1xOMZMJ1VDuPlvkO/+MLBw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1745; 6:a56NFWJJAKDfFdPgdWNOslMwue2kYZrIPnP6lBLXW1FeL5MMDkAQffyGH+8Q34lOfQfzXuG4uB6FxdAVmbGVALz6GhzKH1OL2EEgarT2ESmNA8UpurTtQyeEjE5uxM95/8GryJzJTbQmhoKl8JQEZ1lWVnz60XTzvpal7meSlJa8M1A9bC1k84WZlVbHLczauQICRr2fz56JN8Z2/UmQAJ7+9ZlxRbk8008rQZObOq35JWgIFRjZe66lPg53jJI0HQuQ4A+CEv/IxMYVJazdxmF+kXxqQR3p5c8cs4AyVHyzz5M5GXm9Aijad448QLHqapHCiiC+GU616XgGEWJAcvp5XYhthO6Lg3ftx44cl+iDilrLmS+O5goNeTb6Av7L+0gxNAPke8Sv6KlH2DSB+LJIaRk45ULMk6w59ZToEgQ=; 5:eu9QOauQIBzNFJa9VW9dpcVUfCMjbqliCLzGEn0UqPSyW348AhGlA4mGxdYy7ni7iq0HVGxHUoRtYmx5MsaOJsn1HYgfXEG2u5Zyk3dO2hZBrBW/5Vk5c1LmJuxCpr3JVUmn2+US57Gfk6b/NOya1A==; 24:6NWTe+ja00vHpDka33URIsZ7V3pjUBKHuZq/Au9mX1LRGu9nbVE1AsrjsB7AgAalVPch6YCbfOF4MXB7ywgqU09xNiclsSh0TwGlXlCwhA8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1745; 7:xpxUPXz1adZ39epuoJdCIg5WjVgMzTOv/OrBg0pp9nOMAlqTdoDD0Nr5Y3VvU0r5lozpyA/ZMNowY3ECAQWtnQmxXp9bmsb8ywKR0/A6SEj8JPjKNMT5pfwWZ4sEXiipONM0zqyVPm/SLtsDeY9HmAfJfpzMtxcUfTiRB0SUHWTKv+LBeZiiZ0EEm5OsyqWXW8v+DjQNEBBTygKLfdNpLk09fn2CHdfpAmMU0Go9x24cfUBe/JDbS3si+ee6xwRQGCO9ZgTfCHGnCyJ9AZxlbiknD1bfONpNg+We0YinK5Zjz9xOUaPaQX75RSFEBvldVAGEdGqfG5sAf0BO4UcBEQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2017 20:28:17.1289 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1745 Archived-At: Subject: Re: [netmod] Interaction of 'when' and 'default' statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 20:28:30 -0000 William Ivory writes: >Yes, I'd noticed that. Does this make the behaviour 'undefined' in YANG 1.0? No, this was a clarification. The text in 6020 was reasonably clear: The "when" statement makes its parent data definition statement conditional. The node defined by the parent data definition statement is only valid when the condition specified by the "when" statement is satisfied. And no default should be provided for any invalid node. If the node can't exist, the default can't either. Thanks, Phil From nobody Thu Mar 23 16:33:24 2017 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 D38891293E3 for ; Thu, 23 Mar 2017 16:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 QpPg5JicZZ1C for ; Thu, 23 Mar 2017 16:33:22 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99E4129511 for ; Thu, 23 Mar 2017 16:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=425; q=dns/txt; s=iport; t=1490312001; x=1491521601; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=e2KAzJ1OPCuGFuMToLILlLfv5B+HLNc/U2h9mduiT7Y=; b=L6UBwFE5WYgnX29mjcFyQXfSpvGIDVzHyAQ1rMnev5VzyVuz7ZNsWlIG Zp2UeeouPLjwFMNhxBKS95yyWoVFsu6b+T5Iyqmj9G7qFhVC1geEyvI3n J+5gi9YS2W5OCPyAAlVO8DF2sUlNN15Fu9TAHwrDojSEFPW41r69+4A0v I=; X-IronPort-AV: E=Sophos;i="5.36,212,1486425600"; d="scan'208";a="653482591" 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; 23 Mar 2017 23:33:19 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2NNXJki022580; Thu, 23 Mar 2017 23:33:19 GMT To: NETMOD Working Group Cc: "Joe Clarke (jclarke)" From: Benoit Claise Message-ID: <02834066-3540-790e-bdda-abc5d90bfdac@cisco.com> Date: Thu, 23 Mar 2017 18:33:20 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] file "ietf-foo@2016-03-20.yang" or file "ietf-foo.yang" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 23:33:24 -0000 Dear all, [Preparing the IETF hackathon] https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis#section-4.2 What is the guideline regarding: file "ietf-foo@2016-03-20.yang" versus file "ietf-foo.yang" Right now, we have a mix of behaviors. This implies that the extracted YANG modules sometimes contains the revision, but not always. Regards, Benoit From nobody Thu Mar 23 17:47:11 2017 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 B9D98124B0A; Thu, 23 Mar 2017 17:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCxxcZOSXqO0; Thu, 23 Mar 2017 17:47:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841AD129AC9; Thu, 23 Mar 2017 17:46:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJM31639; Fri, 24 Mar 2017 00:46:55 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 24 Mar 2017 00:46:54 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.110]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 24 Mar 2017 08:46:47 +0800 From: "Zhuangyan (Yan)" To: Robert Wilton , Dan Romascanu CC: "ccamp@ietf.org" , Russ Housley , "netmod@ietf.org" Thread-Topic: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap Thread-Index: AQHSoyAwoq56LyDgkkKNUB+ZJ9Ayv6GhiacAgACAXICAABIIgIAAEhcAgADzpzA= Date: Fri, 24 Mar 2017 00:46:46 +0000 Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785A951C2D0@nkgeml513-mbx.china.huawei.com> References: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.170.230] Content-Type: multipart/alternative; boundary="_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A951C2D0nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58D46C80.00CA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.110, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5c028b526b4770f27ea2d830a29d4bf6 Archived-At: Subject: Re: [netmod] 802.3 Ethernet YANG (802.3cp) and IETF overlap X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 00:47:04 -0000 --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A951C2D0nkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpTb3JyeSwgYSBsaXR0bGUgYmVoaW5kIHRoaXMgZGlzY3Vzc2lvbuKApiBzb21l IGNvbmNsdXNpb25zIGZyb20gbGFzdCB3ZWVr4oCZcyBJRUVFIDgwMi4zY2YgbWVldGluZy4NCg0K WWVzLCB0aGUgODAyLjNjZiBwcm9qZWN0IGlzIG5vdCBjaGFydGVyZWQgdG8gbW9kaWZ5IHRoZSBD bGF1c2UgMzAsIGJ1dCB3ZSBkaXNjdXNzZWQgdGhlIHBvc3NpYmlsaXR5IG9mIGhhdmluZyB1c2Vm dWwgYXR0cmlidXRlcyBmcm9tIGV4aXN0aW5nIE1JQiBidXQgYmV5b25kIENsYXVzZSAzMCBmb3Ig bWFuYWdlbWVudC4NClRoZSBjb25jbHVzaW9uIGlzIHllcywgdGhlIGdyb3VwIGFncmVlZCB0byBo YXZlIHRob3NlIGF0dHJpYnV0ZXMgaW4gbW9kdWxlcyB3aGlsZSBQODAyLjNjZiAoODAyLjMuMikg d291bGQgYWRkIGFuIGFubmV4IHRvIGludHJvZHVjZSB0aG9zZSBhdHRyaWJ1dGVzIGFuZCBwcm92 aWRlIHJlZmVyZW5jZXMgdG8gc3RhbmRhcmRzIG91dHNpZGUgODAyLjMgYXMgc3VnZ2VzdGlvbnMg dG8gQ2xhdXNlIDMwLg0KDQpBcyBhIGZvbGxvdy11cCwgdGhlIElFRUUgODAyLjMgd2lsbCBkaXNj dXNzIGFuZCBkZWNpZGUgaG93IHRvIGFkZCB0aG9zZSBhdHRyaWJ1dGVzIGZyb20gdGhhdCBhbm5l eCB0byBDbGF1c2UgMzAuDQpJZiBubyBmZWF0dXJlcywgdGhlbiBpdCBjYW4gYmUgZG9uZSBieSBz dWJtaXR0aW5nIGNvbW1lbnRzIHRvIE1haW50ZW5hbmNlIEdyb3VwLiBJZiAgdGhvc2UgYXJlIG5l dyBmZWF0dXJlcywgYSBuZXcgcHJvamVjdCBvciBhIGV4aXN0aW5nIHByb2plY3QgdGhhdCBjYW4g bW9kaWZ5IENsYXVzZSAzMCB3b3VsZCBiZSBuZWVkZWQuDQpJbiBzdWNoIHdheSwgdGhlIFlBTkcg cHJvamVjdCBpdHNlbGYgd291bGQgZ2V0IGFsb25nIHdlbGwgd2l0aCB0aGUgcHJvamVjdCB0aW1l bGluZS4NCg0KQmVzaWRlcywgZm9yIHRoZSA0IHByb3Bvc2VkIGF0dHJpYnV0ZXM6DQpSb3cgMTc6 IEluIFBGQyBmcmFtZXMgKHVzZWQgaW4gIEVUSEVSTElLRSBNSUIgZG90M0hDSW5QRkNGcmFtZXMp DQogUm93IDE4OiBPdXQgUEZDIGZyYW1lcyAodXNlZCBpbiBFVEhFUkxJS0UgTUlCIGRvdDNIQ091 dFBGQ0ZyYW1lcykNCiBSb3cgMTk6IFRvdGFsIE9jdGV0cyByZWNlaXZlZCAoZ29vZCAmIGJhZCkg KHVzZWQgaW4gUk1PTiBNSUIgZXRoZXJTdGF0c09jdGV0cykNCiBSb3cgMjU6IEZyYW1lcyBkcm9w cGVkIGFzIGJlaW5nIHRvbyBzaG9ydC4gKGNvbWJpbmVkIHZhbHVlIG9mIHR3byBSTU9OIE1JQiBj b3VudGVycyAoZXRoZXJTdGF0c1VuZGVyc2l6ZVBrdHMgKyBldGhlclN0YXRzRnJhZ21lbnRzKSkN Cg0KVGhlIEV0aGVybmV0IEludGVyZmFjZSBtb2R1bGUgaGFzIGJlZW4gYWRvcHRlZCB3aXRoIHRo ZXNlIGF0dHJpYnV0ZXMgYW5kIGluY2x1ZGVkIGluIEQwLjEgIDogKS4gQnV0IHdlIGhhdmVu4oCZ dCBwdXQgdGhlc2UgYXR0cmlidXRlcyBpbnRvIHRoZSBhbm5leCBhcyBzdWdnZXN0ZWQgYXR0cmli dXRlcyB0byBDbGF1c2UgMzAuDQpZb3UgY2FuIHN1Ym1pdCBjb21tZW50cyB0byBhZGQgdGhlbS4g QW5kIGlmIG1vcmUgYXR0cmlidXRlcyBhcmUgc3VnZ2VzdGVkLCBwbGVhc2UgZmVlbCBmcmVlIHRv IHByb3Bvc2UuDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2h+DQoNCkJlc3QgUmVnYXJkcywNCg0KWWFu DQoNCg0K5Y+R5Lu25Lq6OiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10g 5Luj6KGoIFJvYmVydCBXaWx0b24NCuWPkemAgeaXtumXtDogMjAxN+W5tDPmnIgyNOaXpSAxOjQ1 DQrmlLbku7bkuro6IERhbiBSb21hc2NhbnUNCuaKhOmAgTogY2NhbXBAaWV0Zi5vcmc7IFJ1c3Mg SG91c2xleTsgbmV0bW9kQGlldGYub3JnDQrkuLvpopg6IFJlOiBbbmV0bW9kXSA4MDIuMyBFdGhl cm5ldCBZQU5HICg4MDIuM2NwKSBhbmQgSUVURiBvdmVybGFwDQoNCg0KSGkgRGFuLA0KDQpUaGFu a3MgZm9yIHRoZSBhZHZpY2UuICBUaGFua2Z1bGx5LCBEYXZpZCBMYXcgaGFzIGJlZW4gYXR0ZW5k aW5nIHRoZSA4MDIuM2NmIHRhc2sgbWVldGluZ3MsIHNvIGhlIHZlcnkgbXVjaCBhd2FyZSBvZiB0 aGUgcHJvcG9zYWwgdG8gYWRkIG5ldyBkZWZpbml0aW9ucyB0byBjbGF1c2UgMzAsIGFuZCBoYXMg b2ZmZXJlZCB0byBoZWxwIGZpbmQgdGhlIGJlc3Qgd2F5IHRocm91Z2ggdGhlIDgwMi4zIHByb2Nl c3MgdG8gYWNoaWV2ZSB0aGUgcmlnaHQgdGVjaG5pY2FsIGdvYWxzLg0KDQpUaGFua3MsDQpSb2IN Cg0KT24gMjMvMDMvMjAxNyAxNjo0MCwgRGFuIFJvbWFzY2FudSB3cm90ZToNCkhpIFJvYmVydCwN ClRoYW5rIHlvdSBmb3IgdGhlIGFuc3dlci4NCklmIHRoZSBjdXJyZW50IElFRUUgODAyLjMgcHJv amVjdCAoY3ApIGlzIG5vdCBjaGFydGVyZWQgdG8gbWFrZSBjaGFuZ2VzIGluIENsYXVzZSAzMCAt IHRoZXNlIGNhbm5vdCBiZSBkb25lLCBhbmQgeW91IG5lZWQgYSBuZXcgcHJvamVjdCBmb3IgdGhp cyBwdXJwb3NlLiBUYWtlIHRoaXMgaW50byBjb25zaWRlcmF0aW9uLCBhcyB0aGlzIG1heSBiZWNv bWUgYSBkZXBlbmRlbmN5IGFuZCBhIGdhdGluZyBpc3N1ZSBmb3IgdGhlIHByb2plY3QgdGltZWxp bmVzLiBJIHN1Z2dlc3QgdGhhdCB5b3UgZGlzY3VzcyB0aGlzIHdpdGggdGhlIElFRUUgODAyLjMg Y2hhaXIgRGF2aWQgTGF3LiBJIGFtIGFsc28gY29weWluZyBSdXNzIHdobyBpcyBub3cgaW4gY2hh cmdlIHdpdGggdGhlIElFVEYgLSBJRUVFIHJlbGF0aW9uc2hpcCB0byBtYWtlIHN1cmUgdGhhdCBo ZSBpcyBhd2FyZSBhYm91dCB0aGUgaXNzdWUuDQpSZWdhcmRzLA0KRGFuDQoNCk9uIFRodSwgTWFy IDIzLCAyMDE3IGF0IDU6MzYgUE0sIFJvYmVydCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29tPG1h aWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSBEYW4sDQoNCk9uIDIzLzAzLzIw MTcgMDc6NTYsIERhbiBSb21hc2NhbnUgd3JvdGU6DQpIaSwNCkkgbGFyZ2VseSBhZ3JlZSB3aXRo IHRoZSBwcm9wb3NhbHMgb2YgdGhlIHRlYW0uDQpJIGhhdmUgb25seSBvbmUgY29tbWVudCAvIGNs YXJpZmljYXRpb24gcmVsYXRlZCB0byB0aGUgUk1PTiBvYmplY3RzIHdoaWNoIGFyZSBwcm9wb3Nl ZCB0byBiZSB0cmFuc2ZlcnJlZCB1bmRlciBJRUVFIDgwMi4zY3AuIEFzIGZhciBhcyBJIHJlbWVt YmVyIHRoZXJlIGFyZSBzb21lIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIGRlZmluaXRpb25zIGlu IHRoZSBSTU9OIE1JQiBmb3Igc29tZSBvZiB0aGUgb2JqZWN0cyBhbmQgdGhlIENsYXVzZSAzMCBk ZWZpbml0aW9ucy4NClVuZm9ydHVuYXRlbHksIHllcyB0aGVyZSBhcmUgZGlmZmVyZW5jZXMuDQoN Cg0KV2hhdCBpcyB0aGUgYXBwcm9hY2ggdGhhdCB5b3UgcHJvcG9zZSB0byB0YWtlPw0KSSdtIHRy eWluZyB0byByYXRpb25hbGl6ZSB0aGVtIGFsbCB0b2dldGhlciAoYXQgbGVhc3QgZm9yIHRoZSBw YXJ0cyBvZiB0aGUgTUlCIHRoYXQgd2Ugd2FudCB0byBjYXJyeSBmb3J3YXJkIGludG8gWUFORyku DQoNClBsZWFzZSBzZWUgYXR0YWNoZWQgZm9yIGEgc3ByZWFkc2hlZXQgdGhhdCBzaG93cyB0aGUg cmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHByb3Bvc2VkIDgwMi4zIFlBTkcgY291bnRlcnMsIHRo ZSBleGlzdGluZyBNSUJzIChJRk1JQiwgUk1PTiwgYW5kIEVUSEVSTkVULUxJS0UpLCBhbmQgODAy LjMgY2xhdXNlIDMwLiAgVGhpcyBkb2Vzbid0IHlldCBjb3ZlciB0aGUgY291bnRlcnMgdGhhdCBJ IHBsYW4gb24gYWRkaW5nIHRvIGRyYWZ0LWlldGYtbmV0bW9kLWludGYtZXh0LXlhbmctMDQgKERy b3AgZHVlIHRvIGludmFsaWQgZGVzdGluYXRpb24gTUFDLCBvZiBSTU9OIHN0eWxlIGhpc3RvZ3Jh bSBjb3VudGVycykuDQoNClRoZXJlIHdpbGwgYWxzbyBiZSBzb21lIHRleHQgYWRkZWQgdG8gdGhl IDgwMi4zY2YgZHJhZnQgdGhhdCBzaG91bGQgZXhwbGFpbiB0aGUgcmVsYXRpb25zaGlwLCBwb3Nz aWJseSBzb21lIG9mIGl0IG1heSBiZSBsaWZ0ZWQgZGlyZWN0bHkgZnJvbSA4MDIuMy4xLg0KDQoN Cg0KDQpJbmNsdWRlIGluIElFRUUgODAyLjNjcCBvbmx5IHRob3NlIG9iamVjdHMgdGhhdCBzdHJp Y3RseSBjb25mb3JtIHRvIENsYXVzZSAzMCBkZWZpbml0aW9ucywgb3IgbW9kaWZ5IC8gYWRkIGRl ZmluaXRpb25zIGluIENsYXVzZSAzMCBpbiBvcmRlciB0byBhY2NvbW1vZGF0ZSBhbGwgdGhlIFJN T04gc3RhdGlzdGljcz8gSWYgdGhlIGxhdGVyIGFwcHJvYWNoIGlzIHRvIGJlIHRha2VuIC0gaXMg SUVFRSA4MDIuM2NwIGNoYXJ0ZXJlZCB0byBtYWtlIGNoYW5nZXMgb3IgYWRkIG5ldyBkZWZpbml0 aW9ucyBpbiBDbGF1c2UgMzAgb2YgSUVFRSA4MDIuMz8NCg0KQSBiaXQgb2YgYm90aCAtIG1vc3Rs eSB0aGUgZm9ybWVyIGFwcHJvYWNoLCBidXQgd2l0aCBhIGZldyBtaXNzaW5nIGNvdW50ZXJzIGhv cGVmdWxseSBhZGRlZCB0byBjbGF1c2UgMzAuDQoNClNwZWNpZmljYWxseSwgSSBob3BpbmcgdGhh dCB0aGUgZm9sbG93aW5nIGNvdW50ZXJzIGNhbiBiZSBhZGRlZCB0byBjbGF1c2UgMzA6DQogUm93 IDE3OiBJbiBQRkMgZnJhbWVzICh1c2VkIGluICBFVEhFUkxJS0UgTUlCIGRvdDNIQ0luUEZDRnJh bWVzKQ0KIFJvdyAxODogT3V0IFBGQyBmcmFtZXMgKHVzZWQgaW4gRVRIRVJMSUtFIE1JQiBkb3Qz SENPdXRQRkNGcmFtZXMpDQogUm93IDE5OiBUb3RhbCBPY3RldHMgcmVjZWl2ZWQgKGdvb2QgJiBi YWQpICh1c2VkIGluIFJNT04gTUlCIGV0aGVyU3RhdHNPY3RldHMpDQogUm93IDI1OiBGcmFtZXMg ZHJvcHBlZCBhcyBiZWluZyB0b28gc2hvcnQuIChjb21iaW5lZCB2YWx1ZSBvZiB0d28gUk1PTiBN SUIgY291bnRlcnMgKGV0aGVyU3RhdHNVbmRlcnNpemVQa3RzICsgZXRoZXJTdGF0c0ZyYWdtZW50 cykpDQoNCkkgdGhpbmsgdGhhdCBpbiBwcmluY2lwYWwgdGhlcmUgaXMgc29tZSBzdXBwb3J0IGZv ciBhZGRpbmcgdGhlc2UgdG8gY2xhdXNlIDMwLCBhbmQgdGhlIGFwcHJvcHJpYXRlIGZvbGtzIGlu IDgwMi4zIHdpbGwgd29yayBvdXQgdGhlIGVhc2llc3QvYmVzdCBtZWNoYW5pc20gdG8gYWNoaWV2 ZSB0aGlzLg0KDQpUaGFua3MsDQpSb2INCg0KDQoNCg0KUmVnYXJkcywNCkRhbg0KDQpPbiBXZWQs IE1hciAyMiwgMjAxNyBhdCA1OjIxIFBNLCBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNpc2NvLmNv bTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PiB3cm90ZToNCg0KSGksDQoNCkknbSBwYXJ0aWNp cGF0aW5nIGluIHRoZSA4MDIuMyB0YXNrIGZvcmNlICg4MDIuM2NmKSB0byBwcm9kdWNlIHN0YW5k YXJkIFlBTkcgbW9kZWxzIGZvciBFdGhlcm5ldCBpbnRlcmZhY2VzIGFuZCBwcm90b2NvbHMgY292 ZXJlZCBieSB0aGUgSUVFRSA4MDIuMyBFdGhlcm5ldCBXb3JraW5nIEdyb3VwLg0KDQpBcyBwYXJ0 IG9mIG15IGludm9sdmVtZW50IHdpdGggdGhhdCBncm91cCwgSSB3YW50IHRvIGhpZ2hsaWdodCBh IGNvdXBsZSBvZiBpc3N1ZXMgdGhhdCBhcm9zZSBpbiB0aGF0IGZvcnVtIHRoYXQgbWF5IGJlIG9m IGludGVyZXN0IHRvIHZhcmlvdXMgV0dzIGluIElFVEYuDQoNClRoaXMgZW1haWwsIGFuZCBhY2Nv bXBhbnlpbmcgc2xpZGVzLCByZXByZXNlbnRzIG15IHBlcnNvbmFsIHZpZXdzLCBhbmQgZG8gbm90 IHJlcHJlc2VudCBhbnkgZm9ybWFsIElFRUUgcG9zaXRpb24uICBIb3dldmVyLCBib3RoIHRoaXMg ZW1haWwgYW5kIHRoZSBhY2NvbXBhbnlpbmcgc2xpZGVzIGhhdmUgYmVlbiByZXZpZXdlZCBpbiBh biA4MDIuM2NmIHRhc2sgZm9yY2UgbWVldGluZywgYW5kIHRoZXJlIHdlcmUgbm8gb2JqZWN0aW9u cyB0byB0aGUgY29udGVudCwgb3IgbXkgc2VuZGluZyBvZiB0aGlzIGVtYWlsIHRvIElFVEYuDQoN CkkgYWxzbyByYWlzZWQgdGhlc2UgaXNzdWVzICh3aXRoIGFuIGVhcmxpZXIgc2V0IG9mIHNsaWRl cykgYXMgcGFydCBvZiB0aGUgSUVURi9JRUVFIGxpYWlzb24gbWVldGluZyBvbiAzMXN0IEphbnVh cnksIGFuZCB0aGUgY29uc2Vuc3VzIHdhcyBnZW5lcmFsbHkgc3VwcG9ydGl2ZSBvZiB0aGlzIGFw cHJvYWNoLCB3aXRoIHRoZSBhZ3JlZWQgbmV4dCBzdGVwcyB0byBjb250YWN0IHRoZSBORVRNT0Qg YW5kIENDQU1QIGNoYWlycywgd2hpY2ggSSBoYXZlIGRvbmUsIGFuZCB0aGUgV0dzIChoZW5jZSB0 aGlzIGVtYWlsKToNCg0KDQoNCkFzIHBhcnQgb2YgdGhhdCBZQU5HIG1vZGVsbGluZyB3b3JrLCB0 aGVyZSBpcyBhbiBhaW0gdG8gZGVmaW5lIGEgY2xlYW4gYm91bmRhcnkgb2Ygd2hhdCBtYW5hZ2Vh YmlsaXR5IGRhdGEgc2hvdWxkIGJlIHNwZWNpZmllZCB3aXRoaW4gODAyLjMgYW5kIHdoYXQgYmVs b25ncyBvdXRzaWRlIHRoZSA4MDIuMyBzcGVjaWZpY2F0aW9ucy4NCg0KVGhlIGRlZmluaXRpb24g dGhhdCB0aGUgdGFzayBmb3JjZSBpcyBjb252ZXJnaW5nIG9uIGlzIHRoYXQgZXZlcnl0aGluZyBy ZWxhdGVkIHRvIEV0aGVybmV0LCBjb3ZlcmVkIGJ5IDgwMi4zLCB0aGF0IGNhbiBiZSBleHByZXNz ZWQgaW4gdGVybXMgb2YgdGhlIDgwMi4zIGNsYXVzZSAzMCBtYW5hZ2VhYmlsaXR5IGRlZmluaXRp b25zLCBzaG91bGQgYmUgbW9kZWxlZCBpbiA4MDIuMy4gIEkuZS4gYnJvYWRseSBldmVyeXRoaW5n IHRoYXQgaXMgY292ZXJlZCBieSA4MDIuMy4xIHRvZGF5LiAgQnV0IGFueSBtYW5hZ2VhYmlsaXR5 IGluZm9ybWF0aW9uIHRoYXQgY2Fubm90IGJlIHJlbGF0ZWQgdG8gY2xhdXNlIDMwIGRlZmluaXRp b25zIHNob3VsZCBiZSBzcGVjaWZpZWQgb3V0c2lkZSBvZiA4MDIuMy4gIE5vdGUsIHdoZXJlIGFw cHJvcHJpYXRlLCBhZGRpdGlvbmFsIGNsYXVzZSAzMCBkZWZpbml0aW9ucyBtYXkgYmUgYWRkZWQg dG8gZml4IGFueSBtaXN0YWtlcyBvciBnbGFyaW5nIGdhcHMuDQoNCg0KDQpUbyB0aGlzIGVuZCwg dGhlcmUgYXJlIGEgY291cGxlIG9mIGFyZWFzIGJldHdlZW4gSUVURiBhbmQgODAyLjMgdGhhdCBk b24ndCBuZWNlc3NhcmlseSBsb29rIGxpa2UgdGhleSBhcmUgZW50aXJlbHkgaW4gdGhlIHJpZ2h0 IHBsYWNlLCBpbiBwYXJ0aWN1bGFyOg0KDQoxKSBUaGUgUk1PTiBNSUIgKFJGQyAyODE5KSBkZWZp bmVzIChhbG9uZyB3aXRoIG90aGVyIG5vbi1FdGhlcm5ldCByZWxhdGVkIGNvbnRlbnQpIHNvbWUg RXRoZXJuZXQgc3BlY2lmaWMgc3RhdGlzdGljcyB0aGF0IHdvdWxkIGJlIGJldHRlciBjby1sb2Nh dGVkIHdpdGggdGhlIEV0aGVybmV0IGludGVyZmFjZSBZQU5HIG1vZGVsIGJlaW5nIGRlZmluZWQg aW4gODAyLjNjcC4gIEhlbmNlLCB0aGUgcHJvcG9zYWwgaXMgdG8gc3Vic3VtZSB0aGUgYXBwcm9w cmlhdGUgRXRoZXJuZXQgc3RhdGlzdGljcyBmcm9tIHRoZSBSTU9OIE1JQiBpbnRvIGEgc2luZ2xl IGNvbWJpbmVkIHJlZmVyZW5jZSBzZXQgZGVmaW5lZCBpbiA4MDIuM2NwLg0KDQoyKSBUaGUgUk1P TiBNSUIgYWxzbyBkZWZpbmVzIHNvbWUgRXRoZXJuZXQgc3BlY2lmaWMgc3RhdGlzdGljcyB0aGF0 IGNhbid0IGJlIGRlZmluZWQgYXMgcGFydCBvZiA4MDIuM2NmIGJlY2F1c2UgdGhleSBkb24ndCBy ZWxhdGUgdG8gODAyLjMgY2xhdXNlIDMwIHJlZ2lzdGVycywgYnV0IGFyZSBzdGlsbCB3aWRlbHkg c3VwcG9ydGVkIGJ5IHZlbmRvcnMsIGFuZCBzaG91bGQgYmUgbW9kZWxlZCBpbiBZQU5HLiAgVGhl IHByb3Bvc2FsIGlzIHRoYXQgZGVmaW5pdGlvbnMgcmVsYXRlZCB0byB0aGVzZSBjb3VudGVycyBj b3VsZCBiZSBhZGRlZCBhcyBwYXJ0IG9mIHRoZSBFdGhlcm5ldC1saWtlIG1vZHVsZSBkcmFmdC1p ZXRmLW5ldG1vZC1pbnRmLWV4dC15YW5nLTAzPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtbmV0bW9kLWludGYtZXh0LXlhbmcvPiwgb3IgcGVyaGFwcyBhIHJlbGF0 ZWQgRXRoZXJuZXQgbW9kdWxlIGluIHRoZSBzYW1lIGRyYWZ0Lg0KDQozKSBUaGUgUG93ZXItRXRo ZXJuZXQgTUlCIChkZWZpbmVkIGluIFJGQyAzNjIxLCBidXQgYWxzbyByZWZlcmVuY2VkIGZyb20g UkZDIDc0NjApLCB3YXMgb3JpZ2luYWxseSBzcGVjaWZpZWQgaW4gSUVURiwgYnV0IG93bmVyc2hp cCBsYXRlciB0cmFuc2ZlcnJlZCB0byA4MDIuMyAodmlhIFJGQyA3NDQ4KS4gIFdoaWxzdCB3b3Jr aW5nIG9uIHRoZSBQb3dlciBvdmVyIEV0aGVybmV0IFlBTkcgbW9kZWwgaXQgaGFzIGJlY29tZSBj bGVhciB0aGF0IG5vdCBhbGwgb2YgdGhlIGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiB0aGUgTUlCIG1h cCB0byB0aGUgdW5kZXJseWluZyA4MDIuMyBjbGF1c2UgMzAgZGVmaW5pdGlvbnMuICBGdXJ0aGVy LCBpdCBsb29rcyBsaWtlIHBhcnRzIG9mIHRoaXMgWUFORyBtb2RlbCB3b3VsZCBiZSBiZXR0ZXIg ZGVmaW5lZCBhcyBleHRlbnNpb25zIHRvIHRoZSBFbnRpdHkgWUFORyBtb2RlbCBiZWluZyBkZWZp bmVkIGluIE5FVE1PRC4gIFRoZSBwcm9wb3NhbCBpcyB0aGF0IHRoZSBwYXJ0cyBvZiB0aGUgUG93 ZXIgb3ZlciBFdGhlcm5ldCBZQU5HIG1vZGVsIHRoYXQgY2FuIGJlIGRpcmVjdGx5IHJlbGF0ZWQg dG8gY2xhdXNlIDMwIGRlZmluaXRpb25zIChlLmcuIHBldGhQc2VQb3J0VGFibGUpIHNob3VsZCBi ZSBkZWZpbmVkIGluIDgwMi4zY2YsIGJ1dCB0aGF0IHRoZSByZW1haW5pbmcgcGFydHMgKGUuZy4s IHBldGhNYWluUHNlT2JqZWN0cyApIGNhbiBob3BlZnVsbHkgYmUgc3RhbmRhcmRpemVkIGluIElF VEYuDQoNCg0KDQpEbyB5b3UgaGF2ZSBhbnkgY29tbWVudHMsIG9yIGNvbmNlcm5zLCBvbiB0aGUg MyBwcm9wb3NhbHMgYWJvdmU/DQoNClJlZ2FyZHMsDQpSb2IgV2lsdG9uDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0 DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg0KDQoNCg== --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A951C2D0nkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN Cgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29s b3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBhbGwsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvcnJ5LCBhIGxpdHRsZSBiZWhpbmQgdGhp cyBkaXNjdXNzaW9u4oCmIHNvbWUgY29uY2x1c2lvbnMgZnJvbSBsYXN0IHdlZWvigJlzIElFRUUg ODAyLjNjZiBtZWV0aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMs IHRoZSA4MDIuM2NmIHByb2plY3QgaXMgbm90IGNoYXJ0ZXJlZCB0byBtb2RpZnkgdGhlIENsYXVz ZSAzMCwgYnV0IHdlIGRpc2N1c3NlZCB0aGUgcG9zc2liaWxpdHkgb2YgaGF2aW5nIHVzZWZ1bCBh dHRyaWJ1dGVzIGZyb20gZXhpc3RpbmcgTUlCDQogYnV0IGJleW9uZCBDbGF1c2UgMzAgZm9yIG1h bmFnZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUg Y29uY2x1c2lvbiBpcyB5ZXMsIHRoZSBncm91cCBhZ3JlZWQgdG8gaGF2ZSB0aG9zZSBhdHRyaWJ1 dGVzIGluIG1vZHVsZXMgd2hpbGUgUDgwMi4zY2YgKDgwMi4zLjIpIHdvdWxkIGFkZCBhbiBhbm5l eCB0byBpbnRyb2R1Y2UgdGhvc2UgYXR0cmlidXRlcw0KIGFuZCBwcm92aWRlIHJlZmVyZW5jZXMg dG8gc3RhbmRhcmRzIG91dHNpZGUgODAyLjMgYXMgc3VnZ2VzdGlvbnMgdG8gQ2xhdXNlIDMwLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBhIGZvbGxvdy11cCwgdGhlIElF RUUgODAyLjMgd2lsbCBkaXNjdXNzIGFuZCBkZWNpZGUgaG93IHRvIGFkZCB0aG9zZSBhdHRyaWJ1 dGVzIGZyb20gdGhhdCBhbm5leCB0byBDbGF1c2UgMzAuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIG5vIGZlYXR1cmVzLCB0aGVuIGl0IGNhbiBiZSBkb25l IGJ5IHN1Ym1pdHRpbmcgY29tbWVudHMgdG8gTWFpbnRlbmFuY2UgR3JvdXAuIElmJm5ic3A7IHRo b3NlIGFyZSBuZXcgZmVhdHVyZXMsIGEgbmV3IHByb2plY3Qgb3IgYSBleGlzdGluZyBwcm9qZWN0 DQogdGhhdCBjYW4gbW9kaWZ5IENsYXVzZSAzMCB3b3VsZCBiZSBuZWVkZWQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBzdWNoIHdheSwgdGhlIFlBTkcgcHJv amVjdCBpdHNlbGYgd291bGQgZ2V0IGFsb25nIHdlbGwgd2l0aCB0aGUgcHJvamVjdCB0aW1lbGlu ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzaWRlcywgZm9yIHRoZSA0 IHByb3Bvc2VkIGF0dHJpYnV0ZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Sb3cgMTc6IEluIFBGQyBmcmFtZXMgKHVzZWQgaW4mbmJzcDsgRVRIRVJMSUtFIE1J QiBkb3QzSENJblBGQ0ZyYW1lcykNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Um93IDE4OiBPdXQgUEZDIGZyYW1lcyAodXNlZCBpbiBFVEhFUkxJS0Ug TUlCIGRvdDNIQ091dFBGQ0ZyYW1lcykNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Um93IDE5OiBUb3RhbCBPY3RldHMgcmVjZWl2ZWQgKGdvb2QgJmFt cDsgYmFkKSAodXNlZCBpbiBSTU9OIE1JQiBldGhlclN0YXRzT2N0ZXRzKQ0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDtSb3cgMjU6IEZyYW1lcyBkcm9w cGVkIGFzIGJlaW5nIHRvbyBzaG9ydC4gKGNvbWJpbmVkIHZhbHVlIG9mIHR3byBSTU9OIE1JQiBj b3VudGVycyAoZXRoZXJTdGF0c1VuZGVyc2l6ZVBrdHMgJiM0MzsgZXRoZXJTdGF0c0ZyYWdtZW50 cykpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBFdGhlcm5ldCBJbnRl cmZhY2UgbW9kdWxlIGhhcyBiZWVuIGFkb3B0ZWQgd2l0aCB0aGVzZSBhdHRyaWJ1dGVzIGFuZCBp bmNsdWRlZCBpbiBEMC4xICZuYnNwOzogKS4gQnV0IHdlIGhhdmVu4oCZdCBwdXQgdGhlc2UgYXR0 cmlidXRlcyBpbnRvIHRoZSBhbm5leA0KIGFzIHN1Z2dlc3RlZCBhdHRyaWJ1dGVzIHRvIENsYXVz ZSAzMC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSBjYW4g c3VibWl0IGNvbW1lbnRzIHRvIGFkZCB0aGVtLiBBbmQgaWYgbW9yZSBhdHRyaWJ1dGVzIGFyZSBz dWdnZXN0ZWQsIHBsZWFzZSBmZWVsIGZyZWUgdG8gcHJvcG9zZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhhbmsgeW91IHZlcnkgbXVjaH48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5ZYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOndpbmRvd3RleHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndp bmRvd3RleHQiPiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij7ku6Po oaggPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Y29sb3I6d2luZG93dGV4dCI+Um9iZXJ0IFdpbHRvbjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij7lj5HpgIHml7bpl7Q8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4gMjAxNzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij7lubQ8c3BhbiBsYW5nPSJFTi1V UyI+Mzwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MjQ8L3NwYW4+5pelPHNwYW4gbGFuZz0i RU4tVVMiPg0KIDE6NDU8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gRGFuIFJvbWFzY2FudTxicj4NCjwvc3Bh bj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBjY2FtcEBpZXRmLm9yZzsgUnVzcyBIb3VzbGV5OyBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8 L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gUmU6IFtuZXRtb2RdIDgwMi4zIEV0aGVybmV0IFlBTkcgKDgwMi4zY3ApIGFuZCBJ RVRGIG92ZXJsYXA8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+SGkgRGFuLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MgZm9yIHRoZSBhZHZpY2UuJm5i c3A7IFRoYW5rZnVsbHksIERhdmlkIExhdyBoYXMgYmVlbiBhdHRlbmRpbmcgdGhlIDgwMi4zY2Yg dGFzayBtZWV0aW5ncywgc28gaGUgdmVyeSBtdWNoIGF3YXJlIG9mIHRoZSBwcm9wb3NhbCB0byBh ZGQgbmV3IGRlZmluaXRpb25zIHRvIGNsYXVzZSAzMCwgYW5kIGhhcyBvZmZlcmVkIHRvIGhlbHAg ZmluZCB0aGUgYmVzdCB3YXkgdGhyb3VnaCB0aGUgODAyLjMgcHJvY2Vzcw0KIHRvIGFjaGlldmUg dGhlIHJpZ2h0IHRlY2huaWNhbCBnb2Fscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1VUyI+VGhhbmtzLDxicj4NClJvYjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk9uIDIzLzAzLzIwMTcgMTY6NDAsIERhbiBSb21hc2NhbnUgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+SGkgUm9iZXJ0LCA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+VGhhbmsgeW91IGZvciB0aGUgYW5zd2VyLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGUgY3VycmVudCBJRUVFIDgwMi4zIHByb2plY3Qg KGNwKSBpcyBub3QgY2hhcnRlcmVkIHRvIG1ha2UgY2hhbmdlcyBpbiBDbGF1c2UgMzAgLSB0aGVz ZSBjYW5ub3QgYmUgZG9uZSwgYW5kIHlvdSBuZWVkIGEgbmV3IHByb2plY3QgZm9yIHRoaXMgcHVy cG9zZS4gVGFrZSB0aGlzIGludG8gY29uc2lkZXJhdGlvbiwgYXMgdGhpcw0KIG1heSBiZWNvbWUg YSBkZXBlbmRlbmN5IGFuZCBhIGdhdGluZyBpc3N1ZSBmb3IgdGhlIHByb2plY3QgdGltZWxpbmVz LiBJIHN1Z2dlc3QgdGhhdCB5b3UgZGlzY3VzcyB0aGlzIHdpdGggdGhlIElFRUUgODAyLjMgY2hh aXIgRGF2aWQgTGF3LiBJIGFtIGFsc28gY29weWluZyBSdXNzIHdobyBpcyBub3cgaW4gY2hhcmdl IHdpdGggdGhlIElFVEYgLSBJRUVFIHJlbGF0aW9uc2hpcCB0byBtYWtlIHN1cmUgdGhhdCBoZSBp cyBhd2FyZSBhYm91dCB0aGUNCiBpc3N1ZS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+RGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFRodSwgTWFy IDIzLCAyMDE3IGF0IDU6MzYgUE0sIFJvYmVydCBXaWx0b24gJmx0OzxhIGhyZWY9Im1haWx0bzpy d2lsdG9uQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJ3aWx0b25AY2lzY28uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIj5IaSBEYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gMjMvMDMvMjAxNyAwNzo1 NiwgRGFuIFJvbWFzY2FudSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgbGFyZ2VseSBhZ3JlZSB3aXRo IHRoZSBwcm9wb3NhbHMgb2YgdGhlIHRlYW0uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhhdmUgb25seSBv bmUgY29tbWVudCAvIGNsYXJpZmljYXRpb24gcmVsYXRlZCB0byB0aGUgUk1PTiBvYmplY3RzIHdo aWNoIGFyZSBwcm9wb3NlZCB0byBiZSB0cmFuc2ZlcnJlZCB1bmRlciBJRUVFIDgwMi4zY3AuIEFz IGZhciBhcyBJIHJlbWVtYmVyIHRoZXJlIGFyZSBzb21lIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhl IGRlZmluaXRpb25zIGluIHRoZSBSTU9OIE1JQiBmb3INCiBzb21lIG9mIHRoZSBvYmplY3RzIGFu ZCB0aGUgQ2xhdXNlIDMwIGRlZmluaXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5VbmZvcnR1bmF0ZWx5LCB5ZXMgdGhlcmUgYXJlIGRpZmZlcmVuY2Vz Ljxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XaGF0IGlzIHRo ZSBhcHByb2FjaCB0aGF0IHlvdSBwcm9wb3NlIHRvIHRha2U/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkknbSB0cnlpbmcgdG8gcmF0aW9uYWxpemUgdGhlbSBhbGwgdG9nZXRoZXIgKGF0 IGxlYXN0IGZvciB0aGUgcGFydHMgb2YgdGhlIE1JQiB0aGF0IHdlIHdhbnQgdG8gY2FycnkgZm9y d2FyZCBpbnRvIFlBTkcpLjxicj4NCjxicj4NClBsZWFzZSBzZWUgYXR0YWNoZWQgZm9yIGEgc3By ZWFkc2hlZXQgdGhhdCBzaG93cyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHByb3Bvc2Vk IDgwMi4zIFlBTkcgY291bnRlcnMsIHRoZSBleGlzdGluZyBNSUJzIChJRk1JQiwgUk1PTiwgYW5k IEVUSEVSTkVULUxJS0UpLCBhbmQgODAyLjMgY2xhdXNlIDMwLiZuYnNwOyBUaGlzIGRvZXNuJ3Qg eWV0IGNvdmVyIHRoZSBjb3VudGVycyB0aGF0IEkgcGxhbiBvbiBhZGRpbmcgdG8gZHJhZnQtaWV0 Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0wNA0KIChEcm9wIGR1ZSB0byBpbnZhbGlkIGRlc3RpbmF0 aW9uIE1BQywgb2YgUk1PTiBzdHlsZSBoaXN0b2dyYW0gY291bnRlcnMpLjxicj4NCjxicj4NClRo ZXJlIHdpbGwgYWxzbyBiZSBzb21lIHRleHQgYWRkZWQgdG8gdGhlIDgwMi4zY2YgZHJhZnQgdGhh dCBzaG91bGQgZXhwbGFpbiB0aGUgcmVsYXRpb25zaGlwLCBwb3NzaWJseSBzb21lIG9mIGl0IG1h eSBiZSBsaWZ0ZWQgZGlyZWN0bHkgZnJvbSA4MDIuMy4xLjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbmNsdWRlIGluIElFRUUgODAyLjNj cCBvbmx5IHRob3NlIG9iamVjdHMgdGhhdCBzdHJpY3RseSBjb25mb3JtIHRvIENsYXVzZSAzMCBk ZWZpbml0aW9ucywgb3IgbW9kaWZ5IC8gYWRkIGRlZmluaXRpb25zIGluIENsYXVzZSAzMCBpbiBv cmRlciB0byBhY2NvbW1vZGF0ZSBhbGwgdGhlIFJNT04gc3RhdGlzdGljcz8gSWYgdGhlIGxhdGVy IGFwcHJvYWNoIGlzIHRvIGJlIHRha2VuDQogLSBpcyBJRUVFIDgwMi4zY3AgY2hhcnRlcmVkIHRv IG1ha2UgY2hhbmdlcyBvciBhZGQgbmV3IGRlZmluaXRpb25zIGluIENsYXVzZSAzMCBvZiBJRUVF IDgwMi4zPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCkEgYml0IG9mIGJv dGggLSBtb3N0bHkgdGhlIGZvcm1lciBhcHByb2FjaCwgYnV0IHdpdGggYSBmZXcgbWlzc2luZyBj b3VudGVycyBob3BlZnVsbHkgYWRkZWQgdG8gY2xhdXNlIDMwLiZuYnNwOw0KPGJyPg0KPGJyPg0K U3BlY2lmaWNhbGx5LCBJIGhvcGluZyB0aGF0IHRoZSBmb2xsb3dpbmcgY291bnRlcnMgY2FuIGJl IGFkZGVkIHRvIGNsYXVzZSAzMDo8YnI+DQombmJzcDtSb3cgMTc6IEluIFBGQyBmcmFtZXMgKHVz ZWQgaW4mbmJzcDsgRVRIRVJMSUtFIE1JQiBkb3QzSENJblBGQ0ZyYW1lcykgPGJyPg0KJm5ic3A7 Um93IDE4OiBPdXQgUEZDIGZyYW1lcyAodXNlZCBpbiBFVEhFUkxJS0UgTUlCIGRvdDNIQ091dFBG Q0ZyYW1lcykgPGJyPg0KJm5ic3A7Um93IDE5OiBUb3RhbCBPY3RldHMgcmVjZWl2ZWQgKGdvb2Qg JmFtcDsgYmFkKSAodXNlZCBpbiBSTU9OIE1JQiBldGhlclN0YXRzT2N0ZXRzKSA8YnI+DQombmJz cDtSb3cgMjU6IEZyYW1lcyBkcm9wcGVkIGFzIGJlaW5nIHRvbyBzaG9ydC4gKGNvbWJpbmVkIHZh bHVlIG9mIHR3byBSTU9OIE1JQiBjb3VudGVycyAoZXRoZXJTdGF0c1VuZGVyc2l6ZVBrdHMgJiM0 MzsgZXRoZXJTdGF0c0ZyYWdtZW50cykpDQo8YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgaW4gcHJp bmNpcGFsIHRoZXJlIGlzIHNvbWUgc3VwcG9ydCBmb3IgYWRkaW5nIHRoZXNlIHRvIGNsYXVzZSAz MCwgYW5kIHRoZSBhcHByb3ByaWF0ZSBmb2xrcyBpbiA4MDIuMyB3aWxsIHdvcmsgb3V0IHRoZSBl YXNpZXN0L2Jlc3QgbWVjaGFuaXNtIHRvIGFjaGlldmUgdGhpcy48YnI+DQo8YnI+DQpUaGFua3Ms PGJyPg0KUm9iPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRhbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFdlZCwgTWFyIDIyLCAyMDE3 IGF0IDU6MjEgUE0sIFJvYmVydCBXaWx0b24gJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+SSdtIHBhcnRpY2lw YXRpbmcgaW4gdGhlIDgwMi4zIHRhc2sgZm9yY2UgKDgwMi4zY2YpIHRvIHByb2R1Y2Ugc3RhbmRh cmQgWUFORyBtb2RlbHMgZm9yIEV0aGVybmV0IGludGVyZmFjZXMgYW5kIHByb3RvY29scyBjb3Zl cmVkIGJ5IHRoZSBJRUVFIDgwMi4zIEV0aGVybmV0IFdvcmtpbmcgR3JvdXAuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIHBhcnQgb2YgbXkgaW52b2x2ZW1l bnQgd2l0aCB0aGF0IGdyb3VwLCBJIHdhbnQgdG8gaGlnaGxpZ2h0IGEgY291cGxlIG9mIGlzc3Vl cyB0aGF0IGFyb3NlIGluIHRoYXQgZm9ydW0gdGhhdCBtYXkgYmUgb2YgaW50ZXJlc3QgdG8gdmFy aW91cyBXR3MgaW4gSUVURi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyI+VGhpcyBlbWFpbCwgYW5kIGFjY29tcGFueWluZyBzbGlkZXMsIHJlcHJlc2VudHMgbXkg cGVyc29uYWwgdmlld3MsIGFuZCBkbyBub3QgcmVwcmVzZW50IGFueSBmb3JtYWwgSUVFRSBwb3Np dGlvbi4mbmJzcDsgSG93ZXZlciwgYm90aCB0aGlzIGVtYWlsIGFuZCB0aGUgYWNjb21wYW55aW5n IHNsaWRlcyBoYXZlIGJlZW4gcmV2aWV3ZWQgaW4gYW4gODAyLjNjZiB0YXNrIGZvcmNlIG1lZXRp bmcsIGFuZCB0aGVyZSB3ZXJlDQogbm8gb2JqZWN0aW9ucyB0byB0aGUgY29udGVudCwgb3IgbXkg c2VuZGluZyBvZiB0aGlzIGVtYWlsIHRvIElFVEYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiPkkgYWxzbyByYWlzZWQgdGhlc2UgaXNzdWVzICh3aXRoIGFuIGVh cmxpZXIgc2V0IG9mIHNsaWRlcykgYXMgcGFydCBvZiB0aGUgSUVURi9JRUVFIGxpYWlzb24gbWVl dGluZyBvbiAzMXN0IEphbnVhcnksIGFuZCB0aGUgY29uc2Vuc3VzIHdhcyBnZW5lcmFsbHkgc3Vw cG9ydGl2ZSBvZiB0aGlzIGFwcHJvYWNoLCB3aXRoIHRoZSBhZ3JlZWQgbmV4dCBzdGVwcyB0byBj b250YWN0IHRoZSBORVRNT0QgYW5kIENDQU1QDQogY2hhaXJzLCB3aGljaCBJIGhhdmUgZG9uZSwg YW5kIHRoZSBXR3MgKGhlbmNlIHRoaXMgZW1haWwpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1VUyI+QXMgcGFydCBvZiB0aGF0IFlBTkcgbW9kZWxsaW5nIHdvcmssIHRoZXJl IGlzIGFuIGFpbSB0byBkZWZpbmUgYSBjbGVhbiBib3VuZGFyeSBvZiB3aGF0IG1hbmFnZWFiaWxp dHkgZGF0YSBzaG91bGQgYmUgc3BlY2lmaWVkIHdpdGhpbiA4MDIuMyBhbmQgd2hhdCBiZWxvbmdz IG91dHNpZGUgdGhlIDgwMi4zIHNwZWNpZmljYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZGVmaW5pdGlvbiB0aGF0IHRoZSB0YXNrIGZvcmNl IGlzIGNvbnZlcmdpbmcgb24gaXMgdGhhdCBldmVyeXRoaW5nIHJlbGF0ZWQgdG8gRXRoZXJuZXQs IGNvdmVyZWQgYnkgODAyLjMsIHRoYXQgY2FuIGJlIGV4cHJlc3NlZCBpbiB0ZXJtcyBvZiB0aGUg ODAyLjMgY2xhdXNlIDMwIG1hbmFnZWFiaWxpdHkgZGVmaW5pdGlvbnMsIHNob3VsZCBiZSBtb2Rl bGVkIGluIDgwMi4zLiZuYnNwOyBJLmUuIGJyb2FkbHkgZXZlcnl0aGluZw0KIHRoYXQgaXMgY292 ZXJlZCBieSA4MDIuMy4xIHRvZGF5LiZuYnNwOyBCdXQgYW55IG1hbmFnZWFiaWxpdHkgaW5mb3Jt YXRpb24gdGhhdCBjYW5ub3QgYmUgcmVsYXRlZCB0byBjbGF1c2UgMzAgZGVmaW5pdGlvbnMgc2hv dWxkIGJlIHNwZWNpZmllZCBvdXRzaWRlIG9mIDgwMi4zLiZuYnNwOyBOb3RlLCB3aGVyZSBhcHBy b3ByaWF0ZSwgYWRkaXRpb25hbCBjbGF1c2UgMzAgZGVmaW5pdGlvbnMgbWF5IGJlIGFkZGVkIHRv IGZpeCBhbnkgbWlzdGFrZXMgb3IgZ2xhcmluZw0KIGdhcHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIj5UbyB0aGlzIGVuZCwgdGhlcmUgYXJlIGEgY291cGxlIG9mIGFy ZWFzIGJldHdlZW4gSUVURiBhbmQgODAyLjMgdGhhdCBkb24ndCBuZWNlc3NhcmlseSBsb29rIGxp a2UgdGhleSBhcmUgZW50aXJlbHkgaW4gdGhlIHJpZ2h0IHBsYWNlLCBpbiBwYXJ0aWN1bGFyOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4xKSBUaGUgUk1PTiBN SUIgKFJGQyAyODE5KSBkZWZpbmVzIChhbG9uZyB3aXRoIG90aGVyIG5vbi1FdGhlcm5ldCByZWxh dGVkIGNvbnRlbnQpIHNvbWUgRXRoZXJuZXQgc3BlY2lmaWMgc3RhdGlzdGljcyB0aGF0IHdvdWxk IGJlIGJldHRlciBjby1sb2NhdGVkIHdpdGggdGhlIEV0aGVybmV0IGludGVyZmFjZSBZQU5HIG1v ZGVsIGJlaW5nIGRlZmluZWQgaW4gODAyLjNjcC4mbmJzcDsgSGVuY2UsIHRoZSBwcm9wb3NhbA0K IGlzIHRvIHN1YnN1bWUgdGhlIGFwcHJvcHJpYXRlIEV0aGVybmV0IHN0YXRpc3RpY3MgZnJvbSB0 aGUgUk1PTiBNSUIgaW50byBhIHNpbmdsZSBjb21iaW5lZCByZWZlcmVuY2Ugc2V0IGRlZmluZWQg aW4gODAyLjNjcC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+ MikgVGhlIFJNT04gTUlCIGFsc28gZGVmaW5lcyBzb21lIEV0aGVybmV0IHNwZWNpZmljIHN0YXRp c3RpY3MgdGhhdCBjYW4ndCBiZSBkZWZpbmVkIGFzIHBhcnQgb2YgODAyLjNjZiBiZWNhdXNlIHRo ZXkgZG9uJ3QgcmVsYXRlIHRvIDgwMi4zIGNsYXVzZSAzMCByZWdpc3RlcnMsIGJ1dCBhcmUgc3Rp bGwgd2lkZWx5IHN1cHBvcnRlZCBieSB2ZW5kb3JzLCBhbmQgc2hvdWxkIGJlIG1vZGVsZWQgaW4g WUFORy4mbmJzcDsNCiBUaGUgcHJvcG9zYWwgaXMgdGhhdCBkZWZpbml0aW9ucyByZWxhdGVkIHRv IHRoZXNlIGNvdW50ZXJzIGNvdWxkIGJlIGFkZGVkIGFzIHBhcnQgb2YgdGhlIEV0aGVybmV0LWxp a2UgbW9kdWxlDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW5ldG1vZC1pbnRmLWV4dC15YW5nLyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtaWV0 Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0wMzwvYT4sIG9yIHBlcmhhcHMgYSByZWxhdGVkIEV0aGVy bmV0IG1vZHVsZSBpbiB0aGUgc2FtZSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1VUyI+MykgVGhlIFBvd2VyLUV0aGVybmV0IE1JQiAoZGVmaW5lZCBpbiBS RkMgMzYyMSwgYnV0IGFsc28gcmVmZXJlbmNlZCBmcm9tIFJGQyA3NDYwKSwgd2FzIG9yaWdpbmFs bHkgc3BlY2lmaWVkIGluIElFVEYsIGJ1dCBvd25lcnNoaXAgbGF0ZXIgdHJhbnNmZXJyZWQgdG8g ODAyLjMgKHZpYSBSRkMgNzQ0OCkuJm5ic3A7IFdoaWxzdCB3b3JraW5nIG9uIHRoZSBQb3dlciBv dmVyIEV0aGVybmV0IFlBTkcgbW9kZWwgaXQgaGFzDQogYmVjb21lIGNsZWFyIHRoYXQgbm90IGFs bCBvZiB0aGUgYXR0cmlidXRlcyBkZWZpbmVkIGluIHRoZSBNSUIgbWFwIHRvIHRoZSB1bmRlcmx5 aW5nIDgwMi4zIGNsYXVzZSAzMCBkZWZpbml0aW9ucy4mbmJzcDsgRnVydGhlciwgaXQgbG9va3Mg bGlrZSBwYXJ0cyBvZiB0aGlzIFlBTkcgbW9kZWwgd291bGQgYmUgYmV0dGVyIGRlZmluZWQgYXMg ZXh0ZW5zaW9ucyB0byB0aGUgRW50aXR5IFlBTkcgbW9kZWwgYmVpbmcgZGVmaW5lZCBpbiBORVRN T0QuJm5ic3A7IFRoZQ0KIHByb3Bvc2FsIGlzIHRoYXQgdGhlIHBhcnRzIG9mIHRoZSBQb3dlciBv dmVyIEV0aGVybmV0IFlBTkcgbW9kZWwgdGhhdCBjYW4gYmUgZGlyZWN0bHkgcmVsYXRlZCB0byBj bGF1c2UgMzAgZGVmaW5pdGlvbnMgKGUuZy4NCjxpPnBldGhQc2VQb3J0VGFibGU8L2k+KSBzaG91 bGQgYmUgZGVmaW5lZCBpbiA4MDIuM2NmLCBidXQgdGhhdCB0aGUgcmVtYWluaW5nIHBhcnRzIChl LmcuLA0KPGk+cGV0aE1haW5Qc2VPYmplY3RzIDwvaT4pIGNhbiBob3BlZnVsbHkgYmUgc3RhbmRh cmRpemVkIGluIElFVEYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5E byB5b3UgaGF2ZSBhbnkgY29tbWVudHMsIG9yIGNvbmNlcm5zLCBvbiB0aGUgMyBwcm9wb3NhbHMg YWJvdmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2Fy ZHMsPGJyPg0KUm9iIFdpbHRvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A951C2D0nkgeml513mbxchi_-- From nobody Thu Mar 23 17:50:54 2017 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 0DFD1129B10 for ; Thu, 23 Mar 2017 17:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 0D1KQeeXkmJz for ; Thu, 23 Mar 2017 17:50:51 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 82453124B0A for ; Thu, 23 Mar 2017 17:50:51 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-09v.sys.comcast.net with SMTP id rDQwcHyt6Qe9crDRKcp01D; Fri, 24 Mar 2017 00:50:50 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-09v.sys.comcast.net with SMTP id rDRJc07ymjCS0rDRKcDFaF; Fri, 24 Mar 2017 00:50:50 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2O0omFQ003369 for ; Thu, 23 Mar 2017 20:50:48 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2O0omCi003366; Thu, 23 Mar 2017 20:50:48 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org In-Reply-To: <20170322.212411.1191940569571241434.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 23 Mar 2017 20:50:48 -0400 Message-ID: <87y3vvpkev.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMgZ9arm099Yizk5yNZQyVPrIGdgOGi+NpqCJ52L0gud3XK98nC1dFFNxYMgaHR4bSCLjzTaUAyabyS79wcgdf+J/gOsDx74oUd+LuDtgga6x+vjEMFD lNBwRY00cX6xiJcRiXeqpYAZ+twGAI0/GjMIpKxZpVE9PA9cl5AdDMce Archived-At: Subject: Re: [netmod] uses and augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 00:50:53 -0000 Martin Bjorklund writes: >> I notice that "augment" is not allowed to target a "grouping", despite >> that naively seems to be an operation that a module designer might like >> to do. I expect that there is a reason why this is not allowed. > > There were lots of debate over this one when we first designed YANG. > The main reason for not allowing this is that it can easily have > unintended consequences. Module A uses a grouping G b/c it fits the > purpose. Later someone augments G with some nodes; at this point it > is not at all clear that the additional nodes are suitable for module > A. True... But assuming that the grouping G has clean semantics, it corresponds to some facility in the device, which in some way or another appears in multiple places in the device's data model. And a module that augments G adds semantics about that facility, and would only be implemented by a device for which the facility uniformly has that additional semantics. So it would be suitable for every place where the grouping is used. It seems like this consideration applies to the "Yang mount" facility also -- if a module A augments another module B, and module B is mounted in several places in the full data model, then all the instances of module B will be augmented. > Ok. Well, if you want to add a sibling node to the nodes in the > grouping it is trivial: > > grouping foo { > leaf a { ... } > } > > uses foo; > leaf b { ... } > > gives you: > > leaf a { ... } > leaf b { ... } Of course, that works. But what I'm considering is a modification of the grouping which implicitly applies to all "uses" of that grouping -- because you don't want to have duplicate declarations of the added nodes in every place the grouping is used. > Well, the syntax of descendant-schema-nodeid looks like an XPath path > expression in abbreviated form, but it is not defined in terms of > XPath, hence there is no text about any XPath context. See also > section 6.5 OK, "context node" isn't the right term, but the idea still applies -- if the schema node identifier is descendant, the starting point for reckoning the descending path has to be specified. Juergen Schoenwaelder writes: > On Wed, Mar 22, 2017 at 02:26:53PM -0400, Dale R. Worley wrote: > This is not at all clear. You only import 'foo' - so why would the > augment of /foo:target (which is not exactly defined either) done in > 'bar' apply to uses foo:target in baz? I'd say because that's what one would expect "augmenting" of a grouping to mean. Again, it looks like there will be similar behavior in "Yang mount". > Augments are restricted to things that have a well defined name in the > data tree because this makes it clear what is being augmented. One > would have to create additional language constructs to make > augmentations of groupings work. It's clear that *groupings* have well-defined names, because "uses" statements can refer to them. RFC 7950 section 7.13 isn't particularly clear about how the argument string of the statement is to be interpreted, but going back over 7950, I'm getting the idea that the names of groupings are not descendant-schema-nodeid's, that is, named based on where the grouping statement sits in the syntactic hierarchy, but are in a separate namespace which is flat regarding equality and inequality comparisons, but has elaborate scoping rules regarding which groupings are visible in which locations. OK, that clarifies why you can't apply "augment" to a grouping -- groupings (and thus the things defined within them) don't have names that can be expressed by descendant-schema-nodeid's. Dale From nobody Thu Mar 23 17:59:27 2017 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 3FD0C1293FC for ; Thu, 23 Mar 2017 17:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 EyMFnZwHbaYB for ; Thu, 23 Mar 2017 17:59:22 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BA8124B0A for ; Thu, 23 Mar 2017 17:59:22 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id y90so183037wrb.0 for ; Thu, 23 Mar 2017 17:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W4HjAh8k7kV9w0RbOe/4OAc4b4oQNManwJ/+BXfWkPY=; b=ymPv81vrae/hA/suiqzgDcthT7aEsZN5Zf+BbizxgB6yn3C8ghXUnf4wKSzVpwd5I5 h3aBqBanysCN2fEkGhEf3DzVOkXyKGYT61vgD1ufkVYd8gbZkxhFtlrNPZJTRozJa5Ya zCKQAgiuy1VTKBLjiQNEAySKNfdjF6cPCxyH7vqrB27fPVESOS4Ww49ZGhSBQ/dOwEtp mnH69o8mzhoQ7rSZg4LSJHetHgWlaKlbgLSF4WhwZRKANxRTcBaQusSfk34y2nGkrNiN k63V23F22r656YHXrdiGIKnXdEa79WGvINWdwEAMsryCR9xHPyujkgqxXHa2eKJdMnTB ob3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W4HjAh8k7kV9w0RbOe/4OAc4b4oQNManwJ/+BXfWkPY=; b=d43/TuT7lT/NEy1AtQTT1uj2Y/Qx50o2RPSznQL1GvZbiahCL/Dm0VPZPLhHmOsodD 2jJ/BLIKZX+5slame9nsQ4ZUnRsRloYp7ZVdEQZqxBCFZNS9lMTocAHzcqvhYWwLml3r py5/XPREw1fhCahVREJfVio6E80p4XWR9//2vNSGzRE5i5JQDgKI25f2He26/oKvO0bs 436X6Ptp2kSWlyrM+DeUkLUFT+xFPtPsvrgH8kT+zjETGlcNkLS4sUshNy5C3Cf5yHaT FXQDBpeVx07XreziYMCW+mQvhHn9IrCCM1A/BqaWr/xqTYzCjhC4VEsZsUYdkG74Vo7U lvhw== X-Gm-Message-State: AFeK/H1nmpnB+h5zWjsW6aoJWcbm5FW+rXFaqF4ulomTuT9LaaOEui7MKaKmEpFD6nC7/mOasB4dFwX8w6IrAw== X-Received: by 10.223.177.151 with SMTP id q23mr4824588wra.65.1490317160553; Thu, 23 Mar 2017 17:59:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.166.37 with HTTP; Thu, 23 Mar 2017 17:59:19 -0700 (PDT) In-Reply-To: <87y3vvpkev.fsf@hobgoblin.ariadne.com> References: <20170322.212411.1191940569571241434.mbj@tail-f.com> <87y3vvpkev.fsf@hobgoblin.ariadne.com> From: Andy Bierman Date: Thu, 23 Mar 2017 17:59:19 -0700 Message-ID: To: "Dale R. Worley" Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=f403045e7cd4f52f92054b6f80f6 Archived-At: Subject: Re: [netmod] uses and augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 00:59:25 -0000 --f403045e7cd4f52f92054b6f80f6 Content-Type: text/plain; charset=UTF-8 Hi, I think the reason this was rejected is because you cannot control which "uses" of the grouping should get the augmenting nodes. They all get the nodes. There is no way for the uses-stmt to "opt-in" to the new changes, except manually: grouping foo { ... } grouping new-foo { uses foo; // add new nodes via augment or data-def-stmt; } By forcing the "uses foo" to change to "uses new-foo", the data model designer is explicitly accepting the new changes. Note that import-without-revision can also cause the uses-stmt to expand differently as the imported module changes over time. This is a separate problem. Andy On Thu, Mar 23, 2017 at 5:50 PM, Dale R. Worley wrote: > Martin Bjorklund writes: > >> I notice that "augment" is not allowed to target a "grouping", despite > >> that naively seems to be an operation that a module designer might like > >> to do. I expect that there is a reason why this is not allowed. > > > > There were lots of debate over this one when we first designed YANG. > > The main reason for not allowing this is that it can easily have > > unintended consequences. Module A uses a grouping G b/c it fits the > > purpose. Later someone augments G with some nodes; at this point it > > is not at all clear that the additional nodes are suitable for module > > A. > > True... But assuming that the grouping G has clean semantics, it > corresponds to some facility in the device, which in some way or another > appears in multiple places in the device's data model. And a module > that augments G adds semantics about that facility, and would only be > implemented by a device for which the facility uniformly has that > additional semantics. So it would be suitable for every place where the > grouping is used. > > It seems like this consideration applies to the "Yang mount" facility > also -- if a module A augments another module B, and module B is mounted > in several places in the full data model, then all the instances of > module B will be augmented. > > > Ok. Well, if you want to add a sibling node to the nodes in the > > grouping it is trivial: > > > > grouping foo { > > leaf a { ... } > > } > > > > uses foo; > > leaf b { ... } > > > > gives you: > > > > leaf a { ... } > > leaf b { ... } > > Of course, that works. But what I'm considering is a modification of > the grouping which implicitly applies to all "uses" of that grouping -- > because you don't want to have duplicate declarations of the added nodes > in every place the grouping is used. > > > Well, the syntax of descendant-schema-nodeid looks like an XPath path > > expression in abbreviated form, but it is not defined in terms of > > XPath, hence there is no text about any XPath context. See also > > section 6.5 > > OK, "context node" isn't the right term, but the idea still applies -- > if the schema node identifier is descendant, the starting point for > reckoning the descending path has to be specified. > > Juergen Schoenwaelder writes: > > On Wed, Mar 22, 2017 at 02:26:53PM -0400, Dale R. Worley wrote: > > This is not at all clear. You only import 'foo' - so why would the > > augment of /foo:target (which is not exactly defined either) done in > > 'bar' apply to uses foo:target in baz? > > I'd say because that's what one would expect "augmenting" of a grouping > to mean. Again, it looks like there will be similar behavior in "Yang > mount". > > > Augments are restricted to things that have a well defined name in the > > data tree because this makes it clear what is being augmented. One > > would have to create additional language constructs to make > > augmentations of groupings work. > > It's clear that *groupings* have well-defined names, because "uses" > statements can refer to them. RFC 7950 section 7.13 isn't particularly > clear about how the argument string of the statement is to be > interpreted, but going back over 7950, I'm getting the idea that the > names of groupings are not descendant-schema-nodeid's, that is, named > based on where the grouping statement sits in the syntactic hierarchy, > but are in a separate namespace which is flat regarding equality and > inequality comparisons, but has elaborate scoping rules regarding which > groupings are visible in which locations. > > OK, that clarifies why you can't apply "augment" to a grouping -- > groupings (and thus the things defined within them) don't have names > that can be expressed by descendant-schema-nodeid's. > > Dale > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --f403045e7cd4f52f92054b6f80f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think the reason this was rejecte= d is because you cannot control
which "uses" of the gro= uping should get the augmenting nodes.
They all get the nodes.=C2= =A0 There is no way for the uses-stmt to "opt-in"
to th= e new changes, except manually:

=C2=A0 =C2=A0group= ing foo { ... }

=C2=A0 =C2=A0grouping new-foo {
=C2=A0 =C2=A0 =C2=A0 =C2=A0uses foo;
=C2=A0 =C2=A0 =C2=A0= =C2=A0// add new nodes via augment or data-def-stmt;
=C2=A0 =C2= =A0}

By forcing the "uses foo" to change= to "uses new-foo",
the data model designer is explicit= ly accepting the new changes.

Note that import-wit= hout-revision can also cause the uses-stmt
to expand differently = as the imported module changes over time.
This is a separate prob= lem.


Andy

=

On Thu, Mar 23, 2= 017 at 5:50 PM, Dale R. Worley <worley@ariadne.com> wrote:<= br>
Martin Bjorklund <mbj@tail-f.com> writes:
>> I notice that "augment" is not allowed to target a "= ;grouping", despite
>> that naively seems to be an operation that a module designer might= like
>> to do.=C2=A0 I expect that there is a reason why this is not allow= ed.
>
> There were lots of debate over this one when we first designed YANG. > The main reason for not allowing this is that it can easily have
> unintended consequences.=C2=A0 Module A uses a grouping G b/c it fits = the
> purpose.=C2=A0 Later someone augments G with some nodes; at this point= it
> is not at all clear that the additional nodes are suitable for module<= br> > A.

True...=C2=A0 But assuming that the grouping G has clean semantics, it
corresponds to some facility in the device, which in some way or another appears in multiple places in the device's data model.=C2=A0 And a modu= le
that augments G adds semantics about that facility, and would only be
implemented by a device for which the facility uniformly has that
additional semantics.=C2=A0 So it would be suitable for every place where t= he
grouping is used.

It seems like this consideration applies to the "Yang mount" faci= lity
also -- if a module A augments another module B, and module B is mounted in several places in the full data model, then all the instances of
module B will be augmented.

> Ok.=C2=A0 Well, if you want to add a sibling node to the nodes in the<= br> > grouping it is trivial:
>
>=C2=A0 =C2=A0grouping foo {
>=C2=A0 =C2=A0 =C2=A0leaf a { ... }
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0uses foo;
>=C2=A0 =C2=A0leaf b { ... }
>
> gives you:
>
>=C2=A0 =C2=A0 leaf a { ... }
>=C2=A0 =C2=A0 leaf b { ... }

Of course, that works.=C2=A0 But what I'm considering is a modification= of
the grouping which implicitly applies to all "uses" of that group= ing --
because you don't want to have duplicate declarations of the added node= s
in every place the grouping is used.

> Well, the syntax of descendant-schema-nodeid looks like an XPath path<= br> > expression in abbreviated form, but it is not defined in terms of
> XPath, hence there is no text about any XPath context.=C2=A0 See also<= br> > section 6.5

OK, "context node" isn't the right term, but the idea still a= pplies --
if the schema node identifier is descendant, the starting point for
reckoning the descending path has to be specified.

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
> On Wed, Mar 22, 2017 at 02:26:53PM -0400, Dale R. Worley wrote:
> This is not at all clear. You only import 'foo' - so why would= the
> augment of /foo:target (which is not exactly defined either) done in > 'bar' apply to uses foo:target in baz?

I'd say because that's what one would expect "augmenting"= of a grouping
to mean.=C2=A0 Again, it looks like there will be similar behavior in "= ;Yang
mount".

> Augments are restricted to things that have a well defined name in the=
> data tree because this makes it clear what is being augmented. One
> would have to create additional language constructs to make
> augmentations of groupings work.

It's clear that *groupings* have well-defined names, because "uses= "
statements can refer to them.=C2=A0 RFC 7950 section 7.13 isn't particu= larly
clear about how the argument string of the statement is to be
interpreted, but going back over 7950, I'm getting the idea that the names of groupings are not descendant-schema-nodeid's, that is, named based on where the grouping statement sits in the syntactic hierarchy,
but are in a separate namespace which is flat regarding equality and
inequality comparisons, but has elaborate scoping rules regarding which
groupings are visible in which locations.

OK, that clarifies why you can't apply "augment" to a groupin= g --
groupings (and thus the things defined within them) don't have names that can be expressed by descendant-schema-nodeid's.

Dale

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

--f403045e7cd4f52f92054b6f80f6-- From nobody Thu Mar 23 18:04:40 2017 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 4D3B4129A7F for ; Thu, 23 Mar 2017 18:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 jxsbWkJPYImB for ; Thu, 23 Mar 2017 18:04:38 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 E326C1294A8 for ; Thu, 23 Mar 2017 18:04:37 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-10v.sys.comcast.net with SMTP id rDdkcEwlH61D9rDefcey3v; Fri, 24 Mar 2017 01:04:37 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-06v.sys.comcast.net with SMTP id rDedcMfP3eyvGrDeecwZEX; Fri, 24 Mar 2017 01:04:36 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2O14Zlr004782; Thu, 23 Mar 2017 21:04:35 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2O14ZvU004779; Thu, 23 Mar 2017 21:04:35 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Martin Bjorklund Cc: lhotka@nic.cz, netmod@ietf.org In-Reply-To: <20170321.212254.1381357367952499259.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 23 Mar 2017 21:04:35 -0400 Message-ID: <87vaqzpjrw.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfFN9DgtnqWgP3AgnjsOdd+qop2Q+je8mSVkY8k9SXTkQ9mMzFArT+4FD+MDklJb64Vjw6XK38xiqhovybqDD1SbYA05TQz4XTf/IVVRq1sZt577RQVpq sXG2BoRQniDAhcbHbpAbNrlmxzUG32T8N14f67YeXdn0NFPd26Pyg6xyeAEcwV5uxyvClozwIqVlMhxsmavNKwx/lKeho9wC/mQ= Archived-At: Subject: Re: [netmod] tree diagrams - flags X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 01:04:39 -0000 Martin Bjorklund writes: > Aha, ok. This description is not a correct description of the YANG > data tree (in which XPath expressions etc are evaluated). There is > not a single "list node" called "interfaces". Look at an example of ^ I'm pretty sure you mean "interface" here. > an XML instance document: > > > > eth0 > ... > > > eth1 > ... > > > > This also reflects the data tree. OK, yes, I'm recalling that now. I run into mental interference because there are at least three ways of looking at it: - The Yang statement is named "list" -- a singular noun -- and not something like "repeated" or "repeated container". And compared to ordinary programming languages, the semantics is "array-of-structures". (The fact that Yang doesn't orthogonalize the array and the structure is why Yang must also have a leaf-list statement.) So the "obvious" semantics of the name is that it's "the name" of "the list". - The XML version doesn't have an overt representation of the array, but does have an overt representation of each structure and uses the list name as the label of each structure. The XPath expressions are evaluated within this version, so the absence of an explicit array node is important. - The JSON representation overtly represents both the array ([...]) and the structures ({...}), and applies the name to the array, not the structures. (Which means that you can't evaluate XPath expressions directly against the JSON representation.) Thus you get the contrasting representations: list bar { key foo; leaf foo { type uint8; } leaf baz { type string; } } 123 zig zag o "bar": [ { "foo": 123, "baz": "zig" }, { "baz": "zag", "foo": 0 } ] each of which invites one to speak of the schema in somewhat different ways. The way you'd describe a tree diagram differs depending on which way you're looking at the schema. Dale From nobody Thu Mar 23 18:28:13 2017 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 CFD10129BDB; Thu, 23 Mar 2017 18:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BS2HmRUuGxTm; Thu, 23 Mar 2017 18:28:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5A9129A7F; Thu, 23 Mar 2017 18:28:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJM34858; Fri, 24 Mar 2017 01:28:03 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 24 Mar 2017 01:28:02 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.110]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 24 Mar 2017 09:27:54 +0800 From: "Zhuangyan (Yan)" To: Robert Wilton , Fatai Zhang , "netmod@ietf.org" , "ccamp@ietf.org" Thread-Topic: Re: [CCAMP] 802.3 Ethernet YANG (802.3cp) and IETF overlap Thread-Index: AQHSpD3bYyEfBpV8G0a+Ill3N8zT1A== Date: Fri, 24 Mar 2017 01:27:53 +0000 Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785A951C2FE@nkgeml513-mbx.china.huawei.com> References: <59ea5342-0973-8f12-7d9a-27154cf42d80@cisco.com> <89c90309-9870-7cd5-ed7c-d44ac09c646a@cisco.com> In-Reply-To: <89c90309-9870-7cd5-ed7c-d44ac09c646a@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.170.230] Content-Type: multipart/alternative; boundary="_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A951C2FEnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58D47625.009E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.110, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: aa0169da3b7fcc1d7acaf19c4902cd8d Archived-At: Subject: Re: [netmod] [CCAMP] 802.3 Ethernet YANG (802.3cp) and IETF overlap X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 01:28:12 -0000 --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A951C2FEnkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIG1haW4gcG9pbnQgaXMgdGhhdCA4MDIuMyBkZWZpbmVzIFBIWSBzcGVjcyBmb3IgRXRoZXJu ZXQgZGV2aWNlcyBhbG9uZyB3aXRoIG1hbmFnZWQgb2JqZWN0cyAod2hpY2ggY2FuIGJlIGNvbnNp ZGVyZWQgYXMgbWFuYWdlbWVudCBpbnRlcmZhY2UpIHRvIG1hbmFnZSB0aG9zZSBwaHlzIGJ5IHNl dHRpbmcvcmVhZGluZyByZWdpc3RlcnMuDQpFdmVuIDgwMi4zIG5vdyBhZ3JlZXMgdG8gYWRkIGV4 dHJhIGF0dHJpYnV0ZXMgZnJvbSBNSUIgYnV0IGJleW9uZCBDbGF1c2UgMzAsIHRob3NlIGF0dHJp YnV0ZXMgYXJlIHN0aWxsIG5lZWRlZCB0byBiZSBzdXBwb3J0ZWQgYnkgODAyLjMgaGFyZHdhcmXi gKYuDQoNCkZvciB0aGUgbWFuYWdlbWVudCBvZiB0aGVzZSBkZXZpY2VzLCA4MDIuMyB3aWxsIHBy b3ZpZGUgbWFuYWdlbWVudCBpbnRlcmZhY2VzIGFjY29yZGluZyB0byB0aGUgY2FwYWJpbGl0eSBv ZiB0aGVpciBkZWZpbmVkIFBIWXMuICBQcmV2aW91c2x5LCBpbiBmb3JtIG9mIE1JQnMsIG5vdyBp biBmb3JtIG9mIFlBTkcgbW9kdWxlcy4NCkJ1dCBmb3IgdGhlIHN5c3RlbSBsZXZlbCBtYW5hZ2Vt ZW50LCB3ZSB0aGluayBJRVRGIGlzIGEgbW9yZSBhcHByb3ByaWF0ZSBwbGFjZSB0byBkaXNjdXNz IHNpbmNlIDgwMi4zIGlzIG5vdCBleHBlcnQgaW4gdGhpcy4NCg0KRm9yIHRoZSBFdGhlcm5ldCBp bnRlcmZhY2UsIGFzIGRpc2N1c3NlZCwgdGhlIHN5c3RlbSByZWxhdGVkIG9yIGdlbmVyaWMgbWFu YWdlbWVudCBhcmUgc3VnZ2VzdGVkIHRvIGJlIGluY2x1ZGVkIGluIFJvYmVydOKAmXMgaW50Zi1l eHQteWFuZyBtb2R1bGUuDQpGb3IgdGhlIFBvRSBwYXJ0LCB0aGUgcG93ZXIgc3lzdGVtIG1hbmFn ZW1lbnQgKGluY2x1ZGluZyB0aGUgcG93ZXIgc291cmNlIGFuZCB0aGUgcG9lIHBvcnQgcHJpb3Jp dHkpIGlzIGEgc3lzdGVtIGxldmVsIG1hbmFnZW1lbnQgYW5kIHdvdWxkIGxpa2UgdG8gaGVhciBJ RVRG4oCZcyB0aG91Z2h0cyBvbiB0aGlzIGFzIHdlbGwuDQoNClRoYW5rIHlvdSBmb3IgeW91ciBj b21tZW50cy4NCg0KQmVzdCBSZWdhcmRzLA0KDQpZYW4NCg0K5Y+R5Lu25Lq6OiBSb2JlcnQgV2ls dG9uIFttYWlsdG86cndpbHRvbkBjaXNjby5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTflubQz5pyI MjPml6UgMjI6NTkNCuaUtuS7tuS6ujogRmF0YWkgWmhhbmc7IG5ldG1vZEBpZXRmLm9yZzsgY2Nh bXBAaWV0Zi5vcmcNCuaKhOmAgTogWmh1YW5neWFuIChZYW4pDQrkuLvpopg6IFJlOiDnrZTlpI06 IFtDQ0FNUF0gODAyLjMgRXRoZXJuZXQgWUFORyAoODAyLjNjcCkgYW5kIElFVEYgb3ZlcmxhcA0K DQpIaSBGYXRhaSwNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMvcmV2aWV3Lg0KDQpTb3JyeSwg b25lIGNvcnJlY3Rpb24gaW4gbXkgZW1haWwuICBUaGUgODAyLjMgWUFORyBwcm9qZWN0IGlzIG9u bHkgODAyLjNjZi4gIFNvbWV0aW1lcyBJIGhhdmUgbWFuYWdlZCB0byBtYW5nbGUgdGhlIG5hbWUg dG9nZXRoZXIgd2l0aCB0aGUgODAyLjEgWUFORyBwcm9qZWN0ICg4MDIuMWNwKSAuLi4NCg0KT24g MjMvMDMvMjAxNyAwMzo1MSwgRmF0YWkgWmhhbmcgd3JvdGU6DQpIaSBSb2IsDQoNClRoYW5rcyBm b3Igc2hhcmluZyB0aGUgaW5mb3JtYXRpb24uDQoNCkkgdGhpbmsgeW91IGFyZSB0YWxraW5nIGFi b3V0IHR3byB0eXBlcyBvZiBZYW5nIG1vZGVscywgb25lIGlzIEV0aGVybmV0IHNwZWNpZmljIHN0 YXRpc3RpY3MsIGFuZCB0aGUgb3RoZXIgb25lIGlzIFBvd2VyIG92ZXIgRXRoZXJuZXQuDQpXZSBh cmUgdHJ5aW5nIHRvIGNvbnZlcnQgdmFyaW91cyBNSUJzIHRoYXQgY29udGFpbiBFdGhlcm5ldCBy ZWxhdGVkIGZ1bmN0aW9uYWxpdHkgdG8gWUFORy4gIEdlbmVyYWxseSB0aGUgTUlCUyB3ZXJlIGRl ZmluZWQgaW4gSUVURi4gIFNvbWUgb2YgdGhlbSBoYXZlIGJlZW4gdHJhbnNmZXJyZWQgdG8gSUVF RSBmb3Igb3duZXJzaGlwLg0KDQpJbiB0aGUgcHJvY2VzcyBvZiBjb252ZXJ0aW5nIHRoZSBjb250 ZW50IGZyb20gTUlCcyB0byBZQU5HIHdlIGFyZSB0YWtpbmcgdGhlIG9wcG9ydHVuaXR5IHRvIHJl ZmluZSB0aGUgY29udGVudHMgdG8gYmV0dGVyIG1lZXQgY3VycmVudCByZXF1aXJlbWVudHMuICBF LmcuIENTTUEvQ0QgY29sbGlzaW9uIGNvdW50ZXJzIGFyZSBnZW5lcmFsbHkgbm90IG9mIHJlbGV2 YW5jZSBvbiBhbnkgY3VycmVudCBFdGhlcm5ldCBoYXJkd2FyZS4NCg0KDQoNCklmIG15IHVuZGVy c3RhbmRpbmcgaXMgY29ycmVjdCwgSSB0aGluayB5b3VyIHByb3Bvc2FscyBhcmUgdGhhdCBzb21l IHBhcnQgb2YgZWFjaCBvZiB0aGVtIHNob3VsZCBiZSBkZWZpbmVkIGluIDgwMi4zY3Agb3IgODAy LjNjZiwgYW5kIHRoZSBsZWZ0IHBhcnQgb2YgZWFjaCBvZiB0aGVtIHNob3VsZCBiZSBkZWZpbmVk IGluIElFVEYuDQpCYXNpY2FsbHksIHllcywgdGhhdCBpcyBjb3JyZWN0Lg0KDQoNCg0KSSBhbSBh IGxpdHRsZSBjb25jZXJuZWQgdGhhdCBob3cgcGVvcGxlIGNhbiBkaXN0aW5ndWlzaCBhbmQganVk Z2Ugd2hpY2ggcGFydCAoZS5nLiwgb2YgRXRoZXJuZXQgc3BlY2lmaWMgc3RhdGlzdGljcyBvciBQ b3dlciBvdmVyIEV0aGVybmV0KSBzaG91bGQgYmUgZGVmaW5lZCBpbiBJRUVFIG9yIElFRlQ/DQpB IGxvdCBvZiB0aGUgODAyLjMgRXRoZXJuZXQgc3BlY2lmaWNhdGlvbiBjb25jZXJucyBmdW5jdGlv bmFsaXR5IHRoYXQgaXMgYmFrZWQgaW50byB0aGUgaGFyZHdhcmUuICBUaGUgODIwLjMgc3BlY2lm aWNhdGlvbiBkZWZpbmVzICh2aWEgQ2xhdXNlIDMwKSBhbiBpbnRlcm5hbCBtYW5hZ2VtZW50IEFQ SSBmb3IgY29uZmlndXJhdGlvbiBhbmQgcmV0cmlldmFsIG9mIG9wZXJhdGlvbmFsIHBhcmFtZXRl cnMgZnJvbSB0aGUgaGFyZHdhcmUuDQoNClNvLCB0aGUgODAyLjNjZiBwbGFuIGlzIHRoYXQgYWxs IG9mIHRoZSBFdGhlcm5ldCByZWxhdGVkIHBhcnRzIG9mIFlBTkcsIG9yIE1JQiwgbW9kdWxlcyB0 aGF0IGp1c3QgcmVwcmVzZW50IHRoZSB2YWx1ZXMgZGVmaW5lZCBpbiBjbGF1c2UgMzAgYXJlIGV4 cGVjdGVkIHRvIHB1Ymxpc2hlZCBhcyBwYXJ0IG9mIHRoZSA4MDIuMyBFdGhlcm5ldCBZQU5HIG1v ZHVsZXMuDQoNCkhvd2V2ZXIsIDgwMi4zY2YgZG8gbm90IHdhbnQgdGhlaXIgc3RhbmRhcmQgWUFO RyBtb2RlbHMgdG8gbWFwIHRvIHBhcmFtZXRlcnMgdGhhdCBhcmUgbm90IGNvdmVyZWQgYnkgY2xh dXNlIDMwIChleGNlcHRpbmcgYSBmZXcgbW9yZSBvYnZpb3VzIG9taXNzaW9ucykgYmVjYXVzZSB0 aGF0IG1pZ2h0IG1lYW4gdGhhdCB0aGUgWUFORyBtb2R1bGUgY2Fubm90IGJlIGZ1bGx5IHN1cHBv cnRlZCBieSBjdXJyZW50IGRldmljZXMgKGUuZy4gaWYgdGhleSBkb24ndCBoYXZlIHRoZSBhY3R1 YWwgaGFyZHdhcmUgcHJlc2VudCB0byBwcm92aWRlIHRoZSBuZWNlc3NhcnkgY291bnRlcnMpLg0K DQpTbywgdGhlIHByb3Bvc2FsIGlzIHRoYXQgc29tZSBwYXJ0cyBvZiB0aGUgRXRoZXJuZXQgc3Rh dGlzdGljcyBnZXQgc3RhbmRhcmRpemVkIGluIElFVEYgaW5zdGVhZCAocHJvYmFibHkgdmlhIE5F VE1PRCkuDQoNCkNvbmNyZXRlbHksIG15IGRlc2lyZSBpcyBmb3IgdGhlIGZvbGxvd2luZyBiaXRz IHdvdWxkIGJlIHN0YW5kYXJkaXplZCBpbiBJRVRGOg0KICAxKSBIaXN0b2dyYW0gcGFja2V0IHN0 YXRpc3RpY3MgKGZyb20gUk1PTikgKGJlY2F1c2UgdmVuZG9ycyBvZnRlbiBzdXBwb3J0IEV0aGVy bmV0IGZyYW1lcyB1cCB0byA5ayBieXRlcywgYnV0IHRoZSBmb3JtYWwgODAyLjMgc3BlY2lmaWNh dGlvbiBvbmx5IGdvZXMgdXAgdG8gMmspLiAgVG8gYmUgYWRkZWQgdG8gZHJhZnQtaWV0Zi1uZXRt b2QtaW50Zi1leHQteWFuZy0wNA0KICAyKSBTb21lIGNvdW50ZXJzIHRoYXQgbW9yZSBnZW5lcmFs bHkgYXBwbHkgdG8gRXRoZXJuZXQtbGlrZSBpbnRlcmZhY2VzIChlLmcuIExBRywgSVJCLCBvciBQ c2V1ZG8td2lyZSBoZWFkLWVuZCBpbnRlcmZhY2VzKS4gIFRoaXMgd291bGQgaW5jbHVkZSB0aGUg bnVtYmVyIG9mIHBhY2tldHMgZHJvcHBlZCBiZWNhdXNlIHRoZXkgZG9uJ3QgbWF0Y2ggdGhlIGRl c3RpbmF0aW9uIE1BQyBhZGRyZXNzIGZpbHRlci4gIFRvIGJlIGFkZGVkIHRvIGRyYWZ0LWlldGYt bmV0bW9kLWludGYtZXh0LXlhbmctMDQuDQogIDMpIFRoZSBwYXJ0cyBvZiBwb3dlciBtYW5hZ2Vt ZW50IHRoYXQgcmVsYXRlIHRvIHBvd2VyIHN1cHBsaWVzIHJhdGhlciB0aGFuIEV0aGVybmV0IGlu dGVyZmFjZXMuICBZYW4gaGFzIHN1Ym1pdHRlZCBhIGRyYWZ0IHRvIE5FVE1PRCBmb3IgdGhpcywg ZHJhZnQtemh1YW5nLW5ldG1vZC15YW5nLXBvZS1tYW5hZ2VtZW50LTAxLiAgSSd2ZSBub3QgcmV2 aWV3ZWQgdGhpcyBkcmFmdCB5ZXQsIGJ1dCBpdCBtYXkgYmUgdGhhdCBpdCBzaG91bGQgYXVnbWVu dCB0aGUgZW50aXR5IFlBTkcgbW9kZWwgKGRyYWZ0LWlldGYtbmV0bW9kLWVudGl0eS0wMykuDQoN Cg0KDQoNCkZvciBleGFtcGxlLCByZWdhcmRpbmcgRXRoZXJuZXQgc3BlY2lmaWMgc3RhdGlzdGlj cywgaG93IHBlb3BsZSBjYW4gZXhhY3RseSBrbm93IHdoaWNoIGluZm9ybWF0aW9uIGNvdWxkIGJl IGJldHRlciBjby1sb2NhdGVkIGluIDgwMi4zY3AgYW5kIHdoaWNoIGRvbuKAmXQgIHJlbGF0ZSB0 byA4MDIuMz8NCkkgdGhpbmsgZGlmZmVyZW50IHBlb3BsZSBtaWdodCBoYXZlIGRpZmZlcmVudCB1 bmRlcnN0YW5kaW5nIGFuZCB0aGVuIGl0IHdpbGwgYnJpbmcgY29uZnVzaW9uIHRvIHRoZSBpbmR1 c3RyeS4NClBvc3NpYmx5IHRoaXMgd2lsbCBiZSB0cnVlLCBidXQgb25jZSB0aGVzZSBiYXNlIG1v ZGVscyBhcmUgc3RhbmRhcmRpemVkLCBJJ20gbm90IHN1cmUgdGhhdCB0aGV5IGFyZSBsaWtlbHkg dG8gZXZvbHZlIHBhcnRpY3VsYXJseSBxdWlja2x5LiAgSSB3b3VsZCB0aGluayB0aGF0IGlmIHRo ZSB3b3JrIGlzIGJlaW5nIGRvbmUgaW4gODAyLjMgdGhlbiBhbnkgYXNzb2NpYXRlZCBZQU5HIHdv dWxkIGJlIHN0YW5kYXJkaXplZCB0aGVyZSwgc2ltaWxhcmx5IGZvciBJRVRGLg0KDQoNCg0KSG93 IGFib3V0IGFsbG93IElFVEYgZGVmaW5lIFlhbmcgbW9kZWxzIGZvciBldmVyeXRoaW5nIG9mIEV0 aGVybmV0IHNwZWNpZmljIHN0YXRpc3RpY3Mgc2luY2UgUk1PTiBNSUIgd2FzIGFscmVhZHkgZGVm aW5lZCBieSBJRVRGIGFuZCBJRUVFIGRlZmluZSBZYW5nIG1vZGVscyBmb3IgZXZlcnl0aGluZyBv ZiBQb3dlciBvdmVyIEV0aGVybmV0IChzaW5jZSBvd25lcnNoaXAgYWxyZWFkeSB0cmFuc2ZlcnJl ZCB0byA4MDIuMyk/ICBJIHBlcnNvbmFsbHkgdGhpbmsgdGhpcyBzaW1wbGUgYXBwcm9hY2ggY291 bGQgbWFrZSBvdXIgbGlmZSBlYXNpZXIsIOKYug0KSSB0aGluayB0aGF0IHRoaXMgYXBwcm9hY2gg bWF5IGhpdCBzb21lIG9mIHRoZSBpc3N1ZXMgYWJvdmUgKHBhcnRpY3VsYXJseSB0aGUgcmVsYXRp b25zaGlwIHRvIGhhcmR3YXJlIGFuZCBjbGF1c2UgMzAgcmVnaXN0ZXJzKS4NCg0KVGhhbmtzLA0K Um9iDQoNCg0KDQoNCkp1c3Qgc29tZSBsb3VkIHRoaW5raW5n4oCmDQoNCg0KDQoNClRoYW5rcw0K DQpGYXRhaQ0KDQrlj5Hku7bkuro6IENDQU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9y Z10g5Luj6KGoIFJvYmVydCBXaWx0b24NCuWPkemAgeaXtumXtDogMjAxN+W5tDPmnIgyMuaXpSAy MzoyMQ0K5pS25Lu25Lq6OiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz47 IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCuS4u+mimDogW0NDQU1QXSA4 MDIuMyBFdGhlcm5ldCBZQU5HICg4MDIuM2NwKSBhbmQgSUVURiBvdmVybGFwDQoNCg0KSGksDQoN CkknbSBwYXJ0aWNpcGF0aW5nIGluIHRoZSA4MDIuMyB0YXNrIGZvcmNlICg4MDIuM2NmKSB0byBw cm9kdWNlIHN0YW5kYXJkIFlBTkcgbW9kZWxzIGZvciBFdGhlcm5ldCBpbnRlcmZhY2VzIGFuZCBw cm90b2NvbHMgY292ZXJlZCBieSB0aGUgSUVFRSA4MDIuMyBFdGhlcm5ldCBXb3JraW5nIEdyb3Vw Lg0KDQpBcyBwYXJ0IG9mIG15IGludm9sdmVtZW50IHdpdGggdGhhdCBncm91cCwgSSB3YW50IHRv IGhpZ2hsaWdodCBhIGNvdXBsZSBvZiBpc3N1ZXMgdGhhdCBhcm9zZSBpbiB0aGF0IGZvcnVtIHRo YXQgbWF5IGJlIG9mIGludGVyZXN0IHRvIHZhcmlvdXMgV0dzIGluIElFVEYuDQoNClRoaXMgZW1h aWwsIGFuZCBhY2NvbXBhbnlpbmcgc2xpZGVzLCByZXByZXNlbnRzIG15IHBlcnNvbmFsIHZpZXdz LCBhbmQgZG8gbm90IHJlcHJlc2VudCBhbnkgZm9ybWFsIElFRUUgcG9zaXRpb24uICBIb3dldmVy LCBib3RoIHRoaXMgZW1haWwgYW5kIHRoZSBhY2NvbXBhbnlpbmcgc2xpZGVzIGhhdmUgYmVlbiBy ZXZpZXdlZCBpbiBhbiA4MDIuM2NmIHRhc2sgZm9yY2UgbWVldGluZywgYW5kIHRoZXJlIHdlcmUg bm8gb2JqZWN0aW9ucyB0byB0aGUgY29udGVudCwgb3IgbXkgc2VuZGluZyBvZiB0aGlzIGVtYWls IHRvIElFVEYuDQoNCkkgYWxzbyByYWlzZWQgdGhlc2UgaXNzdWVzICh3aXRoIGFuIGVhcmxpZXIg c2V0IG9mIHNsaWRlcykgYXMgcGFydCBvZiB0aGUgSUVURi9JRUVFIGxpYWlzb24gbWVldGluZyBv biAzMXN0IEphbnVhcnksIGFuZCB0aGUgY29uc2Vuc3VzIHdhcyBnZW5lcmFsbHkgc3VwcG9ydGl2 ZSBvZiB0aGlzIGFwcHJvYWNoLCB3aXRoIHRoZSBhZ3JlZWQgbmV4dCBzdGVwcyB0byBjb250YWN0 IHRoZSBORVRNT0QgYW5kIENDQU1QIGNoYWlycywgd2hpY2ggSSBoYXZlIGRvbmUsIGFuZCB0aGUg V0dzIChoZW5jZSB0aGlzIGVtYWlsKToNCg0KDQoNCkFzIHBhcnQgb2YgdGhhdCBZQU5HIG1vZGVs bGluZyB3b3JrLCB0aGVyZSBpcyBhbiBhaW0gdG8gZGVmaW5lIGEgY2xlYW4gYm91bmRhcnkgb2Yg d2hhdCBtYW5hZ2VhYmlsaXR5IGRhdGEgc2hvdWxkIGJlIHNwZWNpZmllZCB3aXRoaW4gODAyLjMg YW5kIHdoYXQgYmVsb25ncyBvdXRzaWRlIHRoZSA4MDIuMyBzcGVjaWZpY2F0aW9ucy4NCg0KVGhl IGRlZmluaXRpb24gdGhhdCB0aGUgdGFzayBmb3JjZSBpcyBjb252ZXJnaW5nIG9uIGlzIHRoYXQg ZXZlcnl0aGluZyByZWxhdGVkIHRvIEV0aGVybmV0LCBjb3ZlcmVkIGJ5IDgwMi4zLCB0aGF0IGNh biBiZSBleHByZXNzZWQgaW4gdGVybXMgb2YgdGhlIDgwMi4zIGNsYXVzZSAzMCBtYW5hZ2VhYmls aXR5IGRlZmluaXRpb25zLCBzaG91bGQgYmUgbW9kZWxlZCBpbiA4MDIuMy4gIEkuZS4gYnJvYWRs eSBldmVyeXRoaW5nIHRoYXQgaXMgY292ZXJlZCBieSA4MDIuMy4xIHRvZGF5LiAgQnV0IGFueSBt YW5hZ2VhYmlsaXR5IGluZm9ybWF0aW9uIHRoYXQgY2Fubm90IGJlIHJlbGF0ZWQgdG8gY2xhdXNl IDMwIGRlZmluaXRpb25zIHNob3VsZCBiZSBzcGVjaWZpZWQgb3V0c2lkZSBvZiA4MDIuMy4gIE5v dGUsIHdoZXJlIGFwcHJvcHJpYXRlLCBhZGRpdGlvbmFsIGNsYXVzZSAzMCBkZWZpbml0aW9ucyBt YXkgYmUgYWRkZWQgdG8gZml4IGFueSBtaXN0YWtlcyBvciBnbGFyaW5nIGdhcHMuDQoNCg0KDQpU byB0aGlzIGVuZCwgdGhlcmUgYXJlIGEgY291cGxlIG9mIGFyZWFzIGJldHdlZW4gSUVURiBhbmQg ODAyLjMgdGhhdCBkb24ndCBuZWNlc3NhcmlseSBsb29rIGxpa2UgdGhleSBhcmUgZW50aXJlbHkg aW4gdGhlIHJpZ2h0IHBsYWNlLCBpbiBwYXJ0aWN1bGFyOg0KDQoxKSBUaGUgUk1PTiBNSUIgKFJG QyAyODE5KSBkZWZpbmVzIChhbG9uZyB3aXRoIG90aGVyIG5vbi1FdGhlcm5ldCByZWxhdGVkIGNv bnRlbnQpIHNvbWUgRXRoZXJuZXQgc3BlY2lmaWMgc3RhdGlzdGljcyB0aGF0IHdvdWxkIGJlIGJl dHRlciBjby1sb2NhdGVkIHdpdGggdGhlIEV0aGVybmV0IGludGVyZmFjZSBZQU5HIG1vZGVsIGJl aW5nIGRlZmluZWQgaW4gODAyLjNjcC4gIEhlbmNlLCB0aGUgcHJvcG9zYWwgaXMgdG8gc3Vic3Vt ZSB0aGUgYXBwcm9wcmlhdGUgRXRoZXJuZXQgc3RhdGlzdGljcyBmcm9tIHRoZSBSTU9OIE1JQiBp bnRvIGEgc2luZ2xlIGNvbWJpbmVkIHJlZmVyZW5jZSBzZXQgZGVmaW5lZCBpbiA4MDIuM2NwLg0K DQoyKSBUaGUgUk1PTiBNSUIgYWxzbyBkZWZpbmVzIHNvbWUgRXRoZXJuZXQgc3BlY2lmaWMgc3Rh dGlzdGljcyB0aGF0IGNhbid0IGJlIGRlZmluZWQgYXMgcGFydCBvZiA4MDIuM2NmIGJlY2F1c2Ug dGhleSBkb24ndCByZWxhdGUgdG8gODAyLjMgY2xhdXNlIDMwIHJlZ2lzdGVycywgYnV0IGFyZSBz dGlsbCB3aWRlbHkgc3VwcG9ydGVkIGJ5IHZlbmRvcnMsIGFuZCBzaG91bGQgYmUgbW9kZWxlZCBp biBZQU5HLiAgVGhlIHByb3Bvc2FsIGlzIHRoYXQgZGVmaW5pdGlvbnMgcmVsYXRlZCB0byB0aGVz ZSBjb3VudGVycyBjb3VsZCBiZSBhZGRlZCBhcyBwYXJ0IG9mIHRoZSBFdGhlcm5ldC1saWtlIG1v ZHVsZSBkcmFmdC1pZXRmLW5ldG1vZC1pbnRmLWV4dC15YW5nLTAzPGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLWludGYtZXh0LXlhbmcvPiwgb3IgcGVy aGFwcyBhIHJlbGF0ZWQgRXRoZXJuZXQgbW9kdWxlIGluIHRoZSBzYW1lIGRyYWZ0Lg0KDQozKSBU aGUgUG93ZXItRXRoZXJuZXQgTUlCIChkZWZpbmVkIGluIFJGQyAzNjIxLCBidXQgYWxzbyByZWZl cmVuY2VkIGZyb20gUkZDIDc0NjApLCB3YXMgb3JpZ2luYWxseSBzcGVjaWZpZWQgaW4gSUVURiwg YnV0IG93bmVyc2hpcCBsYXRlciB0cmFuc2ZlcnJlZCB0byA4MDIuMyAodmlhIFJGQyA3NDQ4KS4g IFdoaWxzdCB3b3JraW5nIG9uIHRoZSBQb3dlciBvdmVyIEV0aGVybmV0IFlBTkcgbW9kZWwgaXQg aGFzIGJlY29tZSBjbGVhciB0aGF0IG5vdCBhbGwgb2YgdGhlIGF0dHJpYnV0ZXMgZGVmaW5lZCBp biB0aGUgTUlCIG1hcCB0byB0aGUgdW5kZXJseWluZyA4MDIuMyBjbGF1c2UgMzAgZGVmaW5pdGlv bnMuICBGdXJ0aGVyLCBpdCBsb29rcyBsaWtlIHBhcnRzIG9mIHRoaXMgWUFORyBtb2RlbCB3b3Vs ZCBiZSBiZXR0ZXIgZGVmaW5lZCBhcyBleHRlbnNpb25zIHRvIHRoZSBFbnRpdHkgWUFORyBtb2Rl bCBiZWluZyBkZWZpbmVkIGluIE5FVE1PRC4gIFRoZSBwcm9wb3NhbCBpcyB0aGF0IHRoZSBwYXJ0 cyBvZiB0aGUgUG93ZXIgb3ZlciBFdGhlcm5ldCBZQU5HIG1vZGVsIHRoYXQgY2FuIGJlIGRpcmVj dGx5IHJlbGF0ZWQgdG8gY2xhdXNlIDMwIGRlZmluaXRpb25zIChlLmcuIHBldGhQc2VQb3J0VGFi bGUpIHNob3VsZCBiZSBkZWZpbmVkIGluIDgwMi4zY2YsIGJ1dCB0aGF0IHRoZSByZW1haW5pbmcg cGFydHMgKGUuZy4sIHBldGhNYWluUHNlT2JqZWN0cyApIGNhbiBob3BlZnVsbHkgYmUgc3RhbmRh cmRpemVkIGluIElFVEYuDQoNCg0KDQpEbyB5b3UgaGF2ZSBhbnkgY29tbWVudHMsIG9yIGNvbmNl cm5zLCBvbiB0aGUgMyBwcm9wb3NhbHMgYWJvdmU/DQoNClJlZ2FyZHMsDQpSb2IgV2lsdG9uDQoN Cg== --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A951C2FEnkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk65a6L5L2TOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0 ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgljb2xv cjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglm b250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBw dCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhlIG1haW4gcG9pbnQgaXMgdGhhdCA4MDIuMyBkZWZpbmVzIFBIWSBzcGVjcyBmb3Ig RXRoZXJuZXQgZGV2aWNlcyBhbG9uZyB3aXRoIG1hbmFnZWQgb2JqZWN0cyAod2hpY2ggY2FuIGJl IGNvbnNpZGVyZWQgYXMgbWFuYWdlbWVudCBpbnRlcmZhY2UpDQogdG8gbWFuYWdlIHRob3NlIHBo eXMgYnkgc2V0dGluZy9yZWFkaW5nIHJlZ2lzdGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkV2ZW4gODAyLjMgbm93IGFncmVlcyB0byBhZGQgZXh0cmEgYXR0 cmlidXRlcyBmcm9tIE1JQiBidXQgYmV5b25kIENsYXVzZSAzMCwgdGhvc2UgYXR0cmlidXRlcyBh cmUgc3RpbGwgbmVlZGVkIHRvIGJlIHN1cHBvcnRlZCBieSA4MDIuMyBoYXJkd2FyZeKApi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIHRoZSBtYW5hZ2VtZW50IG9mIHRo ZXNlIGRldmljZXMsIDgwMi4zIHdpbGwgcHJvdmlkZSBtYW5hZ2VtZW50IGludGVyZmFjZXMgYWNj b3JkaW5nIHRvIHRoZSBjYXBhYmlsaXR5IG9mIHRoZWlyIGRlZmluZWQgUEhZcy4gJm5ic3A7UHJl dmlvdXNseSwgaW4NCiBmb3JtIG9mIE1JQnMsIG5vdyBpbiBmb3JtIG9mIFlBTkcgbW9kdWxlcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBmb3IgdGhlIHN5 c3RlbSBsZXZlbCBtYW5hZ2VtZW50LCB3ZSB0aGluayBJRVRGIGlzIGEgbW9yZSBhcHByb3ByaWF0 ZSBwbGFjZSB0byBkaXNjdXNzIHNpbmNlIDgwMi4zIGlzIG5vdCBleHBlcnQgaW4gdGhpcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIHRoZSBFdGhlcm5ldCBpbnRlcmZh Y2UsIGFzIGRpc2N1c3NlZCwgdGhlIHN5c3RlbSByZWxhdGVkIG9yIGdlbmVyaWMgbWFuYWdlbWVu dCBhcmUgc3VnZ2VzdGVkIHRvIGJlIGluY2x1ZGVkIGluIFJvYmVydOKAmXMgaW50Zi1leHQteWFu ZyBtb2R1bGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3Ig dGhlIFBvRSBwYXJ0LCB0aGUgcG93ZXIgc3lzdGVtIG1hbmFnZW1lbnQgKGluY2x1ZGluZyB0aGUg cG93ZXIgc291cmNlIGFuZCB0aGUgcG9lIHBvcnQgcHJpb3JpdHkpIGlzIGEgc3lzdGVtIGxldmVs IG1hbmFnZW1lbnQgYW5kIHdvdWxkIGxpa2UNCiB0byBoZWFyIElFVEbigJlzIHRob3VnaHRzIG9u IHRoaXMgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmsg eW91IGZvciB5b3VyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllhbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRv d3RleHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQi PiBSb2JlcnQgV2lsdG9uIFttYWlsdG86cndpbHRvbkBjaXNjby5jb21dDQo8YnI+DQo8L3NwYW4+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5Y+R6YCB 5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+IDIwMTc8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5bm0PHNw YW4gbGFuZz0iRU4tVVMiPjM8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjIzPC9zcGFuPuaX pTxzcGFuIGxhbmc9IkVOLVVTIj4NCiAyMjo1OTxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3Bh biBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBGYXRhaSBaaGFu ZzsgbmV0bW9kQGlldGYub3JnOyBjY2FtcEBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7mioTpgIE8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBaaHVhbmd5 YW4gKFlhbik8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IDwvc3Bhbj7nrZTlpI08c3BhbiBsYW5nPSJFTi1V UyI+OiBbQ0NBTVBdIDgwMi4zIEV0aGVybmV0IFlBTkcgKDgwMi4zY3ApIGFuZCBJRVRGIG92ZXJs YXA8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj5IaSBGYXRhaSw8YnI+DQo8YnI+DQpUaGFua3MgZm9yIHRoZSBjb21t ZW50cy9yZXZpZXcuPGJyPg0KPGJyPg0KU29ycnksIG9uZSBjb3JyZWN0aW9uIGluIG15IGVtYWls LiZuYnNwOyBUaGUgODAyLjMgWUFORyBwcm9qZWN0IGlzIG9ubHkgODAyLjNjZi4mbmJzcDsgU29t ZXRpbWVzIEkgaGF2ZSBtYW5hZ2VkIHRvIG1hbmdsZSB0aGUgbmFtZSB0b2dldGhlciB3aXRoIHRo ZSA4MDIuMSBZQU5HIHByb2plY3QgKDgwMi4xY3ApIC4uLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+T24gMjMvMDMvMjAxNyAwMzo1MSwgRmF0YWkgWmhhbmcgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUm9iLDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciBzaGFyaW5nIHRoZSBpbmZvcm1hdGlvbi48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgeW91IGFyZSB0YWxraW5nIGFi b3V0IHR3byB0eXBlcyBvZiBZYW5nIG1vZGVscywgb25lIGlzIEV0aGVybmV0IHNwZWNpZmljIHN0 YXRpc3RpY3MsIGFuZCB0aGUgb3RoZXIgb25lIGlzIFBvd2VyIG92ZXIgRXRoZXJuZXQuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2UgYXJlIHRyeWluZyB0 byBjb252ZXJ0IHZhcmlvdXMgTUlCcyB0aGF0IGNvbnRhaW4gRXRoZXJuZXQgcmVsYXRlZCBmdW5j dGlvbmFsaXR5IHRvIFlBTkcuJm5ic3A7IEdlbmVyYWxseSB0aGUgTUlCUyB3ZXJlIGRlZmluZWQg aW4gSUVURi4mbmJzcDsgU29tZSBvZiB0aGVtIGhhdmUgYmVlbiB0cmFuc2ZlcnJlZCB0byBJRUVF IGZvciBvd25lcnNoaXAuPGJyPg0KPGJyPg0KSW4gdGhlIHByb2Nlc3Mgb2YgY29udmVydGluZyB0 aGUgY29udGVudCBmcm9tIE1JQnMgdG8gWUFORyB3ZSBhcmUgdGFraW5nIHRoZSBvcHBvcnR1bml0 eSB0byByZWZpbmUgdGhlIGNvbnRlbnRzIHRvIGJldHRlciBtZWV0IGN1cnJlbnQgcmVxdWlyZW1l bnRzLiZuYnNwOyBFLmcuIENTTUEvQ0QgY29sbGlzaW9uIGNvdW50ZXJzIGFyZSBnZW5lcmFsbHkg bm90IG9mIHJlbGV2YW5jZSBvbiBhbnkgY3VycmVudCBFdGhlcm5ldCBoYXJkd2FyZS4NCjxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgSSB0aGlu ayB5b3VyIHByb3Bvc2FscyBhcmUgdGhhdCBzb21lIHBhcnQgb2YgZWFjaCBvZiB0aGVtIHNob3Vs ZCBiZSBkZWZpbmVkIGluIDgwMi4zY3Agb3IgODAyLjNjZiwgYW5kIHRoZSBsZWZ0DQogcGFydCBv ZiBlYWNoIG9mIHRoZW0gc2hvdWxkIGJlIGRlZmluZWQgaW4gSUVURi4gPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+QmFzaWNhbGx5LCB5ZXMsIHRoYXQgaXMgY29ycmVjdC48YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkkgYW0gYSBsaXR0bGUgY29uY2VybmVkIHRoYXQgaG93IHBlb3BsZSBjYW4gZGlzdGluZ3Vp c2ggYW5kIGp1ZGdlIHdoaWNoIHBhcnQgKGUuZy4sIG9mIEV0aGVybmV0IHNwZWNpZmljIHN0YXRp c3RpY3Mgb3IgUG93ZXIgb3ZlciBFdGhlcm5ldCkgc2hvdWxkDQogYmUgZGVmaW5lZCBpbiBJRUVF IG9yIElFRlQ/IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkEgbG90IG9mIHRoZSA4 MDIuMyBFdGhlcm5ldCBzcGVjaWZpY2F0aW9uIGNvbmNlcm5zIGZ1bmN0aW9uYWxpdHkgdGhhdCBp cyBiYWtlZCBpbnRvIHRoZSBoYXJkd2FyZS4mbmJzcDsgVGhlIDgyMC4zIHNwZWNpZmljYXRpb24g ZGVmaW5lcyAodmlhIENsYXVzZSAzMCkgYW4gaW50ZXJuYWwgbWFuYWdlbWVudCBBUEkgZm9yIGNv bmZpZ3VyYXRpb24gYW5kIHJldHJpZXZhbCBvZiBvcGVyYXRpb25hbA0KIHBhcmFtZXRlcnMgZnJv bSB0aGUgaGFyZHdhcmUuPGJyPg0KPGJyPg0KU28sIHRoZSA4MDIuM2NmIHBsYW4gaXMgdGhhdCBh bGwgb2YgdGhlIEV0aGVybmV0IHJlbGF0ZWQgcGFydHMgb2YgWUFORywgb3IgTUlCLCBtb2R1bGVz IHRoYXQganVzdCByZXByZXNlbnQgdGhlIHZhbHVlcyBkZWZpbmVkIGluIGNsYXVzZSAzMCBhcmUg ZXhwZWN0ZWQgdG8gcHVibGlzaGVkIGFzIHBhcnQgb2YgdGhlIDgwMi4zIEV0aGVybmV0IFlBTkcg bW9kdWxlcy48YnI+DQo8YnI+DQpIb3dldmVyLCA4MDIuM2NmIGRvIG5vdCB3YW50IHRoZWlyIHN0 YW5kYXJkIFlBTkcgbW9kZWxzIHRvIG1hcCB0byBwYXJhbWV0ZXJzIHRoYXQgYXJlIG5vdCBjb3Zl cmVkIGJ5IGNsYXVzZSAzMCAoZXhjZXB0aW5nIGEgZmV3IG1vcmUgb2J2aW91cyBvbWlzc2lvbnMp IGJlY2F1c2UgdGhhdCBtaWdodCBtZWFuIHRoYXQgdGhlIFlBTkcgbW9kdWxlIGNhbm5vdCBiZSBm dWxseSBzdXBwb3J0ZWQgYnkgY3VycmVudCBkZXZpY2VzIChlLmcuIGlmIHRoZXkgZG9uJ3QNCiBo YXZlIHRoZSBhY3R1YWwgaGFyZHdhcmUgcHJlc2VudCB0byBwcm92aWRlIHRoZSBuZWNlc3Nhcnkg Y291bnRlcnMpLjxicj4NCjxicj4NClNvLCB0aGUgcHJvcG9zYWwgaXMgdGhhdCBzb21lIHBhcnRz IG9mIHRoZSBFdGhlcm5ldCBzdGF0aXN0aWNzIGdldCBzdGFuZGFyZGl6ZWQgaW4gSUVURiBpbnN0 ZWFkIChwcm9iYWJseSB2aWEgTkVUTU9EKS48YnI+DQo8YnI+DQpDb25jcmV0ZWx5LCBteSBkZXNp cmUgaXMgZm9yIHRoZSBmb2xsb3dpbmcgYml0cyB3b3VsZCBiZSBzdGFuZGFyZGl6ZWQgaW4gSUVU Rjo8YnI+DQombmJzcDsgMSkgSGlzdG9ncmFtIHBhY2tldCBzdGF0aXN0aWNzIChmcm9tIFJNT04p IChiZWNhdXNlIHZlbmRvcnMgb2Z0ZW4gc3VwcG9ydCBFdGhlcm5ldCBmcmFtZXMgdXAgdG8gOWsg Ynl0ZXMsIGJ1dCB0aGUgZm9ybWFsIDgwMi4zIHNwZWNpZmljYXRpb24gb25seSBnb2VzIHVwIHRv IDJrKS4mbmJzcDsgVG8gYmUgYWRkZWQgdG8gZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQteWFu Zy0wNA0KPGJyPg0KJm5ic3A7IDIpIFNvbWUgY291bnRlcnMgdGhhdCBtb3JlIGdlbmVyYWxseSBh cHBseSB0byBFdGhlcm5ldC1saWtlIGludGVyZmFjZXMgKGUuZy4gTEFHLCBJUkIsIG9yIFBzZXVk by13aXJlIGhlYWQtZW5kIGludGVyZmFjZXMpLiZuYnNwOyBUaGlzIHdvdWxkIGluY2x1ZGUgdGhl IG51bWJlciBvZiBwYWNrZXRzIGRyb3BwZWQgYmVjYXVzZSB0aGV5IGRvbid0IG1hdGNoIHRoZSBk ZXN0aW5hdGlvbiBNQUMgYWRkcmVzcyBmaWx0ZXIuJm5ic3A7IFRvIGJlIGFkZGVkIHRvIGRyYWZ0 LWlldGYtbmV0bW9kLWludGYtZXh0LXlhbmctMDQuPGJyPg0KJm5ic3A7IDMpIFRoZSBwYXJ0cyBv ZiBwb3dlciBtYW5hZ2VtZW50IHRoYXQgcmVsYXRlIHRvIHBvd2VyIHN1cHBsaWVzIHJhdGhlciB0 aGFuIEV0aGVybmV0IGludGVyZmFjZXMuJm5ic3A7IFlhbiBoYXMgc3VibWl0dGVkIGEgZHJhZnQg dG8gTkVUTU9EIGZvciB0aGlzLCBkcmFmdC16aHVhbmctbmV0bW9kLXlhbmctcG9lLW1hbmFnZW1l bnQtMDEuJm5ic3A7IEkndmUgbm90IHJldmlld2VkIHRoaXMgZHJhZnQgeWV0LCBidXQgaXQgbWF5 IGJlIHRoYXQgaXQgc2hvdWxkIGF1Z21lbnQNCiB0aGUgZW50aXR5IFlBTkcgbW9kZWwgKGRyYWZ0 LWlldGYtbmV0bW9kLWVudGl0eS0wMykuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgZXhhbXBsZSwgcmVn YXJkaW5nIEV0aGVybmV0IHNwZWNpZmljIHN0YXRpc3RpY3MsIGhvdyBwZW9wbGUgY2FuIGV4YWN0 bHkga25vdyB3aGljaCBpbmZvcm1hdGlvbiBjb3VsZCBiZSBiZXR0ZXIgY28tbG9jYXRlZCBpbiA4 MDIuM2NwIGFuZCB3aGljaA0KIGRvbuKAmXQgJm5ic3A7cmVsYXRlIHRvIDgwMi4zPyA8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSB0aGluayBkaWZmZXJlbnQgcGVvcGxlIG1pZ2h0IGhhdmUgZGlmZmVyZW50IHVuZGVy c3RhbmRpbmcgYW5kIHRoZW4gaXQgd2lsbCBicmluZyBjb25mdXNpb24gdG8gdGhlIGluZHVzdHJ5 Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBvc3NpYmx5IHRoaXMgd2lsbCBiZSB0 cnVlLCBidXQgb25jZSB0aGVzZSBiYXNlIG1vZGVscyBhcmUgc3RhbmRhcmRpemVkLCBJJ20gbm90 IHN1cmUgdGhhdCB0aGV5IGFyZSBsaWtlbHkgdG8gZXZvbHZlIHBhcnRpY3VsYXJseSBxdWlja2x5 LiZuYnNwOyBJIHdvdWxkIHRoaW5rIHRoYXQgaWYgdGhlIHdvcmsgaXMgYmVpbmcgZG9uZSBpbiA4 MDIuMyB0aGVuIGFueSBhc3NvY2lhdGVkIFlBTkcNCiB3b3VsZCBiZSBzdGFuZGFyZGl6ZWQgdGhl cmUsIHNpbWlsYXJseSBmb3IgSUVURi48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3cgYWJvdXQg YWxsb3cgSUVURiBkZWZpbmUgWWFuZyBtb2RlbHMgZm9yIGV2ZXJ5dGhpbmcgb2YgRXRoZXJuZXQg c3BlY2lmaWMgc3RhdGlzdGljcyBzaW5jZSBSTU9OIE1JQiB3YXMgYWxyZWFkeSBkZWZpbmVkIGJ5 IElFVEYgYW5kIElFRUUgZGVmaW5lDQogWWFuZyBtb2RlbHMgZm9yIGV2ZXJ5dGhpbmcgb2YgUG93 ZXIgb3ZlciBFdGhlcm5ldCAoc2luY2Ugb3duZXJzaGlwIGFscmVhZHkgdHJhbnNmZXJyZWQgdG8g ODAyLjMpPyAmbmJzcDtJIHBlcnNvbmFsbHkgdGhpbmsgdGhpcyBzaW1wbGUgYXBwcm9hY2ggY291 bGQgbWFrZSBvdXIgbGlmZSBlYXNpZXIsDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB0aGluayB0aGF0IHRoaXMgYXBwcm9h Y2ggbWF5IGhpdCBzb21lIG9mIHRoZSBpc3N1ZXMgYWJvdmUgKHBhcnRpY3VsYXJseSB0aGUgcmVs YXRpb25zaGlwIHRvIGhhcmR3YXJlIGFuZCBjbGF1c2UgMzAgcmVnaXN0ZXJzKS48YnI+DQo8YnI+ DQpUaGFua3MsPGJyPg0KUm9iPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SnVzdCBzb21l IGxvdWQgdGhpbmtpbmfigKY8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpq dXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTpp bnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtz PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRl ci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RmF0YWk8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij7lj5Hku7bkuro8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4gQ0NBTVAgWzxhIGhyZWY9 Im1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 d2luZG93dGV4dCI+5Luj6KGoIDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPlJvYmVydCBXaWx0b248YnI+DQo8L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5Y+R 6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+IDIwMTc8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5bm0 PHNwYW4gbGFuZz0iRU4tVVMiPjM8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjIyPC9zcGFu PuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiAyMzoyMTxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiA8YSBocmVm PSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj4NCm5ldG1vZEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9 Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxi PuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+ IFtDQ0FNUF0gODAyLjMgRXRoZXJuZXQgWUFORyAoODAyLjNjcCkgYW5kIElFVEYgb3ZlcmxhcDwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5JJ20gcGFydGljaXBhdGlu ZyBpbiB0aGUgODAyLjMgdGFzayBmb3JjZSAoODAyLjNjZikgdG8gcHJvZHVjZSBzdGFuZGFyZCBZ QU5HIG1vZGVscyBmb3IgRXRoZXJuZXQgaW50ZXJmYWNlcyBhbmQgcHJvdG9jb2xzIGNvdmVyZWQg YnkgdGhlIElFRUUgODAyLjMgRXRoZXJuZXQgV29ya2luZyBHcm91cC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+QXMgcGFydCBvZiBteSBpbnZvbHZlbWVudCB3 aXRoIHRoYXQgZ3JvdXAsIEkgd2FudCB0byBoaWdobGlnaHQgYSBjb3VwbGUgb2YgaXNzdWVzIHRo YXQgYXJvc2UgaW4gdGhhdCBmb3J1bSB0aGF0IG1heSBiZSBvZiBpbnRlcmVzdCB0byB2YXJpb3Vz IFdHcyBpbiBJRVRGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGlzIGVtYWlsLCBhbmQgYWNjb21wYW55aW5nIHNsaWRlcywgcmVwcmVzZW50cyBteSBwZXJz b25hbCB2aWV3cywgYW5kIGRvIG5vdCByZXByZXNlbnQgYW55IGZvcm1hbCBJRUVFIHBvc2l0aW9u LiZuYnNwOyBIb3dldmVyLCBib3RoIHRoaXMgZW1haWwgYW5kIHRoZSBhY2NvbXBhbnlpbmcgc2xp ZGVzIGhhdmUgYmVlbiByZXZpZXdlZCBpbiBhbiA4MDIuM2NmIHRhc2sgZm9yY2UgbWVldGluZywg YW5kIHRoZXJlIHdlcmUNCiBubyBvYmplY3Rpb25zIHRvIHRoZSBjb250ZW50LCBvciBteSBzZW5k aW5nIG9mIHRoaXMgZW1haWwgdG8gSUVURi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1VUyI+SSBhbHNvIHJhaXNlZCB0aGVzZSBpc3N1ZXMgKHdpdGggYW4gZWFybGll ciBzZXQgb2Ygc2xpZGVzKSBhcyBwYXJ0IG9mIHRoZSBJRVRGL0lFRUUgbGlhaXNvbiBtZWV0aW5n IG9uIDMxc3QgSmFudWFyeSwgYW5kIHRoZSBjb25zZW5zdXMgd2FzIGdlbmVyYWxseSBzdXBwb3J0 aXZlIG9mIHRoaXMgYXBwcm9hY2gsIHdpdGggdGhlIGFncmVlZCBuZXh0IHN0ZXBzIHRvIGNvbnRh Y3QgdGhlIE5FVE1PRCBhbmQgQ0NBTVANCiBjaGFpcnMsIHdoaWNoIEkgaGF2ZSBkb25lLCBhbmQg dGhlIFdHcyAoaGVuY2UgdGhpcyBlbWFpbCk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIj5BcyBwYXJ0IG9mIHRoYXQgWUFORyBtb2RlbGxpbmcgd29yaywgdGhlcmUgaXMg YW4gYWltIHRvIGRlZmluZSBhIGNsZWFuIGJvdW5kYXJ5IG9mIHdoYXQgbWFuYWdlYWJpbGl0eSBk YXRhIHNob3VsZCBiZSBzcGVjaWZpZWQgd2l0aGluIDgwMi4zIGFuZCB3aGF0IGJlbG9uZ3Mgb3V0 c2lkZSB0aGUgODAyLjMgc3BlY2lmaWNhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBkZWZpbml0aW9uIHRoYXQgdGhlIHRhc2sgZm9yY2UgaXMg Y29udmVyZ2luZyBvbiBpcyB0aGF0IGV2ZXJ5dGhpbmcgcmVsYXRlZCB0byBFdGhlcm5ldCwgY292 ZXJlZCBieSA4MDIuMywgdGhhdCBjYW4gYmUgZXhwcmVzc2VkIGluIHRlcm1zIG9mIHRoZSA4MDIu MyBjbGF1c2UgMzAgbWFuYWdlYWJpbGl0eSBkZWZpbml0aW9ucywgc2hvdWxkIGJlIG1vZGVsZWQg aW4gODAyLjMuJm5ic3A7IEkuZS4gYnJvYWRseSBldmVyeXRoaW5nDQogdGhhdCBpcyBjb3ZlcmVk IGJ5IDgwMi4zLjEgdG9kYXkuJm5ic3A7IEJ1dCBhbnkgbWFuYWdlYWJpbGl0eSBpbmZvcm1hdGlv biB0aGF0IGNhbm5vdCBiZSByZWxhdGVkIHRvIGNsYXVzZSAzMCBkZWZpbml0aW9ucyBzaG91bGQg YmUgc3BlY2lmaWVkIG91dHNpZGUgb2YgODAyLjMuJm5ic3A7IE5vdGUsIHdoZXJlIGFwcHJvcHJp YXRlLCBhZGRpdGlvbmFsIGNsYXVzZSAzMCBkZWZpbml0aW9ucyBtYXkgYmUgYWRkZWQgdG8gZml4 IGFueSBtaXN0YWtlcyBvciBnbGFyaW5nDQogZ2Fwcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiPlRvIHRoaXMgZW5kLCB0aGVyZSBhcmUgYSBjb3VwbGUgb2YgYXJlYXMg YmV0d2VlbiBJRVRGIGFuZCA4MDIuMyB0aGF0IGRvbid0IG5lY2Vzc2FyaWx5IGxvb2sgbGlrZSB0 aGV5IGFyZSBlbnRpcmVseSBpbiB0aGUgcmlnaHQgcGxhY2UsIGluIHBhcnRpY3VsYXI6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjEpIFRoZSBSTU9OIE1JQiAo UkZDIDI4MTkpIGRlZmluZXMgKGFsb25nIHdpdGggb3RoZXIgbm9uLUV0aGVybmV0IHJlbGF0ZWQg Y29udGVudCkgc29tZSBFdGhlcm5ldCBzcGVjaWZpYyBzdGF0aXN0aWNzIHRoYXQgd291bGQgYmUg YmV0dGVyIGNvLWxvY2F0ZWQgd2l0aCB0aGUgRXRoZXJuZXQgaW50ZXJmYWNlIFlBTkcgbW9kZWwg YmVpbmcgZGVmaW5lZCBpbiA4MDIuM2NwLiZuYnNwOyBIZW5jZSwgdGhlIHByb3Bvc2FsDQogaXMg dG8gc3Vic3VtZSB0aGUgYXBwcm9wcmlhdGUgRXRoZXJuZXQgc3RhdGlzdGljcyBmcm9tIHRoZSBS TU9OIE1JQiBpbnRvIGEgc2luZ2xlIGNvbWJpbmVkIHJlZmVyZW5jZSBzZXQgZGVmaW5lZCBpbiA4 MDIuM2NwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4yKSBU aGUgUk1PTiBNSUIgYWxzbyBkZWZpbmVzIHNvbWUgRXRoZXJuZXQgc3BlY2lmaWMgc3RhdGlzdGlj cyB0aGF0IGNhbid0IGJlIGRlZmluZWQgYXMgcGFydCBvZiA4MDIuM2NmIGJlY2F1c2UgdGhleSBk b24ndCByZWxhdGUgdG8gODAyLjMgY2xhdXNlIDMwIHJlZ2lzdGVycywgYnV0IGFyZSBzdGlsbCB3 aWRlbHkgc3VwcG9ydGVkIGJ5IHZlbmRvcnMsIGFuZCBzaG91bGQgYmUgbW9kZWxlZCBpbiBZQU5H LiZuYnNwOw0KIFRoZSBwcm9wb3NhbCBpcyB0aGF0IGRlZmluaXRpb25zIHJlbGF0ZWQgdG8gdGhl c2UgY291bnRlcnMgY291bGQgYmUgYWRkZWQgYXMgcGFydCBvZiB0aGUgRXRoZXJuZXQtbGlrZSBt b2R1bGUNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtbmV0bW9kLWludGYtZXh0LXlhbmcvIj48c3BhbiBzdHlsZT0iY29sb3I6IzNEMjJCMzt0ZXh0 LWRlY29yYXRpb246bm9uZSI+ZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0wMzwvc3Bh bj48L2E+LCBvciBwZXJoYXBzIGEgcmVsYXRlZCBFdGhlcm5ldCBtb2R1bGUgaW4gdGhlIHNhbWUg ZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjMpIFRo ZSBQb3dlci1FdGhlcm5ldCBNSUIgKGRlZmluZWQgaW4gUkZDIDM2MjEsIGJ1dCBhbHNvIHJlZmVy ZW5jZWQgZnJvbSBSRkMgNzQ2MCksIHdhcyBvcmlnaW5hbGx5IHNwZWNpZmllZCBpbiBJRVRGLCBi dXQgb3duZXJzaGlwIGxhdGVyIHRyYW5zZmVycmVkIHRvIDgwMi4zICh2aWEgUkZDIDc0NDgpLiZu YnNwOyBXaGlsc3Qgd29ya2luZyBvbiB0aGUgUG93ZXIgb3ZlciBFdGhlcm5ldCBZQU5HIG1vZGVs IGl0IGhhcw0KIGJlY29tZSBjbGVhciB0aGF0IG5vdCBhbGwgb2YgdGhlIGF0dHJpYnV0ZXMgZGVm aW5lZCBpbiB0aGUgTUlCIG1hcCB0byB0aGUgdW5kZXJseWluZyA4MDIuMyBjbGF1c2UgMzAgZGVm aW5pdGlvbnMuJm5ic3A7IEZ1cnRoZXIsIGl0IGxvb2tzIGxpa2UgcGFydHMgb2YgdGhpcyBZQU5H IG1vZGVsIHdvdWxkIGJlIGJldHRlciBkZWZpbmVkIGFzIGV4dGVuc2lvbnMgdG8gdGhlIEVudGl0 eSBZQU5HIG1vZGVsIGJlaW5nIGRlZmluZWQgaW4gTkVUTU9ELiZuYnNwOyBUaGUNCiBwcm9wb3Nh bCBpcyB0aGF0IHRoZSBwYXJ0cyBvZiB0aGUgUG93ZXIgb3ZlciBFdGhlcm5ldCBZQU5HIG1vZGVs IHRoYXQgY2FuIGJlIGRpcmVjdGx5IHJlbGF0ZWQgdG8gY2xhdXNlIDMwIGRlZmluaXRpb25zIChl LmcuDQo8aT5wZXRoUHNlUG9ydFRhYmxlPC9pPikgc2hvdWxkIGJlIGRlZmluZWQgaW4gODAyLjNj ZiwgYnV0IHRoYXQgdGhlIHJlbWFpbmluZyBwYXJ0cyAoZS5nLiwNCjxpPnBldGhNYWluUHNlT2Jq ZWN0cyA8L2k+KSBjYW4gaG9wZWZ1bGx5IGJlIHN0YW5kYXJkaXplZCBpbiBJRVRGLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+RG8geW91IGhhdmUgYW55IGNvbW1lbnRz LCBvciBjb25jZXJucywgb24gdGhlIDMgcHJvcG9zYWxzIGFib3ZlPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxicj4NClJvYiBXaWx0b248bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A951C2FEnkgeml513mbxchi_-- From nobody Thu Mar 23 18:32:59 2017 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 1622C129B10 for ; Thu, 23 Mar 2017 18:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 LuBDwOYfDFrJ for ; Thu, 23 Mar 2017 18:32:56 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0138.outbound.protection.outlook.com [104.47.40.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18EF128BE1 for ; Thu, 23 Mar 2017 18:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/3t80LhTWGWzJH6GYIh/kukGO9KVm2oiK3A+bYhgzqY=; b=TqaefA8iDptgya5uBaZj47zStWwsFZJKvzu284NUzBvtD1Oj7QD9BfL7oGwM07LajUqbDGtiVMvGR3zW7lwxHE0rFMOlrba5CyhcMO0dM0viok5AYqEnsPiSl6wAKWZidNUYjVRJgYrNViMEC1d9OmJAGPpE3DoZMvpNOAPep8k= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Fri, 24 Mar 2017 01:32:54 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0991.017; Fri, 24 Mar 2017 01:32:54 +0000 From: Kent Watsen To: Benoit Claise , NETMOD Working Group CC: "Joe Clarke (jclarke)" Thread-Topic: [netmod] file "ietf-foo@2016-03-20.yang" or file "ietf-foo.yang" Thread-Index: AQHSpC3f63JwphpgHEaajT0PcpLwG6Gi8bKA Date: Fri, 24 Mar 2017 01:32:54 +0000 Message-ID: <30B9FE1D-D8E8-4255-847B-DBAD1AA6E73D@juniper.net> References: <02834066-3540-790e-bdda-abc5d90bfdac@cisco.com> In-Reply-To: <02834066-3540-790e-bdda-abc5d90bfdac@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:miTwsIkJcyMx0qM9NhhSO8t+J5WtghX2FDtS7Q55yLYjB7vSc7n1uJg/KIHGhlv7pmeAw/OlsUJCQKAiliCmdtAjOz2zy/RvTwJgV5/NxbWOIM0+ifeVaZZv3SuuLES2ML39qj8bqLbOqsQGTcb//75F9tQeBtmQXywq0z8/Q47MJTM8HP7OQBAaKRB6gRvuOkJkTETQ3/XkjLPoRRrwJSV3HFzBlSEgQDQK7IAc9rh3UmiqRZMzERNEn3teqVFaNlTtDFeRO2EtFVyF/hlqgzCYtVYkv02bGqICN/jwCxeNzyb31ew07t4mo7vxa7nlxLh9PRba1MFc5b7fTFCKyA== x-ms-office365-filtering-correlation-id: b295907b-271d-40e0-a5d8-08d47255b1d7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123558025)(20161123555025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0256C18696 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39850400002)(39860400002)(39840400002)(39410400002)(5423002)(2906002)(6246003)(3280700002)(3660700001)(6486002)(82746002)(83506001)(230783001)(2950100002)(5660300001)(77096006)(7736002)(8676002)(81166006)(3846002)(6506006)(305945005)(25786009)(83716003)(53936002)(38730400002)(6116002)(102836003)(8936002)(4326008)(189998001)(122556002)(36756003)(4001350100001)(66066001)(86362001)(6306002)(6512007)(33656002)(229853002)(54356999)(99286003)(76176999)(50986999)(6436002)(2900100001)(222073002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0B6729EFF31C0B43947EBDD4696F9E27@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2017 01:32:54.6588 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [netmod] file "ietf-foo@2016-03-20.yang" or file "ietf-foo.yang" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 01:32:58 -0000 SGkgQmVub2l0LA0KDQpTZWN0aW9uIDQuMiBvZiByZmM2MTg3YmlzIHNheXM6DQoNCiAgIFRoZSAi PENPREUgQkVHSU5TPiIgdGFnIFNIT1VMRCBiZSBmb2xsb3dlZCBieSBhIHN0cmluZyANCiAgIGlk ZW50aWZ5aW5nIHRoZSBmaWxlIG5hbWUgc3BlY2lmaWVkIGluIFNlY3Rpb24gNS4yIG9mIA0KICAg W1JGQzc5NTBdLg0KDQpXaGlsZSBTZWN0aW9uIDUuMiBvZiBSRkM3OTUwIHNheXM6DQoNCiAgIFRo ZSBuYW1lIG9mIHRoZSBmaWxlIFNIT1VMRCBiZSBvZiB0aGUgZm9ybToNCg0KICAgICBtb2R1bGUt b3Itc3VibW9kdWxlLW5hbWUgWydAJyByZXZpc2lvbi1kYXRlXSAoICcueWFuZycgLyAnLnlpbicg KQ0KDQogICAibW9kdWxlLW9yLXN1Ym1vZHVsZS1uYW1lIiBpcyB0aGUgbmFtZSBvZiB0aGUgbW9k dWxlIG9yIA0KICAgc3VibW9kdWxlLCBhbmQgdGhlIG9wdGlvbmFsICJyZXZpc2lvbi1kYXRlIiBp cyB0aGUgbGF0ZXN0DQogICByZXZpc2lvbiBvZiB0aGUgbW9kdWxlIG9yIHN1Ym1vZHVsZSwgYXMg ZGVmaW5lZCBieSB0aGUNCiAgICJyZXZpc2lvbiIgc3RhdGVtZW50IChTZWN0aW9uIDcuMS45KS4N Cg0KV2hpbGUgdGhlIFNIT1VMRCBzdGF0ZW1lbnRzIHByb3ZpZGUgYSByZWNvbW1lbmRhdGlvbiwg dGhlDQpzcXVhcmUtYnJhY2tldHMgIltdIiBpbXBhcnQgbm8gYmlhcywgYW5kIHRoZSB0ZXh0IGlz IGFtYmlndW91cy4NClRoYXQgaXMsIGlzIHRoZSByZXZpc2lvbi1kYXRlIG9wdGlvbmFsICpvbmx5 KiBiZWNhdXNlIHRoZSANCnJldmlzaW9uIHN0YXRlbWVudCBpcyBvcHRpb25hbCB3aXRoaW4gdGhl IG1vZHVsZT8gIFdoYXQgaXMgDQp0aGUgcmVjb21tZW5kYXRpb24gZm9yIHdoZW4gdGhlIHJldmlz aW9uIHN0YXRlbWVudCBpcyBwcmVzZW50Pw0KVGhlIFJGQzc5NTAgdGV4dCBpc24ndCBjbGVhci4N Cg0KTXkgb3BpbmlvbiBpcyB0aGF0IFJGQzc5NTAgZXJyYXRhIHNob3VsZCBzdGF0ZSB0aGF0IHRo ZSBmaWxlIA0KbmFtZSBTSE9VTEQgaW5jbHVkZSB0aGUgcmV2aXNpb24tZGF0ZSB3aGVuIHRoZSBy ZXZpc2lvbiANCnN0YXRlbWVudCBhcHBlYXJzIHdpdGhpbiB0aGUgbW9kdWxlLg0KDQpLZW50IC8v IGNvbnRyaWJ1dG9yDQoNCg0KLS0tLS1PUklHSU5BTCBNRVNTQUdFLS0tLS0NCg0KRGVhciBhbGws DQoNCltQcmVwYXJpbmcgdGhlIElFVEYgaGFja2F0aG9uXQ0KDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzYwODdiaXMjc2VjdGlvbi00 LjINCldoYXQgaXMgdGhlIGd1aWRlbGluZSByZWdhcmRpbmc6DQogICAgIDxDT0RFIEJFR0lOUz4g ZmlsZSAiaWV0Zi1mb29AMjAxNi0wMy0yMC55YW5nIg0KICAgICB2ZXJzdXMNCiAgICAgPENPREUg QkVHSU5TPiBmaWxlICJpZXRmLWZvby55YW5nIg0KDQpSaWdodCBub3csIHdlIGhhdmUgYSBtaXgg b2YgYmVoYXZpb3JzLg0KVGhpcyBpbXBsaWVzIHRoYXQgdGhlIGV4dHJhY3RlZCBZQU5HIG1vZHVs ZXMgc29tZXRpbWVzIGNvbnRhaW5zIHRoZSANCnJldmlzaW9uLCBidXQgbm90IGFsd2F5cy4NCg0K UmVnYXJkcywgQmVub2l0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg0K From nobody Thu Mar 23 23:31:41 2017 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 C39EF1316D1 for ; Thu, 23 Mar 2017 23:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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 af2ilTOVOwkY for ; Thu, 23 Mar 2017 23:31:37 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538C11316D2 for ; Thu, 23 Mar 2017 23:31:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2914D1451; Fri, 24 Mar 2017 07:31:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ZVSdGMtjJ4g4; Fri, 24 Mar 2017 07:31:32 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 24 Mar 2017 07:31:34 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9442420035; Fri, 24 Mar 2017 07:31:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LlQ0f2iQOBkG; Fri, 24 Mar 2017 07:31:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BA8920031; Fri, 24 Mar 2017 07:31:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BBD873EF8621; Fri, 24 Mar 2017 07:31:38 +0100 (CET) Date: Fri, 24 Mar 2017 07:31:38 +0100 From: Juergen Schoenwaelder To: "Dale R. Worley" Cc: netmod@ietf.org Message-ID: <20170324063138.GA42195@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Dale R. Worley" , netmod@ietf.org References: <20170322.212411.1191940569571241434.mbj@tail-f.com> <87y3vvpkev.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y3vvpkev.fsf@hobgoblin.ariadne.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] uses and augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 06:31:40 -0000 On Thu, Mar 23, 2017 at 08:50:48PM -0400, Dale R. Worley wrote: > Martin Bjorklund writes: > >> I notice that "augment" is not allowed to target a "grouping", despite > >> that naively seems to be an operation that a module designer might like > >> to do. I expect that there is a reason why this is not allowed. > > > > There were lots of debate over this one when we first designed YANG. > > The main reason for not allowing this is that it can easily have > > unintended consequences. Module A uses a grouping G b/c it fits the > > purpose. Later someone augments G with some nodes; at this point it > > is not at all clear that the additional nodes are suitable for module > > A. > > True... But assuming that the grouping G has clean semantics, it > corresponds to some facility in the device, which in some way or another > appears in multiple places in the device's data model. And a module > that augments G adds semantics about that facility, and would only be > implemented by a device for which the facility uniformly has that > additional semantics. So it would be suitable for every place where the > grouping is used. But this is an assumption and it is not generally true. [...] > But what I'm considering is a modification of > the grouping which implicitly applies to all "uses" of that grouping -- > because you don't want to have duplicate declarations of the added nodes > in every place the grouping is used. There may be cases where this may appear useful but I see also cases where people will get largely suprised by the result if such wildcard augmentations would be possible. > > Augments are restricted to things that have a well defined name in the > > data tree because this makes it clear what is being augmented. One > > would have to create additional language constructs to make > > augmentations of groupings work. > > It's clear that *groupings* have well-defined names, because "uses" > statements can refer to them. I wrote 'name in the data tree' and I meant 'name in the schema tree' (sorry). Augments apply to something that has a name in the schema tree, groupings do not have that. The "grouping" statement is not a data definition statement and, as such, does not define any nodes in the schema tree. > RFC 7950 section 7.13 isn't particularly > clear about how the argument string of the statement is to be > interpreted, but going back over 7950, I'm getting the idea that the > names of groupings are not descendant-schema-nodeid's, that is, named > based on where the grouping statement sits in the syntactic hierarchy, > but are in a separate namespace which is flat regarding equality and > inequality comparisons, but has elaborate scoping rules regarding which > groupings are visible in which locations. Yes. > OK, that clarifies why you can't apply "augment" to a grouping -- > groupings (and thus the things defined within them) don't have names > that can be expressed by descendant-schema-nodeid's. Yes. This is how things were defined. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 24 01:09:54 2017 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 3E4D3129C46 for ; Fri, 24 Mar 2017 01:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 OQD5DT0mVeqG for ; Fri, 24 Mar 2017 01:09:52 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64DEB129C3F for ; Fri, 24 Mar 2017 01:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1892; q=dns/txt; s=iport; t=1490342992; x=1491552592; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=zMz0RYfWzEOFJNodP8bWPm7tb8TqsIhZv3++qJudxzI=; b=IAXWJ2OMVgjMUM7avRcN8d9B2jWRCvqZ1Fk4oV19PsE9JmRu51GW+8BZ C8BfBChptdpwwvZUOhbOC61csJ4TgFZ7UclE3jFLSmBawnFRHQ1kLhFV1 DOjLKBuZmXC47hkUTltMz1Fasn0G11IPka6Au7m1xgz5qheuIV6hliQWS k=; X-IronPort-AV: E=Sophos;i="5.36,214,1486425600"; d="scan'208";a="653489736" 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; 24 Mar 2017 08:09:50 +0000 Received: from [10.61.254.180] ([10.61.254.180]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2O89oaV026947; Fri, 24 Mar 2017 08:09:50 GMT To: Kent Watsen , NETMOD Working Group References: <02834066-3540-790e-bdda-abc5d90bfdac@cisco.com> <30B9FE1D-D8E8-4255-847B-DBAD1AA6E73D@juniper.net> Cc: "Joe Clarke (jclarke)" From: Benoit Claise Message-ID: Date: Fri, 24 Mar 2017 09:09:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <30B9FE1D-D8E8-4255-847B-DBAD1AA6E73D@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] file "ietf-foo@2016-03-20.yang" or file "ietf-foo.yang" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 08:09:54 -0000 On 3/24/2017 2:32 AM, Kent Watsen wrote: > Hi Benoit, > > Section 4.2 of rfc6187bis says: > > The "" tag SHOULD be followed by a string > identifying the file name specified in Section 5.2 of > [RFC7950]. > > While Section 5.2 of RFC7950 says: > > The name of the file SHOULD be of the form: > > module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' ) > > "module-or-submodule-name" is the name of the module or > submodule, and the optional "revision-date" is the latest > revision of the module or submodule, as defined by the > "revision" statement (Section 7.1.9). > > While the SHOULD statements provide a recommendation, the > square-brackets "[]" impart no bias, and the text is ambiguous. > That is, is the revision-date optional *only* because the > revision statement is optional within the module? What is > the recommendation for when the revision statement is present? > The RFC7950 text isn't clear. > > My opinion is that RFC7950 errata should state that the file > name SHOULD include the revision-date when the revision > statement appears within the module. That makes sense. Any other views? Regards, Benoit > > Kent // contributor > > > -----ORIGINAL MESSAGE----- > > Dear all, > > [Preparing the IETF hackathon] > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis#section-4.2 > What is the guideline regarding: > file "ietf-foo@2016-03-20.yang" > versus > file "ietf-foo.yang" > > Right now, we have a mix of behaviors. > This implies that the extracted YANG modules sometimes contains the > revision, but not always. > > Regards, Benoit > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Fri Mar 24 06:40:09 2017 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 48FC21296CF for ; Fri, 24 Mar 2017 06:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 5qbndqPogLbX for ; Fri, 24 Mar 2017 06:40:05 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387831296C8 for ; Fri, 24 Mar 2017 06:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2457; q=dns/txt; s=iport; t=1490362805; x=1491572405; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=B45CP8T1LMWx/9recwjUAp3sVSSswm8TZAKaDfC5ffw=; b=bdOGt1lpNifEENmLMWwF0NNd+PgwZ62/tmmHmaqqL6/JubOgwb4hMZ+7 9nE8u9EaWJrT2lyRmVd1zw3t07Pue+LoLoWpzuk/h5HaBsi+KN+w4Fgft aHTu+EihvNGYg7ftde5qEQ6tGSqES09wThIMe3lD+ZbiQktUMGWu3iYDg 4=; X-IronPort-AV: E=Sophos;i="5.36,215,1486425600"; d="scan'208";a="653497903" 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; 24 Mar 2017 13:40:03 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2ODe3Pd005170; Fri, 24 Mar 2017 13:40:03 GMT To: Benoit Claise , Kent Watsen , NETMOD Working Group References: <02834066-3540-790e-bdda-abc5d90bfdac@cisco.com> <30B9FE1D-D8E8-4255-847B-DBAD1AA6E73D@juniper.net> Cc: "Joe Clarke (jclarke)" From: Robert Wilton Message-ID: <146c5483-6e6d-a581-781b-bf5351b1df68@cisco.com> Date: Fri, 24 Mar 2017 13:40:00 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] file "ietf-foo@2016-03-20.yang" or file "ietf-foo.yang" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 13:40:07 -0000 On 24/03/2017 08:09, Benoit Claise wrote: > On 3/24/2017 2:32 AM, Kent Watsen wrote: >> Hi Benoit, >> >> Section 4.2 of rfc6187bis says: >> >> The "" tag SHOULD be followed by a string >> identifying the file name specified in Section 5.2 of >> [RFC7950]. >> >> While Section 5.2 of RFC7950 says: >> >> The name of the file SHOULD be of the form: >> >> module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' ) >> >> "module-or-submodule-name" is the name of the module or >> submodule, and the optional "revision-date" is the latest >> revision of the module or submodule, as defined by the >> "revision" statement (Section 7.1.9). >> >> While the SHOULD statements provide a recommendation, the >> square-brackets "[]" impart no bias, and the text is ambiguous. >> That is, is the revision-date optional *only* because the >> revision statement is optional within the module? What is >> the recommendation for when the revision statement is present? >> The RFC7950 text isn't clear. >> >> My opinion is that RFC7950 errata should state that the file >> name SHOULD include the revision-date when the revision >> statement appears within the module. > That makes sense. > Any other views? I don't feel strongly, but would it make more sense if instead rfc6187bis stated that the file name SHOULD include the revision date? I.e. 7950 states what the filename is allowed to look like and 6187bis states what they should look like for IETF produced models. Thanks, Rob > > Regards, Benoit >> >> Kent // contributor >> >> >> -----ORIGINAL MESSAGE----- >> >> Dear all, >> >> [Preparing the IETF hackathon] >> >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis#section-4.2 >> >> What is the guideline regarding: >> file "ietf-foo@2016-03-20.yang" >> versus >> file "ietf-foo.yang" >> >> Right now, we have a mix of behaviors. >> This implies that the extracted YANG modules sometimes contains the >> revision, but not always. >> >> Regards, Benoit >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Fri Mar 24 06:44:17 2017 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 4A76C1294C1 for ; Fri, 24 Mar 2017 06:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 YMXBOYkGqPgO for ; Fri, 24 Mar 2017 06:44:10 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFD61296EA for ; Fri, 24 Mar 2017 06:44:10 -0700 (PDT) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id E53441AE0310; Fri, 24 Mar 2017 14:44:08 +0100 (CET) Date: Fri, 24 Mar 2017 14:44:08 +0100 (CET) Message-Id: <20170324.144408.1191664098390131544.mbj@tail-f.com> To: rwilton@cisco.com Cc: bclaise@cisco.com, kwatsen@juniper.net, netmod@ietf.org, jclarke@cisco.com From: Martin Bjorklund In-Reply-To: <146c5483-6e6d-a581-781b-bf5351b1df68@cisco.com> References: <30B9FE1D-D8E8-4255-847B-DBAD1AA6E73D@juniper.net> <146c5483-6e6d-a581-781b-bf5351b1df68@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] file "ietf-foo@2016-03-20.yang" or file "ietf-foo.yang" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 13:44:15 -0000 Robert Wilton wrote: > > > On 24/03/2017 08:09, Benoit Claise wrote: > > On 3/24/2017 2:32 AM, Kent Watsen wrote: > >> Hi Benoit, > >> > >> Section 4.2 of rfc6187bis says: > >> > >> The "" tag SHOULD be followed by a string > >> identifying the file name specified in Section 5.2 of > >> [RFC7950]. > >> > >> While Section 5.2 of RFC7950 says: > >> > >> The name of the file SHOULD be of the form: > >> > >> module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' ) > >> > >> "module-or-submodule-name" is the name of the module or > >> submodule, and the optional "revision-date" is the latest > >> revision of the module or submodule, as defined by the > >> "revision" statement (Section 7.1.9). > >> > >> While the SHOULD statements provide a recommendation, the > >> square-brackets "[]" impart no bias, and the text is ambiguous. > >> That is, is the revision-date optional *only* because the > >> revision statement is optional within the module? What is > >> the recommendation for when the revision statement is present? > >> The RFC7950 text isn't clear. > >> > >> My opinion is that RFC7950 errata should state that the file > >> name SHOULD include the revision-date when the revision > >> statement appears within the module. > > That makes sense. > > Any other views? > > I don't feel strongly, but would it make more sense if instead > rfc6187bis stated that the file name SHOULD include the revision date? > I.e. 7950 states what the filename is allowed to look like and 6187bis > states what they should look like for IETF produced models. +1 /martin From nobody Fri Mar 24 10:07:20 2017 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 8E6CF12704B for ; Fri, 24 Mar 2017 10:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eEVVLV_szd3J for ; Fri, 24 Mar 2017 10:07:17 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 E933D12949A for ; Fri, 24 Mar 2017 10:07:15 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id u1so5802522wra.2 for ; Fri, 24 Mar 2017 10:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vdrw6Ml686648NkSrlLNn5VqNiciNcCXtcULiwBpXko=; b=0oeMfYjqAk6beCaZHnFYD8C5JO2bvr9oQ+ZNTqwM9wjmoAbNkFlQTEkqziSNmlNzfF SEIN8XtywDXoDNCYM5QyB8a3c+TJixzMNzKQQi8r6ml/+BQqg3GzSdi3l89QflGGr2qY vcdJMgVFWV/SqcbKRgdq6/5d7tZ3BwYyC8b9hqb+erwY/l99/yy4tOKdJMmwGSyEKuuG hDpksahau6kFUwWL767jV0PbfUvBARohk7AlwWSgkuHIANYBJahqC9qz+635m2TcPPn6 d+rWxrfer0zQ6mi1asinnQCAcVjZRzRy1K5w5lJ8PBZtvAYHtYB9sUC9d9cKCWIlZhjG tyIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vdrw6Ml686648NkSrlLNn5VqNiciNcCXtcULiwBpXko=; b=TyxPPuSQWbIR3FcXQYeuA/LyWjlTFz2A6n7e5BlmBTsQuW3R6s3qsTzbFeP0HXC0fq MXVx+rFzzuk+LYiDvIS9P6KPfrZneBqiItJook4iEP8c4Skfgi0DjjbhJgSD8qt8NQrZ MyNd7y4ZsfE/nOaRCp1RYP5Y2cAh19ByzIL9CakrP9iVW7SEIqq+21mbzc3pe5/kgqX1 n7SNkClVYFi4ocYPKJxSKCUWIIS8dIzS7Wgs8idMq+kjjJZtxzwNOnqVgrK0CWZSFDCD 7zdRoutoqnEkVCxq2Y+k1/w6aN5A86zSmgx1lKj6RYZw0+qPYwYvxFN90LoQbzl6e3cW 85EQ== X-Gm-Message-State: AFeK/H0HepN5dp75R5Y7p5jSQB249oqazNMAmO/iLqvFmnVKLu+jDcpGmgz3m5e5zoYUd0wKk5ITBgw/3kNALA== X-Received: by 10.223.177.151 with SMTP id q23mr8575612wra.65.1490375234234; Fri, 24 Mar 2017 10:07:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.166.37 with HTTP; Fri, 24 Mar 2017 10:07:13 -0700 (PDT) In-Reply-To: <20170324.144408.1191664098390131544.mbj@tail-f.com> References: <30B9FE1D-D8E8-4255-847B-DBAD1AA6E73D@juniper.net> <146c5483-6e6d-a581-781b-bf5351b1df68@cisco.com> <20170324.144408.1191664098390131544.mbj@tail-f.com> From: Andy Bierman Date: Fri, 24 Mar 2017 10:07:13 -0700 Message-ID: To: Martin Bjorklund Cc: Robert Wilton , Joe Marcus Clarke , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=f403045e7cd46b45cf054b7d06aa Archived-At: Subject: Re: [netmod] file "ietf-foo@2016-03-20.yang" or file "ietf-foo.yang" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 17:07:19 -0000 --f403045e7cd46b45cf054b7d06aa Content-Type: text/plain; charset=UTF-8 On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund wrote: > Robert Wilton wrote: > > > > > > On 24/03/2017 08:09, Benoit Claise wrote: > > > On 3/24/2017 2:32 AM, Kent Watsen wrote: > > >> Hi Benoit, > > >> > > >> Section 4.2 of rfc6187bis says: > > >> > > >> The "" tag SHOULD be followed by a string > > >> identifying the file name specified in Section 5.2 of > > >> [RFC7950]. > > >> > > >> While Section 5.2 of RFC7950 says: > > >> > > >> The name of the file SHOULD be of the form: > > >> > > >> module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' > ) > > >> > > >> "module-or-submodule-name" is the name of the module or > > >> submodule, and the optional "revision-date" is the latest > > >> revision of the module or submodule, as defined by the > > >> "revision" statement (Section 7.1.9). > > >> > > >> While the SHOULD statements provide a recommendation, the > > >> square-brackets "[]" impart no bias, and the text is ambiguous. > > >> That is, is the revision-date optional *only* because the > > >> revision statement is optional within the module? What is > > >> the recommendation for when the revision statement is present? > > >> The RFC7950 text isn't clear. > > >> > > >> My opinion is that RFC7950 errata should state that the file > > >> name SHOULD include the revision-date when the revision > > >> statement appears within the module. > > > That makes sense. > > > Any other views? > > > > I don't feel strongly, but would it make more sense if instead > > rfc6187bis stated that the file name SHOULD include the revision date? > > I.e. 7950 states what the filename is allowed to look like and 6187bis > > states what they should look like for IETF produced models. > > +1 > This is fine, but this there is a larger goal of library consistency that is impacted by this guideline. (such as the github/YangModels/yang repo. 1) changing the filename for each revision is not git-friendly (if one wants to track changes over releases) 2) many revisions are actually obsolete work-in-progress so keeping every old file around will grow into a problem 3) almost every import is import-without-revision so compiling the old obsolete modules quickly breaks as the new work-in-progress version makes incompatible changes. However, import-by-revision breaks if you only keep the latest revision around, so these problems have to be managed by the YANG librarians ;-) > > /martin > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --f403045e7cd46b45cf054b7d06aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Robert Wilton <rwilton@cisco.com> wrote:
>
>
> On 24/03/2017 08:09, Benoit Claise wrote:
> > On 3/24/2017 2:32 AM, Kent Watsen wrote:
> >> Hi Benoit,
> >>
> >> Section 4.2 of rfc6187bis says:
> >>
> >>=C2=A0 =C2=A0 =C2=A0The "<CODE BEGINS>" tag SH= OULD be followed by a string
> >>=C2=A0 =C2=A0 =C2=A0identifying the file name specified in Sec= tion 5.2 of
> >>=C2=A0 =C2=A0 =C2=A0[RFC7950].
> >>
> >> While Section 5.2 of RFC7950 says:
> >>
> >>=C2=A0 =C2=A0 =C2=A0The name of the file SHOULD be of the form= :
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0module-or-submodule-name ['@= 9; revision-date] ( '.yang' / '.yin' )
> >>
> >>=C2=A0 =C2=A0 =C2=A0"module-or-submodule-name" is th= e name of the module or
> >>=C2=A0 =C2=A0 =C2=A0submodule, and the optional "revision= -date" is the latest
> >>=C2=A0 =C2=A0 =C2=A0revision of the module or submodule, as de= fined by the
> >>=C2=A0 =C2=A0 =C2=A0"revision" statement (Section 7.= 1.9).
> >>
> >> While the SHOULD statements provide a recommendation, the
> >> square-brackets "[]" impart no bias, and the text i= s ambiguous.
> >> That is, is the revision-date optional *only* because the
> >> revision statement is optional within the module?=C2=A0 What = is
> >> the recommendation for when the revision statement is present= ?
> >> The RFC7950 text isn't clear.
> >>
> >> My opinion is that RFC7950 errata should state that the file<= br> > >> name SHOULD include the revision-date when the revision
> >> statement appears within the module.
> > That makes sense.
> > Any other views?
>
> I don't feel strongly, but would it make more sense if instead
> rfc6187bis stated that the file name SHOULD include the revision date?=
> I.e. 7950 states what the filename is allowed to look like and 6187bis=
> states what they should look like for IETF produced models.

+1

This is fine, but this there is a la= rger goal of library consistency that is
impacted by this guideli= ne. (such as the github/YangModels/yang repo.=C2=A0

1) changing the filename for each revision is not git-friendly
= (if one wants to track changes over releases)

2) m= any revisions are actually obsolete work-in-progress
so keeping e= very old file around will grow into a problem

3) a= lmost every import is import-without-revision so compiling the
ol= d obsolete modules quickly breaks as the new work-in-progress version
=
makes incompatible changes.

However, import-b= y-revision breaks if you only keep the latest revision around,
so= these problems have to be managed by the YANG librarians ;-)



/martin


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

--f403045e7cd46b45cf054b7d06aa-- From nobody Fri Mar 24 10:34:41 2017 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 59C631297DE for ; Fri, 24 Mar 2017 10:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 MlgPZxe-g_2L for ; Fri, 24 Mar 2017 10:34:37 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10093.outbound.protection.outlook.com [40.107.1.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B28126C23 for ; Fri, 24 Mar 2017 10:34:37 -0700 (PDT) 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; bh=slwN8vPw4FtapfqPhKba00NMHWISJhrIUJDWMVRLQjc=; b=eD8xtOfmlR5Pf3JgurOhCVm3eIZ/91NeG+nhNmXZBXyI/YNRESd9qHiaN8H2kS9/9srplD0zKN5/Yle6fPpotJJ5ZzpfDP7zbP15Pmvb3HQ/3QkZMuYzvY75kklR7JZOEATujarx/nBhJBJzqMq+gLLSThfHhOjK2uWpjnr1iw0= Authentication-Results: Brocade.com; dkim=none (message not signed) header.d=none;Brocade.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by HE1PR0701MB3001.eurprd07.prod.outlook.com (10.168.93.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Fri, 24 Mar 2017 17:34:34 +0000 Message-ID: <01a601d2a4c4$acd437a0$4001a8c0@gateway.2wire.net> From: t.petch To: William Ivory , Phil Shafer CC: References: <201703232024.v2NKO4i7024020@idle.juniper.net> Date: Fri, 24 Mar 2017 17:30:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: VI1PR09CA0058.eurprd09.prod.outlook.com (10.174.49.26) To HE1PR0701MB3001.eurprd07.prod.outlook.com (10.168.93.135) X-MS-Office365-Filtering-Correlation-Id: b4db7182-4035-4ab2-5992-08d472dc0a2b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB3001; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 3:pMMPmBrnh0L5JXjf7uFuvtgqj3DCZc8FibjW06vJ+ql1M1MfsiKgSg0bO7Ed7vxMrYQaXeAO1zH9oRTa3y9DP05KYtahgO7bPSRKmWb4NP+M+RjusRErH2WmUnRc6lSV9ETw68c8Juph22cUaXHuxVLnfmo1fWZIWZ42Z3OMalS0zcKCHLqGu1awaLWZ1Iig0q3XAuAqc+4glpchuNxPJi32My3cKCis1uM6SbiW6uWjHgO8WWhrgdRYhzghkpGbSLX+hRBKZKtzdZhF5eD/YQ==; 25:lB4aSiQJHioV/pOLTVqVaPnRitVTw1RMshRWO5ZphPcYcPCfoa3hizefVT79hvuoX/+7ZE5hQXARQ8+JfwB/AyLD8tWCvV8AuIAKEzuUE4nFHvFHLy47RiVaKbqV382hFuCv3VZBqHidAt62pXqdRyJJ6/YZkLUPcktFWiZeX8ZIA8hhiYgu1R/fbnEFHKEYbYpwQR6wwqjmWoF0yeHvFzzFxvuhu2j4Nr+7c0uR2ZnhMhtf4jzwvkA1Sgl8Ma7Oz+NwCRSUyFJ2x88m3Qsoal6WdDmhfdzmUXy45UP9D2Uh2xNhR8ZzzWLmARUt6VHKMFVnNVHrzTtg1iLY8nTdVvT1eXl6n21dzn5dk/a+nXRAuMTFVeuiCVioC5O03vWlbOvOW4SWvD0htZ0TOFTF1iv6R9AETvH+nC3rNI8TL8sbYl7BBHOAnNAEChN8yjo5LMMtopgaVwx1CUJp1sInWw== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 31:M5jmR5/zSO6GGitgR+hTBVGpa6vl0y57FNYBm5kHls51d/tQG0VCwm/8P1uCLwOtMZ1Guq0VcuT/kDQG73imHILMlFhQKVE/6X/jXGwbxH1Xt5wTU4plYVMy5aN9A2UD3r4si5cvDNH0OXjD63N9caz22RWakRW3AkNCAI1TcsLeiPi+w2YVkkP8cdRWwBcfmp9s/V5Nn2NjFLaI2smRBMQdyME5/FJKtu8nxRcE7fhCLGmV8QmYGw/+8an9ae2EkEhnHMLeJTacMpazmEHrEg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:HE1PR0701MB3001; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3001; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 4:vXYtDkuyYjtdFsfNm8by4Nv3KMqvnNenfi0/mwRbpSwKC11CbDHCpf1wN9D0CwCZQFTrn7arBCKDIGBHNiUr5o5GRHcnuGYI626eoZsdAmwU+HnHzftCSSQfOlswowAzdeS2iBP/e8Ke72kcGBrrZGC9bzJRWsdAvLf/abZKbV09orgGEvGLZq85acV56NPDbdMhasarcdRYqo8xgk1arX09ENJCnn2Lo9AfBm096yOkLFKnSBkCSh+wrOdUZB7d0SS92i8x2sv/d2aTbRD+LR2xnUoLYed8gREAQEazDXtSqwWWLRvfIzy5eaV9fH/w1eQ24Gu8zK3fA5OwuhyU1d9wHg499rlMPaE8rmSlvX7Jp6JJAtM30p5HE8whCVvYU6wEslN2D+UXSYnZ5i3i9H3S4yvaDS87R4mjZ6gduu1vGG8Msx1oJSLgsYHVAf2LUQf0RjtskKYu6Rlh+MTAEDveYkyTvV649RPOa6/KuqRgeVsXThevO4U6kt/4zMEk7+p2ujupWyE8mPzNXci/UE4Mbq+HPnKlKflMS1hcWhTP49gp4vQ2ofIh931Guk9WI6pANs7y7d8Ou5K8qHvA1QKy651VOHyXrDcChmnuXJAgBht2ThKwXcVhGsM1kxYQ2zuQEeW0FgpGD/67tvGgJA== X-Forefront-PRVS: 0256C18696 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39450400003)(39860400002)(39850400002)(39840400002)(39410400002)(13464003)(377454003)(81686999)(50986999)(9686003)(76176999)(6306002)(4720700003)(6666003)(230700001)(8666007)(42186005)(3846002)(33646002)(61296003)(84392002)(189998001)(86362001)(7736002)(2906002)(1456003)(5660300001)(44736005)(23756003)(6246003)(50226002)(6496005)(50466002)(6486002)(305945005)(53936002)(1556002)(38730400002)(81166006)(66066001)(62236002)(1941001)(47776003)(25786009)(8676002)(4326008)(44716002)(229853002)(6116002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3001; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3001; 23:szm7ZOM3J4YMe0J00+zXABp2xLYLvGVZCD5mx?= =?iso-8859-1?Q?zPc3injb6Q9R2J1vQ8cQHRSW+FE+O8PKdIyKEJGdHfjh5QrBPnj8dqsdlI?= =?iso-8859-1?Q?tnJvnLRhgviP/clmhS+DLUMYXb3CTU98VS/eS+KSj+41AC/mRnCYZGxJaB?= =?iso-8859-1?Q?Pvt2vJHiItSi52rSStn9ngN5sksMi8p23KDxfimsHivNlftLMO3NCdvWbI?= =?iso-8859-1?Q?JDcgqWxWdGdgM3+iwNp9/2Kg7LsdcucaHZoLK5tOLAicrkUXCP6cNiM5xP?= =?iso-8859-1?Q?BO6urxS38MxW3sgzdyDbg2ZRryTrP3kDS/+y4YKtE3vtFOjV6oDYkQrlwU?= =?iso-8859-1?Q?aPob4bqtuO70XZcBmyUpIaWsEe02wDV58d2yeCeNd8JcUB3iv7v8U0DWPO?= =?iso-8859-1?Q?UqdYHzJnsJhP7g8BN7Zj713H3+XBxYRzA0mSshF30Fus69kHoQEETaImp0?= =?iso-8859-1?Q?eSYt8UOGlW+7Og6Or6HG3Ppz7YBR3Ak53kvnHmd4IAvuhW2yb141p3A6di?= =?iso-8859-1?Q?xX+OUBTJ0q/H4UACyEk3TuY2Q5OcsvVmbaIvPeTdJCu9VGQHoa76mQRltV?= =?iso-8859-1?Q?qAlF+WmEqcOFldgfUBdF4WhocMyADrdyv5J15+vRl6bU5rWX8TWftaw7B7?= =?iso-8859-1?Q?GL3/iEOyTONgXyLcJ89F3IYhv4SzkOwEC9XT6/IgaOIzgy2/ywKE9oa4oh?= =?iso-8859-1?Q?AnCmg07Lyzpcp7EZSTcpHba8MQu6eNygUc/2F01MGvsNlQteWyj+wwB2WP?= =?iso-8859-1?Q?16FfQuQMYiMCTPlsJxXolAhGMVjWUVG4Bx5VVlhW6wZcX2v5tKYFtyXrZ3?= =?iso-8859-1?Q?E6kBQYhB+HUFkZzIBHo8hRF2Ho43mnu8GFAsieGEVvPsbDiQMfTx3p9TuF?= =?iso-8859-1?Q?rroWfE1iX7FvcIbMu77z7r7li+0WrExqFjW2r+zRwsPGF+JcG4K1AsO5O7?= =?iso-8859-1?Q?drr+1nCbrKC/lkqM7if5XuXYcTEMDp28DRsDphWdN3TI59OvLNEfDht3DF?= =?iso-8859-1?Q?kpPVszw7yBgPUmxuBzomEOufeUv96Ty8D4w8OdkJtcsQrH5vCcXWJYX972?= =?iso-8859-1?Q?OLQJWjVM0j2fGW4fDB0ZDid8dqJlXFV4nUkc1gfzjA/jj1Kzj+lm4RkbV1?= =?iso-8859-1?Q?DWXD4m2VcyAcS83cGxOPBRTBCg3uZmn4vHew6mPNkRXVlUSD2etrpYP61a?= =?iso-8859-1?Q?PK9690pjTr5r1mzv5L9ba7RTB6pA5YoHgP1fqwXCTy5OD1KJIJksaUhZho?= =?iso-8859-1?Q?4sCzdJSnB1fQlBNy+k2VlnSx+gyEhllHj8GDX2Bc6jNYd24e8d/TOpfweb?= =?iso-8859-1?Q?TdtXs1x0eVgkENEylPX7/7OvE?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 6:lo57y7Jn5PcKbxJc7dxkQGVIjaJUoVZ6UlYgv0lheVaGj8+r0rCP6iRu7pRM7eUAjr2mAyiYtFuyhkBT+5PojkTzlKoOOk31yyqzgSWljPTbYL0WIcVYS2/hqnHM7ynknLbS0234jHySV231xW1NkPxopiRDlF2ICYx9xdkoW46o9cyfzcmB6tvg8hH89fLhbQiRVtGH0ndAnhyKk0tmtTNmBdOxaJNGdJm+4L67ek7MvsaqnYYidNd/tK5vCzbeMwlEBMmgARlUZNMpE78RjDiR6FDK0LNMHxh4CXlzxdaq9CPzfssV6jIpci5q5yjLs/Jmn+JVaLPa2xUbNqXPppVIpPOXIQ6dvFqPR23sCnQZ/e7UZc00eUNWekOKOEot6wtuuMNieLQtqCAcL94ItA==; 5:0khfnh2NoerWcoZyE8x9eF4aqGijtPOqJ/w3/z60e77Jxc0xJvImumCcbIUchtGUn4sif+vC5xus6AGWzBRGpB+7RJRw9qF5G4zCYygEf249j08ldrntbiNVP5zCcJ99vKNWy2lwrKIiG5DB8XDGpg==; 24:UrUMEtTpBDtXMq3R/WH82uU9ZyoWDjZ9y+uvcO4xmCMaFE3VF04vVDuVSxL0Wpn3u37CJiwtfKtlCxTmOZFXePybIDGQecy+nWdtIYB/e10= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 7:0+7psxzgLarxTkcglH6IN0rKO9kWSwDblPzjXi0KZvfopWNLkfddUB8G3bBcw9fDe0V5kJgszqVhZg1HHhv7iz263+neF4B9Bpl8pPktMN9Rjz7uZTrRjb+hcpHYfai/LSBOWmhWqjGnKSHG7posfX0UYJ7RopayHiQAfNke8p/Gwd4OU/zjg91eiskd0MDgI/T86TthZGrMpEl97Pe6uJDQs4plbIOwUP69XJhAmfaKd2Pu5v0ZwiQ6c4e4By/IupWaSAbMsF/I+FfSRcajYI9gMXvNjYBn0Ju+YocsT6BcjMs42+hmF97Wyemc73Ur0y8QLABkZZDpQR2y/e5KGQ== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2017 17:34:34.9742 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3001 Archived-At: Subject: Re: [netmod] Interaction of 'when' and 'default' statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 17:34:39 -0000 ----- Original Message ----- From: "Phil Shafer" Sent: Thursday, March 23, 2017 8:24 PM > William Ivory writes: > >Yes, I'd noticed that. Does this make the behaviour 'undefined' in YANG 1.0? > > No, this was a clarification. The text in 6020 was reasonably clear: > > The "when" statement makes its parent data definition statement > conditional. The node defined by the parent data definition > statement is only valid when the condition specified by the "when" > statement is satisfied. > > And no default should be provided for any invalid node. If the node > can't exist, the default can't either. William Having tracked the discussions that led to RFC7950, the sense I got was that if you can avoid using 'when' then avoid using it. If you cannot avoid using 'when' avoid using it. Not something that is ever likely to appear in an I-D but the 'when' statement does have complex interactions that may not be intuitive and although RFC7950 does spell them out, yet they may not be apparent; which this thread also spells out to me:-) I would not say this of any other YANG statement. Tom Petch > Thanks, > Phil > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Mar 24 10:34:47 2017 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 5EEF8126C23 for ; Fri, 24 Mar 2017 10:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 mRyZ11tnTVOp for ; Fri, 24 Mar 2017 10:34:37 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10093.outbound.protection.outlook.com [40.107.1.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ACCA1201F2 for ; Fri, 24 Mar 2017 10:34:36 -0700 (PDT) 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; bh=V4k0dFSzD/vkfvbpurwJ0zsAwoi6wnmbKD87xRlcT10=; b=Z/Z4XaFnqgOa9tn9BnG2782VbKDSCLpTtEJr5TlwmPWZ8Y2VHl0FH/sBZ5n1WtqztZ8ioLhL4/rB8QqdndYDI0e8IV1NPwkJIOcXh1S7vcDr5WTACBr1H6A5HI2TktXpld0WkNv7m2Fsk1EbbvDSEFMJ9H8iNZ3mYldZCTs6UIY= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by HE1PR0701MB3001.eurprd07.prod.outlook.com (10.168.93.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Fri, 24 Mar 2017 17:34:33 +0000 Message-ID: <01a501d2a4c4$ac2c5ee0$4001a8c0@gateway.2wire.net> From: t.petch To: , Martin Bjorklund CC: References: <30B9FE1D-D8E8-4255-847B-DBAD1AA6E73D@juniper.net> <146c5483-6e6d-a581-781b-bf5351b1df68@cisco.com> <20170324.144408.1191664098390131544.mbj@tail-f.com> Date: Fri, 24 Mar 2017 17:22:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: VI1PR09CA0058.eurprd09.prod.outlook.com (10.174.49.26) To HE1PR0701MB3001.eurprd07.prod.outlook.com (10.168.93.135) X-MS-Office365-Filtering-Correlation-Id: ad2423bf-b74a-4e41-18d1-08d472dc0988 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB3001; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 3:UkQNUOkdzQVKrpsaaYR8Dk6QyGWVBmBkKFndo8l7JBZ93ZZpBkbT/zwyp/6K8ButjNhEPitWBLho13BgMrw/PhXqwy0uuXfRb0K9OKEMprmEHgOFYIJ93Im3qIOK5Qn9h+s+k7HYOxMPRr08v56wCk4bzLCoaRU1siS3o/5dCNK3RLEb66G2gRHcGHbGafOfvgXY0xT1a5MPcmiEM85YcvsVGJgScLyB0z0xpHroLP0FYpscPx5XdY4tfFIz/Qu69KhBGDEoT9iVaC7cG4pdaA==; 25:0kGZQSTnR1iDFJugSxUjyako59KK4LKr2LblSS1q0nxXZYtjGBKk9JXjcONweZOHGeCDDSjtIIks6ZFfK8S9S1Ndu3hE/XUXzMoamMDCm2qWb75QaWse0upOPfZwB67oBKnZSoYzrR+DYbBjV5OyrTgW8T1QNRLIpjMqIVIr1Z41hg11iPUqEmMDGWOwpf2nbaLV14YVV/PE+ubGarqFDeCxXe8Si2qLhkXXyAi26cSKwrsycIo5IBacB+3WqOLz7gzH93WP2KtDuJESc7J64oB4YwI0ZhV/ZPSctluRJ1QJq7nmhwrX92Vv0lVWJJyqYtrQVhanOq0/Mi8LTg2dFqcKxHISHJvsCFNhC7/cuYEjtZgLyFIDQapmvgiNJpihEf+oHxkZwBq+m46lF2lzk43rRkMIaVQJwHaWYbp14nz6pzV9S6/YtBXBD0ZWh7cUSOBdGInl+CzMc0iK2NepWA== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 31:ZsAdqBbj0a7XLuVB29Wh+eUUf5qGqa9u4SjY+2tyV/Zlbhcfv/mYkCJpiizPxMd7Vx4X+iB2oFDi3Q9qf0gM3RjeNjXvwgEi3xqvAEUHfViFGnlwz0xTBZY04PR5WV1L4ZRAnmc/RgUQ83y0tQGqt+Ff+k8DSRKSIWTBgbzK13F0amDRxETdcaA2toVkmjDPk24xLxXWqaMx4c2ZQOtI5TPM74ecnOpAag7xnLYDYaOVQdVNXtzkGnA3Rab64MBSO+pYHwcEKCGLQsPa2ViDaw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:HE1PR0701MB3001; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3001; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 4:SnnMmhKbObZihrhZ9gki2hKor15ebt4SOBywhgBxZgvYxGpuN3pCy0YK3FjqNJOAgQj92TEFu93e2oC/t37sx4j0114UuUeVbc9WzC/I+Ql1yTa11SEMRfAs5LBmaO7KyyXdGVMySzuq79z7rD0AmeKXi1Wj7PZk2TDFucy0Vqw47XGkPnPhnW0rhfCLiyqHmm6qT/YhjQkBhA8GvGWbLpJksrHZWHeP7L7ILdXrivBjVs+CqZsMZGqyrojNhAyX88z9j+9c+/ZDPKMlZ17H9aFGZURHdTH7m2KReB0SKW3JKaBLlSLqBpqnxxnL5oTwE2bs4/UK0+101o8rqFbgAtbVRO8afOCVeM/dEC5cbUVUZ9RCWAlwMs/j1FVw89N9N2vKLtdzgByqUkWCQd0b4jaKN6QQnfLOiw+nmxZMPnfiWDBmU5SJtEhs6bAvjQxO7oOV0uJQSNy0fQEqOlYGLmwQbMOe0wao+gMFcGgseaL1SScZFJSSlyupoAJB/BRK+I2oKemH1ldUnmgU4rDAZUwdsTGgo3Z2fcB6VQVqdImuid/oH+liXRj+X34zUWF/gLtzuxUWWD+7nBGN0a2nZBV4SKnwxb+pB3cmkP94hxKNAtFlXbKrGXgpZKKag2AG7DC79sPz0bYDSJAKl2jBGw== X-Forefront-PRVS: 0256C18696 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39450400003)(39860400002)(39850400002)(39840400002)(39410400002)(13464003)(377454003)(24454002)(5423002)(81686999)(50986999)(9686003)(76176999)(6306002)(4720700003)(230700001)(42186005)(230783001)(3846002)(33646002)(61296003)(84392002)(189998001)(86362001)(7736002)(2906002)(93886004)(1456003)(5660300001)(44736005)(23756003)(6246003)(50226002)(6496005)(50466002)(6486002)(305945005)(53936002)(1556002)(38730400002)(81166006)(66066001)(62236002)(47776003)(53546009)(25786009)(8676002)(4326008)(44716002)(229853002)(6116002)(74416001)(7726001)(222073002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3001; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3001; 23:gr9vPNc3sveqZXrKSiN/h/UBNIYbM0hTXEjNI?= =?iso-8859-1?Q?fhQY7Bu2/dIGZqOpn3bEOBfvZT6zAA8WqDObJi0NhkOP4Hc6kv49T1DbIr?= =?iso-8859-1?Q?xMvFy5EgJqXJG8KKOUW9w1vE525XvPDk3jOz+q6AFcO2+60AVxYs3BvYxR?= =?iso-8859-1?Q?t93lt+7Atm76sjJ1bbhfGBwcebqoUEK2pTxue7VC999WyF8qY/Sc/lozae?= =?iso-8859-1?Q?mvwCikmM8aeJ2MJkexj4nx/qYY0UP87UToCiZ1kd3bTroLI6l01pN/8IAU?= =?iso-8859-1?Q?euS/6zYnsk2906O/6NVp7elXJTbzB64Z6j2whIUcNgFJaEjpC+vgPIgoL/?= =?iso-8859-1?Q?EsxJE/AByhneTtoH3n/hKoU0WuZJsoG+k9O9d4WlhhxCaxnPeoecEB8lu/?= =?iso-8859-1?Q?2I1G/zfB3kyTXBhgbrCaXTkwuZ8lTIbqMXWDYXqvdl9HHzjlmwiRjLZFz9?= =?iso-8859-1?Q?cybFjzmNRR7hdIEfOc1eX/3JelYwpiSE7BuOEiZgku5VErKdGW9Aguv587?= =?iso-8859-1?Q?0PzcEgAr8KPxfHCFR5M797GEMxA/T5bICpZR4/tkN3FrMigk+1Xj7FEQcd?= =?iso-8859-1?Q?WY7FDkH0sZjieA7p4tWSu/rID7GSBvDTYbIoj34BusrNsaZEJ31N02k7Ei?= =?iso-8859-1?Q?vhhcpA6xClJejfxouctp3a/GIYpv9pyr6yQFt9OJfopcB9DpYbCYDxVbuO?= =?iso-8859-1?Q?Hb5gvwBK2lR3C8KO32HeiXXcZxn7j73XvBMRYH6sBlS1h+rb2T1diwTn6U?= =?iso-8859-1?Q?rdM0/cfyBo+pIt+Sm2Ps54L5T9D85F/gTcCftdBEL8DZkj2XA8Kn+0lWva?= =?iso-8859-1?Q?0ImWhtGvqZ8AChPkdbPobOhrgfEYNzvWc0mfiguVL53nZCMqNcoi735mm4?= =?iso-8859-1?Q?2qw3ZEguj4M/e67e3/cHb27+QI/Qyze9s1mY8U+hx8WcHnyO6SB1bT2fSr?= =?iso-8859-1?Q?OFWIgA90QZAB9bzgR0UIioQd3EWCIkHqn73aDE4oMhcZ1UukJm8p8l7yrc?= =?iso-8859-1?Q?+Yq4JdTWA3jl6kAk46ktin8IwxWD69Dhkp1OwxvW2EY19XlEpINHv3dCSc?= =?iso-8859-1?Q?T2BW+NsYrtjhTR0za9WydvqIOKQX8Bh+uL762RP67G4M+4CH3YAYl4F1sA?= =?iso-8859-1?Q?W/xsWkV4ZqQZekMnU8Uojo8mYhH5WPNzG5jbpbEfQ3MGyWq++yryoqj/w9?= =?iso-8859-1?Q?wjnWL+EhlH8qHiS43BmKSUtvMBf4rSjsjHGgO0uUdkjNYPFUgeZ6Gu8Eac?= =?iso-8859-1?Q?jlcM07NWXir2yFynPx/1aQw5cVuLLsqt6d1p+XrchPkhOb0nKvQ4AAfhOJ?= =?iso-8859-1?Q?GF24/RnbH5eerdWmMikwn1DCE2RWKeAuoHQEnH1nzaOeWDo0XHWCG5X6L4?= =?iso-8859-1?Q?oZVj6m7gQrpTnc9nyfsqriv8b+dO4fa9cOb6+ZGLLfHhAQArveoBg=3D?= =?iso-8859-1?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 6:orbPX2Hk5BUQ50Q5yMFqCf8r09BXLtv7ijZKaMoM4oOHscEeJ2ujnensM0CqT8pBTNedtRLI3EfRy+6MNAmUNQIUyVc2MZOg0hN5PLmzURHIHWJiyKbFHiMvgsH/qBhHkJKWNkPeDddhe/CTD0ayMM2N5k3rIZ4uYNEyoFfQHqNeJnZo27qXgeWsF7cOKDtJK4t6QWJClCn0lmSR5Nio1zbhf+MjWxw1k2fzXOhfX/KTDmmD74tONSS823XR4bibIY0AxuJw108IUd1bq+N5Lj2Gs6zO6LQ0P/dhjphlgJP1EXf7YPpPi3R16C7TKUGIaHPP5aaAdmzW7hVOiEFOzAvskTNDEZEyaeRM+cu0D3y7uj5Fzv9IKI1QiuWFlSWRR3e+wACkCs6M5+wFhe/wDg==; 5:RgwCoKyOQNbEtta6DN9TNAmRac/ev5rUeLLejkwsgNW6kazCrSkj+Eu5uBRBDRAOKgOan8RHAaccoejn7EaI2c/ftoL7Ugjc5Mq5CDQZzvxAq79+33ACjX+zuhKCZE9A3xN81ZVGi3aIZCaYy7vy9A==; 24:bA888jgw1ipN43bO7CXSXqvXOKnVTMWBLj5JvKOZfHGL0i7QlWghdQZD4OLZGKjtwdUBX+Fgq3BFcg2+MUAmt817ulwyXoYLoBOdfebLXxQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 7:olMBfDV6B915RTxp7ozA3BdFF3idYmXYLwQt1EQV1HR3XGT3iZFXw2MJ7ZrLIhc7uuzgaklpnPP3Fzc9taXAazEloYv0VT4paugIomP076sC4aR3wz+HXb6hppSxEIhq2KWP2218f0nGPRdgdPduC306eZxepti8j/HjKxx09OchtB+LWorwESv9vYiBOqf2wYVwaUyk7CI9rmF8sXiDl+wnIgVysDrPl8m2Qd4/lYUdU2vCF+UhIzzXB98VSBsufRbH5cxWqc3GWRXZoQqIjlYUOeFCeNYZfiEtaMwke4RiKLWKJhBxvwgubjxmb0C2QRB9XlgOEdBgmwUJI2R1MQ== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2017 17:34:33.9103 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3001 Archived-At: Subject: Re: [netmod] file "ietf-foo@2016-03-20.yang" or file "ietf-foo.yang" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 17:34:40 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; Sent: Friday, March 24, 2017 1:44 PM > Robert Wilton wrote: > > > > > > On 24/03/2017 08:09, Benoit Claise wrote: > > > On 3/24/2017 2:32 AM, Kent Watsen wrote: > > >> Hi Benoit, > > >> > > >> Section 4.2 of rfc6187bis says: > > >> > > >> The "" tag SHOULD be followed by a string > > >> identifying the file name specified in Section 5.2 of > > >> [RFC7950]. > > >> > > >> While Section 5.2 of RFC7950 says: > > >> > > >> The name of the file SHOULD be of the form: > > >> > > >> module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' ) > > >> > > >> "module-or-submodule-name" is the name of the module or > > >> submodule, and the optional "revision-date" is the latest > > >> revision of the module or submodule, as defined by the > > >> "revision" statement (Section 7.1.9). > > >> > > >> While the SHOULD statements provide a recommendation, the > > >> square-brackets "[]" impart no bias, and the text is ambiguous. > > >> That is, is the revision-date optional *only* because the > > >> revision statement is optional within the module? What is > > >> the recommendation for when the revision statement is present? > > >> The RFC7950 text isn't clear. > > >> > > >> My opinion is that RFC7950 errata should state that the file > > >> name SHOULD include the revision-date when the revision > > >> statement appears within the module. > > > That makes sense. > > > Any other views? > > > > I don't feel strongly, but would it make more sense if instead > > rfc6187bis stated that the file name SHOULD include the revision date? > > I.e. 7950 states what the filename is allowed to look like and 6187bis > > states what they should look like for IETF produced models. Yes, and I would also like RFC6087bis to require the date on the file statement, if present, to match that on the revision statement - I have seen several I-D where this has not been the case. Something a tool could check. Should the date be the most recent revision statement? I cannot see why not. Will there always be a revision statement? RFC7950 says SHOULD, cardinality 0..n so not always. Tom Petch > +1 > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Mar 24 11:36:01 2017 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 EB571127876 for ; Fri, 24 Mar 2017 11:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 e6tuLcUnbNip for ; Fri, 24 Mar 2017 11:35:57 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE51126C2F for ; Fri, 24 Mar 2017 11:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12492; q=dns/txt; s=iport; t=1490380557; x=1491590157; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=RPQBUtLt6pcTsvBSJZobKBr3N57BTbEgrrQbgdckvJg=; b=My3wT9V8klcS/3E4TfwT1ZbtpBXioM18nxQ50zBvpFe/A2vFkICCDEN+ Q/BcBsJZRkCethO7NAa+DJPQsQT4cvPoeFJaO5qkIaxPKec9K+ErUckz1 DoCObjQdUplHM2E2axtPC/2jjuWVlbjsK5PtjM4+ILyIl+SoepdHFxVlB M=; X-IronPort-AV: E=Sophos;i="5.36,216,1486425600"; d="scan'208,217";a="651682364" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2017 18:35:55 +0000 Received: from [10.61.230.242] ([10.61.230.242]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2OIZp97030655; Fri, 24 Mar 2017 18:35:52 GMT To: Andy Bierman , Martin Bjorklund References: <30B9FE1D-D8E8-4255-847B-DBAD1AA6E73D@juniper.net> <146c5483-6e6d-a581-781b-bf5351b1df68@cisco.com> <20170324.144408.1191664098390131544.mbj@tail-f.com> Cc: Joe Marcus Clarke , "netmod@ietf.org" From: Robert Wilton Message-ID: <0d6144bc-c0ff-4a47-c4bc-46aae6d7a856@cisco.com> Date: Fri, 24 Mar 2017 18:35:48 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------15D3237E366D172B17ABB40A" Archived-At: Subject: Re: [netmod] file "ietf-foo@2016-03-20.yang" or file "ietf-foo.yang" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 18:36:00 -0000 This is a multi-part message in MIME format. --------------15D3237E366D172B17ABB40A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 24/03/2017 17:07, Andy Bierman wrote: > > > On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund > wrote: > > Robert Wilton > wrote: > > > > > > On 24/03/2017 08:09, Benoit Claise wrote: > > > On 3/24/2017 2:32 AM, Kent Watsen wrote: > > >> Hi Benoit, > > >> > > >> Section 4.2 of rfc6187bis says: > > >> > > >> The "" tag SHOULD be followed by a string > > >> identifying the file name specified in Section 5.2 of > > >> [RFC7950]. > > >> > > >> While Section 5.2 of RFC7950 says: > > >> > > >> The name of the file SHOULD be of the form: > > >> > > >> module-or-submodule-name ['@' revision-date] ( '.yang' > / '.yin' ) > > >> > > >> "module-or-submodule-name" is the name of the module or > > >> submodule, and the optional "revision-date" is the latest > > >> revision of the module or submodule, as defined by the > > >> "revision" statement (Section 7.1.9). > > >> > > >> While the SHOULD statements provide a recommendation, the > > >> square-brackets "[]" impart no bias, and the text is ambiguous. > > >> That is, is the revision-date optional *only* because the > > >> revision statement is optional within the module? What is > > >> the recommendation for when the revision statement is present? > > >> The RFC7950 text isn't clear. > > >> > > >> My opinion is that RFC7950 errata should state that the file > > >> name SHOULD include the revision-date when the revision > > >> statement appears within the module. > > > That makes sense. > > > Any other views? > > > > I don't feel strongly, but would it make more sense if instead > > rfc6187bis stated that the file name SHOULD include the revision > date? > > I.e. 7950 states what the filename is allowed to look like and > 6187bis > > states what they should look like for IETF produced models. > > +1 > > > This is fine, but this there is a larger goal of library consistency > that is > impacted by this guideline. (such as the github/YangModels/yang repo. > > 1) changing the filename for each revision is not git-friendly > (if one wants to track changes over releases) Perhaps this is a difference between a development version (maybe being worked on in a separate directory in git) vs a published version, and by published I mean any draft revision. > > 2) many revisions are actually obsolete work-in-progress > so keeping every old file around will grow into a problem For the YANG models in RFCs, I guess that they are effectively published forever in github. But for drafts, I think that they can could be removed from github at the point that there is no other current draft that references them, which should be scriptable. > > 3) almost every import is import-without-revision so compiling the > old obsolete modules quickly breaks as the new work-in-progress version > makes incompatible changes. Yes. Perhaps YANG is missing an "import with revision X or greater" (given that revisions are expected to be backwards compatible)? > > However, import-by-revision breaks if you only keep the latest > revision around, > so these problems have to be managed by the YANG librarians ;-) I agree. > > > > > /martin > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --------------15D3237E366D172B17ABB40A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 24/03/2017 17:07, Andy Bierman wrote:


On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Robert Wilton <rwilton@cisco.com> wrote:
>
>
> On 24/03/2017 08:09, Benoit Claise wrote:
> > On 3/24/2017 2:32 AM, Kent Watsen wrote:
> >> Hi Benoit,
> >>
> >> Section 4.2 of rfc6187bis says:
> >>
> >>     The "<CODE BEGINS>" tag SHOULD be followed by a string
> >>     identifying the file name specified in Section 5.2 of
> >>     [RFC7950].
> >>
> >> While Section 5.2 of RFC7950 says:
> >>
> >>     The name of the file SHOULD be of the form:
> >>
> >>       module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )
> >>
> >>     "module-or-submodule-name" is the name of the module or
> >>     submodule, and the optional "revision-date" is the latest
> >>     revision of the module or submodule, as defined by the
> >>     "revision" statement (Section 7.1.9).
> >>
> >> While the SHOULD statements provide a recommendation, the
> >> square-brackets "[]" impart no bias, and the text is ambiguous.
> >> That is, is the revision-date optional *only* because the
> >> revision statement is optional within the module?  What is
> >> the recommendation for when the revision statement is present?
> >> The RFC7950 text isn't clear.
> >>
> >> My opinion is that RFC7950 errata should state that the file
> >> name SHOULD include the revision-date when the revision
> >> statement appears within the module.
> > That makes sense.
> > Any other views?
>
> I don't feel strongly, but would it make more sense if instead
> rfc6187bis stated that the file name SHOULD include the revision date?
> I.e. 7950 states what the filename is allowed to look like and 6187bis
> states what they should look like for IETF produced models.

+1

This is fine, but this there is a larger goal of library consistency that is
impacted by this guideline. (such as the github/YangModels/yang repo. 

1) changing the filename for each revision is not git-friendly
(if one wants to track changes over releases)
Perhaps this is a difference between a development version (maybe being worked on in a separate directory in git) vs a published version, and by published I mean any draft revision.


2) many revisions are actually obsolete work-in-progress
so keeping every old file around will grow into a problem
For the YANG models in RFCs, I guess that they are effectively published forever in github.
But for drafts, I think that they can could be removed from github at the point that there is no other current draft that references them, which should be scriptable.


3) almost every import is import-without-revision so compiling the
old obsolete modules quickly breaks as the new work-in-progress version
makes incompatible changes.
Yes.

Perhaps YANG is missing an "import with revision X or greater" (given that revisions are expected to be backwards compatible)?


However, import-by-revision breaks if you only keep the latest revision around,
so these problems have to be managed by the YANG librarians ;-)
I agree.





/martin


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


--------------15D3237E366D172B17ABB40A-- From nobody Sun Mar 26 02:32:23 2017 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 D9BE2129526 for ; Sun, 26 Mar 2017 02:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 gLZPY3h3b7Un for ; Sun, 26 Mar 2017 02:32:19 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0118.outbound.protection.outlook.com [104.47.2.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F5112951F for ; Sun, 26 Mar 2017 02:32:18 -0700 (PDT) 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; bh=sjcxZtv1Mt+TvBPyJJXV8ttF/zOi5WLfxgd/WUo8JrM=; b=CVHK1C4CLzunYz2VH413T402L8QMNqLKBmxaASe4q9u1izXr1iQ9lgOJzyxyYL5U6jAtEX9ksI2yUPm/QMEvIt65yBYveiQBKZoxE5uUxNSWh7UFEjNbYnGGukZOflqNHOKi7dXGoWI68f12mW2G23sX/J3rdWBRqztan1hebpE= Authentication-Results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by AM5PR0701MB2995.eurprd07.prod.outlook.com (10.168.156.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Sun, 26 Mar 2017 09:32:15 +0000 Message-ID: <016401d2a613$9da6a7e0$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , Martin Bjorklund CC: Joe Marcus Clarke , References: <30B9FE1D-D8E8-4255-847B-DBAD1AA6E73D@juniper.net> <146c5483-6e6d-a581-781b-bf5351b1df68@cisco.com> <20170324.144408.1191664098390131544.mbj@tail-f.com> Date: Sun, 26 Mar 2017 10:30:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: DB6P18901CA0011.EURP189.PROD.OUTLOOK.COM (10.169.208.149) To AM5PR0701MB2995.eurprd07.prod.outlook.com (10.168.156.145) X-MS-Office365-Filtering-Correlation-Id: fc1bb443-53ff-4340-00aa-08d4742afd77 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2995; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 3:bIoKYLUiMEXz7zngWwNNoqih4FqSZDnt/luCSzY9GY/3p1F8MxFzv5IlED+jBA7vgKSdaWo92Fxy/W7cxBvphBsJ4d+PcTAEtHjINQw1K8+JSCjfVZ62lmtqli/esZfThHeYtLmVF0vjyNljy7ku5sAG/zdmOd4G9lYDwgvLgcX0JQCzTD23AXcK05Hh+itENS4lf3VJvyWKx12Pkyx6sWZmJ4ERGSFo5q16qNK/YSn7AGWGPoQ8KRl3dF5I8yfYn+2lTTW0C2n7Xqvjk95YTg==; 25:G+igoItjxn1KtvBLoQJ3pLkWTLq1zXxysHtlbFNLoZmYeDPqZnp4jUExrydgHFadQMDnD4GcmYa4LR91P5T7M2LS6zSHUXDoF105zpaqG69j/t2DJKJtQR0CVwqnzqs/LwHN4yI7/psXCavOgbfy+saSDttC0pzLXbPniYUOnVE3HaZ2u2iKAJYoDgEOyikey7HXSnjqsLQ9UxDWgcOU0MdAn/s3sgpXDo9x+TUnD0RHjlkY4RwnQAiWDWS+iSlM6rMbAoRngwpQwRCs3dCZoNHinaeWsFKAviM8rpn/ikl/udA86irzyap4/2or2PfDInkmI0g+SdqoIqH7INy4FrgSJghHPT2axQdGy8RhaeD4fX0dSfvPMG3eox0QmLDk/dPKUJaePPaaw0eOJCd3/ShkjKXWoFIeKURsNsADDNZeVcibkT2XPopXFDQOUy49hxTzhcFcVMlmsXhoh45A8g== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 31:6Q35UCcWIMN6yZI5izRiRg8W5wMD+3fgdk1rWi7/544SPoKy0Zj1FLXtQPOGM+7jY9t5YNImxnAKclKwBIfy5SvZkhc+d/5Bm9nAW8Cw9bHoFXf3zTPhaGqKTKUg4Et6dj5B7fbCBkMFQzdtvsrvkshOn+xqhf5NW+tB5Skrye9dJD7cnnik+9moLp2OebHh6Vflr1gvzoy0faf2JuskrTvL1/FNdOByZZd/ocnokdmVNUX/l99sdJfIsbRf0k7A9WCaiOrXhvmd4HpDs5loDw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:AM5PR0701MB2995; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2995; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 4:mKnBteu+0one48NdPWnu3/q/5PsugSXS1asT5DyaBLALi4z2TRqidULFmjeh0oe9i2zOwvPsj3jfYLmb4/q6S3O30VDWPihaoJkywe4eI3IFTZqsQJQy40JkwqhoZOaMXaAx0gL050PyEpm+TJn+fexF20VsY/HkZV88Ki7Nagd1BrUH/uqgwaRZ/nPMsAdEsl7GJW2sJdi5ikKxyLS5NbdHMq5WMVd+amPEGXkkLbE+ii6w0bwjoPJFFEd4caW2C0GVO9sUO+eWxKIRo2JuTJ7lpHNhrC30oYK+HSlDYso9qoF3r2yPSzxI2hgn640iU/CsfFE4ETDkfpWFywDxrtHEJR53l+2sak3xTiDE1/ybwjQ/s8aaYk6D2p6KdK8Wva0hUE5wbApFcyCSW01P0XXZYu4t8tnJPwTngCFP+QhjGrKJCXbYFCppuKXqPNdR2fylDiSFFZCJKUNsl1k54eXCqRPayl7q5Qhr2zbAjs74llbXYK4T4g0UvUZuDtcS5TLSYruWutJ0sB9VZwEUMYOnHC4RsR2n0h98FDtwoZlc7BuMNWZucLNxBOVQDJzZ4tU5b7JyPXNqLa8GiBtkvH5/MBPAabmO9t5tIgOrrqwHLnww9fsKMioCFUr9jetl8UIT4ILxtrdytuxUL3QqiQ== X-Forefront-PRVS: 0258E7CCD4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39850400002)(39860400002)(39840400002)(39410400002)(39450400003)(13464003)(377454003)(5423002)(24454002)(53546009)(5660300001)(25786009)(6306002)(33646002)(9686003)(54906002)(50466002)(44736005)(4326008)(229853002)(97736004)(14496001)(6486002)(4720700003)(6666003)(23676002)(7736002)(305945005)(62236002)(86362001)(189998001)(44716002)(230783001)(116806002)(84392002)(1556002)(8676002)(50226002)(81166006)(47776003)(2906002)(3846002)(53936002)(6116002)(81686999)(81816999)(93886004)(50986999)(76176999)(38730400002)(230700001)(6496005)(6246003)(1456003)(66066001)(61296003)(42186005)(74416001)(7726001)(222073002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2995; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTU7MjM6QXJwSHdnNjdXVi9hMi81c0dpekRTbjJL?= =?utf-8?B?RXo4MlFZdUw5TnJTNkxGS2tqZXlBUXgvZWpqcWswYlV4VDhnZ241bjA4NHdB?= =?utf-8?B?UVBOTC9iRVV3NmRocTJkRUozc3BqK2N0cEp4d29BSndNNzZiTkxLU29VRGZt?= =?utf-8?B?dkowdXJkQ2dsVDNyT0c1cWxTL2pnMWwyVFJxRWFjSHpNSzNhWE1iSk1iTWE1?= =?utf-8?B?MFM3S3dRN1VIUEExakZHdVdqNU1SQ3ZNbzYwT3g1SFpGcmZ1ZVZ5Vk91SDZB?= =?utf-8?B?empsL215Wk1zYzAyNFY3OXlzcm1XeVRYaGpqVm41eDJDQmpIWUNYYTVVRGt3?= =?utf-8?B?bjh6TTY3OXdxVkJVRzVQTHVxOE9WeGhEVUxGcXpqZHFVVHRua1AwWVMvaGdY?= =?utf-8?B?Mjc3STAwM3U1U1J4ZjJUekgwWENTdDRtak8wenljYXk1cWIxeWEvTUtMVUV2?= =?utf-8?B?Y1VUTlZUaXFKMjhBd3lmQmZEZDBHVk9DaElBc1RqV0xMNmo0dVJmNGxGc1VP?= =?utf-8?B?K0dSc3JIazZSK1RUZlorL2NOVG1FZm00VVp4dHcySFQzenlSYmdkV3MwL05C?= =?utf-8?B?dGthakJIU2lPOW5WdEV1SkloclhJT05qQTVBbmV4NDhuT0I5dm53ajFGdDFt?= =?utf-8?B?VXN4cVdHWGtHWWFncEtsSmFhNWs0M1Z5dlFMaW9UZnM4UEIvSDVjSWhpRTB0?= =?utf-8?B?cHhNM2F3NFprTEdoVkhXL3BJOTRnaFdBYmRTWnZEYU1NKzBua2tIeWtLRUo5?= =?utf-8?B?aUpsN1hVSnlhaEJLODBIdlR6OVV1K0Q4bktqQ3EwcThkaGVueWYvUXh4YWx1?= =?utf-8?B?MCttbkxzT0xkS2c5VXpseG52dUJiblRla3FjV3E4SW03ZE5pK2Q5TCtLV0Y5?= =?utf-8?B?UmRQajlwTDJvbUF6dHNycWV3ZmwvdW9TSFFmMHV1TDdZdnArQk1DN0FhSGc1?= =?utf-8?B?d3ZLS2tDdW1vQ0R0b0hvQlVycHVIeEVRY05aMS9XR0pxaktBZ1JEMmQ1alNO?= =?utf-8?B?VEFWSW45MUFvRWIyYkQrcitncG0yVWZiR0RZcmFyaENMVU03WWV4bSs1S2o4?= =?utf-8?B?SmRqc1h3ODJCZWRZTTBCMFhjaHpSSmFsbDBKT1lnQ1NNY2l6ekhCWHF2YVda?= =?utf-8?B?V0t5cHk3VFptb3IxRENVZTBtN3VTZ3Q4UWFhalZSa2trNmE1Q3VJRWIyempC?= =?utf-8?B?YUFiakJ5RWdGbWhYL3crVXR6czNhNDNEMHg1RjVOMXA1R3huREtEUkxZNEFt?= =?utf-8?B?VnVoQTZyNkpvRnlyZDBzR3VrRkd2TXoxNU9QemdMRG1IUFMrTXdWU2k5RkNi?= =?utf-8?B?OEN5R0VSUjNUVVNUZ0VycWd0cEVTQTB5bngxQ1NrVmpNLzhwc2VZU2psQU95?= =?utf-8?B?LzNXbmk5VjdTcEV4eFM4amVsc2lUQzkvVzJXeWNDSDFEZnY1Z3BFNEFuSUl4?= =?utf-8?B?ZDMzbE55bkxCQ09rV0RQMmpONWh1UEtVc0ovM2Yra1RIVUdUbFdXTFEyU0FB?= =?utf-8?B?bHhBTG83TDFNRk9TMzFyeWNncTl0bTRtOEpyTXM0cHQxWXRKY0hzSk9Ud0J3?= =?utf-8?B?UU9oUE9Kdjk5WTYvTGhIYXFlcHVrYnQ5eVZxc1RsYmIxaFdFZ3lmVERrNW9H?= =?utf-8?B?L2ZLNmRJeElFUndVN0hIVkpjYncvWGRDbU55S2hXL0hBWVB4a2wxeVd5UjBS?= =?utf-8?B?eEN4MW5UUE5Sb3NoanE5dWsyZDRWdUd0Y21NNGtIVklITmdaYjZ6QXlyNHpV?= =?utf-8?B?WDhGT05Ra0tSRjhqTDVlaHM4QmxWT3laZmZ0cy9NWEpreUhHUy9ZamlkbXJE?= =?utf-8?B?WFkrZ2c2NUpDOGhTMjdRK2U1ZEhtbTBlVngxcUE3UXlDNElGYytxd2t0Mk1o?= =?utf-8?B?V05CaWpUeFlQbU9zUGhXZE9LWU1CTzRHOHplSFZ3MS9CWTY4VTlieUljbTZ1?= =?utf-8?B?SDlaZEFCeXFTdFJOVkV6c2dVRXJpMHlxWnRXUmo3N2pxME00WEZBc3lXanhW?= =?utf-8?Q?elhCB30N?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 6:IqFRcqsIhOBUs1UgB3nwsnA6a+ha0B25LX11KGX3lgJrXD9hg4BlfwpZj48c1yBkLEHLrMSg1/7noJKGW8AKuKtvBrDRGPpZST8l20QWSSrtp6ym8bauAG+9OE8fRxPbdgCSFgc3DgqJT+gyVW8OeqCQNG6nerYUnL19VgF6gl4MxFVydoM5utcQN8bzW9St6WWvDO20X9C+zuNh1wKFvWB2uQC2grouQEQ4OPpFhC8KUGWvzyBH7SSahlPFuboWclaLkEfoLvi3teLTgRByvGAPO5c1x7+YNbg18B9AQzKqVYCQ4VZMFalj3ABEALwcKEdyPXkYTFu96YjW8aZV0qI8T1PsS0JCmvExQWvkbbjGlWiFg5hXfU/iJrclhQ72HHzlRlmxjZ3PUh+OByjr9g==; 5:xP15h5OgLTboDrRXQCJswKc2rMOapOYtd4PTEokrDU+/8auywYXcG2lrfQ8wiIVoK9tEhE1NUrpkNRH5hhoI0qYIfZndkLxIb7wykEp1O9qOMrpoeN86P+BPE8A6mOOIuDN/mo5uWYoqEUhY2DdR2A==; 24:/WMVy/LXnjJtjhPts4zskE72V6DIGUv7vcYh/I+ywnzFJcVJgdXua4Jz0S0WHZOVyVMT+QGQkS8MTaMQVDA5B2e+DBdjXs9if6CygbGWVLg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 7:hIltBURz3MUFXuXwWmkeyQTfIIV/2NfYl6OYYQOOh4OSHkYMBUijjE30DHDms2UYHnE7vSahuYofuvl/bIsIZ6q2R+bONa5lj6nsgvSRlNnkaC4C65Bd8e6E9mTOKwt5yTzP11xl9hM4B7HOgVBUGQsBJJXW+eY3eNx4hBBu8/Cd9rSTPYfSe1rnyB/8fNbEN4u38w1JdZ/E0uSUURJ9Wtto8r4xJmR4bf7qqJ0R+Z1xOMKkazUjed8+12X1eEFfWamvHGHHi5p7vo31CeEg1PI6JBl44XVjFix5wJ4zkuNNA2uVd+yNsnXqgT4YjopHyOGMWXQm05dV1U6Tpj6olA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2017 09:32:15.1441 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2995 Archived-At: Subject: Re: [netmod] file "ietf-foo@2016-03-20.yang" or file "ietf-foo.yang" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 09:32:22 -0000 ----- Original Message ----- From: "Andy Bierman" Sent: Friday, March 24, 2017 6:07 PM > On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund wrote: > > > Robert Wilton wrote: > > > > > > > > > On 24/03/2017 08:09, Benoit Claise wrote: > > > > On 3/24/2017 2:32 AM, Kent Watsen wrote: > > > >> Hi Benoit, > > > >> > > > >> Section 4.2 of rfc6187bis says: > > > >> > > > >> The "" tag SHOULD be followed by a string > > > >> identifying the file name specified in Section 5.2 of > > > >> [RFC7950]. > > > >> > > > >> While Section 5.2 of RFC7950 says: > > > >> > > > >> The name of the file SHOULD be of the form: > > > >> > > > >> module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' > > ) > > > >> > > > >> "module-or-submodule-name" is the name of the module or > > > >> submodule, and the optional "revision-date" is the latest > > > >> revision of the module or submodule, as defined by the > > > >> "revision" statement (Section 7.1.9). > > > >> > > > >> While the SHOULD statements provide a recommendation, the > > > >> square-brackets "[]" impart no bias, and the text is ambiguous. > > > >> That is, is the revision-date optional *only* because the > > > >> revision statement is optional within the module? What is > > > >> the recommendation for when the revision statement is present? > > > >> The RFC7950 text isn't clear. > > > >> > > > >> My opinion is that RFC7950 errata should state that the file > > > >> name SHOULD include the revision-date when the revision > > > >> statement appears within the module. > > > > That makes sense. > > > > Any other views? > > > > > > I don't feel strongly, but would it make more sense if instead > > > rfc6187bis stated that the file name SHOULD include the revision date? > > > I.e. 7950 states what the filename is allowed to look like and 6187bis > > > states what they should look like for IETF produced models. > > > > +1 > > > > This is fine, but this there is a larger goal of library consistency that is > impacted by this guideline. (such as the github/YangModels/yang repo. > > 1) changing the filename for each revision is not git-friendly > (if one wants to track changes over releases) > > 2) many revisions are actually obsolete work-in-progress > so keeping every old file around will grow into a problem > > 3) almost every import is import-without-revision so compiling the > old obsolete modules quickly breaks as the new work-in-progress version > makes incompatible changes. > > However, import-by-revision breaks if you only keep the latest revision > around, > so these problems have to be managed by the YANG librarians ;-) So a single revision level is too crude (for at least some of these issues) and we need a major/minor release identifier, the minor being updated with each version of a draft, the major being constant from the time of the first draft-ngt-xxxbis to its publication as an RFC. Tom Petch > > > > > > /martin > > > > > Andy > > > > _______________________________________________ > > 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 Sun Mar 26 10:17:38 2017 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 23E68129650 for ; Sun, 26 Mar 2017 10:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 zWVtxwSHGTDi for ; Sun, 26 Mar 2017 10:17:31 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0138.outbound.protection.outlook.com [104.47.32.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB421270A7 for ; Sun, 26 Mar 2017 10:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S7RYdnF/Uo/3HLeNsQRtV8RgLqB/0kzHBtwogP7I+3k=; b=dBhmRbyOmEAyUoX3meSkuNzDzu8UchRvU+1kXUeCM4SQkrisHLjlPIVjz8s3qCMA8qUcJu4s0SdSNkEXNDBKwSU51Mgjj4kPZPsh/EvMiEkjIRnn9Xiz9zqeZSmczDMqGk7UnXF9aDOt1lmgd+lLlRKqoD5crfaXpiSwY4ew5hM= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Sun, 26 Mar 2017 17:17:29 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1005.007; Sun, 26 Mar 2017 17:17:29 +0000 From: Kent Watsen To: David Bannister CC: Dean Bogdanovic , NetMod WG Thread-Topic: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt Thread-Index: AQHSnSlHwAqIi04elk+0OsiclimezKGaqssAgAyBg4A= Date: Sun, 26 Mar 2017 17:17:29 +0000 Message-ID: <86AA35DF-0D22-45E7-A954-E766133ED49D@juniper.net> References: <148939875845.17039.4017763838166134753.idtracker@ietfa.amsl.com> <4D50BFD4-0E59-4DF8-BEC9-0D9BE50F5BA6@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: netflix.com; dkim=none (message not signed) header.d=none;netflix.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:a87nE7mhmaUMuPnjCK8iXiAuiK0FpaTHPrVyZ6R44LRx3Ombr7Py/KEKu54E2QX7Bs2QLXJaitNtdCHU73fCt3EeDdH0QWknAFxE+12bYsFDY6W++b9KtuNekZd7vyMsQJMjwE5kRCMSZCRS36Fs2TbiG+PpT0lffhQRQ2JodzgmpsPx9wnZekA94IIN+Ia5gvWQ+wJTGqaiLA8G3fE66MnbhK4OnXDUZhO6omKNyeb2zyyZNhjygjBUmz9QsN+GQa7t15aVCVxB23rrjT6rlBNGCHbDU/BHTL/W3xqnRs07NCJL9zobH8ripZFSBaHLUJhQVhbU2TWXarfyL9z9ew== x-ms-office365-filtering-correlation-id: 2ce1de03-8e84-405d-796b-08d4746bfb76 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(95692535739014)(177428888720325)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39840400002)(39450400003)(39850400002)(39860400002)(377454003)(76104003)(78124002)(53824002)(377424004)(24454002)(229853002)(6916009)(2950100002)(81166006)(33656002)(8676002)(8936002)(76176999)(5660300001)(7906003)(36756003)(7736002)(54906002)(606005)(6306002)(6436002)(6512007)(54896002)(50986999)(99286003)(110136004)(236005)(54356999)(25786009)(53936002)(53546009)(39060400002)(6246003)(4326008)(86362001)(6506006)(38730400002)(53386004)(2906002)(6486002)(77096006)(10710500007)(7110500001)(189998001)(3280700002)(4001350100001)(3660700001)(93886004)(230783001)(122556002)(66066001)(3846002)(102836003)(6116002)(15650500001)(2900100001)(14971765001)(2420400007)(83716003)(82746002)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_86AA35DF0D2245E7A954E766133ED49Djunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2017 17:17:29.3688 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 17:17:37 -0000 --_000_86AA35DF0D2245E7A954E766133ED49Djunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SEkgRGF2aWQsDQoNCkkgYmVsaWV2ZSBhbiBhbmFsb2d5IHRvIHRoZSBpZXRmLXJvdXRpbmcgbW9k dWxlIGNhbiBhbmQgc2hvdWxkIGJlIG1hZGUgaGVyZS4gIEluIGJvdGggY2FzZXMsIHRoZSBtb2R1 bGUgcHJvdmlkZXMgYSBtaW5pbWFsIHNrZWxldG9uIHRoYXQgaXMgaW50ZW5kZWQgdG8gYmUgZXh0 ZW5kZWQgYnkgYXVnbWVudGF0aW9ucy4gICBJZiBhbnl0aGluZywgSSBjb3VsZCBhcmd1ZSB0aGF0 IHRoZSBhY2wgbW9kdWxlIGRvZXNuJ3QgZ28gZmFyIGVub3VnaCwgaW4gdGhhdCB0aGVyZSBpcyBu byBmZWF0dXJlIHN0YXRlbWVudCBvbiB0aGUgImFjZS1pcCIgYW5kICJhY2UtZXRoIiBjYXNlIHN0 YXRlbWVudHMsIGFzIGlmIGl0J3MgYXNzdW1pbmcgdGhhdCBhbGwgc2VydmVycyBpbXBsZW1lbnQg TDMgYW5kIEwyIEFDTHMsIHdoaWNoIEkgZmluZCBzdXNwaWNpb3VzLi4uDQoNCllvdSB3cml0ZSBi ZWxvdyAiYXVnbWVudGVkIGJ5IGVhY2ggdmVuZG9yIiwgYnV0IEkgZG9uJ3QgYmVsaWV2ZSB0aGF0 IHRoaXMgaXMgdGhlIGludGVudCwgc28gbXVjaCBhcyAoanVzdCBsaWtlIHdpdGggdGhlIGlldGYt cm91dGluZykgdGhhdCBmdXR1cmUgSUVURiBtb2R1bGVzIHdpbGwgYmUgZGVmaW5lZCB0byBmbGVz aCBpdCBvdXQuICBJbiBwYXJ0aWN1bGFyLCB0aGUgZXhpc3RpbmcgImFjZS1pcCIgYW5kICJhY2Ut ZXRoIiBjYXNlIHN0YXRlbWVudHMgY2FuIGJlIGF1Z21lbnRlZCwgYXMgd2VsbCBhcyBicmFuZCBu ZXcgY2FzZSBzdGF0ZW1lbnRzIGFkZGVkLiAgIEkgYWdyZWUgdGhhdCwgaW4gaXRzIGN1cnJlbnQg Zm9ybSwgdGhpcyBkcmFmdCBpcyBvZiBsaW1pdGVkIHVzZSwgYnV0IGtlZXAgaW4gbXkgdGhhdCB0 aGUgaWV0Zi1yb3V0aW5nIG1vZHVsZSBub3cgaGFzIDQyIG90aGVyIG1vZHVsZXMgYXVnbWVudGlu ZyBpdCwgc28gdGhlcmUncyBob3BlIHRoYXQgdGhlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdCBt b2R1bGUgd2lsbCBzaW1pbGFybHkgYmUgZmxlc2hlZCBvdXQgaW4gc2hvcnQgb3JkZXIuDQoNCldo YXQgZG8geW91IHRoaW5rPyAgRG8geW91IHRoaW5rIHdlIHNob3VsZCBwdXQgZmVhdHVyZSBzdGF0 ZW1lbnRzIG9uIHRoZSB0d28gY2FzZSBzdGF0ZW1lbnRzLCBvciBldmVuIG1vdmUgdGhlc2UgaW50 byBvdGhlciBtb2R1bGVzIChpbiB0aGUgc2FtZSBkcmFmdCkgc28gdGhhdCB0aGVyZSBpcyBubyBz cGVjaWFsbmVzcyBpbXBhcnRlZCBvbiB0aGVtPw0KDQpXaGF0IGFib3V0IG90aGVycz8gIEknbSBj b25jZXJuZWQgdGhhdCB3ZSBtYXkgbm90IGhhdmUgc3VmZmljaWVudCBkb21haW4gZXhwZXJ0aXNl IGluIHRoZSBORVRNT0QgV0cgLSBzaW1pbGFyIHRvIHRoZSByb3V0aW5nLWNmZyBkcmFmdCwgdW50 aWwgdGhlIHJ0Z3dnIHN0YXJ0ZWQgdG8gZm9jdXMgb24gaXQuDQoNCktlbnQgIC8vIHNoZXBoZXJk DQoNCg0KT24gMy8xOC8xNywgOToxOCBBTSwgIkRhdmlkIEJhbm5pc3RlciIgPGRwYkBuZXRmbGl4 LmNvbTxtYWlsdG86ZHBiQG5ldGZsaXguY29tPj4gd3JvdGU6DQoNCihzZWNvbmQgdHJ5KQ0KVGhl cmUgd2VyZSBubyBjaGFuZ2VzIHRvIHRoZSBtb2RlbCBzbyBteSBjb25jZXJucyByZW1haW4gdGhl IHNhbWUuICBBdWdtZW50YXRpb24gaXMgbm90IGEgc2NhbGFibGUgc29sdXRpb24gd2hlbiBkZWFs aW5nIHdpdGggYSBtdXRsaS12ZW5kb3Igb3IgaW4gc29tZSBpbnN0YW5jZXMgYSBtdWx0aS1idXNp bmVzcy11bml0IGVudmlyb25tZW50LiAgVGhlICduZXdjbycgZXhhbXBsZSBpbiB0aGUgZHJhZnQg aWxsdXN0cmF0ZXMgdGhpcyBwcm9ibGVtLiAgVGhlIElFVEYgcHJvZHVjZXMgYSAnc3RhbmRhcmQn IGZvciBhbiBBQ0wgZHJhZnQgd2hpY2ggaXMgc28gc3BhcnNlIGluIG5hdHVyZSB0aGF0IGl0IG11 c3QgYmUgYXVnbWVudGVkIGJ5IGVhY2ggdmVuZG9yLiAgSW4gdGhlIGJlc3QgY2FzZSB0aGlzIGdp dmVzIG1lIGEgdW5pcXVlIG1vZGVsIHBlciB2ZW5kb3IgYmVjYXVzZSB3ZSBrbm93IHRoZSB2ZW5k b3JzIGFyZSBub3QgZ29pbmcgdG8gZ2V0IHRvZ2V0aGVyIHRvIGRlZmluZSB0aGUgbWlzc2luZyBw aWVjZXMuICBUaGUgdmVuZG9ycyB3aWxsIHVzZSBhIHZhcmlldHkgb2YgbWVjaGFuaXNtcyB0byBj b21wbGV0ZSB0aGUgbW9kZWwgZnJvbSB1c2luZyBhIHNjcmlwdCB0byBidWlsZCB0aGVpciBtb2Rl bHMgZnJvbSBzb3VyY2UgY29kZSwgaGFuZGxpbmcgdGhlIG1pc3NpbmcgcGllY2VzIGFzIGFyYml0 cmFyeSBjb2RlIChhbnl4bWwpLCBvciBldmVyeXRoaW5nIGFzIGEgc3RyaW5nLiAgVGhlbiB0aGVy ZSBpcyB0aGUgd29yc2UgY2FzZSB3aGVyZSBhIHZlbmRvciBoYXMgbm8gaW50ZXJuYWwgc3RhbmRh cmRpemF0aW9uICh5b3Uga25vdyB3aG8geW91IGFyZSkgYW5kIHRoZWlyIG93biBwcm9kdWN0IGxp bmVzIHdpbGwgbm90IGFsaWduIGludG8gYSBjb21tb24gbW9kZWwuICBUaGUgb2JqZWN0IGhlcmUs IGZvciBtZSwgaXMgdG8gZ2V0IHRvIGEgc2luZ2xlIG1vZGVsIGZvciBhbGwgdmVuZG9ycyBiYXJy aW5nIGEgdW5pcXVlIGZlYXR1cmUgdGhhdCBiZWxvbmdzIHRvIG9uZSB2ZW5kb3IgaW4gd2hpY2gg Y2FzZSBhdWdtZW50YXRpb24gaXMgYWNjZXB0YWJsZS4NCg0KQ291bGQgeW91IGFkZCB0byB0aGlz IGluIHRoZSBmdXR1cmUgYW5kIHJldiB1cCB0aGUgUkZDPyAgU3VyZS4gIEhvd2V2ZXIsIEkgYW0g bm90IHN1cmUgd2hhdCB2YWx1ZSB0aGF0IGJyaW5ncyB0byB0aGUgY29tbXVuaXR5LiAgSW4gaXRz IGN1cnJlbnQgZm9ybSBJIHdvdWxkIG5vdCBhc2sgYW55IG9mIG15IHZlbmRvcnMgdG8gaW1wbGVt ZW50IHRoaXMgZHJhZnQuICBJbnN0ZWFkIEkgd291bGQgcHVzaCB0aGVtIHRvd2FyZHMgdGhlIE9w ZW5Db25maWcgQUNMIG1vZGVsLg0KDQpPbiBUdWUsIE1hciAxNCwgMjAxNyBhdCA5OjEyIFBNLCBL ZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5l dD4+IHdyb3RlOg0KSGkgRGF2aWQsDQoNCkNhbiB5b3UgcGxlYXNlIGNvbmZpcm0gdGhhdCB0aGUg YWRkaXRpb25hbCBleGFtcGxlcyBhZGRyZXNzIHlvdXIgY29uY2Vybj8gIEFuZCwgaWYgbm90LCBw bGVhc2UNCmV4cGxhaW4gaWYgdGhlcmUgaXMgYW55IHJlYXNvbiB3aHkgd2hhdCB5b3UncmUgbG9v a2luZyBmb3IgY291bGRuJ3QgYmUgYWRkZWQgb3IgYXVnbWVudGVkIGluDQppbiB0aGUgZnV0dXJl Lg0KDQpUaGFua3MsDQpLZW50IC8vIHNoZXBoZXJkDQoNCk9uIDMvMTMvMTcsIDU6NTcgQU0sICJu ZXRtb2Qgb24gYmVoYWxmIG9mIERlYW4gQm9nZGFub3ZpYyIgPG5ldG1vZC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGl2YW5kZWFu QGdtYWlsLmNvbTxtYWlsdG86aXZhbmRlYW5AZ21haWwuY29tPj4gd3JvdGU6DQoNCkhlcmUgaXMg dGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBBQ0wgZHJhZnQuIFNpbmNlIERlY2VtYmVyIGFuZCBzb21l IGFkZGl0aW9uYWwgY29tbWVudHMgYWJvdXQgdGhlIEFDTCBtb2RlbCwgSSBzcG9rZSB3aXRoIG1h bnkgb3BlcmF0b3JzIGFuZCBob3cgdGhleSB1c2UgQUNMcy4gSSBoYXZlIGFsc28gcmVjZWl2ZWQg bG90IG9mIGRldGFpbGVkIEFDTCBjb25maWd1cmF0aW9ucy4gSW4gbW9zdCBjYXNlcywgdGhlIG1v ZGVsIGlzIGVhc2lseSBhZGFwdGVkIHRvIHRoZSBjdXJyZW50IHVzZSBjYXNlcyBpbiBvcGVyYXRp b25zLiBCdXQgdG8gYW5zd2VyIHRoZSBjb21tZW50cywgdGhlIGF1dGhvcnMgaGF2ZSBhZGRlZCBh IGRldGFpbGVkIGV4YW1wbGUgaW4gdGhlIGFkZGVuZHVtIHNlY3Rpb24gaG93IHRoZSBtb2RlbCBj YW4gYmUgZXh0ZW5kZWQgYW5kIGhvdyB0aGlzIG1vZGVsIGNhbiBiZSB1c2VkLg0KDQpDaGVlcnMs DQoNCkRlYW4NCg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2Rl bC0xMC50eHQNCkRhdGU6IE1hcmNoIDEzLCAyMDE3IGF0IDEwOjUyOjM4IEFNIEdNVCsxDQpUbzog PG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc+Piwg IktpcmFuIEtvdXNoaWsiIDxra291c2hpa0BjaXNjby5jb208bWFpbHRvOmtrb3VzaGlrQGNpc2Nv LmNvbT4+LCAiTGlzYSBIdWFuZyIgPGx5aWh1YW5nMTZAZ21haWwuY29tPG1haWx0bzpseWlodWFu ZzE2QGdtYWlsLmNvbT4+LCAiRGVhbiBCb2dkYW5vdmljIiA8aXZhbmRlYW5AZ21haWwuY29tPG1h aWx0bzppdmFuZGVhbkBnbWFpbC5jb20+PiwgIkRhbmEgQmxhaXIiIDxkYmxhaXJAY2lzY28uY29t PG1haWx0bzpkYmxhaXJAY2lzY28uY29tPj4sICJLaXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNhIiA8 a2tvdXNoaWtAY2lzY28uY29tPG1haWx0bzpra291c2hpa0BjaXNjby5jb20+Pg0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTAudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERlYW4gQm9nZGFub3ZpYyBhbmQgcG9zdGVk IHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wt bW9kZWwNClJldmlzaW9uOiAxMA0KVGl0bGU6IE5ldHdvcmsgQWNjZXNzIENvbnRyb2wgTGlzdCAo QUNMKSBZQU5HIERhdGEgTW9kZWwNCkRvY3VtZW50IGRhdGU6IDIwMTctMDMtMTMNCkdyb3VwOiBu ZXRtb2QNClBhZ2VzOiAzMg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTAudHh0DQpTdGF0dXM6 ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRt b2QtYWNsLW1vZGVsLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTANCkRpZmY6ICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEw DQoNCkFic3RyYWN0Og0KICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGRhdGEgbW9kZWwgb2Yg QWNjZXNzIENvbnRyb2wgTGlzdCAoQUNMKQ0KICBiYXNpYyBidWlsZGluZyBibG9ja3MuDQoNCiAg RWRpdG9yaWFsIE5vdGUgKFRvIGJlIHJlbW92ZWQgYnkgUkZDIEVkaXRvcikNCg0KICBUaGlzIGRy YWZ0IGNvbnRhaW5zIG1hbnkgcGxhY2Vob2xkZXIgdmFsdWVzIHRoYXQgbmVlZCB0byBiZSByZXBs YWNlZA0KICB3aXRoIGZpbmFsaXplZCB2YWx1ZXMgYXQgdGhlIHRpbWUgb2YgcHVibGljYXRpb24u ICBUaGlzIG5vdGUNCiAgc3VtbWFyaXplcyBhbGwgb2YgdGhlIHN1YnN0aXR1dGlvbnMgdGhhdCBh cmUgbmVlZGVkLiAgUGxlYXNlIG5vdGUNCiAgdGhhdCBubyBvdGhlciBSRkMgRWRpdG9yIGluc3Ry dWN0aW9ucyBhcmUgc3BlY2lmaWVkIGFueXdoZXJlIGVsc2UgaW4NCiAgdGhpcyBkb2N1bWVudC4N Cg0KICBBcnR3b3JrIGluIHRoaXMgZG9jdW1lbnQgY29udGFpbnMgc2hvcnRoYW5kIHJlZmVyZW5j ZXMgdG8gZHJhZnRzIGluDQogIHByb2dyZXNzLiAgUGxlYXNlIGFwcGx5IHRoZSBmb2xsb3dpbmcg cmVwbGFjZW1lbnRzDQoNCiAgbyAgIlhYWFgiIC0tPiB0aGUgYXNzaWduZWQgUkZDIHZhbHVlIGZv ciB0aGlzIGRyYWZ0Lg0KDQogIG8gIFJldmlzaW9uIGRhdGUgaW4gbW9kZWwgKE9jdCAxMiwgMjAx NikgbmVlZHMgdG8gZ2V0IHVwZGF0ZWQgd2l0aA0KICAgICB0aGUgZGF0ZSB0aGUgZHJhZnQgZ2V0 cyBhcHByb3ZlZC4gIFRoZSBkYXRlIGFsc28gbmVlZHMgdG8gZ2V0DQogICAgIHJlZmxlY3RlZCBv biB0aGUgbGluZSB3aXRoIDxDT0RFIEJFR0lOUz4uDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0 YXJpYXQNCg0KDQo= --_000_86AA35DF0D2245E7A954E766133ED49Djunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIgMCA1IDMgMCAwIDAgMiAwIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLm0tNTkyMzE1NTE2MDIzNjk5MzY1NmFwcGxlLXRh Yi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOm1fLTU5MjMxNTUxNjAyMzY5OTM2NTZhcHBsZS10YWIt c3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFu dDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNv cmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lu cw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkhJ IERhdmlkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+ SSBiZWxpZXZlIGFuIGFuYWxvZ3kgdG8gdGhlIGlldGYtcm91dGluZyBtb2R1bGUgY2FuIGFuZCBz aG91bGQgYmUgbWFkZSBoZXJlLiZuYnNwOyBJbiBib3RoIGNhc2VzLCB0aGUgbW9kdWxlIHByb3Zp ZGVzIGEgbWluaW1hbCBza2VsZXRvbiB0aGF0IGlzIGludGVuZGVkIHRvIGJlIGV4dGVuZGVkIGJ5 IGF1Z21lbnRhdGlvbnMuJm5ic3A7ICZuYnNwO0lmIGFueXRoaW5nLCBJIGNvdWxkDQogYXJndWUg dGhhdCB0aGUgYWNsIG1vZHVsZSBkb2Vzbid0IGdvIGZhciBlbm91Z2gsIGluIHRoYXQgdGhlcmUg aXMgbm8gZmVhdHVyZSBzdGF0ZW1lbnQgb24gdGhlICZxdW90O2FjZS1pcCZxdW90OyBhbmQgJnF1 b3Q7YWNlLWV0aCZxdW90OyBjYXNlIHN0YXRlbWVudHMsIGFzIGlmIGl0J3MgYXNzdW1pbmcgdGhh dCBhbGwgc2VydmVycyBpbXBsZW1lbnQgTDMgYW5kIEwyIEFDTHMsIHdoaWNoIEkgZmluZCBzdXNw aWNpb3VzLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp Ij5Zb3Ugd3JpdGUgYmVsb3cgJnF1b3Q7YXVnbWVudGVkIGJ5IGVhY2ggdmVuZG9yJnF1b3Q7LCBi dXQgSSBkb24ndCBiZWxpZXZlIHRoYXQgdGhpcyBpcyB0aGUgaW50ZW50LCBzbyBtdWNoIGFzIChq dXN0IGxpa2Ugd2l0aCB0aGUgaWV0Zi1yb3V0aW5nKSB0aGF0IGZ1dHVyZSBJRVRGIG1vZHVsZXMg d2lsbCBiZSBkZWZpbmVkIHRvIGZsZXNoIGl0IG91dC4gJm5ic3A7SW4gcGFydGljdWxhciwNCiB0 aGUgZXhpc3RpbmcgJnF1b3Q7YWNlLWlwJnF1b3Q7IGFuZCAmcXVvdDthY2UtZXRoJnF1b3Q7IGNh c2Ugc3RhdGVtZW50cyBjYW4gYmUgYXVnbWVudGVkLCBhcyB3ZWxsIGFzIGJyYW5kIG5ldyBjYXNl IHN0YXRlbWVudHMgYWRkZWQuJm5ic3A7Jm5ic3A7IEkgYWdyZWUgdGhhdCwgaW4gaXRzIGN1cnJl bnQgZm9ybSwgdGhpcyBkcmFmdCBpcyBvZiBsaW1pdGVkIHVzZSwgYnV0IGtlZXAgaW4gbXkgdGhh dCB0aGUgaWV0Zi1yb3V0aW5nIG1vZHVsZSBub3cgaGFzIDQyIG90aGVyIG1vZHVsZXMgYXVnbWVu dGluZw0KIGl0LCBzbyB0aGVyZSdzIGhvcGUgdGhhdCB0aGUgaWV0Zi1hY2Nlc3MtY29udHJvbC1s aXN0IG1vZHVsZSB3aWxsIHNpbWlsYXJseSBiZSBmbGVzaGVkIG91dCBpbiBzaG9ydCBvcmRlci48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPldoYXQgZG8g eW91IHRoaW5rPyZuYnNwOyBEbyB5b3UgdGhpbmsgd2Ugc2hvdWxkIHB1dCBmZWF0dXJlIHN0YXRl bWVudHMgb24gdGhlIHR3byBjYXNlIHN0YXRlbWVudHMsIG9yIGV2ZW4gbW92ZSB0aGVzZSBpbnRv IG90aGVyIG1vZHVsZXMgKGluIHRoZSBzYW1lIGRyYWZ0KSBzbyB0aGF0IHRoZXJlIGlzIG5vIHNw ZWNpYWxuZXNzIGltcGFydGVkIG9uIHRoZW0/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpIj5XaGF0IGFib3V0IG90aGVycz8mbmJzcDsgSSdtIGNvbmNlcm5l ZCB0aGF0IHdlIG1heSBub3QgaGF2ZSBzdWZmaWNpZW50IGRvbWFpbiBleHBlcnRpc2UgaW4gdGhl IE5FVE1PRCBXRyAtIHNpbWlsYXIgdG8gdGhlIHJvdXRpbmctY2ZnIGRyYWZ0LCB1bnRpbCB0aGUg cnRnd2cgc3RhcnRlZCB0byBmb2N1cyBvbiBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmkiPktlbnQmbmJzcDsgLy8gc2hlcGhlcmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMy8xOC8xNywg OToxOCBBTSwgJnF1b3Q7RGF2aWQgQmFubmlzdGVyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 ZHBiQG5ldGZsaXguY29tIj5kcGJAbmV0ZmxpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+KHNlY29uZCB0cnkpPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuNXB0Ij5UaGVyZSB3ZXJlIG5vIGNoYW5nZXMgdG8gdGhlIG1vZGVsIHNvIG15IGNv bmNlcm5zIHJlbWFpbiB0aGUgc2FtZS4mbmJzcDsgQXVnbWVudGF0aW9uIGlzIG5vdCBhIHNjYWxh YmxlIHNvbHV0aW9uIHdoZW4gZGVhbGluZyB3aXRoIGEgbXV0bGktdmVuZG9yIG9yIGluIHNvbWUg aW5zdGFuY2VzIGEgbXVsdGktYnVzaW5lc3MtdW5pdCBlbnZpcm9ubWVudC4mbmJzcDsgVGhlICdu ZXdjbycNCiBleGFtcGxlIGluIHRoZSBkcmFmdCBpbGx1c3RyYXRlcyB0aGlzIHByb2JsZW0uJm5i c3A7IFRoZSBJRVRGIHByb2R1Y2VzIGEgJ3N0YW5kYXJkJyBmb3IgYW4gQUNMIGRyYWZ0IHdoaWNo IGlzIHNvIHNwYXJzZSBpbiBuYXR1cmUgdGhhdCBpdCBtdXN0IGJlIGF1Z21lbnRlZCBieSBlYWNo IHZlbmRvci4mbmJzcDsgSW4gdGhlIGJlc3QgY2FzZSB0aGlzIGdpdmVzIG1lIGEgdW5pcXVlIG1v ZGVsIHBlciB2ZW5kb3IgYmVjYXVzZSB3ZSBrbm93IHRoZSB2ZW5kb3JzIGFyZQ0KIG5vdCBnb2lu ZyB0byBnZXQgdG9nZXRoZXIgdG8gZGVmaW5lIHRoZSBtaXNzaW5nIHBpZWNlcy4mbmJzcDsgVGhl IHZlbmRvcnMgd2lsbCB1c2UgYSB2YXJpZXR5IG9mIG1lY2hhbmlzbXMgdG8gY29tcGxldGUgdGhl IG1vZGVsIGZyb20gdXNpbmcgYSBzY3JpcHQgdG8gYnVpbGQgdGhlaXIgbW9kZWxzIGZyb20gc291 cmNlIGNvZGUsIGhhbmRsaW5nIHRoZSBtaXNzaW5nIHBpZWNlcyBhcyBhcmJpdHJhcnkgY29kZSAo YW55eG1sKSwgb3IgZXZlcnl0aGluZyBhcw0KIGEgc3RyaW5nLiZuYnNwOyBUaGVuIHRoZXJlIGlz IHRoZSB3b3JzZSBjYXNlIHdoZXJlIGEgdmVuZG9yIGhhcyBubyBpbnRlcm5hbCBzdGFuZGFyZGl6 YXRpb24gKHlvdSBrbm93IHdobyB5b3UgYXJlKSBhbmQgdGhlaXIgb3duIHByb2R1Y3QgbGluZXMg d2lsbCBub3QgYWxpZ24gaW50byBhIGNvbW1vbiBtb2RlbC4mbmJzcDsgVGhlIG9iamVjdCBoZXJl LCBmb3IgbWUsIGlzIHRvIGdldCB0byBhIHNpbmdsZSBtb2RlbCBmb3IgYWxsIHZlbmRvcnMgYmFy cmluZyBhIHVuaXF1ZQ0KIGZlYXR1cmUgdGhhdCBiZWxvbmdzIHRvIG9uZSB2ZW5kb3IgaW4gd2hp Y2ggY2FzZSBhdWdtZW50YXRpb24gaXMgYWNjZXB0YWJsZS4gJm5ic3A7PC9zcGFuPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Q291bGQg eW91IGFkZCB0byB0aGlzIGluIHRoZSBmdXR1cmUgYW5kIHJldiB1cCB0aGUgUkZDPyZuYnNwOyBT dXJlLiZuYnNwOyBIb3dldmVyLCBJIGFtIG5vdCBzdXJlIHdoYXQgdmFsdWUgdGhhdCBicmluZ3Mg dG8gdGhlIGNvbW11bml0eS4mbmJzcDsgSW4gaXRzIGN1cnJlbnQgZm9ybSBJIHdvdWxkIG5vdCBh c2sgYW55IG9mIG15IHZlbmRvcnMgdG8gaW1wbGVtZW50IHRoaXMgZHJhZnQuJm5ic3A7DQogSW5z dGVhZCBJIHdvdWxkIHB1c2ggdGhlbSB0b3dhcmRzIHRoZSBPcGVuQ29uZmlnIEFDTCBtb2RlbC4g Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBUdWUsIE1hciAxNCwgMjAxNyBhdCA5OjEyIFBNLCBLZW50IFdhdHNlbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5r d2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpIj5IaSBEYXZpZCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5DYW4geW91IHBsZWFzZSBjb25maXJtIHRoYXQgdGhl IGFkZGl0aW9uYWwgZXhhbXBsZXMgYWRkcmVzcyB5b3VyIGNvbmNlcm4/Jm5ic3A7IEFuZCwgaWYg bm90LCBwbGVhc2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5leHBsYWluIGlmIHRoZXJlIGlzIGFu eSByZWFzb24gd2h5IHdoYXQgeW91J3JlIGxvb2tpbmcgZm9yIGNvdWxkbid0IGJlIGFkZGVkIG9y IGF1Z21lbnRlZCBpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPmluIHRoZSBmdXR1cmUuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmkiPktlbnQgLy8gc2hlcGhlcmQ8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAzLzEzLzE3LCA1OjU3IEFNLCAmcXVvdDtu ZXRtb2Qgb24gYmVoYWxmIG9mIERlYW4gQm9nZGFub3ZpYyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOml2YW5kZWFuQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml2YW5kZWFuQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkhlcmUgaXMgdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBBQ0wgZHJhZnQuIFNpbmNlIERlY2Vt YmVyIGFuZCBzb21lIGFkZGl0aW9uYWwgY29tbWVudHMgYWJvdXQgdGhlIEFDTCBtb2RlbCwgSSBz cG9rZSB3aXRoIG1hbnkgb3BlcmF0b3JzIGFuZCBob3cgdGhleSB1c2UgQUNMcy4gSSBoYXZlIGFs c28gcmVjZWl2ZWQNCiBsb3Qgb2YgZGV0YWlsZWQgQUNMIGNvbmZpZ3VyYXRpb25zLiBJbiBtb3N0 IGNhc2VzLCB0aGUgbW9kZWwgaXMgZWFzaWx5IGFkYXB0ZWQgdG8gdGhlIGN1cnJlbnQgdXNlIGNh c2VzIGluIG9wZXJhdGlvbnMuIEJ1dCB0byBhbnN3ZXIgdGhlIGNvbW1lbnRzLCB0aGUgYXV0aG9y cyBoYXZlIGFkZGVkIGEgZGV0YWlsZWQgZXhhbXBsZSBpbiB0aGUgYWRkZW5kdW0gc2VjdGlvbiBo b3cgdGhlIG1vZGVsIGNhbiBiZSBleHRlbmRlZCBhbmQgaG93IHRoaXMNCiBtb2RlbCBjYW4gYmUg dXNlZC4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+RGVhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5C ZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1 ZSZxdW90OyI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5T dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtbmV0bW9kLWFj bC1tb2RlbC0xMC50eHQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhIE5ldWUmcXVvdDsiPkRhdGU6DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+TWFyY2ggMTMsIDIwMTcgYXQgMTA6 NTI6MzggQU0gR01UJiM0MzsxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhIE5ldWUmcXVvdDsiPlRvOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPiZsdDs8YSBocmVmPSJtYWlsdG86bmV0 bW9kLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZC1jaGFpcnNAaWV0Zi5v cmc8L2E+Jmd0OywgJnF1b3Q7S2lyYW4gS291c2hpayZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv Omtrb3VzaGlrQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtrb3VzaGlrQGNpc2NvLmNvbTwv YT4mZ3Q7LCAmcXVvdDtMaXNhIEh1YW5nJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bHlpaHVh bmcxNkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5seWlodWFuZzE2QGdtYWlsLmNvbTwvYT4m Z3Q7LA0KICZxdW90O0RlYW4gQm9nZGFub3ZpYyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOml2 YW5kZWFuQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml2YW5kZWFuQGdtYWlsLmNvbTwvYT4m Z3Q7LCAmcXVvdDtEYW5hIEJsYWlyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGJsYWlyQGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRibGFpckBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7 S2lyYW4gQWdyYWhhcmEgU3JlZW5pdmFzYSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtrb3Vz aGlrQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtrb3VzaGlrQGNpc2NvLmNvbTwvYT4mZ3Q7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTAudHh0 PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEZWFuIEJvZ2Rhbm92aWMg YW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTo8 c3BhbiBjbGFzcz0ibS01OTIzMTU1MTYwMjM2OTkzNjU2YXBwbGUtdGFiLXNwYW4iPiA8L3NwYW4+ ZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsPGJyPg0KUmV2aXNpb246PHNwYW4gY2xhc3M9Im0t NTkyMzE1NTE2MDIzNjk5MzY1NmFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPjEwPGJyPg0KVGl0bGU6 PHNwYW4gY2xhc3M9Im0tNTkyMzE1NTE2MDIzNjk5MzY1NmFwcGxlLXRhYi1zcGFuIj4gPC9zcGFu Pk5ldHdvcmsgQWNjZXNzIENvbnRyb2wgTGlzdCAoQUNMKSBZQU5HIERhdGEgTW9kZWw8YnI+DQpE b2N1bWVudCBkYXRlOjxzcGFuIGNsYXNzPSJtLTU5MjMxNTUxNjAyMzY5OTM2NTZhcHBsZS10YWIt c3BhbiI+IDwvc3Bhbj4yMDE3LTAzLTEzPGJyPg0KR3JvdXA6PHNwYW4gY2xhc3M9Im0tNTkyMzE1 NTE2MDIzNjk5MzY1NmFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPm5ldG1vZDxicj4NClBhZ2VzOjxz cGFuIGNsYXNzPSJtLTU5MjMxNTUxNjAyMzY5OTM2NTZhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj4z Mjxicj4NClVSTDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xMC50eHQiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1uZXRt b2QtYWNsLW1vZGVsLTEwLnR4dDwvYT48YnI+DQpTdGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC8iIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1hY2wt bW9kZWwvPC9hPjxicj4NCkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRt b2QtYWNsLW1vZGVsLTEwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xMDwvYT48YnI+DQpEaWZmOiAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2Qt YWNsLW1vZGVsLTEwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xMDwvYT48YnI+DQo8YnI+DQpBYnN0 cmFjdDo8YnI+DQombmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGRhdGEgbW9k ZWwgb2YgQWNjZXNzIENvbnRyb2wgTGlzdCAoQUNMKTxicj4NCiZuYnNwOyZuYnNwO2Jhc2ljIGJ1 aWxkaW5nIGJsb2Nrcy48YnI+DQo8YnI+DQombmJzcDsmbmJzcDtFZGl0b3JpYWwgTm90ZSAoVG8g YmUgcmVtb3ZlZCBieSBSRkMgRWRpdG9yKTxicj4NCjxicj4NCiZuYnNwOyZuYnNwO1RoaXMgZHJh ZnQgY29udGFpbnMgbWFueSBwbGFjZWhvbGRlciB2YWx1ZXMgdGhhdCBuZWVkIHRvIGJlIHJlcGxh Y2VkPGJyPg0KJm5ic3A7Jm5ic3A7d2l0aCBmaW5hbGl6ZWQgdmFsdWVzIGF0IHRoZSB0aW1lIG9m IHB1YmxpY2F0aW9uLiZuYnNwOyBUaGlzIG5vdGU8YnI+DQombmJzcDsmbmJzcDtzdW1tYXJpemVz IGFsbCBvZiB0aGUgc3Vic3RpdHV0aW9ucyB0aGF0IGFyZSBuZWVkZWQuJm5ic3A7IFBsZWFzZSBu b3RlPGJyPg0KJm5ic3A7Jm5ic3A7dGhhdCBubyBvdGhlciBSRkMgRWRpdG9yIGluc3RydWN0aW9u cyBhcmUgc3BlY2lmaWVkIGFueXdoZXJlIGVsc2UgaW48YnI+DQombmJzcDsmbmJzcDt0aGlzIGRv Y3VtZW50Ljxicj4NCjxicj4NCiZuYnNwOyZuYnNwO0FydHdvcmsgaW4gdGhpcyBkb2N1bWVudCBj b250YWlucyBzaG9ydGhhbmQgcmVmZXJlbmNlcyB0byBkcmFmdHMgaW48YnI+DQombmJzcDsmbmJz cDtwcm9ncmVzcy4mbmJzcDsgUGxlYXNlIGFwcGx5IHRoZSBmb2xsb3dpbmcgcmVwbGFjZW1lbnRz PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7byAmbmJzcDsmcXVvdDtYWFhYJnF1b3Q7IC0tJmd0OyB0 aGUgYXNzaWduZWQgUkZDIHZhbHVlIGZvciB0aGlzIGRyYWZ0Ljxicj4NCjxicj4NCiZuYnNwOyZu YnNwO28gJm5ic3A7UmV2aXNpb24gZGF0ZSBpbiBtb2RlbCAoT2N0IDEyLCAyMDE2KSBuZWVkcyB0 byBnZXQgdXBkYXRlZCB3aXRoPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhl IGRhdGUgdGhlIGRyYWZ0IGdldHMgYXBwcm92ZWQuJm5ic3A7IFRoZSBkYXRlIGFsc28gbmVlZHMg dG8gZ2V0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVmbGVjdGVkIG9uIHRo ZSBsaW5lIHdpdGggJmx0O0NPREUgQkVHSU5TJmd0Oy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpUaGUgSUVU RiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_86AA35DF0D2245E7A954E766133ED49Djunipernet_-- From nobody Sun Mar 26 15:34:19 2017 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 25DD01286CA; Sun, 26 Mar 2017 15:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 YtBT3vI4UCiU; Sun, 26 Mar 2017 15:34:04 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0118.outbound.protection.outlook.com [23.103.201.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B75126BF6; Sun, 26 Mar 2017 15:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kRlebIrkaonK3beZ9dRyY9pgdGDvNaR4lhvQAvggURM=; b=Nz+1adadMyBd+R5mPsCCjAWwV3/mUg05e+3l3RA8LFc0cirSGWtxy8G+C69XlE/f+FQSdtr8LQQk8DRNadqxVVDH8MjJo2VaByslC1ap8gp4yBx/MeoJ6Zv83VUenVZEf0wdtoX/SJgEYrYvxRhUYtXgKLmaSN5XSKUFGAvOgp4= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1439.namprd09.prod.outlook.com (10.173.50.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Sun, 26 Mar 2017 22:34:02 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.020; Sun, 26 Mar 2017 22:34:01 +0000 From: "Waltermire, David A. (Fed)" To: "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "mile@ietf.org" Thread-Topic: PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8g== Date: Sun, 26 Mar 2017 22:34:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.220.139] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1439; 7:hClKWSPOlpJaHaSusXNqvUn2+aKbt/Rr9pKEAoIfd9jzNKkjkWBjiwZpyodwJaX9pfqcZcmO0PUki2D7LW58cV8awv2NPXwL48+xcCiBOatbRJsm9OK+ZDb4CgqfkDrgvQn8WbVhDoJ7EUej1Dxk7Wn4RNf4u3/jyn7OQnNOq03us3436SEWN4D3EDi8ko187EY0r65cXVhLCr02nopa9Uz55QKED6R1pCLFujK5kmM6EIxS4k5JHQKCZYi0l5mgp7hcbrPNosPefSCwWb7Y6gCYDFBDbK/JIxedaL1Uq1IAw1RX9gBjs4AOzD0tHwNRgX55loptWGMw+xpb58LJgQ== x-ms-office365-filtering-correlation-id: d1714e22-885a-4c53-e580-08d4749833d9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:MWHPR09MB1439; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:MWHPR09MB1439; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1439; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39840400002)(39450400003)(39410400002)(39850400002)(5660300001)(2501003)(6116002)(102836003)(3846002)(8936002)(74316002)(97736004)(122556002)(7736002)(189998001)(25786009)(2201001)(450100002)(53936002)(8676002)(7696004)(81166006)(38730400002)(86362001)(305945005)(33656002)(99286003)(9686003)(55016002)(6506006)(6436002)(77096006)(2900100001)(3660700001)(66066001)(2906002)(50986999)(54356999)(3280700002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1439; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2017 22:34:01.8200 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1439 Archived-At: Subject: [netmod] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 22:34:07 -0000 The US Government has been working within the IETF SACM work group to stand= ardize the collection of endpoint configuration and other posture informati= on from enterprise endpoints. Collecting this information is critical to su= pport automation of common network security tasks, including asset, softwar= e, vulnerability, and configuration management. Thus far, our efforts have = focused primarily on standards to collect information in support of asset, = software and vulnerability management use cases, and has worked with other = IETF members to determine what data would need to be to be collected, and h= ow that data would be securely communicated across the network. Through suc= h exchanges an organization can know what client endpoints are connected to= their network, and if they are vulnerable to attack. Given the proliferation of attacks against network infrastructure devices, = it is clear that the next step in our enterprise security automation effort= must be to enable standardized reporting of similar information from netwo= rk infrastructure devices. With the growing number of Yang models and incre= ased adoption of NETCONF, RESTCONF, and related protocol work, the time is = right to work out how these standards can be used to measure the health of = network devices. This information will, as in our efforts in SACM for clien= t devices, support asset, software, vulnerability, and configuration manage= ment use cases. Standards-based reporting of this information from network = infrastructure devices will help network defenders protect against known at= tacks, and provide the necessary knowledge to detect and mitigate future at= tacks.=20 We would like to start a discussion about how to leverage the existing IETF= network management protocols to best address security automation for netwo= rk infrastructure devices. We would like your ideas on how to best pursue t= his work, and your insights into network infrastructure security problems t= hat will impact our networks in the future. We are holding a side meeting a= t IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion abou= t how to move forward. We will be meeting in Vevey 4 at the IETF meeting ve= nue. Here is a summary of the meeting details: PANIC (Posture Assessment through Network Information Collection) Bar BoF Wednesday, March 29th, 2017 @ 6:30pm CDT Swissotel Conference Center - Vevey 4 We look forward to working with you, and hope to see you in Chicago at the = PANIC Bar BoF. Regards, Dave David Waltermire Information Technology Laboratory | Computer Security Division National Institute of Standards and Technology From nobody Mon Mar 27 04:05:46 2017 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 C972412947B; Mon, 27 Mar 2017 04:05:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149061273980.30545.7535277172948608866@ietfa.amsl.com> Date: Mon, 27 Mar 2017 04:05:39 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-14.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 11:05:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : A YANG Data Model for Syslog Configuration Authors : Clyde Wildes Kiran Koushik Filename : draft-ietf-netmod-syslog-model-14.txt Pages : 28 Date : 2017-03-27 Abstract: This document describes a data model for the configuration of syslog. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-14 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 27 09:09:54 2017 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 2A921129478 for ; Mon, 27 Mar 2017 09:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVCMA3c--hDH for ; Mon, 27 Mar 2017 09:09:51 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9476A129465 for ; Mon, 27 Mar 2017 09:09:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7EA0F1E5693; Mon, 27 Mar 2017 09:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wYdC9sGrss6k; Mon, 27 Mar 2017 09:09:14 -0700 (PDT) Received: from [172.16.46.43] (dtrscolumbus03.d.subnet.rcn.com [207.229.135.146]) by c8a.amsl.com (Postfix) with ESMTPSA id 3D8DB1E568B; Mon, 27 Mar 2017 09:09:14 -0700 (PDT) From: William Lupton Content-Type: multipart/alternative; boundary="Apple-Mail=_011DAB40-E1B9-4602-B6A4-F6955B80D6DC" Date: Mon, 27 Mar 2017 11:09:51 -0500 To: netmod@ietf.org Message-Id: <914D6A80-10BA-42A8-AC71-14BDD9E62A4C@broadband-forum.org> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [netmod] BBF alarm management YANG plans X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 16:09:53 -0000 --Apple-Mail=_011DAB40-E1B9-4602-B6A4-F6955B80D6DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, I believe that we last discussed alarms (and = draft-vallin-netmod-alarm-module) back in October when the -01 draft was = published. Alarm management has once again come to the fore in BBF and I = wanted to give NETMOD an update on our plans. We wish to base our alarm management support on = draft-vallin-netmod-alarm-module We request that it be adopted as a working group draft We will have various comments, e.g. Providing some means of overriding alarm severities Adjusting the alarm-history feature to include some additional nodes = that we believe should be within its scope Various proposals to adjust node names that we feel will better reflect = their usage and/or increase consistency Individual contributors will bring detailed comments directly to the = NETMOD list. Thanks, William= --Apple-Mail=_011DAB40-E1B9-4602-B6A4-F6955B80D6DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All,

I believe that we last discussed alarms = (and draft-vallin-netmod-alarm-module) back in October when the -01 = draft was published. Alarm management has once again come to the fore in = BBF and I wanted to give NETMOD an update on our plans.
  • We wish to base our = alarm management support = on draft-vallin-netmod-alarm-module
  • We request = that it be adopted as a working group draft
  • We will = have various comments, e.g.
    • Providing = some means of overriding alarm severities
    • Adjusting = the alarm-history feature to include some additional nodes that we = believe should be within its scope
    • Various proposals = to adjust node names that we feel will better reflect their usage and/or = increase consistency
Individual = contributors will bring detailed comments directly to the NETMOD = list.

Thanks,
William
= --Apple-Mail=_011DAB40-E1B9-4602-B6A4-F6955B80D6DC-- From nobody Mon Mar 27 18:44:38 2017 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 4AABE12762F for ; Mon, 27 Mar 2017 18:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 6JRFRxXsNvMA for ; Mon, 27 Mar 2017 18:44:32 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4321296D1 for ; Mon, 27 Mar 2017 18:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21598; q=dns/txt; s=iport; t=1490665472; x=1491875072; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=RdrzcDyjsOdTej5xwuYSh2MfURQzldkODWZxPVVYymo=; b=CV/Xh3spefQODOYN3ZBy/qFk/UjUmLIMHLxrfx0zFHc0XZasVS85XdMi EbwsY88ubqngONeDHBoXBBhrzlh/+440OHd8bl4uqO7qAlAjffCEEtwVV 84yeIVAJ+5YU3zdR5CVTfEuOk4Emp/AYEzNZD/JuSJdcLPquXRiJGyIld E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQC8v9lY/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQuNcZFQiBeNNIILAx8LhS5KAoMePxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQMBARgeNgQHDAQLDgMEAQEBDBsHIQYfCQgGAQwGAgEBF4lUAxUOrjmHN?= =?us-ascii?q?w2DCwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhk6CBYFhgQmCPRSHaAWJHgWHPYt?= =?us-ascii?q?BOoZ7hxuENoF8hSqDNCOGNIhXghZiiBYfOIEEJBYIFxVBhFgdggEiNYltAQEB?= X-IronPort-AV: E=Sophos;i="5.36,234,1486425600"; d="scan'208";a="400959691" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 01:44:26 +0000 Received: from [10.82.212.25] (rtp-vpn4-1049.cisco.com [10.82.212.25]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2S1iP6U024924; Tue, 28 Mar 2017 01:44:26 GMT To: Mehmet Ersue , "'Lou Berger'" , "'Kent Watsen'" , netmod@ietf.org References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <675654fd-1532-1755-621c-a3ecb06950e3@labn.net> <025a01d29e82$8549d070$8fdd7150$@gmail.com> <02c901d29f70$fd0cbe30$f7263a90$@gmail.com> From: Benoit Claise Message-ID: Date: Mon, 27 Mar 2017 20:44:25 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <02c901d29f70$fd0cbe30$f7263a90$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 01:44:36 -0000 Mehmet, As long as the WG items are in the milestones, we're good. Regards, Benoit > Hi Lou, Kent, > > I promised to provide some minimal text which can be used as WG item > description. > I'm fine with any fine tuning. > > See below: > > a) Maintaining the data modeling language YANG. This effort entails > periodically updating the specification to address new requirements > as they arise. ADD RFC 7950./> > > b) Maintaining the guidelines for developing YANG models. This effort > is primarily driven by updates made to the YANG specification. > ADD RFC 6087./> > > c) Maintaining a conceptual framework in which YANG models are used. > This effort entails describing the generic context that in YANG > exists and how certain YANG statements interact in that context. > An example of this is YANG's relationship with datastores. ADD revised datastore draft will provide a conceptual framework for the handling > of datastores, which can be adopted by other WGs for their usage scenario./> > > . . . > > e) Maintaining YANG models used as basic YANG building blocks. This > effort entails updating existing YANG models (ietf-yang-types and > ietf-inet-types) as needed, as well as defining additional core YANG > data models when necessary. ADD the models for Syslog, ACL and Common Interface Extensions as well as the > model for hardware management. The Schema mount draft will provide a > mechanism to combine YANG modules into the schema defined in other YANG > modules./> > > BTW: There is no topic description (in a)-f) covering YANG module > classification. > I assume it can be added with a sentence to a) or b). > > Thanks, > Mehmet > >> -----Original Message----- >> From: Mehmet Ersue >> Sent: Thursday, March 16, 2017 11:59 PM >> To: Lou Berger ; 'Kent Watsen' ; >> netmod@ietf.org >> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' >> >> Subject: RE: [netmod] draft netmod charter update proposal >> >>> From: Lou Berger [mailto:lberger@labn.net] Mehmet, >>> see below. >>> On 3/16/2017 2:24 PM, Mehmet Ersue wrote: >>>> Lou, >> . . . >>>> I actually provided a very simple proposal. You guys can fill the >>>> idea with minimal text better than me. I'm fine whatever the text is. >>>> If you think the high-level topic description a)-f) does already >>>> define the WG item clearly you can simply say "this is achieved with >>>> WG >>> item XY". >>>> If not, you can keep the high-level focus text but set additionally >>>> the borders of the WG item with a few concrete words. >>> I really can't tell for sure, but it feels to me that this comment >>> boils down to a style comment and you have a preference for different >>> contents in the charter. I'd like to be sensitive to this. As our >>> style differs, having a concrete proposal on specific text changes >>> would be really helpful in us (and the WG) evaluating the changes >>> you'd like to see. Without such specific examples and think we're >>> left with the charter as currently proposed. Perhaps someone else who >> has similar feelings can chime in and provide proposed text. >>> Anyone else have any comments or proposed changes? >> I think the wording depends on the time period is for which the charter is >> prepared. >> I can try some text once I have time tomorrow. >> >> . . . >>>> I think the DS draft provides a conceptual framework for diverse DS >>>> usage scenarios to be used by many protocols, where IETF WGs may >>>> actually decide using a subset of the DS framework for their purpose >>>> and for their protocol standardization. >>>> Based on this the conceptual framework cannot be standardized as it >>>> is but the protocols using a consistent subset have to be > standardized. >>>> Following this consideration I think the intended status of the DS >>>> draft should be changed to: Informational RFC If you agree please >>>> indicate this change accordingly. >>> I think Juergen's reply to your previous message highlights that there >>> is a difference of opinion here based on the technical specifics of >>> the draft. My position as chair is that I'll support whatever makes >>> sense based on the document produced by the WG. Today the document >>> authors believe PS is appropriate, once we have a version that is >>> stabilizing for LC -- which hopefully will be the next version or two >>> -- then will be a good time to revisit this. >> There are indeed different opinions concerning the goal of the DS draft. >> I agree with the document introduction and see it as a conceptual > framework >> covering many usage scenarios. >> Such a conceptual framework describing possible solutions is informational > in >> nature and is not relevant for standardization. >> >>>>>> This is as I think also important to avoid an overlapping between >>>>>> NETCONF and NETMOD charters. >>>>> I don't follow this point. Certainly I'd hope that the protocol >>>>> impact of revised DS are covered in a PS document, unless for some >>>>> reason there are no "on-the-wire" changes needed. TI wouldn't >>>>> expect that the document status of the base revised data store >>>>> document would >>> impact that. Do you? >>>>> If so, how? >>>> My comment is actually superfluous if you agree with my >>>> considerations above. >>>> The worst case would in my opinion happen if the DS conceptual >>>> framework covering many high-level DS usage scenarios would be >>>> attempted to standardize, which at the end would prescribe protocol >>>> WGs what they should be standardizing. >>> Yang presumes a certain set of functions for the protocols it operates > over. >>> I'm not sure why having a document that specifies this would be an > issue. >> This is again an interesting discussion which SHOULD be discussed in a > joint >> session. >> I don't have a strong opinion but it can be seen differently. >> >>>> In such a case the conceptual framework would most likely cause a >>>> competing situation with protocol WG's goals and documents and >>>> cannot be adopted successfully. >>> If a protocol doesn't provide full support for yang (requirements) it >>> can't fully support all yang features. If your point is that when >>> NetMod changes basic yang functions/operations that this might >>> constrain the protocols (and related WGs) over which it operates, then >>> I agree that this is the case. How could it be otherwise? >> Usually modeling languages provide many language constructs and people >> modeling models choose which one is best for their purpose. >> The same applies to the DS concept framework. The protocol WGs would like >> to have the freedom to choose the subset to adopt from the protocol pov. >> >>> Thanks, >>> >>> Lou >>> >>>> Thanks, >>>> Mehmet >>>> >>>>>> PS: I expect that most of the Netconf WG member read also the >>> Netmod >>>>>> maillist and therefor skip sending to both ML. >>>>>> >>>>> Great. >>>>> >>>>> Thanks. >>>>> Lou >>>>>> Thanks, >>>>>> Mehmet >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Mehmet Ersue >>>>>>> Sent: Thursday, March 9, 2017 7:36 PM >>>>>>> To: Lou Berger ; 'Kent Watsen' >>>>>>> ; netmod@ietf.org >>>>>>> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' >>>>>>> >>>>>>> Subject: RE: [netmod] draft netmod charter update proposal >>>>>>> >>>>>>> Hi Lou, >>>>>>> >>>>>>>> The charters from the last couple of years don't have the >>>>>>>> intended >>>>>> status -- >>>>>>> at least the ones we checked. >>>>>>>> I actually feel pretty strongly about this (which of course can >>>>>>>> be easily overruled by our AD). It's my experience that >>>>>>>> premature discussions on intended status, i.e., before a >>>>>>>> document is sufficiently >>>>>>> mature, leads to process-focused arguments that detracts from >>>>>>> making technical progress. While once a document is mature and >>>>>>> core direction/content is fixed, it is generally obvious what >>>>>>> status is >>>>>> appropriate. >>>>>>> The charters from the last couple of years have a short WG item >>>>>> definition, >>>>>>> which would be IMO sufficient. >>>>>>> You are right the intended status is not available since a few >>>>>>> years, but >>>>>> IMO it >>>>>>> is part of the target definition and would be very useful for the >>>>>>> draft >>>>>> authors >>>>>>> and WG members to regard. >>>>>>> >>>>>>>>> It would be good to bring the high-level topics in relation to >>>>>>>>> the WG >>>>>>> items. >>>>>>>> I'm sorry, I don't understand this last sentence can you rephrase > it? >>>>>>> What I meant is that the high-level topics a)-f) might be good as >>>>>>> WG focus description but are not sufficient as draft target > definition. >>>>>>> If you think the high-level topic description is more or less the >>>>>>> WG item definition, then we could simply write "this is achieved >>>>>>> with WG >>>> item >>>>> XY". >>>>>>> If not, we could keep the high-level focus text but set >>>>>>> additionally the borders of the WG item with some concrete words. >>>>>>> >>>>>>>>> BTW: We agreed in diverse discussions that the DS concept is >>>>>>> Informational in nature. >>>>>>>>> I think this should be corrected in the draft. >>>>>>>> So this sounds like an objection to a specific document. This >>>>>>>> is a fair point to raise, but in our opinion it is not a charter >>>>>>>> impacting point or discussion. If this is in fact the issue >>>>>>>> you'd like to raise and discuss, lets do so under a document >>>>>>>> specific thread, e.g., >>>>>> "Subject: >>>>>>> intended status of revised-datastore". >>>>>>> >>>>>>> I am actually raising this point since November meeting. There >>>>>>> are >>>>>> different >>>>>>> threads where I explained why it is appropriate as Informational. >>>>>>> The last thread I remember is at: >>>>>>> >> https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH1 >>>>>>> 1xcY >>>>>>> The recent position of NETCONF co-chairs is in >>>>>>> >> https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd >>>>>>> 8qr5k >>>>>>> >>>>>>> Thank you for your consideration. >>>>>>> >>>>>>> Regards, >>>>>>> Mehmet >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>> Sent: Wednesday, March 8, 2017 11:28 PM >>>>>>>> To: Mehmet Ersue ; 'Kent Watsen' >>>>>>>> ; netmod@ietf.org >>>>>>>> Subject: Re: [netmod] draft netmod charter update proposal >>>>>>>> >>>>>>>> Hi Mehmet, >>>>>>>> >>>>>>>> On 3/8/2017 4:47 PM, Mehmet Ersue wrote: >>>>>>>>> Kent, >>>>>>>>> >>>>>>>>>> we understand that this is how NETCONF charters are >>>>>>>>>> structured, but it is not our practice, >>>>>>>>> AFAIK it was the NETMOD practice for the charters until today. >>>>>>>> The charters from the last couple of years don't have the >>>>>>>> intended status -- at least the ones we checked. >>>>>>>> >>>>>>>> I actually feel pretty strongly about this (which of course can >>>>>>>> be easily overruled by our AD). It's my experience that >>>>>>>> premature discussions on intended status, i.e., before a >>>>>>>> document is sufficiently mature, leads to process-focused >>>>>>>> arguments that detracts >>>>>> from >>>>>>> making technical progress. >>>>>>>> While once a document is mature and core direction/content is >>>>>>>> fixed, it is generally obvious what status is appropriate. >>>>>>>> >>>>>>>> >>>>>>>>> I did not ask >>>>>>>>> more than written in the current charter. >>>>>>>>> It would be good to bring the high-level topics in relation to >>>>>>>>> the WG >>>>>>> items. >>>>>>>> I'm sorry, I don't understand this last sentence can you rephrase > it? >>>>>>>>>> as the information is available at the top of each draft, and >>>>>>>>>> also because >>>>>>>> this information need not be fixed when the milestone is added. >>>>>>>> >>>>>>>>> I believe a WG charter should be self-sufficient covering the >>>>>>>>> target definition and intended status of the WG items. >>>>>>>>> Otherwise one can change the target for a WG item by simply >>>>>>>>> editing the draft abstract anytime. >>>>>>>> Per IETF process, all it ever takes to make a change in document >>>>>>>> status is WG consensus, and then IESG and IETF buy-in as part of >>>>>>>> the >>>>>>> publication process. >>>>>>>>> BTW: We agreed in diverse discussions that the DS concept is >>>>>>>>> Informational in nature. >>>>>>>>> I think this should be corrected in the draft. >>>>>>>> So this sounds like an objection to a specific document. This >>>>>>>> is a fair point to raise, but in our opinion it is not a charter >>>>>>>> impacting point or discussion. If this is in fact the issue >>>>>>>> you'd like to raise and discuss, lets do so under a document >>>>>>>> specific thread, e.g., >>>>>> "Subject: >>>>>>>> intended status of revised-datastore". >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lou >>>>>>>> >>>>>>>>> Mehmet >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of >>> Kent >>>>>>>>>> Watsen >>>>>>>>>> Sent: Wednesday, March 8, 2017 7:45 PM >>>>>>>>>> To: netmod@ietf.org >>>>>>>>>> Cc: netmod-chairs@ietf.org >>>>>>>>>> Subject: Re: [netmod] draft netmod charter update proposal >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi NETMOD WG, >>>>>>>>>> >>>>>>>>>> Please find below draft-4 having the following change: >>>>>>>>>> >>>>>>>>>> - added "(e.g., I2RS, RTGWG)" to a sentence. >>>>>>>>>> >>>>>>>>>> Hi Sue, Lou and I looked at the proposed charter and found a >>>>>>>>>> sentence that nicely describes our WG's intent to work with >>>>>>>>>> and support other WGs (beyond NETCONF), but we felt that the >>>>>>>>>> text could be made more clear by adding in the above-mentioned >>> change. >>>>>>>>>> Beyond this, and the existing a), >>>>>>>>> b), >>>>>>>>>> and c), we believe that the charter proposal covers our >>>>>>>>>> support for I2RS, >>>>>>>>> do >>>>>>>>>> you agree? >>>>>>>>>> >>>>>>>>>> Hi Mehmet, regarding putting a short description and the >>>>>>>>>> intended status >>>>>>>>> for >>>>>>>>>> each draft into the charter, we understand that this is how >>>>>>>>>> NETCONF >>>>>>>>> charters >>>>>>>>>> are structured, but it is not our practice, as the information >>>>>>>>>> is >>>>>>>>> available at the >>>>>>>>>> top of each draft, and also because this information need not >>>>>>>>>> be fixed >>>>>>>>> when >>>>>>>>>> the milestone is added. >>>>>>>>>> >>>>>>>>>> All, Any other comments? >>>>>>>>>> >>>>>>>>>> Kent >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Network Modeling (NETMOD) >>>>>>>>>> ------------------------- >>>>>>>>>> >>>>>>>>>> Charter >>>>>>>>>> >>>>>>>>>> Current Status: Active >>>>>>>>>> >>>>>>>>>> Chairs: >>>>>>>>>> Lou Berger >>>>>>>>>> Kent Watsen >>>>>>>>>> >>>>>>>>>> Operations and Management Area Directors: >>>>>>>>>> Benoit Claise >>>>>>>>>> Joel Jaeggli >>>>>>>>>> >>>>>>>>>> Operations and Management Area Advisor: >>>>>>>>>> Benoit Claise >>>>>>>>>> >>>>>>>>>> Secretary: >>>>>>>>>> Zitao (Michael) Wang >>>>>>>>>> >>>>>>>>>> Mailing Lists: >>>>>>>>>> General Discussion: netmod@ietf.org >>>>>>>>>> To Subscribe: >> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>>>> Archive: >>>>>> https://mailarchive.ietf.org/arch/browse/netmod/ >>>>>>>>>> Description of Working Group: >>>>>>>>>> >>>>>>>>>> The Network Modeling (NETMOD) working group is responsible >>>>>>>>>> for the YANG >>>>>>>>>> data modeling language, and guidelines for developing YANG >>>>> models. >>>>>>>> The >>>>>>>>>> NETMOD working group addresses general topics related to >>>>>>>>>> the use of >>>>>>>> the >>>>>>>>>> YANG language and YANG models, for example, the mapping of >>>>> YANG >>>>>>>>>> modeled >>>>>>>>>> data into various encodings. Finally, the NETMOD working >> group >>>>>>>>>> also defines core YANG models used as basic YANG building >>>>>>>>>> blocks, >>>>>>> and >>>>>>>>>> YANG models that do not otherwise fall under the charter of >>>>>>>>>> any >>>>>> other >>>>>>>>>> IETF working group. >>>>>>>>>> >>>>>>>>>> The NETMOD WG is responsible for: >>>>>>>>>> >>>>>>>>>> a) Maintaining the data modeling language YANG. This >>>>>>>>>> effort >>>>>> entails >>>>>>>>>> periodically updating the specification to address new >>>>>> requirements >>>>>>>>>> as they arise. >>>>>>>>>> >>>>>>>>>> b) Maintaining the guidelines for developing YANG models. >>>>>>>>>> This >>>>>> effort >>>>>>>>>> is primarily driven by updates made to the YANG > specification. >>>>>>>>>> c) Maintaining a conceptual framework in which YANG models >>>>>>>>>> are >>>>>>> used. >>>>>>>>>> This effort entails describing the generic context that >>>>>>>>>> in >>>> YANG >>>>>>>>>> exists and how certain YANG statements interact in that >>>>>> context. >>>>>>>>>> An example of this is YANG's relationship with datastores. >>>>>>>>>> >>>>>>>>>> d) Maintaining encodings for YANG modeled data. This >>>>>>>>>> effort >>>>>> entails >>>>>>>>>> updating encodings already defined by the NETMOD working >>>>>>>>>> (XML >>>>>>> and >>>>>>>>>> JSON) to accommodate changes to the YANG specification, >>>>>>>>>> and >>>>>>>> defining >>>>>>>>>> new encodings that are needed, and yet do not fall under >>>>>>>>>> the >>>>>> charter >>>>>>>>>> of any other active IETF working group. >>>>>>>>>> >>>>>>>>>> e) Maintaining YANG models used as basic YANG building >> blocks. >>>>>> This >>>>>>>>>> effort entails updating existing YANG models >>>>>>>>>> (ietf-yang-types >>>>>> and >>>>>>>>>> ietf-inet-types) as needed, as well as defining >>>>>>>>>> additional core >>>>>> YANG >>>>>>>>>> data models when necessary. >>>>>>>>>> >>>>>>>>>> f) Defining and maintaining YANG models that do not fall >>>>>>>>>> under >>>> the >>>>>>>>>> charter of any other active IETF working group. >>>>>>>>>> >>>>>>>>>> The NETMOD working group consults with the NETCONF >> working >>>>>>> group >>>>>>>> to >>>>>>>>>> ensure that new requirements are understood and can be met >>>>>>>>>> by >>>>> the >>>>>>>>>> protocols (e.g., NETCONF and RESTCONF) developed within >>>>>>>>>> that >>>>>>> working >>>>>>>>>> group. The NETMOD working group coordinates with other >>>>>>>>>> working >>>>>>>> groups >>>>>>>>>> (e.g., I2RS, RTGWG) on possible extensions to YANG to >>>>>>>>>> address >>> new >>>>>>>>>> modeling requirements and, when needed, which group will >>>>>>>>>> run >>> the >>>>>>>>>> process on a specific model. >>>>>>>>>> >>>>>>>>>> The NETMOD working group does not serve as a review team >>>>>>>>>> for >>>>>>> YANG >>>>>>>>>> modules developed by other working groups. Instead, the >>>>>>>>>> YANG >>>>>>>> doctors, >>>>>>>>>> as organized by the OPS area director responsible for network >>>>>>>>>> management, will act as advisors for other working groups >>>>>>>>>> and >>>>>> provide >>>>>>>>>> YANG reviews for the OPS area directors. >>>>>>>>>> >>>>>>>>>> Milestones: >>>>>>>>>> >>>>>>>>>> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for >>>>>> publication >>>>>>>>>> Mar 2017 - Submit >>>>>>>>>> draft-ietf-netmod-yang-model-classification >>>>>>>>>> to >>>>>> IESG >>>>>>>>>> for publication >>>>>>>>>> Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for >>>>>> publication >>>>>>>>>> Apr 2017 - Submit draft-ietf-netmod-entity to IESG for >>>> publication >>>>>>>>>> Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG >>>>>>>>>> for >>>>>>>>> publication >>>>>>>>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG >>>>>>>>>> for >>>>>>>>> publication >>>>>>>>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores to >>>>>>>>>> IESG >>>> for >>>>>>>>>> publication >>>>>>>>>> Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for >>>>>>>>>> publication >>>>>>>>>> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to >>>>>>>>>> IESG >>>> for >>>>>>>>>> publication >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 Mon Mar 27 18:50:31 2017 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 2AB5312985A for ; Mon, 27 Mar 2017 18:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 3NWWH3sej4TK for ; Mon, 27 Mar 2017 18:50:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3EB1297EC for ; Mon, 27 Mar 2017 18:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25280; q=dns/txt; s=iport; t=1490665824; x=1491875424; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=2AjHrHBe/O1K7XFjBl0MKLuTGdGaLF+t0yhP9WuJn0c=; b=ms+Ntg8esWXKN9FNsHihE94qhuSEWvhQRp5f0BNEgReZYv98TcgINrOr YsFvtGlG+Q3CPCljs4elzheeO5zJlhfB5nmB75CA8j9D5wuMK+f7gTbFR +AItAq87MyRyC+7PSkDauKy/I5E65WyKbo4uavuBlmb9WWyDrgjP69x7v g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAQDnwNlY/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQuDYooPkVCIF400ggsDHwuFLkoCgx4/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAwEBGAkVNgQHDAQLDgMEAQEBAgIIGwMCAiEGHwkIBgEMBgIBAReJV?= =?us-ascii?q?AMVDqwTgiaHNw2DCwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFQ4IFgWGBCYI?= =?us-ascii?q?9FIUJgl8FiR4Fhz2LQTqGe4cbhDaBfIUqgzQjhjSIV4IWYogWHziBBCQWCBcVQ?= =?us-ascii?q?YRYHYIBIjWJbQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,234,1486425600"; d="scan'208";a="223737523" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 01:50:07 +0000 Received: from [10.82.212.25] (rtp-vpn4-1049.cisco.com [10.82.212.25]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v2S1o31Y009953; Tue, 28 Mar 2017 01:50:04 GMT To: Mehmet Ersue , "'Kent Watsen'" , "'Lou Berger'" , netmod@ietf.org References: <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <02e701d29d93$0e770480$2b650d80$@gmail.com> <675654fd-1532-1755-621c-a3ecb06950e3@labn.net> <025a01d29e82$8549d070$8fdd7150$@gmail.com> <007201d2a349$fa8c3b40$efa4b1c0$@gmail.com> <142D20A9-8A20-4D2E-8B2F-BDE7514A28B1@juniper.net> <017c01d2a3f7$96201420$c2603c60$@gmail.com> From: Benoit Claise Message-ID: Date: Mon, 27 Mar 2017 20:50:03 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <017c01d2a3f7$96201420$c2603c60$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft netmod charter update proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 01:50:30 -0000 Dear all, >>>>>>>>>>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores >>>>>>>>>>>> to IESG > Another question is whether this should be earlier, e.g. August. > As it is a high-priority topic needed at least by 2 WGs, Agreed. This should be earlier. Regards, Benoit > we were saying that revised-datastores should be finalized within 4 months and NC/RC-bis will take another 4-5 months. > > Thanks, > Mehmet > >> -----Original Message----- >> From: Kent Watsen [mailto:kwatsen@juniper.net] >> Sent: Wednesday, March 22, 2017 9:48 PM >> To: Mehmet Ersue ; 'Lou Berger' ; >> netmod@ietf.org >> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' >> >> Subject: Re: [netmod] draft netmod charter update proposal >> >> Hi Mehmet, >> >> From a charter perspective, we have: >> >> a) Maintaining the data modeling language YANG. This effort >> entails periodically updating the specification to address >> new requirements as they arise. >> >> From a milestone perspective, you are correct that we don't have a >> milestone for 7950bis as of yet. We do, however, have a "YANG Next" >> discussion on the agenda, which may or may not lead to the creation of a >> milestone for it. >> >> As for NETCONF/RESTCONF revisions depending on a 7950bis, if that is true, >> then it will likely force us to create the milestone in the near-term for it. That >> withstanding, I think that NETCONF WG could take the lead by >> moving/copying the NETCONF-specific parts from RFC7950 into an rfc6241bis. >> It would be nice if we could decouple the refactoring of these documents >> across our WGs. >> >> Kent // co-chair hat >> >> >> >> -----ORIGINAL MESSAGE----- >> Hi Kent, Lou, >> >> as I see 7950bis has not been mentioned in the charter text and the >> milestones. >> As you know NETCONF and RESTCONF revisions are dependent on the timing >> of 7950bis. >> How is this essential deliverable and its timing going to be addressed in the >> charter? >> >> Mehmet >> >>> -----Original Message----- >>> From: Mehmet Ersue >>> Sent: Friday, March 17, 2017 11:51 PM >>> To: Lou Berger ; 'Kent Watsen' >>> ; netmod@ietf.org >>> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' >>> >>> Subject: RE: [netmod] draft netmod charter update proposal >>> >>> Hi Lou, Kent, >>> >>> I promised to provide some minimal text which can be used as WG item >>> description. >>> I'm fine with any fine tuning. >>> >>> See below: >>> >>> a) Maintaining the data modeling language YANG. This effort entails >>> periodically updating the specification to address new requirements >>> as they arise. ADD>> revision >> of RFC >>> 7950./> >>> >>> b) Maintaining the guidelines for developing YANG models. This effort >>> is primarily driven by updates made to the YANG specification. >> ADD>> continuous effort has been recently addressed with a revision of RFC >> 6087./> >>> c) Maintaining a conceptual framework in which YANG models are used. >>> This effort entails describing the generic context that in YANG >>> exists and how certain YANG statements interact in that context. >>> An example of this is YANG's relationship with datastores. >>> ADD>> for the >> handling >>> of datastores, which can be adopted by other WGs for their usage >>> scenario./> >>> >>> . . . >>> >>> e) Maintaining YANG models used as basic YANG building blocks. This >>> effort entails updating existing YANG models (ietf-yang-types and >>> ietf-inet-types) as needed, as well as defining additional core YANG >>> data models when necessary. ADD>> work on the models for Syslog, ACL and Common Interface Extensions as >>> well as the model for hardware management. The Schema mount draft will >>> provide a mechanism to combine YANG modules into the schema defined >> in >>> other YANG modules./> >>> >>> BTW: There is no topic description (in a)-f) covering YANG module >>> classification. >>> I assume it can be added with a sentence to a) or b). >>> >>> Thanks, >>> Mehmet >>> >>>> -----Original Message----- >>>> From: Mehmet Ersue >>>> Sent: Thursday, March 16, 2017 11:59 PM >>>> To: Lou Berger ; 'Kent Watsen' >>>> ; netmod@ietf.org >>>> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' >>>> >>>> Subject: RE: [netmod] draft netmod charter update proposal >>>> >>>>> From: Lou Berger [mailto:lberger@labn.net] Mehmet, >>>>> see below. >>>>> On 3/16/2017 2:24 PM, Mehmet Ersue wrote: >>>>>> Lou, >>>> . . . >>>>>> I actually provided a very simple proposal. You guys can fill >>>>>> the idea with minimal text better than me. I'm fine whatever the >>>>>> text >> is. >>>>>> If you think the high-level topic description a)-f) does already >>>>>> define the WG item clearly you can simply say "this is achieved >>>>>> with WG >>>>> item XY". >>>>>> If not, you can keep the high-level focus text but set >>>>>> additionally the borders of the WG item with a few concrete words. >>>>> I really can't tell for sure, but it feels to me that this comment >>>>> boils down to a style comment and you have a preference for >>>>> different contents in the charter. I'd like to be sensitive to >>>>> this. As our style differs, having a concrete proposal on >>>>> specific text changes would be really helpful in us (and the WG) >>>>> evaluating the changes you'd like to see. Without such specific >>>>> examples and think we're left with the charter as currently >>>>> proposed. Perhaps someone else who >>>> has similar feelings can chime in and provide proposed text. >>>>> Anyone else have any comments or proposed changes? >>>> I think the wording depends on the time period is for which the >>>> charter is prepared. >>>> I can try some text once I have time tomorrow. >>>> >>>> . . . >>>>>> I think the DS draft provides a conceptual framework for diverse >>>>>> DS usage scenarios to be used by many protocols, where IETF WGs >>>>>> may actually decide using a subset of the DS framework for their >>>>>> purpose and for their protocol standardization. >>>>>> Based on this the conceptual framework cannot be standardized as >>>>>> it is but the protocols using a consistent subset have to be >> standardized. >>>>>> Following this consideration I think the intended status of the >>>>>> DS draft should be changed to: Informational RFC If you agree >>>>>> please indicate this change accordingly. >>>>> I think Juergen's reply to your previous message highlights that >>>>> there is a difference of opinion here based on the technical >>>>> specifics of the draft. My position as chair is that I'll support >>>>> whatever makes sense based on the document produced by the WG. >>>>> Today the document authors believe PS is appropriate, once we have >>>>> a version that is stabilizing for LC -- which hopefully will be >>>>> the next version or two >>>>> -- then will be a good time to revisit this. >>>> There are indeed different opinions concerning the goal of the DS draft. >>>> I agree with the document introduction and see it as a conceptual >>>> framework covering many usage scenarios. >>>> Such a conceptual framework describing possible solutions is >>>> informational in nature and is not relevant for standardization. >>>> >>>>>>>> This is as I think also important to avoid an overlapping >>>>>>>> between NETCONF and NETMOD charters. >>>>>>> I don't follow this point. Certainly I'd hope that the >>>>>>> protocol impact of revised DS are covered in a PS document, >>>>>>> unless for some reason there are no "on-the-wire" changes >>>>>>> needed. TI wouldn't expect that the document status of the >>>>>>> base revised data store document would >>>>> impact that. Do you? >>>>>>> If so, how? >>>>>> My comment is actually superfluous if you agree with my >>>>>> considerations above. >>>>>> The worst case would in my opinion happen if the DS conceptual >>>>>> framework covering many high-level DS usage scenarios would be >>>>>> attempted to standardize, which at the end would prescribe >>>>>> protocol WGs what they should be standardizing. >>>>> Yang presumes a certain set of functions for the protocols it >>>>> operates >>> over. >>>>> I'm not sure why having a document that specifies this would be an >> issue. >>>> This is again an interesting discussion which SHOULD be discussed in >>>> a joint session. >>>> I don't have a strong opinion but it can be seen differently. >>>> >>>>>> In such a case the conceptual framework would most likely cause >>>>>> a competing situation with protocol WG's goals and documents and >>>>>> cannot be adopted successfully. >>>>> If a protocol doesn't provide full support for yang (requirements) >>>>> it can't fully support all yang features. If your point is that >>>>> when NetMod changes basic yang functions/operations that this >>>>> might constrain the protocols (and related WGs) over which it >>>>> operates, then I agree that this is the case. How could it be otherwise? >>>> Usually modeling languages provide many language constructs and >>>> people modeling models choose which one is best for their purpose. >>>> The same applies to the DS concept framework. The protocol WGs would >>>> like to have the freedom to choose the subset to adopt from the >>>> protocol >>> pov. >>>>> Thanks, >>>>> >>>>> Lou >>>>> >>>>>> Thanks, >>>>>> Mehmet >>>>>> >>>>>>>> PS: I expect that most of the Netconf WG member read also the >>>>> Netmod >>>>>>>> maillist and therefor skip sending to both ML. >>>>>>>> >>>>>>> Great. >>>>>>> >>>>>>> Thanks. >>>>>>> Lou >>>>>>>> Thanks, >>>>>>>> Mehmet >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Mehmet Ersue >>>>>>>>> Sent: Thursday, March 9, 2017 7:36 PM >>>>>>>>> To: Lou Berger ; 'Kent Watsen' >>>>>>>>> ; netmod@ietf.org >>>>>>>>> Cc: 'Benoit Claise' ; 'Mahesh Jethanandani' >>>>>>>>> >>>>>>>>> Subject: RE: [netmod] draft netmod charter update proposal >>>>>>>>> >>>>>>>>> Hi Lou, >>>>>>>>> >>>>>>>>>> The charters from the last couple of years don't have the >>>>>>>>>> intended >>>>>>>> status -- >>>>>>>>> at least the ones we checked. >>>>>>>>>> I actually feel pretty strongly about this (which of course >>>>>>>>>> can be easily overruled by our AD). It's my experience that >>>>>>>>>> premature discussions on intended status, i.e., before a >>>>>>>>>> document is sufficiently >>>>>>>>> mature, leads to process-focused arguments that detracts from >>>>>>>>> making technical progress. While once a document is mature >>>>>>>>> and core direction/content is fixed, it is generally obvious >>>>>>>>> what status is >>>>>>>> appropriate. >>>>>>>>> The charters from the last couple of years have a short WG >>>>>>>>> item >>>>>>>> definition, >>>>>>>>> which would be IMO sufficient. >>>>>>>>> You are right the intended status is not available since a >>>>>>>>> few years, but >>>>>>>> IMO it >>>>>>>>> is part of the target definition and would be very useful for >>>>>>>>> the draft >>>>>>>> authors >>>>>>>>> and WG members to regard. >>>>>>>>> >>>>>>>>>>> It would be good to bring the high-level topics in relation >>>>>>>>>>> to the WG >>>>>>>>> items. >>>>>>>>>> I'm sorry, I don't understand this last sentence can you >> rephrase >>> it? >>>>>>>>> What I meant is that the high-level topics a)-f) might be >>>>>>>>> good as WG focus description but are not sufficient as draft >>>>>>>>> target >>> definition. >>>>>>>>> If you think the high-level topic description is more or less >>>>>>>>> the WG item definition, then we could simply write "this is >>>>>>>>> achieved with WG >>>>>> item >>>>>>> XY". >>>>>>>>> If not, we could keep the high-level focus text but set >>>>>>>>> additionally the borders of the WG item with some concrete >> words. >>>>>>>>>>> BTW: We agreed in diverse discussions that the DS concept >>>>>>>>>>> is >>>>>>>>> Informational in nature. >>>>>>>>>>> I think this should be corrected in the draft. >>>>>>>>>> So this sounds like an objection to a specific document. >>>>>>>>>> This is a fair point to raise, but in our opinion it is not >>>>>>>>>> a charter impacting point or discussion. If this is in fact >>>>>>>>>> the issue you'd like to raise and discuss, lets do so under >>>>>>>>>> a document specific thread, e.g., >>>>>>>> "Subject: >>>>>>>>> intended status of revised-datastore". >>>>>>>>> >>>>>>>>> I am actually raising this point since November meeting. >>>>>>>>> There are >>>>>>>> different >>>>>>>>> threads where I explained why it is appropriate as Informational. >>>>>>>>> The last thread I remember is at: >>>>>>>>> >> https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH1 >>>>>>>>> 1xcY >>>>>>>>> The recent position of NETCONF co-chairs is in >>>>>>>>> >> https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd >>>>>>>>> 8qr5k >>>>>>>>> >>>>>>>>> Thank you for your consideration. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Mehmet >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>>> Sent: Wednesday, March 8, 2017 11:28 PM >>>>>>>>>> To: Mehmet Ersue ; 'Kent Watsen' >>>>>>>>>> ; netmod@ietf.org >>>>>>>>>> Subject: Re: [netmod] draft netmod charter update proposal >>>>>>>>>> >>>>>>>>>> Hi Mehmet, >>>>>>>>>> >>>>>>>>>> On 3/8/2017 4:47 PM, Mehmet Ersue wrote: >>>>>>>>>>> Kent, >>>>>>>>>>> >>>>>>>>>>>> we understand that this is how NETCONF charters are >>>>>>>>>>>> structured, but it is not our practice, >>>>>>>>>>> AFAIK it was the NETMOD practice for the charters until today. >>>>>>>>>> The charters from the last couple of years don't have the >>>>>>>>>> intended status -- at least the ones we checked. >>>>>>>>>> >>>>>>>>>> I actually feel pretty strongly about this (which of course >>>>>>>>>> can be easily overruled by our AD). It's my experience that >>>>>>>>>> premature discussions on intended status, i.e., before a >>>>>>>>>> document is sufficiently mature, leads to process-focused >>>>>>>>>> arguments that detracts >>>>>>>> from >>>>>>>>> making technical progress. >>>>>>>>>> While once a document is mature and core direction/content >>>>>>>>>> is fixed, it is generally obvious what status is appropriate. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I did not ask >>>>>>>>>>> more than written in the current charter. >>>>>>>>>>> It would be good to bring the high-level topics in relation >>>>>>>>>>> to the WG >>>>>>>>> items. >>>>>>>>>> I'm sorry, I don't understand this last sentence can you >> rephrase >>> it? >>>>>>>>>>>> as the information is available at the top of each draft, >>>>>>>>>>>> and also because >>>>>>>>>> this information need not be fixed when the milestone is added. >>>>>>>>>> >>>>>>>>>>> I believe a WG charter should be self-sufficient covering >>>>>>>>>>> the target definition and intended status of the WG items. >>>>>>>>>>> Otherwise one can change the target for a WG item by simply >>>>>>>>>>> editing the draft abstract anytime. >>>>>>>>>> Per IETF process, all it ever takes to make a change in >>>>>>>>>> document status is WG consensus, and then IESG and IETF >>>>>>>>>> buy-in as part of the >>>>>>>>> publication process. >>>>>>>>>>> BTW: We agreed in diverse discussions that the DS concept >>>>>>>>>>> is Informational in nature. >>>>>>>>>>> I think this should be corrected in the draft. >>>>>>>>>> So this sounds like an objection to a specific document. >>>>>>>>>> This is a fair point to raise, but in our opinion it is not >>>>>>>>>> a charter impacting point or discussion. If this is in fact >>>>>>>>>> the issue you'd like to raise and discuss, lets do so under >>>>>>>>>> a document specific thread, e.g., >>>>>>>> "Subject: >>>>>>>>>> intended status of revised-datastore". >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Lou >>>>>>>>>> >>>>>>>>>>> Mehmet >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf >> Of >>>>> Kent >>>>>>>>>>>> Watsen >>>>>>>>>>>> Sent: Wednesday, March 8, 2017 7:45 PM >>>>>>>>>>>> To: netmod@ietf.org >>>>>>>>>>>> Cc: netmod-chairs@ietf.org >>>>>>>>>>>> Subject: Re: [netmod] draft netmod charter update proposal >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi NETMOD WG, >>>>>>>>>>>> >>>>>>>>>>>> Please find below draft-4 having the following change: >>>>>>>>>>>> >>>>>>>>>>>> - added "(e.g., I2RS, RTGWG)" to a sentence. >>>>>>>>>>>> >>>>>>>>>>>> Hi Sue, Lou and I looked at the proposed charter and found >>>>>>>>>>>> a sentence that nicely describes our WG's intent to work >>>>>>>>>>>> with and support other WGs (beyond NETCONF), but we felt >>>>>>>>>>>> that >>> the >>>>>>>>>>>> text could be made more clear by adding in the >>>>>>>>>>>> above-mentioned >>>>> change. >>>>>>>>>>>> Beyond this, and the existing a), >>>>>>>>>>> b), >>>>>>>>>>>> and c), we believe that the charter proposal covers our >>>>>>>>>>>> support for I2RS, >>>>>>>>>>> do >>>>>>>>>>>> you agree? >>>>>>>>>>>> >>>>>>>>>>>> Hi Mehmet, regarding putting a short description and the >>>>>>>>>>>> intended status >>>>>>>>>>> for >>>>>>>>>>>> each draft into the charter, we understand that this is >>>>>>>>>>>> how NETCONF >>>>>>>>>>> charters >>>>>>>>>>>> are structured, but it is not our practice, as the >>>>>>>>>>>> information is >>>>>>>>>>> available at the >>>>>>>>>>>> top of each draft, and also because this information need >>>>>>>>>>>> not be fixed >>>>>>>>>>> when >>>>>>>>>>>> the milestone is added. >>>>>>>>>>>> >>>>>>>>>>>> All, Any other comments? >>>>>>>>>>>> >>>>>>>>>>>> Kent >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Network Modeling (NETMOD) >>>>>>>>>>>> ------------------------- >>>>>>>>>>>> >>>>>>>>>>>> Charter >>>>>>>>>>>> >>>>>>>>>>>> Current Status: Active >>>>>>>>>>>> >>>>>>>>>>>> Chairs: >>>>>>>>>>>> Lou Berger >>>>>>>>>>>> Kent Watsen >>>>>>>>>>>> >>>>>>>>>>>> Operations and Management Area Directors: >>>>>>>>>>>> Benoit Claise >>>>>>>>>>>> Joel Jaeggli >>>>>>>>>>>> >>>>>>>>>>>> Operations and Management Area Advisor: >>>>>>>>>>>> Benoit Claise >>>>>>>>>>>> >>>>>>>>>>>> Secretary: >>>>>>>>>>>> Zitao (Michael) Wang >>>>>>>>>>>> >>>>>>>>>>>> Mailing Lists: >>>>>>>>>>>> General Discussion: netmod@ietf.org >>>>>>>>>>>> To Subscribe: >>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>>>>>> Archive: >>>>>>>> https://mailarchive.ietf.org/arch/browse/netmod/ >>>>>>>>>>>> Description of Working Group: >>>>>>>>>>>> >>>>>>>>>>>> The Network Modeling (NETMOD) working group is >>>>>>>>>>>> responsible for the YANG >>>>>>>>>>>> data modeling language, and guidelines for developing >>>>>>>>>>>> YANG >>>>>>> models. >>>>>>>>>> The >>>>>>>>>>>> NETMOD working group addresses general topics related >>>>>>>>>>>> to the use of >>>>>>>>>> the >>>>>>>>>>>> YANG language and YANG models, for example, the >> mapping >>>>>>>>>>>> of >>>>>>> YANG >>>>>>>>>>>> modeled >>>>>>>>>>>> data into various encodings. Finally, the NETMOD >>>>>>>>>>>> working >>>> group >>>>>>>>>>>> also defines core YANG models used as basic YANG >>>>>>>>>>>> building blocks, >>>>>>>>> and >>>>>>>>>>>> YANG models that do not otherwise fall under the >>>>>>>>>>>> charter of any >>>>>>>> other >>>>>>>>>>>> IETF working group. >>>>>>>>>>>> >>>>>>>>>>>> The NETMOD WG is responsible for: >>>>>>>>>>>> >>>>>>>>>>>> a) Maintaining the data modeling language YANG. This >>>>>>>>>>>> effort >>>>>>>> entails >>>>>>>>>>>> periodically updating the specification to address >>>>>>>>>>>> new >>>>>>>> requirements >>>>>>>>>>>> as they arise. >>>>>>>>>>>> >>>>>>>>>>>> b) Maintaining the guidelines for developing YANG models. >>>>>>>>>>>> This >>>>>>>> effort >>>>>>>>>>>> is primarily driven by updates made to the YANG >>> specification. >>>>>>>>>>>> c) Maintaining a conceptual framework in which YANG >>>>>>>>>>>> models are >>>>>>>>> used. >>>>>>>>>>>> This effort entails describing the generic context >>>>>>>>>>>> that in >>>>>> YANG >>>>>>>>>>>> exists and how certain YANG statements interact in >>>>>>>>>>>> that >>>>>>>> context. >>>>>>>>>>>> An example of this is YANG's relationship with >> datastores. >>>>>>>>>>>> d) Maintaining encodings for YANG modeled data. This >>>>>>>>>>>> effort >>>>>>>> entails >>>>>>>>>>>> updating encodings already defined by the NETMOD >>>>>>>>>>>> working (XML >>>>>>>>> and >>>>>>>>>>>> JSON) to accommodate changes to the YANG >>>>>>>>>>>> specification, and >>>>>>>>>> defining >>>>>>>>>>>> new encodings that are needed, and yet do not fall >>>>>>>>>>>> under the >>>>>>>> charter >>>>>>>>>>>> of any other active IETF working group. >>>>>>>>>>>> >>>>>>>>>>>> e) Maintaining YANG models used as basic YANG building >>>> blocks. >>>>>>>> This >>>>>>>>>>>> effort entails updating existing YANG models >>>>>>>>>>>> (ietf-yang-types >>>>>>>> and >>>>>>>>>>>> ietf-inet-types) as needed, as well as defining >>>>>>>>>>>> additional core >>>>>>>> YANG >>>>>>>>>>>> data models when necessary. >>>>>>>>>>>> >>>>>>>>>>>> f) Defining and maintaining YANG models that do not >>>>>>>>>>>> fall under >>>>>> the >>>>>>>>>>>> charter of any other active IETF working group. >>>>>>>>>>>> >>>>>>>>>>>> The NETMOD working group consults with the NETCONF >>>> working >>>>>>>>> group >>>>>>>>>> to >>>>>>>>>>>> ensure that new requirements are understood and can be >>>>>>>>>>>> met by >>>>>>> the >>>>>>>>>>>> protocols (e.g., NETCONF and RESTCONF) developed within >>>>>>>>>>>> that >>>>>>>>> working >>>>>>>>>>>> group. The NETMOD working group coordinates with other >>>>>>>>>>>> working >>>>>>>>>> groups >>>>>>>>>>>> (e.g., I2RS, RTGWG) on possible extensions to YANG to >>>>>>>>>>>> address >>>>> new >>>>>>>>>>>> modeling requirements and, when needed, which group >>>>>>>>>>>> will run >>>>> the >>>>>>>>>>>> process on a specific model. >>>>>>>>>>>> >>>>>>>>>>>> The NETMOD working group does not serve as a review >>>>>>>>>>>> team for >>>>>>>>> YANG >>>>>>>>>>>> modules developed by other working groups. Instead, the >>>>>>>>>>>> YANG >>>>>>>>>> doctors, >>>>>>>>>>>> as organized by the OPS area director responsible for >> network >>>>>>>>>>>> management, will act as advisors for other working >>>>>>>>>>>> groups and >>>>>>>> provide >>>>>>>>>>>> YANG reviews for the OPS area directors. >>>>>>>>>>>> >>>>>>>>>>>> Milestones: >>>>>>>>>>>> >>>>>>>>>>>> Done - Submit draft-ietf-netmod-rfc6087bis to IESG for >>>>>>>> publication >>>>>>>>>>>> Mar 2017 - Submit >>>>>>>>>>>> draft-ietf-netmod-yang-model-classification >>>>>>>>>>>> to >>>>>>>> IESG >>>>>>>>>>>> for publication >>>>>>>>>>>> Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG >>>>>>>>>>>> for >>>>>>>> publication >>>>>>>>>>>> Apr 2017 - Submit draft-ietf-netmod-entity to IESG for >>>>>> publication >>>>>>>>>>>> Apr 2017 - Submit draft-ietf-netmod-syslog-model to >>>>>>>>>>>> IESG for >>>>>>>>>>> publication >>>>>>>>>>>> Oct 2017 - Submit draft-ietf-netmod-schema-mount to >>>>>>>>>>>> IESG for >>>>>>>>>>> publication >>>>>>>>>>>> Oct 2017 - Submit draft-ietf-netmod-revised-datastores >>>>>>>>>>>> to IESG >>>>>> for >>>>>>>>>>>> publication >>>>>>>>>>>> Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to >>>>>>>>>>>> IESG >> for >>>>>>>>>>>> publication >>>>>>>>>>>> Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang >>>>>>>>>>>> to IESG >>>>>> for >>>>>>>>>>>> publication >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 Mon Mar 27 19:21:22 2017 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 1B59312985B for ; Mon, 27 Mar 2017 19:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 m4Bz_4WXTrjP for ; Mon, 27 Mar 2017 19:21:15 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733EB1296D1 for ; Mon, 27 Mar 2017 19:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=439; q=dns/txt; s=iport; t=1490667675; x=1491877275; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=iQdmsB1JRs/tyZSB2upPELpAq84rJjqKbChy5xL5pEQ=; b=PCXjAfwDe3/4m8sqjpZMkxHuac5ElFmQ8/3yUfcNbMzmDV3Yjd5Pht2d hJ2GInCkyF2ETJ9mKav1fDJSCkTsac2mUQU1FxyMVclIUWdqkJsly4M+U mswyTlfohkPUaZlHRhBQcaYU+FnngpHMKtWy3xTej/htjwt5sXnDzXKnP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAwDrx9lY/5JdJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1RhgQuDYooPkjeSVYIPgg4niRs/GAECAQEBAQEBAWsohT8VdgImAl8NCAE?= =?us-ascii?q?BigMOm3+QBoImik8BAQEBBgEBAQEfBYELhUOCBYUnWoRDgl8FkGCLe4FThSiLU?= =?us-ascii?q?YFkAYh1hleLT4gWHziBBCQWCBcVhzciNQEBAQGJaQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,234,1486425600"; d="scan'208";a="403227298" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 02:21:14 +0000 Received: from [10.82.212.25] (rtp-vpn4-1049.cisco.com [10.82.212.25]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v2S2LEab004822 for ; Tue, 28 Mar 2017 02:21:14 GMT To: NETMOD Working Group From: Benoit Claise Message-ID: Date: Mon, 27 Mar 2017 21:21:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Progressing the new NETMOD charter X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 02:21:17 -0000 Dear all, Thanks for the NETMOD chartering discussion. I took ownership of the new charter text, which is now at https://datatracker.ietf.org/doc/charter-ietf-netmod/, and I will progress it. https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-netmod%2Fwithmilestones-08.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-netmod%2Fwithmilestones-08-00.txt Regards, Benoit From nobody Tue Mar 28 05:12:04 2017 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 D358D1294C3 for ; Tue, 28 Mar 2017 05:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 kAcH5vfo29QR for ; Tue, 28 Mar 2017 05:11:59 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0110.outbound.protection.outlook.com [104.47.1.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DFC129582 for ; Tue, 28 Mar 2017 05:11:59 -0700 (PDT) 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; bh=MIbLFdHrLxfFLENZHkY00K3XFrV+oyeTQzcirS0xIlE=; b=IbjczOwXONtFVP7ccZxttywoQUBjDybxiExcxNhVBfErKTMhftE09hcDOd/b5fFwEXEYMgwAaFnvAAPwc37RCGhnxXoI8idmZ0Fjj62cZh/8W3AcboS3V2qa34OaGvuuOsG0mhuLIoaLd+7s835byJY0k/GWPxGXLOToBvMUB5w= Authentication-Results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by DB6PR0701MB2999.eurprd07.prod.outlook.com (10.168.84.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Tue, 28 Mar 2017 12:11:55 +0000 Message-ID: <030f01d2a7bc$3f539c20$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , Martin Bjorklund CC: References: <30B9FE1D-D8E8-4255-847B-DBAD1AA6E73D@juniper.net> <146c5483-6e6d-a581-781b-bf5351b1df68@cisco.com> <20170324.144408.1191664098390131544.mbj@tail-f.com> Date: Tue, 28 Mar 2017 13:04:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: DB6PR0301CA0039.eurprd03.prod.outlook.com (10.168.49.49) To DB6PR0701MB2999.eurprd07.prod.outlook.com (10.168.84.137) X-MS-Office365-Filtering-Correlation-Id: 74688a00-dea3-46fc-acb9-08d475d3a0f6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423060)(201703031133066); SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 3:M+mNm7WZMLA1zwf1ec9C7MzD04UtpiBS3ejM66jUztOzIR1Mz2PdIeeHmbW0lbWrcZxY6PDni7hU+o+6RFkVBoITPR35GOSAg5z5TIIBRunycPsZd+sHtwzpK3cjkw44MDCc2lzBr0PR7vDY2YgeVyy9VcB8zT/bUNrN1O1bLFeZo3Q7/VbHKWz6dmsVWMFLy+Taq/PShbchlii6W9tyDBmj/2VI1Umxvj9jxuDrGQ5pJhbf/nqp5JLMigo/+Qcw1/7VtOi3kzKMCjtbRU5Z4HO/55Jtrowm64n9DgK9Jn4DLm2kPWuhp00Yru2ynhaHlsG1gMBCi0/TbjWNBdMWyg==; 25:PyIOEj8CuhYHz7VXHNaIaetaXacUzQGgYjOWUfv6eFetX+jI/3DtFjnGkiZxARt0MT609DkFmciatj90ufZg+4ZiK4Pcg5XmF9PqbZro9xU/zD9G78IeLkJXSs81QSEMsRn21TR55ZtMYcH2KK5f0ADwCYSuaHrUFKNYjEHjE0NQvxPPPVl0Oq2n27RTJrLnX0IccZ80AjIeM1JqeQpkdgPICzcZcC6Z7Y2UQfPN6W28B/c/yP0y62dVpkL0GdhOCHK66wFD+J7whIDO68ulsCaUiks/8eFPPsCoNZt6wZa5jqMfHb7eQczl1cV5//rOZ9Ntai87W/QgS2O0DxiD394gjVB34lQH+h5lb0/EMQnsyhc/ZEWr4dHIgWLkpFZlTXoMSc8RU6L+o6QT/pkTQBXN6E49cnynHNJe7kIeaHtD3U6v2Inc2Xq8q5zV7Trhy8jBW8zODhnUm/rJYhrH2g== X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 31:Mlbl/5JIVLWJj53x37yLRHT2rbq5yQhPcng6chVttTlU679wCn8JdlIvVJFK9k5dkam2ZK0xspjzgi2vM+WayLaDg1pnHLpZnrZ6CyTi5oToY1nvvPSDf9W+IOtNbThgMOIcjNLJ4S3WrEWR+8sVSMXeNEf4D3czqaQ7m9BFM0CvhaE94+lNhAfWZRummk6teXXO7YuX86Ebx21PVr1AfsLkAhRzthKUFcl9xAF4wY2AMH0kFyu3NizjDjwhmnPdLjB1rfj76oAsfnGCAk8BPA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040435)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123562025)(20161123560025)(20161123555025)(201703131423060)(201702281528060)(201703061421060)(201703061406060)(20161123564025)(6072148); SRVR:DB6PR0701MB2999; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 4:U9lkfpf67fHpIlwv33FVYDhbiCDsy1JBn+YLHjlxGuiXPprlQ8DzxjKhfXSSbaU2+/5DPrSoly4w4EFTqHc1C81xziNLATz9mFOCu4A0gfycciA5rhNeg6/215oTI/jeUKSlP3YcIhPZ2qbbtyaB0P82Ph7EpllyZ9lIyAuaYT/sEdSiJFQGKtzm6jtZYmkP1Y5I/YtHJuiQ4juVC19yQK2DsMujXDxcsHZPmZBS8THJJV9fMaJAaj07NdlhDKURINhpe97+niuEfEfxOF9rnUXcFBc8o7zG7ZPBfDcr8sALVC0LPN8cxLLmOebYEo1ofRHmdoddNpi+010PxD0jYjyLl+pMrqG7mJdC8FWYoa/ytAorse+7f5NCMp5kOIAOCqLRU9duqiEM9eQJ7QQebHcjwgCC1BQXedaOohkRpdyj7a9smScvqPsFcF5HFRNugvNnyG3lVfP0FRWPxNIu1ivD7GQb/hb4f67ElmzMkQNcrUc32+jDBNnRO9HVLuHKBJqBrv7DtsdiaDro/aqWUdE/8hs++Hm90NsLUWVYMIWa7u1Fh3jucuTretm/GxR3AFNJeAYOrad0hI5BYBvWeN4Cad/PxPocEHalA8eUKyaOHcUoBrIYJfPFUture+NoHMqtdJUX0LvjlO9f6toEUwQip6rAb8hClLyWonlBrCcGxAeu0TzEE5OqrKpvtc3qju4TrE5KYeC4N9pjkM4sS91xuG3ZFhs/4uZySqzxTtWucz5YQahvEg5X4PzPuFnL3wSKDr6JIBJOH5JDW3OY7/uxeh9v9EOwzk5oNgbI778= X-Forefront-PRVS: 0260457E99 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39450400003)(39400400002)(39840400002)(39410400002)(39860400002)(39850400002)(24454002)(5423002)(13464003)(377454003)(66066001)(8676002)(38730400002)(6246003)(230700001)(14496001)(3846002)(6116002)(23676002)(189998001)(5660300001)(81166006)(50226002)(6496005)(53936002)(7736002)(305945005)(6486002)(229853002)(81816999)(25786009)(81686999)(44736005)(9686003)(53546009)(61296003)(86362001)(2906002)(4326008)(50986999)(76176999)(42186005)(6666003)(4720700003)(230783001)(50466002)(47776003)(62236002)(44716002)(6306002)(33646002)(5820100001)(74416001)(7726001)(222073002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2999; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjI5OTk7MjM6WVJ6R3dENDJLNlpnUXk2VGVKQTd4Q1RI?= =?utf-8?B?bGI0ajVUcThFeW9zMDNXa3RPdTBRaHJ3WWRiNHBNZWdGK0VDNkZWcnBBejly?= =?utf-8?B?Rzl5OC9OMjlyR2JKNVF1MGhJWU0rVHJzWmZDK3RSUzQzMTdxYmxiWkwyMFR3?= =?utf-8?B?WGh3aEx6aHovMjVCNXFWejRpeU5IUWFkNS9DTEtyK3p1aTlieTNaNXJQWFgx?= =?utf-8?B?ZXRxU3BXbEwzVi85UGp1WnprRVBhVFZodVRqNmZMaVYvWGlHQ1RGUGJtbnNy?= =?utf-8?B?cExjanZpdXdUZ3RJQ1FNYjgzeVZaZC8rNW9hdWNsNG5HeEc3M0FydlRKSzVR?= =?utf-8?B?N3dWT0d1Sm1odDlOcnBlWmlySDBjMU9uSlkrL1lPL011T1pYUkZLd29sRzc3?= =?utf-8?B?ZDVIczhxZHpIZDY0M0hBSzd6VkVzaGVuUTVDT2hLc2tTMGtqYUwvZExLcnNx?= =?utf-8?B?WVJ3TjdwWStKcjRSUUVkRHltaG1MSE1icWIzbUw3ajlpL2ljSjVCek9adXk2?= =?utf-8?B?NXNvU1VmU1kyZ0YvSzJ0S0FMb05rWXVva3U0Qy9yNVBpeUhvTnMrVjFFV3Nw?= =?utf-8?B?eTdTcnBqbHlieVpqRG5mZzRKTEFSZnlkWFZ1Vmk5U3lsNXBWTUk3aG5SRHdM?= =?utf-8?B?R0RDbFY2UVd0ZXZXS3FKVFpPMEUvYlovWm9HejlKK0lrVk1jMWpROWFwcVBw?= =?utf-8?B?Tjg4YmdRQmlFNEpQM2syN0p4SXgzZFhCT2NFQTFabjZ0N1ZyVEdmeDZWbkpB?= =?utf-8?B?akdJdEsxemo0eDc0eDRkNVFWaUMyRnZYRWtYc3BaZzUxWjVsaFJ5ekJCTFMx?= =?utf-8?B?cUxXcUNhejhqS1R4YitadHZnM2JSbXlsN1M3a0NIOEJLOTR4UHJuUy9pSW55?= =?utf-8?B?SGlHemRHS1NwSWViM241QkpPRlhPQWIzL1RTNTZJSU40bXcvRmdJUC9IK24r?= =?utf-8?B?c2twK3h6UURGMWh5aVV4SmhIYXp3OXIrUVNuN0o1RHQyditYODJMUlh2Rk9F?= =?utf-8?B?ZGdwekdySEZlMnBLTlRuYW5ZeFRXR1pkR1NTUXVuWUc2a2VIVWJnZXh5VkE3?= =?utf-8?B?Y0NsY0FwbkV3cFQ5S092SG14RHlvOEhja1dLWDkzQ0Z1eGM5ajhZMUNVcjhq?= =?utf-8?B?MWJQZm1xUzZuSnBGL2dwWDlaVTlQU0tmNXFiUHRXOXNFU2pGYytLSXRRUDFL?= =?utf-8?B?S0RldUF1T3NwUEJLUlgwY08zKzZ1SFAweW52VDRYblFVRm9QZDh3MFNjam5D?= =?utf-8?B?RGxZLzVTd1hXN2Q3NkNaaUpaSS9tcVRmWElDMEtTdWsyaXdreE1HcVo3T1l4?= =?utf-8?B?bzlhWnMwK2thYTFablhHWlpIQjA0NHVYWVljanFVTlNYVm5SdE9JZGprMmk3?= =?utf-8?B?TXNBZWFVb2hlaXF0UVM5NjdKZEs1UHBPL1RZZUVhZ0NxdGd0Vm9FRG9adkli?= =?utf-8?B?TjJaNjdjeTN4ci9DQ2tZSjc1QjhVZ1Ayb21DOE1BUngxK21aeWpCTFV5WFUw?= =?utf-8?B?c0lMTGRIZHlMVmx6eTdmZTBTUk1sd3d6NW1OeldPV0U2N0thNWM4WWhuaUV6?= =?utf-8?B?MlovWXlzcUdOMzFyUkpoaTVFM0hBQ3FHSlpvTGZKRjhCTGRSbVJmOHJvMW10?= =?utf-8?B?WDZiVWpwRUdnNERlM0p2anJURmhSanQ4YU01QnFvQTRoTk5GSzY1bzZBZHdo?= =?utf-8?B?R3BvRCsvZy83SGUxTGxadGg1alV5diszalI5azhIVDRTMGNLQmhSL29QSDBU?= =?utf-8?B?SmlnTFhxUTFHNnFMSExuWlhVaE45NlRnSnFpbTlSb0tmbVdBb3hlcHV6Z0FQ?= =?utf-8?B?OFhnakI5NDRJcU1JSmNyQXZodTE0bTI2U3lsQ3h6M24xWFVPSDlyc1Q0a2xW?= =?utf-8?Q?iY+hVtPuzF9vc=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 6:N+C2erLEHWrdHvBmlUlF2BKIgxyk5nNetwjTb1gMe9JB8F721w6/qXpQ8/3G28It6nE/Q9tTZTqkxwvIp7lUAkl/2oIgUtiPJkgeEkRlMwjI6T+QN8p44LTpPtXkQdC3y0jEAiv5oMd59FgKZ2aB+eM41t3hn11MmRRM8f83ILfgivMPEQBf8X2tBAkAd7cGbzUS0cPPuRcStWQSwCa5i00KB405I3vO1Myg673s0JX0wj6yudqErgM5zcPQUE4Arb2YQx9rjCOgHx/3Rbw2D6DzpOn6l9XuUCHFaDrYWhGYa3EBvTXLXmTCYyFmVVU9M54rCn7qJMQJXtJQ6pdQNLlWktU3uGd61uA7lFrxxNpnYKOgXeQgNRiutq2Dyz/hNx7U5rmB95WGwxXHmWW2Lw==; 5:+9JY/l2ChswU/myMRru0FX5re84i65WC6e6H69btMl9DvlO5JKh4x7azqNgdUxZEcJUWm0+T6r+OTjXWxQZJ0+R+6q3W11Z3T3lq2/4mhCfUyFFI+DFEdTayonJkC4Bep8MWUf0Dl27M0BEk8ETo2A==; 24:6nqSnNbOJWQfj6ImH8hMa9W5Qu4qyI/OpDXt0f+KFPGidDMgyT3GapdEQjxJQBFqZ2LTch+DK2wRA3I132We2Pt3VUjiBtiwJTT5117yu0Y= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 7:hpqcZ0zHRawkeFlfn9nTg5InTS+E2SdbnZYnwRQcFrnCTpvDMmR7UFPi3+YdK1r5hL/a46mdqM5orSC31oScpsZA3ZKBEhjownb4mk4VDeIG5/uD0mnAI6WkIcQG9ytsBWW/5BGiT/qEowLibTQKNS83K0FPoa7LbMiFrAI4ZgtlUA7GJsa05xmfe247hHQ5xtfZFEfyFkEl4ZxsFnqnu+UapcYVjv5ihmjeomM6fbNuC+dp0SR4EMTFKQq7mJHqrQsZZKiAJ7kpnKOwAF84mYZkNB3Pk5LNsyjq1lvCmGnpX59QWa8yKhLy8k6z577D/foMnhVejr0+DLuiySuk6A== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2017 12:11:55.4053 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2999 Archived-At: Subject: Re: [netmod] file "ietf-foo@2016-03-20.yang" or file "ietf-foo.yang" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 12:12:03 -0000 ----- Original Message ----- From: "Andy Bierman" Sent: Friday, March 24, 2017 6:07 PM > On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund wrote: > > > Robert Wilton wrote: > > > On 24/03/2017 08:09, Benoit Claise wrote: > > > > On 3/24/2017 2:32 AM, Kent Watsen wrote: > > > >> > > > >> Section 4.2 of rfc6187bis says: > > > >> > > > >> The "" tag SHOULD be followed by a string > > > >> identifying the file name specified in Section 5.2 of > > > >> [RFC7950]. > > > >> > > > >> While Section 5.2 of RFC7950 says: > > > >> > > > >> The name of the file SHOULD be of the form: > > > >> module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' > > ) > > > >> > > > >> "module-or-submodule-name" is the name of the module or > > > >> submodule, and the optional "revision-date" is the latest > > > >> revision of the module or submodule, as defined by the > > > >> "revision" statement (Section 7.1.9). > > > >> > > > >> While the SHOULD statements provide a recommendation, the > > > >> square-brackets "[]" impart no bias, and the text is ambiguous. > > > >> That is, is the revision-date optional *only* because the > > > >> revision statement is optional within the module? What is > > > >> the recommendation for when the revision statement is present? > > > >> The RFC7950 text isn't clear. > > > >> > > > >> My opinion is that RFC7950 errata should state that the file > > > >> name SHOULD include the revision-date when the revision > > > >> statement appears within the module. > > > > That makes sense. > > > > Any other views? > > > > > > I don't feel strongly, but would it make more sense if instead > > > rfc6187bis stated that the file name SHOULD include the revision date? > > > I.e. 7950 states what the filename is allowed to look like and 6187bis > > > states what they should look like for IETF produced models. > > > > +1 > > This is fine, but this there is a larger goal of library consistency that is > impacted by this guideline. (such as the github/YangModels/yang repo. > > 1) changing the filename for each revision is not git-friendly > (if one wants to track changes over releases) > > 2) many revisions are actually obsolete work-in-progress > so keeping every old file around will grow into a problem > > 3) almost every import is import-without-revision so compiling the > old obsolete modules quickly breaks as the new work-in-progress version > makes incompatible changes. Andy In a quick trawl of 277 recently published IETF I-Ds with YANG modules in them, I found 16 using import with revision. Almost every? Well, nearly all. Tom Petch > However, import-by-revision breaks if you only keep the latest revision > around, > so these problems have to be managed by the YANG librarians ;-) > > > > > > > /martin > > > > > Andy > > > > _______________________________________________ > > 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 Tue Mar 28 06:59:13 2017 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 40D3D1293FB; Tue, 28 Mar 2017 06:59:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: netmod-chairs@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149070955216.30562.13909945162900610745.idtracker@ietfa.amsl.com> Date: Tue, 28 Mar 2017 06:59:12 -0700 Archived-At: Subject: [netmod] Spencer Dawkins' No Objection on charter-ietf-netmod-08-01: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 13:59:12 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-netmod-08-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netmod/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This revised charter changes a lot of text, so I'm glad it's going for external review, but it seems clear to me. I did wonder why the link to http://www.ietf.org/iesg/directorate/yang-doctors.html was removed. Was this not found to be useful in the current charter, or is there a policy about URLs in charters that I should know about? From nobody Tue Mar 28 08:04:20 2017 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 ABAC312942F; Tue, 28 Mar 2017 08:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 akIXbJDZWV-7; Tue, 28 Mar 2017 08:04:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732CD1294CD; Tue, 28 Mar 2017 08:04:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDR53755; Tue, 28 Mar 2017 15:04:08 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 28 Mar 2017 16:04:07 +0100 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.8]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 28 Mar 2017 23:03:56 +0800 From: "Zhengguangying (Walker)" To: Martin Bjorklund CC: "netmod@ietf.org" , "netconf@ietf.org" Thread-Topic: comments to draft-ietf-netmod-revised-datastores-01 on the IETF98 meeting Thread-Index: AdKn02//shqdO5PWQjmTW/vx0wluPA== Date: Tue, 28 Mar 2017 15:03:55 +0000 Message-ID: <381D7D55085B1E4D8B581BD652E1E140B2A565F5@nkgeml513-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.148] Content-Type: multipart/alternative; boundary="_000_381D7D55085B1E4D8B581BD652E1E140B2A565F5nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.58DA7B68.011D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bb6c7db6eeb2b84beb782f62e1f5fc9a Archived-At: Subject: [netmod] comments to draft-ietf-netmod-revised-datastores-01 on the IETF98 meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:04:14 -0000 --_000_381D7D55085B1E4D8B581BD652E1E140B2A565F5nkgeml513mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTWFydGluLA0KDQoNCg0KICAgICAgTXkgY29tbWVudHMgaXMgd2h5IGl0IG5lZWQgWUFORyBt b2R1bGVzIGNoYW5nZSB0aGVyZSBkZWZpbml0aW9uPyAgZGF0YXN0b3JlIGlzIHRoZSBjb25jZXB0 aW9uIG9mIHN5c3RlbSBkYXRhc3RvcmUgbWVjaGluaXNtLCAgd2UgY2FuIHVzZSBmaWx0ZXIgb3Ig Y29tbW9uIHRvcCBsZXZlbCBZQU5HIG1vZHVsIHRvIHN1cHBvcnQgbXVsdGkgZGF0YXN0b3JlLg0K DQogICAgIEJ1dCwgaWYgYXNrIFlBTkcgbW9kdWxlcyB0byBjaGFuZ2UgdGhlaXIgZGVmaW5pdGlv biB0byB1c2Ugc3BsaXQgdHJlZSwgaXQgd2lsbCBib3VuZCB0aGUgZGF0YXN0b3JlIGxvZ2ljIHRv IFlBTkcgbW9kdWxlcywgaXQgbm90IGxvb2tzIGxpa2UgYSBnb29kIGlkZWEsICBiZWNhdXNlIGFs bCBZQU5HIG1vZHVsZXMgc2hvdWxkIGNoYW5nZSBhbmQga25vdyB0aGUgZGF0YXN0b3JlLg0KDQoN Cg0KICAgICBTbywgbXkgc3VnZ2VzdGlvbiBpcyBub3Qgc3VlIHNwbGl0IHRyZWUgaW4gWUFORyBt b2R1bGVzLCBidXQgc3VwcG9ydCBpdCBieSBuZXRjb25mIG9yIGFub3RoZXIgbmV3IFRPUCBsZXZl bCBZQU5HIG1vZHVsZS4NCg0KDQoNClRoYW5rcw0KDQoNCg0KWmhlbmcgZ3Vhbmd5aW5nICh3YWxr ZXIpICBGcm9tIEh1YXdlaQ0K --_000_381D7D55085B1E4D8B581BD652E1E140B2A565F5nkgeml513mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Martin,

 

      My comments is why it need YANG modules c= hange there definition?  datastore is the conception of system datasto= re mechinism,  we can use filter or common top level YANG modul to sup= port multi datastore.

     But, if ask YANG modules to change their defini= tion to use split tree, it will bound the datastore logic to YANG modules, = it not looks like a good idea,  because all YANG modules should change= and know the datastore.

 

     So, my suggestion is not sue split tree in YANG= modules, but support it by netconf or another new TOP level YANG module.

 

Thanks

 

Zheng guangying (walker)  From Huawei

--_000_381D7D55085B1E4D8B581BD652E1E140B2A565F5nkgeml513mbschi_-- From nobody Tue Mar 28 08:30:15 2017 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 581431289C3; Tue, 28 Mar 2017 08:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQsq9sUhFLJp; Tue, 28 Mar 2017 08:30:05 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2F6126FB3; Tue, 28 Mar 2017 08:30:05 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id 81so61444153pgh.2; Tue, 28 Mar 2017 08:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=a/gJor9KZHEeZCtM4GEbqWe17uWuL4QM2Fir1qpRTFY=; b=cLDrdiuEFcjC/zX4xQYOP8tudKAK3WhCi98ep4Zki671g6vzQ3n/0AO8hosKtBcLNC ITa6W7cXYWIX5uLwgu5pgVT3a+OKLrk/hv/CR0F2sXiOA3GyiLMuBZjj099NSiOMcXh2 2GOzqJCJw4NcefgTbtiV42FEHMu8T8ePnL0hw59AWvDZt5gmYaktOJ4KXqEmwaAp3Mkr kvQcBnTnVh/7CiQCRduj/HhEMe2cZY+Edd3wtMM+54ExsOsyHySWjmoBtUY+cfDF4NDI i0K3FHPQekDpNLfrp7cATkUqJK3MeXyU5OeeV0TPu3JZa2ihL/luNnieQSk8xLhUF0pg mZxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=a/gJor9KZHEeZCtM4GEbqWe17uWuL4QM2Fir1qpRTFY=; b=Oo6Gu0Q0qvA2Lq8FogbeCnA58+p2Bt4ODOxHyFE4YIhvnU2qggfxJH3G3H/ULbcC8b TLy7LQogKE1dKW/X8Qm1vGt0D1/38qwAAyOkAdEMpP+pWEmi3crHkhypTqtFLP8uhALM ZnFcQa0OUepKbYHxHSPFzsF2+HpAFZX2rFZDIAN84UY3GwxtXZK+D2Fn0vv5KzPcIIYd m1LxBsL91LXqJuUNYKkeNbdKTZl1KMhQfKaMO4NlUF5ScpHhrIrdJl+fI9hzNgAZ7M4C V+oyvA5weA4QlbLvaehphwGZLlz+faXy/5lDVV4zvOQipl0cdRsibSE85nQoUo4hPJMt rBmw== X-Gm-Message-State: AFeK/H3FSk9hIypHG+xyrISdfcFiQTtvAUEK9XuuWvgL+fYi4ZOqgmGnTmfSbT79BDmp+g== X-Received: by 10.84.211.130 with SMTP id c2mr37708774pli.82.1490715005309; Tue, 28 Mar 2017 08:30:05 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1008::47a? ([2001:420:c0c8:1008::47a]) by smtp.gmail.com with ESMTPSA id t187sm8174708pfb.116.2017.03.28.08.30.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Mar 2017 08:30:04 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_878507E5-40E5-45F7-A2A0-17A2E71EBE6A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <381D7D55085B1E4D8B581BD652E1E140B2A565F5@nkgeml513-mbs.china.huawei.com> Date: Tue, 28 Mar 2017 10:30:04 -0500 Cc: Martin Bjorklund , "netconf@ietf.org" , "netmod@ietf.org" Message-Id: References: <381D7D55085B1E4D8B581BD652E1E140B2A565F5@nkgeml513-mbs.china.huawei.com> To: "Zhengguangying (Walker)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] [Netconf] comments to draft-ietf-netmod-revised-datastores-01 on the IETF98 meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:30:08 -0000 --Apple-Mail=_878507E5-40E5-45F7-A2A0-17A2E71EBE6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 28, 2017, at 10:03 AM, Zhengguangying (Walker) = wrote: >=20 > Hi Martin, > =20 > My comments is why it need YANG modules change there definition? = datastore is the conception of system datastore mechinism, we can use = filter or common top level YANG modul to support multi datastore. > But, if ask YANG modules to change their definition to use split = tree, it will bound the datastore logic to YANG modules, it not looks = like a good idea, because all YANG modules should change and know the = datastore. I do not think there is anything in the proposal that says that YANG = modules will be bound to a particular datastore, or that they need to = know about the different datastores a particular implementation = supports. The suggestion to collapse the config and state part of the tree is to = avoid data getting duplicated as a result of implementation of the new = datastore concept. > =20 > So, my suggestion is not sue split tree in YANG modules, but = support it by netconf or another new TOP level YANG module. > =20 > Thanks > =20 > Zheng guangying (walker) =46rom Huawei > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_878507E5-40E5-45F7-A2A0-17A2E71EBE6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mar 28, 2017, at 10:03 AM, Zhengguangying (Walker) <zhengguangying@huawei.com> wrote:

Hi = Martin,

 

      My comments is why it need = YANG modules change there definition?  datastore is the conception = of system datastore mechinism,  we can use filter or common top = level YANG modul to support multi datastore.
     But, if ask YANG modules to change = their definition to use split tree, it will bound the datastore logic to = YANG modules, it not looks like a good idea,  because all YANG = modules should change and know the = datastore.

I do = not think there is anything in the proposal that says that YANG modules = will be bound to a particular datastore, or that they need to know about = the different datastores a particular implementation = supports.

The suggestion to collapse = the config and state part of the tree is to avoid data getting = duplicated as a result of implementation of the new datastore = concept.

 

     So, my suggestion is not sue = split tree in YANG modules, but support it by netconf or another new TOP = level YANG module.

 

Thanks

 

Zheng guangying (walker)  =46rom = Huawei
_______________________________________________
Netconf mailing = list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_878507E5-40E5-45F7-A2A0-17A2E71EBE6A-- From nobody Tue Mar 28 08:57:45 2017 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 05D4E120725; Tue, 28 Mar 2017 08:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 QQiZhurALvrB; Tue, 28 Mar 2017 08:57:42 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 D7868128D40; Tue, 28 Mar 2017 08:57:41 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.128.130; From: "Susan Hares" To: "'Mahesh Jethanandani'" , "'Zhengguangying \(Walker\)'" Cc: , References: <381D7D55085B1E4D8B581BD652E1E140B2A565F5@nkgeml513-mbs.china.huawei.com> In-Reply-To: Date: Tue, 28 Mar 2017 11:52:43 -0400 Message-ID: <018501d2a7db$56bcdce0$043696a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0186_01D2A7B9.CFAD86D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHV+57pm+O7m2DpepyVFy9a0GpMZQK2NQowoY4NmuA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] [Netconf] comments to draft-ietf-netmod-revised-datastores-01 on the IETF98 meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:57:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0186_01D2A7B9.CFAD86D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I2RS Topology modules are being design to work in configuration datastore or I2RS datastore. Sue From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethanandani Sent: Tuesday, March 28, 2017 11:30 AM To: Zhengguangying (Walker) Cc: netconf@ietf.org; netmod@ietf.org Subject: Re: [Netconf] comments to draft-ietf-netmod-revised-datastores-01 on the IETF98 meeting On Mar 28, 2017, at 10:03 AM, Zhengguangying (Walker) wrote: Hi Martin, My comments is why it need YANG modules change there definition? datastore is the conception of system datastore mechinism, we can use filter or common top level YANG modul to support multi datastore. But, if ask YANG modules to change their definition to use split tree, it will bound the datastore logic to YANG modules, it not looks like a good idea, because all YANG modules should change and know the datastore. I do not think there is anything in the proposal that says that YANG modules will be bound to a particular datastore, or that they need to know about the different datastores a particular implementation supports. The suggestion to collapse the config and state part of the tree is to avoid data getting duplicated as a result of implementation of the new datastore concept. So, my suggestion is not sue split tree in YANG modules, but support it by netconf or another new TOP level YANG module. Thanks Zheng guangying (walker) From Huawei _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com ------=_NextPart_000_0186_01D2A7B9.CFAD86D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I2RS Topology modules are being design to work in configuration = datastore or I2RS datastore.

 

Sue

 

From:= = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani
Sent: Tuesday, March 28, 2017 11:30 = AM
To: Zhengguangying (Walker)
Cc: netconf@ietf.org; = netmod@ietf.org
Subject: Re: [Netconf] comments to = draft-ietf-netmod-revised-datastores-01 on the IETF98 = meeting

 

 

On Mar 28, 2017, at 10:03 AM, Zhengguangying (Walker) = <zhengguangying@huawei.com&g= t; wrote:

 

Hi = Martin,

 <= /o:p>

  =     My comments is why it need YANG modules change there = definition?  datastore is the conception of system datastore = mechinism,  we can use filter or common top level YANG modul to = support multi datastore.

  =    But, if ask YANG modules to change their definition to use = split tree, it will bound the datastore logic to YANG modules, it not = looks like a good idea,  because all YANG modules should change and = know the = datastore.

 

I do = not think there is anything in the proposal that says that YANG modules = will be bound to a particular datastore, or that they need to know about = the different datastores a particular implementation = supports.

 

The suggestion to collapse the config and state part = of the tree is to avoid data getting duplicated as a result of = implementation of the new datastore concept.

 

 <= /o:p>

  =    So, my suggestion is not sue split tree in YANG modules, = but support it by netconf or another new TOP level YANG = module.

 <= /o:p>

Thanks<= /o:p>

 <= /o:p>

Zheng = guangying (walker)  From Huawei

__________= _____________________________________
Netconf mailing = list
Netconf@ie= tf.org
https://ww= w.ietf.org/mailman/listinfo/netconf

 

Mahesh Jethanandani

 

 

 

------=_NextPart_000_0186_01D2A7B9.CFAD86D0-- From nobody Tue Mar 28 11:59:43 2017 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 634931293E3 for ; Tue, 28 Mar 2017 11:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 u8n0Df6-__r2 for ; Tue, 28 Mar 2017 11:59:38 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6D112943C for ; Tue, 28 Mar 2017 11:59:37 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id s68so99655388vke.3 for ; Tue, 28 Mar 2017 11:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F90f0AqIKU5/zqNr+eN+fPW+fsX+fWZIbuM0UsZ0B/k=; b=ZRVgcA5NWdcFlRO0o/AlWaZagtUPXcTTG9xuZG21PsCOO0yNqcVGdIjkCDseLN/6Wj SvN+kiiYDrz+JWy40w2Pif7U0Qb8pDsBqS/9oOvowgnJNswRNPxxom9IWuFeKwJ2KoJF QmcU9Hndu+sdQ7hZtZqWDjS+ctDY4p/gqD0cA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F90f0AqIKU5/zqNr+eN+fPW+fsX+fWZIbuM0UsZ0B/k=; b=r2D+87yGm9KN1G+nE9f818CQ1qYe+cob/mLVEwONUR1mKTtUbv5aix0lOn6JFGOwkx bJwPPO19Pa0ybmm0g7wjbRoro99/fIcxbm9uZAqyvxHt9rmYg0eZhJUvmlBMMKY9ks5s LzMvh2EdYu9zwIc2HJEyPjELDVsxblDl+07zz4hxk/LfssSXLS9S846u1oCjPcYdAIB7 5ocKzee1zrUkCM33G6IjvkovsZRJfSKwZRuN4MyB+47DHe81ZD/VRW2AZQEWySGsBH71 0jmj9YeIRAYLGAH3P4WAh1MOdGOllsFADD8meG5azVxpLm4pz3aMAzLn1KX8vq7oQU/e 5XYg== X-Gm-Message-State: AFeK/H1TfxKO0mQPsqcascBi8ejKaInqFlPp/Gotgz46EBT9Uj6SObhNrczWRGp9MqOQkso6mK8QdctPAAoYaJnp X-Received: by 10.176.3.231 with SMTP id 94mr7795909uau.10.1490727576646; Tue, 28 Mar 2017 11:59:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.33.72 with HTTP; Tue, 28 Mar 2017 11:59:36 -0700 (PDT) In-Reply-To: <86AA35DF-0D22-45E7-A954-E766133ED49D@juniper.net> References: <148939875845.17039.4017763838166134753.idtracker@ietfa.amsl.com> <4D50BFD4-0E59-4DF8-BEC9-0D9BE50F5BA6@juniper.net> <86AA35DF-0D22-45E7-A954-E766133ED49D@juniper.net> From: David Bannister Date: Tue, 28 Mar 2017 14:59:36 -0400 Message-ID: To: Kent Watsen Cc: Dean Bogdanovic , NetMod WG Content-Type: multipart/alternative; boundary=94eb2c056802aa292a054bcf0f12 Archived-At: Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:59:41 -0000 --94eb2c056802aa292a054bcf0f12 Content-Type: text/plain; charset=UTF-8 I would agree that the mix of L2 and L3 in the same operational ACL is a bit out of the ordinary. I could see where a combined approach may be appealing to some. As a network operator I do not see this as a negative. It would be nice to give the vendor the option to defer the L2/3 combination but it does not look attainable in the current model. "augmented by each vendor" There are many things missing in IETF models and some things which are not under the IETF umbrella. In this discussion the first that comes to mind is an 802.x model. It is good to see there is currently an IEEE effort to develop one. However, it does not exist today. The various ether types are covered in some of the vendor models I have seen. We take the Newco example in the draft which typedefs an enum of 'known-ether-type.' Meanwhile Oldco is using a typedef of 'ethertype.' Both New and Old co both augment this draft. In this scenario the network operator is stuck sorting out the logic in which vendor model to use and having to deal with two data structures for the same entity (ether-type). Using models this way does nothing to simplify network coding and management. I am against augmentation from vendor models for common items but it is ok for vendor unique items. Ether-type is not vendor unique. Augmentation has its place but it appears to be overused even within the context of IETF only models. Not sure if pointing out ietf-routing was a good idea. Five years in the making and 42 augmenting models. :-) If we can get the well known IETF standardized missing bits from L3, L4 for v4 and v6 into this it would work for me but I think the IETF may have missed the boat on this one. On Sun, Mar 26, 2017 at 1:17 PM, Kent Watsen wrote: > HI David, > > > > I believe an analogy to the ietf-routing module can and should be made > here. In both cases, the module provides a minimal skeleton that is > intended to be extended by augmentations. If anything, I could argue that > the acl module doesn't go far enough, in that there is no feature statement > on the "ace-ip" and "ace-eth" case statements, as if it's assuming that all > servers implement L3 and L2 ACLs, which I find suspicious... > > > > You write below "augmented by each vendor", but I don't believe that this > is the intent, so much as (just like with the ietf-routing) that future > IETF modules will be defined to flesh it out. In particular, the existing > "ace-ip" and "ace-eth" case statements can be augmented, as well as brand > new case statements added. I agree that, in its current form, this draft > is of limited use, but keep in my that the ietf-routing module now has 42 > other modules augmenting it, so there's hope that the > ietf-access-control-list module will similarly be fleshed out in short > order. > > > > What do you think? Do you think we should put feature statements on the > two case statements, or even move these into other modules (in the same > draft) so that there is no specialness imparted on them? > > > > What about others? I'm concerned that we may not have sufficient domain > expertise in the NETMOD WG - similar to the routing-cfg draft, until the > rtgwg started to focus on it. > > > > Kent // shepherd > > > > > > On 3/18/17, 9:18 AM, "David Bannister" wrote: > > > > (second try) > > There were no changes to the model so my concerns remain the same. > Augmentation is not a scalable solution when dealing with a mutli-vendor or > in some instances a multi-business-unit environment. The 'newco' example > in the draft illustrates this problem. The IETF produces a 'standard' for > an ACL draft which is so sparse in nature that it must be augmented by each > vendor. In the best case this gives me a unique model per vendor because > we know the vendors are not going to get together to define the missing > pieces. The vendors will use a variety of mechanisms to complete the model > from using a script to build their models from source code, handling the > missing pieces as arbitrary code (anyxml), or everything as a string. Then > there is the worse case where a vendor has no internal standardization (you > know who you are) and their own product lines will not align into a common > model. The object here, for me, is to get to a single model for all > vendors barring a unique feature that belongs to one vendor in which case > augmentation is acceptable. > > > > Could you add to this in the future and rev up the RFC? Sure. However, I > am not sure what value that brings to the community. In its current form I > would not ask any of my vendors to implement this draft. Instead I would > push them towards the OpenConfig ACL model. > > > > On Tue, Mar 14, 2017 at 9:12 PM, Kent Watsen wrote: > > Hi David, > > > > Can you please confirm that the additional examples address your concern? > And, if not, please > > explain if there is any reason why what you're looking for couldn't be > added or augmented in > > in the future. > > > > Thanks, > > Kent // shepherd > > > > On 3/13/17, 5:57 AM, "netmod on behalf of Dean Bogdanovic" < > netmod-bounces@ietf.org on behalf of ivandean@gmail.com> wrote: > > > > Here is the new version of the ACL draft. Since December and some > additional comments about the ACL model, I spoke with many operators and > how they use ACLs. I have also received lot of detailed ACL configurations. > In most cases, the model is easily adapted to the current use cases in > operations. But to answer the comments, the authors have added a detailed > example in the addendum section how the model can be extended and how this > model can be used. > > > > Cheers, > > > > Dean > > > > > > Begin forwarded message: > > > > *From: *internet-drafts@ietf.org > > *Subject: New Version Notification for draft-ietf-netmod-acl-model-10.txt* > > *Date: *March 13, 2017 at 10:52:38 AM GMT+1 > > *To: *, "Kiran Koushik" , > "Lisa Huang" , "Dean Bogdanovic" , > "Dana Blair" , "Kiran Agrahara Sreenivasa" < > kkoushik@cisco.com> > > > > > A new version of I-D, draft-ietf-netmod-acl-model-10.txt > has been successfully submitted by Dean Bogdanovic and posted to the > IETF repository. > > Name: draft-ietf-netmod-acl-model > Revision: 10 > Title: Network Access Control List (ACL) YANG Data Model > Document date: 2017-03-13 > Group: netmod > Pages: 32 > URL: https://www.ietf.org/internet-drafts/draft- > ietf-netmod-acl-model-10.txt > Status: https://datatracker.ietf.org/doc/draft-ietf- > netmod-acl-model/ > Htmlized: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-10 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf- > netmod-acl-model-10 > > Abstract: > This document describes a data model of Access Control List (ACL) > basic building blocks. > > Editorial Note (To be removed by RFC Editor) > > This draft contains many placeholder values that need to be replaced > with finalized values at the time of publication. This note > summarizes all of the substitutions that are needed. Please note > that no other RFC Editor instructions are specified anywhere else in > this document. > > Artwork in this document contains shorthand references to drafts in > progress. Please apply the following replacements > > o "XXXX" --> the assigned RFC value for this draft. > > o Revision date in model (Oct 12, 2016) needs to get updated with > the date the draft gets approved. The date also needs to get > reflected on the line with . > > > > > 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. > > The IETF Secretariat > > > > > --94eb2c056802aa292a054bcf0f12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would agree that the mix of L2 and L3 in the same operat= ional ACL is a bit out of the ordinary.=C2=A0 I could see where a combined = approach may be appealing to some.=C2=A0 As a network operator I do not see= this as a negative.=C2=A0 It would be nice to give the vendor the option t= o defer the L2/3 combination but it does not look attainable in the current= model.

"augmented by each vendor" =C2=A0There= are many things missing in IETF models and some things which are not under= the IETF umbrella.=C2=A0 In this discussion the first that comes to mind i= s an 802.x model.=C2=A0 It is good to see there is currently an IEEE effort= to develop one.=C2=A0 However, it does not exist today.=C2=A0 The various = ether types are covered in some of the vendor models I have seen.=C2=A0 We = take the Newco example in the draft which typedefs an enum of 'known-et= her-type.' =C2=A0Meanwhile Oldco is using a typedef of 'ethertype.&= #39; =C2=A0Both New and Old co both augment this draft. In this scenario th= e network operator is stuck sorting out the logic in which vendor model to = use and having to deal with two data structures for the same entity (ether-= type). =C2=A0 Using models this way does nothing to simplify network coding= and management.=C2=A0 I am against augmentation from vendor models for com= mon items but it is ok for vendor unique items.=C2=A0 Ether-type is not ven= dor unique.=C2=A0 Augmentation has its place but it appears to be overused = even within the context of IETF only models.

Not s= ure if pointing out ietf-routing was a good idea. Five years in the making = and 42 augmenting models. :-)

If we can get the we= ll known IETF standardized missing bits from L3, L4 for v4 and v6 into this= it would work for me but I think the IETF may have missed the boat on this= one.




On Sun, Mar 26, 2017 at 1:17 P= M, Kent Watsen <kwatsen@juniper.net> wrote:

HI David,=

=C2=A0=

I believe an ana= logy to the ietf-routing module can and should be made here.=C2=A0 In both = cases, the module provides a minimal skeleton that is intended to be extend= ed by augmentations.=C2=A0 =C2=A0If anything, I could argue that the acl module doesn't go far enough, in that there is no f= eature statement on the "ace-ip" and "ace-eth" case sta= tements, as if it's assuming that all servers implement L3 and L2 ACLs,= which I find suspicious...

=C2=A0=

You write below = "augmented by each vendor", but I don't believe that this is = the intent, so much as (just like with the ietf-routing) that future IETF m= odules will be defined to flesh it out.=C2=A0 In particular, the existing "ace-ip" and "ace-eth" case statements ca= n be augmented, as well as brand new case statements added.=C2=A0=C2=A0 I a= gree that, in its current form, this draft is of limited use, but keep in m= y that the ietf-routing module now has 42 other modules augmenting it, so there's hope that the ietf-access-control-list module will simi= larly be fleshed out in short order.

=C2=A0=

What do you thin= k?=C2=A0 Do you think we should put feature statements on the two case stat= ements, or even move these into other modules (in the same draft) so that t= here is no specialness imparted on them?

=C2=A0=

What about other= s?=C2=A0 I'm concerned that we may not have sufficient domain expertise= in the NETMOD WG - similar to the routing-cfg draft, until the rtgwg start= ed to focus on it.

=C2=A0=

Kent=C2=A0 // sh= epherd

=C2=A0=

=C2=A0=

On 3/18/17, 9:18 AM, "David Bannister" <= ;dpb@netflix.com&g= t; wrote:

=C2=A0

(second try)<= u>

There were no change= s to the model so my concerns remain the same.=C2=A0 Augmentation is not a = scalable solution when dealing with a mutli-vendor or in some instances a m= ulti-business-unit environment.=C2=A0 The 'newco' example in the draft illustrates this problem.=C2=A0 The IETF produces a &= #39;standard' for an ACL draft which is so sparse in nature that it mus= t be augmented by each vendor.=C2=A0 In the best case this gives me a uniqu= e model per vendor because we know the vendors are not going to get together to define the missing pieces.=C2=A0 The vendors = will use a variety of mechanisms to complete the model from using a script = to build their models from source code, handling the missing pieces as arbi= trary code (anyxml), or everything as a string.=C2=A0 Then there is the worse case where a vendor has no interna= l standardization (you know who you are) and their own product lines will n= ot align into a common model.=C2=A0 The object here, for me, is to get to a= single model for all vendors barring a unique feature that belongs to one vendor in which case augmentation is acceptabl= e. =C2=A0

=C2=A0=

Could you add to thi= s in the future and rev up the RFC?=C2=A0 Sure.=C2=A0 However, I am not sur= e what value that brings to the community.=C2=A0 In its current form I woul= d not ask any of my vendors to implement this draft.=C2=A0 Instead I would push them towards the OpenConfig ACL model. =C2=A0<= u>

=C2=A0

On Tue, Mar 14, 2017 at 9:12 PM, Kent Watsen <kwatsen@juniper.net> wrote:

Hi David,=

=C2=A0=

Can you please c= onfirm that the additional examples address your concern?=C2=A0 And, if not= , please

explain if there= is any reason why what you're looking for couldn't be added or aug= mented in

in the future.

=C2=A0=

Thanks,

Kent // shepherd=

=C2=A0=

=C2=A0

Here is the new version of the ACL draft. Since Dece= mber and some additional comments about the ACL model, I spoke with many op= erators and how they use ACLs. I have also received lot of detailed ACL configurations. In most cases, the model is easily ada= pted to the current use cases in operations. But to answer the comments, th= e authors have added a detailed example in the addendum section how the mod= el can be extended and how this model can be used.

=C2=A0

Cheers,

=C2=A0

Dean

=C2=A0

=C2=A0<= /p>

Begin forwarded message:

=C2=A0

Subject: New Version Notification for draft-ietf-netmod-acl-model-10.txt

Date: March 13,= 2017 at 10:52:38 AM GMT+1

To: <netmod-chairs@ietf.o= rg>, "Kiran Koushik" <kkoushik@cisco.com>, "Lisa Huang" &= lt;lyihuang16@gma= il.com>, "Dean Bogdanovic" <ivandean@gmail.com>, "Dana Blair" <dblair@cisco.com>, &= quot;Kiran Agrahara Sreenivasa" <kkoushik@cisco.com>

=C2=A0


A new version of I-D, draft-ietf-netmod-acl-model-10.txt
has been successfully submitted by Dean Bogdanovic and posted to the
IETF repository.

Name: draft-ietf-netmod-acl-model
Revision: 10
Title: Network Access Control List (ACL) YANG Data Model
Document date: 2017-03-13
Group: netmod
Pages: 32
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-ietf-netmod-acl-model-10.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.i= etf.org/html/draft-ietf-netmod-acl-model-10
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-net= mod-acl-model-10

Abstract:
=C2=A0=C2=A0This document describes a data model of Access Control List (AC= L)
=C2=A0=C2=A0basic building blocks.

=C2=A0=C2=A0Editorial Note (To be removed by RFC Editor)

=C2=A0=C2=A0This draft contains many placeholder values that need to be rep= laced
=C2=A0=C2=A0with finalized values at the time of publication.=C2=A0 This no= te
=C2=A0=C2=A0summarizes all of the substitutions that are needed.=C2=A0 Plea= se note
=C2=A0=C2=A0that no other RFC Editor instructions are specified anywhere el= se in
=C2=A0=C2=A0this document.

=C2=A0=C2=A0Artwork in this document contains shorthand references to draft= s in
=C2=A0=C2=A0progress.=C2=A0 Please apply the following replacements

=C2=A0=C2=A0o =C2=A0"XXXX" --> the assigned RFC value for this= draft.

=C2=A0=C2=A0o =C2=A0Revision date in model (Oct 12, 2016) needs to get upda= ted with
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the date the draft gets approved.=C2=A0 The d= ate also needs to get
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0reflected on the line with <CODE BEGINS>= ;.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=C2=A0

=C2=A0


--94eb2c056802aa292a054bcf0f12-- From nobody Tue Mar 28 12:37:14 2017 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 DFFBF129564 for ; Tue, 28 Mar 2017 12:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 ZOf5Rq_UQUzA for ; Tue, 28 Mar 2017 12:37:09 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4D121126C22 for ; Tue, 28 Mar 2017 12:37:05 -0700 (PDT) Received: from localhost (dhcp-9410.meeting.ietf.org [31.133.148.16]) by mail.tail-f.com (Postfix) with ESMTPSA id 895011AE02A9 for ; Tue, 28 Mar 2017 21:37:03 +0200 (CEST) Date: Tue, 28 Mar 2017 14:37:02 -0500 (CDT) Message-Id: <20170328.143702.671206132497537810.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] origin definition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 19:37:11 -0000 Hi, In the session today, Hank Birkhotz made a comment about the definition of the origin attributes. In the Etherpad minutes it was captured as: Hank Birkhotz: Draft differentiates between state vs dynamic configuration, state and dynamic configuraiton look the same, but they are not. Pull/align the distinction into the origin definition. Hank, could you elaborate a bit on this? /martin From nobody Tue Mar 28 14:39:18 2017 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 2B9141294B0 for ; Tue, 28 Mar 2017 14:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 n7SZZok0BbE3 for ; Tue, 28 Mar 2017 14:39:13 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0D8126C0F for ; Tue, 28 Mar 2017 14:39:13 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id s68so104488438vke.3 for ; Tue, 28 Mar 2017 14:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zjJymy0bK/p3rDAo6Z58YKzQPcJgz/c09fFZwqPeUhA=; b=Nir+o5rRoV85vyPyb7GegcGzQi0HGKikgKqlYz9SgN42BCzNz86miOq35Kwjg9W6/D 0kd7HwzaaJX/V0aDel+4bEJVrA4o0k8u4pnvEv12+qkpWHXUXYk3vPVC44nBiqE4W5Xu hbx7kD3nXpz12cqjIwnvJSBjbxYo4gAt17n1M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zjJymy0bK/p3rDAo6Z58YKzQPcJgz/c09fFZwqPeUhA=; b=hNLJ4gyD6yszto60DRBycbsKqdCi74WDR4YdUGDynvnO8CiHwYO4MVQO//keYgDz0Y VmXn1hi2Azmond21kB4lLZOGn2VBX7yFfK8RfrwziH6/HdQetIkJ/ImndNYjqhOXoSy5 His/nGB1cksjZcp8U29ka/X3VhvypzmWL+MNEQsMmMqICEgnsNumDQS/L7jhBXH9Q9bd 9iafPqrUxzkhwvuA4BX+AL0xti9Lqrcfk4CO77LJ+H4fbTZyPaNu8B/ZF5/6MOqqty8a nb5DnmrBBQgqk779Owswct+jiIdZp3PSO4V5vIPFHI5vNb8mmuLW1SvL7Hiy0d3HK37S siJw== X-Gm-Message-State: AFeK/H2nvVaSPaqeyOXjOyyJwbbYfGKT1dCJ7U7yAjK7idS8bNv/ohHdklGNhUoUDs7GbYhs6DSiVBeY77uuzhnZ X-Received: by 10.31.140.205 with SMTP id o196mr13794262vkd.7.1490737152017; Tue, 28 Mar 2017 14:39:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.33.72 with HTTP; Tue, 28 Mar 2017 14:39:11 -0700 (PDT) In-Reply-To: References: <3B8DC570-FB2D-4EE9-98BA-EEED20F2DBC0@gmail.com> <1061F93A-2D1F-41FB-9A21-A3D92188E7E2@gmail.com> <179f5eb2-0de9-42cb-f291-738f16dab568@cisco.com> <4ab7ace4-e6aa-1fc5-a259-ad196a8b882c@cisco.com> <7635AD99-C245-41FA-8622-4ABA220DEF47@juniper.net> From: David Bannister Date: Tue, 28 Mar 2017 17:39:11 -0400 Message-ID: To: NetMod WG Content-Type: multipart/alternative; boundary=001a11425722665ff3054bd14aa3 Archived-At: Subject: [netmod] Fwd: WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 21:39:16 -0000 --001a11425722665ff3054bd14aa3 Content-Type: text/plain; charset=UTF-8 I was asked to resend this to the list. ---------- Forwarded message ---------- From: David Bannister Date: Sat, Dec 17, 2016 at 1:06 PM Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016) To: Kent Watsen Cc: Dean Bogdanovic , "netmod@ietf.org" I would like to see a model which is a standardized and contains the basic L2, L3 and L4 fields to make it useful for for data plane, control plane, management plane and day-to-day troubleshooting. The current iteration of the draft does not meet these requirements. Vendor augmentation is not an acceptable answer for fields which are well defined, well understood and standardized by the IETF. Vendors do not standardize amongst themselves willingly. This leads the network operator to deal with multiple versions of the same model if augmentation is used. As a network operator we want to reduce complexity in network management, not increase. If we need a feature which only one vendor has we accept the fact we must augment from that vendor's proprietary model. For vendors or devices that cannot support all pieces of a proposed model a deviation can be provided. L2 Given that the IEEE has yet to define an Ethernet model makes the ACL draft, and others, somewhat problematic. However, it is well known, well understood and standardized elsewhere. Each ethertype should have an associated node which represents the data for that ethertype to allow for matching in the ACL. The following list of ethertypes is considered mandatory: IPv6-uni, IPv6-multi, IPv4-uni, IPv4-multi, MPLS-uni, MPLS-multi, 802.1q and if you feel something is missing please add. All the L3 and L4 fields below are well defined, well understood and standardized by the IETF. L3 The layer 3 portion of the ACL draft needs to add the following for IPv4: TTL, Len, IHL, ECN, Ident, Flags, offset. IPv6 add traffic class, len, next header and hop limit. L4 For TCP add sequence, ack#, offset, Resv, TCP-flags, window size, urgent pointer and options. For UDP add Length. ICMP add type, code and rest of header. --001a11425722665ff3054bd14aa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was asked to resend this to the list.

---------- Forwarded message ----------
From: David Bannister <dpb@netflix.com>
Date: Sat, Dec 17= , 2016 at 1:06 PM
Subject: Re: [netmod] WG Last Call for draft-ietf-netm= od-acl-model-09 (until Oct 27, 2016)
To: Kent Watsen <kwatsen@juniper.net>
Cc: Dean Bogdanovic = <ivandean@gmail.com>, "= ;netmod@ietf.org" <netmod@ietf.org>


I = would like to see a model which is a standardized and contains the basic L2= , L3 and L4 fields to make it useful for for data plane, control plane, man= agement plane and day-to-day troubleshooting.=C2=A0 The current iteration o= f the draft does not meet these requirements. Vendor augmentation is not an= acceptable answer for fields which are well defined, well understood and s= tandardized by the IETF.=C2=A0 Vendors do not standardize amongst themselve= s willingly. This leads the network operator to deal with multiple versions= of the same model if augmentation is used.=C2=A0 As a network operator we = want to reduce complexity in network management, not increase.=C2=A0 If we = need a feature which only one vendor has we accept the fact we must augment= from that vendor's proprietary model.=C2=A0 For vendors or devices tha= t cannot support all pieces of a proposed model a deviation can be provided= .


L2
Given that the IEEE has yet to define an Ethernet model makes the ACL draft, and others, somewhat problematic.=C2=A0 However, it is well known, well un= derstood and standardized elsewhere.=C2=A0 Each ethertype should have an=20 associated node which represents the data for that ethertype to allow=20 for matching in the ACL.=C2=A0 The following list of ethertypes is consider= ed mandatory: IPv6-uni, IPv6-multi, IPv4-uni, IPv4-multi, MPLS-uni,=20 MPLS-multi, =C2=A0802.1q and if you feel something is missing please add.

All the L3 and L4 fields below are well de= fined, well understood and standardized by the IETF.
L3
The layer 3 portion of the ACL draft needs to add the following for IPv4:=20 TTL, Len, IHL, ECN, Ident, Flags, offset.=C2=A0 IPv6 add traffic class, len= ,=20 next header and hop limit.

L4
For TCP add sequence, ack#, offset, Resv, TCP-flags, window size, urgent=20 pointer and options.=C2=A0 For UDP add Length.=C2=A0 ICMP add type, code an= d rest=20 of header.
=C2=A0
--001a11425722665ff3054bd14aa3-- From nobody Wed Mar 29 03:47:23 2017 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 891CC1242F5 for ; Wed, 29 Mar 2017 03:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiAU-qhjXiRi for ; Wed, 29 Mar 2017 03:47:19 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00109.outbound.protection.outlook.com [40.107.0.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E144D126557 for ; Wed, 29 Mar 2017 03:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oRQ+78ntdlNe8tmNrWjdeX3VGizA+pJZ2nEOhmLDkC4=; b=chHJGdmuaZHkZEBkHLZzD3bSYzGL8ZhCgxBniCY9eetbMDCeNbvAhzwrCpuxQRV0/V1sujrdjYDP9thpZVnQfNhZmqk+trH7zfHeqy7B5brsDyDItrWrNtDL3lxtaRfAWFEnDHQEHC+HqjbLPGbLtnEt++Gcg4E2n3Uek1C6TYo= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 10:47:16 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 10:47:16 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: "netmod@ietf.org" Thread-Topic: Question about must statement in grouping Thread-Index: AdKob59zUH9BTX/5SB69vtC6sOJtgA== Date: Wed, 29 Mar 2017 10:47:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.20] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0627; 7:AZGFg4KWYUp2qKuYNJziVdjpeVS5VJ0byVcgpS9SVgo2NEqqIX/rjA3an9cLjJtq24eoheXjkykucZP5VO2S81PUX4HKiEEjkUw9QY2/MGgqmCWtK3XtBUgYCSURy0WzF3fpCkKno3rMZ/bugDAfQQ7BPimB+MBX7D4QVNLG/OoB7L+YTUewy+cJDWKQaq0l4F0ROrC1KHrfc1u5T8VNwz0nJhjCGrbZhDI2mNxuuR052Kq1Kqwr50WqtQwoXFoiyI7lE9DovBfB7Rtn8Amy4kME+EWJxURe00VpLPfpsXuNHV6TNMuHm0ecEO6ChcwqYG5vMSmc4G0WPGeDXVAprg== x-ms-office365-filtering-correlation-id: 3103b547-7bc8-4031-2328-08d47690f776 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM2PR07MB0627; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040449)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(201703131423074)(201702281528074)(201703061421074)(201703061406074)(20161123555025)(20161123558025)(6072148); SRVR:AM2PR07MB0627; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0627; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(39400400002)(39410400002)(39850400002)(74316002)(2900100001)(8936002)(66066001)(50986999)(7736002)(55016002)(102836003)(6116002)(790700001)(3846002)(54356999)(122556002)(99936001)(81166006)(1730700003)(8676002)(86362001)(6436002)(189998001)(6916009)(33656002)(5660300001)(7696004)(6506006)(5630700001)(6306002)(99286003)(38730400002)(54896002)(110136004)(9686003)(2906002)(53936002)(9326002)(3660700001)(3280700002)(2351001)(25786009)(2501003)(5640700003)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0627; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0A73_01D2A88A.973C4B70" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 10:47:16.2843 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0627 Archived-At: Subject: [netmod] Question about must statement in grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 10:47:21 -0000 ------=_NextPart_000_0A73_01D2A88A.973C4B70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0A74_01D2A88A.973C4B70" ------=_NextPart_001_0A74_01D2A88A.973C4B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We have a question on the usage of a must statement within a grouping. Assume the following grouping grouping a-group { list a-list { must "count(.) != 1" { description "This list must either be empty or have at least 2 elements"; } key "entry"; leaf entry { type uint16; } leaf another-entry { type uint32; } } } And used in another module container a-container { uses a-group; } The uses actually results in a data-tree like below +--rw a-container +--rw a-list* [entry] +--rw entry uint16 +--rw another-entry uint32 Does the usage of the grouping usage also result in the expected behavior for the must statement when configuring /a-container/a-list? The '.' in the must statement in the grouping refers to 'a-list' so will that return 2 in case we have configured 2 elements in /a-container/a-list or should we write the must statement at the level of 'a-container' stating that "count(a-list) != 1" (as below)? grouping a-group { list a-list { key "entry"; leaf entry { type uint16; } } } And used in another module container a-container { uses a-group; must "count(a-list) != 1" { description "This list must either be empty or have at least 2 elements"; } } Best regards - Vriendelijke groeten, Bart Bogaert ------=_NextPart_001_0A74_01D2A88A.973C4B70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have a question on the usage of a must statement within = a grouping.

 

Assume the following grouping

 

grouping a-group = {

  list a-list = {

    = must “count(.) !=3D 1” {

      description

        “This list must = either be empty or have at least 2 = elements”;

    }

    = key “entry”;

    leaf entry {

      type = uint16;

    = }

  =   leaf another-entry {

    =   type uint32;

    }

  = }

}

 

And used in another module

 

container = a-container {

  = uses a-group;

}

 

The uses actually results in a data-tree like = below

 

  = +--rw a-container

      +--rw a-list* = [entry]

           +--rw = entry  =          uint16

           +--rw = another-entry   uint32

 

Does the usage of the grouping = usage also result in the expected behavior for the must statement when = configuring /a-container/a-list?  The ‘.’ in the must = statement in the grouping refers to ‘a-list’ so will that = return 2 in case we have configured 2 elements in /a-container/a-list or = should we write the must statement at the level of = ‘a-container’ stating that “count(a-list) !=3D = 1” (as below)?

 

grouping a-group {

  = list a-list {

    key = “entry”;

    leaf entry {

      type = uint16;

    = }

  = }

}

 

And used in another module

 

container = a-container {

  = uses a-group;

  = must “count(a-list) !=3D 1” {

    = description

      “This list must either be = empty or have at least 2 elements”;

  = }

}

 

Best regards - Vriendelijke groeten,

Bart Bogaert

------=_NextPart_001_0A74_01D2A88A.973C4B70-- ------=_NextPart_000_0A73_01D2A88A.973C4B70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjkxMDQ3MTRaMCMGCSqGSIb3DQEJBDEWBBSwOKSM s9/otvlWsfpJVXL90Bg8ezCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAE94M1GrOUTZgC5XH/JgxmEaUYb3BLPjjeXZPixdAlezAKSdbU1qWA5y0QCT 3RNaFOYersOZbHQPg8bUk5MKkUblYr/PfIr0l9XpXo9WkMVFlkCUU2+xlaLdq+Y2xQM1DrFgjjEZ YFv8q/xsrnnQmTWZbFPDd4bBNiq+G493IJdloot0o7ZXREov6xBevKHkKXSyId5ogUeGq9nx8GLX 9wyWn5ckoHzZX850QAN9Qi2E0NGpaAiljMhNPDtNyakpnxAmYfR5B+PZn3//SayeiVnIeRh69JA6 oXnxPLohcx2DHzozfrh4uZHHJ15Nt5nPxhzO+X9o9Iqhphy+maFoQ+cAAAAAAAA= ------=_NextPart_000_0A73_01D2A88A.973C4B70-- From nobody Wed Mar 29 05:02:19 2017 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 CD6641296C5 for ; Wed, 29 Mar 2017 05:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 W5Y9UmG4Xmmu for ; Wed, 29 Mar 2017 05:02:08 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20093.outbound.protection.outlook.com [40.107.2.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373801296C3 for ; Wed, 29 Mar 2017 05:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xtrO7B5kReChat8/IzWiCOQ59uhNYDduI2lAgQT7/34=; b=QbhmHWfAxJ4LOodHerYEd+TrtM7CIPLfQw7Je66pQLB6wRfyEOyR/6N1DnC4ZS4tRgJQQdK5C5Fr0j553UahiIhMkGGOnAZbdFcWc11d5pVQVy6yNfB82kWUOxZMFiOvsXFIIUrTl/6bR/6cWnMWHzoHNcXt5V0IH1JVyB8ch98= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0625.eurprd07.prod.outlook.com (10.160.54.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 12:02:06 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 12:02:05 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Thread-Topic: Question about must statement in grouping Thread-Index: AdKob59zUH9BTX/5SB69vtC6sOJtgAAFDffA Date: Wed, 29 Mar 2017 12:02:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.20] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0625; 7:MWkOlRZkhIud4Z0xGQhLTVQ9in4jYLYGt2MQF42JKA12IdSs1G5tzfSUi6S8H5ymtVIn4poSVG2cOKTT7+ElfbdDM3uLI3jLBy0MJ1xN2aUVdZcMXX9Nyi5VU+C8se8nU5r0fqGMo+fBBjCcQ/CP8aQMS1/Xl3yI8S00dFobV7HEENeWIJKGEaQi7+r3XCn/oLiXuzPzzo/FncIMZC8KR1qLZBm82yxnZX6GKu1KocA/uN/uDfFLB2+mbgrS/lgltcXkMn05+o4dvW15GccICGStZ8CqlCxGC1opQsQHvEJEtKCc11+Ft7Or+t6Ha24t7o25RVKzHD5W7CtTbKXOyw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39850400002)(39400400002)(39410400002)(39450400003)(2900100001)(99936001)(6506006)(2501003)(25786009)(54356999)(77096006)(2950100002)(7736002)(50986999)(229853002)(6436002)(76176999)(7696004)(66066001)(5660300001)(99286003)(122556002)(53546009)(6306002)(54896002)(9686003)(55016002)(53936002)(2906002)(38730400002)(189998001)(3280700002)(3660700001)(33656002)(74316002)(8936002)(86362001)(8676002)(6246003)(81166006)(790700001)(6116002)(3846002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0625; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 5ab1134a-e127-47b1-2817-08d4769b6b38 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM2PR07MB0625; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006041)(93001041)(6055026)(6041248)(20161123558025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:AM2PR07MB0625; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0625; x-forefront-prvs: 0261CCEEDF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0AB8_01D2A895.0A763C40" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 12:02:05.4031 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0625 Archived-At: Subject: Re: [netmod] Question about must statement in grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 12:02:18 -0000 ------=_NextPart_000_0AB8_01D2A895.0A763C40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0AB9_01D2A895.0A763C40" ------=_NextPart_001_0AB9_01D2A895.0A763C40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Changing "count(.) != 1" into "count(../a-list) != 1" in the grouping does the job as expected. So it seems that count(.) within the context of the a-list applies to each element in the list and rather than to the list itself? Regards, Bart From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Bogaert, Bart (Nokia - BE/Antwerp) Sent: 29 March 2017 12:47 To: netmod@ietf.org Subject: [netmod] Question about must statement in grouping Hi, We have a question on the usage of a must statement within a grouping. Assume the following grouping grouping a-group { list a-list { must "count(.) != 1" { description "This list must either be empty or have at least 2 elements"; } key "entry"; leaf entry { type uint16; } leaf another-entry { type uint32; } } } And used in another module container a-container { uses a-group; } The uses actually results in a data-tree like below +--rw a-container +--rw a-list* [entry] +--rw entry uint16 +--rw another-entry uint32 Does the usage of the grouping usage also result in the expected behavior for the must statement when configuring /a-container/a-list? The '.' in the must statement in the grouping refers to 'a-list' so will that return 2 in case we have configured 2 elements in /a-container/a-list or should we write the must statement at the level of 'a-container' stating that "count(a-list) != 1" (as below)? grouping a-group { list a-list { key "entry"; leaf entry { type uint16; } } } And used in another module container a-container { uses a-group; must "count(a-list) != 1" { description "This list must either be empty or have at least 2 elements"; } } Best regards - Vriendelijke groeten, Bart Bogaert ------=_NextPart_001_0AB9_01D2A895.0A763C40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Changing “count(.) !=3D 1” into = “count(../a-list) !=3D 1” in the grouping does the job as = expected.  So it seems that count(.) within the context of the = a-list applies to each element in the list and rather than to the list = itself?

 

Regards, Bart

 

From: netmod = [mailto:netmod-bounces@ietf.org] On Behalf Of Bogaert, Bart = (Nokia - BE/Antwerp)
Sent: 29 March 2017 12:47
To: = netmod@ietf.org
Subject: [netmod] Question about must = statement in grouping

 

Hi,

 

We have a question on the usage of a must statement within = a grouping.

 

Assume the following grouping

 

grouping a-group = {

  list a-list = {

    = must “count(.) !=3D 1” {

      description

        “This list must = either be empty or have at least 2 = elements”;

    }

    = key “entry”;

    leaf entry {

      type = uint16;

    = }

  =   leaf another-entry {

    =   type uint32;

    }

  = }

}

 

And used in another module

 

container = a-container {

  = uses a-group;

}

 

The uses actually results in a data-tree like = below

 

  = +--rw a-container

      +--rw a-list* = [entry]

           +--rw = entry  =          uint16

           +--rw = another-entry   uint32

 

Does the usage of the grouping = usage also result in the expected behavior for the must statement when = configuring /a-container/a-list?  The ‘.’ in the must = statement in the grouping refers to ‘a-list’ so will that = return 2 in case we have configured 2 elements in /a-container/a-list or = should we write the must statement at the level of = ‘a-container’ stating that “count(a-list) !=3D = 1” (as below)?

 

grouping a-group {

  = list a-list {

    key = “entry”;

    leaf entry {

      type = uint16;

    = }

  = }

}

 

And used in another module

 

container = a-container {

  = uses a-group;

  = must “count(a-list) !=3D 1” {

    = description

      “This list must either be = empty or have at least 2 elements”;

  = }

}

 

Best regards - Vriendelijke groeten,

Bart Bogaert

------=_NextPart_001_0AB9_01D2A895.0A763C40-- ------=_NextPart_000_0AB8_01D2A895.0A763C40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjkxMjAyMDJaMCMGCSqGSIb3DQEJBDEWBBTrel2v ccn++6M7JhRKmPIuR5UljzCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAJ9Rybkip5Dy0stsQGk9MlOEosbeA7doe/KmFXYTHlUf+T+708ndGFgXz/Jf /ZBhK0fUP7ew44BNAoRFTQqISfOeSQP14gLsb4SDV0d+TU2GliixPjHdz/N5Va5C1BrNu+MSI17e eLdJou9hVvSdp8BEkriZUugX8PNPskPK4Ztvr/KMEaHBrRxzXiGArSV4dPd/fE3UeRh7gnu0XX8X /I+uYmNdTMLNChhR33o8UOpQ72ZB0dOT6m/K9udaOe7wPSpXkgKVlfRxWihGbQV6B+Ef9w/pVwfZ tp6d8iZBmdKmjNPGSNMIiopOYbEe/RArTVlZDIzt2ERypd/WEGLOPQMAAAAAAAA= ------=_NextPart_000_0AB8_01D2A895.0A763C40-- From nobody Wed Mar 29 05:37:12 2017 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 A4ABD1296C7 for ; Wed, 29 Mar 2017 05:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UChjQV12Z-j1 for ; Wed, 29 Mar 2017 05:37:09 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 45064126B7F for ; Wed, 29 Mar 2017 05:37:09 -0700 (PDT) Received: from localhost (dhcp-93d7.meeting.ietf.org [31.133.147.215]) by trail.lhotka.name (Postfix) with ESMTPSA id E9B34182000E; Wed, 29 Mar 2017 14:35:33 +0200 (CEST) From: Ladislav Lhotka To: "Bogaert\, Bart \(Nokia - BE\/Antwerp\)" , "Bogaert\, Bart \(Nokia - BE\/Antwerp\)" , "netmod\@ietf.org" In-Reply-To: References: Date: Wed, 29 Mar 2017 07:37:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Question about must statement in grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 12:37:11 -0000 "Bogaert, Bart (Nokia - BE/Antwerp)" writes: > Changing "count(.) != 1" into "count(../a-list) != 1" in the grouping does > the job as expected. So it seems that count(.) within the context of the > a-list applies to each element in the list and rather than to the list > itself? Both versions of the XPath expression are evaluated once for each entry of the list, and the entry's 'a-list' node is the context node. By definition, '.' selects the context node, so 'count(.)' is always 1. After the change, '..' selects the parent node and 'a-list' then selects all nodes of that name, which are the entries of the list. Note that it would be more efficient to verify the constraint on the parent container, with 'count(a-list) != 1'. Lada > > > > Regards, Bart > > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Bogaert, Bart > (Nokia - BE/Antwerp) > Sent: 29 March 2017 12:47 > To: netmod@ietf.org > Subject: [netmod] Question about must statement in grouping > > > > Hi, > > > > We have a question on the usage of a must statement within a grouping. > > > > Assume the following grouping > > > > grouping a-group { > > list a-list { > > must "count(.) != 1" { > > description > > "This list must either be empty or have at least 2 elements"; > > } > > key "entry"; > > leaf entry { > > type uint16; > > } > > leaf another-entry { > > type uint32; > > } > > } > > } > > > > And used in another module > > > > container a-container { > > uses a-group; > > } > > > > The uses actually results in a data-tree like below > > > > +--rw a-container > > +--rw a-list* [entry] > > +--rw entry uint16 > > +--rw another-entry uint32 > > > > Does the usage of the grouping usage also result in the expected behavior > for the must statement when configuring /a-container/a-list? The '.' in the > must statement in the grouping refers to 'a-list' so will that return 2 in > case we have configured 2 elements in /a-container/a-list or should we write > the must statement at the level of 'a-container' stating that "count(a-list) > != 1" (as below)? > > > > grouping a-group { > > list a-list { > > key "entry"; > > leaf entry { > > type uint16; > > } > > } > > } > > > > And used in another module > > > > container a-container { > > uses a-group; > > must "count(a-list) != 1" { > > description > > "This list must either be empty or have at least 2 elements"; > > } > > } > > > > Best regards - Vriendelijke groeten, > > Bart Bogaert > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 29 05:43:43 2017 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 E37FA1296D7 for ; Wed, 29 Mar 2017 05:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 GX3fJ6CulZKr for ; Wed, 29 Mar 2017 05:43:34 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0138.outbound.protection.outlook.com [104.47.2.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D7A1296D6 for ; Wed, 29 Mar 2017 05:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Dz+eP71iVk3y5o+U+Pmo65aItbfpFjpYkHsqsu9EWxk=; b=ASEBYNq/LsQVezJRHzEbE6Qov7nkaYgJ36Fc380aokc4SncpoPBjhPyksBPpQ8zuv2cxBriSFdOHGtr/egd74VrQJ2kmWGT1aGwSiKrYiK0H8zIPAZ7hbdQJAXq07pN4VF/8l+rPApJ0YXBYdM35dYHcOZDMkEbExD9a04t/m2o= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0628.eurprd07.prod.outlook.com (10.160.54.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 12:43:30 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 12:43:31 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] Question about must statement in grouping Thread-Index: AdKob59zUH9BTX/5SB69vtC6sOJtgAAFDffAAAFU4oAAADA8MA== Date: Wed, 29 Mar 2017 12:43:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.20] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0628; 7:UMmeObg5T17s4w8Ofh7XHdeBsAUYakeFLSiCIIJ3XgDsm2BYwavpg1T71FRqE7cUtCKR1qzkiJozT6iZRlPrchBMv99nT2v2ry9BE7AOGK9WCoCWIU0/tQDndl7HDwOtvapZzqqynjBT1t72OcZIJnsTX6OdrSQ3G9+F4MQBXJ/9/KxM7MfH20OkQaxWh4pVyUrv6WO0QmQnmyeKkd5pCaR7CUouSh/0OIpVu2s2lyTdnYQ5wL+dwuu99YdiXiHBGyP3FZY6UVHMyah1o5o27gG9NGAUK8D8X9UrQgurjE06fU4JEvEUIkjXlk/LtPouLlJihrrh/zddeznVdhGjtw== x-ms-office365-filtering-correlation-id: 5f4dee90-0791-47b6-a5dc-08d476a134d7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM2PR07MB0628; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123564025)(6072148); SRVR:AM2PR07MB0628; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0628; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39450400003)(39840400002)(39860400002)(39400400002)(39410400002)(39850400002)(51914003)(13464003)(76176999)(33656002)(50986999)(6306002)(54356999)(9686003)(99936001)(5660300001)(53936002)(38730400002)(2950100002)(6116002)(6436002)(3846002)(3280700002)(77096006)(6506006)(6246003)(3660700001)(102836003)(7696004)(2906002)(122556002)(8936002)(74316002)(99286003)(81166006)(55016002)(66066001)(8676002)(86362001)(229853002)(305945005)(2900100001)(189998001)(2501003)(7736002)(25786009)(53546009)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0628; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0AE6_01D2A89A.D457CEC0" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 12:43:31.2531 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0628 Archived-At: Subject: Re: [netmod] Question about must statement in grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 12:43:37 -0000 ------=_NextPart_000_0AE6_01D2A89A.D457CEC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Lada, thanks for the feedback. Any specific reason why you say that this would be more efficient when used in the context of the parent container and not in the grouping? Regards, Bart -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz] Sent: 29 March 2017 14:37 To: Bogaert, Bart (Nokia - BE/Antwerp) ; Bogaert, Bart (Nokia - BE/Antwerp) ; netmod@ietf.org Subject: Re: [netmod] Question about must statement in grouping "Bogaert, Bart (Nokia - BE/Antwerp)" writes: > Changing "count(.) != 1" into "count(../a-list) != 1" in the grouping > does the job as expected. So it seems that count(.) within the > context of the a-list applies to each element in the list and rather > than to the list itself? Both versions of the XPath expression are evaluated once for each entry of the list, and the entry's 'a-list' node is the context node. By definition, '.' selects the context node, so 'count(.)' is always 1. After the change, '..' selects the parent node and 'a-list' then selects all nodes of that name, which are the entries of the list. Note that it would be more efficient to verify the constraint on the parent container, with 'count(a-list) != 1'. Lada > > > > Regards, Bart > > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Bogaert, > Bart (Nokia - BE/Antwerp) > Sent: 29 March 2017 12:47 > To: netmod@ietf.org > Subject: [netmod] Question about must statement in grouping > > > > Hi, > > > > We have a question on the usage of a must statement within a grouping. > > > > Assume the following grouping > > > > grouping a-group { > > list a-list { > > must "count(.) != 1" { > > description > > "This list must either be empty or have at least 2 elements"; > > } > > key "entry"; > > leaf entry { > > type uint16; > > } > > leaf another-entry { > > type uint32; > > } > > } > > } > > > > And used in another module > > > > container a-container { > > uses a-group; > > } > > > > The uses actually results in a data-tree like below > > > > +--rw a-container > > +--rw a-list* [entry] > > +--rw entry uint16 > > +--rw another-entry uint32 > > > > Does the usage of the grouping usage also result in the expected > behavior for the must statement when configuring /a-container/a-list? > The '.' in the must statement in the grouping refers to 'a-list' so > will that return 2 in case we have configured 2 elements in > /a-container/a-list or should we write the must statement at the level > of 'a-container' stating that "count(a-list) != 1" (as below)? > > > > grouping a-group { > > list a-list { > > key "entry"; > > leaf entry { > > type uint16; > > } > > } > > } > > > > And used in another module > > > > container a-container { > > uses a-group; > > must "count(a-list) != 1" { > > description > > "This list must either be empty or have at least 2 elements"; > > } > > } > > > > Best regards - Vriendelijke groeten, > > Bart Bogaert > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ------=_NextPart_000_0AE6_01D2A89A.D457CEC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMjkxMjQzMjhaMCMGCSqGSIb3DQEJBDEWBBT4csof vsRaqwjUGVnpv1YYGDwh4zCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAHXAVzmH7k7JJQwQADVbWngnbME3TJYtw9gqjIRKFfkxH/tYHfk5UuECWf6r mfDraDIVhTe10w3+znM53dxqBD2+uy9C4hs49t/ibxJJH4NGU+66gLcMMq157n9pwBy5vuQw9a1A iu6rb4W64k/a9g8vJ1AG5K6J+0l9rmcLS84MF9coe/Kf7s6SYvW3jAylneCYUFJ0QcBmEqdiAXxE DUlzVg5QhIqjzLO/lC005pVNh2Cg/4JoGZT2XpoegdIAG+nKj4ZAvVJOBT8OFxORl3m4teg+1WqI +YMLEvb7fuJy8SzeC9T2WlHHoUQSJ38hDTg7a1Mg1PineLnKhTnGhqIAAAAAAAA= ------=_NextPart_000_0AE6_01D2A89A.D457CEC0-- From nobody Wed Mar 29 07:11:30 2017 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 CEA91124D37 for ; Wed, 29 Mar 2017 07:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 st6xji7LA6Z0 for ; Wed, 29 Mar 2017 07:11:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9F5B1294C0 for ; Wed, 29 Mar 2017 07:11:25 -0700 (PDT) Received: from t2001067c03700128d56fa3cbcd67951e.v6.meeting.ietf.org (t2001067c03700128d56fa3cbcd67951e.v6.meeting.ietf.org [IPv6:2001:67c:370:128:d56f:a3cb:cd67:951e]) by mail.nic.cz (Postfix) with ESMTPSA id 0AD37622CC; Wed, 29 Mar 2017 16:11:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490796684; bh=WKGD16KReMIh7xVfDkLBbY2r5n8NNW2A3jN2aQDwI5Y=; h=From:Date:To; b=LdJZjiA1S9spbN8VGOQqtr1lpwcRWgPQjKttKZzDoyNtg8kdAgM2J6xl01A9mdrS5 cnUgsf1Xzcd0WWM0uA+2jGlwTaX/l9EkfSyXpj0YuuEBKUdqmVKvS2UVPJ1eLt+A7V sKJNbxZmmYpf9a7Cs7su4iPk9nG4NVM4Nk0gusz4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 29 Mar 2017 09:11:21 -0500 Cc: "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <878E52CD-EF16-4E01-949C-03C88ABCEF5B@nic.cz> References: To: "Bogaert, Bart (Nokia - BE/Antwerp)" X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Question about must statement in grouping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 14:11:29 -0000 > On 29 Mar 2017, at 07:43, Bogaert, Bart (Nokia - BE/Antwerp) = wrote: >=20 > Lada, thanks for the feedback. >=20 > Any specific reason why you say that this would be more efficient when = used > in the context of the parent container and not in the grouping? As I wrote, the expression is evaluated once for each entry, always with = the same result. It may or may not be a problem depending on the number = of entries. Lada=20 >=20 > Regards, Bart >=20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 > Sent: 29 March 2017 14:37 > To: Bogaert, Bart (Nokia - BE/Antwerp) ; = Bogaert, > Bart (Nokia - BE/Antwerp) ; netmod@ietf.org > Subject: Re: [netmod] Question about must statement in grouping >=20 > "Bogaert, Bart (Nokia - BE/Antwerp)" writes: >=20 >> Changing "count(.) !=3D 1" into "count(../a-list) !=3D 1" in the = grouping=20 >> does the job as expected. So it seems that count(.) within the=20 >> context of the a-list applies to each element in the list and rather=20= >> than to the list itself? >=20 > Both versions of the XPath expression are evaluated once for each = entry of > the list, and the entry's 'a-list' node is the context node. By = definition, > '.' selects the context node, so 'count(.)' is always 1. After the = change, > '..' selects the parent node and 'a-list' then selects all nodes of = that > name, which are the entries of the list. >=20 > Note that it would be more efficient to verify the constraint on the = parent > container, with 'count(a-list) !=3D 1'. >=20 > Lada >=20 >>=20 >>=20 >>=20 >> Regards, Bart >>=20 >>=20 >>=20 >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Bogaert,=20= >> Bart (Nokia - BE/Antwerp) >> Sent: 29 March 2017 12:47 >> To: netmod@ietf.org >> Subject: [netmod] Question about must statement in grouping >>=20 >>=20 >>=20 >> Hi, >>=20 >>=20 >>=20 >> We have a question on the usage of a must statement within a = grouping. >>=20 >>=20 >>=20 >> Assume the following grouping >>=20 >>=20 >>=20 >> grouping a-group { >>=20 >> list a-list { >>=20 >> must "count(.) !=3D 1" { >>=20 >> description >>=20 >> "This list must either be empty or have at least 2 elements"; >>=20 >> } >>=20 >> key "entry"; >>=20 >> leaf entry { >>=20 >> type uint16; >>=20 >> } >>=20 >> leaf another-entry { >>=20 >> type uint32; >>=20 >> } >>=20 >> } >>=20 >> } >>=20 >>=20 >>=20 >> And used in another module >>=20 >>=20 >>=20 >> container a-container { >>=20 >> uses a-group; >>=20 >> } >>=20 >>=20 >>=20 >> The uses actually results in a data-tree like below >>=20 >>=20 >>=20 >> +--rw a-container >>=20 >> +--rw a-list* [entry] >>=20 >> +--rw entry uint16 >>=20 >> +--rw another-entry uint32 >>=20 >>=20 >>=20 >> Does the usage of the grouping usage also result in the expected=20 >> behavior for the must statement when configuring /a-container/a-list? = =20 >> The '.' in the must statement in the grouping refers to 'a-list' so=20= >> will that return 2 in case we have configured 2 elements in=20 >> /a-container/a-list or should we write the must statement at the = level=20 >> of 'a-container' stating that "count(a-list) !=3D 1" (as below)? >>=20 >>=20 >>=20 >> grouping a-group { >>=20 >> list a-list { >>=20 >> key "entry"; >>=20 >> leaf entry { >>=20 >> type uint16; >>=20 >> } >>=20 >> } >>=20 >> } >>=20 >>=20 >>=20 >> And used in another module >>=20 >>=20 >>=20 >> container a-container { >>=20 >> uses a-group; >>=20 >> must "count(a-list) !=3D 1" { >>=20 >> description >>=20 >> "This list must either be empty or have at least 2 elements"; >>=20 >> } >>=20 >> } >>=20 >>=20 >>=20 >> Best regards - Vriendelijke groeten, >>=20 >> Bart Bogaert >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 29 09:29:35 2017 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 87B581243F3 for ; Wed, 29 Mar 2017 09:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 MYD_wAESt1XO for ; Wed, 29 Mar 2017 09:29:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F37129450 for ; Wed, 29 Mar 2017 09:29:30 -0700 (PDT) Received: from t2001067c03700128c5a9ef37722ff64e.v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:128:c5a9:ef37:722f:f64e]) by mail.nic.cz (Postfix) with ESMTPSA id 3CF7962396 for ; Wed, 29 Mar 2017 18:29:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490804969; bh=tXcle+Kd7QLR+sYvLL2h274YOmnDhBXH+37Pl92gd1A=; h=From:Date:To; b=q1oB+AGzayebmP9l0Si/TuJTkJ3jU7Rx3yRRbHLpfVJoGX3ERVeKjkMevxlBbxods tpBG+0EN7maoHtY4irJ4TdIUzBhpCvpqz7sCNZiWLANboA3YsVZW1AYUvfYS0tQ5G1 QQV+aov1Kn9LkwBe2DMsx3qulHdBv/COcQ/Ax0vk= From: Ladislav Lhotka Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Wed, 29 Mar 2017 11:29:16 -0500 To: NETMOD WG X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] YANG library with datastores and schema mount X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:29:33 -0000 Hi, I put together an initial mockup of the idea that I talked about = yesterday =E2=80=93 unified YANG library subsuming datastores and schema = mount: = https://github.com/netmod-wg/schema-mount/wiki/YANG-Library-with-Datastore= s-and-Schema-Mount Notes: - The data consists of the lists: "module", "datastore" and "schema". - The "module" part is exactly identical to the current YANG library: it = defines modules with revisions, supported features etc. These modules = can then be referenced (repeatedly) in the "schema" part to build up the = overall data model. The assumption is that every module can be = implemented only in one version. - The "datastore" part lists the available datastores and defines, = perhaps along with other things, the schema by referring to one or more = entries of the "schema" list. A named schema can be used in any number = of datastores. - Each entry of the "schema" part lists the schema's "top-level" modules = and, optionally, mounted schemas. - YANG library will not only be provided as state (meta)data by servers, = it can also be thought of as a companion data modelling mini-language to = YANG where YANG defines modules and YANG Library tells everything about = how they fit together. I envision that both can be also used in RFCs for = specifying data models. The mockup is really just a quick kick-off, most things can be discussed = and done differently, but I believe it is important to have all this = information represented in a compact way and in a single place. Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 29 13:42:10 2017 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 8421B1201F2; Wed, 29 Mar 2017 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 gGmLV8P5-rxf; Wed, 29 Mar 2017 13:42:06 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0098.outbound.protection.outlook.com [23.103.200.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74055129481; Wed, 29 Mar 2017 13:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w3Gma++M9mODIA8/U+rJLTU2z37VjY89vzwisgNlYyI=; b=mDBytFIu/s6c65I+1o8OErJY2xzT6TfzqPchKLjvDoKZmoSZCna4xB099oUnG8/e+AFTPy9nLb2ReJIiLk/ltF1yiU0BVnHg0fk7bm0NjbYnRaUz7wNrXubW6v7qjdcHFtBLglX9mIHPYIOL8y9kgdN8eSHw1XSdHuwtAAAZ10M= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Wed, 29 Mar 2017 20:42:04 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.021; Wed, 29 Mar 2017 20:42:04 +0000 From: "Waltermire, David A. (Fed)" To: "saag@ietf.org" , "opsawg@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" Thread-Topic: PANIC Bar BoF Tonight @ 6:30pm CDT Thread-Index: AdKoyz/2/d9baDSGTnuHD2EJjZ7Mgw== Date: Wed, 29 Mar 2017 20:42:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.222.87] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1440; 7:MRz0WSeTiWWcEhsHvpdzglCWeYt10yvdJL2HAM7tWMGoGl4fZ6pjnisT6YM4hGexNOoWOCm5NeE3pWeaCCBiezL3s0n0EVCAoLPMstiTbJEmLCN46tegb36TvmcCDHqJo8cU+YuenCc6+3tO74BzGcpl3tyywY0a6G2mNqIK68Q/FhptBRZZxWy/LoL6AEX0Pr4RRpmuAnL7M3lYf/4RI4jjDz81lgkDjfo3qZ0y+bI5jSWddlbyxn1HC7xwDAZ6ZfsO1t29VTfNbUPR2LNjA3INADhXpccxGwzlPnlN25nJSvJYCZfdBwwgmQNAibjz2eqxMzcK5U8D5H9xmwaILQ== x-ms-office365-filtering-correlation-id: ca08842c-5a57-4a1f-02fa-08d476e40f60 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:MWHPR09MB1440; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:MWHPR09MB1440; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1440; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39450400003)(39850400002)(39400400002)(7696004)(6506006)(2501003)(53936002)(77096006)(74316002)(305945005)(9686003)(55016002)(33656002)(6436002)(99286003)(8676002)(81166006)(8936002)(3660700001)(2201001)(86362001)(25786009)(102836003)(3280700002)(50986999)(54356999)(2900100001)(3846002)(189998001)(6116002)(2906002)(5660300001)(7736002)(122556002)(38730400002)(450100002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1440; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 20:42:04.5631 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1440 Archived-At: Subject: [netmod] PANIC Bar BoF Tonight @ 6:30pm CDT X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 20:42:08 -0000 Just a quick reminder... the Posture Assessment through Network Information= Collection (PANIC) bar BoF is tonight right after the IETF 98 Technical an= d Administrative Plenary at 6:30pm CDT in Vevey 4 at the Swissotel Conferen= ce Center. We are hoping to start a discussion about how to leverage the ex= isting IETF network management protocols to best address security automatio= n for network infrastructure devices. We would like your ideas on how to be= st pursue this work, and your insights into network infrastructure security= problems that will impact our networks in the future. We are holding a sid= e meeting at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a disc= ussion about how to move forward on this topic. Given the late hour, we will have some light snacks. We hope to see you the= re. Regards, David Waltermire From nobody Thu Mar 30 11:55:58 2017 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 7915E1201FA; Thu, 30 Mar 2017 11:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqBUuJgND5qH; Thu, 30 Mar 2017 11:55:54 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0C2126B72; Thu, 30 Mar 2017 11:55:53 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2UItp2e030653; Thu, 30 Mar 2017 19:55:51 +0100 Received: from 950129200 (dhcp-8535.meeting.ietf.org [31.133.133.53]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2UItnCp030630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Mar 2017 19:55:50 +0100 Reply-To: From: "Adrian Farrel" To: , Date: Thu, 30 Mar 2017 19:55:51 +0100 Message-ID: <042d01d2a987$414844a0$c3d8cde0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKphlqOZxnzPxBmRdajq9pU3vTa7Q== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22976.001 X-TM-AS-Result: No--3.130-10.0-31-10 X-imss-scan-details: No--3.130-10.0-31-10 X-TMASE-MatchedRID: ZeZXEHjiKRlS/isIEXGDv7u9iqQJLR0vh8Ytn75ClDNVCJR4LoJu4rC/ tyr/qneUptiFgxvHaW9GXdPR9R77GDhkyYEbqgcm+cKX6yCQ13uz5LIh2+IOfNoVfIzJhiw0nKQ gYq4pRtmFu+YpukiIJh9l1zPMOb+6TX7PJ/OU3vL+xOhjarOnHt0H8LFZNFG7CKFCmhdu5cXrdo rMz3unsoBZ360Bo2Fs0TbVdHbBlre03CpH8K7VIKRIZlQ8ceOTRUa/cBCi+N9LgVu0TC67A0ob6 bMXcgBXJNOtXGWfATeRzy9lhw/CZKG6tVpjWHJfjF1XCR4TdrdTI6qsXPa6iJ6oP1a0mRIj Archived-At: Subject: [netmod] Progress of draft-ietf-netmod-yang-model-classification and draft-wu-opsawg-service-model-explained X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 18:55:57 -0000 Hi, As just stated at the mic in the OPS Area meeting, I met with Dean Bogdanovic today to discuss the overlap/underlap between these two drafts. 1. We went through the text changes to draft-ietf-netmod-yang-model-classification and I am happy that changes in the -05 revision address the questions I have been asking. I do see two nits: a. draft-ietf-l3sm-l3vpn-service-model is now RFC 8049 b. The paragraph that references that document is perfect and correct, but may be slightly out of place as its current position suggests that it is a "Network Service model" where I think that Dean and I have agreed that it is actually one level higher (a business service model in his language) and so basically out of scope of this document. I would suggest moving this paragraph to be the last paragraph in Section 2.1. 2. draft-wu-opsawg-service-model-explained We will revise this document to align a little more closely with the language in draft-ietf-netmod-yang-model-classification and (more important) to not re-state (even in different language) what is in draft-ietf-netmod-yang-model-classification. I believe this will address all open worries in the document that have been expressed on the list. Thanks, Adrian From nobody Thu Mar 30 14:10:41 2017 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 4BDC9129583; Thu, 30 Mar 2017 14:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7MuL1UCXfPV; Thu, 30 Mar 2017 14:10:23 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::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 60722129483; Thu, 30 Mar 2017 14:09:32 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id g2so49777515pge.3; Thu, 30 Mar 2017 14:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d7n0OsvI/E7+Yq5EncNM9IcshiVZcXglle39gzrq8Dc=; b=ih8nvURFKBQYdAAxqj3PCbkKDGGUS1bUlcMZMvwAAyBvP1fG38yLaZn79WUrK3U+HM Anoq9z+WGsfkWUoodyGhb/GbsF9+iRSMwPK4OvVq0Hx20Ro2KmxK5Wgwkh5AfEvKMa8R E7Sml4iBo6oVeEQGJ7YYLD3kY8yQOoJgSXaEcJ8SjGACxId1GoPpfJjgp30kd8li5FU8 A79ORrCsbHXkFCCQl2brQfUWPO6DTO04TJ1LCxIcghZO1bAY0hYx/7DvjibAEtGryjEQ 2Q3/fC6BWTTCVebtBixpsYxYu006keBevnABnk3L9YY1wMIV14cTXCQNCVaHS7Ie5t0v KWFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d7n0OsvI/E7+Yq5EncNM9IcshiVZcXglle39gzrq8Dc=; b=n+62Z6GQQGvBUky4ktktzai45icgI+TN/HFngZMkhFbHOsiumoQyWUFZwGzhAaH95f bezxVHU4g0j1A/tdkVQmNMvvwB0UE0jCHYddCWUpRWbtQtrrbDWGtvhYsFNfJl5DRJEq i/6b73/S3EMQExTXobywjdcB7JxD5oPU8Mpd7GBR6tqOY+gt7zt7CrtquN7o9WRvmmzd 2Yx7NK/qKUjg8JwS/tVk3Ox8YlVDg6kV22eGbe6/sE/2Pyz/PZYjapM0t4pIxONczuBy 8WMVJZvHMd/QuwKQT+jacuOzabfKd9fjGZ45/uJflnkyekotX2mXpFLL7P7SeU3vYPv/ hdeA== X-Gm-Message-State: AFeK/H1FThdrfqT9Yk+sPekffJkWhKQQ9ykryI8h8495srZHvSZPFu2vOuSuX6biZUxX2g== X-Received: by 10.84.149.168 with SMTP id m37mr1342822pla.97.1490908171684; Thu, 30 Mar 2017 14:09:31 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1006::483? ([2001:420:c0c8:1006::483]) by smtp.gmail.com with ESMTPSA id b80sm6178658pfe.87.2017.03.30.14.09.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Mar 2017 14:09:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Thu, 30 Mar 2017 16:09:28 -0500 Cc: "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "mile@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> References: To: "Waltermire, David A. (Fed)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:10:25 -0000 David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) = wrote: >=20 >=20 > The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture = information from enterprise endpoints. Collecting this information is = critical to support automation of common network security tasks, = including asset, software, vulnerability, and configuration management. = Thus far, our efforts have focused primarily on standards to collect = information in support of asset, software and vulnerability management = use cases, and has worked with other IETF members to determine what data = would need to be to be collected, and how that data would be securely = communicated across the network. Through such exchanges an organization = can know what client endpoints are connected to their network, and if = they are vulnerable to attack. >=20 > Given the proliferation of attacks against network infrastructure = devices, it is clear that the next step in our enterprise security = automation effort must be to enable standardized reporting of similar = information from network infrastructure devices. With the growing number = of Yang models and increased adoption of NETCONF, RESTCONF, and related = protocol work, the time is right to work out how these standards can be = used to measure the health of network devices. This information will, as = in our efforts in SACM for client devices, support asset, software, = vulnerability, and configuration management use cases. Standards-based = reporting of this information from network infrastructure devices will = help network defenders protect against known attacks, and provide the = necessary knowledge to detect and mitigate future attacks.=20 >=20 > We would like to start a discussion about how to leverage the existing = IETF network management protocols to best address security automation = for network infrastructure devices. We would like your ideas on how to = best pursue this work, and your insights into network infrastructure = security problems that will impact our networks in the future. We are = holding a side meeting at IETF 98 on Wednesday, March 29th at 6:30pm CDT = to start a discussion about how to move forward. We will be meeting in = Vevey 4 at the IETF meeting venue. Maybe this was discussed in the BoF =E2=80=A6 The best way to have a discussion would be to present the proposal in = the form of a draft in the NETCONF WG. >=20 > Here is a summary of the meeting details: >=20 > PANIC (Posture Assessment through Network Information Collection) Bar = BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 >=20 > We look forward to working with you, and hope to see you in Chicago at = the PANIC Bar BoF. >=20 > Regards, > Dave >=20 > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com From nobody Thu Mar 30 14:38:38 2017 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 1EC5C12957A; Thu, 30 Mar 2017 14:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 v7Vjhi8uSBcT; Thu, 30 Mar 2017 14:38:15 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0125.outbound.protection.outlook.com [23.103.201.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EF512953D; Thu, 30 Mar 2017 14:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fhpXRk2GXCuvUgvGh+EBOd5yyb2hEdf9Y+A3Gg7UDCg=; b=sAc443pJMGmmB+rvDgp7auJLvAC5gpLiBEDJZEPjRDx2tjaJxhhxxBBYTBFaNYT7r1L5cEZW4xb2P1+pFGJJt/59jajXXYjQq6my+i+q4m3tW9sqUmVpH3e2B/srI8UyQ6J51tXSkLdqjMusOzw/hadQM6auuofO1ACthGQoF7I= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1439.namprd09.prod.outlook.com (10.173.50.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Thu, 30 Mar 2017 21:38:12 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.022; Thu, 30 Mar 2017 21:38:12 +0000 From: "Waltermire, David A. (Fed)" To: Mahesh Jethanandani CC: "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "mile@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8= Date: Thu, 30 Mar 2017 21:38:12 +0000 Message-ID: References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> In-Reply-To: <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2600:1008:b026:3c5b:880a:2104:6fcd:5c70] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1439; 7:fmv4/kXlxEmSHZh/xh02rUjNmsl0GtUs05jZK7Y5JFRT7yWIkni0cnk2SgQZQiUNjYRZoLTnk2WVzy2tCEDpK/MoPb0+MisFwIhwqY7uvEPHQImImx+ebtTn0hJtnaWMEmV7pq9rZr2QBgjyDuh9QztAe0k32sStINXMDl60EX5w7kYmusucQ30aor9koMF+Y8/Hu2M38uMklSJ8lRhVyow5dlcSQdFVdmvwNSf4UNqt3lKNTYgUjlssksNS34F6d7+giRWkjm1pv2qSf+qBTaFSFyyxEN9VzCtC8O2KSxODbLjhj9Rbo5kQIwP5FXsI/7rkguFdPdU4We0kC7Q3Vg== x-ms-office365-filtering-correlation-id: 0b91b875-39a5-4d7b-8e91-08d477b510f1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:MWHPR09MB1439; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(192374486261705)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:MWHPR09MB1439; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1439; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39840400002)(39850400002)(39450400003)(39400400002)(39410400002)(24454002)(377454003)(33716001)(2950100002)(81166006)(229853002)(8676002)(8936002)(1411001)(2900100001)(2860100001)(7736002)(102836003)(2920100001)(6116002)(86362001)(3280700002)(5660300001)(3660700001)(7906003)(55846006)(6916009)(6486002)(77096006)(2906002)(6506006)(606005)(6436002)(99286003)(6306002)(9686003)(54896002)(54906002)(6512007)(53936002)(561944003)(76176999)(54356999)(236005)(39060400002)(110136004)(33656002)(38730400002)(4326008)(6246003)(25786009)(122556002)(189998001)(50986999)(82676001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1439; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A406F4455056956FC17A5EEB332131B682A83BF7unknown_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 21:38:12.1393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1439 Archived-At: Subject: Re: [netmod] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:38:19 -0000 --_000_A406F4455056956FC17A5EEB332131B682A83BF7unknown_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We plan to write up a description adddessing the problem and ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" wr= ote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF =85 The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_A406F4455056956FC17A5EEB332131B682A83BF7unknown_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
We plan to write up a description adddessing the problem and 

On: 30 March 2017 16:09, "Mahesh Jethanandani" <mjethanandani@= gmail.com> wrote:
David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.walt= ermire@nist.gov> wrote:
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF =85

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.= ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com



 --_000_A406F4455056956FC17A5EEB332131B682A83BF7unknown_-- From nobody Thu Mar 30 14:44:02 2017 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 D922C1294FF; Thu, 30 Mar 2017 14:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 eqPa49MvjPl0; Thu, 30 Mar 2017 14:43:45 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0132.outbound.protection.outlook.com [23.103.200.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E2012960F; Thu, 30 Mar 2017 14:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Bgy2cJz1F/T9adb2KnkuXVvqo86DsAhG2xpN1H3tqTg=; b=xhzIPm+kHjjtlg+Qe7OsmT9AhZw12Iire5D5VWqeRcUHAQUkardpSdr0JGxrDR6vHaA/SWOEA27RohNM0PHXEpfPrP7M9Xc5ZFZkhN05yzlMvfwAOLXVYtocHhYxV6CWkeWuQNvC3CJWlNII1HAU7kqTBicxcqqh4PM8m5Poix0= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Thu, 30 Mar 2017 21:43:38 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.022; Thu, 30 Mar 2017 21:43:38 +0000 From: "Waltermire, David A. (Fed)" To: Mahesh Jethanandani CC: "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "mile@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AADCZJw== Date: Thu, 30 Mar 2017 21:43:38 +0000 Message-ID: <7623EF23448E9148C613E4C1A97C06377ECF6972@unknown> References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2600:1008:b026:3c5b:880a:2104:6fcd:5c70] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1440; 7:gPsskoOr3cXkVmihP4hWs0QtZDGbhd8A2Kp/gNTQmsAbfI9Cfi14UXdKY02b3Uvhv4lNfT2xRpurzw37oB8vbbmTWk+b5pY9bAA+oAptCjRd53sJNLJsbpknTcdhBOefZmtvZZEQd4auihnLBiPeu7KhahevujGV1BrnWa+a5q3h9nLJoXS0kjK3yu3cHsiMS+dOAGBjfXU2j8c7fy5jKMGNNH4tl90GwKU5yayxhUmqajLIG7AZwiWYTfGPl49ofLloK9WapwYrVh5vhfq5/BfLEwwdVlVDHUSiPQv1GG24u+MFCZfbY87JHPgeDZZV4pXs/ls/1IjLrpP7BnZhbg== x-ms-office365-filtering-correlation-id: 4dced6c9-e1e6-46be-7105-08d477b5d358 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:MWHPR09MB1440; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(192374486261705)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:MWHPR09MB1440; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1440; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39410400002)(39840400002)(39400400002)(39850400002)(39860400002)(24454002)(377454003)(6512007)(54356999)(9686003)(236005)(39060400002)(38730400002)(99286003)(81166006)(110136004)(54906002)(6506006)(6306002)(76176999)(54896002)(55846006)(6246003)(8676002)(2906002)(5660300001)(50986999)(7736002)(606005)(2920100001)(7906003)(2900100001)(2860100001)(122556002)(6436002)(25786009)(2950100002)(33716001)(3280700002)(8936002)(3660700001)(561944003)(86362001)(4326008)(1411001)(189998001)(77096006)(6486002)(33656002)(229853002)(102836003)(6116002)(53936002)(6916009)(82676001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1440; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_7623EF23448E9148C613E4C1A97C06377ECF6972unknown_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 21:43:38.1864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1440 Archived-At: Subject: Re: [netmod] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:43:48 -0000 --_000_7623EF23448E9148C613E4C1A97C06377ECF6972unknown_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry. Clicked send on my phone accidentally. We plan to write a draft describing the problem and scope of what we want t= o address. We will share this on the PANIC list and continue the conversati= on from there. We may want to present ideas in WGs like NETCONF at some tim= e in the future. We will know more once further discussion is had. Thanks, Dave ________________________________ On: 30 March 2017 16:38, "Waltermire, David A. (Fed)" wrote: We plan to write up a description adddessing the problem and ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" wr= ote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF =85 The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_7623EF23448E9148C613E4C1A97C06377ECF6972unknown_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Sorry. Clicked send on my phone accidentally.

We plan to write a draft describing the problem and scope = of what we want to address. We will share this on the PANIC list and contin= ue the conversation from there. We may want to present ideas in WGs&nb= sp;like NETCONF at some time in the future. We will know more once further discussion is had.

Thanks,
Dave

On: 30 March 2017 16:38, "Waltermire, David A. (Fed)" <david.w= altermire@nist.gov> wrote:
We plan to write up a description adddessing the problem and 

On: 30 March 2017 16:09, "Mahesh Jethanandani" <mjethanandani@= gmail.com> wrote:
David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.walt= ermire@nist.gov> wrote:
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF =85

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.= ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com



--_000_7623EF23448E9148C613E4C1A97C06377ECF6972unknown_-- From nobody Thu Mar 30 15:26:43 2017 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 76387129494; Thu, 30 Mar 2017 15:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 SSnFxnE6wQO9; Thu, 30 Mar 2017 15:26:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB941293EE; Thu, 30 Mar 2017 15:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13061; q=dns/txt; s=iport; t=1490912798; x=1492122398; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=19mVUMQghqkUXDVMyPEbKC6F3Nr1e6SrPaD79QcZXeE=; b=g/k9I3Rb/jz5+kQWtXEraOpwQ6cUwvvGx7WsDbRvL7yxcxWYFRF4tjTh kekVVgp1uRDnHDzTECp7c4WNMa0rYwJjEt0Nz1bGXWQgKVmC3lI8g9AJu GNy/RVmNYCfT7FCyUip1Vdepw5hp5Zs431KE+rg9LYfuXrA6ejJwbDEgg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQCdhd1Y/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm4/KWGBCweNbJFViBmIBoUxgg4fAQyCQIJsSgKDOD8YAQIBAQE?= =?us-ascii?q?BAQEBayiFFQEBAQECAQEBKzsGCwULAgEIGAwbByEGCxQRAQEEAQ0FCIg+gS0DD?= =?us-ascii?q?QgOrVuHKg2DIwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhk6Eb4JRRociBZwvOwG?= =?us-ascii?q?GfIcbhC+RQIpyiHoBHziBBVsVQYZZdYkCgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,249,1486425600"; d="scan'208,217";a="226906754" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Mar 2017 22:26:37 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v2UMQbBv000371 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Mar 2017 22:26:37 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Mar 2017 18:26:36 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 30 Mar 2017 18:26:36 -0400 From: "Eric Voit (evoit)" To: "Waltermire, David A. (Fed)" , "Mahesh Jethanandani" CC: "mile@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AAQkXsA== Date: Thu, 30 Mar 2017 22:26:36 +0000 Message-ID: <9ab236e3d421458e81f35534d2e13aaf@XCH-RTP-013.cisco.com> References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.244.210] Content-Type: multipart/alternative; boundary="_000_9ab236e3d421458e81f35534d2e13aafXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 22:26:41 -0000 --_000_9ab236e3d421458e81f35534d2e13aafXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David, I know it is early, but for the secure communication part, have you conside= red using the YANG Push work being developed in the NETCONF WG? With this approach, you can subscribe to state changes within a device's YA= NG models. These could be PANIC developed YANG models, existing YANG mode= ls such as IETF-System, IETF-keychain, or some combination. Then if a hac= ker inserts new hardware, changes software versions, adds keys, adds users,= etc. that state change can be securely pushed to a subscribing where it ca= n be determined whether the change was expected/desired. Eric ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" > wrote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) > wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF ... The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_9ab236e3d421458e81f35534d2e13aafXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi David,

 

I know it is early, but for the secur= e communication part, have you considered using the YANG Push work being developed in the NETCONF WG?

 

With this approach, you can subscribe= to state changes within a device‘s YANG models.  These could be= PANIC developed YANG models,  existing YANG models such as IETF-System, IETF-keychain, or some combination.   Then if a = hacker inserts new hardware, changes software versions, adds keys, adds use= rs, etc. that state change can be securely pushed to a subscribing where it= can be determined whether the change was expected/desired. 

 

Eric

On: 30 March 2017 16:09,= "Mahesh Jethanandani" <mjethanandani@gmail.com> wrote:

David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:=
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF …

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.= ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com


--_000_9ab236e3d421458e81f35534d2e13aafXCHRTP013ciscocom_-- From nobody Fri Mar 31 10:55:11 2017 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 200C9126D74; Fri, 31 Mar 2017 10:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 UoVXRZggRVzT; Fri, 31 Mar 2017 10:55:05 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607AD128DF6; Fri, 31 Mar 2017 10:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14467; q=dns/txt; s=iport; t=1490982905; x=1492192505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4vKofzxxu709iQwFQtlzKVJn2p8fQiwY0PGnr6QpS00=; b=l2aDiqbcpj7xjdQEZ05KQ1KvLLhimLfCcp1TQbbeQMdTvcHZ+IGKogLb LvXkjFC8E1vGvtMsnOdAsf2i9+NTz7Rto1rb0eyWSLneTd33C3yOQmWxs wcjXhlZN+5GexoYCUCaAGoNU/8rcs63Amiz5sDjNq5ZWUa9lpZmg0bCMe E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQBUl95Y/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm49KWGBCweNbZFUiBmIBoUxgg4fAQqCQoJsSgKDRz8YAQIBAQE?= =?us-ascii?q?BAQEBayiFFQEBAQECAQEBKzsGCwULAgEIEQQBAQEnByEGCxQJCAEBBA4FCIhAg?= =?us-ascii?q?S0DDQgOsAaHKw2DJAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhk6Eb4JRgjmFLwW?= =?us-ascii?q?cLzsBjheEL5FDinaIegEfOIEFWxVBhll1iE6BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,252,1486425600"; d="scan'208,217";a="405643111" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 17:55:04 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v2VHt3Eq008873 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Mar 2017 17:55:04 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 31 Mar 2017 12:55:03 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1210.000; Fri, 31 Mar 2017 12:55:03 -0500 From: "Panos Kampanakis (pkampana)" To: "Waltermire, David A. (Fed)" CC: "mile@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AADCZJwAqSdrQ Date: Fri, 31 Mar 2017 17:55:03 +0000 Message-ID: References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com>, <7623EF23448E9148C613E4C1A97C06377ECF6972@unknown> In-Reply-To: <7623EF23448E9148C613E4C1A97C06377ECF6972@unknown> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.108.5] Content-Type: multipart/alternative; boundary="_000_ccdeecc4ccda40598cd347b10fa0a026XCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 17:55:09 -0000 --_000_ccdeecc4ccda40598cd347b10fa0a026XCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there a list for PANIC already? I couldn't find it. From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Waltermire, David A.= (Fed) Sent: Thursday, March 30, 2017 5:44 PM To: Mahesh Jethanandani Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org Subject: Re: [mile] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Sorry. Clicked send on my phone accidentally. We plan to write a draft describing the problem and scope of what we want t= o address. We will share this on the PANIC list and continue the conversati= on from there. We may want to present ideas in WGs like NETCONF at some tim= e in the future. We will know more once further discussion is had. Thanks, Dave ________________________________ On: 30 March 2017 16:38, "Waltermire, David A. (Fed)" > wrote: We plan to write up a description adddessing the problem and ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" > wrote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) > wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF ... The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_ccdeecc4ccda40598cd347b10fa0a026XCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is there a  list for PANIC alrea= dy?

I couldn’t find it.<= /span>

 

 

From: mile [mailto:mile-bounces@ietf= .org] On Behalf Of Waltermire, David A. (Fed)
Sent: Thursday, March 30, 2017 5:44 PM
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org<= br> Subject: Re: [mile] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT

 

Sorry. Clicked send on m= y phone accidentally.

 =

We plan to write a draft= describing the problem and scope of what we want to address. We will share= this on the PANIC list and continue the conversation from there. We may wa= nt to present ideas in WGs like NETCONF at some time in the future. We will know more once further discussion is had.=

 =

Thanks,

Dave

 =

On: 30 March 2017 16:38,= "Waltermire, David A. (Fed)" <david.waltermire@nist.gov> wrote:

We plan to write up a description adddessing the problem and&nb= sp;

On: 30 March 2017 16:09,= "Mahesh Jethanandani" <mjethanandani@gmail.com> wrote:

David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:=
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF …

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.= ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com


--_000_ccdeecc4ccda40598cd347b10fa0a026XCHALN010ciscocom_-- From nobody Fri Mar 31 14:16:41 2017 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 86F081299F4; Fri, 31 Mar 2017 14:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 aPXpEDRMWTKx; Fri, 31 Mar 2017 14:16:36 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0094.outbound.protection.outlook.com [23.103.201.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2147D129A0F; Fri, 31 Mar 2017 14:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0ZLQGdQ0+YrrwHNcFbPDvkhpBquqDGzffvfbKuTDLMI=; b=I63z9I5kdjpu6vxhwC0g8LbQbkT9CGyFDovI5tJRufXvOPbUkHGa3kQ+otkmwwUW9VXrbzlTf4E7nClT975dXwkBhLkzK9b17acqD2z1nICVIvLAg7BCKZUTkkr2TliOGFGXuM7M6lqNcq3ZFnCaucuVzh1De9PjvEv/uj52idc= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1437.namprd09.prod.outlook.com (10.173.50.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Fri, 31 Mar 2017 21:16:33 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.023; Fri, 31 Mar 2017 21:16:33 +0000 From: "Waltermire, David A. (Fed)" To: "Eric Voit (evoit)" , Mahesh Jethanandani CC: "mile@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AAQkXsAApvTOA Date: Fri, 31 Mar 2017 21:16:32 +0000 Message-ID: References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> <9ab236e3d421458e81f35534d2e13aaf@XCH-RTP-013.cisco.com> In-Reply-To: <9ab236e3d421458e81f35534d2e13aaf@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.96] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1437; 7:jFJhSBUZCZMUkfv7NwbnR9aA/cu2RcBMqpz3z+qBd+koPuk6tcMfSkbe3sZshJHn9cF9chTip3V1DAERgdgmonjWEpsjMfdaTZV/RYG52w4x3rZEndtf8qpBbn+UAYrZNGPxfQI6JlomlbzRQAGD17btDWfDhjPDZWebeWC5kqJ8R51f03AW+wiCNbgbSmjVALZpKg551Db7CoH+vPSRXA39zhEXv9He9T+C/6F9xapgqaMaCwoNsN86TCQqIuq5IO2cFIeXGJwxMO+yn/rGS1jQF/5m81ahBm7RDtwfEWg437IUS9Xd/AMqrRsCe5NjRcIRsYsE6Ng6/+J6q/CatA== x-ms-office365-filtering-correlation-id: 870e64b7-77b2-49f8-67af-08d4787b34f4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR09MB1437; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(120809045254105)(192374486261705)(95692535739014)(21748063052155)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:MWHPR09MB1437; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1437; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39400400002)(39450400003)(39410400002)(39850400002)(24454002)(377454003)(3846002)(6116002)(8676002)(790700001)(102836003)(93886004)(7736002)(81156014)(81166006)(6246003)(74316002)(3660700001)(2950100002)(3280700002)(53546009)(25786009)(39060400002)(53936002)(77096006)(38730400002)(7906003)(4326008)(6506006)(7696004)(99286003)(8936002)(66066001)(229853002)(6306002)(2906002)(606005)(9686003)(54896002)(5660300001)(236005)(19609705001)(6436002)(2900100001)(54906002)(122556002)(561944003)(50986999)(76176999)(54356999)(55016002)(189998001)(33656002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1437; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR09MB1440A5DDCAC838605469B044F0370MWHPR09MB1440namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 21:16:32.8633 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1437 Archived-At: Subject: Re: [netmod] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 21:16:39 -0000 --_000_MWHPR09MB1440A5DDCAC838605469B044F0370MWHPR09MB1440namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, We have considered YANG Push as part of PANIC. I have read the draft and I = attended your presentation during NETCONF. I think Yang Push is something w= e should consider as part of the PANIC solution. Do you have an implementat= ion of YANG Push that can be experimented with? Regards, Dave From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Thursday, March 30, 2017 6:27 PM To: Waltermire, David A. (Fed) ; Mahesh Jethanan= dani Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Hi David, I know it is early, but for the secure communication part, have you conside= red using the YANG Push work being developed in the NETCONF WG? With this approach, you can subscribe to state changes within a device's YA= NG models. These could be PANIC developed YANG models, existing YANG mode= ls such as IETF-System, IETF-keychain, or some combination. Then if a hac= ker inserts new hardware, changes software versions, adds keys, adds users,= etc. that state change can be securely pushed to a subscribing where it ca= n be determined whether the change was expected/desired. Eric ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" > wrote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) > wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF ... The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_MWHPR09MB1440A5DDCAC838605469B044F0370MWHPR09MB1440namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

 

We have considered YANG Push as part of PANIC. I ha= ve read the draft and I attended your presentation during NETCONF. I think = Yang Push is something we should consider as part of the PANIC solution. Do you have an implementation of YANG Push that can= be experimented with?

 

Regards,

Dave

 

From: Eric Voit (evoit) [mailto:evoi= t@cisco.com]
Sent: Thursday, March 30, 2017 6:27 PM
To: Waltermire, David A. (Fed) <david.waltermire@nist.gov>; Ma= hesh Jethanandani <mjethanandani@gmail.com>
Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org<= br> Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT

 

Hi David,

 

I know it is early, but for the secur= e communication part, have you considered using the YANG Push work being developed in the NETCONF WG?

 

With this approach, you can subscribe= to state changes within a device‘s YANG models.  These could be= PANIC developed YANG models,  existing YANG models such as IETF-System, IETF-keychain, or some combination.   Then if a = hacker inserts new hardware, changes software versions, adds keys, adds use= rs, etc. that state change can be securely pushed to a subscribing where it= can be determined whether the change was expected/desired. 

 

Eric

On: 30 March 2017 16:09,= "Mahesh Jethanandani" <mjethanandani@gmail.com> wrote:

David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:=
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF …

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.= ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com=

--_000_MWHPR09MB1440A5DDCAC838605469B044F0370MWHPR09MB1440namp_-- From nobody Fri Mar 31 14:18:07 2017 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 DA9FF129A0F; Fri, 31 Mar 2017 14:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 5njpH8njgP25; Fri, 31 Mar 2017 14:17:59 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0131.outbound.protection.outlook.com [23.103.201.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F9A1299F4; Fri, 31 Mar 2017 14:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aW14rQ64WfLW9mzTRTK9aaVmNJBIx1f3V5oEqcMxPNA=; b=hpUOIJ1uVPoMNfr/Jq9M035Ve71IubtMcYr7jzjb4+nMgcZHsilT7VD+X8NBaBEAcTy7LY07i37SWCRVLM9ISqlZCQv9FPjFhYqhhuhmfmBfa6+V1FMETCHj+KVsM6FpsKO6XTGCixV9cYNOF8H9dm3c/Pk/i7zodsD3N6xigNk= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1437.namprd09.prod.outlook.com (10.173.50.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Fri, 31 Mar 2017 21:17:56 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.023; Fri, 31 Mar 2017 21:17:56 +0000 From: "Waltermire, David A. (Fed)" To: "Panos Kampanakis (pkampana)" CC: "mile@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AADCZJwAqSdrQAAcUj4A= Date: Fri, 31 Mar 2017 21:17:55 +0000 Message-ID: References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com>, <7623EF23448E9148C613E4C1A97C06377ECF6972@unknown> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.96] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1437; 7:ilvMp1wVulrAzgWCMh//83kCjV9uIhC1BSXRA3CuWOUQ9H9+IvUGOPMLTaCZz+R5zvZrgYEAH4iNuYyncP1zQ5ROnV9It77nk3s6GbE2p5G/iK7GHnAOOCkiFrR0oU/ZO82pAEYdo5OaUvg/CL1q/MqQMm05nWfwDPRe/E8GfLbNuf4cUYJDK9a+HSAx5cUeeUMdeFEJtX3jAtMDEWdxypRss2O1UNhlkQuXt/qq+kPH59uERwfzFRiOqsSM0F0KQfvttfN38VWsJY2ULXumJ0WBw3ocfqbJkhb+ONJsrumZ2+ZeB51D4hiwvfnfbxjWv9/duSZLarVoyr2H+9zC6A== x-ms-office365-filtering-correlation-id: fd71323e-2060-4daa-2f11-08d4787b6670 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR09MB1437; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(95692535739014)(21748063052155)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:MWHPR09MB1437; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1437; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39400400002)(39450400003)(39410400002)(39850400002)(24454002)(377454003)(3846002)(6116002)(8676002)(790700001)(102836003)(93886004)(7736002)(81166006)(6246003)(74316002)(6916009)(3660700001)(2950100002)(3280700002)(53546009)(25786009)(53936002)(77096006)(110136004)(38730400002)(7906003)(4326008)(6506006)(7696004)(99286003)(8936002)(66066001)(229853002)(6306002)(2906002)(606005)(9686003)(54896002)(5660300001)(236005)(19609705001)(6436002)(2900100001)(54906002)(122556002)(561944003)(50986999)(76176999)(54356999)(55016002)(189998001)(33656002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1437; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR09MB1440EA71FBA40D793535A0CAF0370MWHPR09MB1440namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 21:17:55.9119 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1437 Archived-At: Subject: Re: [netmod] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 21:18:02 -0000 --_000_MWHPR09MB1440EA71FBA40D793535A0CAF0370MWHPR09MB1440namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Panos, We have requested a list to be setup. We will post again with signup info o= nce the list is created. Thanks, Dave From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: Friday, March 31, 2017 1:55 PM To: Waltermire, David A. (Fed) Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Is there a list for PANIC already? I couldn't find it. From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Waltermire, David A.= (Fed) Sent: Thursday, March 30, 2017 5:44 PM To: Mahesh Jethanandani > Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org Subject: Re: [mile] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Sorry. Clicked send on my phone accidentally. We plan to write a draft describing the problem and scope of what we want t= o address. We will share this on the PANIC list and continue the conversati= on from there. We may want to present ideas in WGs like NETCONF at some tim= e in the future. We will know more once further discussion is had. Thanks, Dave ________________________________ On: 30 March 2017 16:38, "Waltermire, David A. (Fed)" > wrote: We plan to write up a description adddessing the problem and ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" > wrote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) > wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF ... The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_MWHPR09MB1440EA71FBA40D793535A0CAF0370MWHPR09MB1440namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Panos,

 

We have requested a list to be setup. We will post = again with signup info once the list is created.

 

Thanks,

Dave

 

From: Panos Kampanakis (pkampana) [m= ailto:pkampana@cisco.com]
Sent: Friday, March 31, 2017 1:55 PM
To: Waltermire, David A. (Fed) <david.waltermire@nist.gov>
Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org<= br> Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT

 

Is there a  list for PANIC alrea= dy?

I couldn’t find it.<= /span>

 

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Waltermire, David A. (Fed)
Sent: Thursday, March 30, 2017 5:44 PM
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org
Subject: Re: [mile] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT

 

Sorry. Clicked send on m= y phone accidentally.

 =

We plan to write a draft= describing the problem and scope of what we want to address. We will share= this on the PANIC list and continue the conversation from there. We may wa= nt to present ideas in WGs like NETCONF at some time in the future. We will know more once further discussion is had.=

 =

Thanks,

Dave

 =

On: 30 March 2017 16:38,= "Waltermire, David A. (Fed)" <david.waltermire@nist.gov> wrote:

We plan to write up a description adddessing the problem and&nb= sp;

On: 30 March 2017 16:09,= "Mahesh Jethanandani" <mjethanandani@gmail.com> wrote:

David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:=
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF …

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.= ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com

--_000_MWHPR09MB1440EA71FBA40D793535A0CAF0370MWHPR09MB1440namp_-- From nobody Fri Mar 31 14:23:03 2017 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 4A50D1270FC; Fri, 31 Mar 2017 14:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 Nv8DxTKnBpHT; Fri, 31 Mar 2017 14:23:00 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0116.outbound.protection.outlook.com [23.103.201.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D364129A0C; Fri, 31 Mar 2017 14:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/p4KiTAn78IHZvOywMqia9OhuKCnXolpaYvdIUAvSj4=; b=QdQEWSkeW+h+kzinF+k4Kc6LuwJryYK5ik4t1FqtqV4+dboDpoK44TfLCDWPOuVrLRr+1pe3yYHRSjbEjsVcy83htaV3EIoTpKrFaD0i3xNkewqegs4CRmYCeuKzkdJP6yMuSda0tlXTd2Wr0p+fHCTIG55BboBvJI+ZZHuTeqs= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1437.namprd09.prod.outlook.com (10.173.50.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Fri, 31 Mar 2017 21:22:57 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0991.023; Fri, 31 Mar 2017 21:22:57 +0000 From: "Waltermire, David A. (Fed)" To: Mahesh Jethanandani CC: "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "mile@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAADKZ5cA= Date: Fri, 31 Mar 2017 21:22:57 +0000 Message-ID: References: <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> In-Reply-To: <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.96] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1437; 7:hTA2/3Zbv17b+e/hSFMR128IXfsMO523GkmSjE08Uts5tF5P6v0liUGswG3aPDw1DtE+r0JVx2mP4kafn88o9QC6Rq8YW+cSDCenvtWHMZ64jLsqelEn+8w1ZqNN3CuCCPbHpFRNyghhNSJqbA0WekH0WYfICoA64CrrBjzd0sRfFOq0HQgjNf4f82GkQS+AM1Won8a7zisNlmfPSPH0VBja08WMzkXGDIM9yS6/7U81IS8/4wp1gIKf6FaAFfTSaf3ubAn8hG7ArKFuVtnzyaZVRhyw0iH/Bgjd2sFCPFwBles6eO38QpZPBRiWTsbfEqGag8n0XnUZxQs2qcxV5w== x-ms-office365-filtering-correlation-id: c503eee0-ada9-4568-96d4-08d4787c1a31 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR09MB1437; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(211171220733660)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:MWHPR09MB1437; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1437; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39850400002)(39410400002)(39840400002)(39450400003)(39400400002)(377454003)(13464003)(24454002)(5660300001)(66066001)(8936002)(9686003)(2906002)(229853002)(6306002)(76176999)(54356999)(50986999)(561944003)(33656002)(189998001)(86362001)(55016002)(6436002)(2900100001)(122556002)(54906002)(99286003)(6916009)(2950100002)(3660700001)(3280700002)(102836003)(8676002)(7736002)(3846002)(6116002)(74316002)(81156014)(81166006)(6246003)(110136004)(38730400002)(7696004)(6506006)(4326008)(53546009)(53936002)(77096006)(1411001)(305945005)(25786009)(39060400002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1437; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 21:22:57.4265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1437 Archived-At: Subject: Re: [netmod] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 21:23:02 -0000 TWFoZXNoLA0KDQpTdWJtaXR0aW5nIGEgZHJhZnQgdG8gdGhlIE5FVENPTkYgV0cgbWlnaHQgYmUg YSBwYXRoIGZvcndhcmQuIEJhc2VkIG9uIHRoZSBmZWVkYmFjayB3ZSByZWNlaXZlZCwgd2UgYXJl IHdvcmtpbmcgb24gYSBzY29wZSBkcmFmdCB0byBmb2N1cyB0aGUgZGlzY3Vzc2lvbiBhcm91bmQg aG93IHdlIGNhbiBsZXZlcmFnZSBleGlzdGluZyB3b3JrLiBJIGhhdmUgYSBwZXJzb25hbCBpbmRp dmlkdWFsIHN0cmVhbSBkcmFmdCByZWFkeSBhbmQgd2lsbCBwb3N0IGl0IGFzIHNvb24gYXMgSSBj YW4gd29yayBvdXQgYW4gaXNzdWUgd2l0aCB0aGUgc3VibWlzc2lvbiB0b29sLg0KDQpSZWdhcmRz LA0KRGF2ZSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYWhlc2gg SmV0aGFuYW5kYW5pIFttYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb21dDQo+IFNlbnQ6IFRo dXJzZGF5LCBNYXJjaCAzMCwgMjAxNyA1OjA5IFBNDQo+IFRvOiBXYWx0ZXJtaXJlLCBEYXZpZCBB LiAoRmVkKSA8ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdj4NCj4gQ2M6IG5ldGNvbmZAaWV0Zi5v cmc7IG5ldG1vZEBpZXRmLm9yZzsgc2FjbUBpZXRmLm9yZzsgbWlsZUBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW05ldGNvbmZdIFBBTklDIEJhciBCb0YgV2VkbmVzZGF5IEAgNjozMHBtIENEVA0K PiANCj4gRGF2aWQsDQo+IA0KPiA+IE9uIE1hciAyNiwgMjAxNywgYXQgNTozNCBQTSwgV2FsdGVy bWlyZSwgRGF2aWQgQS4gKEZlZCkNCj4gPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+IHdyb3Rl Og0KPiA+DQo+ID4NCj4gPiBUaGUgVVMgR292ZXJubWVudCBoYXMgYmVlbiB3b3JraW5nIHdpdGhp biB0aGUgSUVURiBTQUNNIHdvcmsgZ3JvdXAgdG8NCj4gc3RhbmRhcmRpemUgdGhlIGNvbGxlY3Rp b24gb2YgZW5kcG9pbnQgY29uZmlndXJhdGlvbiBhbmQgb3RoZXIgcG9zdHVyZQ0KPiBpbmZvcm1h dGlvbiBmcm9tIGVudGVycHJpc2UgZW5kcG9pbnRzLiBDb2xsZWN0aW5nIHRoaXMgaW5mb3JtYXRp b24gaXMgY3JpdGljYWwNCj4gdG8gc3VwcG9ydCBhdXRvbWF0aW9uIG9mIGNvbW1vbiBuZXR3b3Jr IHNlY3VyaXR5IHRhc2tzLCBpbmNsdWRpbmcgYXNzZXQsDQo+IHNvZnR3YXJlLCB2dWxuZXJhYmls aXR5LCBhbmQgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50LiBUaHVzIGZhciwgb3VyIGVmZm9ydHMN Cj4gaGF2ZSBmb2N1c2VkIHByaW1hcmlseSBvbiBzdGFuZGFyZHMgdG8gY29sbGVjdCBpbmZvcm1h dGlvbiBpbiBzdXBwb3J0IG9mDQo+IGFzc2V0LCBzb2Z0d2FyZSBhbmQgdnVsbmVyYWJpbGl0eSBt YW5hZ2VtZW50IHVzZSBjYXNlcywgYW5kIGhhcyB3b3JrZWQNCj4gd2l0aCBvdGhlciBJRVRGIG1l bWJlcnMgdG8gZGV0ZXJtaW5lIHdoYXQgZGF0YSB3b3VsZCBuZWVkIHRvIGJlIHRvIGJlDQo+IGNv bGxlY3RlZCwgYW5kIGhvdyB0aGF0IGRhdGEgd291bGQgYmUgc2VjdXJlbHkgY29tbXVuaWNhdGVk IGFjcm9zcyB0aGUNCj4gbmV0d29yay4gVGhyb3VnaCBzdWNoIGV4Y2hhbmdlcyBhbiBvcmdhbml6 YXRpb24gY2FuIGtub3cgd2hhdCBjbGllbnQNCj4gZW5kcG9pbnRzIGFyZSBjb25uZWN0ZWQgdG8g dGhlaXIgbmV0d29yaywgYW5kIGlmIHRoZXkgYXJlIHZ1bG5lcmFibGUgdG8NCj4gYXR0YWNrLg0K PiA+DQo+ID4gR2l2ZW4gdGhlIHByb2xpZmVyYXRpb24gb2YgYXR0YWNrcyBhZ2FpbnN0IG5ldHdv cmsgaW5mcmFzdHJ1Y3R1cmUgZGV2aWNlcywgaXQNCj4gaXMgY2xlYXIgdGhhdCB0aGUgbmV4dCBz dGVwIGluIG91ciBlbnRlcnByaXNlIHNlY3VyaXR5IGF1dG9tYXRpb24gZWZmb3J0IG11c3QNCj4g YmUgdG8gZW5hYmxlIHN0YW5kYXJkaXplZCByZXBvcnRpbmcgb2Ygc2ltaWxhciBpbmZvcm1hdGlv biBmcm9tIG5ldHdvcmsNCj4gaW5mcmFzdHJ1Y3R1cmUgZGV2aWNlcy4gV2l0aCB0aGUgZ3Jvd2lu ZyBudW1iZXIgb2YgWWFuZyBtb2RlbHMgYW5kDQo+IGluY3JlYXNlZCBhZG9wdGlvbiBvZiBORVRD T05GLCBSRVNUQ09ORiwgYW5kIHJlbGF0ZWQgcHJvdG9jb2wgd29yaywgdGhlDQo+IHRpbWUgaXMg cmlnaHQgdG8gd29yayBvdXQgaG93IHRoZXNlIHN0YW5kYXJkcyBjYW4gYmUgdXNlZCB0byBtZWFz dXJlIHRoZQ0KPiBoZWFsdGggb2YgbmV0d29yayBkZXZpY2VzLiBUaGlzIGluZm9ybWF0aW9uIHdp bGwsIGFzIGluIG91ciBlZmZvcnRzIGluIFNBQ00gZm9yDQo+IGNsaWVudCBkZXZpY2VzLCBzdXBw b3J0IGFzc2V0LCBzb2Z0d2FyZSwgdnVsbmVyYWJpbGl0eSwgYW5kIGNvbmZpZ3VyYXRpb24NCj4g bWFuYWdlbWVudCB1c2UgY2FzZXMuIFN0YW5kYXJkcy1iYXNlZCByZXBvcnRpbmcgb2YgdGhpcyBp bmZvcm1hdGlvbiBmcm9tDQo+IG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgZGV2aWNlcyB3aWxsIGhl bHAgbmV0d29yayBkZWZlbmRlcnMgcHJvdGVjdCBhZ2FpbnN0DQo+IGtub3duIGF0dGFja3MsIGFu ZCBwcm92aWRlIHRoZSBuZWNlc3Nhcnkga25vd2xlZGdlIHRvIGRldGVjdCBhbmQgbWl0aWdhdGUN Cj4gZnV0dXJlIGF0dGFja3MuDQo+ID4NCj4gPiBXZSB3b3VsZCBsaWtlIHRvIHN0YXJ0IGEgZGlz Y3Vzc2lvbiBhYm91dCBob3cgdG8gbGV2ZXJhZ2UgdGhlIGV4aXN0aW5nIElFVEYNCj4gbmV0d29y ayBtYW5hZ2VtZW50IHByb3RvY29scyB0byBiZXN0IGFkZHJlc3Mgc2VjdXJpdHkgYXV0b21hdGlv biBmb3INCj4gbmV0d29yayBpbmZyYXN0cnVjdHVyZSBkZXZpY2VzLiBXZSB3b3VsZCBsaWtlIHlv dXIgaWRlYXMgb24gaG93IHRvIGJlc3QNCj4gcHVyc3VlIHRoaXMgd29yaywgYW5kIHlvdXIgaW5z aWdodHMgaW50byBuZXR3b3JrIGluZnJhc3RydWN0dXJlIHNlY3VyaXR5DQo+IHByb2JsZW1zIHRo YXQgd2lsbCBpbXBhY3Qgb3VyIG5ldHdvcmtzIGluIHRoZSBmdXR1cmUuIFdlIGFyZSBob2xkaW5n IGEgc2lkZQ0KPiBtZWV0aW5nIGF0IElFVEYgOTggb24gV2VkbmVzZGF5LCBNYXJjaCAyOXRoIGF0 IDY6MzBwbSBDRFQgdG8gc3RhcnQgYQ0KPiBkaXNjdXNzaW9uIGFib3V0IGhvdyB0byBtb3ZlIGZv cndhcmQuIFdlIHdpbGwgYmUgbWVldGluZyBpbiBWZXZleSA0IGF0IHRoZQ0KPiBJRVRGIG1lZXRp bmcgdmVudWUuDQo+IA0KPiBNYXliZSB0aGlzIHdhcyBkaXNjdXNzZWQgaW4gdGhlIEJvRiDigKYN Cj4gDQo+IFRoZSBiZXN0IHdheSB0byBoYXZlIGEgZGlzY3Vzc2lvbiB3b3VsZCBiZSB0byBwcmVz ZW50IHRoZSBwcm9wb3NhbCBpbiB0aGUNCj4gZm9ybSBvZiBhIGRyYWZ0IGluIHRoZSBORVRDT05G IFdHLg0KPiANCj4gPg0KPiA+IEhlcmUgaXMgYSBzdW1tYXJ5IG9mIHRoZSBtZWV0aW5nIGRldGFp bHM6DQo+ID4NCj4gPiBQQU5JQyAoUG9zdHVyZSBBc3Nlc3NtZW50IHRocm91Z2ggTmV0d29yayBJ bmZvcm1hdGlvbiBDb2xsZWN0aW9uKSBCYXINCj4gPiBCb0YgV2VkbmVzZGF5LCBNYXJjaCAyOXRo LCAyMDE3IEAgNjozMHBtIENEVCBTd2lzc290ZWwgQ29uZmVyZW5jZQ0KPiA+IENlbnRlciAtIFZl dmV5IDQNCj4gPg0KPiA+IFdlIGxvb2sgZm9yd2FyZCB0byB3b3JraW5nIHdpdGggeW91LCBhbmQg aG9wZSB0byBzZWUgeW91IGluIENoaWNhZ28gYXQNCj4gdGhlIFBBTklDIEJhciBCb0YuDQo+ID4N Cj4gPiBSZWdhcmRzLA0KPiA+IERhdmUNCj4gPg0KPiA+IERhdmlkIFdhbHRlcm1pcmUNCj4gPiBJ bmZvcm1hdGlvbiBUZWNobm9sb2d5IExhYm9yYXRvcnkgfCBDb21wdXRlciBTZWN1cml0eSBEaXZp c2lvbg0KPiA+IE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3kN Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiBOZXRjb25mQGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+IA0KPiBNYWhlc2gg SmV0aGFuYW5kYW5pDQo+IG1qZXRoYW5hbmRhbmlAZ21haWwuY29tDQo+IA0KPiANCg0K From nobody Fri Mar 31 15:30:25 2017 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 EF40F126DCA; Fri, 31 Mar 2017 15:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 940bh4kTDmyQ; Fri, 31 Mar 2017 15:30:20 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034BA124217; Fri, 31 Mar 2017 15:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19613; q=dns/txt; s=iport; t=1490999419; x=1492209019; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7wxMQWivaC05J4CoJSQp3a/2s4VZdrYsseKXlN32Seo=; b=KZCNZ6aHuLUc3/SIJYtM6MDH7b+GStxp6tBVCiEnFd/1sGd95I3yWlc8 Js8QBsTJGBIJjzdCNNRhSmLE+EvV8pnSIeKV+/Yg7a3SGjXe07TzoqrJi 61YA2hnImMkrHPFukkKn3MvV4Os1RNGvxH1OpSR4DXNX58RHuKCzY5NLu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAQBB2N5Y/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm49KWGBCweNbZFViBqNN4IOHwEMgkCCbEoCg0k/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAgEBASs7BgsFCwIBCBEEAQEBDBsHIQYLFAkIAQEEAQ0FCBOIL?= =?us-ascii?q?YEtAw0IDq9BhywNgyQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZOhG+CUUaBc4U?= =?us-ascii?q?vBZwvOwGGfIcbhC+CBokFhjiKdoh6AR84gQVbFUGGWXWIToENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,254,1486425600"; d="scan'208,217";a="216950536" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 22:30:18 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v2VMUIhm028690 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Mar 2017 22:30:18 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 31 Mar 2017 18:30:17 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 31 Mar 2017 18:30:17 -0400 From: "Eric Voit (evoit)" To: "Waltermire, David A. (Fed)" , "Mahesh Jethanandani" CC: "mile@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AAQkXsAApvTOAAAkfouA= Date: Fri, 31 Mar 2017 22:30:17 +0000 Message-ID: <20f788b0479b41fd8db957f78dc983aa@XCH-RTP-013.cisco.com> References: , <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> <9ab236e3d421458e81f35534d2e13aaf@XCH-RTP-013.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_20f788b0479b41fd8db957f78dc983aaXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 22:30:23 -0000 --_000_20f788b0479b41fd8db957f78dc983aaXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For experimentation, OpenDaylight has YANG Push code for the both subscribe= r and publisher. I can work with you offline to help define a viable testb= ed. Eric From: Waltermire, David A, March 31, 2017 5:17 PM Eric, We have considered YANG Push as part of PANIC. I have read the draft and I = attended your presentation during NETCONF. I think Yang Push is something w= e should consider as part of the PANIC solution. Do you have an implementat= ion of YANG Push that can be experimented with? Regards, Dave From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Thursday, March 30, 2017 6:27 PM To: Waltermire, David A. (Fed) >; Mahesh Jethanandani > Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT Hi David, I know it is early, but for the secure communication part, have you conside= red using the YANG Push work being developed in the NETCONF WG? With this approach, you can subscribe to state changes within a device's YA= NG models. These could be PANIC developed YANG models, existing YANG mode= ls such as IETF-System, IETF-keychain, or some combination. Then if a hac= ker inserts new hardware, changes software versions, adds keys, adds users,= etc. that state change can be securely pushed to a subscribing where it ca= n be determined whether the change was expected/desired. Eric ________________________________ On: 30 March 2017 16:09, "Mahesh Jethanandani" > wrote: David, > On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) > wrote: > > > The US Government has been working within the IETF SACM work group to sta= ndardize the collection of endpoint configuration and other posture informa= tion from enterprise endpoints. Collecting this information is critical to = support automation of common network security tasks, including asset, softw= are, vulnerability, and configuration management. Thus far, our efforts hav= e focused primarily on standards to collect information in support of asset= , software and vulnerability management use cases, and has worked with othe= r IETF members to determine what data would need to be to be collected, and= how that data would be securely communicated across the network. Through s= uch exchanges an organization can know what client endpoints are connected = to their network, and if they are vulnerable to attack. > > Given the proliferation of attacks against network infrastructure devices= , it is clear that the next step in our enterprise security automation effo= rt must be to enable standardized reporting of similar information from net= work infrastructure devices. With the growing number of Yang models and inc= reased adoption of NETCONF, RESTCONF, and related protocol work, the time i= s right to work out how these standards can be used to measure the health o= f network devices. This information will, as in our efforts in SACM for cli= ent devices, support asset, software, vulnerability, and configuration mana= gement use cases. Standards-based reporting of this information from networ= k infrastructure devices will help network defenders protect against known = attacks, and provide the necessary knowledge to detect and mitigate future = attacks. > > We would like to start a discussion about how to leverage the existing IE= TF network management protocols to best address security automation for net= work infrastructure devices. We would like your ideas on how to best pursue= this work, and your insights into network infrastructure security problems= that will impact our networks in the future. We are holding a side meeting= at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion ab= out how to move forward. We will be meeting in Vevey 4 at the IETF meeting = venue. Maybe this was discussed in the BoF ... The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG. > > Here is a summary of the meeting details: > > PANIC (Posture Assessment through Network Information Collection) Bar BoF > Wednesday, March 29th, 2017 @ 6:30pm CDT > Swissotel Conference Center - Vevey 4 > > We look forward to working with you, and hope to see you in Chicago at th= e PANIC Bar BoF. > > Regards, > Dave > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --_000_20f788b0479b41fd8db957f78dc983aaXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For experimentation, OpenDaylight has= YANG Push code for the both subscriber and publisher.  I can work wit= h you offline to help define a viable testbed.

 

Eric

 

From: Waltermire, David A,  Mar= ch 31, 2017 5:17 PM

Eric,

 

We have considered YANG Push as part of PANIC. I ha= ve read the draft and I attended your presentation during NETCONF. I think = Yang Push is something we should consider as part of the PANIC solution. Do you have an implementation of YANG Push that can= be experimented with?

 

Regards,

Dave

 

From: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Thursday, March 30, 2017 6:27 PM
To: Waltermire, David A. (Fed) <david.waltermire@nist.gov>; Mahesh Jethanandani <mjetha= nandani@gmail.com>
Cc: mile@ietf.org; netconf@ietf.org; netmod@ietf.org; sacm@ietf.org
Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT

 

Hi David,

 

I know it is early, but for the secur= e communication part, have you considered using the YANG Push work being developed in the NETCONF WG?

 

With this approach, you can subscribe= to state changes within a device‘s YANG models.  These could be= PANIC developed YANG models,  existing YANG models such as IETF-System, IETF-keychain, or some combination.   Then if a = hacker inserts new hardware, changes software versions, adds keys, adds use= rs, etc. that state change can be securely pushed to a subscribing where it= can be determined whether the change was expected/desired. 

 

Eric

On: 30 March 2017 16:09,= "Mahesh Jethanandani" <mjethanandani@gmail.com> wro= te:

David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <= david.waltermire@nist.gov> w= rote:
>
>
> The US Government has been working within the IETF SACM work group to = standardize the collection of endpoint configuration and other posture info= rmation from enterprise endpoints. Collecting this information is critical = to support automation of common network security tasks, including asset, software, vulnerability, and configuratio= n management. Thus far, our efforts have focused primarily on standards to = collect information in support of asset, software and vulnerability managem= ent use cases, and has worked with other IETF members to determine what data would need to be to be collected= , and how that data would be securely communicated across the network. Thro= ugh such exchanges an organization can know what client endpoints are conne= cted to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devi= ces, it is clear that the next step in our enterprise security automation e= ffort must be to enable standardized reporting of similar information from = network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTC= ONF, and related protocol work, the time is right to work out how these sta= ndards can be used to measure the health of network devices. This informati= on will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configurat= ion management use cases. Standards-based reporting of this information fro= m network infrastructure devices will help network defenders protect agains= t known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing= IETF network management protocols to best address security automation for = network infrastructure devices. We would like your ideas on how to best pur= sue this work, and your insights into network infrastructure security problems that will impact our networks in = the future. We are holding a side meeting at IETF 98 on Wednesday, March 29= th at 6:30pm CDT to start a discussion about how to move forward. We will b= e meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF …

The best way to have a discussion would be to present the proposal in the f= orm of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar = BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at= the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com=

--_000_20f788b0479b41fd8db957f78dc983aaXCHRTP013ciscocom_--