From nobody Tue Mar 1 01:42:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99801B36D4 for ; Tue, 1 Mar 2016 01:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_PDsc53sH0w for ; Tue, 1 Mar 2016 01:42:33 -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 0938D1B36D2 for ; Tue, 1 Mar 2016 01:42:32 -0800 (PST) Received: from [IPv6:2001:1488:fffe:255:b41e:902c:38d7:b6ca] (unknown [IPv6:2001:1488:fffe:255:b41e:902c:38d7:b6ca]) by mail.nic.cz (Postfix) with ESMTPSA id ED67E18180E; Tue, 1 Mar 2016 10:42:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456825350; bh=+cn77q5ozjwyICx9Vy7OqgTf94K4m1uRfm5nIFF+fxU=; h=From:Date:To; b=buKlJyk1Mgz6pnKeXwPENVkXcrxo1wt1MrH5lBKwfE0SuRMbc8CgnX5fjVfOqm5AW J2S430hkAIwBqwGBZSpjZtSKpePtzviHwFti+IQ/eNbsHKlFTZ3bqjk/ANylXmxvoX hRTPh46ekmKAsv7jXOOk65DZLuJLs/72mKUXy2Nk= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <1456825129206.33792@pantheon.tech> Date: Tue, 1 Mar 2016 10:42:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <46058C3A-C2F6-4012-9A21-BD8A475BB601@nic.cz> References: <56D40ABD.40507@alcatel-lucent.com> <3101CBD7-6B1A-4FA1-B238-65B05AA6C63D@nic.cz> <1456825129206.33792@pantheon.tech> To: =?iso-8859-2?Q?Anton_Tk=E1=E8ik?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Peter Verthez , "netmod@ietf.org" Subject: Re: [netmod] Augment issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 09:42:35 -0000 > On 01 Mar 2016, at 10:38, Anton Tk=E1=E8ik = wrote: >=20 > Hi, > Noticed other issue with example set, > In https://github.com/mbj4668/pyang/issues/194 Lada stated that in = YANG 1.0 submodule can not augment nodes > defined in parent model. >=20 > Is that correct that submodule can not augment definition defined in = parent module? This isn't possible in YANG 1.0 but will be possible in 1.1. However, in = the present case the definition being augmented from the submodule is = arguably in a different module. Lada > Is such definition also augmentation. >=20 >=20 >=20 > ________________________________________ > Od: Ladislav Lhotka > Odoslan=E9: 29. febru=E1ra 2016 17:36 > Komu: Peter Verthez > K=F3pia: netmod@ietf.org > Predmet: Re: [netmod] Augment issue >=20 > Hi Peter, >=20 > I agree it should be OK. I tried to reproduce the situation and test = it with pyang and it led to a Python exception. So I filed an issue: >=20 > https://github.com/mbj4668/pyang/issues/206 >=20 > Lada >=20 >> On 29 Feb 2016, at 10:09, Peter Verthez = wrote: >>=20 >> Hi all, >>=20 >> A few weeks ago I reported a bug on the OpenDaylight YANG parser, = regarding a error that was generated on a particular augment = construction. The bug report is the following: >> https://bugs.opendaylight.org/show_bug.cgi?id=3D5335 >>=20 >> We are disagreeing on the interpretation of the YANG RFC regarding to = this bug, so could we get the opinion of the people on this mailing list = on it? >>=20 >> The problem originated from a proposed Broadband Forum model, but = there's a dummy model that reproduces the problem attached to that bug = report. >>=20 >> Thanks, >> Peter. >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > AntonTk=E1=E8ik > Chief Software Architect >=20 > Mlynsk=E9 Nivy 56 / 821 05 Bratislava / Slovakia > +421 911 309 249 / anton.tkacik@pantheon.tech > reception: +421 2 206 65 111 / www.pantheon.sk > [logo] -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From anton.tkacik@pantheon.tech Tue Mar 1 01:39:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D151B36C9 for ; Tue, 1 Mar 2016 01:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.304 X-Spam-Level: X-Spam-Status: No, score=0.304 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 OZXeYkq-PAb6 for ; Tue, 1 Mar 2016 01:39:01 -0800 (PST) Received: from amalka.pantheon.sk (amalka.pantheon.sk [46.229.239.144]) by ietfa.amsl.com (Postfix) with ESMTP id A31EC1B36C8 for ; Tue, 1 Mar 2016 01:39:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id 57A1823D66; Tue, 1 Mar 2016 10:38:58 +0100 (CET) X-Virus-Scanned: amavisd-new at pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mzSt7X-yxgO; Tue, 1 Mar 2016 10:38:53 +0100 (CET) Received: from XMBX1.pantheon.local (fw.pantheon.sk [46.229.239.141]) by amalka.pantheon.sk (Postfix) with ESMTPS; Tue, 1 Mar 2016 10:38:53 +0100 (CET) Received: from XMBX1.pantheon.local (10.10.4.5) by XMBX1.pantheon.local (10.10.4.5) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 1 Mar 2016 10:38:49 +0100 Received: from XMBX1.pantheon.local ([10.10.4.5]) by XMBX1.pantheon.local ([10.10.4.5]) with mapi id 15.00.1156.000; Tue, 1 Mar 2016 10:38:49 +0100 From: =?iso-8859-2?Q?Anton_Tk=E1=E8ik?= To: Ladislav Lhotka , Peter Verthez Thread-Topic: [netmod] Augment issue Thread-Index: AQHRctONjev345sDikWDmUoYiqfUmZ9DKDKAgAEt/0E= Date: Tue, 1 Mar 2016 09:38:49 +0000 Message-ID: <1456825129206.33792@pantheon.tech> References: <56D40ABD.40507@alcatel-lucent.com>, <3101CBD7-6B1A-4FA1-B238-65B05AA6C63D@nic.cz> In-Reply-To: <3101CBD7-6B1A-4FA1-B238-65B05AA6C63D@nic.cz> Accept-Language: sk-SK, en-US Content-Language: sk-SK X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [173.38.220.40] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 01 Mar 2016 01:46:19 -0800 Cc: "netmod@ietf.org" Subject: Re: [netmod] Augment issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 09:40:24 -0000 Hi, Noticed other issue with example set, In https://github.com/mbj4668/pyang/issues/194 Lada stated that in YANG 1.0= submodule can not augment nodes defined in parent model. Is that correct that submodule can not augment definition defined in parent= module? Is such definition also augmentation. ________________________________________ Od: Ladislav Lhotka Odoslan=E9: 29. febru=E1ra 2016 17:36 Komu: Peter Verthez K=F3pia: netmod@ietf.org Predmet: Re: [netmod] Augment issue Hi Peter, I agree it should be OK. I tried to reproduce the situation and test it wit= h pyang and it led to a Python exception. So I filed an issue: https://github.com/mbj4668/pyang/issues/206 Lada > On 29 Feb 2016, at 10:09, Peter Verthez wrote: > > Hi all, > > A few weeks ago I reported a bug on the OpenDaylight YANG parser, regardi= ng a error that was generated on a particular augment construction. The b= ug report is the following: > https://bugs.opendaylight.org/show_bug.cgi?id=3D5335 > > We are disagreeing on the interpretation of the YANG RFC regarding to thi= s bug, so could we get the opinion of the people on this mailing list on it= ? > > The problem originated from a proposed Broadband Forum model, but there's= a dummy model that reproduces the problem attached to that bug report. > > Thanks, > Peter. > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod AntonTk=E1=E8ik Chief Software Architect Mlynsk=E9 Nivy 56 / 821 05 Bratislava / Slovakia +421 911 309 249 / anton.tkacik@pantheon.tech reception: +421 2 206 65 111 / www.pantheon.sk [logo] From nobody Tue Mar 1 02:21:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68831B3EC8 for ; Tue, 1 Mar 2016 02:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 OgXxneWJbp1i for ; Tue, 1 Mar 2016 02:21:30 -0800 (PST) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9FE1B3EC6 for ; Tue, 1 Mar 2016 02:21:30 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 57F61C007720; Tue, 1 Mar 2016 11:21:29 +0100 (CET) To: Ladislav Lhotka , =?UTF-8?B?QW50b24gVGvDocSNaWs=?= References: <56D40ABD.40507@alcatel-lucent.com> <3101CBD7-6B1A-4FA1-B238-65B05AA6C63D@nic.cz> <1456825129206.33792@pantheon.tech> <46058C3A-C2F6-4012-9A21-BD8A475BB601@nic.cz> From: Jernej Tuljak Message-ID: <56D56D27.5090502@mg-soft.si> Date: Tue, 1 Mar 2016 11:21:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <46058C3A-C2F6-4012-9A21-BD8A475BB601@nic.cz> Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Peter Verthez , "netmod@ietf.org" Subject: Re: [netmod] Augment issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 10:21:34 -0000 Ladislav Lhotka je 1.3.2016 ob 10:42 napisal: >> On 01 Mar 2016, at 10:38, Anton Tkáčik wrote: >> >> Hi, >> Noticed other issue with example set, >> In https://github.com/mbj4668/pyang/issues/194 Lada stated that in YANG 1.0 submodule can not augment nodes >> defined in parent model. >> >> Is that correct that submodule can not augment definition defined in parent module? > This isn't possible in YANG 1.0 but will be possible in 1.1. However, in the present case the definition being augmented from the submodule is arguably in a different module. I disagree. Submodules do not see "/jbox:jukebox/jboxcd:cdcapable" in 1.0, since "jbox:cdcapable" is a name defined in the main module. An explicit include of another submodule doing the augmentation is needed to make their test case valid YANG. Any other case would mean breaking out of submodule containment, much like when we discussed XPath expressions breaking out of module containment. Jernej > > Lada > >> Is such definition also augmentation. >> >> >> >> ________________________________________ >> Od: Ladislav Lhotka >> Odoslané: 29. februára 2016 17:36 >> Komu: Peter Verthez >> Kópia: netmod@ietf.org >> Predmet: Re: [netmod] Augment issue >> >> Hi Peter, >> >> I agree it should be OK. I tried to reproduce the situation and test it with pyang and it led to a Python exception. So I filed an issue: >> >> https://github.com/mbj4668/pyang/issues/206 >> >> Lada >> >>> On 29 Feb 2016, at 10:09, Peter Verthez wrote: >>> >>> Hi all, >>> >>> A few weeks ago I reported a bug on the OpenDaylight YANG parser, regarding a error that was generated on a particular augment construction. The bug report is the following: >>> https://bugs.opendaylight.org/show_bug.cgi?id=5335 >>> >>> We are disagreeing on the interpretation of the YANG RFC regarding to this bug, so could we get the opinion of the people on this mailing list on it? >>> >>> The problem originated from a proposed Broadband Forum model, but there's a dummy model that reproduces the problem attached to that bug report. >>> >>> Thanks, >>> Peter. >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> AntonTkáčik >> Chief Software Architect >> >> Mlynské Nivy 56 / 821 05 Bratislava / Slovakia >> +421 911 309 249 / anton.tkacik@pantheon.tech >> reception: +421 2 206 65 111 / www.pantheon.sk >> [logo] > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Mar 1 02:33:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8471B3F04 for ; Tue, 1 Mar 2016 02:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.006] autolearn=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 DNgdJo8OLxYv for ; Tue, 1 Mar 2016 02:33: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 56F181B3F05 for ; Tue, 1 Mar 2016 02:33:30 -0800 (PST) Received: from [IPv6:2001:1488:fffe:255:6ccf:ac79:c569:b5ae] (unknown [IPv6:2001:1488:fffe:255:6ccf:ac79:c569:b5ae]) by mail.nic.cz (Postfix) with ESMTPSA id EC8B0181C5C; Tue, 1 Mar 2016 11:33:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456828409; bh=Q0OAJ4KNVHWN63ZqLun7xPPnyYvqal/ko/4DS4ld4fM=; h=From:Date:To; b=jbpyp97O2IGHodB9fwwrAXG3DoRSFfNN9+uS97pvQYC7JkB+eGb1yiCY/RSTzI5kg fjFM/sxnfo7Wf6OyxXVHCqcxc2w015EKzE5wNK11dEw7g+sRY74cyURZCIF1FTsWkT +MmB7c/eyxop3NnBQ7SDM+FljAv+iuYSK3M/RZ+M= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56D56D27.5090502@mg-soft.si> Date: Tue, 1 Mar 2016 11:33:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <70C510A6-980B-48C7-9814-5A7FA5656120@nic.cz> References: <56D40ABD.40507@alcatel-lucent.com> <3101CBD7-6B1A-4FA1-B238-65B05AA6C63D@nic.cz> <1456825129206.33792@pantheon.tech> <46058C3A-C2F6-4012-9A21-BD8A475BB601@nic.cz> <56D56D27.5090502@mg-soft.si> To: Jernej Tuljak X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Peter Verthez , "netmod@ietf.org" , =?iso-8859-2?Q?Anton_Tk=E1=E8ik?= Subject: Re: [netmod] Augment issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 10:33:33 -0000 > On 01 Mar 2016, at 11:21, Jernej Tuljak = wrote: >=20 > Ladislav Lhotka je 1.3.2016 ob 10:42 napisal: >>> On 01 Mar 2016, at 10:38, Anton Tk=E1=E8ik = wrote: >>>=20 >>> Hi, >>> Noticed other issue with example set, >>> In https://github.com/mbj4668/pyang/issues/194 Lada stated that in = YANG 1.0 submodule can not augment nodes >>> defined in parent model. >>>=20 >>> Is that correct that submodule can not augment definition defined in = parent module? >> This isn't possible in YANG 1.0 but will be possible in 1.1. However, = in the present case the definition being augmented from the submodule is = arguably in a different module. >=20 > I disagree. Submodules do not see "/jbox:jukebox/jboxcd:cdcapable" in = 1.0, since "jbox:cdcapable" is a name defined in the main module. An = explicit include of another submodule doing the augmentation is needed = to make their test case valid YANG. Any other case Isn't it what I wrote? This has changed in 1.1, no includes are needed = in submodules in order to "see" definitions in the main module? Lada > would mean breaking out of submodule containment, much like when we = discussed XPath expressions breaking out of module containment. >=20 > Jernej >=20 >>=20 >> Lada >>=20 >>> Is such definition also augmentation. >>>=20 >>>=20 >>>=20 >>> ________________________________________ >>> Od: Ladislav Lhotka >>> Odoslan=E9: 29. febru=E1ra 2016 17:36 >>> Komu: Peter Verthez >>> K=F3pia: netmod@ietf.org >>> Predmet: Re: [netmod] Augment issue >>>=20 >>> Hi Peter, >>>=20 >>> I agree it should be OK. I tried to reproduce the situation and test = it with pyang and it led to a Python exception. So I filed an issue: >>>=20 >>> https://github.com/mbj4668/pyang/issues/206 >>>=20 >>> Lada >>>=20 >>>> On 29 Feb 2016, at 10:09, Peter Verthez = wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> A few weeks ago I reported a bug on the OpenDaylight YANG parser, = regarding a error that was generated on a particular augment = construction. The bug report is the following: >>>> https://bugs.opendaylight.org/show_bug.cgi?id=3D5335 >>>>=20 >>>> We are disagreeing on the interpretation of the YANG RFC regarding = to this bug, so could we get the opinion of the people on this mailing = list on it? >>>>=20 >>>> The problem originated from a proposed Broadband Forum model, but = there's a dummy model that reproduces the problem attached to that bug = report. >>>>=20 >>>> Thanks, >>>> Peter. >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> AntonTk=E1=E8ik >>> Chief Software Architect >>>=20 >>> Mlynsk=E9 Nivy 56 / 821 05 Bratislava / Slovakia >>> +421 911 309 249 / anton.tkacik@pantheon.tech >>> reception: +421 2 206 65 111 / www.pantheon.sk >>> [logo] >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 1 03:14:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A0B1A01EA for ; Tue, 1 Mar 2016 03:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gp2tVFektae9 for ; Tue, 1 Mar 2016 03:14:46 -0800 (PST) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2A31A0199 for ; Tue, 1 Mar 2016 03:14:45 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 73BA0C3DF0E0; Tue, 1 Mar 2016 12:14:43 +0100 (CET) To: Ladislav Lhotka References: <56D40ABD.40507@alcatel-lucent.com> <3101CBD7-6B1A-4FA1-B238-65B05AA6C63D@nic.cz> <1456825129206.33792@pantheon.tech> <46058C3A-C2F6-4012-9A21-BD8A475BB601@nic.cz> <56D56D27.5090502@mg-soft.si> <70C510A6-980B-48C7-9814-5A7FA5656120@nic.cz> From: Jernej Tuljak Message-ID: <56D579A1.1070701@mg-soft.si> Date: Tue, 1 Mar 2016 12:14:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <70C510A6-980B-48C7-9814-5A7FA5656120@nic.cz> Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Peter Verthez , "netmod@ietf.org" , =?UTF-8?B?QW50b24gVGvDocSNaWs=?= Subject: Re: [netmod] Augment issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 11:14:49 -0000 Ladislav Lhotka je 1.3.2016 ob 11:33 napisal: >> On 01 Mar 2016, at 11:21, Jernej Tuljak wrote: >> >> Ladislav Lhotka je 1.3.2016 ob 10:42 napisal: >>>> On 01 Mar 2016, at 10:38, Anton Tkáčik wrote: >>>> >>>> Hi, >>>> Noticed other issue with example set, >>>> In https://github.com/mbj4668/pyang/issues/194 Lada stated that in YANG 1.0 submodule can not augment nodes >>>> defined in parent model. >>>> >>>> Is that correct that submodule can not augment definition defined in parent module? >>> This isn't possible in YANG 1.0 but will be possible in 1.1. However, in the present case the definition being augmented from the submodule is arguably in a different module. >> I disagree. Submodules do not see "/jbox:jukebox/jboxcd:cdcapable" in 1.0, since "jbox:cdcapable" is a name defined in the main module. An explicit include of another submodule doing the augmentation is needed to make their test case valid YANG. Any other case > Isn't it what I wrote? This has changed in 1.1, no includes are needed in submodules in order to "see" definitions in the main module? Perhaps I misunderstood. You seemed to be saying their example is still valid 1.0, since "the definition being augmented from the submodule is arguably in a different module". Jernej > > Lada > >> would mean breaking out of submodule containment, much like when we discussed XPath expressions breaking out of module containment. >> >> Jernej >> >>> Lada >>> >>>> Is such definition also augmentation. >>>> >>>> >>>> >>>> ________________________________________ >>>> Od: Ladislav Lhotka >>>> Odoslané: 29. februára 2016 17:36 >>>> Komu: Peter Verthez >>>> Kópia: netmod@ietf.org >>>> Predmet: Re: [netmod] Augment issue >>>> >>>> Hi Peter, >>>> >>>> I agree it should be OK. I tried to reproduce the situation and test it with pyang and it led to a Python exception. So I filed an issue: >>>> >>>> https://github.com/mbj4668/pyang/issues/206 >>>> >>>> Lada >>>> >>>>> On 29 Feb 2016, at 10:09, Peter Verthez wrote: >>>>> >>>>> Hi all, >>>>> >>>>> A few weeks ago I reported a bug on the OpenDaylight YANG parser, regarding a error that was generated on a particular augment construction. The bug report is the following: >>>>> https://bugs.opendaylight.org/show_bug.cgi?id=5335 >>>>> >>>>> We are disagreeing on the interpretation of the YANG RFC regarding to this bug, so could we get the opinion of the people on this mailing list on it? >>>>> >>>>> The problem originated from a proposed Broadband Forum model, but there's a dummy model that reproduces the problem attached to that bug report. >>>>> >>>>> Thanks, >>>>> Peter. >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> AntonTkáčik >>>> Chief Software Architect >>>> >>>> Mlynské Nivy 56 / 821 05 Bratislava / Slovakia >>>> +421 911 309 249 / anton.tkacik@pantheon.tech >>>> reception: +421 2 206 65 111 / www.pantheon.sk >>>> [logo] >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > From nobody Tue Mar 1 03:50:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8744D1A21AF for ; Tue, 1 Mar 2016 03:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.006] autolearn=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 xHZhdcm6iUoW for ; Tue, 1 Mar 2016 03:50:32 -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 87D071A21C3 for ; Tue, 1 Mar 2016 03:50:28 -0800 (PST) Received: from [IPv6:2001:1488:fffe:255:a43c:bf36:6fd:58c9] (unknown [IPv6:2001:1488:fffe:255:a43c:bf36:6fd:58c9]) by mail.nic.cz (Postfix) with ESMTPSA id 0130018168C; Tue, 1 Mar 2016 12:50:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456833027; bh=UjMT3gL5n/9K/3tVCQjtvkVhRjtVO07f5W4Hcr67VQU=; h=From:Date:To; b=LSHFK4I/nm8kKSD0yC/+/Br7SkOf5KEFw+Rp56he7vQjul3iz+H3HKOJx8kIkphc0 9GAvJYOyXmQURrGFur6fJA4saGCgXBjcuH+Vl1bSbsOJDDj5M/aLjWPVjrOS/pKTAi eIqDs4wbFPPDmxxpvGadY3U+b9VW1s404W60AlI4= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56D579A1.1070701@mg-soft.si> Date: Tue, 1 Mar 2016 12:50:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <66C79E7F-3894-4669-A44F-2D33EB7F646B@nic.cz> References: <56D40ABD.40507@alcatel-lucent.com> <3101CBD7-6B1A-4FA1-B238-65B05AA6C63D@nic.cz> <1456825129206.33792@pantheon.tech> <46058C3A-C2F6-4012-9A21-BD8A475BB601@nic.cz> <56D56D27.5090502@mg-soft.si> <70C510A6-980B-48C7-9814-5A7FA5656120@nic.cz> <56D579A1.1070701@mg-soft.si> To: Jernej Tuljak X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Peter Verthez , "netmod@ietf.org" Subject: Re: [netmod] Augment issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 11:50:34 -0000 > On 01 Mar 2016, at 12:14, Jernej Tuljak = wrote: >=20 > Ladislav Lhotka je 1.3.2016 ob 11:33 napisal: >>> On 01 Mar 2016, at 11:21, Jernej Tuljak = wrote: >>>=20 >>> Ladislav Lhotka je 1.3.2016 ob 10:42 napisal: >>>>> On 01 Mar 2016, at 10:38, Anton Tk=E1=E8ik = wrote: >>>>>=20 >>>>> Hi, >>>>> Noticed other issue with example set, >>>>> In https://github.com/mbj4668/pyang/issues/194 Lada stated that in = YANG 1.0 submodule can not augment nodes >>>>> defined in parent model. >>>>>=20 >>>>> Is that correct that submodule can not augment definition defined = in parent module? >>>> This isn't possible in YANG 1.0 but will be possible in 1.1. = However, in the present case the definition being augmented from the = submodule is arguably in a different module. >>> I disagree. Submodules do not see "/jbox:jukebox/jboxcd:cdcapable" = in 1.0, since "jbox:cdcapable" is a name defined in the main module. An = explicit include of another submodule doing the augmentation is needed = to make their test case valid YANG. Any other case >> Isn't it what I wrote? This has changed in 1.1, no includes are = needed in submodules in order to "see" definitions in the main module? >=20 > Perhaps I misunderstood. You seemed to be saying their example is = still valid 1.0, since "the definition being augmented from the = submodule is arguably in a different module". I understood that Anton was asking about a submodule augmenting "native" = target nodes defined in the main module. I agree that the outcome for = augmenting an augment is not clear in 1.0. In any case, in 1.1 this = issue should be gone. Lada=20 >=20 > Jernej >=20 >>=20 >> Lada >>=20 >>> would mean breaking out of submodule containment, much like when we = discussed XPath expressions breaking out of module containment. >>>=20 >>> Jernej >>>=20 >>>> Lada >>>>=20 >>>>> Is such definition also augmentation. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ________________________________________ >>>>> Od: Ladislav Lhotka >>>>> Odoslan=E9: 29. febru=E1ra 2016 17:36 >>>>> Komu: Peter Verthez >>>>> K=F3pia: netmod@ietf.org >>>>> Predmet: Re: [netmod] Augment issue >>>>>=20 >>>>> Hi Peter, >>>>>=20 >>>>> I agree it should be OK. I tried to reproduce the situation and = test it with pyang and it led to a Python exception. So I filed an = issue: >>>>>=20 >>>>> https://github.com/mbj4668/pyang/issues/206 >>>>>=20 >>>>> Lada >>>>>=20 >>>>>> On 29 Feb 2016, at 10:09, Peter Verthez = wrote: >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> A few weeks ago I reported a bug on the OpenDaylight YANG parser, = regarding a error that was generated on a particular augment = construction. The bug report is the following: >>>>>> https://bugs.opendaylight.org/show_bug.cgi?id=3D5335 >>>>>>=20 >>>>>> We are disagreeing on the interpretation of the YANG RFC = regarding to this bug, so could we get the opinion of the people on this = mailing list on it? >>>>>>=20 >>>>>> The problem originated from a proposed Broadband Forum model, but = there's a dummy model that reproduces the problem attached to that bug = report. >>>>>>=20 >>>>>> Thanks, >>>>>> Peter. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> AntonTk=E1=E8ik >>>>> Chief Software Architect >>>>>=20 >>>>> Mlynsk=E9 Nivy 56 / 821 05 Bratislava / Slovakia >>>>> +421 911 309 249 / anton.tkacik@pantheon.tech >>>>> reception: +421 2 206 65 111 / www.pantheon.sk >>>>> [logo] >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 1 07:28:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20C61ACC8D for ; Tue, 1 Mar 2016 06:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR_wqZCkLhTZ for ; Tue, 1 Mar 2016 06:59:16 -0800 (PST) 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 DAB851AC7E8 for ; Tue, 1 Mar 2016 06:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7803; q=dns/txt; s=iport; t=1456844355; x=1458053955; h=from:to:cc:subject:date:message-id:mime-version; bh=Ou2OfwMXAckJjB3zyhVAJ1okfqTdh1iIJzw9eKo0Fms=; b=Bvmnh1Q7y4TLuGL/ilBzjuEJxp5NmCCNoVa9m/QP164NSC61o0mn0dxZ LnFqrJMQWYCJZCZCiBwCrfIXMz9WFf8NqR3ccnO0E0uzC7bTzkCDAKbXz V0wbaTpEk7hEY2k1Zhqgn9L111DJl4/q7Ufy8+rKx8u58cvtTAW2lnrAx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAgA9rdVW/5xdJa1egm5MUnO6LAENg?= =?us-ascii?q?WaGE4FGOBQBAQEBAQEBZBwLhEQELUwSAW0TJgEEDg2IF794AQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEWkzsFlw4BE41Hjn2OSwEeAQFCg2SILX4BAQE?= X-IronPort-AV: E=Sophos; i="5.22,523,1449532800"; d="scan'208,217"; a="81861533" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2016 14:59:14 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u21ExErd027971 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 1 Mar 2016 14:59:14 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 1 Mar 2016 08:59:13 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.009; Tue, 1 Mar 2016 08:59:13 -0600 From: "Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco)" To: "netmod@ietf.org" Thread-Topic: Netconf, none operation and non-presence containers Thread-Index: AdFzx/0extDY26cfTbqtE5+VF5X/Ew== Date: Tue, 1 Mar 2016 14:59:13 +0000 Message-ID: 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.61.80.61] Content-Type: multipart/alternative; boundary="_000_e77b72ce35d84a57857e875354848072XCHALN018ciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 01 Mar 2016 07:28:12 -0800 Cc: "Tony Tkacik -X \(ttkacik - PANTHEON TECHNOLOGIES at Cisco\)" Subject: [netmod] Netconf, none operation and non-presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 14:59:18 -0000 --_000_e77b72ce35d84a57857e875354848072XCHALN018ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello netmod group, We've run into following situation with NETCONF and we would like to know y= our opinion on what's the correct behavior here: Model (root non-presence container with nested list) : container mapping-nodes { list mapping-node{ key "id"; leaf id { type string; } } } Netconf edit-config RPC (replacing mapping-node entry with none operation f= or mapping-nodes container, in an empty data store): ... none node1-put And the question here is: Whether the edit should fail or not ? The problem is that mapping-nodes container does not exist and in edit-conf= ig rpc, there's "none" operation associated to it. Our first assumption was that the resulting data structure should be invali= d due to missing root container and rpc should fail. However, the container is non-presence (exists only for organizing the hier= archy of data nodes), which means that it may be created/deleted as child n= odes appear/disappear. In which case, the operation doesn't have to fail and can create mapping-no= des container even if "none" operation is associated with it. Regards, Maros --_000_e77b72ce35d84a57857e875354848072XCHALN018ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello netmod group,

 

We’ve run into following situation with NETCON= F and we would like to know your opinion on what’s the correct behavi= or here:

 

Model (root non-presence container with neste= d list) :


container mapping-nodes {

    list m= apping-node{

    &= nbsp;   key "id";

    &= nbsp;   leaf id {

    &= nbsp;       type string;

    &= nbsp;   }

    }=

}

 

Netconf edit-config RPC (replacing mapping-no= de entry with none operation for mapping-nodes container, in an empty data = store):

 

    <edit-config>

        …

        <defau= lt-operation>none</default-operation>

        <confi= g>

        &nbs= p;   <mapping-nodes xmlns=3D"urn:opendaylight:mdsal:mappi= ng:test">

        &nbs= p;       <mapping-node xmlns:a=3D"urn= :ietf:params:xml:ns:netconf:base:1.0" a:operation=3D"replace"= ;>

        &nbs= p;           <id>no= de1-put</id>

        &nbs= p;       </mapping-node>

        &nbs= p;   </mapping-nodes>

        </conf= ig>

    </edit-config>

 

And the question here is: Whether the edit should= fail or not ?

The problem is that mapping-nodes container does not= exist and in edit-config rpc, there’s “none” operation a= ssociated to it.

Our first assumption was that the resulting data str= ucture should be invalid due to missing root container and rpc should fail.=

However, the container is non-presence (exists only = for organizing the hierarchy of data nodes), which means that it may be cre= ated/deleted as child nodes appear/disappear.

In which case, the operation doesn’t have to f= ail and can create mapping-nodes container even if “none” opera= tion is associated with it.

 

Regards,

Maros

--_000_e77b72ce35d84a57857e875354848072XCHALN018ciscocom_-- From nobody Tue Mar 1 07:29:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B841B2D52 for ; Tue, 1 Mar 2016 07:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obZknfUGmfP2 for ; Tue, 1 Mar 2016 07:29:52 -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 F21D01B2D4F for ; Tue, 1 Mar 2016 07:29:51 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C13DA14E4; Tue, 1 Mar 2016 16:29:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7lNq69BNVq42; Tue, 1 Mar 2016 16:29: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, 1 Mar 2016 16:29:50 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E27A020037; Tue, 1 Mar 2016 16:29:49 +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 qSDToemFU0Uh; Tue, 1 Mar 2016 16:29:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 324F420036; Tue, 1 Mar 2016 16:29:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 061913A02BBC; Tue, 1 Mar 2016 16:29:47 +0100 (CET) Date: Tue, 1 Mar 2016 16:29:47 +0100 From: Juergen Schoenwaelder To: "Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco)" Message-ID: <20160301152947.GA29060@elstar.local> Mail-Followup-To: "Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco)" , "netmod@ietf.org" , "Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "Tony Tkacik -X \(ttkacik - PANTHEON TECHNOLOGIES at Cisco\)" , "netmod@ietf.org" Subject: Re: [netmod] Netconf, none operation and non-presence containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Mar 2016 15:29:54 -0000 Hi, please send NETCONF specific questions to the NETCONF list and not to the NETMOD list. Your question does seem to be NETCONF specific. Thanks, /js On Tue, Mar 01, 2016 at 02:59:13PM +0000, Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco) wrote: > Hello netmod group, > > We've run into following situation with NETCONF and we would like to know your opinion on what's the correct behavior here: > > Model (root non-presence container with nested list) : > > container mapping-nodes { > list mapping-node{ > key "id"; > leaf id { > type string; > } > } > } > > Netconf edit-config RPC (replacing mapping-node entry with none operation for mapping-nodes container, in an empty data store): > > > ... > none > > > > node1-put > > > > > > And the question here is: Whether the edit should fail or not ? > The problem is that mapping-nodes container does not exist and in edit-config rpc, there's "none" operation associated to it. > Our first assumption was that the resulting data structure should be invalid due to missing root container and rpc should fail. > However, the container is non-presence (exists only for organizing the hierarchy of data nodes), which means that it may be created/deleted as child nodes appear/disappear. > In which case, the operation doesn't have to fail and can create mapping-nodes container even if "none" operation is associated with it. > > Regards, > Maros > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 1 08:20:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5BE1B2E50 for ; Tue, 1 Mar 2016 08:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMOMWU749imt for ; Tue, 1 Mar 2016 08:20:26 -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 EAB381B2E45 for ; Tue, 1 Mar 2016 08:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2118; q=dns/txt; s=iport; t=1456849226; x=1458058826; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=pZp+4QRmJ+ohBNhoP8uQSqACiKYZ2mboZmJ4uy2k4+A=; b=Ywtkn46pv0T7BXe7zBqeK00T6nKbCO2YFpML/Emyq+BPTVs+qdH8KqF5 wg0aiQ4DKHOeaM/5hNBCjqTXtjbujfIueelnC30iZrh6ymjUhLxa32w1b bldLxaoKon9zKhBr9WsBN2uSuyEELsYYfpyBk3puxtHMabtlnUXDFZPdj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBADNwNVW/xbLJq1evRqEB4grAQEBA?= =?us-ascii?q?QEBZRwLhGsVQDYCBRYLAgsDAgECAUsNCAEBiBuhMo9bjxwBAQEHAgEde4UXi2+?= =?us-ascii?q?BOgWXDo1iiSaFUI5MYoNkPIhvAQEB?= X-IronPort-AV: E=Sophos;i="5.22,523,1449532800"; d="scan'208";a="625793906" 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; 01 Mar 2016 16:20:17 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u21GKHeA026991 for ; Tue, 1 Mar 2016 16:20:17 GMT To: "netmod@ietf.org" From: Robert Wilton Message-ID: <56D5C142.1070508@cisco.com> Date: Tue, 1 Mar 2016 16:20:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] NETCONF/YANG operational state datastore X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:20:28 -0000 Hi, In some of the previous opstate related discussions on this alias, I had some confusion as to which datastore operational state is held in (or whether it is held in a datastore at all :-) It also seems that the NETCONF/YANG related RFCs are vague on whether operational state is actually held in a datastore, or if so what it is. I've given some snippets below. Is this something that needs to be clarified as errata to those standards (particularly NACM)? -- rfc6020bis, section 7.21.1. The config Statement states: " If "config" is "false", the definition represents state data. Data nodes representing state data are not part of configuration datastores." ... which obviously indicates that they are not part of any configuration datastore, but doesn't indicate that they are part of an operational state datastore. -- rfc6241 (section 1.1 terminology) defines datastore and configuration datastore as: o datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof. o configuration datastore: The datastore holding the complete set of configuration data that is required to get a device from its initial default state into a desired operational state. The NETCONF RFC then goes on to describe/use configuration datastores in various ways, but makes no further mention of any operational state datastore. E.g. the one line description of a NETCONF get request is "Description: Retrieve running configuration and device state information." -- rfc6536 NACM, (section 3.2. Datastore Access) states: Only the standard NETCONF datastores (candidate, running, and startup) are controlled by NACM. Local or remote files or datastores accessed via the parameter are not controlled by NACM. Which implies that if operational state is held in a datastore then it is not controlled by NACM - which presumably can't be right. Thanks, Rob From nobody Tue Mar 1 08:39:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBC21B2EEE for ; Tue, 1 Mar 2016 08:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHRjGSmFAkpj for ; Tue, 1 Mar 2016 08:39:51 -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 5E0261B2EF6 for ; Tue, 1 Mar 2016 08:39:47 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2D29D8D9; Tue, 1 Mar 2016 17:39:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id u0S7lP5GYUsz; Tue, 1 Mar 2016 17:39:37 +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, 1 Mar 2016 17:39:44 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE2F320038; Tue, 1 Mar 2016 17:39:44 +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 Br4hp4fL4qMF; Tue, 1 Mar 2016 17:39: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 BE32020036; Tue, 1 Mar 2016 17:39:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B256F3A02D1E; Tue, 1 Mar 2016 17:39:42 +0100 (CET) Date: Tue, 1 Mar 2016 17:39:42 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160301163942.GA29233@elstar.local> Mail-Followup-To: Robert Wilton , "netmod@ietf.org" References: <56D5C142.1070508@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D5C142.1070508@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] NETCONF/YANG operational state datastore X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Mar 2016 16:39:54 -0000 I once again point to section 4.3 and more specifically to section 4.3.3 of RFC 6244. There have also been several I-Ds and discussions during past WG meetings on how to deal with this issue. See for example this: https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 Some of the discussion took place in NETCONF. See for example http://www.ietf.org/proceedings/84/minutes/minutes-84-netconf http://www.ietf.org/proceedings/85/minutes/minutes-85-netconf It is actually interesting to look at Phil's slides: http://www.ietf.org/proceedings/85/slides/slides-85-netconf-6.pdf This was November 2012, i2rs was just getting born and open config likely did not even exist. All I want to point out is that this is not a new topic for people who have been around long enough and yes there were quite some discussions before we created the structure that is found in a couple of RFCs. The RFCs are reasonably consistent in saying what a configuration datastore is. The rest simply never was defined and so you can't find an answer in the RFCs (except perhaps section 4.3.3 of RFC 6244 documenting that whether operational state is a datastore or not is somewhat undefined). /js (in his historian role ;-) On Tue, Mar 01, 2016 at 04:20:18PM +0000, Robert Wilton wrote: > Hi, > > In some of the previous opstate related discussions on this alias, I had > some confusion as to which datastore operational state is held in (or > whether it is held in a datastore at all :-) > > It also seems that the NETCONF/YANG related RFCs are vague on whether > operational state is actually held in a datastore, or if so what it is. > I've given some snippets below. Is this something that needs to be > clarified as errata to those standards (particularly NACM)? > > -- > > rfc6020bis, section 7.21.1. The config Statement states: > > " If "config" is "false", the definition represents state data. Data > nodes representing state data are not part of configuration > datastores." > > ... which obviously indicates that they are not part of any > configuration datastore, but doesn't indicate that they are part of an > operational state datastore. > > -- > > rfc6241 (section 1.1 terminology) defines datastore and configuration > datastore as: > > o datastore: A conceptual place to store and access information. A > datastore might be implemented, for example, using files, a > database, flash memory locations, or combinations thereof. > > o configuration datastore: The datastore holding the complete set of > configuration data that is required to get a device from its > initial default state into a desired operational state. > > > The NETCONF RFC then goes on to describe/use configuration datastores in > various ways, but makes no further mention of any operational state > datastore. > > E.g. the one line description of a NETCONF get request is "Description: > Retrieve running configuration and device state information." > > -- > > rfc6536 NACM, (section 3.2. Datastore Access) states: > > Only the standard NETCONF datastores (candidate, running, and > startup) are controlled by NACM. Local or remote files or datastores > accessed via the parameter are not controlled by NACM. > > > Which implies that if operational state is held in a datastore then it > is not controlled by NACM - which presumably can't be right. > > > Thanks, > Rob > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 1 09:47:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A8A1B30C1 for ; Tue, 1 Mar 2016 09:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9MAoBdmO-r6 for ; Tue, 1 Mar 2016 09:46:58 -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 00A311B30B9 for ; Tue, 1 Mar 2016 09:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4618; q=dns/txt; s=iport; t=1456854418; x=1458064018; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=qlDf9EUTvi5QXaSt8n4LYJkRiIc+Mlke9B3ZB5/WfDQ=; b=fAJXRu+dMo6yfvLMB8FurBeLROBuhaR4kc6n5Hnjtb6tMXqeyCxwF9dT 58fE6Nvpt2xVkxd7qDcFF17qdSOOeiw/vTq7ekaaubMQPX275YyUCv3rR wF44n37z27ozRlOulE75oXV7NKsHYB8BVaKQ/wUnFfg9Hr/kSoXJaXFVU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQBd1NVW/xbLJq1ehAxtujQBDYFmF?= =?us-ascii?q?wqFKEoCggQUAQEBAQEBAWQcC4RCAQECAgEBATU2ChELGAkWDwkDAgECARUwBg0?= =?us-ascii?q?GAgEBBYgWDsAOAQEBAQEBAQEBAQEBAQEBAQEBAReGEoQ6g3oLEQGEWAEElw6FW?= =?us-ascii?q?YgJiSaFUI5MHgEBQoIDGYFIPC4Bhw6BMgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,524,1449532800"; d="scan'208";a="649660789" 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; 01 Mar 2016 17:46:56 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u21HktxB014455 for ; Tue, 1 Mar 2016 17:46:55 GMT To: "netmod@ietf.org" References: <56D5C142.1070508@cisco.com> <20160301163942.GA29233@elstar.local> From: Robert Wilton Message-ID: <56D5D590.3000303@cisco.com> Date: Tue, 1 Mar 2016 17:46:56 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160301163942.GA29233@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] NETCONF/YANG operational state datastore X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:47:00 -0000 Juergen, Thanks for the pointers. Some of them are very enlightening. The specific concern that caused me to send this email was the comment about applicable datastores for NACM, hence I was considering whether or not to submit an erratum on rfc6536 section 3.2. However, that section is specifically only talking about datastores, and given that operational state isn't (currently) formally defined as being a datastore in NETCONF/YANG then that section is probably still valid as it stands. Personally I think that it would be generally helpful if the drafts did provide some more explicit details on how operational data is/is not represented, and from some of your references it appears that I might not be the only one. :-) Rob On 01/03/2016 16:39, Juergen Schoenwaelder wrote: > I once again point to section 4.3 and more specifically to section > 4.3.3 of RFC 6244. There have also been several I-Ds and discussions > during past WG meetings on how to deal with this issue. See for > example this: > > https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 > > Some of the discussion took place in NETCONF. See for example > > http://www.ietf.org/proceedings/84/minutes/minutes-84-netconf > http://www.ietf.org/proceedings/85/minutes/minutes-85-netconf > > It is actually interesting to look at Phil's slides: > > http://www.ietf.org/proceedings/85/slides/slides-85-netconf-6.pdf > > This was November 2012, i2rs was just getting born and open config > likely did not even exist. All I want to point out is that this is not > a new topic for people who have been around long enough and yes there > were quite some discussions before we created the structure that is > found in a couple of RFCs. > > The RFCs are reasonably consistent in saying what a configuration > datastore is. The rest simply never was defined and so you can't find > an answer in the RFCs (except perhaps section 4.3.3 of RFC 6244 > documenting that whether operational state is a datastore or not is > somewhat undefined). > > /js (in his historian role ;-) > > On Tue, Mar 01, 2016 at 04:20:18PM +0000, Robert Wilton wrote: >> Hi, >> >> In some of the previous opstate related discussions on this alias, I had >> some confusion as to which datastore operational state is held in (or >> whether it is held in a datastore at all :-) >> >> It also seems that the NETCONF/YANG related RFCs are vague on whether >> operational state is actually held in a datastore, or if so what it is. >> I've given some snippets below. Is this something that needs to be >> clarified as errata to those standards (particularly NACM)? >> >> -- >> >> rfc6020bis, section 7.21.1. The config Statement states: >> >> " If "config" is "false", the definition represents state data. Data >> nodes representing state data are not part of configuration >> datastores." >> >> ... which obviously indicates that they are not part of any >> configuration datastore, but doesn't indicate that they are part of an >> operational state datastore. >> >> -- >> >> rfc6241 (section 1.1 terminology) defines datastore and configuration >> datastore as: >> >> o datastore: A conceptual place to store and access information. A >> datastore might be implemented, for example, using files, a >> database, flash memory locations, or combinations thereof. >> >> o configuration datastore: The datastore holding the complete set of >> configuration data that is required to get a device from its >> initial default state into a desired operational state. >> >> >> The NETCONF RFC then goes on to describe/use configuration datastores in >> various ways, but makes no further mention of any operational state >> datastore. >> >> E.g. the one line description of a NETCONF get request is "Description: >> Retrieve running configuration and device state information." >> >> -- >> >> rfc6536 NACM, (section 3.2. Datastore Access) states: >> >> Only the standard NETCONF datastores (candidate, running, and >> startup) are controlled by NACM. Local or remote files or datastores >> accessed via the parameter are not controlled by NACM. >> >> >> Which implies that if operational state is held in a datastore then it >> is not controlled by NACM - which presumably can't be right. >> >> >> Thanks, >> Rob >> >> >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 1 13:51:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21C61B422A; Tue, 1 Mar 2016 13:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAte_Lwg-AeG; Tue, 1 Mar 2016 13:51:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8A3BB1B3C3B; Tue, 1 Mar 2016 13:51:50 -0800 (PST) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u21LpngQ011723 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 1 Mar 2016 15:51:50 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local From: Robert Sparks To: General Area Review Team , "ietf@ietf.org" , netmod@ietf.org, draft-ietf-netmod-yang-metadata.all@ietf.org Message-ID: <56D60EF5.7020001@nostrum.com> Date: Tue, 1 Mar 2016 15:51:49 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 21:51:56 -0000 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-netmod-yang-metadata-04 Reviewer: Robert Sparks Review Date: 1Mar2016 IETF LC End Date: 9Mar2016 IESG Telechat date: not yet scheduled Summary: Ready with nits 1) I might be missing something obvious, but the introduction has two statements that don't seem aligned: " Values of annotations are not limited to strings; any YANG built-in or derived type may be used for them" and "annotations are scalar values and cannot be further structured". If I'm not missing something, that may be more of an open issue than a nit. 2) The shepherd writeup calls out the tension in figuring out whether to make this an extension or a new built-in statement. Please consider capturing the reasoning for the path you chose in the draft itself. From nobody Tue Mar 1 14:56:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90141B42EB; Tue, 1 Mar 2016 14:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uJ9MLDtmZI1; Tue, 1 Mar 2016 14:56:08 -0800 (PST) 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 39BA01B42E7; Tue, 1 Mar 2016 14:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1785; q=dns/txt; s=iport; t=1456872968; x=1458082568; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=er0310epgkJ6ffFzO8pwmZ3s/Dt0POo7KoQo6GPRroA=; b=H/SzkSVTNVSzXlu0BxX8d7nkg4qyUktEhp8HSv1wPWrUJIHvgfvZBKte 60RrWkY0vxT2SX3tEBkiVwGHHLaizIlovf4aB6YvZPfwy+aeMmVQUVPXB MoXD3VebYxlf+OCL9kGrB9znQ0OCLBK6Aomq4DkJlSEMzNvXuYlHzDaLy Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAgDRDdZW/40NJK1agzpSbQa6LQENg?= =?us-ascii?q?WYXCoUoSgKBTjgUAQEBAQEBAWQnhEEBAQEDAQEBATc0EAsCAQgOByEQJwslAgQ?= =?us-ascii?q?BEgiIDwgOvXcBAQEBAQEBAQEBAQEBAQEBAQEBEwSGEoQ6iG8Flw4BhViCb4UTg?= =?us-ascii?q?WeERIhShXWIVgEeAQFCggMZgUhqh0N+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,524,1449532800"; d="scan'208";a="242628283" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Mar 2016 22:56:07 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u21Mu7kS021132 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Mar 2016 22:56:07 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 1 Mar 2016 16:56:06 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Tue, 1 Mar 2016 16:56:06 -0600 From: "Eric Voit (evoit)" To: Lou Berger , netmod WG , "netmod-chairs@ietf.org" Thread-Topic: [netmod] Moving the WG discussion on mount forward Thread-Index: AQHRczHG5tUO9DZGpkeMHoFzBKqKgZ9FL2mQ Date: Tue, 1 Mar 2016 22:56:06 +0000 Message-ID: References: <56D4ACA6.40208@labn.net> In-Reply-To: <56D4ACA6.40208@labn.net> 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.82.252.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Moving the WG discussion on mount forward X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:56:10 -0000 What I would like to see: (1) Terminology included which unambiguously partitions the functions of th= e three different type of mount options discussed in this WG (i.e., structu= ral mount, alias mount, and peer mount). This would be needed even if on= ly the structural mount technology itself is specified in the draft. (2) Agreement from draft authors that any Mount options build off of a comm= on, extensible syntax. (3) Agreement from OpenDaylight developers that the peer mount definition c= orresponds to the meaning of their "Mount" Eric > From: netmod, February 29, 2016 3:40 PM >=20 >=20 > All, >=20 > At last week's interim, Martin committed to update his document based on = the > meeting and then work with the other mount document authors (i.e., Lada a= nd > Alex) on a future version. Martin has now published this version: > https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-02 >=20 > Lada also said that he was okay with using Martin's document as a startin= g point > for the working group document on this topic. (Keep in mind a -00 WG > document is a starting point, not and end point.) >=20 > We'd now like to ask for additional feedback from other WG contributors o= n > their opinions on what they would like see added to base document in orde= r for > it to be accepted as a WG document. > So please review the document and send comments to the list -- again on w= hat > areas need to be covered for the document to be accepted as a -00 WG draf= t. > We're hoping for comments within the next week or so. >=20 > Thank you, > Netmod chairs >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 2 03:16:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD4C1ACE73; Wed, 2 Mar 2016 02:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMs0f9fl7cKZ; Wed, 2 Mar 2016 02:42:14 -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 594BA1ACE70; Wed, 2 Mar 2016 02:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8460; q=dns/txt; s=iport; t=1456915333; x=1458124933; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=jUJDT5M2ITY28ZbrRQiBDEVH4nYY+du0rMH3woynNfA=; b=kXtmwb5C0imzPv9DoMd8fVTUfydLtvpBKwW379uzK/tau607A8KHNKbi qj3Te1Ph1GPmWGsT4vVAb2Q7Zk7aHGrU4M0JNjKY3hUbzeJBBwBFsXTvm g36t0tB2pnjw0Vwj+m658Rtozb9S5lYNWQ4Xg1A7Ur1DWqsGpXApFei/o k=; X-IronPort-AV: E=Sophos;i="5.22,528,1449532800"; d="scan'208";a="633011262" 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; 02 Mar 2016 10:42:11 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u22AgBJi027801; Wed, 2 Mar 2016 10:42:11 GMT To: "Acee Lindem (acee)" , Ladislav Lhotka References: <03b801d16382$b01e9e70$105bdb50$@olddog.co.uk> <56BA76C1.2040009@bogus.com> <56C01065.1000804@pi.nu> <56C1F076.5070708@innovationslab.net> <56C29512.3030401@pi.nu> <56C314FA.40209@innovationslab.net> <059901d168b9$15c92fc0$415b8f40$@olddog.co.uk> <56C32361.8050901@innovationslab.net> <56CEF681.5040306@cisco.com> <7C8F95D6-6F20-4E69-B7B3-2176C8F528D9@nic.cz> <56D00DAB.7060302@cisco.com> From: Benoit Claise Message-ID: <56D6B643.9050400@cisco.com> Date: Wed, 2 Mar 2016 10:45:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Wed, 02 Mar 2016 03:16:48 -0800 Cc: "Bocci, Matthew \(Matthew\)" , Brian Haberman , "ops-ads@ietf.org" , Santosh Esale , NETMOD WG , "rtg-ads@ietf.org" , George Swallow , Adrian Farrel , "Kamran Raza \(skraza\)" , joel jaeggli , "jescia.chenxia@huawei.com" , Loa Andersson , "int-ads@ietf.org" , Jeff Tantsura , Ross Callon , Adrian Farrel , "Rajiv Asati \(rajiva\)" , "Sowmya Krishnaswamy \(sowkrish\)" , Xufeng Liu Subject: Re: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 10:42:17 -0000 On 2/26/2016 1:13 PM, Acee Lindem (acee) wrote: > Hi Benoit, Lada, > > On 2/26/16, 3:32 AM, "netmod on behalf of Benoit Claise (bclaise)" > wrote: > >> Hi Lada, >> >>> Hi Benoit, >>> >>> this was discussed a while ago in this thread: >>> >>> https://mailarchive.ietf.org/arch/msg/netmod/TehrMAboX-cMmmX537rs81DNl3I >>> >>> tl;dr: The WG decision then was to introduce a new type in >>> ietf-inet-types, namely "dotted-quad", that explicitly does NOT have the >>> semantics of an IPv4 address - it is an uint32 number that's expressed >>> in the dotted quad format, which is what most router platforms accept as >>> routerID via CLI. >> From what I understand below, this is not an acceptable solution. >> I'm sure the routing experts will confirm this. > At least for the OSPF Router ID (RFC 2328) and the BGP Identifier (RFC > 4271), the dotted-quad type matches the semantics of the protocols. The > value is not necessarily a routable address and solely a unique 32-bit > identifier within the protocol routing domain that is commonly expressed > in dotted quad format. What is the problem with using this YANG type? uint32 sure, but what is the conclusion regarding dotted-quad? On one side, I hear: dotted-quad is suitable because it's uint32 and does NOT have the semantics of an IPv4 address. On the other side, I hear: we should not even display the identifier as an IPv4 address. The routing experts should tell us if the dotted-quad type is appropriate. Regards, Benoit > > Thanks, > Acee > >> Regards, Benoit >>> Lada >>> >>>> On 25 Feb 2016, at 13:41, Benoit Claise wrote: >>>> >>>> Dear all, >>>> >>>> Sorry for the delay (mix of vacation and business travel). >>>> >>>> Let me try to summarize the situation as I see it: >>>> - From the routing RFCs, BGP Identifier, OSPF router ID, TE >>>> identifier, and LSR identifiers are all an unsigned integers. >>>> - We need consistency for the router ID and identifier in YANG >>>> leaf/typedef >>>> - The OSPF MIB module has defined >>>> RouterID ::= TEXTUAL-CONVENTION >>>> STATUS current >>>> DESCRIPTION >>>> "A OSPF Router Identifier. >>>> Note that the Router ID, in OSPF, has the same format >>>> as an IP address, but identifies the router independent >>>> of its IP address." >>>> SYNTAX IpAddress >>>> >>>> >>>> ospfRouterId OBJECT-TYPE >>>> SYNTAX RouterID >>>> MAX-ACCESS read-write >>>> STATUS current >>>> DESCRIPTION >>>> "A 32-bit integer uniquely identifying the >>>> router in the Autonomous System. >>>> By convention, to ensure uniqueness, this >>>> should default to the value of one of the >>>> router's IP interface addresses. >>>> >>>> As Adrian mentioned: it is NOT an IP address but the MIB module uses >>>> the notational formatting of n IP address for display purposes. >>>> - An IPv4 address as OSPF router ID doesn't make sense in an IPv6 >>>> environment >>>> >>>> Based on this, I believe that: >>>> - We must not associate an IP address semantic with the router ID >>>> - Based on Brian's feedback (which I agree with) "As long as the YANG >>>> module does not specify a format that makes the routerID display like >>>> an IPv4 address", it was probably a mistake to have defined RouterID as >>>> IpAdress in OSPF MIB module. >>>> - Interestingly, >>>> https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-20 contains: >>>> >>>> grouping router-id { >>>> description >>>> "This grouping provides router ID."; >>>> leaf router-id { >>>> type yang:dotted-quad; >>>> description >>>> "A 32-bit number in the form of a dotted quad that is used >>>> by >>>> some routing protocols identifying a router."; >>>> reference >>>> " >>>> RFC 2328 >>>> : OSPF Version 2."; >>>> } >>>> } >>>> >>>> This should be an uint32 number. >>>> - An union-based solution is a bad compromise >>>> From draft-raza-mpls-ldp-mldp-yang-02 >>>> leaf lsr-id { >>>> type union { >>>> type yang:dotted-quad; >>>> type uint32; >>>> } >>>> description "LSR ID."; >>>> >>>> >>>> >>>> Since the question was asked: as AD, I would support uint32 everywhere. >>>> >>>> Now, practically, how to move forward? >>>> - Either all drafts reference draft-ietf-netmod-routing-cfg-20 (with >>>> the uint32 modification), >>>> - Or you create a "Common Routing YANG Data Types", similarly to RFC >>>> 6991 including the router IDs. I see already many typedef in >>>> draft-raza-mpls-ldp-mldp-yang-02 >>>> - Or you define you own types in your own draft >>>> >>>> But, if we have agreement on the uint32, let's document this now >>>> somewhere/somehow, and let's not revisit this on regular basis (yes, I >>>> see it coming...) >>>> A few lines of explanation in the draft would already help for >>>> example, in an operational section, explaining to people the mapping of >>>> the MIB OSPF RouterID to the YANG object >>>> >>>> Regards, Benoit >>>>> Hi Adrian, >>>>> >>>>> On 2/16/16 7:53 AM, Adrian Farrel wrote: >>>>> >>>>>> Hi Brian, >>>>>> >>>>>> I said I wasn't going to participate in this discussion :-) >>>>>> >>>>> Nice try. ;) >>>>> >>>>> >>>>>>>> I should not respond to questions that I don't fully understand, >>>>>>>> but: >>>>>>>> >>>>>>>> the BGP Identifier is an unsigned integer >>>>>>>> the OSPF router ID is an unsigned integer >>>>>>>> >>>>>>> I assume the above is based on the YANG definition of OSPF >>>>>>> routerID. RFC >>>>>>> 4750 says the routerID is an IPv4 address. Is that an issue? >>>>>>> >>>>>> To quote from 4750... >>>>>> >>>>>> RouterID ::= TEXTUAL-CONVENTION >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "A OSPF Router Identifier. >>>>>> Note that the Router ID, in OSPF, has the same format >>>>>> as an IP address, but identifies the router independent >>>>>> of its IP address." >>>>>> SYNTAX IpAddress >>>>>> >>>>>> So it explicitly says it is NOT an IP address but the MIB module >>>>>> uses the notational formatting of n IP address for display purposes. >>>>>> >>>>>> I think this is done because the router ID is often chosen to be an >>>>>> IP address of the router, and because it is easier for humans to deal >>>>>> with a.b.c.d where each element is a 3-digit number less than 256, >>>>>> than it is to manage a single number in the range 0 to 2^32 -1. >>>>>> >>>>>> >>>>> The above is the textual convention, whereas the following is the >>>>> actual >>>>> OSPF routerID... >>>>> >>>>> ospfRouterId OBJECT-TYPE >>>>> SYNTAX RouterID >>>>> MAX-ACCESS read-write >>>>> STATUS current >>>>> DESCRIPTION >>>>> "A 32-bit integer uniquely identifying the >>>>> router in the Autonomous System. >>>>> By convention, to ensure uniqueness, this >>>>> should default to the value of one of the >>>>> router's IP interface addresses. >>>>> >>>>> So the MIB actually says the default is to use an IPv4 address... >>>>> >>>>> All that being said, my point was further along where I said: >>>>> >>>>> >>>>>>> I am not concerned with what the operator will choose as his/her >>>>>>> routerID value. I am concerned with what format options will be >>>>>>> associated with the routerID in the yang module. As long as the >>>>>>> format >>>>>>> options does not allow display in dotted decimal notation, I am >>>>>>> fine. >>>>>>> >>>>> As long as the YANG module does not specify a format that makes the >>>>> routerID display like an IPv4 address, I am fine. >>>>> >>>>> Brian >>>>> >>>>> >>>>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> . >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 2 04:38:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57B41A1BCC; Wed, 2 Mar 2016 04:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy1otqfzeDTW; Wed, 2 Mar 2016 04:22:57 -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 4B4DF1A1B24; Wed, 2 Mar 2016 04:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9140; q=dns/txt; s=iport; t=1456921377; x=1458130977; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=d/9Zpjav0jGFxj8YQK/JV6mVHflCHrEKzBClnlqGNyE=; b=dHWEY1+F3XeYZJscL/bo+UEUaBDFBZOV7C+hXmzETadlKibMxBwmZqHJ 7R1N2mDRwEnl4kZC/f7fCZ1+UIrIBDZ8RYYoSPUB3nAvhsx9SEdADTblH YsPkSla+JhQk2MPgf6jg2+ugy9hLNf8tK8C7sy0AR+C3SoKVnuUxCLc6Q w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgBs2tZW/5pdJa1egzpSXg+6JQENg?= =?us-ascii?q?WcXDIUmSgKBRjgUAQEBAQEBAWQnhEEBAQEDAQEBATcxAwsFCwIBCBgeBQsnCyU?= =?us-ascii?q?CBA4FG4d+CA64IQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKBbIJOgiiCC4Mtg?= =?us-ascii?q?Q8FlxIBhVmICYFgh2mFLY5LAR4BAUKCAxkUgTRqiGABAQE?= X-IronPort-AV: E=Sophos;i="5.22,528,1449532800"; d="scan'208";a="243181140" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2016 12:22:56 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u22CMuf0014903 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Mar 2016 12:22:56 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Mar 2016 06:22:55 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.009; Wed, 2 Mar 2016 06:22:55 -0600 From: "Rajiv Asati (rajiva)" To: "Benoit Claise (bclaise)" Thread-Topic: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02] Thread-Index: AQHRdGhHDGCjmMM3SVO8zztT1y00HJ9GE678 Date: Wed, 2 Mar 2016 12:22:54 +0000 Message-ID: <597CDEEE-EEE3-449F-BA08-5937AE8D8AFD@cisco.com> References: <03b801d16382$b01e9e70$105bdb50$@olddog.co.uk> <56BA76C1.2040009@bogus.com> <56C01065.1000804@pi.nu> <56C1F076.5070708@innovationslab.net> <56C29512.3030401@pi.nu> <56C314FA.40209@innovationslab.net> <059901d168b9$15c92fc0$415b8f40$@olddog.co.uk> <56C32361.8050901@innovationslab.net> <56CEF681.5040306@cisco.com> <7C8F95D6-6F20-4E69-B7B3-2176C8F528D9@nic.cz> <56D00DAB.7060302@cisco.com> ,<56D6B643.9050400@cisco.com> In-Reply-To: <56D6B643.9050400@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 02 Mar 2016 04:38:47 -0800 Cc: "Bocci, Matthew \(Matthew\)" , Brian Haberman , "ops-ads@ietf.org" , Santosh Esale , NETMOD WG , "rtg-ads@ietf.org" , "Sowmya Krishnaswamy \(sowkrish\)" , Adrian Farrel , George Swallow , joel jaeggli , Jeff Tantsura , "jescia.chenxia@huawei.com" , "int-ads@ietf.org" , "Kamran Raza \(skraza\)" , Ross Callon , Adrian Farrel , Loa Andersson , Xufeng Liu Subject: Re: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 12:23:00 -0000 dotted-quad is very much suitable to represent the router ID for various pr= otocols including LDP. This maintains the backward compatibility and is of = uint32 type.=20 Cheers, Rajiv=20 > On Mar 2, 2016, at 5:42 AM, Benoit Claise (bclaise) w= rote: >=20 >> On 2/26/2016 1:13 PM, Acee Lindem (acee) wrote: >> Hi Benoit, Lada, >>=20 >> On 2/26/16, 3:32 AM, "netmod on behalf of Benoit Claise (bclaise)" >> wrote: >>=20 >>> Hi Lada, >>>=20 >>>> Hi Benoit, >>>>=20 >>>> this was discussed a while ago in this thread: >>>>=20 >>>> https://mailarchive.ietf.org/arch/msg/netmod/TehrMAboX-cMmmX537rs81DNl= 3I >>>>=20 >>>> tl;dr: The WG decision then was to introduce a new type in >>>> ietf-inet-types, namely "dotted-quad", that explicitly does NOT have t= he >>>> semantics of an IPv4 address - it is an uint32 number that's expressed >>>> in the dotted quad format, which is what most router platforms accept = as >>>> routerID via CLI. >>> From what I understand below, this is not an acceptable solution. >>> I'm sure the routing experts will confirm this. >> At least for the OSPF Router ID (RFC 2328) and the BGP Identifier (RFC >> 4271), the dotted-quad type matches the semantics of the protocols. The >> value is not necessarily a routable address and solely a unique 32-bit >> identifier within the protocol routing domain that is commonly expressed >> in dotted quad format. What is the problem with using this YANG type? > uint32 sure, but what is the conclusion regarding dotted-quad? > On one side, I hear: dotted-quad is suitable because it's uint32 and does= NOT have the semantics of an IPv4 address. > On the other side, I hear: we should not even display the identifier as a= n IPv4 address. >=20 > The routing experts should tell us if the dotted-quad type is appropriate= . >=20 > Regards, Benoit >>=20 >> Thanks, >> Acee >>=20 >>> Regards, Benoit >>>> Lada >>>>=20 >>>>> On 25 Feb 2016, at 13:41, Benoit Claise wrote: >>>>>=20 >>>>> Dear all, >>>>>=20 >>>>> Sorry for the delay (mix of vacation and business travel). >>>>>=20 >>>>> Let me try to summarize the situation as I see it: >>>>> - From the routing RFCs, BGP Identifier, OSPF router ID, TE >>>>> identifier, and LSR identifiers are all an unsigned integers. >>>>> - We need consistency for the router ID and identifier in YANG >>>>> leaf/typedef >>>>> - The OSPF MIB module has defined >>>>> RouterID ::=3D TEXTUAL-CONVENTION >>>>> STATUS current >>>>> DESCRIPTION >>>>> "A OSPF Router Identifier. >>>>> Note that the Router ID, in OSPF, has the same format >>>>> as an IP address, but identifies the router independent >>>>> of its IP address." >>>>> SYNTAX IpAddress >>>>>=20 >>>>>=20 >>>>> ospfRouterId OBJECT-TYPE >>>>> SYNTAX RouterID >>>>> MAX-ACCESS read-write >>>>> STATUS current >>>>> DESCRIPTION >>>>> "A 32-bit integer uniquely identifying the >>>>> router in the Autonomous System. >>>>> By convention, to ensure uniqueness, this >>>>> should default to the value of one of the >>>>> router's IP interface addresses. >>>>>=20 >>>>> As Adrian mentioned: it is NOT an IP address but the MIB module uses >>>>> the notational formatting of n IP address for display purposes. >>>>> - An IPv4 address as OSPF router ID doesn't make sense in an IPv6 >>>>> environment >>>>>=20 >>>>> Based on this, I believe that: >>>>> - We must not associate an IP address semantic with the router ID >>>>> - Based on Brian's feedback (which I agree with) "As long as the YANG >>>>> module does not specify a format that makes the routerID display like >>>>> an IPv4 address", it was probably a mistake to have defined RouterID = as >>>>> IpAdress in OSPF MIB module. >>>>> - Interestingly, >>>>> https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-20 contains= : >>>>>=20 >>>>> grouping router-id { >>>>> description >>>>> "This grouping provides router ID."; >>>>> leaf router-id { >>>>> type yang:dotted-quad; >>>>> description >>>>> "A 32-bit number in the form of a dotted quad that is use= d >>>>> by >>>>> some routing protocols identifying a router."; >>>>> reference >>>>> " >>>>> RFC 2328 >>>>> : OSPF Version 2."; >>>>> } >>>>> } >>>>>=20 >>>>> This should be an uint32 number. >>>>> - An union-based solution is a bad compromise >>>>> From draft-raza-mpls-ldp-mldp-yang-02 >>>>> leaf lsr-id { >>>>> type union { >>>>> type yang:dotted-quad; >>>>> type uint32; >>>>> } >>>>> description "LSR ID."; >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Since the question was asked: as AD, I would support uint32 everywher= e. >>>>>=20 >>>>> Now, practically, how to move forward? >>>>> - Either all drafts reference draft-ietf-netmod-routing-cfg-20 (with >>>>> the uint32 modification), >>>>> - Or you create a "Common Routing YANG Data Types", similarly to RFC >>>>> 6991 including the router IDs. I see already many typedef in >>>>> draft-raza-mpls-ldp-mldp-yang-02 >>>>> - Or you define you own types in your own draft >>>>>=20 >>>>> But, if we have agreement on the uint32, let's document this now >>>>> somewhere/somehow, and let's not revisit this on regular basis (yes, = I >>>>> see it coming...) >>>>> A few lines of explanation in the draft would already help for >>>>> example, in an operational section, explaining to people the mapping = of >>>>> the MIB OSPF RouterID to the YANG object >>>>>=20 >>>>> Regards, Benoit >>>>>> Hi Adrian, >>>>>>=20 >>>>>>> On 2/16/16 7:53 AM, Adrian Farrel wrote: >>>>>>>=20 >>>>>>> Hi Brian, >>>>>>>=20 >>>>>>> I said I wasn't going to participate in this discussion :-) >>>>>>>=20 >>>>>> Nice try. ;) >>>>>>=20 >>>>>>=20 >>>>>>>>> I should not respond to questions that I don't fully understand, >>>>>>>>> but: >>>>>>>>>=20 >>>>>>>>> the BGP Identifier is an unsigned integer >>>>>>>>> the OSPF router ID is an unsigned integer >>>>>>>>>=20 >>>>>>>> I assume the above is based on the YANG definition of OSPF >>>>>>>> routerID. RFC >>>>>>>> 4750 says the routerID is an IPv4 address. Is that an issue? >>>>>>>>=20 >>>>>>> To quote from 4750... >>>>>>>=20 >>>>>>> RouterID ::=3D TEXTUAL-CONVENTION >>>>>>> STATUS current >>>>>>> DESCRIPTION >>>>>>> "A OSPF Router Identifier. >>>>>>> Note that the Router ID, in OSPF, has the same format >>>>>>> as an IP address, but identifies the router independent >>>>>>> of its IP address." >>>>>>> SYNTAX IpAddress >>>>>>>=20 >>>>>>> So it explicitly says it is NOT an IP address but the MIB module >>>>>>> uses the notational formatting of n IP address for display purposes= . >>>>>>>=20 >>>>>>> I think this is done because the router ID is often chosen to be an >>>>>>> IP address of the router, and because it is easier for humans to de= al >>>>>>> with a.b.c.d where each element is a 3-digit number less than 256, >>>>>>> than it is to manage a single number in the range 0 to 2^32 -1. >>>>>>>=20 >>>>>>>=20 >>>>>> The above is the textual convention, whereas the following is the >>>>>> actual >>>>>> OSPF routerID... >>>>>>=20 >>>>>> ospfRouterId OBJECT-TYPE >>>>>> SYNTAX RouterID >>>>>> MAX-ACCESS read-write >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "A 32-bit integer uniquely identifying the >>>>>> router in the Autonomous System. >>>>>> By convention, to ensure uniqueness, this >>>>>> should default to the value of one of the >>>>>> router's IP interface addresses. >>>>>>=20 >>>>>> So the MIB actually says the default is to use an IPv4 address... >>>>>>=20 >>>>>> All that being said, my point was further along where I said: >>>>>>=20 >>>>>>=20 >>>>>>>> I am not concerned with what the operator will choose as his/her >>>>>>>> routerID value. I am concerned with what format options will be >>>>>>>> associated with the routerID in the yang module. As long as the >>>>>>>> format >>>>>>>> options does not allow display in dotted decimal notation, I am >>>>>>>> fine. >>>>>>>>=20 >>>>>> As long as the YANG module does not specify a format that makes the >>>>>> routerID display like an IPv4 address, I am fine. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> . >>>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Wed Mar 2 06:44:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB8A1B2BD7 for ; Wed, 2 Mar 2016 06:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.006] autolearn=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 FuSbrfXJsyCU for ; Wed, 2 Mar 2016 06:44:43 -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 7EBB21B2B98 for ; Wed, 2 Mar 2016 06:44:42 -0800 (PST) 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 ACB53181C61; Wed, 2 Mar 2016 15:44:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456929880; bh=Hd6yCFdUqqG0reh0mDQryvfsVazcD2Q1ZlhYlBwoVhU=; h=From:Date:To; b=i+iLGWZRRQm02is9OzDbF5W9QKOWE3hBenppAA4xk3RhJaFqJnCfR7w3HMV3Yl/CA ur7iR30UJwfYo29nILHxu0F72o4+EiZ0lkI4aNk+kBd09zbAC4o5G0IPjb5wmTUa3o 5RBqcqor2Xx/ORCJ99T2ViEX36gYmPhaM5nk/CvI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 2 Mar 2016 15:44:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9211B380-B0EE-43C5-964C-7884351BE498@nic.cz> References: To: Kent Watsen X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 14:44:45 -0000 > On 01 Mar 2016, at 00:07, Kent Watsen wrote: >=20 >=20 > The chairs were just reviewing notes and realized that this thread = never closed properly. >=20 > Juergen has some concerns regarding realistic milestones, that were = never addressed. Robert, can you please try to address Juergen=E2=80=99s = concerns now? >=20 > Also, there were only a two responses before indicating willingness to = review the draft as it progresses (thanks Dan and Martin). Can others = that support this draft and willing to review this draft say so? Sorry I haven't responded earlier. I support adopting this document as a = WG item, and I will review it. Lada >=20 > Thanks, > Netmod Chairs >=20 >=20 > From: netmod on behalf of Kent Watsen = > Date: Tuesday, December 15, 2015 at 11:48 AM > To: "netmod@ietf.org" > Subject: [netmod] call for consensus to adopt = draft-wilton-netmod-intf-ext-yang as NETMOD WG draft >=20 >=20 > The minutes for IETF 94 show that there was in-room support for = adopting draft-wilton-netmod-intf-ext-yang as a WG draft. The minutes = also show that this decision would be confirmed on the mailing list, = which I am doing now. =20 >=20 > Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item = and correspondingly add this to the WG charter as a milestone? Please = comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG = Chairs will gauge whether or not there is consensus to move forward with = the document. >=20 > Thanks, > Kent >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 2 06:54:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1881B2B56; Wed, 2 Mar 2016 06:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTTHQbGj2y3E; Wed, 2 Mar 2016 06:33:25 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A4A1B2B55; Wed, 2 Mar 2016 06:33:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12538; q=dns/txt; s=iport; t=1456929202; x=1458138802; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=d4lcD0OJpKnrgt2bzc5STy2G/hwQMHf5RKDaJOeaesQ=; b=RzkOaKXf/iju+jPqbp+ywpEUfqrsWAjg8D4inMwYaLBAD4qqn6PXM07f A48a+O7O5oNcPuczqDxYxWl5uu25MDkIFqGeh7vB6T4meebv7Dsye9Sne dG6OQ4hC4gVp5d2kq96iC6FwaroX+LU3G/Qbcfg89Gjrxh7FYvqCf07Or Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgB0+dZW/51dJa1egzpSbQa6IAENg?= =?us-ascii?q?WcXCoUoSgIcgSk4FAEBAQEBAQFkJ4RCAQEEAQEBIBE3AwsQAgEIGAICHwcCAgI?= =?us-ascii?q?lCxUQAgQBDQUbiAYOqjiPHAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEe4lRgiiCC?= =?us-ascii?q?xiCaoE6BZcSAYVZiAmBYIdphS2OSwEeAQFCggMZFIE0aodifgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,529,1449532800"; d="scan'208";a="244700930" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2016 14:33:00 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u22EX0dc027575 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Mar 2016 14:33:00 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Mar 2016 08:32:59 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Wed, 2 Mar 2016 08:32:59 -0600 From: "Acee Lindem (acee)" To: "Benoit Claise (bclaise)" , Ladislav Lhotka Thread-Topic: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02] Thread-Index: AQHRb9DmpmJ/M3F6OEK7UQLfQDjiaZ8+ZXmA///p5QCACAYjgP///HSA Date: Wed, 2 Mar 2016 14:32:59 +0000 Message-ID: References: <03b801d16382$b01e9e70$105bdb50$@olddog.co.uk> <56BA76C1.2040009@bogus.com> <56C01065.1000804@pi.nu> <56C1F076.5070708@innovationslab.net> <56C29512.3030401@pi.nu> <56C314FA.40209@innovationslab.net> <059901d168b9$15c92fc0$415b8f40$@olddog.co.uk> <56C32361.8050901@innovationslab.net> <56CEF681.5040306@cisco.com> <7C8F95D6-6F20-4E69-B7B3-2176C8F528D9@nic.cz> <56D00DAB.7060302@cisco.com> <56D6B643.9050400@cisco.com> In-Reply-To: <56D6B643.9050400@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.199] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 02 Mar 2016 06:54:49 -0800 Cc: "Bocci, Matthew \(Matthew\)" , Brian Haberman , "ops-ads@ietf.org" , Santosh Esale , NETMOD WG , "rtg-ads@ietf.org" , George Swallow , Adrian Farrel , "Kamran Raza \(skraza\)" , joel jaeggli , "jescia.chenxia@huawei.com" , Loa Andersson , "int-ads@ietf.org" , Jeff Tantsura , Ross Callon , Adrian Farrel , "Rajiv Asati \(rajiva\)" , "Sowmya Krishnaswamy \(sowkrish\)" , Xufeng Liu Subject: Re: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 14:33:27 -0000 DQoNCk9uIDMvMi8xNiwgNDo0NSBBTSwgIkJlbm9pdCBDbGFpc2UgKGJjbGFpc2UpIiA8YmNsYWlz ZUBjaXNjby5jb20+IHdyb3RlOg0KDQo+T24gMi8yNi8yMDE2IDE6MTMgUE0sIEFjZWUgTGluZGVt IChhY2VlKSB3cm90ZToNCj4+IEhpIEJlbm9pdCwgTGFkYSwNCj4+DQo+PiBPbiAyLzI2LzE2LCAz OjMyIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKSINCj4+ IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYmNsYWlzZUBjaXNjby5jb20+ IHdyb3RlOg0KPj4NCj4+PiBIaSBMYWRhLA0KPj4+DQo+Pj4+IEhpIEJlbm9pdCwNCj4+Pj4NCj4+ Pj4gdGhpcyB3YXMgZGlzY3Vzc2VkIGEgd2hpbGUgYWdvIGluIHRoaXMgdGhyZWFkOg0KPj4+Pg0K Pj4+PiANCj4+Pj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25ldG1vZC9U ZWhyTUFib1gtY01tbVg1MzdyczgxRE5sMw0KPj4+PkkNCj4+Pj4NCj4+Pj4gdGw7ZHI6IFRoZSBX RyBkZWNpc2lvbiB0aGVuIHdhcyB0byBpbnRyb2R1Y2UgYSBuZXcgdHlwZSBpbg0KPj4+PiBpZXRm LWluZXQtdHlwZXMsIG5hbWVseSAiZG90dGVkLXF1YWQiLCB0aGF0IGV4cGxpY2l0bHkgZG9lcyBO T1QgaGF2ZQ0KPj4+PnRoZQ0KPj4+PiBzZW1hbnRpY3Mgb2YgYW4gSVB2NCBhZGRyZXNzIC0gaXQg aXMgYW4gdWludDMyIG51bWJlciB0aGF0J3MgZXhwcmVzc2VkDQo+Pj4+IGluIHRoZSBkb3R0ZWQg cXVhZCBmb3JtYXQsIHdoaWNoIGlzIHdoYXQgbW9zdCByb3V0ZXIgcGxhdGZvcm1zIGFjY2VwdA0K Pj4+PmFzDQo+Pj4+IHJvdXRlcklEIHZpYSBDTEkuDQo+Pj4gIEZyb20gd2hhdCBJIHVuZGVyc3Rh bmQgYmVsb3csIHRoaXMgaXMgbm90IGFuIGFjY2VwdGFibGUgc29sdXRpb24uDQo+Pj4gSSdtIHN1 cmUgdGhlIHJvdXRpbmcgZXhwZXJ0cyB3aWxsIGNvbmZpcm0gdGhpcy4NCj4+IEF0IGxlYXN0IGZv ciB0aGUgT1NQRiBSb3V0ZXIgSUQgKFJGQyAyMzI4KSBhbmQgdGhlIEJHUCBJZGVudGlmaWVyIChS RkMNCj4+IDQyNzEpLCB0aGUgZG90dGVkLXF1YWQgdHlwZSBtYXRjaGVzIHRoZSBzZW1hbnRpY3Mg b2YgdGhlIHByb3RvY29scy4gVGhlDQo+PiB2YWx1ZSBpcyBub3QgbmVjZXNzYXJpbHkgYSByb3V0 YWJsZSBhZGRyZXNzIGFuZCBzb2xlbHkgYSB1bmlxdWUgMzItYml0DQo+PiBpZGVudGlmaWVyIHdp dGhpbiB0aGUgcHJvdG9jb2wgcm91dGluZyBkb21haW4gdGhhdCBpcyBjb21tb25seSBleHByZXNz ZWQNCj4+IGluIGRvdHRlZCBxdWFkIGZvcm1hdC4gV2hhdCBpcyB0aGUgcHJvYmxlbSB3aXRoIHVz aW5nIHRoaXMgWUFORyB0eXBlPw0KPnVpbnQzMiBzdXJlLCBidXQgd2hhdCBpcyB0aGUgY29uY2x1 c2lvbiByZWdhcmRpbmcgZG90dGVkLXF1YWQ/DQo+T24gb25lIHNpZGUsIEkgaGVhcjogZG90dGVk LXF1YWQgaXMgc3VpdGFibGUgYmVjYXVzZSBpdCdzIHVpbnQzMiBhbmQNCj5kb2VzIE5PVCBoYXZl IHRoZSBzZW1hbnRpY3Mgb2YgYW4gSVB2NCBhZGRyZXNzLg0KPk9uIHRoZSBvdGhlciBzaWRlLCBJ IGhlYXI6IHdlIHNob3VsZCBub3QgZXZlbiBkaXNwbGF5IHRoZSBpZGVudGlmaWVyIGFzDQo+YW4g SVB2NCBhZGRyZXNzLg0KPg0KPlRoZSByb3V0aW5nIGV4cGVydHMgc2hvdWxkIHRlbGwgdXMgaWYg dGhlIGRvdHRlZC1xdWFkIHR5cGUgaXMgYXBwcm9wcmlhdGUuDQoNCg0KV2UgaGF2ZSBiZWVuIGRp c3BsYXlpbmcgdGhlc2UgdW5pcXVlIGlkZW50aWZpZXJzIChSb3V0ZXIgSURzKSBpbiBkb3R0ZWQN CnF1YWQgZm9ybWF0IGluIA0KT0FNIHN5c3RlbXMgc2luY2UgdGhlIGVhcmx5IDkwcywgc28gd2h5 IHNob3VsZG7igJl0IHdlIGNvbnRpbnVlPyBUaGUNCmRlc2NyaXB0aW9uIHNob3VsZCANCnNwZWNp Znkgd2hldGhlciB0aGF0IGl0IGlzIHNpbXBseSBhIHVuaXF1ZSBhZGRyZXNzIGFuZCwgbm90IG5l Y2Vzc2FyaWx5LCBhDQpyb3V0YWJsZSBJUA0KYWRkcmVzcy4gDQoNClRoYW5rcywNCkFjZWUNCg0K DQoNCg0KDQo+DQo+UmVnYXJkcywgQmVub2l0DQo+Pg0KPj4gVGhhbmtzLA0KPj4gQWNlZQ0KPj4N Cj4+PiBSZWdhcmRzLCBCZW5vaXQNCj4+Pj4gTGFkYQ0KPj4+Pg0KPj4+Pj4gT24gMjUgRmViIDIw MTYsIGF0IDEzOjQxLCBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4gd3JvdGU6DQo+ Pj4+Pg0KPj4+Pj4gRGVhciBhbGwsDQo+Pj4+Pg0KPj4+Pj4gU29ycnkgZm9yIHRoZSBkZWxheSAo bWl4IG9mIHZhY2F0aW9uIGFuZCBidXNpbmVzcyB0cmF2ZWwpLg0KPj4+Pj4NCj4+Pj4+IExldCBt ZSB0cnkgdG8gc3VtbWFyaXplIHRoZSBzaXR1YXRpb24gYXMgSSBzZWUgaXQ6DQo+Pj4+PiAtIEZy b20gdGhlIHJvdXRpbmcgUkZDcywgQkdQIElkZW50aWZpZXIsIE9TUEYgcm91dGVyIElELCBURQ0K Pj4+Pj4gaWRlbnRpZmllciwgYW5kIExTUiBpZGVudGlmaWVycyBhcmUgYWxsIGFuIHVuc2lnbmVk IGludGVnZXJzLg0KPj4+Pj4gLSBXZSBuZWVkIGNvbnNpc3RlbmN5IGZvciB0aGUgcm91dGVyIElE IGFuZCBpZGVudGlmaWVyIGluIFlBTkcNCj4+Pj4+IGxlYWYvdHlwZWRlZg0KPj4+Pj4gLSBUaGUg T1NQRiBNSUIgbW9kdWxlIGhhcyBkZWZpbmVkDQo+Pj4+PiBSb3V0ZXJJRCA6Oj0gVEVYVFVBTC1D T05WRU5USU9ODQo+Pj4+PiAgICAgICAgICBTVEFUVVMgICAgICAgY3VycmVudA0KPj4+Pj4gICAg ICAgICAgREVTQ1JJUFRJT04NCj4+Pj4+ICAgICAgICAgICAgICJBIE9TUEYgUm91dGVyIElkZW50 aWZpZXIuDQo+Pj4+PiAgICAgICAgICAgICAgTm90ZSB0aGF0IHRoZSBSb3V0ZXIgSUQsIGluIE9T UEYsIGhhcyB0aGUgc2FtZSBmb3JtYXQNCj4+Pj4+ICAgICAgICAgICAgICBhcyBhbiBJUCBhZGRy ZXNzLCBidXQgaWRlbnRpZmllcyB0aGUgcm91dGVyIGluZGVwZW5kZW50DQo+Pj4+PiAgICAgICAg ICAgICAgb2YgaXRzIElQIGFkZHJlc3MuIg0KPj4+Pj4gICAgICAgICAgU1lOVEFYICAgICAgIElw QWRkcmVzcw0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAgICAgb3NwZlJvdXRlcklkIE9CSkVDVC1UWVBF DQo+Pj4+PiAgICAgICAgICBTWU5UQVggICAgICAgUm91dGVySUQNCj4+Pj4+ICAgICAgICAgIE1B WC1BQ0NFU1MgICByZWFkLXdyaXRlDQo+Pj4+PiAgICAgICAgICBTVEFUVVMgICAgICAgY3VycmVu dA0KPj4+Pj4gICAgICAgICAgREVTQ1JJUFRJT04NCj4+Pj4+ICAgICAgICAgICAgICJBIDMyLWJp dCBpbnRlZ2VyIHVuaXF1ZWx5IGlkZW50aWZ5aW5nIHRoZQ0KPj4+Pj4gICAgICAgICAgICAgcm91 dGVyIGluIHRoZSBBdXRvbm9tb3VzIFN5c3RlbS4NCj4+Pj4+ICAgICAgICAgICAgIEJ5IGNvbnZl bnRpb24sIHRvIGVuc3VyZSB1bmlxdWVuZXNzLCB0aGlzDQo+Pj4+PiAgICAgICAgICAgICBzaG91 bGQgZGVmYXVsdCB0byB0aGUgdmFsdWUgb2Ygb25lIG9mIHRoZQ0KPj4+Pj4gICAgICAgICAgICAg cm91dGVyJ3MgSVAgaW50ZXJmYWNlIGFkZHJlc3Nlcy4NCj4+Pj4+DQo+Pj4+PiBBcyBBZHJpYW4g bWVudGlvbmVkOiBpdCBpcyBOT1QgYW4gSVAgYWRkcmVzcyBidXQgdGhlIE1JQiBtb2R1bGUgdXNl cw0KPj4+Pj4gdGhlIG5vdGF0aW9uYWwgZm9ybWF0dGluZyBvZiBuIElQIGFkZHJlc3MgZm9yIGRp c3BsYXkgcHVycG9zZXMuDQo+Pj4+PiAtIEFuIElQdjQgYWRkcmVzcyBhcyBPU1BGIHJvdXRlciBJ RCBkb2Vzbid0IG1ha2Ugc2Vuc2UgaW4gYW4gSVB2Ng0KPj4+Pj4gZW52aXJvbm1lbnQNCj4+Pj4+ DQo+Pj4+PiBCYXNlZCBvbiB0aGlzLCBJIGJlbGlldmUgdGhhdDoNCj4+Pj4+IC0gV2UgbXVzdCBu b3QgYXNzb2NpYXRlIGFuIElQIGFkZHJlc3Mgc2VtYW50aWMgd2l0aCB0aGUgcm91dGVyIElEDQo+ Pj4+PiAtIEJhc2VkIG9uIEJyaWFuJ3MgZmVlZGJhY2sgKHdoaWNoIEkgYWdyZWUgd2l0aCkgIkFz IGxvbmcgYXMgdGhlIFlBTkcNCj4+Pj4+IG1vZHVsZSBkb2VzIG5vdCBzcGVjaWZ5IGEgZm9ybWF0 IHRoYXQgbWFrZXMgdGhlIHJvdXRlcklEIGRpc3BsYXkgbGlrZQ0KPj4+Pj4gYW4gSVB2NCBhZGRy ZXNzIiwgaXQgd2FzIHByb2JhYmx5IGEgbWlzdGFrZSB0byBoYXZlIGRlZmluZWQgUm91dGVySUQN Cj4+Pj4+YXMNCj4+Pj4+IElwQWRyZXNzIGluIE9TUEYgTUlCIG1vZHVsZS4NCj4+Pj4+IC0gSW50 ZXJlc3RpbmdseSwNCj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW5ldG1vZC1yb3V0aW5nLWNmZy0yMA0KPj4+Pj5jb250YWluczoNCj4+Pj4+DQo+Pj4+PiAgICAg ICAgZ3JvdXBpbmcgcm91dGVyLWlkIHsNCj4+Pj4+ICAgICAgICAgIGRlc2NyaXB0aW9uDQo+Pj4+ PiAgICAgICAgICAgICJUaGlzIGdyb3VwaW5nIHByb3ZpZGVzIHJvdXRlciBJRC4iOw0KPj4+Pj4g ICAgICAgICAgbGVhZiByb3V0ZXItaWQgew0KPj4+Pj4gICAgICAgICAgICB0eXBlIHlhbmc6ZG90 dGVkLXF1YWQ7DQo+Pj4+PiAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+Pj4+PiAgICAgICAgICAg ICAgIkEgMzItYml0IG51bWJlciBpbiB0aGUgZm9ybSBvZiBhIGRvdHRlZCBxdWFkIHRoYXQgaXMN Cj4+Pj4+dXNlZA0KPj4+Pj4gYnkNCj4+Pj4+ICAgICAgICAgICAgICAgc29tZSByb3V0aW5nIHBy b3RvY29scyBpZGVudGlmeWluZyBhIHJvdXRlci4iOw0KPj4+Pj4gICAgICAgICAgICByZWZlcmVu Y2UNCj4+Pj4+ICAgICAgICAgICAgICAiDQo+Pj4+PiBSRkMgMjMyOA0KPj4+Pj4gOiBPU1BGIFZl cnNpb24gMi4iOw0KPj4+Pj4gICAgICAgICAgfQ0KPj4+Pj4gICAgICAgIH0NCj4+Pj4+DQo+Pj4+ PiBUaGlzIHNob3VsZCBiZSBhbiB1aW50MzIgbnVtYmVyLg0KPj4+Pj4gLSBBbiB1bmlvbi1iYXNl ZCBzb2x1dGlvbiBpcyBhIGJhZCBjb21wcm9taXNlDQo+Pj4+PiAgIEZyb20gZHJhZnQtcmF6YS1t cGxzLWxkcC1tbGRwLXlhbmctMDINCj4+Pj4+ICAgICAgICAgICAgICAgIGxlYWYgbHNyLWlkIHsN Cj4+Pj4+ICAgICAgICAgICAgICAgICAgdHlwZSB1bmlvbiB7DQo+Pj4+PiAgICAgICAgICAgICAg ICAgICAgdHlwZSB5YW5nOmRvdHRlZC1xdWFkOw0KPj4+Pj4gICAgICAgICAgICAgICAgICAgIHR5 cGUgdWludDMyOw0KPj4+Pj4gICAgICAgICAgICAgICAgICB9DQo+Pj4+PiAgICAgICAgICAgICAg ICAgIGRlc2NyaXB0aW9uICJMU1IgSUQuIjsNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFNp bmNlIHRoZSBxdWVzdGlvbiB3YXMgYXNrZWQ6IGFzIEFELCBJIHdvdWxkIHN1cHBvcnQgdWludDMy DQo+Pj4+PmV2ZXJ5d2hlcmUuDQo+Pj4+Pg0KPj4+Pj4gTm93LCBwcmFjdGljYWxseSwgaG93IHRv IG1vdmUgZm9yd2FyZD8NCj4+Pj4+IC0gRWl0aGVyIGFsbCBkcmFmdHMgcmVmZXJlbmNlIGRyYWZ0 LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLTIwICh3aXRoDQo+Pj4+PiB0aGUgdWludDMyIG1vZGlm aWNhdGlvbiksDQo+Pj4+PiAtIE9yIHlvdSBjcmVhdGUgYSAiQ29tbW9uIFJvdXRpbmcgWUFORyBE YXRhIFR5cGVzIiwgc2ltaWxhcmx5IHRvIFJGQw0KPj4+Pj4gNjk5MSBpbmNsdWRpbmcgdGhlIHJv dXRlciBJRHMuIEkgc2VlIGFscmVhZHkgbWFueSB0eXBlZGVmIGluDQo+Pj4+PiBkcmFmdC1yYXph LW1wbHMtbGRwLW1sZHAteWFuZy0wMg0KPj4+Pj4gLSBPciB5b3UgZGVmaW5lIHlvdSBvd24gdHlw ZXMgaW4geW91ciBvd24gZHJhZnQNCj4+Pj4+DQo+Pj4+PiBCdXQsIGlmIHdlIGhhdmUgYWdyZWVt ZW50IG9uIHRoZSB1aW50MzIsIGxldCdzIGRvY3VtZW50IHRoaXMgbm93DQo+Pj4+PiBzb21ld2hl cmUvc29tZWhvdywgYW5kIGxldCdzIG5vdCByZXZpc2l0IHRoaXMgb24gcmVndWxhciBiYXNpcyAo eWVzLA0KPj4+Pj5JDQo+Pj4+PiBzZWUgaXQgY29taW5nLi4uKQ0KPj4+Pj4gQSBmZXcgbGluZXMg b2YgZXhwbGFuYXRpb24gaW4gdGhlIGRyYWZ0IHdvdWxkIGFscmVhZHkgaGVscCBmb3INCj4+Pj4+ IGV4YW1wbGUsIGluIGFuIG9wZXJhdGlvbmFsIHNlY3Rpb24sIGV4cGxhaW5pbmcgdG8gcGVvcGxl IHRoZSBtYXBwaW5nDQo+Pj4+Pm9mDQo+Pj4+PiB0aGUgTUlCIE9TUEYgUm91dGVySUQgdG8gdGhl IFlBTkcgb2JqZWN0DQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywgQmVub2l0DQo+Pj4+Pj4gSGkgQWRy aWFuLA0KPj4+Pj4+DQo+Pj4+Pj4gT24gMi8xNi8xNiA3OjUzIEFNLCBBZHJpYW4gRmFycmVsIHdy b3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IEhpIEJyaWFuLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBJIHNhaWQg SSB3YXNuJ3QgZ29pbmcgdG8gcGFydGljaXBhdGUgaW4gdGhpcyBkaXNjdXNzaW9uIDotKQ0KPj4+ Pj4+Pg0KPj4+Pj4+IE5pY2UgdHJ5LiA7KQ0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pj4+PiBJIHNo b3VsZCBub3QgcmVzcG9uZCB0byBxdWVzdGlvbnMgdGhhdCBJIGRvbid0IGZ1bGx5IHVuZGVyc3Rh bmQsDQo+Pj4+Pj4+Pj4gYnV0Og0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gdGhlIEJHUCBJZGVudGlm aWVyIGlzIGFuIHVuc2lnbmVkIGludGVnZXINCj4+Pj4+Pj4+PiB0aGUgT1NQRiByb3V0ZXIgSUQg aXMgYW4gdW5zaWduZWQgaW50ZWdlcg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJIGFzc3VtZSB0aGUg YWJvdmUgaXMgYmFzZWQgb24gdGhlIFlBTkcgZGVmaW5pdGlvbiBvZiBPU1BGDQo+Pj4+Pj4+PiBy b3V0ZXJJRC4gUkZDDQo+Pj4+Pj4+PiA0NzUwIHNheXMgdGhlIHJvdXRlcklEIGlzIGFuIElQdjQg YWRkcmVzcy4gSXMgdGhhdCBhbiBpc3N1ZT8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+IFRvIHF1b3RlIGZy b20gNDc1MC4uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBSb3V0ZXJJRCA6Oj0gVEVYVFVBTC1DT05WRU5U SU9ODQo+Pj4+Pj4+ICAgICAgICAgIFNUQVRVUyAgICAgICBjdXJyZW50DQo+Pj4+Pj4+ICAgICAg ICAgIERFU0NSSVBUSU9ODQo+Pj4+Pj4+ICAgICAgICAgICAgICJBIE9TUEYgUm91dGVyIElkZW50 aWZpZXIuDQo+Pj4+Pj4+ICAgICAgICAgICAgICBOb3RlIHRoYXQgdGhlIFJvdXRlciBJRCwgaW4g T1NQRiwgaGFzIHRoZSBzYW1lIGZvcm1hdA0KPj4+Pj4+PiAgICAgICAgICAgICAgYXMgYW4gSVAg YWRkcmVzcywgYnV0IGlkZW50aWZpZXMgdGhlIHJvdXRlcg0KPj4+Pj4+PmluZGVwZW5kZW50DQo+ Pj4+Pj4+ICAgICAgICAgICAgICBvZiBpdHMgSVAgYWRkcmVzcy4iDQo+Pj4+Pj4+ICAgICAgICAg IFNZTlRBWCAgICAgICBJcEFkZHJlc3MNCj4+Pj4+Pj4NCj4+Pj4+Pj4gU28gaXQgZXhwbGljaXRs eSBzYXlzIGl0IGlzIE5PVCBhbiBJUCBhZGRyZXNzIGJ1dCB0aGUgTUlCIG1vZHVsZQ0KPj4+Pj4+ PiB1c2VzIHRoZSBub3RhdGlvbmFsIGZvcm1hdHRpbmcgb2YgbiBJUCBhZGRyZXNzIGZvciBkaXNw bGF5DQo+Pj4+Pj4+cHVycG9zZXMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkgdGhpbmsgdGhpcyBpcyBk b25lIGJlY2F1c2UgdGhlIHJvdXRlciBJRCBpcyBvZnRlbiBjaG9zZW4gdG8gYmUgYW4NCj4+Pj4+ Pj4gSVAgYWRkcmVzcyBvZiB0aGUgcm91dGVyLCBhbmQgYmVjYXVzZSBpdCBpcyBlYXNpZXIgZm9y IGh1bWFucyB0bw0KPj4+Pj4+PmRlYWwNCj4+Pj4+Pj4gd2l0aCBhLmIuYy5kIHdoZXJlIGVhY2gg ZWxlbWVudCBpcyBhIDMtZGlnaXQgbnVtYmVyIGxlc3MgdGhhbiAyNTYsDQo+Pj4+Pj4+IHRoYW4g aXQgaXMgdG8gbWFuYWdlIGEgc2luZ2xlIG51bWJlciBpbiB0aGUgcmFuZ2UgMCB0byAyXjMyIC0x Lg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+IFRoZSBhYm92ZSBpcyB0aGUgdGV4dHVhbCBjb252 ZW50aW9uLCB3aGVyZWFzIHRoZSBmb2xsb3dpbmcgaXMgdGhlDQo+Pj4+Pj4gYWN0dWFsDQo+Pj4+ Pj4gT1NQRiByb3V0ZXJJRC4uLg0KPj4+Pj4+DQo+Pj4+Pj4gICAgIG9zcGZSb3V0ZXJJZCBPQkpF Q1QtVFlQRQ0KPj4+Pj4+ICAgICAgICAgIFNZTlRBWCAgICAgICBSb3V0ZXJJRA0KPj4+Pj4+ICAg ICAgICAgIE1BWC1BQ0NFU1MgICByZWFkLXdyaXRlDQo+Pj4+Pj4gICAgICAgICAgU1RBVFVTICAg ICAgIGN1cnJlbnQNCj4+Pj4+PiAgICAgICAgICBERVNDUklQVElPTg0KPj4+Pj4+ICAgICAgICAg ICAgICJBIDMyLWJpdCBpbnRlZ2VyIHVuaXF1ZWx5IGlkZW50aWZ5aW5nIHRoZQ0KPj4+Pj4+ICAg ICAgICAgICAgIHJvdXRlciBpbiB0aGUgQXV0b25vbW91cyBTeXN0ZW0uDQo+Pj4+Pj4gICAgICAg ICAgICAgQnkgY29udmVudGlvbiwgdG8gZW5zdXJlIHVuaXF1ZW5lc3MsIHRoaXMNCj4+Pj4+PiAg ICAgICAgICAgICBzaG91bGQgZGVmYXVsdCB0byB0aGUgdmFsdWUgb2Ygb25lIG9mIHRoZQ0KPj4+ Pj4+ICAgICAgICAgICAgIHJvdXRlcidzIElQIGludGVyZmFjZSBhZGRyZXNzZXMuDQo+Pj4+Pj4N Cj4+Pj4+PiBTbyB0aGUgTUlCIGFjdHVhbGx5IHNheXMgdGhlIGRlZmF1bHQgaXMgdG8gdXNlIGFu IElQdjQgYWRkcmVzcy4uLg0KPj4+Pj4+DQo+Pj4+Pj4gQWxsIHRoYXQgYmVpbmcgc2FpZCwgbXkg cG9pbnQgd2FzIGZ1cnRoZXIgYWxvbmcgd2hlcmUgSSBzYWlkOg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+ Pj4+Pj4+IEkgYW0gbm90IGNvbmNlcm5lZCB3aXRoIHdoYXQgdGhlIG9wZXJhdG9yIHdpbGwgY2hv b3NlIGFzIGhpcy9oZXINCj4+Pj4+Pj4+IHJvdXRlcklEIHZhbHVlLiBJIGFtIGNvbmNlcm5lZCB3 aXRoIHdoYXQgZm9ybWF0IG9wdGlvbnMgd2lsbCBiZQ0KPj4+Pj4+Pj4gYXNzb2NpYXRlZCB3aXRo IHRoZSByb3V0ZXJJRCBpbiB0aGUgeWFuZyBtb2R1bGUuIEFzIGxvbmcgYXMgdGhlDQo+Pj4+Pj4+ PiBmb3JtYXQNCj4+Pj4+Pj4+IG9wdGlvbnMgZG9lcyBub3QgYWxsb3cgZGlzcGxheSBpbiBkb3R0 ZWQgZGVjaW1hbCBub3RhdGlvbiwgSSBhbQ0KPj4+Pj4+Pj4gZmluZS4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4gQXMgbG9uZyBhcyB0aGUgWUFORyBtb2R1bGUgZG9lcyBub3Qgc3BlY2lmeSBhIGZvcm1hdCB0 aGF0IG1ha2VzIHRoZQ0KPj4+Pj4+IHJvdXRlcklEIGRpc3BsYXkgbGlrZSBhbiBJUHY0IGFkZHJl c3MsIEkgYW0gZmluZS4NCj4+Pj4+Pg0KPj4+Pj4+IEJyaWFuDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+IC0tDQo+Pj4+IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+Pj4gUEdQ IEtleSBJRDogRTc0RThDMEMNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gLg0KPj4+Pg0K Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4g bmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQoNCg== From nobody Wed Mar 2 08:00:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4081B1ACAD8 for ; Wed, 2 Mar 2016 08:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROxUQGSqjnY7 for ; Wed, 2 Mar 2016 08:00:54 -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 8DE7B1A8AEB for ; Wed, 2 Mar 2016 08:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11265; q=dns/txt; s=iport; t=1456934453; x=1458144053; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=hw2GBjgy8umg9tpmHCrs709UB4CC1yhTuh2S/eQSj5o=; b=XzS1usoF2eehft71c/77DM+BkOjnDoTSSHnL//Tw4bFfUXqbRi1Ht+QC fogtRQ3ieODAlD8VPCwR2pQAicg8byJrHfBDepWEOhd5Y/jzE0y7vSJef QYH1uNLPYMtB0+n8GcQj5C0k2A9XuA586TP6tae+yM1GRmMGu/fNAVH8j w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAQDeDNdW/xbLJq1egm6BHm26KgENg?= =?us-ascii?q?WcXAQmFKEoCgX4UAQEBAQEBAWQnhEEBAQEEAQEBGlEKEQsOAwMBAgEJFggHCQM?= =?us-ascii?q?CAQIBFR8JCAYBDAYCAQGIHQ66LgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKEO?= =?us-ascii?q?oQFEQE+hBoFlxKNY4FghESDAoVQjkweAQFCgjCBNDwuhy6BMgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,529,1449532800"; d="scan'208,217";a="633017708" 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; 02 Mar 2016 16:00:51 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u22G0pUk016636; Wed, 2 Mar 2016 16:00:51 GMT To: Kent Watsen , "netmod@ietf.org" References: From: Robert Wilton Message-ID: <56D70E33.1000008@cisco.com> Date: Wed, 2 Mar 2016 16:00:51 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000009010906050404050709" Archived-At: Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 16:00:56 -0000 This is a multi-part message in MIME format. --------------000009010906050404050709 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, Re-reading Juergen's email, I think that his main concern was whether there would be sufficient reviewers of this draft. It is slightly tricky because this draft is covering configuration that I believe many network device vendors require and support to make their devices function in a sensible fashion, but are not standardized anywhere because until YANG came along there has been little need to do so (since the features don't generally need to inter-operate between devices). In terms of milestones, I agree with Juergen, that it is really the cross reviews from other device vendors that is most important. I.e. to confirm that these configuration knobs are generally applicable to a broad set of devices. So I would think that the next steps would consist of: - confirmation that this configuration is generally common across vendors. - check whether there is any other common interface level configuration that is missing and should also be covered. - see if it is possible to agree on some more concrete default values for some of the settings. - see if there is any additional operational state that should also be made available. I think that it is likely that some needs to be added. - see if any further explanation or documentation of the defaults described in this draft are required. However, I don't think that this really should end up being a large YANG module, or that it should take a particularly long time to standardize, presuming that we can get the reviews and agreement of course. Does that help clarify your/Juergen's concerns? Thanks, Rob On 29/02/2016 23:07, Kent Watsen wrote: > > The chairs were just reviewing notes and realized that this thread > never closed properly. > > Juergen has some concerns regarding realistic milestones, that were > never addressed. Robert, can you please try to address Juergen’s > concerns now? > > Also, there were only a two responses before indicating willingness to > review the draft as it progresses (thanks Dan and Martin). Can others > that support this draft and willing to review this draft say so? > > Thanks, > Netmod Chairs > > > From: netmod > on behalf of Kent Watsen > > > Date: Tuesday, December 15, 2015 at 11:48 AM > To: "netmod@ietf.org " > > Subject: [netmod] call for consensus to adopt > draft-wilton-netmod-intf-ext-yang as NETMOD WG draft > > > The minutes for IETF 94 show that there was in-room support for > adopting draft-wilton-netmod-intf-ext-yang as a WG draft. The > minutes also show that this decision would be confirmed on the mailing > list, which I am doing now. > > Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item > and correspondingly add this to the WG charter as a milestone? Please > comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG > Chairs will gauge whether or not there is consensus to move forward > with the document. > > Thanks, > Kent > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------000009010906050404050709 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Kent,

Re-reading Juergen's email, I think that his main concern was whether there would be sufficient reviewers of this draft.  It is slightly tricky because this draft is covering configuration that I believe many network device vendors require and support to make their devices function in a sensible fashion, but are not standardized anywhere because until YANG came along there has been little need to do so (since the features don't generally need to inter-operate between devices).

In terms of milestones, I agree with Juergen, that it is really the cross reviews from other device vendors that is most important.  I.e. to confirm that these configuration knobs are generally applicable to a broad set of devices.  So I would think that the next steps would consist of:
 - confirmation that this configuration is generally common across vendors.
 - check whether there is any other common interface level configuration that is missing and should also be covered.
 - see if it is possible to agree on some more concrete default values for some of the settings.
 - see if there is any additional operational state that should also be made available.  I think that it is likely that some needs to be added.
 - see if any further explanation or documentation of the defaults described in this draft are required.

However, I don't think that this really should end up being a large YANG module, or that it should take a particularly long time to standardize, presuming that we can get the reviews and agreement of course.

Does that help clarify your/Juergen's concerns?

Thanks,
Rob


On 29/02/2016 23:07, Kent Watsen wrote:

The chairs were just reviewing notes and realized that this thread never closed properly.

Juergen has some concerns regarding realistic milestones, that were never addressed.  Robert, can you please try to address Juergen’s concerns now?

Also, there were only a two responses before indicating willingness to review the draft as it progresses (thanks Dan and Martin).  Can others that support this draft and willing to review this draft say so?

Thanks,
Netmod Chairs


From: netmod <netmod-bounces@ietf.org> on behalf of Kent Watsen <kwatsen@juniper.net>
Date: Tuesday, December 15, 2015 at 11:48 AM
To: "netmod@ietf.org" <netmod@ietf.org>
Subject: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft


The minutes for IETF 94 show that there was in-room support for adopting draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show that this decision would be confirmed on the mailing list, which I am doing now.  

Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and correspondingly add this to the WG charter as a milestone?  Please comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will gauge whether or not there is consensus to move forward with the document.

Thanks,
Kent


 

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

--------------000009010906050404050709-- From nobody Wed Mar 2 09:45:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AAF1B2FB8 for ; Wed, 2 Mar 2016 09:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUF_ww9dCsUT for ; Wed, 2 Mar 2016 09:45:45 -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 C40FE1B3010 for ; Wed, 2 Mar 2016 09:45:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3252; q=dns/txt; s=iport; t=1456940744; x=1458150344; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PqINyhx8XtUi4j8DsdHWyRDEPZBMQUYIUyvlXppSf6s=; b=GzcfsBzWvaBITUwzDRowrKdwt880gqwJGusy2KZjuHrjaoRCbn/ZUWl6 bRpUUZ00e6faNUXufNxa4b/Uc/ucycNvHEMFN/qGdxLTA0fhEUN/K7hqW eLw7acoXXxPjPaiLWLk/XRJq727KL/0QiybsF0bLil4Y6ctrlOkgm0Ffv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgCAJddW/4YNJK1egzpSbQa6FgENg?= =?us-ascii?q?WcXCoUkSgIcgSs4FAEBAQEBAQFkJ4RCAQEEAQEBIBE6GwIBCBoCJgICAiULFRA?= =?us-ascii?q?CBAESiCEOq32PFgEBAQEBAQEBAQEBAQEBAQEBARQEe4lRhDODAoE6BY0siWYBh?= =?us-ascii?q?VmICY52jksBHgEBQoNkaodifgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,529,1449532800"; d="scan'208";a="243302840" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Mar 2016 17:45:44 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u22Hjhm3019418 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Mar 2016 17:45:44 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Mar 2016 11:45:43 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Wed, 2 Mar 2016 11:45:43 -0600 From: "Acee Lindem (acee)" To: Ladislav Lhotka , NETMOD WG Thread-Topic: [netmod] proposed change to ietf-routing Thread-Index: AQHRcJq0RazNoMs9PkSzBYV8exAQ959GhjuA Date: Wed, 2 Mar 2016 17:45:42 +0000 Message-ID: References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> In-Reply-To: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> 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.199] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] proposed change to ietf-routing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 17:45:51 -0000 SGkgTGFkYSwgTkVUTU9EIFdHIG1lbWJlcnMsDQoNClRoZXJlIGFyZSBhY3R1YWxseSBhIG51bWJl ciBvZiBjaGFuZ2VzIHRoYXQgd2Ugd291bGQgbGlrZSB0bw0Kc2VlIGluIHRoZSBpZXRmLXJvdXRp bmcgbW9kZWw6DQoNCi0gUmVtb3ZlIHJvdXRpbmctaW5zdGFuY2VzIHNpbmNlIGlldGYtcm91dGlu ZyBzaW5jZSBpdCB3aWxsIGJlDQogIOKAnG1vdW50ZWTigJ0gYXQgZGlmZmVyZW50IHBvaW50cyBp biB0aGUgZGV2aWNlIGhpZXJhcmNoeSBkZXBlbmRlbnQNCiAgb24gdGhlIGRldmljZSByZXF1aXJl bWVudHMuDQoNCi0gQ29sbGFwc2UgaXQgaW50byBvbmUgbW9kdWxlIHN1cHBvcnRpbmcgZGlmZmVy ZW50IGFkZHJlc3MgZmFtaWxpZXMNCiAgcmF0aGVyIDMgbW9kdWxlcyAoYmFzZSwgSVB2NCwgYW5k IElQdjYpLg0KDQotIFJlbW92ZSB0aGUgTkQgKFJGQyA0ODYxKSBSb3V0ZXIgQWR2ZXJ0aXNlbWVu dCBwcm90b2NvbCBzaW5jZSBpdA0KICBkb2VzbuKAmXQgbmVlZCB0byBiZSBoZXJlLg0KDQotIFN1 cHBvcnQgYXQgbGVhc3QgdGhlIG5leHQgaG9wIGVuaGFuY2VtZW50cyBpbg0KICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWNlZS1ydGd3Zy15YW5nLXJpYi1leHRlbmQtMDANCg0K LSBJbmNsdWRlIGF0IGxlYXN0IEVDTVAgaW4gdGhlIHN0YXRpYyByb3V0ZSBjb25maWd1cmF0aW9u Lg0KDQotIFN0cnVjdHVyZSBjb25zaXN0ZW50IHdpdGggdGhlIG9wZXJhdGlvbmFsIHN0YXRlIHJl Y29tbWVuZGF0aW9uLg0KICBFdmVuIHcvbyBoYXZpbmcgdGhlIGZpbmFsIHJlY29tbWVuZGF0aW9u LCB0aGlzIG1vZGVsIHNlZW1zIHRvDQogIGJyYW5jaCBiZXR3ZWVuIGNvbmZpZyBhbmQgc3RhdGUg YXQgd2F5IHRvbyBoaWdoIGEgbGV2ZWwuDQoNClRoYW5rcywNCkFjZWUNCg0KDQpPbiAyLzI2LzE2 LCA4OjM2IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBMYWRpc2xhdiBMaG90a2EiDQo8bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KDQo+ SGksDQo+DQo+YXMgYSBwYXJ0IG9mIHN5bmNocm9uaXphdGlvbiBvZiB0aGUgcm91dGluZyBkYXRh IG1vZGVscyB0aGF0IGFyZSBiZWluZw0KPmRldmVsb3BlZCBieSB0aGUgTkVUTU9EIGFuZCBSVEcg d29ya2luZyBncm91cHMsIHRoZSBhdXRob3JzIG9mDQo+ZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGlu Zy1jZmcgcHJvcG9zZSB0byByZW1vdmUgdGhlIHJvdXRpbmctaW5zdGFuY2UNCj5sZXZlbCBpbiB0 aGUgZGF0YSBoaWVyYXJjaHksIGFuZCBsZWF2ZSBpdCB0byBzdHJ1Y3R1cmFsLW1vdW50L1lTREwg dG8NCj5wcm92aWRlIGEgdG9wIGxldmVsIHN0cnVjdHVyZS4NCj4NCj5TY2hlbWF0aWNhbGx5LCB0 aGUgY29uZmlndXJhdGlvbiBhbmQgc3RhdGUgZGF0YSBzdWJ0cmVlcyBvZiBpZXRmLXJvdXRpbmcN Cj53b3VsZCBiZSByZWR1Y2VkIHRvIHNvbWV0aGluZyBsaWtlIHRoaXM6DQo+DQo+bW9kdWxlOiBp ZXRmLXJvdXRpbmcNCj4gICArLS1ybyByb3V0aW5nLXN0YXRlDQo+ICAgfCAgKy0tcm8gcm91dGVy LWlkPyAgICAgICAgICAgeWFuZzpkb3R0ZWQtcXVhZA0KPiAgIHwgICstLXJvIGludGVyZmFjZXMN Cj4gICB8ICB8ICArLS1ybyBpbnRlcmZhY2UqICAgaWY6aW50ZXJmYWNlLXN0YXRlLXJlZg0KPiAg IHwgICstLXJvIHJvdXRpbmctcHJvdG9jb2xzDQo+ICAgfCAgfCAgKy0tcm8gcm91dGluZy1wcm90 b2NvbCogW3R5cGUgbmFtZV0NCj4gICB8ICB8ICAgICAuLi4NCj4gICB8ICArLS1ybyByaWJzDQo+ ICAgfCAgICAgKy0tcm8gcmliKiBbbmFtZV0NCj4gICB8ICAgICAgICAuLi4NCj4gICArLS1ydyBy b3V0aW5nDQo+ICAgICAgKy0tcncgcm91dGVyLWlkPyAgICAgICAgICAgeWFuZzpkb3R0ZWQtcXVh ZA0KPiAgICAgICstLXJ3IGRlc2NyaXB0aW9uPyAgICAgICAgIHN0cmluZw0KPiAgICAgICstLXJ3 IHJvdXRpbmctcHJvdG9jb2xzDQo+ICAgICAgfCAgKy0tcncgcm91dGluZy1wcm90b2NvbCogW3R5 cGUgbmFtZV0NCj4gICAgICB8ICAgICAuLi4NCj4gICAgICArLS1ydyByaWJzDQo+ICAgICAgICAg Ky0tcncgcmliKiBbbmFtZV0NCj4JICAgIC4uLg0KPg0KPkFyZSB0aGVyZSBhbnkgb2JqZWN0aW9u cyB0byB0aGlzIGNoYW5nZT8NCj4NCj5UaGFua3MsDQo+DQo+QWNlZSBhbmQgTGFkYQ0KPiANCj4t LQ0KPkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj5QR1AgS2V5IElEOiBFNzRFOEMwQw0K Pg0KPg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg== From nobody Wed Mar 2 13:51:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855F71B3274 for ; Wed, 2 Mar 2016 13:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.906 X-Spam-Level: X-Spam-Status: No, score=-13.906 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, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2L_qP_8BNkOq for ; Wed, 2 Mar 2016 13:51:19 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90CBD1B327B for ; Wed, 2 Mar 2016 13:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38716; q=dns/txt; s=iport; t=1456955478; x=1458165078; h=from:to:cc:subject:date:message-id:mime-version; bh=h96BBbY0YiJnnk4Pjltt1iP6dExYOF620fFxobVT+Ws=; b=dNJlbdPfSRa26l+Lrsae41nzekyUpR5w0gbGla4/qTxPyH+IctQVFJgM TOmyOgWcJFxSCnGvI4KTLRrIxmrGgBb9bnbQKd9xp1ehb6n5dYPtuozfb BDSQ2XIduScfX78259A9sO1OOaH4J/YXMDew71j7WbIgfdtOtvnTf8DUm Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQAXX9dW/4sNJK1egm5MUm0GuhgBD?= =?us-ascii?q?YFngjmDVgIcgSw4FAEBAQEBAQFkJ4RBAQIEIwpMEgEIEQMBAiEBBgMCBDAUCQo?= =?us-ascii?q?EAQ0FiCABrGWPEgEBAQEBAQEBAQEBAQEBAQEBAQEBARWGEoFsCIJGhA8OOBaCS?= =?us-ascii?q?iuBDwWNLIVKhBwBjWKBYIREgyWFLY5LAR4BAUKDZGqHJT0BfQEBAQ?= X-IronPort-AV: E=Sophos; i="5.22,530,1449532800"; d="scan'208,217"; a="78991634" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Mar 2016 21:51:17 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u22LpHbG023702 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Mar 2016 21:51:17 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Mar 2016 15:51:16 -0600 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.1104.009; Wed, 2 Mar 2016 15:51:16 -0600 From: "Clyde Wildes (cwildes)" To: "Hinshaw, Patrick" , "draft-ietf-netmod-syslog-model@tools.ietf.org" Thread-Topic: draft-ietf-netmod-syslog-model Thread-Index: AQHRdM2lbboAwpBL20mCh5tdqk3vqw== Date: Wed, 2 Mar 2016 21:51:16 +0000 Message-ID: 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: [171.69.106.40] Content-Type: multipart/alternative; boundary="_000_B8C2238351754246ABD21EB893F78F93ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-syslog-model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 21:51:25 -0000 --_000_B8C2238351754246ABD21EB893F78F93ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGF0cmljaywNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldy4NCg0KUmVnYXJkaW5nIHRoZSBzZXZl cml0eSBsZWFmOiBtdWx0aXBsZSBzZXZlcml0aWVzIGFyZSBhbHJlYWR5IGNvdmVyZWQgd2hlbiBz ZXZlcml0eSBpcyBzcGVjaWZpZWQgYmVjYXVzZSB0aGUgZGVmYXVsdCBzZXZlcml0eSBjb21wYXJp c29uIGlzIGFsbCBtZXNzYWdlcyBvZiB0aGUgc3BlY2lmaWVkIHNldmVyaXR5IGFuZCBncmVhdGVy LiBZb3UgY2FuIHVzZSBvZiB0aGUgb3B0aW9uYWwgcGF0dGVybi1tYXRjaCBzdHJpbmcgdG8gc2Vs ZWN0IGEgbWVzc2FnZSB3aXRoIGEgc3BlY2lmaWMgcHJpb3JpdHkgKGluY2x1ZGVzIHNldmVyaXR5 IGFuZCBmYWNpbGl0eSkuIElmIHlvdSBuZWVkIGZ1cnRoZXIgZmlsdGVyaW5nIGNhcGFiaWxpdHks IHlvdSBjb3VsZCBhZGQgdGhpcyB0aHJvdWdoIGF1Z21lbnRhdGlvbiBvZiB0aGUgbG9nLXNlbGVj dG9yIGNvbnRhaW5lci4NCg0KUmVnYXJkaW5nIHRoZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgcmVt b3RlIGRlc3RpbmF0aW9uOiBpbiBhbiBlYXJsaWVyIHJldmlldyBpdCB3YXMgcmVxdWlyZWQgdGhh dCB0aGUgbW9kZWwgY29uZm9ybSB0byB0aGUgcmVjb21tZW5kYXRpb24gaW4gU2VjdGlvbiAzIG9m IGRyYWZ0LXNjaG9lbnctbmV0bW9kLXlhbmctcGF0dGVybi0wMC4gWW91ciBwcm9wb3NhbCBkb2Vz IG5vdCBmb2xsb3cgdGhhdCBwYXR0ZXJuLg0KDQpSZWdhcmRpbmcgdGhlIGxlYWYgbm9kZXMgdG8g YmUgYWRkZWQgcmVxdWVzdDoNCg0KLSBUaGUgcHJlc2VuY2Ugb3IgYWJzZW5jZSBvZiBhIGxlYWYg aW4gdGhlIGxvZy1hY3Rpb25zIGNvbnRhaW5lciBpbmRpY2F0ZXMgd2hldGhlciB0aGUgaW50ZW5k ZWQgYWN0aW9uIGlzIGVuYWJsZWQvZGlzYWJsZWQuIFRoaXMgcGF0dGVybiBpcyB1c2VkIGZvciBh bGwgbG9nIGFjdGlvbnMuDQotIFRoZSBwcm9wb3NlZCBpZXRmLXN5c2xvZyBtb2RlbCBkb2VzIG5v dCBpbmNsdWRlIG9wZXJhdGlvbmFsIHN0YXRlIG9yIG5vdGlmaWNhdGlvbnMuIE9wZXJhdGlvbmFs IHN0YXRlIGluIHRoZSBtb2RlbCdzIGNvbmZpZyBzZWN0aW9uIHdvdWxkIGhhdmUgdG8gYmUgZmxh Z2dlZCBhcyBzdWNoLiBQbGVhc2UgcmVmZXIgdG8gdGhlICJTdGF0ZSBEYXRhIiBzdGF0ZW1lbnQg ZnJvbSBSRkMgNjAyMCBzZWN0aW9uIDQuMi4zLg0KLSBBIGN1c3RvbS1wcmVmaXggbGVhZiB0byBw cmVwZW5kIGEgY3VzdG9tIHNpZ25hdHVyZSBmb3IgZWFjaCBsb2cgbWVzc2FnZSBjb3VsZCBiZSBh ZGRlZCB0aG91Z2ggYXVnbWVudGF0aW9uLiBJZiB0aGVyZSBpcyBhIGNvbnNlbnN1cyB0aGF0IHRo aXMgc2hvdWxkIGJlIGFkZGVkIGZvciBhbGwgaW1wbGVtZW50YXRpb25zIEkgd2lsbCBnbGFkbHkg YWRkIGl0Lg0KDQpUaGFua3MsDQoNCkNseWRlDQoNCkZyb206ICJIaW5zaGF3LCBQYXRyaWNrIiA8 cGhpbnNoYXdAY2llbmEuY29tPG1haWx0bzpwaGluc2hhd0BjaWVuYS5jb20+Pg0KRGF0ZTogVHVl c2RheSwgTWFyY2ggMSwgMjAxNiBhdCAxMToyMiBQTQ0KVG86ICJkcmFmdC1pZXRmLW5ldG1vZC1z eXNsb2ctbW9kZWxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbmV0bW9kLXN5c2xv Zy1tb2RlbEB0b29scy5pZXRmLm9yZz4iIDxkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWxA dG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbEB0b29s cy5pZXRmLm9yZz4+DQpTdWJqZWN0OiBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwNClJl c2VudC1Gcm9tOiA8cHJ2cz02ODY5OWM5NjUyPXBoaW5zaGF3QGNpZW5hLmNvbTxtYWlsdG86cHJ2 cz02ODY5OWM5NjUyPXBoaW5zaGF3QGNpZW5hLmNvbT4+DQpSZXNlbnQtVG86IDxkcmFmdC1pZXRm LW5ldG1vZC1zeXNsb2ctbW9kZWxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbmV0bW9kLXN5 c2xvZy1tb2RlbEBpZXRmLm9yZz4+DQpSZXNlbnQtRGF0ZTogVHVlc2RheSwgTWFyY2ggMSwgMjAx NiBhdCAxMTo1NCBQTQ0KDQpIZWxsbywNCg0KVGhlcmUgYXJlIGEgZmV3IGxlYXZlcyBpbiB0aGlz IGN1cnJlbnQgZHJhZnQgdGhhdCBJIGJlbGlldmUgc2hvdWxkIGJlIGFsdGVyZWQsIGFzIHdlbGwg YXMgYSBmZXcgdGhhdCBzaG91bGQgYmUgYWRkZWQuDQoNCkZpcnN0LCB0aGUgc2V2ZXJpdHkgbGVh ZiBub2RlIGluIHRoZSBzeXNsb2ctc2V2ZXJpdHkgZ3JvdXBpbmcgY291bGQgYmUgY2hhbmdlZCB0 byBhIGxlYWYtbGlzdCBub2RlLiBUaGlzIHdpbGwgZW5hYmxlIGEgdXNlciB0byBjaG9vc2UgYW55 IGNvbWJpbmF0aW9uIG9mIHNldmVyaXRpZXMsIGluc3RlYWQgb2YgYmVpbmcgc3RyaWN0bHkgbGlt aXRlZCB0byBhIHJhbmdlLiBUaGlzIGZ1bmN0aW9uYWxpdHkgd291bGQgYmUgdXNlZCB3aGVuIHRo ZSBzZXZlcml0eS1vcGVyYXRvciBsZWFmIGlzIHNldCB0byDigJxlcXVhbOKAnS4NCg0KU2Vjb25k LCBpbiB0aGUgcmVtb3RlIGNvbnRhaW5lciwgdGhlcmUgaXMgYSBsaXN0IGNhbGxlZCDigJxkZXN0 aW5hdGlvbuKAnSB3aXRoIHRoZSBrZXkg4oCcbmFtZeKAnSBvZiB0eXBlIHN0cmluZy4gQW5vdGhl ciB3YXkgdG8gZG8gdGhpcyB3b3VsZCBiZSB0byBjaGFuZ2UgdGhpcyB0eXBlIHRvIGluZXQ6aG9z dCwgYXMgd2VsbCBhcyBhZGRpbmcgYSBuZXcgbGVhZiBub2RlIHRoYXQgaG9sZHMgdGhlIHJlc29s dmVkIElQIGFkZHJlc3Mgb2YgdHlwZSBpbmV0OmlwLWFkZHJlc3MgKHJlYWQtb25seSkuIFdlIHdv dWxkIGluIHR1cm4gZGVsZXRlIHRoZSBsZWFmIG5vZGUg4oCcYWRkcmVzc+KAnSB1bmRlciBib3Ro IHRoZSB0Y3AgYW5kIHVkcCBjaG9pY2Ugc3RhdGVtZW50LiBUaGlzIHdvdWxkIGVsaW1pbmF0ZSB0 aGUgbmVlZCB0byBjcmVhdGUgYW4gYXJiaXRyYXJ5IG5hbWUgZm9yIGVhY2ggc2VydmVyLCBoYXZp bmcgdGhlIGhvc3RuYW1lIGFzIHRoZSBsaXN0IGtleSBzZWVtcyB0byBiZSB0aGUgbW9yZSBpbnR1 aXRpdmUgYXBwcm9hY2guDQoNCkxhc3RseSwgdGhlcmUgYXJlIGEgZmV3IGxlYWYgbm9kZXMgdGhh dCBJICBiZWxpZXZlIHNob3VsZCBhZGRlZCB0byB0aGUgcmVtb3RlIGNvbnRhaW5lcjoNCjEpICAg ICAgQW4gYWRtaW5pc3RyYXRpdmUgc3RhdGUgbGVhZiBub2RlIHRvIGVuYWJsZS9kaXNhYmxlIHRo ZSByZW1vdGUgc2VydmVyLg0KMikgICAgICBBbiBvcGVyYXRpb25hbCBzdGF0ZSBsZWFmIG5vZGUg dG8gc2VlIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBvZiB0aGUgcmVtb3RlIHNlcnZlciAoVGhpcyBp cyByZWFkLW9ubHkpLg0KYS4gICAgICAgQm90aCBvZiB0aGVzZSBub2RlcyB3b3VsZCBhbGxvdyB0 aGUgdXNlciB0byBiZSBhd2FyZSBvZiB0aGUgc3RhdHVzIG9mIHRoZWlyIHN5c2xvZyBzZXJ2ZXJz LCBzb21ldGhpbmcgdGhpcyBtb2RlbCBpcyBjdXJyZW50bHkgbGFja2luZy4NCmIuICAgICAgQm90 aCB3b3VsZCBiZSBlbnVtZXJhdGVkIHR5cGVzIHdpdGggdmFsdWVzIGVuYWJsZSBhbmQgZGlzYWJs ZS4NCjMpICAgICAgQSBjdXN0b20tcHJlZml4IGxlYWYgbm9kZSBvZiB0eXBlIHN0cmluZyBhbGxv d2luZyBhIGN1c3RvbSBzaWduYXR1cmUgdG8gYmUgcHJlcGVuZGVkIHRvIGVhY2ggc3lzbG9nIG1l c3NhZ2UuDQoNCkhlcmXigJlzIGEgdHJlZSBvZiB0aGUgcmVtb3RlIGNvbnRhaW5lciBtYWRlIGlu IHB5YW5nIHNob3dpbmcgdGhlIGNoYW5nZXMgSeKAmXZlIHByb3Bvc2VkLiBOb3RlIHRoYXQgdGhl c2UgY2hhbmdlcyB3aWxsIGFmZmVjdCBvdGhlciBjb250YWluZXJzIHVzaW5nIHRoZSBzZXZlcml0 eSBub2RlIGZyb20gdGhlIHN5c2xvZy1zZXZlcml0eSBncm91cGluZzoNCg0KbW9kdWxlOiBkcmFm dC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMDYNCuKApi4NCiAgICAgICAgICstLXJ3IHJlbW90 ZQ0KICAgICAgICAgfCAgKy0tcncgZGVzdGluYXRpb24qIFtuYW1lXQ0KICAgICAgICAgfCAgICAg Ky0tcncgbmFtZSAgICAgICAgICAgICAgICAgICAgaW5ldDpob3N0DQogICAgICAgICB8ICAgICAr LS1ybyByZXNvbHZlZC1pcD8gICAgICAgICAgICBpbmV0OmlwLWFkZHJlc3MNCiAgICAgICAgIHwg ICAgICstLXJ3ICh0cmFuc3BvcnQpDQogICAgICAgICB8ICAgICB8ICArLS06KHRjcCkNCiAgICAg ICAgIHwgICAgIHwgIHwgICstLXJ3IHRjcA0KICAgICAgICAgfCAgICAgfCAgfCAgICAgKy0tcncg cG9ydD8gICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICB8ICAgICB8ICArLS06KHVkcCkN CiAgICAgICAgIHwgICAgIHwgICAgICstLXJ3IHVkcA0KICAgICAgICAgfCAgICAgfCAgICAgICAg Ky0tcncgcG9ydD8gICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICB8ICAgICArLS1ydyBs b2ctc2VsZWN0b3INCiAgICAgICAgIHwgICAgIHwgICstLXJ3IChzZWxlY3Rvci1mYWNpbGl0eSkN CiAgICAgICAgIHwgICAgIHwgIHwgICstLToobm8tbG9nLWZhY2lsaXR5KQ0KICAgICAgICAgfCAg ICAgfCAgfCAgfCAgKy0tcncgbm8tZmFjaWxpdGllcz8gICBlbXB0eQ0KICAgICAgICAgfCAgICAg fCAgfCAgKy0tOihsb2ctZmFjaWxpdHkpDQogICAgICAgICB8ICAgICB8ICB8ICAgICArLS1ydyBs b2ctZmFjaWxpdHkqIFtmYWNpbGl0eV0NCiAgICAgICAgIHwgICAgIHwgIHwgICAgICAgICstLXJ3 IGZhY2lsaXR5ICAgICAgICAgICAgIHVuaW9uDQogICAgICAgICB8ICAgICB8ICB8ICAgICAgICAr LS1ydyBzZXZlcml0eSogICAgICAgICAgICB1bmlvbiAvLyBub3cgYSBsZWFmLWxpc3Qgbm9kZQ0K ICAgICAgICAgfCAgICAgfCAgfCAgICAgICAgKy0tcncgc2V2ZXJpdHktb3BlcmF0b3I/ICAgZW51 bWVyYXRpb24ge3NlbGVjdG9yLXNldmVyaXR5LW9wZXJhdG9yLWNvbmZpZ30/DQogICAgICAgICB8 ICAgICB8ICArLS1ydyBwYXR0ZXJuLW1hdGNoPyAgIHN0cmluZyB7c2VsZWN0b3ItbWF0Y2gtcHJv Y2Vzc2luZy1jb25maWd9Pw0KICAgICAgICAgfCAgICAgKy0tcncgZGVzdGluYXRpb24tZmFjaWxp dHk/ICAgaWRlbnRpdHlyZWYNCiAgICAgICAgIHwgICAgICstLXJ3IHNvdXJjZS1pbnRlcmZhY2U/ ICAgICAgIGlmOmludGVyZmFjZS1yZWYNCiAgICAgICAgIHwgICAgICstLXJ3IGN1c3RvbS1wcmVm aXg/ICAgICAgICAgIHN0cmluZw0KICAgICAgICAgfCAgICAgKy0tcncgYWRtaW5pc3RyYXRpdmUt c3RhdGU/ICAgZW51bWVyYXRpb24NCiAgICAgICAgIHwgICAgICstLXJvIG9wZXJhdGlvbmFsLXN0 YXRlPyAgICAgIGVudW1lcmF0aW9uDQogICAgICAgICB8ICAgICArLS1ydyBzeXNsb2ctc2lnbiEg e3NpZ25lZC1tZXNzYWdlcy1jb25maWd9Pw0KICAgICAgICAgfCAgICAgICAgKy0tcncgY2VydC1p bml0aWFsLXJlcGVhdCAgICB1aW50MTYNCiAgICAgICAgIHwgICAgICAgICstLXJ3IGNlcnQtcmVz ZW5kLWRlbGF5ICAgICAgdWludDE2DQogICAgICAgICB8ICAgICAgICArLS1ydyBjZXJ0LXJlc2Vu ZC1jb3VudCAgICAgIHVpbnQxNg0KICAgICAgICAgfCAgICAgICAgKy0tcncgc2lnLW1heC1kZWxh eSAgICAgICAgICB1aW50MTYNCiAgICAgICAgIHwgICAgICAgICstLXJ3IHNpZy1udW1iZXItcmVz ZW5kcyAgICAgdWludDE2DQogICAgICAgICB8ICAgICAgICArLS1ydyBzaWctcmVzZW5kLWRlbGF5 ICAgICAgIHVpbnQxNg0KICAgICAgICAgfCAgICAgICAgKy0tcncgc2lnLXJlc2VuZC1jb3VudCAg ICAgICB1aW50MTYNCuKApi4NCg0KUGxlYXNlIGxldCBtZSBrbm93IHdoYXQgeW91ciB0aG91Z2h0 cyBhcmUgb24gdGhlc2UgcHJvcG9zZWQgY2hhbmdlcy4NCg0KUmVzcGVjdGZ1bGx5LA0KDQpQYXRy aWNrIEhpbnNoYXcNCnBoaW5zaGF3QGNpZW5hLmNvbTxtYWlsdG86cGhpbnNoYXdAY2llbmEuY29t Pg0KDQo= --_000_B8C2238351754246ABD21EB893F78F93ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+UGF0 cmljayw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyBmb3IgeW91ciByZXZp ZXcuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRpbmcgdGhlIHNldmVyaXR5 IGxlYWY6IG11bHRpcGxlIHNldmVyaXRpZXMgYXJlIGFscmVhZHkgY292ZXJlZCB3aGVuIHNldmVy aXR5IGlzIHNwZWNpZmllZCBiZWNhdXNlIHRoZSBkZWZhdWx0IHNldmVyaXR5IGNvbXBhcmlzb24g aXMgYWxsIG1lc3NhZ2VzIG9mIHRoZSBzcGVjaWZpZWQgc2V2ZXJpdHkgYW5kIGdyZWF0ZXIuIFlv dSBjYW4gdXNlIG9mIHRoZSBvcHRpb25hbCBwYXR0ZXJuLW1hdGNoIHN0cmluZyB0byBzZWxlY3Qg YQ0KIG1lc3NhZ2Ugd2l0aCBhIHNwZWNpZmljIHByaW9yaXR5IChpbmNsdWRlcyBzZXZlcml0eSBh bmQgZmFjaWxpdHkpLiBJZiB5b3UgbmVlZCBmdXJ0aGVyIGZpbHRlcmluZyBjYXBhYmlsaXR5LCB5 b3UgY291bGQgYWRkIHRoaXMgdGhyb3VnaCBhdWdtZW50YXRpb24gb2YgdGhlIGxvZy1zZWxlY3Rv ciBjb250YWluZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRpbmcgdGhl IHNwZWNpZmljYXRpb24gZm9yIHRoZSByZW1vdGUgZGVzdGluYXRpb246IGluIGFuIGVhcmxpZXIg cmV2aWV3IGl0IHdhcyByZXF1aXJlZCB0aGF0IHRoZSBtb2RlbCBjb25mb3JtIHRvDQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7IGZvbnQtc2l6ZTogbWVkaXVtOyI+ dGhlIHJlY29tbWVuZGF0aW9uIGluIFNlY3Rpb24gMyBvZiBkcmFmdC1zY2hvZW53LW5ldG1vZC15 YW5nLXBhdHRlcm4tMDAuIFlvdXIgcHJvcG9zYWwgZG9lcyBub3QgZm9sbG93IHRoYXQgcGF0dGVy bi48L3NwYW4+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRpbmcgdGhlIGxl YWYgbm9kZXMgdG8gYmUgYWRkZWQgcmVxdWVzdDo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pi0gVGhlIHByZXNlbmNlIG9yIGFic2VuY2Ugb2YgYSBsZWFmIGluIHRoZSBsb2ctYWN0aW9u cyBjb250YWluZXIgaW5kaWNhdGVzIHdoZXRoZXIgdGhlIGludGVuZGVkIGFjdGlvbiBpcyBlbmFi bGVkL2Rpc2FibGVkLiBUaGlzIHBhdHRlcm4gaXMgdXNlZCBmb3IgYWxsIGxvZyBhY3Rpb25zLjwv ZGl2Pg0KPGRpdj4tIFRoZSBwcm9wb3NlZCBpZXRmLXN5c2xvZyBtb2RlbCBkb2VzIG5vdCBpbmNs dWRlIG9wZXJhdGlvbmFsIHN0YXRlIG9yIG5vdGlmaWNhdGlvbnMuIE9wZXJhdGlvbmFsIHN0YXRl IGluIHRoZSBtb2RlbCdzIGNvbmZpZyBzZWN0aW9uIHdvdWxkIGhhdmUgdG8gYmUgZmxhZ2dlZCBh cyBzdWNoLiBQbGVhc2UgcmVmZXIgdG8gdGhlICZxdW90O1N0YXRlIERhdGEmcXVvdDsgc3RhdGVt ZW50IGZyb20gUkZDIDYwMjAgc2VjdGlvbiA0LjIuMy48L2Rpdj4NCjxkaXY+LSBBIGN1c3RvbS1w cmVmaXggbGVhZiB0byBwcmVwZW5kIGEgY3VzdG9tIHNpZ25hdHVyZSBmb3IgZWFjaCBsb2cgbWVz c2FnZSBjb3VsZCBiZSBhZGRlZCB0aG91Z2ggYXVnbWVudGF0aW9uLiBJZiB0aGVyZSBpcyBhIGNv bnNlbnN1cyB0aGF0IHRoaXMgc2hvdWxkIGJlIGFkZGVkIGZvciBhbGwgaW1wbGVtZW50YXRpb25z IEkgd2lsbCBnbGFkbHkgYWRkIGl0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhh bmtzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2x5ZGU8L2Rpdj4NCjxkaXY+DQo8 ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVm dDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDog bWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURE SU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklH SFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+JnF1b3Q7SGluc2hhdywgUGF0cmljayZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnBoaW5zaGF3QGNpZW5hLmNvbSI+cGhpbnNoYXdAY2llbmEuY29tPC9h PiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlR1 ZXNkYXksIE1hcmNoIDEsIDIwMTYgYXQgMTE6MjIgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1u ZXRtb2Qtc3lzbG9nLW1vZGVsQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLW5ldG1vZC1zeXNs b2ctbW9kZWxAdG9vbHMuaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHJh ZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLW5l dG1vZC1zeXNsb2ctbW9kZWxAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+ZHJhZnQtaWV0Zi1uZXRtb2Qtc3lz bG9nLW1vZGVsIDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5SZXNlbnQtRnJv bTogPC9zcGFuPiZsdDs8YSBocmVmPSJtYWlsdG86cHJ2cz02ODY5OWM5NjUyPXBoaW5zaGF3QGNp ZW5hLmNvbSI+cHJ2cz02ODY5OWM5NjUyPXBoaW5zaGF3QGNpZW5hLmNvbTwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlJlc2VudC1UbzogPC9zcGFuPiZsdDs8YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsQGlldGYub3JnIj5kcmFm dC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWxAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5SZXNlbnQtRGF0ZTogPC9zcGFuPlR1ZXNkYXksIE1hcmNo IDEsIDIwMTYgYXQgMTE6NTQgUE08YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JF Qy1odG1sNDAiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29y ZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9u cyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjYz NTUyODc4NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTE3MzUwNDM2IC0xMzUwODYxMTYgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Ljc1aW47DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MS4yNWluOw0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDoxLjc1aW47DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mi4yNWluOw0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIuNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6My4yNWluOw0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMuNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDo0LjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCW1hcmdpbi1sZWZ0OjQuNzVpbjsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkhlbGxvLCA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRo ZXJlIGFyZSBhIGZldyBsZWF2ZXMgaW4gdGhpcyBjdXJyZW50IGRyYWZ0IHRoYXQgSSBiZWxpZXZl IHNob3VsZCBiZSBhbHRlcmVkLCBhcyB3ZWxsIGFzIGEgZmV3IHRoYXQgc2hvdWxkIGJlIGFkZGVk Lg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5GaXJzdCwg dGhlIHNldmVyaXR5IGxlYWYgbm9kZSBpbiB0aGUgc3lzbG9nLXNldmVyaXR5IGdyb3VwaW5nIGNv dWxkIGJlIGNoYW5nZWQgdG8gYSBsZWFmLWxpc3Qgbm9kZS4gVGhpcyB3aWxsIGVuYWJsZSBhIHVz ZXIgdG8gY2hvb3NlIGFueSBjb21iaW5hdGlvbiBvZiBzZXZlcml0aWVzLCBpbnN0ZWFkIG9mIGJl aW5nIHN0cmljdGx5IGxpbWl0ZWQgdG8gYSByYW5nZS4NCiBUaGlzIGZ1bmN0aW9uYWxpdHkgd291 bGQgYmUgdXNlZCB3aGVuIHRoZSBzZXZlcml0eS1vcGVyYXRvciBsZWFmIGlzIHNldCB0byDigJxl cXVhbOKAnS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNl Y29uZCwgaW4gdGhlIHJlbW90ZSBjb250YWluZXIsIHRoZXJlIGlzIGEgbGlzdCBjYWxsZWQg4oCc ZGVzdGluYXRpb27igJ0gd2l0aCB0aGUga2V5IOKAnG5hbWXigJ0gb2YgdHlwZSBzdHJpbmcuIEFu b3RoZXIgd2F5IHRvIGRvIHRoaXMgd291bGQgYmUgdG8gY2hhbmdlIHRoaXMgdHlwZSB0byBpbmV0 Omhvc3QsIGFzIHdlbGwgYXMgYWRkaW5nIGEgbmV3IGxlYWYgbm9kZSB0aGF0DQogaG9sZHMgdGhl IHJlc29sdmVkIElQIGFkZHJlc3Mgb2YgdHlwZSBpbmV0OmlwLWFkZHJlc3MgKHJlYWQtb25seSku IFdlIHdvdWxkIGluIHR1cm4gZGVsZXRlIHRoZSBsZWFmIG5vZGUg4oCcYWRkcmVzc+KAnSB1bmRl ciBib3RoIHRoZSB0Y3AgYW5kIHVkcCBjaG9pY2Ugc3RhdGVtZW50LiBUaGlzIHdvdWxkIGVsaW1p bmF0ZSB0aGUgbmVlZCB0byBjcmVhdGUgYW4gYXJiaXRyYXJ5IG5hbWUgZm9yIGVhY2ggc2VydmVy LCBoYXZpbmcgdGhlIGhvc3RuYW1lIGFzDQogdGhlIGxpc3Qga2V5IHNlZW1zIHRvIGJlIHRoZSBt b3JlIGludHVpdGl2ZSBhcHByb2FjaC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkxhc3RseSwgdGhlcmUgYXJlIGEgZmV3IGxlYWYgbm9kZXMgdGhhdCBJJm5i c3A7IGJlbGlldmUgc2hvdWxkIGFkZGVkIHRvIHRoZSByZW1vdGUgY29udGFpbmVyOg0KPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi43NWluO3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxz cGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5BbiBhZG1pbmlzdHJhdGl2ZSBzdGF0ZSBsZWFmIG5vZGUgdG8gZW5hYmxlL2Rp c2FibGUgdGhlIHJlbW90ZSBzZXJ2ZXIuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi43NWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ DQo8IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6 IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IS0tW2VuZGlmXS0tPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BbiBvcGVyYXRpb25hbCBz dGF0ZSBsZWFmIG5vZGUgdG8gc2VlIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBvZiB0aGUgcmVtb3Rl IHNlcnZlciAoVGhpcyBpcyByZWFkLW9ubHkpLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDoxLjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMiBs Zm8xIj4NCjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQt c2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbic7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJvdGgg b2YgdGhlc2Ugbm9kZXMgd291bGQgYWxsb3cgdGhlIHVzZXIgdG8gYmUgYXdhcmUgb2YgdGhlIHN0 YXR1cyBvZiB0aGVpciBzeXNsb2cgc2VydmVycywgc29tZXRoaW5nIHRoaXMgbW9kZWwgaXMgY3Vy cmVudGx5IGxhY2tpbmcuDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MS4yNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IS0t W2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj5iLjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2Vu ZGlmXS0tPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Cb3RoIHdvdWxkIGJlIGVudW1lcmF0 ZWQgdHlwZXMgd2l0aCB2YWx1ZXMgZW5hYmxlIGFuZCBkaXNhYmxlLjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPg0KPCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Myk8c3BhbiBzdHlsZT0i Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ QSBjdXN0b20tcHJlZml4IGxlYWYgbm9kZSBvZiB0eXBlIHN0cmluZyBhbGxvd2luZyBhIGN1c3Rv bSBzaWduYXR1cmUgdG8gYmUgcHJlcGVuZGVkIHRvIGVhY2ggc3lzbG9nIG1lc3NhZ2UuPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5IZXJl4oCZcyBhIHRyZWUgb2YgdGhlIHJlbW90ZSBjb250YWluZXIgbWFkZSBpbiBw eWFuZyBzaG93aW5nIHRoZSBjaGFuZ2VzIEnigJl2ZSBwcm9wb3NlZC4gTm90ZSB0aGF0IHRoZXNl IGNoYW5nZXMgd2lsbCBhZmZlY3Qgb3RoZXIgY29udGFpbmVycyB1c2luZyB0aGUgc2V2ZXJpdHkg bm9kZSBmcm9tIHRoZSBzeXNsb2ctc2V2ZXJpdHkgZ3JvdXBpbmc6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+bW9kdWxlOiBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMDY8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj7igKYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHJlbW90ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGRl c3RpbmF0aW9uKiBbbmFtZV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBu YW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGluZXQ6aG9zdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJvIHJlc29s dmVkLWlwPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBpbmV0OmlwLWFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7LS1ydyAodHJhbnNwb3J0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyAmIzQzOy0tOih0Y3ApPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwm bmJzcDsgJiM0MzstLXJ3IHRjcDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBwb3J0PyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBpbmV0OnBvcnQtbnVtYmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7ICYjNDM7LS06KHVkcCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHVkcDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t cncgcG9ydD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5ldDpwb3J0LW51bWJlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGxvZy1zZWxlY3RvcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgKHNlbGVjdG9yLWZhY2lsaXR5 KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS06KG5v LWxvZy1mYWNpbGl0eSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNw OyB8Jm5ic3A7ICYjNDM7LS1ydyBuby1mYWNpbGl0aWVzPyZuYnNwOyZuYnNwOyBlbXB0eTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS06KGxvZy1mYWNp bGl0eSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0tcncgbG9nLWZhY2lsaXR5KiBbZmFjaWxpdHldPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstLXJ3IGZhY2lsaXR5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVuaW9uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHNldmVyaXR5KiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1bmlvbiAvLyBu b3cgYSBsZWFmLWxpc3Qgbm9kZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBzZXZl cml0eS1vcGVyYXRvcj8mbmJzcDsmbmJzcDsgZW51bWVyYXRpb24ge3NlbGVjdG9yLXNldmVyaXR5 LW9wZXJhdG9yLWNvbmZpZ30/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYj NDM7LS1ydyBwYXR0ZXJuLW1hdGNoPyZuYnNwOyZuYnNwOyBzdHJpbmcge3NlbGVjdG9yLW1hdGNo LXByb2Nlc3NpbmctY29uZmlnfT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1y dyBkZXN0aW5hdGlvbi1mYWNpbGl0eT8mbmJzcDsmbmJzcDsgaWRlbnRpdHlyZWY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBzb3VyY2UtaW50ZXJmYWNlPyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZjppbnRlcmZhY2UtcmVmPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgY3VzdG9tLXByZWZpeD8mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyaW5nPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYWRtaW5pc3RyYXRpdmUtc3RhdGU/Jm5ic3A7Jm5ic3A7 IGVudW1lcmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcm8gb3BlcmF0 aW9uYWwtc3RhdGU/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudW1lcmF0aW9uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgc3lzbG9nLXNpZ24hIHtzaWduZWQt bWVzc2FnZXMtY29uZmlnfT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICYjNDM7LS1ydyBjZXJ0LWluaXRpYWwtcmVwZWF0Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVp bnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst LXJ3IGNlcnQtcmVzZW5kLWRlbGF5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQx NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3 IGNlcnQtcmVzZW5kLWNvdW50Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQxNjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHNp Zy1tYXgtZGVsYXkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgdWludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmIzQzOy0tcncgc2lnLW51bWJlci1yZXNlbmRzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHVpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0 MzstLXJ3IHNpZy1yZXNlbmQtZGVsYXkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdWludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm IzQzOy0tcncgc2lnLXJlc2VuZC1jb3VudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB1aW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPuKApi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5QbGVhc2UgbGV0IG1lIGtub3cgd2hhdCB5b3VyIHRob3VnaHRzIGFyZSBvbiB0aGVz ZSBwcm9wb3NlZCBjaGFuZ2VzLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVzcGVjdGZ1bGx5LCA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogNy41cHQ7IGZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsiPlBhdHJpY2sgSGluc2hhdzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogNy41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiPjxicj4N Cjx1PjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj48YSBocmVmPSJtYWlsdG86cGhpbnNoYXdAY2ll bmEuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+cGhpbnNoYXdAY2llbmEuY29tPC9zcGFu PjwvYT48L3NwYW4+PC91Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFu Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8C2238351754246ABD21EB893F78F93ciscocom_-- From nobody Wed Mar 2 19:44:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5981B3AE9 for ; Wed, 2 Mar 2016 19:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 dcGgfVUC2QjA for ; Wed, 2 Mar 2016 19:44:48 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 0ADDB1B3AEA for ; Wed, 2 Mar 2016 19:44:48 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id of3so8448977lbc.1 for ; Wed, 02 Mar 2016 19:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=L6qoOiUW3wIIgjObv0J4Ba5ORTajNNkFYls4dxqmAmw=; b=ARN1/CBbNW9mrhZniOhqhk2/8P+5OcSz9t7/7E0+TQkKPc69pCoAZ4/IrIiUy0a1Qr esdpk6M860d1Su/Tt6I3FNLt4iTh59Be1+SSXGdkRtr3vhp5TmkMa/n/2oKozCEnb7Wl 9UHFGuNFCV+U8oXcV6SwaUq0dxOD5KuJsMn/lOr8+q4JV5rimu7jQFlEIsZxFxR0Gntz J9zF2yXYqU0skpxrnCrmwX8/iQ2fxwFbiPy3eQmPtpB2YCEDzlGCX+EZNLglJ/dlYy4i igDL9A08KDvW7fDHKw58mM8ta4fRz5h0AH6fYjXcN4HdDr8Bzu0gGCLvA5dFSC8bzR1p RJeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=L6qoOiUW3wIIgjObv0J4Ba5ORTajNNkFYls4dxqmAmw=; b=UpueO3LsQ28/x4uWE/4uHxvskbCngl2+Yr9BAHnWBgbNX01rP4e0XNC+JE5TPpnmEL retFIhpeUNXHuKehOzRBudWGMxt6nlMiB/swLGfZgSNwGS8wyauM81COytLNAMJpPZN8 VXyHNSvH+NkAWMgMH78Q6Ud93FHkcYKb6PYe7Q17i3+pD+MgnCpuqFF+tqgR9xACvoH1 uf+fvxNyxBQb/xJl99/g7Fv/NLrrviKZj9zfLxH5jt0NoA7/DRcdqBTUuHrbBIJmfnKq ZXR2yF/suWX8QrVY67qhbp3buWM747WnHDwRP808iaQHgrsanXRB89gEeWkhtFHZqjOw QZWA== X-Gm-Message-State: AD7BkJJIVGmJ2aMSfNDfJLOkkQHqcaHljz/gk7lsnv3qV6HmaPY5UnUY55i4xt9jQMkKstf3jNih0hDOSwefVw== MIME-Version: 1.0 X-Received: by 10.25.149.68 with SMTP id x65mr130032lfd.138.1456976686326; Wed, 02 Mar 2016 19:44:46 -0800 (PST) Received: by 10.112.110.68 with HTTP; Wed, 2 Mar 2016 19:44:46 -0800 (PST) Date: Wed, 2 Mar 2016 19:44:46 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11403882d5c06b052d1cd1e0 Archived-At: Subject: [netmod] typo in yang-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 03:44:49 -0000 --001a11403882d5c06b052d1cd1e0 Content-Type: text/plain; charset=UTF-8 Hi, IMO the YANG 1.1 draft should use a github issue tracker so I don't have to send typo stuff to the list. The example on pg 48 has a wrong end tag 10 Andy --001a11403882d5c06b052d1cd1e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

IMO the YANG 1.1 draft should use a= github issue tracker so
I don't have to send typo stuff to t= he list.

The example on pg 48 has a wrong end tag<= /div>

         <reset>
           <delay>10</delay>
         </down>

Andy

--001a11403882d5c06b052d1cd1e0-- From nobody Wed Mar 2 21:44:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4CD1A906E for ; Wed, 2 Mar 2016 21:44:26 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnHnGS-ReLG5 for ; Wed, 2 Mar 2016 21:44:23 -0800 (PST) Received: from BLU004-OMC3S15.hotmail.com (blu004-omc3s15.hotmail.com [65.55.116.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 6CDDE1A906A for ; Wed, 2 Mar 2016 21:44:23 -0800 (PST) Received: from BLU436-SMTP180 ([65.55.116.72]) by BLU004-OMC3S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 2 Mar 2016 21:44:22 -0800 X-TMN: [q+unMk1xTXkveKKdFvIzGa9nipPtRkzZ] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: User-Agent: Microsoft-MacOutlook/14.6.0.151221 Date: Wed, 2 Mar 2016 21:44:15 -0800 From: Ashesh Mishra To: Thread-Topic: NETMOD IETF 95 Slot Requests MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B_3539799861_7217203" X-OriginalArrivalTime: 03 Mar 2016 05:44:21.0198 (UTC) FILETIME=[BC255EE0:01D1750F] Archived-At: Subject: [netmod] NETMOD IETF 95 Slot Requests X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 05:44:26 -0000 --B_3539799861_7217203 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, It=B9s that time again. Please reply to this email (with the information below) to request a presentation slot in the NETMOD WG meetings at IETF 95 =AD Buenos Aires. Topic: Draft: Duration: Presenter: Thanks! Ashesh=20 --B_3539799861_7217203 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,

<= div>It’s that time again. 

Please reply = to this email (with the information below) to request a presentation slot in= the NETMOD WG meetings at IETF 95 – Buenos Aires.

Topic:
Draft:
Duration:
=
Presenter:

Thanks!
Ashesh&nbs= p;


--B_3539799861_7217203-- From nobody Wed Mar 2 23:37:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA121A002A for ; Wed, 2 Mar 2016 23:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdzl3oRiiZ_e for ; Wed, 2 Mar 2016 23:37: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 568FB1A0020 for ; Wed, 2 Mar 2016 23:37:26 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 53782193C; Thu, 3 Mar 2016 08:37:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id E-9_N8iicJQA; Thu, 3 Mar 2016 08:37:07 +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, 3 Mar 2016 08:37:23 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F1D020037; Thu, 3 Mar 2016 08:37:23 +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 DtE1wZDyXwcc; Thu, 3 Mar 2016 08:37:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12D9A20036; Thu, 3 Mar 2016 08:37:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E11F53A03B0A; Thu, 3 Mar 2016 08:37:21 +0100 (CET) Date: Thu, 3 Mar 2016 08:37:21 +0100 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20160303073721.GA32873@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Ladislav Lhotka , NETMOD WG References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> 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.4.2.3i Archived-At: Cc: NETMOD WG Subject: Re: [netmod] proposed change to ietf-routing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 03 Mar 2016 07:37:29 -0000 Who is 'we'? /js On Wed, Mar 02, 2016 at 05:45:42PM +0000, Acee Lindem (acee) wrote: > Hi Lada, NETMOD WG members, > > There are actually a number of changes that we would like to > see in the ietf-routing model: > > - Remove routing-instances since ietf-routing since it will be > “mounted” at different points in the device hierarchy dependent > on the device requirements. > > - Collapse it into one module supporting different address families > rather 3 modules (base, IPv4, and IPv6). > > - Remove the ND (RFC 4861) Router Advertisement protocol since it > doesn’t need to be here. > > - Support at least the next hop enhancements in > https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-00 > > - Include at least ECMP in the static route configuration. > > - Structure consistent with the operational state recommendation. > Even w/o having the final recommendation, this model seems to > branch between config and state at way too high a level. > > Thanks, > Acee > > > On 2/26/16, 8:36 AM, "netmod on behalf of Ladislav Lhotka" > wrote: > > >Hi, > > > >as a part of synchronization of the routing data models that are being > >developed by the NETMOD and RTG working groups, the authors of > >draft-ietf-netmod-routing-cfg propose to remove the routing-instance > >level in the data hierarchy, and leave it to structural-mount/YSDL to > >provide a top level structure. > > > >Schematically, the configuration and state data subtrees of ietf-routing > >would be reduced to something like this: > > > >module: ietf-routing > > +--ro routing-state > > | +--ro router-id? yang:dotted-quad > > | +--ro interfaces > > | | +--ro interface* if:interface-state-ref > > | +--ro routing-protocols > > | | +--ro routing-protocol* [type name] > > | | ... > > | +--ro ribs > > | +--ro rib* [name] > > | ... > > +--rw routing > > +--rw router-id? yang:dotted-quad > > +--rw description? string > > +--rw routing-protocols > > | +--rw routing-protocol* [type name] > > | ... > > +--rw ribs > > +--rw rib* [name] > > ... > > > >Are there any objections to this change? > > > >Thanks, > > > >Acee and Lada > > > >-- > >Ladislav Lhotka, CZ.NIC Labs > >PGP Key ID: E74E8C0C > > > > > > > > > >_______________________________________________ > >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 -- 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 3 03:17:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979431A8FD7 for ; Thu, 3 Mar 2016 03:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.974 X-Spam-Level: * X-Spam-Status: No, score=1.974 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 cQ0CNaJGC6YJ for ; Thu, 3 Mar 2016 03:16:52 -0800 (PST) Received: from teledg001ba020.telecomitalia.it (teledg001ba020.telecomitalia.it [156.54.233.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861ED1A8F42 for ; Thu, 3 Mar 2016 03:16:49 -0800 (PST) Content-Type: multipart/mixed; boundary="_b8e4164e-f3d9-496c-9bcb-99d0157ceb0e_" Received: from TELCAH001BA020.telecomitalia.local (10.188.101.214) by teledg001ba020.telecomitalia.it (10.188.101.210) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 3 Mar 2016 12:16:46 +0100 Received: from TELMBB001BA020.telecomitalia.local ([169.254.2.43]) by TELCAH001BA020.telecomitalia.local ([10.188.101.214]) with mapi id 14.03.0266.001; Thu, 3 Mar 2016 12:16:45 +0100 From: De Noia Giuseppe To: "netmod@ietf.org" Thread-Topic: Question about NFV modeling Thread-Index: AdF1Pab5nb0OPKHBS5mMYBQthoQ8Hg== Date: Thu, 3 Mar 2016 11:16:45 +0000 Message-ID: <167E7B4797E08C4DBC40AED09620195944C83AFE@TELMBB001BA020.telecomitalia.local> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.188.101.196] x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Archived-At: Subject: [netmod] Question about NFV modeling X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 11:16:55 -0000 --_b8e4164e-f3d9-496c-9bcb-99d0157ceb0e_ Content-Type: multipart/alternative; boundary="_000_167E7B4797E08C4DBC40AED09620195944C83AFETELMBB001BA020t_" --_000_167E7B4797E08C4DBC40AED09620195944C83AFETELMBB001BA020t_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, is it in the objectives of this group to address NFV modeling? I mean modeling Network Services and Virtual Network Functions on boarding,= deploying and in general life cycle phases? Thanks, Giuseppe _________________________________________ TIM Giuseppe De Noia Core Network & Infrastructures Network Function Virtualization Telecom Italia S.p.A. +39 11 2288887 +39 331 6111197 Tim Official: Facebook - Twitter<= https://twitter.com/tim_official> www.tim.it Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ?= necessario. --_000_167E7B4797E08C4DBC40AED09620195944C83AFETELMBB001BA020t_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

is it in the objectives of this group to address NFV= modeling?

I mean modeling Network Services and Virtual Network= Functions on boarding, deploying and in general  life cycle phases?

 

Thanks,

Giuseppe

 

_________________________________________=
TIM

Giuseppe De Noia
Core Network & Infrastructures
Network Function Virtualization

Telecom Italia S.p.A.

+39 11 2288887
+39 331 6111197
Tim Official: Facebook - Twitter
www.tim.it

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non è necessario.

--_000_167E7B4797E08C4DBC40AED09620195944C83AFETELMBB001BA020t_-- --_b8e4164e-f3d9-496c-9bcb-99d0157ceb0e_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_b8e4164e-f3d9-496c-9bcb-99d0157ceb0e_-- From nobody Thu Mar 3 03:46:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF161A90B7 for ; Thu, 3 Mar 2016 03:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFijkAzq9LiS for ; Thu, 3 Mar 2016 03:46: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 4FA041A8F48 for ; Thu, 3 Mar 2016 03:46: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 211B118F9; Thu, 3 Mar 2016 12:46:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GHQNoRaLhxPK; Thu, 3 Mar 2016 12:46: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; Thu, 3 Mar 2016 12:46:50 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD1BC20037; Thu, 3 Mar 2016 12:46:50 +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 K9gbfAe5__r1; Thu, 3 Mar 2016 12:46: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 9911E20036; Thu, 3 Mar 2016 12:46:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B7DDA3A03D45; Thu, 3 Mar 2016 12:46:48 +0100 (CET) Date: Thu, 3 Mar 2016 12:46:48 +0100 From: Juergen Schoenwaelder To: De Noia Giuseppe Message-ID: <20160303114648.GA33297@elstar.local> Mail-Followup-To: De Noia Giuseppe , "netmod@ietf.org" References: <167E7B4797E08C4DBC40AED09620195944C83AFE@TELMBB001BA020.telecomitalia.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <167E7B4797E08C4DBC40AED09620195944C83AFE@TELMBB001BA020.telecomitalia.local> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Question about NFV modeling X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 03 Mar 2016 11:46:56 -0000 The WG charter says: The NETMOD WG may also develop any additional data models written in YANG that the WG considers core building blocks and that do not fall under the charters of other active IETF working groups. The NETMOD WG may simply add such milestones as it sees fit, with the advice and consent of the responsible AD. In other words, data models done here must be considered 'core building blocks' and they must not fall into the charters of other active IETF working groups. For any data model, it is essential that a critical number of people familiar with the technology are involved. Perhaps you should take this to the NFVRG as this seems to be the closest venue for this kind of work in the IETF/IRTF space right now. /js On Thu, Mar 03, 2016 at 11:16:45AM +0000, De Noia Giuseppe wrote: > Hi, > is it in the objectives of this group to address NFV modeling? > I mean modeling Network Services and Virtual Network Functions on boarding, deploying and in general life cycle phases? > > Thanks, > Giuseppe > > _________________________________________ > TIM > Giuseppe De Noia > Core Network & Infrastructures > Network Function Virtualization > > Telecom Italia S.p.A. > > +39 11 2288887 > +39 331 6111197 > Tim Official: Facebook - Twitter > www.tim.it > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > > [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 3 05:01:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D027C1ACC91 for ; Thu, 3 Mar 2016 05:01:49 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYzR3RpHOA00 for ; Thu, 3 Mar 2016 05:01:45 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC891ACCDC for ; Thu, 3 Mar 2016 05:01:43 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C62401CC008D; Thu, 3 Mar 2016 14:01:43 +0100 (CET) From: Ladislav Lhotka To: "Acee Lindem \(acee\)" , NETMOD WG In-Reply-To: References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 03 Mar 2016 14:01:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] proposed change to ietf-routing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 13:01:50 -0000 "Acee Lindem (acee)" writes: > Hi Lada, NETMOD WG members, > > There are actually a number of changes that we would like to > see in the ietf-routing model: > > - Remove routing-instances since ietf-routing since it will be > =E2=80=9Cmounted=E2=80=9D at different points in the device hierarchy d= ependent > on the device requirements. Agreed. > > - Collapse it into one module supporting different address families > rather 3 modules (base, IPv4, and IPv6). This is possible, but we would have to introduce a mechanism for implementations supporting only one of them. It seems to me that it is easier to select modules for base + any combination of address families, and each family module inserts appropriate stuff to right places - and there is quite a bunch of them. What you are proposing probably means the (single) module would have if-features or whens in all those places. > > - Remove the ND (RFC 4861) Router Advertisement protocol since it > doesn=E2=80=99t need to be here. Well, RFC 4861 says: "A router MUST allow for the following conceptual variables to be configured by system management." So I don't think they can be considered optional. We could perhaps move them to a submodule so that they don't clutter the main module. > > - Support at least the next hop enhancements in > https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-00 They can be added via augments, and many potential users of the routing module (hosts and simple routers) don't support them. > > - Include at least ECMP in the static route configuration. Same as in the previous case: ietf-routing provides a choice node for next-hops in both RIBs and static routes, and ECMP is explicitly mentioned as a candidate for augmentation. Why is it such a big a problem? > > - Structure consistent with the operational state recommendation. > Even w/o having the final recommendation, this model seems to > branch between config and state at way too high a level. Could you outline the concrete changes that you propose here? The most significant part of state data in this module is the list of RIBs, and I don't see any way how it can be bundled with configuration somewhere deeper in the hierarchy. Lada > > Thanks, > Acee > > > On 2/26/16, 8:36 AM, "netmod on behalf of Ladislav Lhotka" > wrote: > >>Hi, >> >>as a part of synchronization of the routing data models that are being >>developed by the NETMOD and RTG working groups, the authors of >>draft-ietf-netmod-routing-cfg propose to remove the routing-instance >>level in the data hierarchy, and leave it to structural-mount/YSDL to >>provide a top level structure. >> >>Schematically, the configuration and state data subtrees of ietf-routing >>would be reduced to something like this: >> >>module: ietf-routing >> +--ro routing-state >> | +--ro router-id? yang:dotted-quad >> | +--ro interfaces >> | | +--ro interface* if:interface-state-ref >> | +--ro routing-protocols >> | | +--ro routing-protocol* [type name] >> | | ... >> | +--ro ribs >> | +--ro rib* [name] >> | ... >> +--rw routing >> +--rw router-id? yang:dotted-quad >> +--rw description? string >> +--rw routing-protocols >> | +--rw routing-protocol* [type name] >> | ... >> +--rw ribs >> +--rw rib* [name] >> ... >> >>Are there any objections to this change? >> >>Thanks, >> >>Acee and Lada >>=20 >>-- >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C >> >> >> >> >>_______________________________________________ >>netmod mailing list >>netmod@ietf.org >>https://www.ietf.org/mailman/listinfo/netmod > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 3 05:07:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2781ACCEA for ; Thu, 3 Mar 2016 05:07:44 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUpIncbBhsdt for ; Thu, 3 Mar 2016 05:07:43 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 82E361ACCE8 for ; Thu, 3 Mar 2016 05:07:42 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 0C8031CC008D; Thu, 3 Mar 2016 14:07:43 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 03 Mar 2016 14:07:42 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] YANG 1.1 conformance announcement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 13:07:44 -0000 Andy Bierman writes: > Hi, > > Buried in the many NETCONF-specific sections is a requirement to > announce the YANG library info. However this info is incomplete > and sec. 5.6.5 needs to be changed because it assumes there is only > 1 revision of the ietf-yang-library module possible. The client cannot > read the read the library to find out which revision of the library template > to use. > This is because yang-library is really meta-data and requires special treatment even if we pretend it is just another part of the data tree. > > > > 5.6.5. Announcing Conformance Information in NETCONF > > This document defines the following mechanism for announcing > conformance information. Other mechanisms may be defined by future > specifications. > > A NETCONF server announces the modules it implements by implementing > the YANG module "ietf-yang-library" defined in > [I-D.ietf-netconf-yang-library], and listing all implemented modules > in the "/modules-state/module" list. > > > OLD: > > The server also advertises the following capability in the > message (line-breaks and whitespaces are used for formatting reasons > only): > > urn:ietf:params:netconf:capability:yang-library:1.0? > module-set-id= > > The parameter "module-set-id" has the same value as the leaf > "/modules-state/module-set-id" from "ietf-yang-library". This > parameter MUST be present. > > NEW: > > The server also advertises the following capability in the > message (line-breaks and whitespaces are used for formatting reasons > only): > > urn:ietf:params:netconf:capability:yang-library:1.0? > revision=&module-set-id= > > The parameter "revision" has the same value as the revision > date of the "ietf-yang-library" implemented by the server. This > parameter MUST be present. > I agree. But what about RESTCONF? How can a client learn which revision of yang-library data the server uses? Lada > > The parameter "module-set-id" has the same value as the leaf > "/modules-state/module-set-id" from "ietf-yang-library". This parameter > MUST be present. > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 3 05:29:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C790F1ACD54; Thu, 3 Mar 2016 05:29: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLKIeTPecsWg; Thu, 3 Mar 2016 05:29:55 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC7B1ACD42; Thu, 3 Mar 2016 05:29:55 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id BB61C1CC008D; Thu, 3 Mar 2016 14:29:56 +0100 (CET) From: Ladislav Lhotka To: Lou Berger , netmod WG , "netmod-chairs\@ietf.org" In-Reply-To: <56D4ACA6.40208@labn.net> References: <56D4ACA6.40208@labn.net> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 03 Mar 2016 14:29:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Moving the WG discussion on mount forward X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 13:29:57 -0000 Lou Berger writes: > All, > > At last week's interim, Martin committed to update his document based > on the meeting and then work with the other mount document authors > (i.e., Lada and Alex) on a future version. Martin has now > published this version: > https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-02 > > Lada also said that he was okay with using Martin's document > as a starting point for the working group document on this > topic. (Keep in mind a -00 WG document is a starting point, not > and end point.) OK, but let me say right away that I would very much prefer the alternative solution sketched in appendix D.2. It is IMO unacceptable to use a YANG extension for defining mount points, because it requires both servers and clients to support such an extension, otherwise no interoperability is possible. It is important to stick to what sec. 6.3.1 in 6020bis says because there is no mechanism for signalling what YANG extensions an implementation supports. Having more extensions like this would undermine the value of YANG as a standard data modelling language. Moreover, it seems unnecessary to define mount-points in the first place. We have no augment-points so why do we need mount-points? I'd argue that any implementation supporting augments would require only minor modifications to support mount points specified through schema node identifiers. Lada > > We'd now like to ask for additional feedback from other WG > contributors on their opinions on what they would like see added > to base document in order for it to be accepted as a WG document. > So please review the document and send comments to the list -- > again on what areas need to be covered for the document to be > accepted as a -00 WG draft. We're hoping for comments within the > next week or so. > > Thank you, > Netmod chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 3 06:21:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F191ACE9D; Thu, 3 Mar 2016 06:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K68KkcyogWlq; Thu, 3 Mar 2016 06:21:29 -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 048BA1ACE8C; Thu, 3 Mar 2016 06:21: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 2994F18F8; Thu, 3 Mar 2016 15:21:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id SSVAqrHkePhM; Thu, 3 Mar 2016 15:21:09 +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, 3 Mar 2016 15:21:26 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CCA320038; Thu, 3 Mar 2016 15:21:26 +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 7mm6fm64kmBw; Thu, 3 Mar 2016 15:21:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2A1520036; Thu, 3 Mar 2016 15:21:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9554C3A03EF2; Thu, 3 Mar 2016 15:21:24 +0100 (CET) Date: Thu, 3 Mar 2016 15:21:24 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160303142124.GA33703@elstar.local> Mail-Followup-To: Ladislav Lhotka , Lou Berger , netmod WG , "netmod-chairs@ietf.org" References: <56D4ACA6.40208@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod-chairs@ietf.org" , netmod WG Subject: Re: [netmod] Moving the WG discussion on mount forward X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 03 Mar 2016 14:21:32 -0000 On Thu, Mar 03, 2016 at 02:29:55PM +0100, Ladislav Lhotka wrote: > Lou Berger writes: > > > All, > > > > At last week's interim, Martin committed to update his document based > > on the meeting and then work with the other mount document authors > > (i.e., Lada and Alex) on a future version. Martin has now > > published this version: > > https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-02 > > > > Lada also said that he was okay with using Martin's document > > as a starting point for the working group document on this > > topic. (Keep in mind a -00 WG document is a starting point, not > > and end point.) > > OK, but let me say right away that I would very much prefer the > alternative solution sketched in appendix D.2. It is IMO unacceptable to > use a YANG extension for defining mount points, because it requires both > servers and clients to support such an extension, otherwise no > interoperability is possible. It is important to stick to what > sec. 6.3.1 in 6020bis says because there is no mechanism for signalling > what YANG extensions an implementation supports. Having more > extensions like this would undermine the value of YANG as a standard > data modelling language. > > Moreover, it seems unnecessary to define mount-points in the first > place. We have no augment-points so why do we need mount-points? I'd > argue that any implementation supporting augments would require only > minor modifications to support mount points specified through schema > node identifiers. I have no clear opinion whether defining mount points explicitely via YANG extensions is goodness or not. Concerning YANG 1.1 Section 6.3.1, can you please detail what exactly your concern is? The relevant text is this: The processing of extensions depends on whether support for those extensions is claimed for a given YANG parser or the tool set in which it is embedded. An unsupported extension, appearing in a YANG module as an unknown-statement (see Section 14) MAY be ignored in its entirety. Any supported extension MUST be processed in accordance with the specification governing that extension. Why do you believe a YANG implementation not supporting the mount point extension can not simply ignore it? /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 3 07:18:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C414E1AD373; Thu, 3 Mar 2016 07:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] autolearn=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 aItrl-M7-gPZ; Thu, 3 Mar 2016 07:18:45 -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 69EAA1AD371; Thu, 3 Mar 2016 07:18:45 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:fc0e:fa8c:3537:c2f0] (unknown [IPv6:2001:718:1a02:1:fc0e:fa8c:3537:c2f0]) by mail.nic.cz (Postfix) with ESMTPSA id DB352181931; Thu, 3 Mar 2016 16:18:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457018323; bh=n4H1WVNEUgOymexzMKv5KA3fJvxXq2E27zp5votwNso=; h=From:Date:To; b=dQnSzIPzzPMAl6wfw2emRFUkCk8Ax3KjidKiLHAc+EYt40V+BlkzqsJjS06kvvF1j MgrP4vd8NdAY3qsBFeYVKJBDwyhOf0ZQ/ErKxsZzDfVFg03xVfiS/x8tGDWyLwA8Vu jxbV80pDod4oW2zXTS5LerLzo1MvTTfVeABtw1lA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160303142124.GA33703@elstar.local> Date: Thu, 3 Mar 2016 16:18:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56D4ACA6.40208@labn.net> <20160303142124.GA33703@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod-chairs@ietf.org" , netmod WG Subject: Re: [netmod] Moving the WG discussion on mount forward X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 15:18:47 -0000 > On 03 Mar 2016, at 15:21, Juergen Schoenwaelder = wrote: >=20 > On Thu, Mar 03, 2016 at 02:29:55PM +0100, Ladislav Lhotka wrote: >> Lou Berger writes: >>=20 >>> All, >>>=20 >>> At last week's interim, Martin committed to update his document = based >>> on the meeting and then work with the other mount document authors >>> (i.e., Lada and Alex) on a future version. Martin has now >>> published this version: >>> = https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-02 >>>=20 >>> Lada also said that he was okay with using Martin's document >>> as a starting point for the working group document on this >>> topic. (Keep in mind a -00 WG document is a starting point, not >>> and end point.) >>=20 >> OK, but let me say right away that I would very much prefer the >> alternative solution sketched in appendix D.2. It is IMO unacceptable = to >> use a YANG extension for defining mount points, because it requires = both >> servers and clients to support such an extension, otherwise no >> interoperability is possible. It is important to stick to what >> sec. 6.3.1 in 6020bis says because there is no mechanism for = signalling >> what YANG extensions an implementation supports. Having more >> extensions like this would undermine the value of YANG as a standard >> data modelling language. >>=20 >> Moreover, it seems unnecessary to define mount-points in the first >> place. We have no augment-points so why do we need mount-points? I'd >> argue that any implementation supporting augments would require only >> minor modifications to support mount points specified through schema >> node identifiers. >=20 > I have no clear opinion whether defining mount points explicitely via > YANG extensions is goodness or not. Concerning YANG 1.1 Section 6.3.1, > can you please detail what exactly your concern is? The relevant text > is this: >=20 > The processing of extensions depends on whether support for those > extensions is claimed for a given YANG parser or the tool set in > which it is embedded. An unsupported extension, appearing in a YANG > module as an unknown-statement (see Section 14) MAY be ignored in = its > entirety. Any supported extension MUST be processed in accordance > with the specification governing that extension. >=20 > Why do you believe a YANG implementation not supporting the mount > point extension can not simply ignore it? If a client doesn't support that extension, it will receive what looks = like mysterious data in replies to get or get-config (or their RESTCONF = equivalents) and is likely to choke. The server isn't able to tell = whether the client knows about the "extended" model or not. You may say it is the same with YSDL, but in fact YSDL doesn't pretend = it can be used with clients that are unaware of it. =46rom the YANG = point of view, however, modules that are intended to be used with YSDL = can be developed and published without waiting for a YANG extension to = be standardized first, because they are just good old YANG modules. Lada=20 >=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: E74E8C0C From nobody Thu Mar 3 07:39:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC45F1A039D; Thu, 3 Mar 2016 07:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHkhIngcVnQ6; Thu, 3 Mar 2016 07:39:02 -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 166F71A0379; Thu, 3 Mar 2016 07:39:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D903B1BD0; Thu, 3 Mar 2016 16:39:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TjGEZtA2cyii; Thu, 3 Mar 2016 16:38: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; Thu, 3 Mar 2016 16:38:59 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE47620037; Thu, 3 Mar 2016 16:38:59 +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 cxLm069mAD_9; Thu, 3 Mar 2016 16:38:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4213A20036; Thu, 3 Mar 2016 16:38:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1ADE03A04002; Thu, 3 Mar 2016 16:38:58 +0100 (CET) Date: Thu, 3 Mar 2016 16:38:58 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160303153857.GA33953@elstar.local> Mail-Followup-To: Ladislav Lhotka , Lou Berger , netmod WG , "netmod-chairs@ietf.org" References: <56D4ACA6.40208@labn.net> <20160303142124.GA33703@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod-chairs@ietf.org" , netmod WG Subject: Re: [netmod] Moving the WG discussion on mount forward X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 03 Mar 2016 15:39:05 -0000 On Thu, Mar 03, 2016 at 04:18:44PM +0100, Ladislav Lhotka wrote: > > > On 03 Mar 2016, at 15:21, Juergen Schoenwaelder wrote: > > > > On Thu, Mar 03, 2016 at 02:29:55PM +0100, Ladislav Lhotka wrote: > >> Lou Berger writes: > >> > >>> All, > >>> > >>> At last week's interim, Martin committed to update his document based > >>> on the meeting and then work with the other mount document authors > >>> (i.e., Lada and Alex) on a future version. Martin has now > >>> published this version: > >>> https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-02 > >>> > >>> Lada also said that he was okay with using Martin's document > >>> as a starting point for the working group document on this > >>> topic. (Keep in mind a -00 WG document is a starting point, not > >>> and end point.) > >> > >> OK, but let me say right away that I would very much prefer the > >> alternative solution sketched in appendix D.2. It is IMO unacceptable to > >> use a YANG extension for defining mount points, because it requires both > >> servers and clients to support such an extension, otherwise no > >> interoperability is possible. It is important to stick to what > >> sec. 6.3.1 in 6020bis says because there is no mechanism for signalling > >> what YANG extensions an implementation supports. Having more > >> extensions like this would undermine the value of YANG as a standard > >> data modelling language. > >> > >> Moreover, it seems unnecessary to define mount-points in the first > >> place. We have no augment-points so why do we need mount-points? I'd > >> argue that any implementation supporting augments would require only > >> minor modifications to support mount points specified through schema > >> node identifiers. > > > > I have no clear opinion whether defining mount points explicitely via > > YANG extensions is goodness or not. Concerning YANG 1.1 Section 6.3.1, > > can you please detail what exactly your concern is? The relevant text > > is this: > > > > The processing of extensions depends on whether support for those > > extensions is claimed for a given YANG parser or the tool set in > > which it is embedded. An unsupported extension, appearing in a YANG > > module as an unknown-statement (see Section 14) MAY be ignored in its > > entirety. Any supported extension MUST be processed in accordance > > with the specification governing that extension. > > > > Why do you believe a YANG implementation not supporting the mount > > point extension can not simply ignore it? > > If a client doesn't support that extension, it will receive what looks like mysterious data in replies to get or get-config (or their RESTCONF equivalents) and is likely to choke. The server isn't able to tell whether the client knows about the "extended" model or not. > Has it not always been the case that unexpected data is ignored? > You may say it is the same with YSDL, but in fact YSDL doesn't pretend it can be used with clients that are unaware of it. From the YANG point of view, however, modules that are intended to be used with YSDL can be developed and published without waiting for a YANG extension to be standardized first, because they are just good old YANG modules. > I do not really see the difference. A client that does not understand the YDSL module will see the same unexpected data. If you are saying that YSDL can't be incrementally deployed, well then I believe there is a bigger problem. /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 3 08:24:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1561A6FC9 for ; Thu, 3 Mar 2016 08:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3n6ktUMsaBf for ; Thu, 3 Mar 2016 08:24:09 -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 EBFB81A6FB6 for ; Thu, 3 Mar 2016 08:24:08 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:fc0e:fa8c:3537:c2f0] (unknown [IPv6:2001:718:1a02:1:fc0e:fa8c:3537:c2f0]) by mail.nic.cz (Postfix) with ESMTPSA id 4A91B1802B6; Thu, 3 Mar 2016 17:24:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457022247; bh=7A1UZWwue92fh0eRFk8VOweCTyTlHL8iQV2/EDXEiH0=; h=From:Date:To; b=vmWrJls0S77bpx50ig6tPzEFap9kxs2Mu1blB2o64KUtahZptT6B/CM0nLdIKJvJz nfzgtbwf7t3LSpCeB4euztI9dbfQd669Bnn844P6cleTZ71/kf3xRMqtxXBuL7Hf3C GKR6kQrYIrj++o0v66vstITK1ZohLe6TTwcgITzU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160303153857.GA33953@elstar.local> Date: Thu, 3 Mar 2016 17:24:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56D4ACA6.40208@labn.net> <20160303142124.GA33703@elstar.local> <20160303153857.GA33953@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod WG Subject: Re: [netmod] Moving the WG discussion on mount forward X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 16:24:12 -0000 > On 03 Mar 2016, at 16:38, Juergen Schoenwaelder = wrote: >=20 > On Thu, Mar 03, 2016 at 04:18:44PM +0100, Ladislav Lhotka wrote: >>=20 >>> On 03 Mar 2016, at 15:21, Juergen Schoenwaelder = wrote: >>>=20 >>> On Thu, Mar 03, 2016 at 02:29:55PM +0100, Ladislav Lhotka wrote: >>>> Lou Berger writes: >>>>=20 >>>>> All, >>>>>=20 >>>>> At last week's interim, Martin committed to update his document = based >>>>> on the meeting and then work with the other mount document authors >>>>> (i.e., Lada and Alex) on a future version. Martin has now >>>>> published this version: >>>>> = https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-02 >>>>>=20 >>>>> Lada also said that he was okay with using Martin's document >>>>> as a starting point for the working group document on this >>>>> topic. (Keep in mind a -00 WG document is a starting point, not >>>>> and end point.) >>>>=20 >>>> OK, but let me say right away that I would very much prefer the >>>> alternative solution sketched in appendix D.2. It is IMO = unacceptable to >>>> use a YANG extension for defining mount points, because it requires = both >>>> servers and clients to support such an extension, otherwise no >>>> interoperability is possible. It is important to stick to what >>>> sec. 6.3.1 in 6020bis says because there is no mechanism for = signalling >>>> what YANG extensions an implementation supports. Having more >>>> extensions like this would undermine the value of YANG as a = standard >>>> data modelling language. >>>>=20 >>>> Moreover, it seems unnecessary to define mount-points in the first >>>> place. We have no augment-points so why do we need mount-points? = I'd >>>> argue that any implementation supporting augments would require = only >>>> minor modifications to support mount points specified through = schema >>>> node identifiers. >>>=20 >>> I have no clear opinion whether defining mount points explicitely = via >>> YANG extensions is goodness or not. Concerning YANG 1.1 Section = 6.3.1, >>> can you please detail what exactly your concern is? The relevant = text >>> is this: >>>=20 >>> The processing of extensions depends on whether support for those >>> extensions is claimed for a given YANG parser or the tool set in >>> which it is embedded. An unsupported extension, appearing in a = YANG >>> module as an unknown-statement (see Section 14) MAY be ignored in = its >>> entirety. Any supported extension MUST be processed in accordance >>> with the specification governing that extension. >>>=20 >>> Why do you believe a YANG implementation not supporting the mount >>> point extension can not simply ignore it? >>=20 >> If a client doesn't support that extension, it will receive what = looks like mysterious data in replies to get or get-config (or their = RESTCONF equivalents) and is likely to choke. The server isn't able to = tell whether the client knows about the "extended" model or not. >>=20 >=20 > Has it not always been the case that unexpected data is ignored? No. Data that aren't in the schema are clearly invalid. >=20 >> You may say it is the same with YSDL, but in fact YSDL doesn't = pretend it can be used with clients that are unaware of it. =46rom the = YANG point of view, however, modules that are intended to be used with = YSDL can be developed and published without waiting for a YANG extension = to be standardized first, because they are just good old YANG modules. >>=20 >=20 > I do not really see the difference. A client that does not understand > the YDSL module will see the same unexpected data. If you are saying > that YSDL can't be incrementally deployed, well then I believe there > is a bigger problem. Well, yes, and I think it is true for structural-mount, too. A device = that implements rtgyangdt's concepts can hardly be managed with old = clients either way. But my question here is: What's the real benefit of the mount-point = extension? If it is just to define an alias for a location in the = schema, then it's not needed because we can use schema node identifiers = for the same purpose. 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: E74E8C0C From nobody Thu Mar 3 08:54:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50EE1A8842 for ; Thu, 3 Mar 2016 08:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvssU1pmgu8c for ; Thu, 3 Mar 2016 08:53:58 -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 212C11A883D for ; Thu, 3 Mar 2016 08:53:58 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E5247193C; Thu, 3 Mar 2016 17:53:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9OPG_ZyATBlo; Thu, 3 Mar 2016 17:53:38 +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, 3 Mar 2016 17:53:56 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A8E920039; Thu, 3 Mar 2016 17:53:56 +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 6KsogdpEX6JX; Thu, 3 Mar 2016 17:53:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAE1420038; Thu, 3 Mar 2016 17:53:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DE05B3A04172; Thu, 3 Mar 2016 17:53:54 +0100 (CET) Date: Thu, 3 Mar 2016 17:53:54 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160303165354.GA34155@elstar.local> Mail-Followup-To: Ladislav Lhotka , Lou Berger , netmod WG References: <56D4ACA6.40208@labn.net> <20160303142124.GA33703@elstar.local> <20160303153857.GA33953@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod WG Subject: Re: [netmod] Moving the WG discussion on mount forward X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 03 Mar 2016 16:53:59 -0000 On Thu, Mar 03, 2016 at 05:24:08PM +0100, Ladislav Lhotka wrote: > > No. Data that aren't in the schema are clearly invalid. > This is defined where? Anyway, if this is the case, then both mount proposals are broken since both do not define the data mounted on a mount point in the schema. > But my question here is: What's the real benefit of the mount-point > extension? If it is just to define an alias for a location in the > schema, then it's not needed because we can use schema node > identifiers for the same purpose. This is a valid question to ask. I just commented on your YANG extension argument, which I do not find too convincing. /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 3 14:42:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358F11B2E6E for ; Thu, 3 Mar 2016 14:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.006 X-Spam-Level: X-Spam-Status: No, score=-0.006 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxanPTJ75EYE for ; Thu, 3 Mar 2016 14:42:46 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56CE21B2E6C for ; Thu, 3 Mar 2016 14:42:44 -0800 (PST) Received: from [88.128.80.212] (helo=latte) by cappuccino.rob.sh with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1abbwt-0006SK-0C for netmod@ietf.org; Thu, 03 Mar 2016 22:42:24 +0000 Date: Thu, 3 Mar 2016 22:40:18 +0000 From: Rob Shakir To: netmod@ietf.org Message-ID: X-Mailer: Airmail Beta (350) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="56d8bd53_4406f705_11a" Archived-At: Subject: [netmod] 'Namespace Qualified' in draft-ietf-netmod-yang-json-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 22:42:49 -0000 --56d8bd53_4406f705_11a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi NETMOD, I am in the process of implementing draft-ietf-netmod-yang-json=E2=80=930= 8, and had some queries as to the content. Hopefully there is some misund= erstanding on my part, or it helps to clean up the text for future people= reviewing/implementing. The phrase =E2=80=98namespace-qualified=E2=80=99 seems to have some ambig= uity through the document. =46or example, in the case that we have two mo= dules: module mod-a =7B prefix =22pfx-a=22; namespace =22http://a.tld=22; =20 container container-a =7B leaf leaf-a =7B type string; =7D =20 leaf ref-a =7B type identityref =7B base SOME=5FIDENTITY; =7D =7D =7D =7D module mod-b =7B prefix =22pfx-b=22; namespace =22http://b.tld=22; =20 container container-b =7B leaf leaf-b =7B type string; =7D =20 leaf ref-b =7B type identityref =7B base SOME=5FIDENTITY; =7D =7D =7D =7D Then, AIUI, the encoding needs to specify the names of the modules for bo= th container-a and container-b (since they sit at the root; and are in di= fferent namespaces) - so we encode these as JSON objects named mod-a:cont= ainer-a and mod-b:container-b as per Section 4 of the document. In this case, we never use the actual namespace (i.e., http://a.tld and h= ttp://b.tld) so calling it =E2=80=98namespace qualified=E2=80=99 appears = ambiguous. Should it be simply referred to as =E2=80=98module-qualified=E2= =80=99=3F Secondarily, the example in Section 6.8 does not actually use the name of= the module, it rather uses the prefix (if for the interface-type leaf). = This doesn=E2=80=99t seem to be explained anywhere within the text. Is th= is a mistake=3F If it=E2=80=99s not (and one could encode container-a and container-b abo= ve as pfx-a:container-a and pfx-b:container-b), then how do we deal with = this case: module a =7B import b =7B prefix =22c=22; =7D =20 leaf id =7B type identityref =7B base =22c:SOME=5FIDENTITY=22; =7D =7D =7D module b =7B ... prefix =22b=22; ... =7D when we encode, if we=E2=80=99re just given a value, do we add the prefix= that a uses to import b, or the prefix that b defines itself=3F (If the = prefix is used for identityref values, then the same question exists for = those values - today, one must track all prefixes that are related to a c= ertain identity value based on different imports, such that one does not = incorrectly reject some prefix:identity statement that was valid). It seems to me that using the module name consistently throughout the enc= oding is preferable, since this cannot be different in a number of places= ; and isn=E2=80=99t as long as the namespace value to make readability wo= rse. I also didn=E2=80=99t understand why an identityref value encodes the nam= espace in the actual value=3F It seems like the =E2=80=9Cbase=E2=80=9D of= the identityref should qualify all possible values here; with the only c= ase that we would ever need this is one where we have: leaf some-reference =7B type union =7B type identityref =7B base =22a=22; =7D type identityref =7B base =22b=22; =7D =7D =7D And a and b both define a value with the same name (where one needs the p= refix to be able to refer to the b version). Thanks, r. --56d8bd53_4406f705_11a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi NETMOD,

I am in the process of implementing draft-ietf-netmod-yang-json=E2=80=93= 08, and had some queries as to the content. Hopefully there is some misun= derstanding on my part, or it helps to clean up the text for future peopl= e reviewing/implementing.

The phrase =E2=80=98namespace-qualified=E2=80=99 seems to have some am= biguity through the document. =46or example, in the case that we have two= modules:

module mod-a =7B
    prefix =22pfx-a=22;
    namespace =22http://a.tld=22;
    =20
    container container-a =7B
        leaf leaf-a =7B
            type string;
        =7D
        =20
        leaf ref-a =7B
            type identityref =7B
                base SOME=5FIDENTITY;
            =7D
        =7D
    =7D
=7D

module mod-b =7B
    prefix =22pfx-b=22;
    namespace =22http://b.tld=22;
    =20
    container container-b =7B
        leaf leaf-b =7B
            type string;
        =7D
        =20
        leaf ref-b =7B
            type identityref =7B
                base SOME=5FIDENTITY;
            =7D
        =7D
    =7D
=7D

Then, AIUI, the encoding needs to specify the names of the modules for= both container-a and container-b (since they s= it at the root; and are in different namespaces) - so we encode these as = JSON objects named mod-a:container-a and mod-b:contain= er-b as per Section 4 of the document.

In this case, we never use the actual namespace (i.e., http://a.= tld and http://b.tld) so calling it =E2=80=98namespac= e qualified=E2=80=99 appears ambiguous. Should it be simply referred to a= s =E2=80=98module-qualified=E2=80=99=3F

Secondarily, the example in Section 6.8 does not actually use the name= of the module, it rather uses the prefix (if for the = interface-type leaf). This doesn=E2=80=99t seem to be explained an= ywhere within the text. Is this a mistake=3F

If it=E2=80=99s not (and one could encode container-a and= container-b above as pfx-a:container-a and pfx-b:container-b), then how do we deal with this case:

module a =7B
        import b =7B prefix =22c=22; =7D
        =20
        leaf id =7B
            type identityref =7B
                base =22c:SOME=5FIDENTITY=22;
            =7D
        =7D
=7D

module b =7B
    ...
    prefix =22b=22;
    ...
=7D

when we encode, if we=E2=80=99re just given a value, do we add the pre= fix that a uses to import b, or the prefix that= b defines itself=3F (If the prefix is used for identi= tyref values, then the same question exists for those values - tod= ay, one must track all prefixes that are related to a certain identity va= lue based on different imports, such that one does not incorrectly reject= some prefix:identity statement that was valid).

It seems to me that using the module name consistently throughout the = encoding is preferable, since this cannot be different in a number of pla= ces; and isn=E2=80=99t as long as the namespace value to make readability= worse.

I also didn=E2=80=99t understand why an identityref value encodes the = namespace in the actual value=3F It seems like the =E2=80=9Cbase=E2=80=9D= of the identityref should qualify all possible values here; with the onl= y case that we would ever need this is one where we have:

leaf some-reference =7B
    type union =7B
        type identityref =7B
            base =22a=22;
        =7D
        type identityref =7B
            base =22b=22;
        =7D
    =7D
=7D

And a and b both define a value with the sam= e name (where one needs the prefix to be able to refer to the b version).

Thanks,
r.

--56d8bd53_4406f705_11a-- From nobody Thu Mar 3 15:32:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6851B2FD6 for ; Thu, 3 Mar 2016 15:32:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q9-ZDZeSHiS for ; Thu, 3 Mar 2016 15:32:43 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47BE1B2FEA for ; Thu, 3 Mar 2016 15:32:42 -0800 (PST) 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 (TLS) id 15.1.415.20; Thu, 3 Mar 2016 23:32:38 +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.0415.024; Thu, 3 Mar 2016 23:32:38 +0000 From: Kent Watsen To: Rob Shakir , "netmod@ietf.org" Thread-Topic: [netmod] 'Namespace Qualified' in draft-ietf-netmod-yang-json-08 Thread-Index: AQHRdZ4GrKRWmg2MQk2iBs2ne6V7kZ9ICuEA Date: Thu, 3 Mar 2016 23:32:37 +0000 Message-ID: <96D2F1CA-8145-43F5-992D-A987AF4A10D7@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 authentication-results: rob.sh; dkim=none (message not signed) header.d=none;rob.sh; 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; BN3PR0501MB1443; 5:fdPpwU/9j+8cHr6AnaY7fAzkQvE49zbZJHkVjL8W/NrIYfvm0zO94A6PQdgQASBSz52vNyZustbaCPLVOwDLR6l+ymF9jpKVdJi9IJ+rdHQ5F+sWsekI8y1psuiixf+BVSTZ375n7RwhVuIAOhReSg==; 24:pfhxAwfcKj+TV0T1EBMVpb4DPIMeGkwYa3sY8+7TPTskxtKugIbQFxbyK/CpYG73TnNtUOnEzapr2Er019krx5xssSfPR40Gv7wq5xjtSbk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-ms-office365-filtering-correlation-id: e085568d-9db4-4228-45dc-08d343bc1b48 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0870212862 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(36756003)(230783001)(86362001)(82746002)(83506001)(99286002)(5002640100001)(76176999)(5001770100001)(81166005)(16236675004)(50986999)(106116001)(54356999)(33656002)(107886002)(19617315012)(189998001)(4001350100001)(1220700001)(87936001)(92566002)(11100500001)(5008740100001)(66066001)(83716003)(122556002)(16601075003)(15975445007)(2950100001)(10400500002)(2906002)(3660700001)(5004730100002)(40100003)(2900100001)(2501003)(6116002)(586003)(102836003)(3280700002)(3846002)(1096002)(77096005)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_96D2F1CA814543F5992DA987AF4A10D7junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2016 23:32:37.8755 (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] 'Namespace Qualified' in draft-ietf-netmod-yang-json-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 23:32:45 -0000 --_000_96D2F1CA814543F5992DA987AF4A10D7junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJbiB0aGlzIGNhc2UsIHdlIG5ldmVyIHVzZSB0aGUgYWN0dWFsIG5hbWVzcGFjZSAoaS5lLiwg aHR0cDovL2EudGxkIGFuZCBodHRwOi8vYi50bGQpIHNvIGNhbGxpbmcgaXQg4oCYbmFtZXNwYWNl IHF1YWxpZmllZOKAmSBhcHBlYXJzIGFtYmlndW91cy4gU2hvdWxkIGl0IGJlIHNpbXBseSByZWZl cnJlZCB0byBhcyDigJhtb2R1bGUtcXVhbGlmaWVk4oCZPw0KDQpJdCBpcyBhIGJpdCBvZiBhIG1p c25vbWVyLCBhbmQgcGVyaGFwcyBjb3VsZCBiZSBpbXByb3ZlZCwgYnV0IFNlY3Rpb24gNCBkZWZp bmVzIOKAnG5hbWVzcGFjZS1xdWFsaWZpZWTigJ0gYXMg4oCcbmFtZSBvZiBtb2R1bGXigJ06DQoN CiAgIG8gIG5hbWVzcGFjZS1xdWFsaWZpZWQgLSB0aGUgZGF0YSBub2RlIGlkZW50aWZpZXIgaXMg cHJlZml4ZWQgd2l0aA0KICAgICAgdGhlIG5hbWUgb2YgdGhlIG1vZHVsZSBpbiB3aGljaCB0aGUg ZGF0YSBub2RlIGlzIGRlZmluZWQsDQogICAgICBzZXBhcmF0ZWQgZnJvbSB0aGUgZGF0YSBub2Rl IGlkZW50aWZpZXIgYnkgdGhlIGNvbG9uIGNoYXJhY3Rlcg0KICAgICAgKCI64oCdKS4NCg0KDQoN Cg0KPiBTZWNvbmRhcmlseSwgdGhlIGV4YW1wbGUgaW4gU2VjdGlvbiA2LjggZG9lcyBub3QgYWN0 dWFsbHkgdXNlIHRoZSBuYW1lIG9mIHRoZSBtb2R1bGUsIGl0IHJhdGhlciB1c2VzIHRoZSBwcmVm aXggKGlmIGZvciB0aGUgaW50ZXJmYWNlLXR5cGUgbGVhZikuIFRoaXMgZG9lc27igJl0IHNlZW0g dG8gYmUgZXhwbGFpbmVkIGFueXdoZXJlIHdpdGhpbiB0aGUgdGV4dC4gSXMgdGhpcyBhIG1pc3Rh a2U/DQoNClRoZSBtb2R1bGUgaXMgWUFORywgYW5kIGluIFlBTkcgdGhlIHByZWZpeCBpcyB1c2Vk LCBzbyDigJxpZuKAnSBpcyBjb3JyZWN0LiAgIEJlbG93IHRoZSBleGFtcGxlIG1vZHVsZSBpcyBh IEpTT04gc25pcHBldCwgd2hlcmUgeW914oCZbGwgZmluZCBhIG1vZHVsZeKAmXMgZnVsbCBuYW1l IHF1YWxpZnlpbmcgdGhlIGlkZW50aXR5Lg0KDQoNCg0KDQo+IElmIGl04oCZcyBub3QgKGFuZCBv bmUgY291bGQgZW5jb2RlIGNvbnRhaW5lci1hIGFuZCBjb250YWluZXItYiBhYm92ZSBhcyBwZngt YTpjb250YWluZXItYSBhbmQgcGZ4LWI6Y29udGFpbmVyLWIpLCB0aGVuIGhvdyBkbyB3ZSBkZWFs IHdpdGggdGhpcyBjYXNlOiA8U05JUC8+DQoNCkkgdGhpbmsgeW914oCZcmUgbWl4aW5nIHRoaW5n cyB1cCwgSlNPTiBlbmNvZGluZyBvbmx5IHVzZXMgbW9kdWxlLW5hbWVzLg0KDQoNCg0KPiBJdCBz ZWVtcyB0byBtZSB0aGF0IHVzaW5nIHRoZSBtb2R1bGUgbmFtZSBjb25zaXN0ZW50bHkgdGhyb3Vn aG91dCB0aGUgZW5jb2RpbmcgaXMgcHJlZmVyYWJsZSwgc2luY2UgdGhpcyBjYW5ub3QgYmUgZGlm ZmVyZW50IGluIGEgbnVtYmVyIG9mIHBsYWNlczsgYW5kIGlzbuKAmXQgYXMgbG9uZyBhcyB0aGUg bmFtZXNwYWNlIHZhbHVlIHRvIG1ha2UgcmVhZGFiaWxpdHkgd29yc2UuDQoNCkluZGVlZC4NCg0K DQoNCg0KPiBJIGFsc28gZGlkbuKAmXQgdW5kZXJzdGFuZCB3aHkgYW4gaWRlbnRpdHlyZWYgdmFs dWUgZW5jb2RlcyB0aGUgbmFtZXNwYWNlIGluIHRoZSBhY3R1YWwgdmFsdWU/DQoNCkl0IGNhbiBh bHNvIGJlIHNpbXBsZSBmb3JtICh3L28gbmFtZXNwYWNlKSBpZiB0aGUgaWRlbnRpdHkgaXMgZGVm aW5lZCBpbiB0aGUgc2FtZSBtb2R1bGUuLi4NCg0KDQoNCg0KPiBJdCBzZWVtcyBsaWtlIHRoZSDi gJxiYXNl4oCdIG9mIHRoZSBpZGVudGl0eXJlZiBzaG91bGQgcXVhbGlmeSBhbGwgcG9zc2libGUg dmFsdWVzIGhlcmU7DQoNCllvdSBtZWFuIHRoYXQgdGhlIG5hbWVzcGFjZSBpcyBpbXBsaWNpdGx5 IGRlZmluZWQgaW4gdGhlIFlBTkcsIHNvIGhhdmluZyBpdCBhbHNvIGluIHRoZSBKU09OIGlzIHJl ZHVuZGFudD8NCg0KDQoNCg0KPiB3aXRoIHRoZSBvbmx5IGNhc2UgdGhhdCB3ZSB3b3VsZCBldmVy IG5lZWQgdGhpcyBpcyBvbmUgd2hlcmUgd2UgaGF2ZToNCg0KbGVhZiBzb21lLXJlZmVyZW5jZSB7 DQogICAgdHlwZSB1bmlvbiB7DQogICAgICAgIHR5cGUgaWRlbnRpdHlyZWYgew0KICAgICAgICAg ICAgYmFzZSAiYSI7DQogICAgICAgIH0NCiAgICAgICAgdHlwZSBpZGVudGl0eXJlZiB7DQogICAg ICAgICAgICBiYXNlICJiIjsNCiAgICAgICAgfQ0KICAgIH0NCn0NCg0KDQo+IEFuZCBhIGFuZCBi IGJvdGggZGVmaW5lIGEgdmFsdWUgd2l0aCB0aGUgc2FtZSBuYW1lICh3aGVyZSBvbmUgbmVlZHMg dGhlIHByZWZpeCB0byBiZSBhYmxlIHRvIHJlZmVyIHRvIHRoZSBiIHZlcnNpb24pLg0KDQoNClNt YWxsIG5pdCwgYnV0IEkgdGhpbmsgdGhpcyBtaWdodCBiZSBiZXR0ZXIgcmVwcmVzZW50ZWQgdXNp bmcgbW9yZSB0aGFuIG9uZSDigJxiYXNl4oCdIHN0YXRlbWVudCBpbiB0aGUgaWRlbnRpdHlyZWY6 DQoNCmxlYWYgc29tZS1yZWZlcmVuY2Ugew0KICAgIHR5cGUgaWRlbnRpdHlyZWYgew0KICAgICAg ICBiYXNlICJhIjsNCiAgICAgICAgYmFzZSAiYiI7DQogICAgfQ0KfQ0KDQoNClJlZ2FyZGxlc3Ms IG15IG9ubHkgdGhvdWdodCBpcyB0aGF0IGl0IGlzIGZvciBjb25zaXN0ZW5jeS4gICBJ4oCZbSBz dXJlIG90aGVycyB3aWxsIGhhdmUgYSBiZXR0ZXIgYW5zd2VyLg0KDQoNCksuDQoNCg0KDQo= --_000_96D2F1CA814543F5992DA987AF4A10D7junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <5616811195BB654FB4F7E19BC9027218@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K PGRpdj4NCjxkaXY+Jmd0OyBJbiB0aGlzIGNhc2UsIHdlIG5ldmVyIHVzZSB0aGUgYWN0dWFsIG5h bWVzcGFjZSAoaS5lLiwgPGNvZGUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxhIGhy ZWY9Imh0dHA6Ly9hLnRsZCI+aHR0cDovL2EudGxkPC9hPjwvY29kZT4gYW5kIDxjb2RlIHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8YSBocmVmPSJodHRwOi8vYi50bGQiPmh0dHA6Ly9i LnRsZDwvYT48L2NvZGU+KSBzbyBjYWxsaW5nIGl0IOKAmG5hbWVzcGFjZSBxdWFsaWZpZWTigJkg YXBwZWFycyBhbWJpZ3VvdXMuIFNob3VsZCBpdCBiZSBzaW1wbHkgcmVmZXJyZWQgdG8gYXMg4oCY bW9kdWxlLXF1YWxpZmllZOKAmT88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NCkl0IGlzIGEgYml0IG9mIGEgbWlzbm9tZXIsIGFuZCBwZXJoYXBzIGNvdWxkIGJlIGltcHJv dmVkLCBidXQgU2VjdGlvbiA0IGRlZmluZXMg4oCcbmFtZXNwYWNlLXF1YWxpZmllZOKAnSBhcyDi gJxuYW1lIG9mIG1vZHVsZeKAnTo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4N Cjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxmb250 IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO28gJm5ic3A7bmFtZXNwYWNl LXF1YWxpZmllZCAtIHRoZSBkYXRhIG5vZGUgaWRlbnRpZmllciBpcyBwcmVmaXhlZCB3aXRoPC9m b250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGZvbnQgZmFjZT0iQ2Fs aWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgbmFtZSBvZiB0aGUgbW9k dWxlIGluIHdoaWNoIHRoZSBkYXRhIG5vZGUgaXMgZGVmaW5lZCw8L2ZvbnQ+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYi PiZuYnNwOyAmbmJzcDsgJm5ic3A7IHNlcGFyYXRlZCBmcm9tIHRoZSBkYXRhIG5vZGUgaWRlbnRp ZmllciBieSB0aGUgY29sb24gY2hhcmFjdGVyPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDYWxpYnJpLHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICgmcXVvdDs64oCdKS48 L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxwPiZndDsgU2Vjb25kYXJp bHksIHRoZSBleGFtcGxlIGluIFNlY3Rpb24gNi44IGRvZXMgbm90IGFjdHVhbGx5IHVzZSB0aGUg bmFtZSBvZiB0aGUgbW9kdWxlLCBpdCByYXRoZXIgdXNlcyB0aGUgcHJlZml4ICg8Y29kZT5pZjwv Y29kZT4gZm9yIHRoZQ0KPGNvZGU+aW50ZXJmYWNlLXR5cGU8L2NvZGU+IGxlYWYpLiBUaGlzIGRv ZXNu4oCZdCBzZWVtIHRvIGJlIGV4cGxhaW5lZCBhbnl3aGVyZSB3aXRoaW4gdGhlIHRleHQuIElz IHRoaXMgYSBtaXN0YWtlPzwvcD4NCjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NClRoZSBtb2R1bGUgaXMgWUFORywgYW5kIGluIFlBTkcgdGhlIHByZWZpeCBpcyB1c2VkLCBz byDigJxpZuKAnSBpcyBjb3JyZWN0LiAmbmJzcDsgQmVsb3cgdGhlIGV4YW1wbGUgbW9kdWxlIGlz IGEgSlNPTiBzbmlwcGV0LCB3aGVyZSB5b3XigJlsbCBmaW5kIGEgbW9kdWxl4oCZcyBmdWxsIG5h bWUgcXVhbGlmeWluZyB0aGUgaWRlbnRpdHkuPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8c3Bh biBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8cD4m Z3Q7IElmIGl04oCZcyBub3QgKGFuZCBvbmUgY291bGQgZW5jb2RlIDxjb2RlPmNvbnRhaW5lci1h PC9jb2RlPiBhbmQgPGNvZGU+Y29udGFpbmVyLWI8L2NvZGU+IGFib3ZlIGFzDQo8Y29kZT5wZngt YTpjb250YWluZXItYTwvY29kZT4gYW5kIDxjb2RlPnBmeC1iOmNvbnRhaW5lci1iPC9jb2RlPiks IHRoZW4gaG93IGRvIHdlIGRlYWwgd2l0aCB0aGlzIGNhc2U6ICZsdDtTTklQLyZndDs8L3A+DQo8 L3NwYW4+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPg0KPHA+SSB0aGluayB5b3XigJlyZSBtaXhpbmcgdGhpbmdzIHVwLCBKU09OIGVuY29kaW5n IG9ubHkgdXNlcyBtb2R1bGUtbmFtZXMuPC9wPg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KJmd0OyBJdCBzZWVtcyB0byBtZSB0aGF0IHVz aW5nIHRoZSBtb2R1bGUgbmFtZSBjb25zaXN0ZW50bHkgdGhyb3VnaG91dCB0aGUgZW5jb2Rpbmcg aXMgcHJlZmVyYWJsZSwgc2luY2UgdGhpcyBjYW5ub3QgYmUgZGlmZmVyZW50IGluIGEgbnVtYmVy IG9mIHBsYWNlczsgYW5kIGlzbuKAmXQgYXMgbG9uZyBhcyB0aGUgbmFtZXNwYWNlIHZhbHVlIHRv IG1ha2UgcmVhZGFiaWxpdHkgd29yc2UuPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4 OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCkluZGVlZC48 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxwPiZndDsgSSBhbHNvIGRpZG7igJl0IHVuZGVyc3Rh bmQgd2h5IGFuIGlkZW50aXR5cmVmIHZhbHVlIGVuY29kZXMgdGhlIG5hbWVzcGFjZSBpbiB0aGUg YWN0dWFsIHZhbHVlPw0KPC9wPg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsi Pg0KSXQgY2FuIGFsc28gYmUgc2ltcGxlIGZvcm0gKHcvbyBuYW1lc3BhY2UpIGlmIHRoZSBpZGVu dGl0eSBpcyBkZWZpbmVkIGluIHRoZSBzYW1lIG1vZHVsZS4uLjwvZGl2Pg0KPGRpdiBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4 OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwv ZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPg0KPHA+Jmd0OyBJdCBzZWVtcyBsaWtlIHRoZSDigJxiYXNl4oCdIG9mIHRoZSBpZGVudGl0 eXJlZiBzaG91bGQgcXVhbGlmeSBhbGwgcG9zc2libGUgdmFsdWVzIGhlcmU7PC9wPg0KPC9zcGFu Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KWW91IG1lYW4gdGhhdCB0aGUgbmFtZXNw YWNlIGlzIGltcGxpY2l0bHkgZGVmaW5lZCBpbiB0aGUgWUFORywgc28gaGF2aW5nIGl0IGFsc28g aW4gdGhlIEpTT04gaXMgcmVkdW5kYW50PzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHNwYW4g aWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPHA+Jmd0 OyB3aXRoIHRoZSBvbmx5IGNhc2UgdGhhdCB3ZSB3b3VsZCBldmVyIG5lZWQgdGhpcyBpcyBvbmUg d2hlcmUgd2UgaGF2ZTo8L3A+DQo8cHJlPjxjb2RlPmxlYWYgc29tZS1yZWZlcmVuY2Ugew0KICAg IHR5cGUgdW5pb24gew0KICAgICAgICB0eXBlIGlkZW50aXR5cmVmIHsNCiAgICAgICAgICAgIGJh c2UgJnF1b3Q7YSZxdW90OzsNCiAgICAgICAgfQ0KICAgICAgICB0eXBlIGlkZW50aXR5cmVmIHsN CiAgICAgICAgICAgIGJhc2UgJnF1b3Q7YiZxdW90OzsNCiAgICAgICAgfQ0KICAgIH0NCn0NCjwv Y29kZT48L3ByZT4NCjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXY+ Jmd0OyBBbmQmbmJzcDs8Y29kZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPmE8L2NvZGU+ Jm5ic3A7YW5kJm5ic3A7PGNvZGUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7Ij5iPC9jb2Rl PiZuYnNwO2JvdGggZGVmaW5lIGEgdmFsdWUgd2l0aCB0aGUgc2FtZSBuYW1lICh3aGVyZSBvbmUg bmVlZHMgdGhlIHByZWZpeCB0byBiZSBhYmxlIHRvIHJlZmVyIHRvIHRoZSZuYnNwOzxjb2RlIHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyI+YjwvY29kZT4mbmJzcDt2ZXJzaW9uKS48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyI+DQpTbWFsbCBuaXQsIGJ1dCBJIHRoaW5rIHRoaXMgbWlnaHQgYmUg YmV0dGVyIHJlcHJlc2VudGVkIHVzaW5nIG1vcmUgdGhhbiBvbmUg4oCcYmFzZeKAnSBzdGF0ZW1l bnQgaW4gdGhlIGlkZW50aXR5cmVmOjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsi Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBw eDsgYm9yZGVyOm5vbmU7IHBhZGRpbmc6MHB4OyI+DQo8ZGl2PmxlYWYgc29tZS1yZWZlcmVuY2Ug ezwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7IHR5cGUgaWRlbnRpdHlyZWYgezwvZGl2Pg0KPGRp dj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmFzZSAmcXVvdDthJnF1b3Q7OzwvZGl2Pg0K PGRpdj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmFzZSAmcXVvdDtiJnF1b3Q7OzwvZGl2 Pg0KPGRpdj4mbmJzcDsgJm5ic3A7IH08L2Rpdj4NCjxkaXY+fTwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KUmVnYXJkbGVzcywgbXkgb25seSB0aG91Z2h0IGlzIHRoYXQgaXQgaXMg Zm9yIGNvbnNpc3RlbmN5LiAmbmJzcDsgSeKAmW0gc3VyZSBvdGhlcnMgd2lsbCBoYXZlIGEgYmV0 dGVyIGFuc3dlci48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+DQpLLjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHN0eWxl Pg0KYm9keSB7DQoJZm9udC1mYW1pbHk6ICJIZWx2ZXRpY2EgTmV1ZSIsIEhlbHZldGljYSwgQXJp YWwsIHNhbnMtc2VyaWY7DQoJcGFkZGluZzoxZW07DQoJbWFyZ2luOmF1dG87DQoJYmFja2dyb3Vu ZDojZmVmZWZlOw0KfQ0KDQpoMSwgaDIsIGgzLCBoNCwgaDUsIGg2IHsNCglmb250LXdlaWdodDog Ym9sZDsNCn0NCg0KaDEgew0KCWNvbG9yOiAjMDAwMDAwOw0KCWZvbnQtc2l6ZTogMjhwdDsNCn0N Cg0KaDIgew0KCWJvcmRlci1ib3R0b206IDFweCBzb2xpZCAjQ0NDQ0NDOw0KCWNvbG9yOiAjMDAw MDAwOw0KCWZvbnQtc2l6ZTogMjRweDsNCn0NCg0KaDMgew0KCWZvbnQtc2l6ZTogMThweDsNCn0N Cg0KaDQgew0KCWZvbnQtc2l6ZTogMTZweDsNCn0NCg0KaDUgew0KCWZvbnQtc2l6ZTogMTRweDsN Cn0NCg0KaDYgew0KCWNvbG9yOiAjNzc3Nzc3Ow0KCWJhY2tncm91bmQtY29sb3I6IGluaGVyaXQ7 DQoJZm9udC1zaXplOiAxNHB4Ow0KfQ0KDQpociB7DQoJaGVpZ2h0OiAwLjJlbTsNCglib3JkZXI6 IDA7DQoJY29sb3I6ICNDQ0NDQ0M7DQoJYmFja2dyb3VuZC1jb2xvcjogI0NDQ0NDQzsNCiAgICBk aXNwbGF5OiBpbmhlcml0Ow0KfQ0KDQpwLCBibG9ja3F1b3RlLCB1bCwgb2wsIGRsLCBsaSwgdGFi bGUsIHByZSB7DQoJbWFyZ2luOiAxNXB4IDA7DQp9DQoNCmEsIGE6dmlzaXRlZCB7DQoJY29sb3I6 ICM0MTgzQzQ7DQoJYmFja2dyb3VuZC1jb2xvcjogaW5oZXJpdDsNCgl0ZXh0LWRlY29yYXRpb246 IG5vbmU7DQp9DQoNCiNtZXNzYWdlIHsNCglib3JkZXItcmFkaXVzOiA2cHg7DQoJYm9yZGVyOiAx cHggc29saWQgI2NjYzsNCglkaXNwbGF5OmJsb2NrOw0KCXdpZHRoOjEwMCU7DQoJaGVpZ2h0OjYw cHg7DQoJbWFyZ2luOjZweCAwcHg7DQp9DQoNCmJ1dHRvbiwgI3dzIHsNCglmb250LXNpemU6IDEy IHB0Ow0KCXBhZGRpbmc6IDRweCA2cHg7DQoJYm9yZGVyLXJhZGl1czogNXB4Ow0KCWJvcmRlcjog MXB4IHNvbGlkICNiYmI7DQoJYmFja2dyb3VuZC1jb2xvcjogI2VlZTsNCn0NCg0KY29kZSwgcHJl LCAjd3MsICNtZXNzYWdlIHsNCglmb250LWZhbWlseTogTW9uYWNvOw0KCWZvbnQtc2l6ZTogMTBw dDsNCglib3JkZXItcmFkaXVzOiAzcHg7DQoJYmFja2dyb3VuZC1jb2xvcjogI0Y4RjhGODsNCglj b2xvcjogaW5oZXJpdDsNCn0NCg0KY29kZSB7DQoJYm9yZGVyOiAxcHggc29saWQgI0VBRUFFQTsN CgltYXJnaW46IDAgMnB4Ow0KCXBhZGRpbmc6IDAgNXB4Ow0KfQ0KDQpwcmUgew0KCWJvcmRlcjog MXB4IHNvbGlkICNDQ0NDQ0M7DQoJb3ZlcmZsb3c6IGF1dG87DQoJcGFkZGluZzogNHB4IDhweDsN Cn0NCg0KcHJlID4gY29kZSB7DQoJYm9yZGVyOiAwOw0KCW1hcmdpbjogMDsNCglwYWRkaW5nOiAw Ow0KfQ0KDQojd3MgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjZjhmOGY4OyB9DQoNCg0KLmJsb29wX21h cmtkb3duIHRhYmxlIHsNCmJvcmRlci1jb2xsYXBzZTogY29sbGFwc2U7ICANCmZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2EsIGFyaWFsLCBmcmVlc2FucywgY2xlYW4sIHNhbnMtc2VyaWY7ICANCmNvbG9y OiByZ2IoNTEsIDUxLCA1MSk7ICANCmZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6IDI1cHg7 DQpwYWRkaW5nOiAwOyB9DQoNCi5ibG9vcF9tYXJrZG93biB0YWJsZSB0ciB7DQpib3JkZXItdG9w OiAxcHggc29saWQgI2NjY2NjYzsNCmJhY2tncm91bmQtY29sb3I6IHdoaXRlOw0KbWFyZ2luOiAw Ow0KcGFkZGluZzogMDsgfQ0KICAgICANCi5ibG9vcF9tYXJrZG93biB0YWJsZSB0cjpudGgtY2hp bGQoMm4pIHsNCmJhY2tncm91bmQtY29sb3I6ICNmOGY4Zjg7IH0NCg0KLmJsb29wX21hcmtkb3du IHRhYmxlIHRyIHRoIHsNCmZvbnQtd2VpZ2h0OiBib2xkOw0KYm9yZGVyOiAxcHggc29saWQgI2Nj Y2NjYzsNCm1hcmdpbjogMDsNCnBhZGRpbmc6IDZweCAxM3B4OyB9DQoNCi5ibG9vcF9tYXJrZG93 biB0YWJsZSB0ciB0ZCB7DQpib3JkZXI6IDFweCBzb2xpZCAjY2NjY2NjOw0KbWFyZ2luOiAwOw0K cGFkZGluZzogNnB4IDEzcHg7IH0NCg0KLmJsb29wX21hcmtkb3duIHRhYmxlIHRyIHRoIDpmaXJz dC1jaGlsZCwgdGFibGUgdHIgdGQgOmZpcnN0LWNoaWxkIHsNCm1hcmdpbi10b3A6IDA7IH0NCg0K LmJsb29wX21hcmtkb3duIHRhYmxlIHRyIHRoIDpsYXN0LWNoaWxkLCB0YWJsZSB0ciB0ZCA6bGFz dC1jaGlsZCB7DQptYXJnaW4tYm90dG9tOiAwOyB9DQoNCi5ibG9vcF9tYXJrZG93biBibG9ja3F1 b3Rlew0KICBib3JkZXItbGVmdDogNHB4IHNvbGlkICNkZGRkZGQ7DQogIHBhZGRpbmc6IDAgMTVw eDsNCiAgY29sb3I6ICM3Nzc3Nzc7IH0NCiAgYmxvY2txdW90ZSA+IDpmaXJzdC1jaGlsZCB7DQog ICAgbWFyZ2luLXRvcDogMDsgfQ0KICBibG9ja3F1b3RlID4gOmxhc3QtY2hpbGQgew0KICAgIG1h cmdpbi1ib3R0b206IDA7IH0NCg0KY29kZSwgcHJlLCAjd3MsICNtZXNzYWdlIHsNCiAgICB3b3Jk LWJyZWFrOiBub3JtYWw7DQogICAgd29yZC13cmFwOiBub3JtYWw7DQp9DQoNCmhyIHsNCiAgICBk aXNwbGF5OiBpbmhlcml0Ow0KfQ0KDQouYmxvb3BfbWFya2Rvd24gOmZpcnN0LWNoaWxkIHsNCiAg ICAtd2Via2l0LW1hcmdpbi1iZWZvcmU6IDA7DQp9DQoNCmNvZGUsIHByZSwgI3dzLCAjbWVzc2Fn ZSB7DQogICAgZm9udC1mYW1pbHk6IE1lbmxvLCBDb25zb2xhcywgTGliZXJhdGlvbiBNb25vLCBD b3VyaWVyLCBtb25vc3BhY2U7DQp9DQoNCg0KLnNlbmQgeyBjb2xvcjojNzdiYjc3OyB9DQouc2Vy dmVyIHsgY29sb3I6Izc3OTliYjsgfQ0KLmVycm9yIHsgY29sb3I6I0FBMDAwMDsgfTwvc3R5bGU+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_96D2F1CA814543F5992DA987AF4A10D7junipernet_-- From nobody Thu Mar 3 15:52:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6151B3000 for ; Thu, 3 Mar 2016 15:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aRwIeKFY4mI for ; Thu, 3 Mar 2016 15:52:39 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6851D1B3019 for ; Thu, 3 Mar 2016 15:52:38 -0800 (PST) Received: from [88.128.80.212] (helo=latte) by cappuccino.rob.sh with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1abd2V-0006iB-84; Thu, 03 Mar 2016 23:52:18 +0000 Date: Thu, 3 Mar 2016 23:47:55 +0000 From: Rob Shakir To: "=?utf-8?Q?netmod=40ietf.org?=" , Kent Watsen Message-ID: In-Reply-To: <96D2F1CA-8145-43F5-992D-A987AF4A10D7@juniper.net> References: <96D2F1CA-8145-43F5-992D-A987AF4A10D7@juniper.net> X-Mailer: Airmail Beta (350) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="56d8cde1_b4820b8_11a" Archived-At: Subject: Re: [netmod] 'Namespace Qualified' in draft-ietf-netmod-yang-json-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 23:52:42 -0000 --56d8cde1_b4820b8_11a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Kent, Thanks for the response=21 On 3 March, 2016 at 11:32:39 PM, Kent Watsen (kwatsen=40juniper.net) wrot= e: > In this case, we never use the actual namespace (i.e.,=C2=A0http://a.tl= d=C2=A0and=C2=A0http://b.tld) so calling it =E2=80=98namespace qualified=E2= =80=99 appears ambiguous. Should it be simply referred to as =E2=80=98mod= ule-qualified=E2=80=99=3F It is a bit of a misnomer, and perhaps could be improved, but Section 4 d= efines =E2=80=9Cnamespace-qualified=E2=80=9D as =E2=80=9Cname of module=E2= =80=9D: =C2=A0 =C2=A0o =C2=A0namespace-qualified - the data node identifier is pr= efixed with =C2=A0 =C2=A0 =C2=A0 the name of the module in which the data node is def= ined, =C2=A0 =C2=A0 =C2=A0 separated from the data node identifier by the colon= character =C2=A0 =C2=A0 =C2=A0 (=22:=E2=80=9D). Thanks. Is there a reason to call this namespace, when we also have a nam= espace statement in the module=3F It seems to present an opportunity to c= ause confusion with little benefit=3F > Secondarily, the example in Section 6.8 does not actually use the name = of the module, it rather uses the prefix (if=C2=A0for the=C2=A0interface-= type=C2=A0leaf). This doesn=E2=80=99t seem to be explained anywhere withi= n the text. Is this a mistake=3F The module is YANG, and in YANG the prefix is used, so =E2=80=9Cif=E2=80=9D= is correct. =C2=A0 Below the example module is a JSON snippet, where you= =E2=80=99ll find a module=E2=80=99s full name qualifying the identity. Ah, sorry =E2=80=94 you=E2=80=99re right. > I also didn=E2=80=99t understand why an identityref value encodes the n= amespace in the actual value=3F It can also be simple form (w/o namespace) if the identity is defined in = the same module... Agreed, I=E2=80=99m more wondering why *ever* carry it. > It seems like the =E2=80=9Cbase=E2=80=9D of the identityref should qual= ify all possible values here; You mean that the namespace is implicitly defined in the YANG, so having = it also in the JSON is redundant=3F Yes. Any identity value that extends that base must be unique AIUI, so ea= ch of those values then defines its namespace. Why do we carry it in the = JSON=3F Thanks again. r. --56d8cde1_b4820b8_11a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

With respect to the Mount draft.

 

I like the goal of being able to take an assortment = of device models (D1..Dn) and merge them in a scalable manner into a single= aggregate model (A).

 

My use case is a management interface aggregator.&nb= sp; A sort of middle box with multiple netconf interfaces on the managed de= vice side and one netconf interface on the manager side.  In my case, = one that performs persistence and pre-provisioning in addition to aggregation.

 

The draft proposes to do this by adding a new syntax= ‘mount’ along with supporting semantics.

  While adding yet another syntax to Yang is a = possibility, I’d like to propose something else.

  Specifically, I’d like to adjust the se= mantics for ‘uses’, ‘rpc’ and ‘notification&#= 8217; and keep the appearance of the current syntax.

 

1)      Allow the ‘uses’ verb to use a module i= n addition to groupings.

2)      Allow the ‘rpc’ and ‘notification= ’ nouns to be used in other places in the schema tree besides at the = top module level.

 

Given these features, I see them being used three wa= ys.

   First to mount  D on A by modifyin= g D, write augment A.

   Second to mount D on A by modifying A, = write uses D.

   Third to mount D on A with a third sepa= rate module, write augment A uses D.

 

At a protocol level, I guess data would just be deep= er in the tree. 

Rpc and notification would now need a prefix to thei= r name to show where in the tree they are from.

 

I wonder if others will see this as a more consisten= t and general purpose adjustment to Yang/Netconf.

 

 

 

--_000_1220E2C537595D439C5D026E83751866E7B4940Cexmb1corpadtran_-- From nobody Fri Mar 4 08:52:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6727E1A1A7B for ; Fri, 4 Mar 2016 08:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8hIvTM5YNfh for ; Fri, 4 Mar 2016 08:52:22 -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 A2B541A0AF1 for ; Fri, 4 Mar 2016 08:52:22 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7198B21CE; Fri, 4 Mar 2016 17:52:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ygc71doVF0lL; Fri, 4 Mar 2016 17:51:58 +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, 4 Mar 2016 17:52:20 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D580520038; Fri, 4 Mar 2016 17:52:20 +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 KDxUVN4vA61r; Fri, 4 Mar 2016 17:52: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 88CA420037; Fri, 4 Mar 2016 17:52:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5A6FC3A04BC0; Fri, 4 Mar 2016 17:52:19 +0100 (CET) Date: Fri, 4 Mar 2016 17:52:19 +0100 From: Juergen Schoenwaelder To: STUART VENTERS Message-ID: <20160304165219.GA36535@elstar.local> Mail-Followup-To: STUART VENTERS , "'netmod@ietf.org'" References: <1220E2C537595D439C5D026E83751866E7B4940C@ex-mb1.corp.adtran.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1220E2C537595D439C5D026E83751866E7B4940C@ex-mb1.corp.adtran.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "'netmod@ietf.org'" Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 04 Mar 2016 16:52:29 -0000 On Fri, Mar 04, 2016 at 04:25:37PM +0000, STUART VENTERS wrote: > > 2) Allow the 'rpc' and 'notification' nouns to be used in other places in the schema tree besides at the top module level. > This is already part of YANG 1.1. /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 4 11:22:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3951A8862 for ; Fri, 4 Mar 2016 11:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jD5e8kdalRL for ; Fri, 4 Mar 2016 11:22:54 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6951A885D for ; Fri, 4 Mar 2016 11:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6854; q=dns/txt; s=iport; t=1457119374; x=1458328974; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=uBkNqlHyrKCISJCsDQ/NIiBrbLZ1z3sF3mx7gYLn71E=; b=Um0mDDKw3EOKas9EbR9I8jzvsivvp4V+MzygnCHynmAPjIrpd6zPDAsJ Lf7zCUm8WzpiZ2w/qQ5rAYplOCVGJNx7aMXPLNXze2S+8CzrxuMZjKGMl hCt++OIMMS3e/DmbhlSAJNUyyQhtzdZCea60LCESm9XNH4BWDXQiBr6Kl M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAgAt4NlW/5hdJa1dgzpSbQa6NAENg?= =?us-ascii?q?WkXCoUkSgKBNzgUAQEBAQEBAWQnhEIBAQQBAQFoAxsCAQgYLicLJQIEARIbiAc?= =?us-ascii?q?OvjoBAQEBAQEBAwEBAQEBAQEVBIYXgz99hDeEPAWNLjiJOwGFXYgKgWKNF4V3i?= =?us-ascii?q?FoBHgEBQoNlaogwfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,537,1449532800"; d="scan'208";a="245661486" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2016 19:22:53 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u24JMqL5021103 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Mar 2016 19:22:52 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 4 Mar 2016 13:22:52 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Fri, 4 Mar 2016 13:22:52 -0600 From: "Yingzhen Qu (yiqu)" To: Ladislav Lhotka , "Acee Lindem (acee)" , "'netmod@ietf.org'" Thread-Topic: [netmod] proposed change to ietf-routing Thread-Index: AQHRcJq0eRi+ZMnx6E2mqojm24lmhp9G2g4AgAFC+QCAANYngIAAu9EA///kwgA= Date: Fri, 4 Mar 2016 19:22:52 +0000 Message-ID: References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.123.122] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] proposed change to ietf-routing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:22:56 -0000 Hi Lada, For ECMP, we can actually define the next-hop as a list, so if there is only one element in the list it=B9s the simple next-hop case, and for ECMP there are multiple elements in the list. RIB is more complete by adding ECMP support. Thanks, Yingzhen On 3/4/16, 5:00 AM, "netmod on behalf of Ladislav Lhotka" wrote: >"Acee Lindem (acee)" writes: > >> Hi Lada,=20 >> >> On 3/3/16, 8:01 AM, "Ladislav Lhotka" wrote: >> >>>"Acee Lindem (acee)" writes: >>> >>>> Hi Lada, NETMOD WG members, >>>> >>>> There are actually a number of changes that we would like to >>>> see in the ietf-routing model: >>>> >>>> - Remove routing-instances since ietf-routing since it will be >>>> =B3mounted=B2 at different points in the device hierarchy dependent >>>> on the device requirements. >>> >>>Agreed. >>> >>>> >>>> - Collapse it into one module supporting different address families >>>> rather 3 modules (base, IPv4, and IPv6). >>> >>>This is possible, but we would have to introduce a mechanism for >>>implementations supporting only one of them. It seems to me that it is >>>easier to select modules for base + any combination of address families, >>>and each family module inserts appropriate stuff to right places - and >>>there is quite a bunch of them. What you are proposing probably means >>>the >>>(single) module would have if-features or whens in all those places. >> >> Are there planned implementations required YANG models where only IPv4 >>or >> IPv6 are supported? Maybe way off in the future, when you and I are both >> sitting on a beach drinking beer there will be IPv6 only products but I >> don=B9t see it happening soon. >> > >Maybe some experts in the embedded area could comment on this, but I >believe in both 6LoWPAN and ZigBee IPv6-only networks are commonplace. > >> >> >>> >>>> >>>> - Remove the ND (RFC 4861) Router Advertisement protocol since it >>>> doesn=B9t need to be here. >>> >>>Well, RFC 4861 says: "A router MUST allow for the following conceptual >>>variables to be configured by system management." >>> >>>So I don't think they can be considered optional. We could perhaps move >>>them to a submodule so that they don't clutter the main module. >> >> I don=B9t disagree - but why are they grouped with the main RIB and infr= a >> draft? Router Advertisement should be with the other RFC 4861 protocols. >> It is out of place here. > >The idea is that any device that implements ietf-routing is required to >support these configuration variables, which is what 4861 says. With a >mechanism like Andy's packages we would have more flexibility, but for >the time being the best solution seems to be to move RA stuff to a >submodule. > >> >> >> >>> >>>> >>>> - Support at least the next hop enhancements in >>>> https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-00 >>> >>>They can be added via augments, and many potential users of the routing >>>module (hosts and simple routers) don't support them. >> >> Are there hosts that don=B9t support at least ECMP? > >I am not sure. If there is consensus that ECMP is really ubiquitous, >then we can add it. > >> >>> >>>> >>>> - Include at least ECMP in the static route configuration. >>> >>>Same as in the previous case: ietf-routing provides a choice node for >>>next-hops in both RIBs and static routes, and ECMP is explicitly >>>mentioned as a candidate for augmentation. Why is it such a big a >>>problem? >> >> It is not but as long as we are changing the model, we might as well >> handle the predominant use cases. > >My concern is that other groups may come up with their favourite >cases. Any new stuff increases the likelihood that bugs or inadequacies >will be discovered in the module after it is published, but then it will >be a problem due to the draconian module update rules. So I'd prefer to >keep this module really skinny. > >> >> >>> >>>> >>>> - Structure consistent with the operational state recommendation. >>>> Even w/o having the final recommendation, this model seems to >>>> branch between config and state at way too high a level. >>> >>>Could you outline the concrete changes that you propose here? The most >>>significant part of state data in this module is the list of RIBs, and I >>>don't see any way how it can be bundled with configuration somewhere >>>deeper in the hierarchy. >> >> I guess we will discuss this in upstate call next week. However, no >>matter >> what solution we come up with, it seems keeping the derived state closer >> to intended/applied config is better. > >OK. > >Lada > >> >> Thanks,=20 >> Acee=20 >> >> >>> >>>Lada >>> >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>> On 2/26/16, 8:36 AM, "netmod on behalf of Ladislav Lhotka" >>>> wrote: >>>> >>>>>Hi, >>>>> >>>>>as a part of synchronization of the routing data models that are being >>>>>developed by the NETMOD and RTG working groups, the authors of >>>>>draft-ietf-netmod-routing-cfg propose to remove the routing-instance >>>>>level in the data hierarchy, and leave it to structural-mount/YSDL to >>>>>provide a top level structure. >>>>> >>>>>Schematically, the configuration and state data subtrees of >>>>>ietf-routing >>>>>would be reduced to something like this: >>>>> >>>>>module: ietf-routing >>>>> +--ro routing-state >>>>> | +--ro router-id? yang:dotted-quad >>>>> | +--ro interfaces >>>>> | | +--ro interface* if:interface-state-ref >>>>> | +--ro routing-protocols >>>>> | | +--ro routing-protocol* [type name] >>>>> | | ... >>>>> | +--ro ribs >>>>> | +--ro rib* [name] >>>>> | ... >>>>> +--rw routing >>>>> +--rw router-id? yang:dotted-quad >>>>> +--rw description? string >>>>> +--rw routing-protocols >>>>> | +--rw routing-protocol* [type name] >>>>> | ... >>>>> +--rw ribs >>>>> +--rw rib* [name] >>>>> ... >>>>> >>>>>Are there any objections to this change? >>>>> >>>>>Thanks, >>>>> >>>>>Acee and Lada >>>>>=20 >>>>>-- >>>>>Ladislav Lhotka, CZ.NIC Labs >>>>>PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>netmod mailing list >>>>>netmod@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/netmod >>>> >>> >>>--=20 >>>Ladislav Lhotka, CZ.NIC Labs >>>PGP Key ID: E74E8C0C >> > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Mar 4 13:31:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273F11A902E for ; Fri, 4 Mar 2016 13:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvNGbRUhqy0J for ; Fri, 4 Mar 2016 13:31:37 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96C61A902D for ; Fri, 4 Mar 2016 13:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9476; q=dns/txt; s=iport; t=1457127096; x=1458336696; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6PDFEebLJyciMsJaBHvljACJS+DT50WB2dJpPSpd+9g=; b=JKi14WCyxb0zA0+BTuG2YGPgqt6/IHaoiIan6R/dtBaMjpd64kl2ZxHK FaemwNu1wn1Sa35IOuM8wKQsg9IuiNIu9fdePW78AelFXT5NB0BrL8dkC ZMJdX8H3xXIpfr1ii62U+Vp2p7BDywH0C6OhPwaiMP43hG+NADcLGMgck U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgBj/dlW/4cNJK1dgzpSbQa6NAENg?= =?us-ascii?q?WkXCoUkSgIcgRs4FAEBAQEBAQFkJ4RBAQEBAwEBAQEgETcDEAsCAQgYAgImAgI?= =?us-ascii?q?CJQsVEAIEARIbh38IDq9YjnoBAQEBAQEBAQIBAQEBAQEBARQEe4hbfYQ3gwKBO?= =?us-ascii?q?gWNLolzAYVdiAqBYo0XhXeIWgEeAQFCg2VqiDB+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,537,1449532800"; d="scan'208";a="245722614" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Mar 2016 21:31:35 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u24LVZF7014679 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Mar 2016 21:31:35 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 4 Mar 2016 15:31:34 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Fri, 4 Mar 2016 15:31:34 -0600 From: "Acee Lindem (acee)" To: Ladislav Lhotka , NETMOD Working Group Thread-Topic: [netmod] proposed change to ietf-routing Thread-Index: AQHRcJq0RazNoMs9PkSzBYV8exAQ959GhjuAgAGWzACAAIJSAIABD6YAgAA7AYA= Date: Fri, 4 Mar 2016 21:31:34 +0000 Message-ID: References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> In-Reply-To: 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.199] Content-Type: text/plain; charset="utf-8" Content-ID: <9BEB10E0A2FFD04BB1B568204CD89CAB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] proposed change to ietf-routing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 21:31:39 -0000 SGkgTGFkYSwgDQoNCk9uIDMvNC8xNiwgODowMCBBTSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3Rr YUBuaWMuY3o+IHdyb3RlOg0KDQo+IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29t PiB3cml0ZXM6DQo+DQo+PiBIaSBMYWRhLCANCj4+DQo+PiBPbiAzLzMvMTYsIDg6MDEgQU0sICJM YWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4+DQo+Pj4iQWNlZSBMaW5k ZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyaXRlczoNCj4+Pg0KPj4+PiBIaSBMYWRhLCBO RVRNT0QgV0cgbWVtYmVycywNCj4+Pj4NCj4+Pj4gVGhlcmUgYXJlIGFjdHVhbGx5IGEgbnVtYmVy IG9mIGNoYW5nZXMgdGhhdCB3ZSB3b3VsZCBsaWtlIHRvDQo+Pj4+IHNlZSBpbiB0aGUgaWV0Zi1y b3V0aW5nIG1vZGVsOg0KPj4+Pg0KPj4+PiAtIFJlbW92ZSByb3V0aW5nLWluc3RhbmNlcyBzaW5j ZSBpZXRmLXJvdXRpbmcgc2luY2UgaXQgd2lsbCBiZQ0KPj4+PiAgIOKAnG1vdW50ZWTigJ0gYXQg ZGlmZmVyZW50IHBvaW50cyBpbiB0aGUgZGV2aWNlIGhpZXJhcmNoeSBkZXBlbmRlbnQNCj4+Pj4g ICBvbiB0aGUgZGV2aWNlIHJlcXVpcmVtZW50cy4NCj4+Pg0KPj4+QWdyZWVkLg0KPj4+DQo+Pj4+ DQo+Pj4+IC0gQ29sbGFwc2UgaXQgaW50byBvbmUgbW9kdWxlIHN1cHBvcnRpbmcgZGlmZmVyZW50 IGFkZHJlc3MgZmFtaWxpZXMNCj4+Pj4gICByYXRoZXIgMyBtb2R1bGVzIChiYXNlLCBJUHY0LCBh bmQgSVB2NikuDQo+Pj4NCj4+PlRoaXMgaXMgcG9zc2libGUsIGJ1dCB3ZSB3b3VsZCBoYXZlIHRv IGludHJvZHVjZSBhIG1lY2hhbmlzbSBmb3INCj4+PmltcGxlbWVudGF0aW9ucyBzdXBwb3J0aW5n IG9ubHkgb25lIG9mIHRoZW0uIEl0IHNlZW1zIHRvIG1lIHRoYXQgaXQgaXMNCj4+PmVhc2llciB0 byBzZWxlY3QgbW9kdWxlcyBmb3IgYmFzZSArIGFueSBjb21iaW5hdGlvbiBvZiBhZGRyZXNzIGZh bWlsaWVzLA0KPj4+YW5kIGVhY2ggZmFtaWx5IG1vZHVsZSBpbnNlcnRzIGFwcHJvcHJpYXRlIHN0 dWZmIHRvIHJpZ2h0IHBsYWNlcyAtIGFuZA0KPj4+dGhlcmUgaXMgcXVpdGUgYSBidW5jaCBvZiB0 aGVtLiBXaGF0IHlvdSBhcmUgcHJvcG9zaW5nIHByb2JhYmx5IG1lYW5zDQo+Pj50aGUNCj4+Pihz aW5nbGUpIG1vZHVsZSB3b3VsZCBoYXZlIGlmLWZlYXR1cmVzIG9yIHdoZW5zIGluIGFsbCB0aG9z ZSBwbGFjZXMuDQo+Pg0KPj4gQXJlIHRoZXJlIHBsYW5uZWQgaW1wbGVtZW50YXRpb25zIHJlcXVp cmVkIFlBTkcgbW9kZWxzIHdoZXJlIG9ubHkgSVB2NA0KPj5vcg0KPj4gSVB2NiBhcmUgc3VwcG9y dGVkPyBNYXliZSB3YXkgb2ZmIGluIHRoZSBmdXR1cmUsIHdoZW4geW91IGFuZCBJIGFyZSBib3Ro DQo+PiBzaXR0aW5nIG9uIGEgYmVhY2ggZHJpbmtpbmcgYmVlciB0aGVyZSB3aWxsIGJlIElQdjYg b25seSBwcm9kdWN0cyBidXQgSQ0KPj4gZG9u4oCZdCBzZWUgaXQgaGFwcGVuaW5nIHNvb24uDQo+ Pg0KPg0KPk1heWJlIHNvbWUgZXhwZXJ0cyBpbiB0aGUgZW1iZWRkZWQgYXJlYSBjb3VsZCBjb21t ZW50IG9uIHRoaXMsIGJ1dCBJDQo+YmVsaWV2ZSBpbiBib3RoIDZMb1dQQU4gYW5kIFppZ0JlZSBJ UHY2LW9ubHkgbmV0d29ya3MgYXJlIGNvbW1vbnBsYWNlLg0KDQpPa2F5IC0gSeKAmXZlIGFsc28g aGVhcmQgcmVxdWlyZW1lbnRzIGZyb20gYW4gU1AgZm9yIGFjY2VzcyBkZXZpY2VzIHdpdGgNCm9u bHkgSVB2Ni4gSG93ZXZlciwgaXMgYSBzZXBhcmF0ZSBtb2R1bGUgcmVxdWlyZWQgZm9yIHRoaXM/ DQppZXRmLXlhbmctdHlwZXMgaGFzIHRoZSB0eXBlIGlwLWFkZHJlc3Mgc3VwcG9ydGluZyBib3Ro IEFGcy4gRG9lcw0Kc3VwcG9ydGluZyBvbmUgb3IgdGhlIG90aGVyIEFGIG9yIGJvdGggbmVlZCB0 byBiZSBlbmZvcmNlZCB3aXRoIHNlcGFyYXRlDQptb2R1bGVzPyBGb3IgSVB2NCwgd2UgYXJlIGdv aW5nIHRvIG5lZWQgdG8gc3VwcG9ydCBJUHY2IG5leHQtaG9wcyAocmVmZXINCnRvIFJGQyA1NTQ5 KS4gIA0KDQoNCj4NCj4+DQo+Pg0KPj4+DQo+Pj4+DQo+Pj4+IC0gUmVtb3ZlIHRoZSBORCAoUkZD IDQ4NjEpIFJvdXRlciBBZHZlcnRpc2VtZW50IHByb3RvY29sIHNpbmNlIGl0DQo+Pj4+ICAgZG9l c27igJl0IG5lZWQgdG8gYmUgaGVyZS4NCj4+Pg0KPj4+V2VsbCwgUkZDIDQ4NjEgc2F5czogIkEg cm91dGVyIE1VU1QgYWxsb3cgZm9yIHRoZSBmb2xsb3dpbmcgY29uY2VwdHVhbA0KPj4+dmFyaWFi bGVzIHRvIGJlIGNvbmZpZ3VyZWQgYnkgc3lzdGVtIG1hbmFnZW1lbnQuIg0KPj4+DQo+Pj5TbyBJ IGRvbid0IHRoaW5rIHRoZXkgY2FuIGJlIGNvbnNpZGVyZWQgb3B0aW9uYWwuIFdlIGNvdWxkIHBl cmhhcHMgbW92ZQ0KPj4+dGhlbSB0byBhIHN1Ym1vZHVsZSBzbyB0aGF0IHRoZXkgZG9uJ3QgY2x1 dHRlciB0aGUgbWFpbiBtb2R1bGUuDQo+Pg0KPj4gSSBkb27igJl0IGRpc2FncmVlIC0gYnV0IHdo eSBhcmUgdGhleSBncm91cGVkIHdpdGggdGhlIG1haW4gUklCIGFuZCBpbmZyYQ0KPj4gZHJhZnQ/ IFJvdXRlciBBZHZlcnRpc2VtZW50IHNob3VsZCBiZSB3aXRoIHRoZSBvdGhlciBSRkMgNDg2MSBw cm90b2NvbHMuDQo+PiBJdCBpcyBvdXQgb2YgcGxhY2UgaGVyZS4NCj4NCj5UaGUgaWRlYSBpcyB0 aGF0IGFueSBkZXZpY2UgdGhhdCBpbXBsZW1lbnRzIGlldGYtcm91dGluZyBpcyByZXF1aXJlZCB0 bw0KPnN1cHBvcnQgdGhlc2UgY29uZmlndXJhdGlvbiB2YXJpYWJsZXMsIHdoaWNoIGlzIHdoYXQg NDg2MSBzYXlzLg0KDQpCdXQgaXQgc2F5cyBub3RoaW5nIGFib3V0IHRoZSBvcmdhbml6YXRpb24g b2YgdGhlIFlBTkcgbW9kdWxlcyA7XikNCg0KPiBXaXRoIGENCj5tZWNoYW5pc20gbGlrZSBBbmR5 J3MgcGFja2FnZXMgd2Ugd291bGQgaGF2ZSBtb3JlIGZsZXhpYmlsaXR5LCBidXQgZm9yDQo+dGhl IHRpbWUgYmVpbmcgdGhlIGJlc3Qgc29sdXRpb24gc2VlbXMgdG8gYmUgdG8gbW92ZSBSQSBzdHVm ZiB0byBhDQo+c3VibW9kdWxlLg0KDQpXaHkgd291bGRu4oCZdCBSQSBiZSBpbiBhIHNlcGFyYXRl IGRyYWZ0IHdpdGggYWxsIHRoZSBvdGhlciBSRkMgNDg2MQ0KcHJvdG9jb2xzPyANCg0KDQoNCj4N Cj4+DQo+Pg0KPj4NCj4+Pg0KPj4+Pg0KPj4+PiAtIFN1cHBvcnQgYXQgbGVhc3QgdGhlIG5leHQg aG9wIGVuaGFuY2VtZW50cyBpbg0KPj4+PiAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1hY2VlLXJ0Z3dnLXlhbmctcmliLWV4dGVuZC0wMA0KPj4+DQo+Pj5UaGV5IGNhbiBiZSBh ZGRlZCB2aWEgYXVnbWVudHMsIGFuZCBtYW55IHBvdGVudGlhbCB1c2VycyBvZiB0aGUgcm91dGlu Zw0KPj4+bW9kdWxlIChob3N0cyBhbmQgc2ltcGxlIHJvdXRlcnMpIGRvbid0IHN1cHBvcnQgdGhl bS4NCj4+DQo+PiBBcmUgdGhlcmUgaG9zdHMgdGhhdCBkb27igJl0IHN1cHBvcnQgYXQgbGVhc3Qg RUNNUD8NCj4NCj5JIGFtIG5vdCBzdXJlLiBJZiB0aGVyZSBpcyBjb25zZW5zdXMgdGhhdCBFQ01Q IGlzIHJlYWxseSB1YmlxdWl0b3VzLA0KPnRoZW4gd2UgY2FuIGFkZCBpdC4NCj4NCj4+DQo+Pj4N Cj4+Pj4NCj4+Pj4gLSBJbmNsdWRlIGF0IGxlYXN0IEVDTVAgaW4gdGhlIHN0YXRpYyByb3V0ZSBj b25maWd1cmF0aW9uLg0KPj4+DQo+Pj5TYW1lIGFzIGluIHRoZSBwcmV2aW91cyBjYXNlOiBpZXRm LXJvdXRpbmcgcHJvdmlkZXMgYSBjaG9pY2Ugbm9kZSBmb3INCj4+Pm5leHQtaG9wcyBpbiBib3Ro IFJJQnMgYW5kIHN0YXRpYyByb3V0ZXMsIGFuZCBFQ01QIGlzIGV4cGxpY2l0bHkNCj4+Pm1lbnRp b25lZCBhcyBhIGNhbmRpZGF0ZSBmb3IgYXVnbWVudGF0aW9uLiBXaHkgaXMgaXQgc3VjaCBhIGJp ZyBhDQo+Pj5wcm9ibGVtPw0KPj4NCj4+IEl0IGlzIG5vdCBidXQgYXMgbG9uZyBhcyB3ZSBhcmUg Y2hhbmdpbmcgdGhlIG1vZGVsLCB3ZSBtaWdodCBhcyB3ZWxsDQo+PiBoYW5kbGUgdGhlIHByZWRv bWluYW50IHVzZSBjYXNlcy4NCj4NCj5NeSBjb25jZXJuIGlzIHRoYXQgb3RoZXIgZ3JvdXBzIG1h eSBjb21lIHVwIHdpdGggdGhlaXIgZmF2b3VyaXRlDQo+Y2FzZXMuIEFueSBuZXcgc3R1ZmYgaW5j cmVhc2VzIHRoZSBsaWtlbGlob29kIHRoYXQgYnVncyBvciBpbmFkZXF1YWNpZXMNCj53aWxsIGJl IGRpc2NvdmVyZWQgaW4gdGhlIG1vZHVsZSBhZnRlciBpdCBpcyBwdWJsaXNoZWQsIGJ1dCB0aGVu IGl0IHdpbGwNCj5iZSBhIHByb2JsZW0gZHVlIHRvIHRoZSBkcmFjb25pYW4gbW9kdWxlIHVwZGF0 ZSBydWxlcy4gU28gSSdkIHByZWZlciB0bw0KPmtlZXAgdGhpcyBtb2R1bGUgcmVhbGx5IHNraW5u eS4NCj4NCj4+DQo+Pg0KPj4+DQo+Pj4+DQo+Pj4+IC0gU3RydWN0dXJlIGNvbnNpc3RlbnQgd2l0 aCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgcmVjb21tZW5kYXRpb24uDQo+Pj4+ICAgRXZlbiB3L28g aGF2aW5nIHRoZSBmaW5hbCByZWNvbW1lbmRhdGlvbiwgdGhpcyBtb2RlbCBzZWVtcyB0bw0KPj4+ PiAgIGJyYW5jaCBiZXR3ZWVuIGNvbmZpZyBhbmQgc3RhdGUgYXQgd2F5IHRvbyBoaWdoIGEgbGV2 ZWwuDQo+Pj4NCj4+PkNvdWxkIHlvdSBvdXRsaW5lIHRoZSBjb25jcmV0ZSBjaGFuZ2VzIHRoYXQg eW91IHByb3Bvc2UgaGVyZT8gVGhlIG1vc3QNCj4+PnNpZ25pZmljYW50IHBhcnQgb2Ygc3RhdGUg ZGF0YSBpbiB0aGlzIG1vZHVsZSBpcyB0aGUgbGlzdCBvZiBSSUJzLCBhbmQgSQ0KPj4+ZG9uJ3Qg c2VlIGFueSB3YXkgaG93IGl0IGNhbiBiZSBidW5kbGVkIHdpdGggY29uZmlndXJhdGlvbiBzb21l d2hlcmUNCj4+PmRlZXBlciBpbiB0aGUgaGllcmFyY2h5Lg0KPj4NCj4+IEkgZ3Vlc3Mgd2Ugd2ls bCBkaXNjdXNzIHRoaXMgaW4gdXBzdGF0ZSBjYWxsIG5leHQgd2Vlay4gSG93ZXZlciwgbm8NCj4+ bWF0dGVyDQo+PiB3aGF0IHNvbHV0aW9uIHdlIGNvbWUgdXAgd2l0aCwgaXQgc2VlbXMga2VlcGlu ZyB0aGUgZGVyaXZlZCBzdGF0ZSBjbG9zZXINCj4+IHRvIGludGVuZGVkL2FwcGxpZWQgY29uZmln IGlzIGJldHRlci4NCj4NCj5PSy4NCj4NCj5MYWRhDQo+DQo+Pg0KPj4gVGhhbmtzLCANCj4+IEFj ZWUgDQo+Pg0KPj4NCj4+Pg0KPj4+TGFkYQ0KPj4+DQo+Pj4+DQo+Pj4+IFRoYW5rcywNCj4+Pj4g QWNlZQ0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiAyLzI2LzE2LCA4OjM2IEFNLCAibmV0bW9kIG9uIGJl aGFsZiBvZiBMYWRpc2xhdiBMaG90a2EiDQo+Pj4+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgbGhvdGthQG5pYy5jej4gd3JvdGU6DQo+Pj4+DQo+Pj4+PkhpLA0KPj4+Pj4N Cj4+Pj4+YXMgYSBwYXJ0IG9mIHN5bmNocm9uaXphdGlvbiBvZiB0aGUgcm91dGluZyBkYXRhIG1v ZGVscyB0aGF0IGFyZSBiZWluZw0KPj4+Pj5kZXZlbG9wZWQgYnkgdGhlIE5FVE1PRCBhbmQgUlRH IHdvcmtpbmcgZ3JvdXBzLCB0aGUgYXV0aG9ycyBvZg0KPj4+Pj5kcmFmdC1pZXRmLW5ldG1vZC1y b3V0aW5nLWNmZyBwcm9wb3NlIHRvIHJlbW92ZSB0aGUgcm91dGluZy1pbnN0YW5jZQ0KPj4+Pj5s ZXZlbCBpbiB0aGUgZGF0YSBoaWVyYXJjaHksIGFuZCBsZWF2ZSBpdCB0byBzdHJ1Y3R1cmFsLW1v dW50L1lTREwgdG8NCj4+Pj4+cHJvdmlkZSBhIHRvcCBsZXZlbCBzdHJ1Y3R1cmUuDQo+Pj4+Pg0K Pj4+Pj5TY2hlbWF0aWNhbGx5LCB0aGUgY29uZmlndXJhdGlvbiBhbmQgc3RhdGUgZGF0YSBzdWJ0 cmVlcyBvZg0KPj4+Pj5pZXRmLXJvdXRpbmcNCj4+Pj4+d291bGQgYmUgcmVkdWNlZCB0byBzb21l dGhpbmcgbGlrZSB0aGlzOg0KPj4+Pj4NCj4+Pj4+bW9kdWxlOiBpZXRmLXJvdXRpbmcNCj4+Pj4+ ICAgKy0tcm8gcm91dGluZy1zdGF0ZQ0KPj4+Pj4gICB8ICArLS1ybyByb3V0ZXItaWQ/ICAgICAg ICAgICB5YW5nOmRvdHRlZC1xdWFkDQo+Pj4+PiAgIHwgICstLXJvIGludGVyZmFjZXMNCj4+Pj4+ ICAgfCAgfCAgKy0tcm8gaW50ZXJmYWNlKiAgIGlmOmludGVyZmFjZS1zdGF0ZS1yZWYNCj4+Pj4+ ICAgfCAgKy0tcm8gcm91dGluZy1wcm90b2NvbHMNCj4+Pj4+ICAgfCAgfCAgKy0tcm8gcm91dGlu Zy1wcm90b2NvbCogW3R5cGUgbmFtZV0NCj4+Pj4+ICAgfCAgfCAgICAgLi4uDQo+Pj4+PiAgIHwg ICstLXJvIHJpYnMNCj4+Pj4+ICAgfCAgICAgKy0tcm8gcmliKiBbbmFtZV0NCj4+Pj4+ICAgfCAg ICAgICAgLi4uDQo+Pj4+PiAgICstLXJ3IHJvdXRpbmcNCj4+Pj4+ICAgICAgKy0tcncgcm91dGVy LWlkPyAgICAgICAgICAgeWFuZzpkb3R0ZWQtcXVhZA0KPj4+Pj4gICAgICArLS1ydyBkZXNjcmlw dGlvbj8gICAgICAgICBzdHJpbmcNCj4+Pj4+ICAgICAgKy0tcncgcm91dGluZy1wcm90b2NvbHMN Cj4+Pj4+ICAgICAgfCAgKy0tcncgcm91dGluZy1wcm90b2NvbCogW3R5cGUgbmFtZV0NCj4+Pj4+ ICAgICAgfCAgICAgLi4uDQo+Pj4+PiAgICAgICstLXJ3IHJpYnMNCj4+Pj4+ICAgICAgICAgKy0t cncgcmliKiBbbmFtZV0NCj4+Pj4+CSAgICAuLi4NCj4+Pj4+DQo+Pj4+PkFyZSB0aGVyZSBhbnkg b2JqZWN0aW9ucyB0byB0aGlzIGNoYW5nZT8NCj4+Pj4+DQo+Pj4+PlRoYW5rcywNCj4+Pj4+DQo+ Pj4+PkFjZWUgYW5kIExhZGENCj4+Pj4+IA0KPj4+Pj4tLQ0KPj4+Pj5MYWRpc2xhdiBMaG90a2Es IENaLk5JQyBMYWJzDQo+Pj4+PlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+DQo+Pj4+Pg0KPj4+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4+Pm5ldG1vZEBpZXRmLm9yZw0K Pj4+Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4+Pg0K Pj4+DQo+Pj4tLSANCj4+PkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+PlBHUCBLZXkg SUQ6IEU3NEU4QzBDDQo+Pg0KPg0KPi0tIA0KPkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMN Cj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KDQo= From nobody Sat Mar 5 00:44:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C261A88C6 for ; Sat, 5 Mar 2016 00:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_2I6l2TomcJ for ; Sat, 5 Mar 2016 00:44:46 -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 A522F1A888F for ; Sat, 5 Mar 2016 00:44: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 CF9AF18F8; Sat, 5 Mar 2016 09:44:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gTUU6IlIt_Oj; Sat, 5 Mar 2016 09:44:17 +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; Sat, 5 Mar 2016 09:44:43 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E2D520038; Sat, 5 Mar 2016 09:44: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 dhctKGi17Tad; Sat, 5 Mar 2016 09:44: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 5DC8520037; Sat, 5 Mar 2016 09:44:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1E8E53A04EF6; Sat, 5 Mar 2016 09:44:40 +0100 (CET) Date: Sat, 5 Mar 2016 09:44:40 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka , Lou Berger , netmod WG Message-ID: <20160305084440.GA37641@elstar.local> Mail-Followup-To: Ladislav Lhotka , Lou Berger , netmod WG References: <56D4ACA6.40208@labn.net> <20160303142124.GA33703@elstar.local> <20160303153857.GA33953@elstar.local> <20160303165354.GA34155@elstar.local> <20160304123353.GA35973@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160304123353.GA35973@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] Moving the WG discussion on mount forward X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 05 Mar 2016 08:44:48 -0000 On Fri, Mar 04, 2016 at 01:33:53PM +0100, Juergen Schoenwaelder wrote: > On Fri, Mar 04, 2016 at 01:22:06PM +0100, Ladislav Lhotka wrote: > > Juergen Schoenwaelder writes: > > > > > On Thu, Mar 03, 2016 at 05:24:08PM +0100, Ladislav Lhotka wrote: > > >> > > >> No. Data that aren't in the schema are clearly invalid. > > >> > > > > > > This is defined where? Anyway, if this is the case, then both mount > > > > I would say that if sending arbitrary rubbish along with YANG-defined > > data isn't forbidden, then it is a bug in the spec. Maybe I am spoiled > > by XML schema languages, but the idea of "anyxml everywhere" is > > quite disturbing. > > > > > proposals are broken since both do not define the data mounted on a > > > mount point in the schema. > > > > Both proposals define it, I believe: structural mount in the > > "mount-point" list, and YSDL in the "schema" list. > > > > But it is not defined in the _schema_. So for an old client, the > mounted data is going to be 'arbitrary rubbish' along with > YANG-defined data. > To legalize 'arbitrary rubbish' in the schema, one could define the mount point as anydata. That is, instead of using a new mount-point extension as proposed in [1], one would write: container logical-devices { list logical-device { key name; leaf name { type string; } anydata logical-device { yangmnt:mount-point; } } } (This example corresponds to the example in Appendix A in [1].) /js [1] draft-bjorklund-netmod-structural-mount-02.txt -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Mar 5 09:24:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326A41B349D for ; Sat, 5 Mar 2016 09:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDQzVSTcikQA for ; Sat, 5 Mar 2016 09:24:11 -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 CE1C61B349C for ; Sat, 5 Mar 2016 09:24:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7093; q=dns/txt; s=iport; t=1457198650; x=1458408250; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=0qPGlsueXjyCFpM/owOJ6vZ+8zFuHrixLyCmMedE8zs=; b=lkFILFbcNK+eEHW8kdEQbYWIvkKu2KhcUdmR1YVuNFv4qUbYYWHb8ory J48/NlAYTPYDznTL/usWhdiJZbHJ/REFxJV0r8FGrAiNkOiefDk0So+wG TKcLI5sux2L81931GnJrd5PrAsJYCyvoKaH65bAyuTXHYvsB8SnRnSezm E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBAASFdtW/xbLJq1dhAxtuC2ECiGFb?= =?us-ascii?q?gKBbwEBAQEBAWUnhEEBAQEEcAgREgoBAgECChYPCQMCAQIBNwYIBg0GAgEBiB4?= =?us-ascii?q?OvykBAQEBAQEBAQEBAQEBAQEBAQEYhheJF4QaBZcqhWOICoIuhnuFUY5VYoNlO?= =?us-ascii?q?y4BAQEBiAMlgRQBAQE?= X-IronPort-AV: E=Sophos;i="5.22,541,1449532800"; d="scan'208,217";a="635966753" 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; 05 Mar 2016 17:24:08 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u25HO7dA005992 for ; Sat, 5 Mar 2016 17:24:08 GMT References: To: NETMOD Working Group From: Benoit Claise X-Forwarded-Message-Id: Message-ID: <56DB1637.7000601@cisco.com> Date: Sat, 5 Mar 2016 18:24:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000308050800080803070602" Archived-At: Subject: [netmod] YANG check in idintis (was: New datatracker release: v6.16.0) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 17:24:13 -0000 This is a multi-part message in MIME format. --------------000308050800080803070602 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, Now, idnits uses xym.py (to extract the YANG data models from the IETF drafts) and pyang (to validate them). And there is also http://www.yangvalidator.com/ And also http://www.claise.be/IETFYANGPageCompilation.html All this to help you with your YANG data models. Regards, Benoit -------- Forwarded Message -------- Subject: New datatracker release: v6.16.0 Date: Sat, 05 Mar 2016 07:02:15 -0800 From: Henrik Levkowetz To: codesprints@ietf.org, iesg@ietf.org, wgchairs@ietf.org Hi, This is an automatic notification about a new datatracker release, v6.16.0, generated when running the mkrelease script. Release notes: ietfdb (6.16.0) ietf; urgency=medium **Yang validation of draft submissions** This release adds Yang validation of submitted drafts which contain Yang code, through a new plug-in architecture which makes it easy to addo other submission-time checkers and validators in the future. It also contains a few unrelated fixes and tweaks, as follows: * Fixed pyflakes complaints introduced with pyflakes 1.1.0 * Refactored draft submission checks so that new checkers can be slotted in through a configuration in settings.py. Refactored the calling of idnits to use the new API, and added a pyang validation check. * Added new entries to requirements.txt: pyang, xym, and jsonfield. Sorted the list. * Merged in [10880] from rjsparks@nostrum.com: Only show the 'Upload new revision' button when the view will actually let you upload a new revision. * Merged in [10862] from rjsparks@nostrum.com: Group concluded working groups by area. Fixes #1670. * Merged in [10839] from housley@vigilsec.com: Added test for proper eneration of the approval message with and without an RFC Editor Note. Tweaked RFC Editor note display template. -- Henrik Levkowetz 05 Mar 2016 06:27:10 -0800 The new version is available for installation through SVN checkout, with 'svn checkout https://svn.tools.ietf.org/svn/tools/ietfdb/tags/6.16.0' For development, check out the new development version instead: 'svn checkout https://svn.tools.ietf.org/svn/tools/ietfdb/tags/dev/6.16.1.dev0' Regards, Henrik (via the mkrelease script) . --------------000308050800080803070602 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Dear all,

Now, idnits uses xym.py (to extract the YANG data models from the IETF drafts) and pyang (to validate them).
And there is also http://www.yangvalidator.com/
And also http://www.claise.be/IETFYANGPageCompilation.html

All this to help you with your YANG data models.

Regards, Benoit


-------- Forwarded Message --------
Subject: New datatracker release: v6.16.0
Date: Sat, 05 Mar 2016 07:02:15 -0800
From: Henrik Levkowetz <henrik@levkowetz.com>
To: codesprints@ietf.org, iesg@ietf.org, wgchairs@ietf.org 


Hi,

This is an automatic notification about a new datatracker release, 
v6.16.0, generated when running the mkrelease script.

Release notes:

ietfdb (6.16.0) ietf; urgency=medium

  **Yang validation of draft submissions**

  This release adds Yang validation of submitted drafts which contain
  Yang code, through a new plug-in architecture which makes it easy to 
  addo other submission-time checkers and validators in the future.

  It also contains a few unrelated fixes and tweaks, as follows:

  * Fixed pyflakes complaints introduced with pyflakes 1.1.0

  * Refactored draft submission checks so that new checkers can be slotted 
    in through a configuration in settings.py.  Refactored the calling of 
    idnits to use the new API, and added a pyang validation check.

  * Added new entries to requirements.txt: pyang, xym, and jsonfield.  Sorted
    the list.

  * Merged in [10880] from rjsparks@nostrum.com:
    Only show the 'Upload new revision' button when the view will actually
    let you upload a new revision.  

  * Merged in [10862] from rjsparks@nostrum.com:
    Group concluded working groups by area. Fixes #1670.  

  * Merged in [10839] from housley@vigilsec.com:
    Added test for proper eneration of the approval message with and without
    an RFC Editor Note.  Tweaked RFC Editor note display template.

 -- Henrik Levkowetz <henrik@levkowetz.com>  05 Mar 2016 06:27:10 -0800

The new version is available for installation through SVN checkout, with
  'svn checkout https://svn.tools.ietf.org/svn/tools/ietfdb/tags/6.16.0'

For development, check out the new development version instead:
  'svn checkout https://svn.tools.ietf.org/svn/tools/ietfdb/tags/dev/6.16.1.dev0'

Regards,

	Henrik
	(via the mkrelease script)

.


--------------000308050800080803070602-- From nobody Mon Mar 7 00:31:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984BE1B37AA for ; Mon, 7 Mar 2016 00:31: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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w_s1S62oTey for ; Mon, 7 Mar 2016 00:31:20 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BFFC01B37A9 for ; Mon, 7 Mar 2016 00:31:20 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 99D071AE0308; Mon, 7 Mar 2016 09:31:18 +0100 (CET) Date: Mon, 07 Mar 2016 09:31:23 +0100 (CET) Message-Id: <20160307.093123.241897337766320049.mbj@tail-f.com> To: lhotka@nic.cz 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] YANG 1.1 conformance announcement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 08:31:22 -0000 Ladislav Lhotka wrote: > Andy Bierman writes: > > > Hi, > > > > Buried in the many NETCONF-specific sections is a requirement to > > announce the YANG library info. However this info is incomplete > > and sec. 5.6.5 needs to be changed because it assumes there is only > > 1 revision of the ietf-yang-library module possible. The client cannot > > read the read the library to find out which revision of the library template > > to use. > > > > This is because yang-library is really meta-data and requires special > treatment even if we pretend it is just another part of the data tree. > > > > > > > > > 5.6.5. Announcing Conformance Information in NETCONF > > > > This document defines the following mechanism for announcing > > conformance information. Other mechanisms may be defined by future > > specifications. > > > > A NETCONF server announces the modules it implements by implementing > > the YANG module "ietf-yang-library" defined in > > [I-D.ietf-netconf-yang-library], and listing all implemented modules > > in the "/modules-state/module" list. > > > > > > OLD: > > > > The server also advertises the following capability in the > > message (line-breaks and whitespaces are used for formatting reasons > > only): > > > > urn:ietf:params:netconf:capability:yang-library:1.0? > > module-set-id= > > > > The parameter "module-set-id" has the same value as the leaf > > "/modules-state/module-set-id" from "ietf-yang-library". This > > parameter MUST be present. > > > > NEW: > > > > The server also advertises the following capability in the > > message (line-breaks and whitespaces are used for formatting reasons > > only): > > > > urn:ietf:params:netconf:capability:yang-library:1.0? > > revision=&module-set-id= > > > > The parameter "revision" has the same value as the revision > > date of the "ietf-yang-library" implemented by the server. This > > parameter MUST be present. > > > > I agree. Yes, this is a good enhancement. I will apply this change. /martin > But what about RESTCONF? How can a client learn which revision of > yang-library data the server uses? > > Lada > > > > > The parameter "module-set-id" has the same value as the leaf > > "/modules-state/module-set-id" from "ietf-yang-library". This parameter > > MUST be present. > > > > > > > > Andy > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Mar 7 02:17:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8B31B3E07 for ; Mon, 7 Mar 2016 02:17:43 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTd2puYboMxU for ; Mon, 7 Mar 2016 02:17:42 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6B87E1B3E03 for ; Mon, 7 Mar 2016 02:17:41 -0800 (PST) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 46B671AE048D; Mon, 7 Mar 2016 11:17:39 +0100 (CET) Date: Mon, 07 Mar 2016 11:17:44 +0100 (CET) Message-Id: <20160307.111744.923704857824087878.mbj@tail-f.com> To: andy@yumaworks.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] typo in yang-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 10:17:43 -0000 Andy Bierman wrote: > Hi, > > IMO the YANG 1.1 draft should use a github issue tracker so > I don't have to send typo stuff to the list. > > The example on pg 48 has a wrong end tag > > > 10 > Thanks, now fixed. /martin From nobody Mon Mar 7 02:26:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BB91B3E37 for ; Mon, 7 Mar 2016 02:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQxYP9XLKAPk for ; Mon, 7 Mar 2016 02:26:40 -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 334171B3E34 for ; Mon, 7 Mar 2016 02:26:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F00A21986; Mon, 7 Mar 2016 11:26:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Wm0lzneOGufA; Mon, 7 Mar 2016 11:26: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; Mon, 7 Mar 2016 11:26:38 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 459C920039; Mon, 7 Mar 2016 11:26:38 +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 mBS7DruDFeXD; Mon, 7 Mar 2016 11:26:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 309FF20038; Mon, 7 Mar 2016 11:26:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 172C73A05D44; Mon, 7 Mar 2016 11:26:37 +0100 (CET) Date: Mon, 7 Mar 2016 11:26:36 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20160307102636.GA41749@elstar.local> Mail-Followup-To: netmod@ietf.org, Martin Bjorklund , balazs.lengyel@ericsson.com References: <56694FF2.1030108@ericsson.com> <56B87BD4.5060607@ericsson.com> <20160216.090033.283670312674076307.mbj@tail-f.com> <20160216114227.GC281@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160216114227.GC281@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] Fwd: Multiple deviations with same target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2016 10:26:41 -0000 On Tue, Feb 16, 2016 at 12:42:27PM +0100, Juergen Schoenwaelder wrote: > So perhaps the proposal is to add > > After applying all deviations announced by a server, in any order, > the resulting data model MUST still be valid. > > just before the beginning of section 7.20.3.1? I like to see whether we have consensus to add this clarifying sentence. I believe it documents something that we always assumed to be true but we did not write it down explicitly. If anyone disagrees with adding this clarification, please speak up now. /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 7 05:45:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACEA1B4117 for ; Mon, 7 Mar 2016 05:45:09 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRtA_mNKMJs1 for ; Mon, 7 Mar 2016 05:45:06 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D68581B410E for ; Mon, 7 Mar 2016 05:45:05 -0800 (PST) Received: from localhost (unknown [172.29.2.201]) by trail.lhotka.name (Postfix) with ESMTPSA id 73AE91CC035F; Mon, 7 Mar 2016 14:45:05 +0100 (CET) From: Ladislav Lhotka To: "Acee Lindem \(acee\)" , NETMOD Working Group In-Reply-To: References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 07 Mar 2016 14:45:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] proposed change to ietf-routing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 13:45:09 -0000 "Acee Lindem (acee)" writes: > Hi Lada,=20 > > On 3/4/16, 8:00 AM, "Ladislav Lhotka" wrote: > >>"Acee Lindem (acee)" writes: >> >>> Hi Lada,=20 >>> >>> On 3/3/16, 8:01 AM, "Ladislav Lhotka" wrote: >>> >>>>"Acee Lindem (acee)" writes: >>>> >>>>> Hi Lada, NETMOD WG members, >>>>> >>>>> There are actually a number of changes that we would like to >>>>> see in the ietf-routing model: >>>>> >>>>> - Remove routing-instances since ietf-routing since it will be >>>>> =E2=80=9Cmounted=E2=80=9D at different points in the device hierarc= hy dependent >>>>> on the device requirements. >>>> >>>>Agreed. >>>> >>>>> >>>>> - Collapse it into one module supporting different address families >>>>> rather 3 modules (base, IPv4, and IPv6). >>>> >>>>This is possible, but we would have to introduce a mechanism for >>>>implementations supporting only one of them. It seems to me that it is >>>>easier to select modules for base + any combination of address families, >>>>and each family module inserts appropriate stuff to right places - and >>>>there is quite a bunch of them. What you are proposing probably means >>>>the >>>>(single) module would have if-features or whens in all those places. >>> >>> Are there planned implementations required YANG models where only IPv4 >>>or >>> IPv6 are supported? Maybe way off in the future, when you and I are both >>> sitting on a beach drinking beer there will be IPv6 only products but I >>> don=E2=80=99t see it happening soon. >>> >> >>Maybe some experts in the embedded area could comment on this, but I >>believe in both 6LoWPAN and ZigBee IPv6-only networks are commonplace. > > Okay - I=E2=80=99ve also heard requirements from an SP for access devices= with > only IPv6. However, is a separate module required for this? An IPv6-only system should not have IPv4-related nodes in the schema. As I wrote, alternatives are (a) define features for individual address families (b) include configuration of address families, and then use "when" statements to control the schema. We also have to consider other families that may be added, even some that don't exist yet. > ietf-yang-types has the type ip-address supporting both AFs. Does > supporting one or the other AF or both need to be enforced with separate > modules? For IPv4, we are going to need to support IPv6 next-hops (refer > to RFC 5549).=20=20 > > >> >>> >>> >>>> >>>>> >>>>> - Remove the ND (RFC 4861) Router Advertisement protocol since it >>>>> doesn=E2=80=99t need to be here. >>>> >>>>Well, RFC 4861 says: "A router MUST allow for the following conceptual >>>>variables to be configured by system management." >>>> >>>>So I don't think they can be considered optional. We could perhaps move >>>>them to a submodule so that they don't clutter the main module. >>> >>> I don=E2=80=99t disagree - but why are they grouped with the main RIB a= nd infra >>> draft? Router Advertisement should be with the other RFC 4861 protocols. >>> It is out of place here. >> >>The idea is that any device that implements ietf-routing is required to >>support these configuration variables, which is what 4861 says. > > But it says nothing about the organization of the YANG modules ;^) No, but currently there is no way to say that if module X is implemented, t= hen module Y has to be implemented, too. > >> With a >>mechanism like Andy's packages we would have more flexibility, but for >>the time being the best solution seems to be to move RA stuff to a >>submodule. > > Why wouldn=E2=80=99t RA be in a separate draft with all the other RFC 4861 > protocols? It could, and we could hope that some mechanism will be established later f= or specifying module dependencies and prerequisites. It's IMO needed anyway. Lada > > > >> >>> >>> >>> >>>> >>>>> >>>>> - Support at least the next hop enhancements in >>>>> https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-00 >>>> >>>>They can be added via augments, and many potential users of the routing >>>>module (hosts and simple routers) don't support them. >>> >>> Are there hosts that don=E2=80=99t support at least ECMP? >> >>I am not sure. If there is consensus that ECMP is really ubiquitous, >>then we can add it. >> >>> >>>> >>>>> >>>>> - Include at least ECMP in the static route configuration. >>>> >>>>Same as in the previous case: ietf-routing provides a choice node for >>>>next-hops in both RIBs and static routes, and ECMP is explicitly >>>>mentioned as a candidate for augmentation. Why is it such a big a >>>>problem? >>> >>> It is not but as long as we are changing the model, we might as well >>> handle the predominant use cases. >> >>My concern is that other groups may come up with their favourite >>cases. Any new stuff increases the likelihood that bugs or inadequacies >>will be discovered in the module after it is published, but then it will >>be a problem due to the draconian module update rules. So I'd prefer to >>keep this module really skinny. >> >>> >>> >>>> >>>>> >>>>> - Structure consistent with the operational state recommendation. >>>>> Even w/o having the final recommendation, this model seems to >>>>> branch between config and state at way too high a level. >>>> >>>>Could you outline the concrete changes that you propose here? The most >>>>significant part of state data in this module is the list of RIBs, and I >>>>don't see any way how it can be bundled with configuration somewhere >>>>deeper in the hierarchy. >>> >>> I guess we will discuss this in upstate call next week. However, no >>>matter >>> what solution we come up with, it seems keeping the derived state closer >>> to intended/applied config is better. >> >>OK. >> >>Lada >> >>> >>> Thanks,=20 >>> Acee=20 >>> >>> >>>> >>>>Lada >>>> >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> >>>>> On 2/26/16, 8:36 AM, "netmod on behalf of Ladislav Lhotka" >>>>> wrote: >>>>> >>>>>>Hi, >>>>>> >>>>>>as a part of synchronization of the routing data models that are being >>>>>>developed by the NETMOD and RTG working groups, the authors of >>>>>>draft-ietf-netmod-routing-cfg propose to remove the routing-instance >>>>>>level in the data hierarchy, and leave it to structural-mount/YSDL to >>>>>>provide a top level structure. >>>>>> >>>>>>Schematically, the configuration and state data subtrees of >>>>>>ietf-routing >>>>>>would be reduced to something like this: >>>>>> >>>>>>module: ietf-routing >>>>>> +--ro routing-state >>>>>> | +--ro router-id? yang:dotted-quad >>>>>> | +--ro interfaces >>>>>> | | +--ro interface* if:interface-state-ref >>>>>> | +--ro routing-protocols >>>>>> | | +--ro routing-protocol* [type name] >>>>>> | | ... >>>>>> | +--ro ribs >>>>>> | +--ro rib* [name] >>>>>> | ... >>>>>> +--rw routing >>>>>> +--rw router-id? yang:dotted-quad >>>>>> +--rw description? string >>>>>> +--rw routing-protocols >>>>>> | +--rw routing-protocol* [type name] >>>>>> | ... >>>>>> +--rw ribs >>>>>> +--rw rib* [name] >>>>>> ... >>>>>> >>>>>>Are there any objections to this change? >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Acee and Lada >>>>>>=20 >>>>>>-- >>>>>>Ladislav Lhotka, CZ.NIC Labs >>>>>>PGP Key ID: E74E8C0C >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>netmod mailing list >>>>>>netmod@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>> >>>>--=20 >>>>Ladislav Lhotka, CZ.NIC Labs >>>>PGP Key ID: E74E8C0C >>> >> >>--=20 >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 7 06:35:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4311B41D2 for ; Mon, 7 Mar 2016 06:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWJLzcwP2HcC for ; Mon, 7 Mar 2016 06:35:34 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA47A1B41D8 for ; Mon, 7 Mar 2016 06:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=519; q=dns/txt; s=iport; t=1457361333; x=1458570933; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=JJg6jwO8sqUgr8r7q7AyQkBA1dDmh1tzb9JK75s+BW4=; b=GSd/p878pVUlvA8YO7MMP/QqMQkmOBQ2KxuC44rFCB28kOZxNqR0jDQQ TcU0N6PBPyKE8VDoTUhPtxlHmPRDiHCvV65ssbVC9BOtyIy2kvIUV8jbi XUxtpcaoW8qUTT3M+0D8T56kLNlj5y/iimQZPlQYPbUKDodwTfm1kD8E4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQD2kN1W/5NdJa1cgzpSbQa4J4ITA?= =?us-ascii?q?Q2BaSGHGDgUAQEBAQEBAWQcC4RIOlEBLBJCJgEEEwiIGg6gP55WAQEBAQYBAQE?= =?us-ascii?q?BAQEBFQSGF40xBZcqAYViiAOBVI0tjlQBHgEBQoNkaog/fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,551,1449532800"; d="scan'208";a="246483746" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2016 14:35:32 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u27EZWEk026791 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 7 Mar 2016 14:35:32 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 08:35:31 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 08:35:31 -0600 From: "Eric Voit (evoit)" To: "netmod@ietf.org" Thread-Topic: YANG Subscriptions @ IETF 95 Hackathon Thread-Index: AdF4fo2p/SLyh6skT3m4dh/YzFJqKQ== Date: Mon, 7 Mar 2016 14:35:31 +0000 Message-ID: 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.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [netmod] YANG Subscriptions @ IETF 95 Hackathon X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 14:35:35 -0000 OpenDaylight's latest release has a YANG PubSub client: https://wiki.opendaylight.org/view/YANG_PUBSUB:_Beryllium_User_Guide This allows a OpenDaylight to subscribe to existing YANG models as per the = NETCONF WG's draft-ietf-netconf-yang-push I am hoping to extend these capabilities in the IETF 95 Hackathon https://www.ietf.org/registration/MeetingWiki/wiki/95hackathon If anyone wants to join in, or if anyone wants to know more, let me know. Eric Eric Voit Principal Engineer evoit@cisco.com From nobody Mon Mar 7 07:24:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8097E1B42C7 for ; Mon, 7 Mar 2016 07:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCx3stEx_8sV for ; Mon, 7 Mar 2016 07:24:36 -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 A616E1B42CA for ; Mon, 7 Mar 2016 07:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14349; q=dns/txt; s=iport; t=1457364270; x=1458573870; h=from:to:subject:date:message-id:mime-version; bh=gH+3v7KbKBPe66DPo6qcKAaknBgyqF8B16+T25j9qZk=; b=MKekg25yvai3+llm2/h8B9UBRHJuame2mtoLd4s9EPl24igAcGfk1DuB biOy2noqRmHRk0+NErl5EIq/yLqw3LOV5CGUQAfKIT8gBsZYNXgNIxg8E /XTcNntV/qDFLMSg1COMEacAhMxWp7jOdjK/bBW8HNV+TH/2at6NeMshY Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQAtnN1W/5pdJa1dgm5MUm0GuCeCE?= =?us-ascii?q?wENgWmGDwKBKTgUAQEBAQEBAWQnhEEBAQEELV4BGQQBAQ4aORQJCQEEARIIF4g?= =?us-ascii?q?DvmwBAQEBAQEBAQEBAQEBAQEBAQEBARaGF4hHEQFUhAQFh1uLH4QwAY1lgWqER?= =?us-ascii?q?IhTjlQBHgEBQoNkaogLNH4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,551,1449532800"; d="scan'208,217";a="246653755" 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; 07 Mar 2016 15:24:29 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u27FOTML019091 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Mar 2016 15:24:29 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 09:24:28 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 09:24:28 -0600 From: "Eric Voit (evoit)" To: Ashesh Mishra , "netmod@ietf.org" Thread-Topic: NETMOD IETF 95 Slot Requests: Mount & YANG PubSub Thread-Index: AdF4hV2/5QGTTPuVScGi0h7e5icGJQ== Date: Mon, 7 Mar 2016 15:24:28 +0000 Message-ID: <482fafa4414a4f8798b7c40f7de46777@XCH-ALN-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.235] Content-Type: multipart/alternative; boundary="_000_482fafa4414a4f8798b7c40f7de46777XCHALN013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [netmod] NETMOD IETF 95 Slot Requests: Mount & YANG PubSub X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 15:24:38 -0000 --_000_482fafa4414a4f8798b7c40f7de46777XCHALN013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am requesting two short slots in NETMOD (1) Needing an extensible Mount syntax across Schema, Alias, & Peers (2) Hackathon Demo on YANG subscriptions ---------- Details: (1) Topic: Needing an extensible Mount syntax across Schema, Alias, & Peer= s Draft: draft-clemm-netmod-mount & draft-voit-netmod-peer-mount-requirements= (both soon updated) Duration: 10 minutes Presenter: Eric Voit Reasoning: The OpenDaylight has a significant implementation (as shown by = the hundreds of webpages including the word "Mount"). However Mount in ODL= refers to "Peer Mount" (see draft-clemm-netmod-mount). As Structural Mou= nt/YDSL draft discussions evolve, we need at a minimum to maintain context = and extensible syntax between efforts. A simple renaming of the word Mount= here would be insufficient as the concepts are closely related. (2) Topic: Hackathon Demo on YANG subscriptions Draft: draft-ietf-netconf-yang-push Duration: 5-10 minutes Presenter: Eric Voit Reasoning: OpenDaylight now has a YANG PubSub client as per the NETCONF WG= draft. A desire for transport independence for Subscription and Push is= growing as additional drafts (including HTTP) are being worked in this spa= ce. This won't just be a NETCONF technology. NETMOD members might like se= eing what is being added here from the Hackathon. Thanks, Eric From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ashesh Mishra Sent: Thursday, March 03, 2016 12:44 AM To: netmod@ietf.org Subject: [netmod] NETMOD IETF 95 Slot Requests Hi All, It's that time again. Please reply to this email (with the information below) to request a presen= tation slot in the NETMOD WG meetings at IETF 95 - Buenos Aires. Topic: Draft: Duration: Presenter: Thanks! Ashesh --_000_482fafa4414a4f8798b7c40f7de46777XCHALN013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am requesting two short slots in NETM= OD

 

(1) Needing an extensible Mount syntax across Schema, Alias= , & Peers

(2) Hackathon Demo on YANG subscriptions

 

----------

Details:

 

(1) Topic:  Needing an exte= nsible Mount syntax across Schema, Alias, & Peers

Draft: draft-clemm-netmod-mount & draft-voit-netmod-peer-m= ount-requirements (both soon updated)=

Duration: 10= minutes

Presenter: E= ric Voit

Reasoning:&n= bsp; The OpenDaylight has a significant implementation (as shown by the hun= dreds of webpages including the word “Mount”).  However Mount in O= DL refers to “Peer Mount” (see draft-clemm-netmod-mount). =  As Structural Mount/YDSL draft discussions evolve, we need at a mini= mum to maintain context and extensible syntax between efforts.  A simp= le renaming of the word Mount here would be insufficient as the concepts are = closely related.

 

(2) Topic: H= ackathon Demo on YANG subscriptions

Draft: draft= -ietf-netconf-yang-push

Duration:&nb= sp; 5-10 minutes

Presenter: E= ric Voit

Reasoning:&n= bsp; OpenDaylight now has a YANG PubSub client as per the NETCONF WG draft.=     A desire for transport independence for Subscription and Push is growing as additio= nal drafts (including HTTP) are being worked in this space.  This won&= #8217;t just be a NETCONF technology.  NETMOD members might like seein= g what is being added here from the Hackathon.

 <= /p>

Thanks,=

Eric

 <= /p>

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of Ashesh Mishra
Sent: Thursday, March 03, 2016 12:44 AM
To: netmod@ietf.org
Subject: [netmod] NETMOD IETF 95 Slot Requests

 

Hi All,

 

It’s that time again.=  

 

Please reply to this email = (with the information below) to request a presentation slot in the NETMOD W= G meetings at IETF 95 – Buenos Aires.

 

Topic:

Draft:

Duration:

Presenter:

 

Thanks!

Ashesh 

 

 

--_000_482fafa4414a4f8798b7c40f7de46777XCHALN013ciscocom_-- From nobody Mon Mar 7 07:51:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEAA1B432C for ; Mon, 7 Mar 2016 07:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLTLphiDoNlr for ; Mon, 7 Mar 2016 07:48:39 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 084B01B4321 for ; Mon, 7 Mar 2016 07:48:39 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 72C1614B361C2 for ; Mon, 7 Mar 2016 15:48:36 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u27Fmbin030048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 Mar 2016 15:48:38 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u27FmZJQ011963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Mar 2016 15:48:35 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.89]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 7 Mar 2016 10:48:35 -0500 From: "Sterne, Jason (Nokia - CA)" To: netmod WG Thread-Topic: YANG Advice/Editing Session at IETF95 ? Thread-Index: AdF4iM3RoqbFshu3QTiDMTBUBH51Mg== Date: Mon, 7 Mar 2016 15:48:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CBFD638US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 07 Mar 2016 07:51:31 -0800 Subject: [netmod] YANG Advice/Editing Session at IETF95 ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 15:48:41 -0000 --_000_A125E53CE190A749957C19483DC79F9F5CBFD638US70TWXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Is there a YANG editing/advice session in the works for IETF95 ? I don't s= ee it on the prelim IETF95 agenda. Regards, Jason --_000_A125E53CE190A749957C19483DC79F9F5CBFD638US70TWXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Is there a YANG editing/advice session in the works for IETF95 ? = I don’t see it on the prelim IETF95 agenda.
 
Regards,
Jason
 
 --_000_A125E53CE190A749957C19483DC79F9F5CBFD638US70TWXCHMBA11z_-- From nobody Mon Mar 7 08:03:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5370F1B4364 for ; Mon, 7 Mar 2016 08:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmixcqTzOwDK for ; Mon, 7 Mar 2016 08:03:34 -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 62CD31B4352 for ; Mon, 7 Mar 2016 08:03:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3946; q=dns/txt; s=iport; t=1457366611; x=1458576211; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=+v6yQOlagTdsiwvmeXANKKei13Ac0SjYZwLQPUp4g1s=; b=IOO0oRnoC3/M53PXjhgMIvocQPb8yBWILDXdFn+P1C79A6p6UQiyBySy xyeq79v9jwykrPCfqFMOhxYJ4ixZqyD9+1FOzdzwSi9Tv5dQz1x8lU6d7 0yI0JHzVloAwKD5dkexVVCnRp6utTHXwbqeelba13PUcg7tkngAcJStyx c=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AgBApd1W/xbLJq1cgm6BHm26QA6Ba?= =?us-ascii?q?RcBCYUkSgKBYRQBAQEBAQEBZCeEQgEBBAEBASAKQQoRCwQUCRYLAgIJAwIBAgE?= =?us-ascii?q?VMAYBDAYCAQGIIA6vd45fAQEBAQEBAQEBAQEBAQEBAQEBAQEOBASKVIc6gToBB?= =?us-ascii?q?JcqgxKBZYh2iSmFUY5VHgFDg2U7Lok9AQEB?= X-IronPort-AV: E=Sophos;i="5.22,552,1449532800"; d="asc'?scan'208,217";a="633187561" 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; 07 Mar 2016 16:03:29 +0000 Received: from [10.61.233.247] ([10.61.233.247]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u27G3T7K021479; Mon, 7 Mar 2016 16:03:29 GMT To: "Sterne, Jason (Nokia - CA)" , netmod WG References: From: Eliot Lear Message-ID: <56DDA650.6030808@cisco.com> Date: Mon, 7 Mar 2016 17:03:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KQgBIDkB4wkCL9Sdi7Q0sGNIVIE79aL67" Archived-At: Subject: Re: [netmod] YANG Advice/Editing Session at IETF95 ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 16:03:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KQgBIDkB4wkCL9Sdi7Q0sGNIVIE79aL67 Content-Type: multipart/mixed; boundary="xrunMuMjHFqgAAuIAjmBFOa5xDh2KPBVK" From: Eliot Lear To: "Sterne, Jason (Nokia - CA)" , netmod WG Message-ID: <56DDA650.6030808@cisco.com> Subject: Re: [netmod] YANG Advice/Editing Session at IETF95 ? References: In-Reply-To: --xrunMuMjHFqgAAuIAjmBFOa5xDh2KPBVK Content-Type: multipart/alternative; boundary="------------090002000300000301060102" This is a multi-part message in MIME format. --------------090002000300000301060102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'd be interested in this as well. On 3/7/16 4:48 PM, Sterne, Jason (Nokia - CA) wrote: > Hi all, > =20 > Is there a YANG editing/advice session in the works for IETF95 ? I > don=E2=80=99t see it on the prelim IETF95 agenda. > =20 > Regards, > Jason > =20 > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------090002000300000301060102 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'd be interested in this as well.

On 3/7/16 4:48 PM, Sterne, Jason (Noki= a - CA) wrote:
Hi all,
=C2=A0
Is there a YANG editing/advice session in the works for IETF95 ?=C2=A0 I don=E2=80=99t see it on the prelim IETF95 ag= enda.
=C2=A0
Regards,
Jason
=C2=A0
 

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

--------------090002000300000301060102-- --xrunMuMjHFqgAAuIAjmBFOa5xDh2KPBVK-- --KQgBIDkB4wkCL9Sdi7Q0sGNIVIE79aL67 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJW3aZQAAoJEIe2a0bZ0nozJzIH/RreC2feiBaTYPDcNV5nEHHl qiWTh79efSPQjUALgP/wCP6TEoZRTIH8/S7Q0qPC8R9/Xj5bDUyQG9qvX9llEfdf VxFYvmqVK2WQ0VDf5mwVe0MP4vfJLNivqIgjQP0lrJDGNvMf73Zw9NUb+iFdZ6HE qyQdfE4kCx5H2Uiun68Eb33xe84N8gTGxRJHSdhIcKoakR84Z0lNq06urZmjD6X2 xeGoDtGBateIHASnFTyS/9Fycca0lLp+1/vS+RZjYx+SiJF/SlmETNuj9Azo8p5i OPf9nB4HSMGiGhEo+g+QGXb5w1WCaFikjTK7ty+qX2Ut7uT2BfSPOwWJeZ13Yyk= =smas -----END PGP SIGNATURE----- --KQgBIDkB4wkCL9Sdi7Q0sGNIVIE79aL67-- From nobody Mon Mar 7 09:23:31 2016 Return-Path: X-Original-To: netmod@ietfc.amsl.com Delivered-To: netmod@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D3A281CD626 for ; Mon, 7 Mar 2016 09:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJmht-hVveeY for ; Mon, 7 Mar 2016 09:23:28 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 205481CD620 for ; Mon, 7 Mar 2016 09:23:24 -0800 (PST) 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 (TLS) id 15.1.415.20; Mon, 7 Mar 2016 17:23:04 +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.0415.024; Mon, 7 Mar 2016 17:23:04 +0000 From: Kent Watsen To: Eliot Lear , "Sterne, Jason (Nokia - CA)" , netmod WG Thread-Topic: [netmod] YANG Advice/Editing Session at IETF95 ? Thread-Index: AdF4iM3RoqbFshu3QTiDMTBUBH51MgAAhUwA///CaoA= Date: Mon, 7 Mar 2016 17:23:04 +0000 Message-ID: <0EACAA06-3541-430C-9F77-43C3F032FEA6@juniper.net> References: <56DDA650.6030808@cisco.com> In-Reply-To: <56DDA650.6030808@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 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.10] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:3lMpXhxQ5BzOW4I2Q4oQKtTRXbDuNwiHtnThpusowyVWpPPKfVH9NzGEC33DXcpHGJiUI/Px5ccOIx1f49rdlkMPyxPti6jEJjHpAjWJiQsc2W1THFAV0zLJ4DOF6wriJY6NMbP0gEs3eTUsgKNy/Q==; 24:7i+1yN1fLVGXxYDNo6LIEuukKL7Av0z3vKp49NlsfBWbFAPKpc2aaTwPtGPMIkoBb7drJC+b+uZNbP76XusOAId/LXBJukvUwvP5urR/iwo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: 16216c4f-d149-40f3-ba4f-08d346ad248f x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 087474FBFA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(479174004)(377454003)(53754006)(81166005)(15975445007)(2950100001)(2900100001)(5004730100002)(99286002)(5002640100001)(586003)(83716003)(92566002)(50986999)(76176999)(66066001)(54356999)(11100500001)(1220700001)(3846002)(3280700002)(6116002)(189998001)(86362001)(4001350100001)(102836003)(1096002)(36756003)(107886002)(5001770100001)(10400500002)(19580405001)(33656002)(19580395003)(87936001)(5008740100001)(19617315012)(2906002)(40100003)(16236675004)(82746002)(83506001)(19625215002)(122556002)(3660700001)(77096005)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0EACAA063541430C9F7743C3F032FEA6junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2016 17:23:04.4807 (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 Advice/Editing Session at IETF95 ? 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, 07 Mar 2016 17:23:30 -0000 --_000_0EACAA063541430C9F7743C3F032FEA6junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpObywgdGhlcmUgd2lsbCBub3QgYmUgYSBZQU5HIGFkdmljZSBhbmQgZWRpdGluZyBzZXNzaW9u IGF0IElFVEY5NS4NCg0KQSBudW1iZXIgb2YgWUFORyBEb2N0b3JzIHdpbGwgYmUgYXQgdGhlIEhh Y2thdGhvbiBib3RoIFNhdHVyZGF5IGFuZCBTdW5kYXksIHNvIHNvbWUgaGVscCBjYW4gYmUgaGFk IHRoZXJlLg0KDQpLZW50DQoNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRWxpb3QgTGVh ciA8bGVhckBjaXNjby5jb208bWFpbHRvOmxlYXJAY2lzY28uY29tPj4NCkRhdGU6IE1vbmRheSwg TWFyY2ggNywgMjAxNiBhdCAxMTowMyBBTQ0KVG86ICJTdGVybmUsIEphc29uIChOb2tpYSAtIENB KSIgPGphc29uLnN0ZXJuZUBub2tpYS5jb208bWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20+ PiwgIm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPiIgPG5ldG1vZEBpZXRm Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBZQU5H IEFkdmljZS9FZGl0aW5nIFNlc3Npb24gYXQgSUVURjk1ID8NCg0KSSdkIGJlIGludGVyZXN0ZWQg aW4gdGhpcyBhcyB3ZWxsLg0KDQpPbiAzLzcvMTYgNDo0OCBQTSwgU3Rlcm5lLCBKYXNvbiAoTm9r aWEgLSBDQSkgd3JvdGU6DQpIaSBhbGwsDQoNCklzIHRoZXJlIGEgWUFORyBlZGl0aW5nL2Fkdmlj ZSBzZXNzaW9uIGluIHRoZSB3b3JrcyBmb3IgSUVURjk1ID8gIEkgZG9u4oCZdCBzZWUgaXQgb24g dGhlIHByZWxpbSBJRVRGOTUgYWdlbmRhLg0KDQpSZWdhcmRzLA0KSmFzb24NCg0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWls aW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg== --_000_0EACAA063541430C9F7743C3F032FEA6junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pk5vLCB0aGVyZSB3aWxsIG5vdCBiZSBhIFlBTkcgYWR2aWNlIGFuZCBl ZGl0aW5nIHNlc3Npb24gYXQgSUVURjk1LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ QSBudW1iZXIgb2YgWUFORyBEb2N0b3JzIHdpbGwgYmUgYXQgdGhlIEhhY2thdGhvbiBib3RoIFNh dHVyZGF5IGFuZCBTdW5kYXksIHNvIHNvbWUgaGVscCBjYW4gYmUgaGFkIHRoZXJlLjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+S2VudDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxp Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+bmV0bW9kICZsdDs8YSBocmVmPSJtYWlsdG86 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg b24gYmVoYWxmIG9mIEVsaW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNv bSI+bGVhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBNYXJjaCA3LCAyMDE2IGF0IDExOjAzIEFNPGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7U3Rlcm5lLCBK YXNvbiAoTm9raWEgLSBDQSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqYXNvbi5zdGVybmVA bm9raWEuY29tIj5qYXNvbi5zdGVybmVAbm9raWEuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9 Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW25l dG1vZF0gWUFORyBBZHZpY2UvRWRpdGluZyBTZXNzaW9uIGF0IElFVEY5NSA/PGJyPg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0i IzAwMDAwMCI+SSdkIGJlIGludGVyZXN0ZWQgaW4gdGhpcyBhcyB3ZWxsLjxicj4NCjxicj4NCjxk aXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMy83LzE2IDQ6NDggUE0sIFN0ZXJuZSwgSmFz b24gKE5va2lhIC0gQ0EpIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlk OkExMjVFNTNDRTE5MEE3NDk5NTdDMTk0ODNEQzc5RjlGNUNCRkQ2MzhAVVM3MFRXWENITUJBMTEu emFtLmFsY2F0ZWwtbHVjZW50LmNvbSIgdHlwZT0iY2l0ZSI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0 b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBFeGNoYW5nZSBTZXJ2ZXIiPg0KPCEtLSBjb252ZXJ0ZWQg ZnJvbSBydGYgLS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBw YWRkaW5nLWxlZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwv c3R5bGU+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMXB0OyI+DQo8ZGl2PkhpIGFsbCw8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pklz IHRoZXJlIGEgWUFORyBlZGl0aW5nL2FkdmljZSBzZXNzaW9uIGluIHRoZSB3b3JrcyBmb3IgSUVU Rjk1ID8mbmJzcDsgSSBkb27igJl0IHNlZSBpdCBvbiB0aGUgcHJlbGltIElFVEY5NSBhZ2VuZGEu PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5KYXNv bjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PGJyPg0KPGZpZWxkc2V0 IGNsYXNzPSJtaW1lQXR0YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4gPGJyPg0KPHByZSB3cmFw PSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRt b2QgbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVm PSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGEgY2xhc3M9Im1v ei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 bW9kPC9hPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bh bj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0EACAA063541430C9F7743C3F032FEA6junipernet_-- From nobody Mon Mar 7 17:06:38 2016 Return-Path: X-Original-To: netmod@ietfc.amsl.com Delivered-To: netmod@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D6FFF1CD639 for ; Mon, 7 Mar 2016 17:06:36 -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_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCpd-xnTPPHd for ; Mon, 7 Mar 2016 17:06:35 -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 ietfc.amsl.com (Postfix) with ESMTPS id A007A1CDF9F for ; Mon, 7 Mar 2016 16:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12030; q=dns/txt; s=iport; t=1457398693; x=1458608293; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=E5dbFOp4SvdHaMwHznrb5uso1WZW1Dui1r10+b6p70I=; b=B1NnHpUUW4JiC6pScFS1FPqJIhQUbVzFXYnVfI61u+VE97/JmdtPyYIp OfrdjenIoVn+7JL07Eqo98LO/276xtOLq0RRecZbiK7BKzPlz133UtUcr FlOOWl/oIcShEq4+bBXnd32PfmmRG0a1xy3HwIfmhjsnW8zyNe9u6+Xkq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgD0Id5W/5JdJa1cgzpSbQa6PwENg?= =?us-ascii?q?WkXCoUkSgIcgRU4FAEBAQEBAQFkJ4RBAQEBAwEBAQEgETcDGwIBCBgCAiYCAgI?= =?us-ascii?q?lCxUQAgQBEhuIAQgOrxuPMQEBAQEBAQQBAQEBAQEBARQEe4hcfYQiFoMCgToFj?= =?us-ascii?q?TCJegGFYogLgWONF4V5iFsBHgEBQoNkaokBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,554,1449532800"; d="scan'208";a="246854536" 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; 08 Mar 2016 00:54:08 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u280s8dY020967 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Mar 2016 00:54:08 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 18:54:07 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 18:54:07 -0600 From: "Acee Lindem (acee)" To: Ladislav Lhotka , NETMOD Working Group Thread-Topic: [netmod] proposed change to ietf-routing Thread-Index: AQHRcJq0RazNoMs9PkSzBYV8exAQ959GhjuAgAGWzACAAIJSAIABD6YAgAA7AYCABIh4AIAAZxkA Date: Tue, 8 Mar 2016 00:54:07 +0000 Message-ID: References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> In-Reply-To: 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.199] Content-Type: text/plain; charset="utf-8" Content-ID: <788CC15D9D0C4D4DA3A1D79FE08D89DE@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] proposed change to ietf-routing 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, 08 Mar 2016 01:06:37 -0000 SGkgTGFkYSwgDQoNCk9uIDMvNy8xNiwgODo0NSBBTSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3Rr YUBuaWMuY3o+IHdyb3RlOg0KDQo+IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29t PiB3cml0ZXM6DQo+DQo+PiBIaSBMYWRhLCANCj4+DQo+PiBPbiAzLzQvMTYsIDg6MDAgQU0sICJM YWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4+DQo+Pj4iQWNlZSBMaW5k ZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyaXRlczoNCj4+Pg0KPj4+PiBIaSBMYWRhLCAN Cj4+Pj4NCj4+Pj4gT24gMy8zLzE2LCA4OjAxIEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGth QG5pYy5jej4gd3JvdGU6DQo+Pj4+DQo+Pj4+PiJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNp c2NvLmNvbT4gd3JpdGVzOg0KPj4+Pj4NCj4+Pj4+PiBIaSBMYWRhLCBORVRNT0QgV0cgbWVtYmVy cywNCj4+Pj4+Pg0KPj4+Pj4+IFRoZXJlIGFyZSBhY3R1YWxseSBhIG51bWJlciBvZiBjaGFuZ2Vz IHRoYXQgd2Ugd291bGQgbGlrZSB0bw0KPj4+Pj4+IHNlZSBpbiB0aGUgaWV0Zi1yb3V0aW5nIG1v ZGVsOg0KPj4+Pj4+DQo+Pj4+Pj4gLSBSZW1vdmUgcm91dGluZy1pbnN0YW5jZXMgc2luY2UgaWV0 Zi1yb3V0aW5nIHNpbmNlIGl0IHdpbGwgYmUNCj4+Pj4+PiAgIOKAnG1vdW50ZWTigJ0gYXQgZGlm ZmVyZW50IHBvaW50cyBpbiB0aGUgZGV2aWNlIGhpZXJhcmNoeSBkZXBlbmRlbnQNCj4+Pj4+PiAg IG9uIHRoZSBkZXZpY2UgcmVxdWlyZW1lbnRzLg0KPj4+Pj4NCj4+Pj4+QWdyZWVkLg0KPj4+Pj4N Cj4+Pj4+Pg0KPj4+Pj4+IC0gQ29sbGFwc2UgaXQgaW50byBvbmUgbW9kdWxlIHN1cHBvcnRpbmcg ZGlmZmVyZW50IGFkZHJlc3MgZmFtaWxpZXMNCj4+Pj4+PiAgIHJhdGhlciAzIG1vZHVsZXMgKGJh c2UsIElQdjQsIGFuZCBJUHY2KS4NCj4+Pj4+DQo+Pj4+PlRoaXMgaXMgcG9zc2libGUsIGJ1dCB3 ZSB3b3VsZCBoYXZlIHRvIGludHJvZHVjZSBhIG1lY2hhbmlzbSBmb3INCj4+Pj4+aW1wbGVtZW50 YXRpb25zIHN1cHBvcnRpbmcgb25seSBvbmUgb2YgdGhlbS4gSXQgc2VlbXMgdG8gbWUgdGhhdCBp dCBpcw0KPj4+Pj5lYXNpZXIgdG8gc2VsZWN0IG1vZHVsZXMgZm9yIGJhc2UgKyBhbnkgY29tYmlu YXRpb24gb2YgYWRkcmVzcw0KPj4+Pj5mYW1pbGllcywNCj4+Pj4+YW5kIGVhY2ggZmFtaWx5IG1v ZHVsZSBpbnNlcnRzIGFwcHJvcHJpYXRlIHN0dWZmIHRvIHJpZ2h0IHBsYWNlcyAtIGFuZA0KPj4+ Pj50aGVyZSBpcyBxdWl0ZSBhIGJ1bmNoIG9mIHRoZW0uIFdoYXQgeW91IGFyZSBwcm9wb3Npbmcg cHJvYmFibHkgbWVhbnMNCj4+Pj4+dGhlDQo+Pj4+PihzaW5nbGUpIG1vZHVsZSB3b3VsZCBoYXZl IGlmLWZlYXR1cmVzIG9yIHdoZW5zIGluIGFsbCB0aG9zZSBwbGFjZXMuDQo+Pj4+DQo+Pj4+IEFy ZSB0aGVyZSBwbGFubmVkIGltcGxlbWVudGF0aW9ucyByZXF1aXJlZCBZQU5HIG1vZGVscyB3aGVy ZSBvbmx5IElQdjQNCj4+Pj5vcg0KPj4+PiBJUHY2IGFyZSBzdXBwb3J0ZWQ/IE1heWJlIHdheSBv ZmYgaW4gdGhlIGZ1dHVyZSwgd2hlbiB5b3UgYW5kIEkgYXJlDQo+Pj4+Ym90aA0KPj4+PiBzaXR0 aW5nIG9uIGEgYmVhY2ggZHJpbmtpbmcgYmVlciB0aGVyZSB3aWxsIGJlIElQdjYgb25seSBwcm9k dWN0cyBidXQNCj4+Pj5JDQo+Pj4+IGRvbuKAmXQgc2VlIGl0IGhhcHBlbmluZyBzb29uLg0KPj4+ Pg0KPj4+DQo+Pj5NYXliZSBzb21lIGV4cGVydHMgaW4gdGhlIGVtYmVkZGVkIGFyZWEgY291bGQg Y29tbWVudCBvbiB0aGlzLCBidXQgSQ0KPj4+YmVsaWV2ZSBpbiBib3RoIDZMb1dQQU4gYW5kIFpp Z0JlZSBJUHY2LW9ubHkgbmV0d29ya3MgYXJlIGNvbW1vbnBsYWNlLg0KPj4NCj4+IE9rYXkgLSBJ 4oCZdmUgYWxzbyBoZWFyZCByZXF1aXJlbWVudHMgZnJvbSBhbiBTUCBmb3IgYWNjZXNzIGRldmlj ZXMgd2l0aA0KPj4gb25seSBJUHY2LiBIb3dldmVyLCBpcyBhIHNlcGFyYXRlIG1vZHVsZSByZXF1 aXJlZCBmb3IgdGhpcz8NCj4NCj5BbiBJUHY2LW9ubHkgc3lzdGVtIHNob3VsZCBub3QgaGF2ZSBJ UHY0LXJlbGF0ZWQgbm9kZXMgaW4gdGhlIHNjaGVtYS4gQXMNCj5JIHdyb3RlLCBhbHRlcm5hdGl2 ZXMgYXJlDQo+DQo+KGEpIGRlZmluZSBmZWF0dXJlcyBmb3IgaW5kaXZpZHVhbCBhZGRyZXNzIGZh bWlsaWVzDQo+KGIpIGluY2x1ZGUgY29uZmlndXJhdGlvbiBvZiBhZGRyZXNzIGZhbWlsaWVzLCBh bmQgdGhlbiB1c2UgIndoZW4iDQo+c3RhdGVtZW50cyB0byBjb250cm9sIHRoZSBzY2hlbWEuDQoN CldlIGhhdmUgdGhlIGlwLWFkZHJlc3MgdHlwZSB0aGF0IHN1cHBvcnRzIGJvdGjigKYgQ291bGRu 4oCZdCB3ZSB1c2UgdGhpcyB0eXBlDQphbmQgaGF2ZSB0aGUgc2VydmVyIHNpbXBseSByZXR1cm4g YW4gZXJyb3IgaWYgYSByb3V0ZSBpcyBjb25maWd1cmVkIGZvciBhbg0KdW5zdXBwb3J0ZWQgYWRk cmVzcyBmYW1pbHk/IFNob3VsZCB0aGUgaWV0Zi15YW5nLXR5cGVzIG1vZHVsZSBiZQ0KcmUtcHVi bGlzaGVkIHdpdGggaXAtYWRkcmVzcyByZW1vdmVkPw0KDQpJIGd1ZXNzIGRvbuKAmXQgc2VlIHRo aXMgYXMgYSBtYWpvciBwb2ludC4NCg0KDQo+DQo+V2UgYWxzbyBoYXZlIHRvIGNvbnNpZGVyIG90 aGVyIGZhbWlsaWVzIHRoYXQgbWF5IGJlIGFkZGVkLCBldmVuIHNvbWUNCj50aGF0IGRvbid0IGV4 aXN0IHlldC4NCg0KDQpBZ3JlZWQuIFRoZXNlIGNhbiBiZSBhZGRlZCB0aHJvdWdoIGF1Z21lbnRh dGlvbi4NCg0KPg0KPj4gaWV0Zi15YW5nLXR5cGVzIGhhcyB0aGUgdHlwZSBpcC1hZGRyZXNzIHN1 cHBvcnRpbmcgYm90aCBBRnMuIERvZXMNCj4+IHN1cHBvcnRpbmcgb25lIG9yIHRoZSBvdGhlciBB RiBvciBib3RoIG5lZWQgdG8gYmUgZW5mb3JjZWQgd2l0aCBzZXBhcmF0ZQ0KPj4gbW9kdWxlcz8g Rm9yIElQdjQsIHdlIGFyZSBnb2luZyB0byBuZWVkIHRvIHN1cHBvcnQgSVB2NiBuZXh0LWhvcHMg KHJlZmVyDQo+PiB0byBSRkMgNTU0OSkuICANCj4+DQo+Pg0KPj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4gLSBSZW1vdmUgdGhlIE5EIChSRkMgNDg2MSkgUm91dGVyIEFkdmVy dGlzZW1lbnQgcHJvdG9jb2wgc2luY2UgaXQNCj4+Pj4+PiAgIGRvZXNu4oCZdCBuZWVkIHRvIGJl IGhlcmUuDQo+Pj4+Pg0KPj4+Pj5XZWxsLCBSRkMgNDg2MSBzYXlzOiAiQSByb3V0ZXIgTVVTVCBh bGxvdyBmb3IgdGhlIGZvbGxvd2luZyBjb25jZXB0dWFsDQo+Pj4+PnZhcmlhYmxlcyB0byBiZSBj b25maWd1cmVkIGJ5IHN5c3RlbSBtYW5hZ2VtZW50LiINCj4+Pj4+DQo+Pj4+PlNvIEkgZG9uJ3Qg dGhpbmsgdGhleSBjYW4gYmUgY29uc2lkZXJlZCBvcHRpb25hbC4gV2UgY291bGQgcGVyaGFwcw0K Pj4+Pj5tb3ZlDQo+Pj4+PnRoZW0gdG8gYSBzdWJtb2R1bGUgc28gdGhhdCB0aGV5IGRvbid0IGNs dXR0ZXIgdGhlIG1haW4gbW9kdWxlLg0KPj4+Pg0KPj4+PiBJIGRvbuKAmXQgZGlzYWdyZWUgLSBi dXQgd2h5IGFyZSB0aGV5IGdyb3VwZWQgd2l0aCB0aGUgbWFpbiBSSUIgYW5kDQo+Pj4+aW5mcmEN Cj4+Pj4gZHJhZnQ/IFJvdXRlciBBZHZlcnRpc2VtZW50IHNob3VsZCBiZSB3aXRoIHRoZSBvdGhl ciBSRkMgNDg2MQ0KPj4+PnByb3RvY29scy4NCj4+Pj4gSXQgaXMgb3V0IG9mIHBsYWNlIGhlcmUu DQo+Pj4NCj4+PlRoZSBpZGVhIGlzIHRoYXQgYW55IGRldmljZSB0aGF0IGltcGxlbWVudHMgaWV0 Zi1yb3V0aW5nIGlzIHJlcXVpcmVkIHRvDQo+Pj5zdXBwb3J0IHRoZXNlIGNvbmZpZ3VyYXRpb24g dmFyaWFibGVzLCB3aGljaCBpcyB3aGF0IDQ4NjEgc2F5cy4NCj4+DQo+PiBCdXQgaXQgc2F5cyBu b3RoaW5nIGFib3V0IHRoZSBvcmdhbml6YXRpb24gb2YgdGhlIFlBTkcgbW9kdWxlcyA7XikNCj4N Cj5ObywgYnV0IGN1cnJlbnRseSB0aGVyZSBpcyBubyB3YXkgdG8gc2F5IHRoYXQgaWYgbW9kdWxl IFggaXMgaW1wbGVtZW50ZWQsDQo+dGhlbg0KPm1vZHVsZSBZIGhhcyB0byBiZSBpbXBsZW1lbnRl ZCwgdG9vLg0KPg0KPj4NCj4+PiBXaXRoIGENCj4+Pm1lY2hhbmlzbSBsaWtlIEFuZHkncyBwYWNr YWdlcyB3ZSB3b3VsZCBoYXZlIG1vcmUgZmxleGliaWxpdHksIGJ1dCBmb3INCj4+PnRoZSB0aW1l IGJlaW5nIHRoZSBiZXN0IHNvbHV0aW9uIHNlZW1zIHRvIGJlIHRvIG1vdmUgUkEgc3R1ZmYgdG8g YQ0KPj4+c3VibW9kdWxlLg0KPj4NCj4+IFdoeSB3b3VsZG7igJl0IFJBIGJlIGluIGEgc2VwYXJh dGUgZHJhZnQgd2l0aCBhbGwgdGhlIG90aGVyIFJGQyA0ODYxDQo+PiBwcm90b2NvbHM/DQo+DQo+ SXQgY291bGQsIGFuZCB3ZSBjb3VsZCBob3BlIHRoYXQgc29tZSBtZWNoYW5pc20gd2lsbCBiZSBl c3RhYmxpc2hlZCBsYXRlcg0KPmZvcg0KPnNwZWNpZnlpbmcgbW9kdWxlIGRlcGVuZGVuY2llcyBh bmQgcHJlcmVxdWlzaXRlcy4gSXQncyBJTU8gbmVlZGVkDQo+YW55d2F5Lg0KDQpBUlAgYW5kIEFD THMgYXJlIGFsc28gbmVlZGVkIGFueXdheSwgdGhhdCBkb2VzbuKAmXQgbWVhbiB0aGV5IG5lZWQg dG8gYmUNCmluY2x1ZGVkIGluIHRoaXMgZHJhZnQuDQoNCkFjZWUgDQoNCg0KPg0KPkxhZGENCj4N Cj4+DQo+Pg0KPj4NCj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+ IC0gU3VwcG9ydCBhdCBsZWFzdCB0aGUgbmV4dCBob3AgZW5oYW5jZW1lbnRzIGluDQo+Pj4+Pj4g ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWNlZS1ydGd3Zy15YW5nLXJpYi1l eHRlbmQtMDANCj4+Pj4+DQo+Pj4+PlRoZXkgY2FuIGJlIGFkZGVkIHZpYSBhdWdtZW50cywgYW5k IG1hbnkgcG90ZW50aWFsIHVzZXJzIG9mIHRoZQ0KPj4+Pj5yb3V0aW5nDQo+Pj4+Pm1vZHVsZSAo aG9zdHMgYW5kIHNpbXBsZSByb3V0ZXJzKSBkb24ndCBzdXBwb3J0IHRoZW0uDQo+Pj4+DQo+Pj4+ IEFyZSB0aGVyZSBob3N0cyB0aGF0IGRvbuKAmXQgc3VwcG9ydCBhdCBsZWFzdCBFQ01QPw0KPj4+ DQo+Pj5JIGFtIG5vdCBzdXJlLiBJZiB0aGVyZSBpcyBjb25zZW5zdXMgdGhhdCBFQ01QIGlzIHJl YWxseSB1YmlxdWl0b3VzLA0KPj4+dGhlbiB3ZSBjYW4gYWRkIGl0Lg0KPj4+DQo+Pj4+DQo+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4gLSBJbmNsdWRlIGF0IGxlYXN0IEVDTVAgaW4gdGhlIHN0YXRpYyBy b3V0ZSBjb25maWd1cmF0aW9uLg0KPj4+Pj4NCj4+Pj4+U2FtZSBhcyBpbiB0aGUgcHJldmlvdXMg Y2FzZTogaWV0Zi1yb3V0aW5nIHByb3ZpZGVzIGEgY2hvaWNlIG5vZGUgZm9yDQo+Pj4+Pm5leHQt aG9wcyBpbiBib3RoIFJJQnMgYW5kIHN0YXRpYyByb3V0ZXMsIGFuZCBFQ01QIGlzIGV4cGxpY2l0 bHkNCj4+Pj4+bWVudGlvbmVkIGFzIGEgY2FuZGlkYXRlIGZvciBhdWdtZW50YXRpb24uIFdoeSBp cyBpdCBzdWNoIGEgYmlnIGENCj4+Pj4+cHJvYmxlbT8NCj4+Pj4NCj4+Pj4gSXQgaXMgbm90IGJ1 dCBhcyBsb25nIGFzIHdlIGFyZSBjaGFuZ2luZyB0aGUgbW9kZWwsIHdlIG1pZ2h0IGFzIHdlbGwN Cj4+Pj4gaGFuZGxlIHRoZSBwcmVkb21pbmFudCB1c2UgY2FzZXMuDQo+Pj4NCj4+Pk15IGNvbmNl cm4gaXMgdGhhdCBvdGhlciBncm91cHMgbWF5IGNvbWUgdXAgd2l0aCB0aGVpciBmYXZvdXJpdGUN Cj4+PmNhc2VzLiBBbnkgbmV3IHN0dWZmIGluY3JlYXNlcyB0aGUgbGlrZWxpaG9vZCB0aGF0IGJ1 Z3Mgb3IgaW5hZGVxdWFjaWVzDQo+Pj53aWxsIGJlIGRpc2NvdmVyZWQgaW4gdGhlIG1vZHVsZSBh ZnRlciBpdCBpcyBwdWJsaXNoZWQsIGJ1dCB0aGVuIGl0IHdpbGwNCj4+PmJlIGEgcHJvYmxlbSBk dWUgdG8gdGhlIGRyYWNvbmlhbiBtb2R1bGUgdXBkYXRlIHJ1bGVzLiBTbyBJJ2QgcHJlZmVyIHRv DQo+Pj5rZWVwIHRoaXMgbW9kdWxlIHJlYWxseSBza2lubnkuDQo+Pj4NCj4+Pj4NCj4+Pj4NCj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiAtIFN0cnVjdHVyZSBjb25zaXN0ZW50IHdpdGggdGhlIG9wZXJh dGlvbmFsIHN0YXRlIHJlY29tbWVuZGF0aW9uLg0KPj4+Pj4+ICAgRXZlbiB3L28gaGF2aW5nIHRo ZSBmaW5hbCByZWNvbW1lbmRhdGlvbiwgdGhpcyBtb2RlbCBzZWVtcyB0bw0KPj4+Pj4+ICAgYnJh bmNoIGJldHdlZW4gY29uZmlnIGFuZCBzdGF0ZSBhdCB3YXkgdG9vIGhpZ2ggYSBsZXZlbC4NCj4+ Pj4+DQo+Pj4+PkNvdWxkIHlvdSBvdXRsaW5lIHRoZSBjb25jcmV0ZSBjaGFuZ2VzIHRoYXQgeW91 IHByb3Bvc2UgaGVyZT8gVGhlIG1vc3QNCj4+Pj4+c2lnbmlmaWNhbnQgcGFydCBvZiBzdGF0ZSBk YXRhIGluIHRoaXMgbW9kdWxlIGlzIHRoZSBsaXN0IG9mIFJJQnMsDQo+Pj4+PmFuZCBJDQo+Pj4+ PmRvbid0IHNlZSBhbnkgd2F5IGhvdyBpdCBjYW4gYmUgYnVuZGxlZCB3aXRoIGNvbmZpZ3VyYXRp b24gc29tZXdoZXJlDQo+Pj4+PmRlZXBlciBpbiB0aGUgaGllcmFyY2h5Lg0KPj4+Pg0KPj4+PiBJ IGd1ZXNzIHdlIHdpbGwgZGlzY3VzcyB0aGlzIGluIHVwc3RhdGUgY2FsbCBuZXh0IHdlZWsuIEhv d2V2ZXIsIG5vDQo+Pj4+bWF0dGVyDQo+Pj4+IHdoYXQgc29sdXRpb24gd2UgY29tZSB1cCB3aXRo LCBpdCBzZWVtcyBrZWVwaW5nIHRoZSBkZXJpdmVkIHN0YXRlDQo+Pj4+Y2xvc2VyDQo+Pj4+IHRv IGludGVuZGVkL2FwcGxpZWQgY29uZmlnIGlzIGJldHRlci4NCj4+Pg0KPj4+T0suDQo+Pj4NCj4+ PkxhZGENCj4+Pg0KPj4+Pg0KPj4+PiBUaGFua3MsIA0KPj4+PiBBY2VlIA0KPj4+Pg0KPj4+Pg0K Pj4+Pj4NCj4+Pj4+TGFkYQ0KPj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcywNCj4+Pj4+PiBB Y2VlDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IE9uIDIvMjYvMTYsIDg6MzYgQU0sICJuZXRtb2Qg b24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSINCj4+Pj4+PiA8bmV0bW9kLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+ SGksDQo+Pj4+Pj4+DQo+Pj4+Pj4+YXMgYSBwYXJ0IG9mIHN5bmNocm9uaXphdGlvbiBvZiB0aGUg cm91dGluZyBkYXRhIG1vZGVscyB0aGF0IGFyZQ0KPj4+Pj4+PmJlaW5nDQo+Pj4+Pj4+ZGV2ZWxv cGVkIGJ5IHRoZSBORVRNT0QgYW5kIFJURyB3b3JraW5nIGdyb3VwcywgdGhlIGF1dGhvcnMgb2YN Cj4+Pj4+Pj5kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZyBwcm9wb3NlIHRvIHJlbW92ZSB0 aGUgcm91dGluZy1pbnN0YW5jZQ0KPj4+Pj4+PmxldmVsIGluIHRoZSBkYXRhIGhpZXJhcmNoeSwg YW5kIGxlYXZlIGl0IHRvIHN0cnVjdHVyYWwtbW91bnQvWVNETA0KPj4+Pj4+PnRvDQo+Pj4+Pj4+ cHJvdmlkZSBhIHRvcCBsZXZlbCBzdHJ1Y3R1cmUuDQo+Pj4+Pj4+DQo+Pj4+Pj4+U2NoZW1hdGlj YWxseSwgdGhlIGNvbmZpZ3VyYXRpb24gYW5kIHN0YXRlIGRhdGEgc3VidHJlZXMgb2YNCj4+Pj4+ Pj5pZXRmLXJvdXRpbmcNCj4+Pj4+Pj53b3VsZCBiZSByZWR1Y2VkIHRvIHNvbWV0aGluZyBsaWtl IHRoaXM6DQo+Pj4+Pj4+DQo+Pj4+Pj4+bW9kdWxlOiBpZXRmLXJvdXRpbmcNCj4+Pj4+Pj4gICAr LS1ybyByb3V0aW5nLXN0YXRlDQo+Pj4+Pj4+ICAgfCAgKy0tcm8gcm91dGVyLWlkPyAgICAgICAg ICAgeWFuZzpkb3R0ZWQtcXVhZA0KPj4+Pj4+PiAgIHwgICstLXJvIGludGVyZmFjZXMNCj4+Pj4+ Pj4gICB8ICB8ICArLS1ybyBpbnRlcmZhY2UqICAgaWY6aW50ZXJmYWNlLXN0YXRlLXJlZg0KPj4+ Pj4+PiAgIHwgICstLXJvIHJvdXRpbmctcHJvdG9jb2xzDQo+Pj4+Pj4+ICAgfCAgfCAgKy0tcm8g cm91dGluZy1wcm90b2NvbCogW3R5cGUgbmFtZV0NCj4+Pj4+Pj4gICB8ICB8ICAgICAuLi4NCj4+ Pj4+Pj4gICB8ICArLS1ybyByaWJzDQo+Pj4+Pj4+ICAgfCAgICAgKy0tcm8gcmliKiBbbmFtZV0N Cj4+Pj4+Pj4gICB8ICAgICAgICAuLi4NCj4+Pj4+Pj4gICArLS1ydyByb3V0aW5nDQo+Pj4+Pj4+ ICAgICAgKy0tcncgcm91dGVyLWlkPyAgICAgICAgICAgeWFuZzpkb3R0ZWQtcXVhZA0KPj4+Pj4+ PiAgICAgICstLXJ3IGRlc2NyaXB0aW9uPyAgICAgICAgIHN0cmluZw0KPj4+Pj4+PiAgICAgICst LXJ3IHJvdXRpbmctcHJvdG9jb2xzDQo+Pj4+Pj4+ICAgICAgfCAgKy0tcncgcm91dGluZy1wcm90 b2NvbCogW3R5cGUgbmFtZV0NCj4+Pj4+Pj4gICAgICB8ICAgICAuLi4NCj4+Pj4+Pj4gICAgICAr LS1ydyByaWJzDQo+Pj4+Pj4+ICAgICAgICAgKy0tcncgcmliKiBbbmFtZV0NCj4+Pj4+Pj4JICAg IC4uLg0KPj4+Pj4+Pg0KPj4+Pj4+PkFyZSB0aGVyZSBhbnkgb2JqZWN0aW9ucyB0byB0aGlzIGNo YW5nZT8NCj4+Pj4+Pj4NCj4+Pj4+Pj5UaGFua3MsDQo+Pj4+Pj4+DQo+Pj4+Pj4+QWNlZSBhbmQg TGFkYQ0KPj4+Pj4+PiANCj4+Pj4+Pj4tLQ0KPj4+Pj4+PkxhZGlzbGF2IExob3RrYSwgQ1ouTklD IExhYnMNCj4+Pj4+Pj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+ Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+Pj4+bmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pm5ldG1vZEBp ZXRmLm9yZw0KPj4+Pj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 bW9kDQo+Pj4+Pj4NCj4+Pj4+DQo+Pj4+Pi0tIA0KPj4+Pj5MYWRpc2xhdiBMaG90a2EsIENaLk5J QyBMYWJzDQo+Pj4+PlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+Pj4+DQo+Pj4NCj4+Pi0tIA0KPj4+ TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4+UEdQIEtleSBJRDogRTc0RThDMEMNCj4+ DQo+DQo+LS0gDQo+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6IEU3 NEU4QzBDDQoNCg== From nobody Mon Mar 7 17:23:54 2016 Return-Path: X-Original-To: netmod@ietfc.amsl.com Delivered-To: netmod@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DB9DE1CD74E for ; Mon, 7 Mar 2016 17:23:53 -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_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv0kMLbgO7aO for ; Mon, 7 Mar 2016 17:23:52 -0800 (PST) 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 ietfc.amsl.com (Postfix) with ESMTPS id 413AE1CD731 for ; Mon, 7 Mar 2016 17:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13438; q=dns/txt; s=iport; t=1457400232; x=1458609832; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GFF3pIepCGVptP6fHpaQEbuk8qqcjVM6QJFoddJMQI8=; b=Gk3eIhDmRv5pcVRnQmQPB6qv1w9Kk+fW1JSAc/uNIjWJp8EVuDJLbxFj jDMR6Vm54pcjL/7qhNFg69SwH8aic91zyS04sHTJVc2+0dYKjKAviwwf4 q4Q/o7FqvjhHcS/cQ6LEplI9p+6xnn6cY0LqpQc+FZrgYwFyPvsrypFVx s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBIKd5W/4cNJK1cgzpSbQa6QQENg?= =?us-ascii?q?WkXCoUkSgIcgRY4FAEBAQEBAQFkJ4RBAQEBAwEBAQEgETcDEAsCAQgYAgImAgI?= =?us-ascii?q?CJQsVEAIEARIbiAEIDq8PjzQBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHuHCwiBS?= =?us-ascii?q?X2EIhaDAiuBDwWNMIl6AYViiAuBY40XhXmIWwEeAQFCg2RqiQF+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,554,1449532800"; d="scan'208";a="80491767" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Mar 2016 01:23:51 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u281Nohs008876 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Mar 2016 01:23:50 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 19:23:50 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 19:23:50 -0600 From: "Acee Lindem (acee)" To: Ladislav Lhotka , NETMOD Working Group Thread-Topic: [netmod] proposed change to ietf-routing Thread-Index: AQHRcJq0RazNoMs9PkSzBYV8exAQ959GhjuAgAGWzACAAIJSAIABD6YAgAA7AYCABIh4AIAAZxkAgABcIgA= Date: Tue, 8 Mar 2016 01:23:50 +0000 Message-ID: <50233540-A77D-4ABB-84ED-5D33E2FB1A4B@cisco.com> References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> In-Reply-To: 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.201] Content-Type: text/plain; charset="utf-8" Content-ID: <9D9E3A94A7832F4E81C114DB518EEC99@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] proposed change to ietf-routing 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, 08 Mar 2016 01:23:54 -0000 DQo+IE9uIE1hciA3LCAyMDE2LCBhdCA3OjU0IFBNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVA Y2lzY28uY29tPiB3cm90ZToNCj4gDQo+IEhpIExhZGEsIA0KPiANCj4gT24gMy83LzE2LCA4OjQ1 IEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+IA0KPj4gIkFj ZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cml0ZXM6DQo+PiANCj4+PiBIaSBM YWRhLCANCj4+PiANCj4+PiBPbiAzLzQvMTYsIDg6MDAgQU0sICJMYWRpc2xhdiBMaG90a2EiIDxs aG90a2FAbmljLmN6PiB3cm90ZToNCj4+PiANCj4+Pj4gIkFjZWUgTGluZGVtIChhY2VlKSIgPGFj ZWVAY2lzY28uY29tPiB3cml0ZXM6DQo+Pj4+IA0KPj4+Pj4gSGkgTGFkYSwgDQo+Pj4+PiANCj4+ Pj4+IE9uIDMvMy8xNiwgODowMSBBTSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBuaWMuY3o+ IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+Pj4gIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28u Y29tPiB3cml0ZXM6DQo+Pj4+Pj4gDQo+Pj4+Pj4+IEhpIExhZGEsIE5FVE1PRCBXRyBtZW1iZXJz LA0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhlcmUgYXJlIGFjdHVhbGx5IGEgbnVtYmVyIG9mIGNoYW5n ZXMgdGhhdCB3ZSB3b3VsZCBsaWtlIHRvDQo+Pj4+Pj4+IHNlZSBpbiB0aGUgaWV0Zi1yb3V0aW5n IG1vZGVsOg0KPj4+Pj4+PiANCj4+Pj4+Pj4gLSBSZW1vdmUgcm91dGluZy1pbnN0YW5jZXMgc2lu Y2UgaWV0Zi1yb3V0aW5nIHNpbmNlIGl0IHdpbGwgYmUNCj4+Pj4+Pj4gIOKAnG1vdW50ZWTigJ0g YXQgZGlmZmVyZW50IHBvaW50cyBpbiB0aGUgZGV2aWNlIGhpZXJhcmNoeSBkZXBlbmRlbnQNCj4+ Pj4+Pj4gIG9uIHRoZSBkZXZpY2UgcmVxdWlyZW1lbnRzLg0KPj4+Pj4+IA0KPj4+Pj4+IEFncmVl ZC4NCj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IC0gQ29sbGFwc2UgaXQgaW50byBvbmUgbW9k dWxlIHN1cHBvcnRpbmcgZGlmZmVyZW50IGFkZHJlc3MgZmFtaWxpZXMNCj4+Pj4+Pj4gIHJhdGhl ciAzIG1vZHVsZXMgKGJhc2UsIElQdjQsIGFuZCBJUHY2KS4NCj4+Pj4+PiANCj4+Pj4+PiBUaGlz IGlzIHBvc3NpYmxlLCBidXQgd2Ugd291bGQgaGF2ZSB0byBpbnRyb2R1Y2UgYSBtZWNoYW5pc20g Zm9yDQo+Pj4+Pj4gaW1wbGVtZW50YXRpb25zIHN1cHBvcnRpbmcgb25seSBvbmUgb2YgdGhlbS4g SXQgc2VlbXMgdG8gbWUgdGhhdCBpdCBpcw0KPj4+Pj4+IGVhc2llciB0byBzZWxlY3QgbW9kdWxl cyBmb3IgYmFzZSArIGFueSBjb21iaW5hdGlvbiBvZiBhZGRyZXNzDQo+Pj4+Pj4gZmFtaWxpZXMs DQo+Pj4+Pj4gYW5kIGVhY2ggZmFtaWx5IG1vZHVsZSBpbnNlcnRzIGFwcHJvcHJpYXRlIHN0dWZm IHRvIHJpZ2h0IHBsYWNlcyAtIGFuZA0KPj4+Pj4+IHRoZXJlIGlzIHF1aXRlIGEgYnVuY2ggb2Yg dGhlbS4gV2hhdCB5b3UgYXJlIHByb3Bvc2luZyBwcm9iYWJseSBtZWFucw0KPj4+Pj4+IHRoZQ0K Pj4+Pj4+IChzaW5nbGUpIG1vZHVsZSB3b3VsZCBoYXZlIGlmLWZlYXR1cmVzIG9yIHdoZW5zIGlu IGFsbCB0aG9zZSBwbGFjZXMuDQo+Pj4+PiANCj4+Pj4+IEFyZSB0aGVyZSBwbGFubmVkIGltcGxl bWVudGF0aW9ucyByZXF1aXJlZCBZQU5HIG1vZGVscyB3aGVyZSBvbmx5IElQdjQNCj4+Pj4+IG9y DQo+Pj4+PiBJUHY2IGFyZSBzdXBwb3J0ZWQ/IE1heWJlIHdheSBvZmYgaW4gdGhlIGZ1dHVyZSwg d2hlbiB5b3UgYW5kIEkgYXJlDQo+Pj4+PiBib3RoDQo+Pj4+PiBzaXR0aW5nIG9uIGEgYmVhY2gg ZHJpbmtpbmcgYmVlciB0aGVyZSB3aWxsIGJlIElQdjYgb25seSBwcm9kdWN0cyBidXQNCj4+Pj4+ IEkNCj4+Pj4+IGRvbuKAmXQgc2VlIGl0IGhhcHBlbmluZyBzb29uLg0KPj4+Pj4gDQo+Pj4+IA0K Pj4+PiBNYXliZSBzb21lIGV4cGVydHMgaW4gdGhlIGVtYmVkZGVkIGFyZWEgY291bGQgY29tbWVu dCBvbiB0aGlzLCBidXQgSQ0KPj4+PiBiZWxpZXZlIGluIGJvdGggNkxvV1BBTiBhbmQgWmlnQmVl IElQdjYtb25seSBuZXR3b3JrcyBhcmUgY29tbW9ucGxhY2UuDQo+Pj4gDQo+Pj4gT2theSAtIEni gJl2ZSBhbHNvIGhlYXJkIHJlcXVpcmVtZW50cyBmcm9tIGFuIFNQIGZvciBhY2Nlc3MgZGV2aWNl cyB3aXRoDQo+Pj4gb25seSBJUHY2LiBIb3dldmVyLCBpcyBhIHNlcGFyYXRlIG1vZHVsZSByZXF1 aXJlZCBmb3IgdGhpcz8NCj4+IA0KPj4gQW4gSVB2Ni1vbmx5IHN5c3RlbSBzaG91bGQgbm90IGhh dmUgSVB2NC1yZWxhdGVkIG5vZGVzIGluIHRoZSBzY2hlbWEuIEFzDQo+PiBJIHdyb3RlLCBhbHRl cm5hdGl2ZXMgYXJlDQo+PiANCj4+IChhKSBkZWZpbmUgZmVhdHVyZXMgZm9yIGluZGl2aWR1YWwg YWRkcmVzcyBmYW1pbGllcw0KPj4gKGIpIGluY2x1ZGUgY29uZmlndXJhdGlvbiBvZiBhZGRyZXNz IGZhbWlsaWVzLCBhbmQgdGhlbiB1c2UgIndoZW4iDQo+PiBzdGF0ZW1lbnRzIHRvIGNvbnRyb2wg dGhlIHNjaGVtYS4NCj4gDQo+IFdlIGhhdmUgdGhlIGlwLWFkZHJlc3MgdHlwZSB0aGF0IHN1cHBv cnRzIGJvdGjigKYgQ291bGRu4oCZdCB3ZSB1c2UgdGhpcyB0eXBlDQo+IGFuZCBoYXZlIHRoZSBz ZXJ2ZXIgc2ltcGx5IHJldHVybiBhbiBlcnJvciBpZiBhIHJvdXRlIGlzIGNvbmZpZ3VyZWQgZm9y IGFuDQo+IHVuc3VwcG9ydGVkIGFkZHJlc3MgZmFtaWx5PyBTaG91bGQgdGhlIGlldGYteWFuZy10 eXBlcyBtb2R1bGUgYmUNCj4gcmUtcHVibGlzaGVkIHdpdGggaXAtYWRkcmVzcyByZW1vdmVkPw0K PiANCj4gSSBndWVzcyBkb27igJl0IHNlZSB0aGlzIGFzIGEgbWFqb3IgcG9pbnQuDQoNClRoZSB0 aGluZyBhYm91dCB0aGUgc3RhdGljIHJvdXRlIGRlZmluaXRpb24gZm9yIElQdjQgYW5kIElQdjYg aXMgdGhhdCB0aGVpciBSSUJzIHdpbGwgaGF2ZSBwcmV0dHkgbXVjaCB0aGUgc2FtZSBzdHJ1Y3R1 cmUgb3RoZXIgdGhhbiBkaWZmZXJlbmNlcyBpbiBhZGRyZXNzIHR5cGUuIEZvciBvdGhlciBBRnMs IHRoZXJlIG1heSBiZSBvdGhlciBkaWZmZXJlbmNlcyBhcyB3ZWxsLiBGb3IgZXZlcnkgYXVnbWVu dGF0aW9uLCB3ZeKAmXJlIGVzc2VudGlhbGx5IGRvdWJsaW5nIHRoZSBzcGVjaWZpY2F0aW9uIGVm Zm9ydC4gDQoNClRoYW5rcywNCkFjZWUNCg0KDQoNCg0KPiANCj4gDQo+PiANCj4+IFdlIGFsc28g aGF2ZSB0byBjb25zaWRlciBvdGhlciBmYW1pbGllcyB0aGF0IG1heSBiZSBhZGRlZCwgZXZlbiBz b21lDQo+PiB0aGF0IGRvbid0IGV4aXN0IHlldC4NCj4gDQo+IA0KPiBBZ3JlZWQuIFRoZXNlIGNh biBiZSBhZGRlZCB0aHJvdWdoIGF1Z21lbnRhdGlvbi4NCj4gDQo+PiANCj4+PiBpZXRmLXlhbmct dHlwZXMgaGFzIHRoZSB0eXBlIGlwLWFkZHJlc3Mgc3VwcG9ydGluZyBib3RoIEFGcy4gRG9lcw0K Pj4+IHN1cHBvcnRpbmcgb25lIG9yIHRoZSBvdGhlciBBRiBvciBib3RoIG5lZWQgdG8gYmUgZW5m b3JjZWQgd2l0aCBzZXBhcmF0ZQ0KPj4+IG1vZHVsZXM/IEZvciBJUHY0LCB3ZSBhcmUgZ29pbmcg dG8gbmVlZCB0byBzdXBwb3J0IElQdjYgbmV4dC1ob3BzIChyZWZlcg0KPj4+IHRvIFJGQyA1NTQ5 KS4gIA0KPj4+IA0KPj4+IA0KPj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiAtIFJlbW92ZSB0aGUgTkQgKFJGQyA0ODYxKSBSb3V0ZXIgQWR2ZXJ0aXNlbWVu dCBwcm90b2NvbCBzaW5jZSBpdA0KPj4+Pj4+PiAgZG9lc27igJl0IG5lZWQgdG8gYmUgaGVyZS4N Cj4+Pj4+PiANCj4+Pj4+PiBXZWxsLCBSRkMgNDg2MSBzYXlzOiAiQSByb3V0ZXIgTVVTVCBhbGxv dyBmb3IgdGhlIGZvbGxvd2luZyBjb25jZXB0dWFsDQo+Pj4+Pj4gdmFyaWFibGVzIHRvIGJlIGNv bmZpZ3VyZWQgYnkgc3lzdGVtIG1hbmFnZW1lbnQuIg0KPj4+Pj4+IA0KPj4+Pj4+IFNvIEkgZG9u J3QgdGhpbmsgdGhleSBjYW4gYmUgY29uc2lkZXJlZCBvcHRpb25hbC4gV2UgY291bGQgcGVyaGFw cw0KPj4+Pj4+IG1vdmUNCj4+Pj4+PiB0aGVtIHRvIGEgc3VibW9kdWxlIHNvIHRoYXQgdGhleSBk b24ndCBjbHV0dGVyIHRoZSBtYWluIG1vZHVsZS4NCj4+Pj4+IA0KPj4+Pj4gSSBkb27igJl0IGRp c2FncmVlIC0gYnV0IHdoeSBhcmUgdGhleSBncm91cGVkIHdpdGggdGhlIG1haW4gUklCIGFuZA0K Pj4+Pj4gaW5mcmENCj4+Pj4+IGRyYWZ0PyBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBzaG91bGQgYmUg d2l0aCB0aGUgb3RoZXIgUkZDIDQ4NjENCj4+Pj4+IHByb3RvY29scy4NCj4+Pj4+IEl0IGlzIG91 dCBvZiBwbGFjZSBoZXJlLg0KPj4+PiANCj4+Pj4gVGhlIGlkZWEgaXMgdGhhdCBhbnkgZGV2aWNl IHRoYXQgaW1wbGVtZW50cyBpZXRmLXJvdXRpbmcgaXMgcmVxdWlyZWQgdG8NCj4+Pj4gc3VwcG9y dCB0aGVzZSBjb25maWd1cmF0aW9uIHZhcmlhYmxlcywgd2hpY2ggaXMgd2hhdCA0ODYxIHNheXMu DQo+Pj4gDQo+Pj4gQnV0IGl0IHNheXMgbm90aGluZyBhYm91dCB0aGUgb3JnYW5pemF0aW9uIG9m IHRoZSBZQU5HIG1vZHVsZXMgO14pDQo+PiANCj4+IE5vLCBidXQgY3VycmVudGx5IHRoZXJlIGlz IG5vIHdheSB0byBzYXkgdGhhdCBpZiBtb2R1bGUgWCBpcyBpbXBsZW1lbnRlZCwNCj4+IHRoZW4N Cj4+IG1vZHVsZSBZIGhhcyB0byBiZSBpbXBsZW1lbnRlZCwgdG9vLg0KPj4gDQo+Pj4gDQo+Pj4+ IFdpdGggYQ0KPj4+PiBtZWNoYW5pc20gbGlrZSBBbmR5J3MgcGFja2FnZXMgd2Ugd291bGQgaGF2 ZSBtb3JlIGZsZXhpYmlsaXR5LCBidXQgZm9yDQo+Pj4+IHRoZSB0aW1lIGJlaW5nIHRoZSBiZXN0 IHNvbHV0aW9uIHNlZW1zIHRvIGJlIHRvIG1vdmUgUkEgc3R1ZmYgdG8gYQ0KPj4+PiBzdWJtb2R1 bGUuDQo+Pj4gDQo+Pj4gV2h5IHdvdWxkbuKAmXQgUkEgYmUgaW4gYSBzZXBhcmF0ZSBkcmFmdCB3 aXRoIGFsbCB0aGUgb3RoZXIgUkZDIDQ4NjENCj4+PiBwcm90b2NvbHM/DQo+PiANCj4+IEl0IGNv dWxkLCBhbmQgd2UgY291bGQgaG9wZSB0aGF0IHNvbWUgbWVjaGFuaXNtIHdpbGwgYmUgZXN0YWJs aXNoZWQgbGF0ZXINCj4+IGZvcg0KPj4gc3BlY2lmeWluZyBtb2R1bGUgZGVwZW5kZW5jaWVzIGFu ZCBwcmVyZXF1aXNpdGVzLiBJdCdzIElNTyBuZWVkZWQNCj4+IGFueXdheS4NCj4gDQo+IEFSUCBh bmQgQUNMcyBhcmUgYWxzbyBuZWVkZWQgYW55d2F5LCB0aGF0IGRvZXNu4oCZdCBtZWFuIHRoZXkg bmVlZCB0byBiZQ0KPiBpbmNsdWRlZCBpbiB0aGlzIGRyYWZ0Lg0KPiANCj4gQWNlZSANCj4gDQo+ IA0KPj4gDQo+PiBMYWRhDQo+PiANCj4+PiANCj4+PiANCj4+PiANCj4+Pj4gDQo+Pj4+PiANCj4+ Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAtIFN1cHBvcnQgYXQgbGVh c3QgdGhlIG5leHQgaG9wIGVuaGFuY2VtZW50cyBpbg0KPj4+Pj4+PiAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWFjZWUtcnRnd2cteWFuZy1yaWItZXh0ZW5kLTAwDQo+Pj4+Pj4g DQo+Pj4+Pj4gVGhleSBjYW4gYmUgYWRkZWQgdmlhIGF1Z21lbnRzLCBhbmQgbWFueSBwb3RlbnRp YWwgdXNlcnMgb2YgdGhlDQo+Pj4+Pj4gcm91dGluZw0KPj4+Pj4+IG1vZHVsZSAoaG9zdHMgYW5k IHNpbXBsZSByb3V0ZXJzKSBkb24ndCBzdXBwb3J0IHRoZW0uDQo+Pj4+PiANCj4+Pj4+IEFyZSB0 aGVyZSBob3N0cyB0aGF0IGRvbuKAmXQgc3VwcG9ydCBhdCBsZWFzdCBFQ01QPw0KPj4+PiANCj4+ Pj4gSSBhbSBub3Qgc3VyZS4gSWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRoYXQgRUNNUCBpcyByZWFs bHkgdWJpcXVpdG91cywNCj4+Pj4gdGhlbiB3ZSBjYW4gYWRkIGl0Lg0KPj4+PiANCj4+Pj4+IA0K Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gLSBJbmNsdWRlIGF0IGxlYXN0IEVDTVAgaW4gdGhl IHN0YXRpYyByb3V0ZSBjb25maWd1cmF0aW9uLg0KPj4+Pj4+IA0KPj4+Pj4+IFNhbWUgYXMgaW4g dGhlIHByZXZpb3VzIGNhc2U6IGlldGYtcm91dGluZyBwcm92aWRlcyBhIGNob2ljZSBub2RlIGZv cg0KPj4+Pj4+IG5leHQtaG9wcyBpbiBib3RoIFJJQnMgYW5kIHN0YXRpYyByb3V0ZXMsIGFuZCBF Q01QIGlzIGV4cGxpY2l0bHkNCj4+Pj4+PiBtZW50aW9uZWQgYXMgYSBjYW5kaWRhdGUgZm9yIGF1 Z21lbnRhdGlvbi4gV2h5IGlzIGl0IHN1Y2ggYSBiaWcgYQ0KPj4+Pj4+IHByb2JsZW0/DQo+Pj4+ PiANCj4+Pj4+IEl0IGlzIG5vdCBidXQgYXMgbG9uZyBhcyB3ZSBhcmUgY2hhbmdpbmcgdGhlIG1v ZGVsLCB3ZSBtaWdodCBhcyB3ZWxsDQo+Pj4+PiBoYW5kbGUgdGhlIHByZWRvbWluYW50IHVzZSBj YXNlcy4NCj4+Pj4gDQo+Pj4+IE15IGNvbmNlcm4gaXMgdGhhdCBvdGhlciBncm91cHMgbWF5IGNv bWUgdXAgd2l0aCB0aGVpciBmYXZvdXJpdGUNCj4+Pj4gY2FzZXMuIEFueSBuZXcgc3R1ZmYgaW5j cmVhc2VzIHRoZSBsaWtlbGlob29kIHRoYXQgYnVncyBvciBpbmFkZXF1YWNpZXMNCj4+Pj4gd2ls bCBiZSBkaXNjb3ZlcmVkIGluIHRoZSBtb2R1bGUgYWZ0ZXIgaXQgaXMgcHVibGlzaGVkLCBidXQg dGhlbiBpdCB3aWxsDQo+Pj4+IGJlIGEgcHJvYmxlbSBkdWUgdG8gdGhlIGRyYWNvbmlhbiBtb2R1 bGUgdXBkYXRlIHJ1bGVzLiBTbyBJJ2QgcHJlZmVyIHRvDQo+Pj4+IGtlZXAgdGhpcyBtb2R1bGUg cmVhbGx5IHNraW5ueS4NCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+PiAN Cj4+Pj4+Pj4gLSBTdHJ1Y3R1cmUgY29uc2lzdGVudCB3aXRoIHRoZSBvcGVyYXRpb25hbCBzdGF0 ZSByZWNvbW1lbmRhdGlvbi4NCj4+Pj4+Pj4gIEV2ZW4gdy9vIGhhdmluZyB0aGUgZmluYWwgcmVj b21tZW5kYXRpb24sIHRoaXMgbW9kZWwgc2VlbXMgdG8NCj4+Pj4+Pj4gIGJyYW5jaCBiZXR3ZWVu IGNvbmZpZyBhbmQgc3RhdGUgYXQgd2F5IHRvbyBoaWdoIGEgbGV2ZWwuDQo+Pj4+Pj4gDQo+Pj4+ Pj4gQ291bGQgeW91IG91dGxpbmUgdGhlIGNvbmNyZXRlIGNoYW5nZXMgdGhhdCB5b3UgcHJvcG9z ZSBoZXJlPyBUaGUgbW9zdA0KPj4+Pj4+IHNpZ25pZmljYW50IHBhcnQgb2Ygc3RhdGUgZGF0YSBp biB0aGlzIG1vZHVsZSBpcyB0aGUgbGlzdCBvZiBSSUJzLA0KPj4+Pj4+IGFuZCBJDQo+Pj4+Pj4g ZG9uJ3Qgc2VlIGFueSB3YXkgaG93IGl0IGNhbiBiZSBidW5kbGVkIHdpdGggY29uZmlndXJhdGlv biBzb21ld2hlcmUNCj4+Pj4+PiBkZWVwZXIgaW4gdGhlIGhpZXJhcmNoeS4NCj4+Pj4+IA0KPj4+ Pj4gSSBndWVzcyB3ZSB3aWxsIGRpc2N1c3MgdGhpcyBpbiB1cHN0YXRlIGNhbGwgbmV4dCB3ZWVr LiBIb3dldmVyLCBubw0KPj4+Pj4gbWF0dGVyDQo+Pj4+PiB3aGF0IHNvbHV0aW9uIHdlIGNvbWUg dXAgd2l0aCwgaXQgc2VlbXMga2VlcGluZyB0aGUgZGVyaXZlZCBzdGF0ZQ0KPj4+Pj4gY2xvc2Vy DQo+Pj4+PiB0byBpbnRlbmRlZC9hcHBsaWVkIGNvbmZpZyBpcyBiZXR0ZXIuDQo+Pj4+IA0KPj4+ PiBPSy4NCj4+Pj4gDQo+Pj4+IExhZGENCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFRoYW5rcywgDQo+ Pj4+PiBBY2VlIA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBMYWRhDQo+Pj4+Pj4g DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+IEFjZWUNCj4+Pj4+Pj4gDQo+Pj4+ Pj4+IA0KPj4+Pj4+PiBPbiAyLzI2LzE2LCA4OjM2IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBM YWRpc2xhdiBMaG90a2EiDQo+Pj4+Pj4+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgbGhvdGthQG5pYy5jej4gd3JvdGU6DQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gSGksDQo+Pj4+ Pj4+PiANCj4+Pj4+Pj4+IGFzIGEgcGFydCBvZiBzeW5jaHJvbml6YXRpb24gb2YgdGhlIHJvdXRp bmcgZGF0YSBtb2RlbHMgdGhhdCBhcmUNCj4+Pj4+Pj4+IGJlaW5nDQo+Pj4+Pj4+PiBkZXZlbG9w ZWQgYnkgdGhlIE5FVE1PRCBhbmQgUlRHIHdvcmtpbmcgZ3JvdXBzLCB0aGUgYXV0aG9ycyBvZg0K Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcgcHJvcG9zZSB0byByZW1vdmUg dGhlIHJvdXRpbmctaW5zdGFuY2UNCj4+Pj4+Pj4+IGxldmVsIGluIHRoZSBkYXRhIGhpZXJhcmNo eSwgYW5kIGxlYXZlIGl0IHRvIHN0cnVjdHVyYWwtbW91bnQvWVNETA0KPj4+Pj4+Pj4gdG8NCj4+ Pj4+Pj4+IHByb3ZpZGUgYSB0b3AgbGV2ZWwgc3RydWN0dXJlLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBTY2hlbWF0aWNhbGx5LCB0aGUgY29uZmlndXJhdGlvbiBhbmQgc3RhdGUgZGF0YSBzdWJ0cmVl cyBvZg0KPj4+Pj4+Pj4gaWV0Zi1yb3V0aW5nDQo+Pj4+Pj4+PiB3b3VsZCBiZSByZWR1Y2VkIHRv IHNvbWV0aGluZyBsaWtlIHRoaXM6DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IG1vZHVsZTogaWV0Zi1y b3V0aW5nDQo+Pj4+Pj4+PiAgKy0tcm8gcm91dGluZy1zdGF0ZQ0KPj4+Pj4+Pj4gIHwgICstLXJv IHJvdXRlci1pZD8gICAgICAgICAgIHlhbmc6ZG90dGVkLXF1YWQNCj4+Pj4+Pj4+ICB8ICArLS1y byBpbnRlcmZhY2VzDQo+Pj4+Pj4+PiAgfCAgfCAgKy0tcm8gaW50ZXJmYWNlKiAgIGlmOmludGVy ZmFjZS1zdGF0ZS1yZWYNCj4+Pj4+Pj4+ICB8ICArLS1ybyByb3V0aW5nLXByb3RvY29scw0KPj4+ Pj4+Pj4gIHwgIHwgICstLXJvIHJvdXRpbmctcHJvdG9jb2wqIFt0eXBlIG5hbWVdDQo+Pj4+Pj4+ PiAgfCAgfCAgICAgLi4uDQo+Pj4+Pj4+PiAgfCAgKy0tcm8gcmlicw0KPj4+Pj4+Pj4gIHwgICAg ICstLXJvIHJpYiogW25hbWVdDQo+Pj4+Pj4+PiAgfCAgICAgICAgLi4uDQo+Pj4+Pj4+PiAgKy0t cncgcm91dGluZw0KPj4+Pj4+Pj4gICAgICstLXJ3IHJvdXRlci1pZD8gICAgICAgICAgIHlhbmc6 ZG90dGVkLXF1YWQNCj4+Pj4+Pj4+ICAgICArLS1ydyBkZXNjcmlwdGlvbj8gICAgICAgICBzdHJp bmcNCj4+Pj4+Pj4+ICAgICArLS1ydyByb3V0aW5nLXByb3RvY29scw0KPj4+Pj4+Pj4gICAgIHwg ICstLXJ3IHJvdXRpbmctcHJvdG9jb2wqIFt0eXBlIG5hbWVdDQo+Pj4+Pj4+PiAgICAgfCAgICAg Li4uDQo+Pj4+Pj4+PiAgICAgKy0tcncgcmlicw0KPj4+Pj4+Pj4gICAgICAgICstLXJ3IHJpYiog W25hbWVdDQo+Pj4+Pj4+PiAJICAgIC4uLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBBcmUgdGhlcmUg YW55IG9iamVjdGlvbnMgdG8gdGhpcyBjaGFuZ2U/DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFRoYW5r cywNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gQWNlZSBhbmQgTGFkYQ0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiAtLQ0KPj4+Pj4+Pj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4+Pj4+Pj4gUEdQ IEtleSBJRDogRTc0RThDMEMNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+IG5ldG1vZEBpZXRm Lm9yZw0KPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QNCj4+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gLS0gDQo+Pj4+Pj4gTGFkaXNsYXYgTGhvdGth LCBDWi5OSUMgTGFicw0KPj4+Pj4+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+Pj4+PiANCj4+Pj4g DQo+Pj4+IC0tIA0KPj4+PiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+Pj4+IFBHUCBL ZXkgSUQ6IEU3NEU4QzBDDQo+Pj4gDQo+PiANCj4+IC0tIA0KPj4gTGFkaXNsYXYgTGhvdGthLCBD Wi5OSUMgTGFicw0KPj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QN Cj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQoNCg== From nobody Mon Mar 7 19:25:51 2016 Return-Path: X-Original-To: netmod@ietfc.amsl.com Delivered-To: netmod@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 689CC1CDB40 for ; Mon, 7 Mar 2016 19:25:49 -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.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YDOWtlV_mJv for ; Mon, 7 Mar 2016 19:25:47 -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 ietfc.amsl.com (Postfix) with ESMTPS id CD68C1CDB3F for ; Mon, 7 Mar 2016 19:25:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFL53668; Tue, 08 Mar 2016 03:25:45 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Mar 2016 03:25:44 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Tue, 8 Mar 2016 11:25:36 +0800 From: "Zhuangyan (Yan)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft Thread-Index: AQHRc0XzOmgxKIY1jkmkuTyx7LV2V59Oz5EQ Date: Tue, 8 Mar 2016 03:25:36 +0000 Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785941CF67E@nkgeml513-mbx.china.huawei.com> References: 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_9B4BC45FDEDDD84F813E9E4A5BAF8785941CF67Enkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56DE4639.0085, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 28327137114706db6f692c780a0201dc Archived-At: Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft 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, 08 Mar 2016 03:25:49 -0000 --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785941CF67Enkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgZm9yIHRoZSBsYXRlIHJlc3BvbnNlLiBJdCB0b29rIHNvbWUgdGltZSB0byByZXZpZXcg dGhpcyBkcmFmdCBhbmQgbW9kZWxzLiAgQW5kIFllcywgSSBzdXBwb3J0IGFkb3B0aW5nIHRoaXMg ZG9jdW1lbnQgYXMgYSBXRyBpdGVtLg0KDQpUbyBtZSwgdGhlIGNvbW1vbiBtb2RlbCBpcyBzb21l dGhpbmcgdXNlZnVsLiBUaGVyZSBwZXJoYXBzIHNvbWUgb3ZlcmxhcHMgaW4gRXRoZXJuZXQtbGlr ZSBtb2RlbCB3aXRoIHRoaW5ncyBpbiBJRUVFLiBJZiB5ZXMsIHdl4oCZbGwgc2VlIGhvdyB0byBj b29wZXJhdGUuDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoNCg0KDQpZYW4NCg0K5Y+R5Lu25Lq6OiBu ZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEtlbnQgV2F0c2Vu DQrlj5HpgIHml7bpl7Q6IDIwMTblubQz5pyIMeaXpSA3OjA3DQrmlLbku7bkuro6IG5ldG1vZEBp ZXRmLm9yZw0K5Li76aKYOiBSZTogW25ldG1vZF0gY2FsbCBmb3IgY29uc2Vuc3VzIHRvIGFkb3B0 IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZyBhcyBORVRNT0QgV0cgZHJhZnQNCg0K DQpUaGUgY2hhaXJzIHdlcmUganVzdCByZXZpZXdpbmcgbm90ZXMgYW5kIHJlYWxpemVkIHRoYXQg dGhpcyB0aHJlYWQgbmV2ZXIgY2xvc2VkIHByb3Blcmx5Lg0KDQpKdWVyZ2VuIGhhcyBzb21lIGNv bmNlcm5zIHJlZ2FyZGluZyByZWFsaXN0aWMgbWlsZXN0b25lcywgdGhhdCB3ZXJlIG5ldmVyIGFk ZHJlc3NlZC4gIFJvYmVydCwgY2FuIHlvdSBwbGVhc2UgdHJ5IHRvIGFkZHJlc3MgSnVlcmdlbuKA mXMgY29uY2VybnMgbm93Pw0KDQpBbHNvLCB0aGVyZSB3ZXJlIG9ubHkgYSB0d28gcmVzcG9uc2Vz IGJlZm9yZSBpbmRpY2F0aW5nIHdpbGxpbmduZXNzIHRvIHJldmlldyB0aGUgZHJhZnQgYXMgaXQg cHJvZ3Jlc3NlcyAodGhhbmtzIERhbiBhbmQgTWFydGluKS4gIENhbiBvdGhlcnMgdGhhdCBzdXBw b3J0IHRoaXMgZHJhZnQgYW5kIHdpbGxpbmcgdG8gcmV2aWV3IHRoaXMgZHJhZnQgc2F5IHNvPw0K DQpUaGFua3MsDQpOZXRtb2QgQ2hhaXJzDQoNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2Yg S2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5u ZXQ+Pg0KRGF0ZTogVHVlc2RheSwgRGVjZW1iZXIgMTUsIDIwMTUgYXQgMTE6NDggQU0NClRvOiAi bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW25ldG1vZF0gY2FsbCBmb3IgY29u c2Vuc3VzIHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZyBhcyBORVRN T0QgV0cgZHJhZnQNCg0KDQpUaGUgbWludXRlcyBmb3IgSUVURiA5NCBzaG93IHRoYXQgdGhlcmUg d2FzIGluLXJvb20gc3VwcG9ydCBmb3IgYWRvcHRpbmcgZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRm LWV4dC15YW5nIGFzIGEgV0cgZHJhZnQuICAgVGhlIG1pbnV0ZXMgYWxzbyBzaG93IHRoYXQgdGhp cyBkZWNpc2lvbiB3b3VsZCBiZSBjb25maXJtZWQgb24gdGhlIG1haWxpbmcgbGlzdCwgd2hpY2gg SSBhbSBkb2luZyBub3cuDQoNClNob3VsZCB3ZSBtb3ZlIHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1u ZXRtb2QtaW50Zi1leHQteWFuZyBhcyBhIFdHIGl0ZW0gYW5kIGNvcnJlc3BvbmRpbmdseSBhZGQg dGhpcyB0byB0aGUgV0cgY2hhcnRlciBhcyBhIG1pbGVzdG9uZT8gIFBsZWFzZSBjb21tZW50IGJ5 IFR1ZXNkYXksIERlY2VtYmVyIDIyLCAyMDE1IGF0IDlBTSBFU1QgYXQgd2hpY2ggdGltZSB0aGUg V0cgQ2hhaXJzIHdpbGwgZ2F1Z2Ugd2hldGhlciBvciBub3QgdGhlcmUgaXMgY29uc2Vuc3VzIHRv IG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBkb2N1bWVudC4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg== --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785941CF67Enkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLnuq/mlofmnKwgQ2hhciI7 DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjVw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwg bGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OuWu i+S9kzt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH 5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5DaGFyMA0KCXttc28tc3R5bGUtbmFtZToi57qv 5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrn uq/mlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U29y cnkgZm9yIHRoZSBsYXRlIHJlc3BvbnNlLiBJdCB0b29rIHNvbWUgdGltZSB0byByZXZpZXcgdGhp cyBkcmFmdCBhbmQgbW9kZWxzLiAmbmJzcDtBbmQgWWVzLCBJIHN1cHBvcnQgYWRvcHRpbmcgdGhp cyBkb2N1bWVudCBhcyBhIFdHIGl0ZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5U byBtZSwgdGhlIGNvbW1vbiBtb2RlbCBpcyBzb21ldGhpbmcgdXNlZnVsLiBUaGVyZSBwZXJoYXBz IHNvbWUgb3ZlcmxhcHMgaW4gRXRoZXJuZXQtbGlrZSBtb2RlbCB3aXRoIHRoaW5ncyBpbiBJRUVF LiBJZiB5ZXMsIHdl4oCZbGwgc2VlIGhvdyB0byBjb29wZXJhdGUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJlc3Qg UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+WWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gbmV0bW9k IFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPuS7o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+S2VudCBXYXRzZW48YnI+DQo8L3NwYW4+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4gMjAxNjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0PHNwYW4g bGFuZz0iRU4tVVMiPjM8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjE8L3NwYW4+5pelPHNw YW4gbGFuZz0iRU4tVVMiPiA3OjA3PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IG5ldG1vZEBpZXRmLm9yZzxi cj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiPiBSZTogW25ldG1vZF0gY2FsbCBmb3IgY29uc2Vuc3VzIHRvIGFkb3B0IGRy YWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZyBhcyBORVRNT0QgV0cgZHJhZnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6YmxhY2siPlRoZSBjaGFpcnMgd2VyZSBqdXN0IHJldmlld2luZyBub3RlcyBhbmQgcmVh bGl6ZWQgdGhhdCB0aGlzIHRocmVhZCBuZXZlciBjbG9zZWQgcHJvcGVybHkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5KdWVyZ2VuIGhhcyBzb21lIGNv bmNlcm5zIHJlZ2FyZGluZyByZWFsaXN0aWMgbWlsZXN0b25lcywgdGhhdCB3ZXJlIG5ldmVyIGFk ZHJlc3NlZC4gJm5ic3A7Um9iZXJ0LCBjYW4geW91IHBsZWFzZSB0cnkgdG8gYWRkcmVzcyBKdWVy Z2Vu4oCZcyBjb25jZXJucyBub3c/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOmJsYWNrIj5BbHNvLCB0aGVyZSB3ZXJlIG9ubHkgYSB0d28gcmVzcG9uc2VzIGJlZm9y ZSBpbmRpY2F0aW5nIHdpbGxpbmduZXNzIHRvIHJldmlldyB0aGUgZHJhZnQgYXMgaXQgcHJvZ3Jl c3NlcyAodGhhbmtzIERhbiBhbmQgTWFydGluKS4gJm5ic3A7Q2FuIG90aGVycyB0aGF0IHN1cHBv cnQgdGhpcw0KIGRyYWZ0IGFuZCB3aWxsaW5nIHRvIHJldmlldyB0aGlzIGRyYWZ0IHNheSBzbz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+TmV0bW9kIENoYWlyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5uZXRtb2QgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNl c0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg S2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Ij5rd2F0 c2VuQGp1bmlwZXIubmV0PC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgRGVjZW1i ZXIgMTUsIDIwMTUgYXQgMTE6NDggQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1h aWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPltuZXRtb2RdIGNhbGwgZm9yIGNvbnNlbnN1cyB0byBhZG9wdCBkcmFm dC13aWx0b24tbmV0bW9kLWludGYtZXh0LXlhbmcgYXMgTkVUTU9EIFdHIGRyYWZ0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlIG1pbnV0ZXMgZm9yIElFVEYgOTQgc2hvdyB0aGF0 IHRoZXJlIHdhcyBpbi1yb29tIHN1cHBvcnQgZm9yIGFkb3B0aW5nJm5ic3A7ZHJhZnQtd2lsdG9u LW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIGEgV0cgZHJhZnQuICZuYnNwOyBUaGUgbWludXRlcyBh bHNvIHNob3cNCiB0aGF0IHRoaXMgZGVjaXNpb24gd291bGQgYmUgY29uZmlybWVkIG9uIHRoZSBt YWlsaW5nIGxpc3QsIHdoaWNoIEkgYW0gZG9pbmcgbm93LiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TaG91bGQgd2Ug bW92ZSB0byBhZG9wdCBkcmFmdC13aWx0b24tbmV0bW9kLWludGYtZXh0LXlhbmcgYXMgYSBXRyBp dGVtIGFuZCBjb3JyZXNwb25kaW5nbHkgYWRkIHRoaXMgdG8gdGhlIFdHIGNoYXJ0ZXIgYXMgYSBt aWxlc3RvbmU/ICZuYnNwO1BsZWFzZSBjb21tZW50DQogYnkgVHVlc2RheSwgRGVjZW1iZXIgMjIs IDIwMTUgYXQgOUFNIEVTVCBhdCB3aGljaCB0aW1lIHRoZSBXRyBDaGFpcnMgd2lsbCBnYXVnZSB3 aGV0aGVyIG9yIG5vdCB0aGVyZSBpcyBjb25zZW5zdXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhl IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5LZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785941CF67Enkgeml513mbxchi_-- From nobody Mon Mar 7 22:47:33 2016 Return-Path: X-Original-To: netmod@ietfc.amsl.com Delivered-To: netmod@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 707FF1CE0E7 for ; Mon, 7 Mar 2016 22:47:31 -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.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id si3AdwkCxuet for ; Mon, 7 Mar 2016 22:47:29 -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 ietfc.amsl.com (Postfix) with ESMTPS id C75271CE0E6 for ; Mon, 7 Mar 2016 22:47: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 59421224A; Tue, 8 Mar 2016 07:47:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Tbl7SbXRu2Wh; Tue, 8 Mar 2016 07:47: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; Tue, 8 Mar 2016 07:47:26 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F5EF20038; Tue, 8 Mar 2016 07:47:26 +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 5Dran_nfcHb9; Tue, 8 Mar 2016 07:47: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 C74ED2003A; Tue, 8 Mar 2016 07:47:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A68723A2A112; Tue, 8 Mar 2016 07:47:19 +0100 (CET) Date: Tue, 8 Mar 2016 07:47:19 +0100 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20160308064719.GA5979@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Ladislav Lhotka , NETMOD Working Group References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> <50233540-A77D-4ABB-84ED-5D33E2FB1A4B@cisco.com> 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: <50233540-A77D-4ABB-84ED-5D33E2FB1A4B@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] proposed change to ietf-routing 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: Tue, 08 Mar 2016 06:47:31 -0000 On Tue, Mar 08, 2016 at 01:23:50AM +0000, Acee Lindem (acee) wrote: > > The thing about the static route definition for IPv4 and IPv6 is that their RIBs will have pretty much the same structure other than differences in address type. For other AFs, there may be other differences as well. For every augmentation, we’re essentially doubling the specification effort. > One benefit of having separate augmentations is that the data types are tighter. For example, the data model does not allow an IPv6 next hop for an IPv4 prefix, i.e., you can't mess up address families since the data model forces a clear separation (and generic validation will catch that in contrast to having the runtime catching inconsistent address family data). How much that matters likely can be debated. But somehow it feels like keeping things separate allows for independent evolution, which may proof to be very handy in the future. I kind of liked Lada's approach to maintain the architectural separation in the data model. /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 7 22:53:09 2016 Return-Path: X-Original-To: netmod@ietfc.amsl.com Delivered-To: netmod@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 838191CE0F8 for ; Mon, 7 Mar 2016 22:53:09 -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.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSgnP7-ZRu9p for ; Mon, 7 Mar 2016 22:53:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfc.amsl.com (Postfix) with ESMTP id 9E67D1CE0F7 for ; Mon, 7 Mar 2016 22:53:08 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 91AB31AE0144; Tue, 8 Mar 2016 07:53:07 +0100 (CET) Date: Tue, 08 Mar 2016 07:55:37 +0100 (CET) Message-Id: <20160308.075537.1138440427020216868.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160308064719.GA5979@elstar.local> References: <50233540-A77D-4ABB-84ED-5D33E2FB1A4B@cisco.com> <20160308064719.GA5979@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] proposed change to ietf-routing 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, 08 Mar 2016 06:53:09 -0000 SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU+IHdyb3RlOg0KPiBPbiBUdWUsIE1hciAwOCwgMjAxNiBhdCAwMToyMzo1MEFNICswMDAwLCBB Y2VlIExpbmRlbSAoYWNlZSkgd3JvdGU6DQo+ID4gDQo+ID4gVGhlIHRoaW5nIGFib3V0IHRoZSBz dGF0aWMgcm91dGUgZGVmaW5pdGlvbiBmb3IgSVB2NCBhbmQgSVB2NiBpcyB0aGF0IHRoZWlyIFJJ QnMgd2lsbCBoYXZlIHByZXR0eSBtdWNoIHRoZSBzYW1lIHN0cnVjdHVyZSBvdGhlciB0aGFuIGRp ZmZlcmVuY2VzIGluIGFkZHJlc3MgdHlwZS4gRm9yIG90aGVyIEFGcywgdGhlcmUgbWF5IGJlIG90 aGVyIGRpZmZlcmVuY2VzIGFzIHdlbGwuIEZvciBldmVyeSBhdWdtZW50YXRpb24sIHdl4oCZcmUg ZXNzZW50aWFsbHkgZG91YmxpbmcgdGhlIHNwZWNpZmljYXRpb24gZWZmb3J0LiANCj4gPg0KPiAN Cj4gT25lIGJlbmVmaXQgb2YgaGF2aW5nIHNlcGFyYXRlIGF1Z21lbnRhdGlvbnMgaXMgdGhhdCB0 aGUgZGF0YSB0eXBlcw0KPiBhcmUgdGlnaHRlci4gRm9yIGV4YW1wbGUsIHRoZSBkYXRhIG1vZGVs IGRvZXMgbm90IGFsbG93IGFuIElQdjYgbmV4dA0KPiBob3AgZm9yIGFuIElQdjQgcHJlZml4LCBp LmUuLCB5b3UgY2FuJ3QgbWVzcyB1cCBhZGRyZXNzIGZhbWlsaWVzIHNpbmNlDQo+IHRoZSBkYXRh IG1vZGVsIGZvcmNlcyBhIGNsZWFyIHNlcGFyYXRpb24gKGFuZCBnZW5lcmljIHZhbGlkYXRpb24g d2lsbA0KPiBjYXRjaCB0aGF0IGluIGNvbnRyYXN0IHRvIGhhdmluZyB0aGUgcnVudGltZSBjYXRj aGluZyBpbmNvbnNpc3RlbnQNCj4gYWRkcmVzcyBmYW1pbHkgZGF0YSkuDQo+IA0KPiBIb3cgbXVj aCB0aGF0IG1hdHRlcnMgbGlrZWx5IGNhbiBiZSBkZWJhdGVkLiBCdXQgc29tZWhvdyBpdCBmZWVs cyBsaWtlDQo+IGtlZXBpbmcgdGhpbmdzIHNlcGFyYXRlIGFsbG93cyBmb3IgaW5kZXBlbmRlbnQg ZXZvbHV0aW9uLCB3aGljaCBtYXkNCj4gcHJvb2YgdG8gYmUgdmVyeSBoYW5keSBpbiB0aGUgZnV0 dXJlLiBJIGtpbmQgb2YgbGlrZWQgTGFkYSdzIGFwcHJvYWNoDQo+IHRvIG1haW50YWluIHRoZSBh cmNoaXRlY3R1cmFsIHNlcGFyYXRpb24gaW4gdGhlIGRhdGEgbW9kZWwuDQoNCkkgYWdyZWUuICBJ IHRoaW5rIHRoZSBtb2RlbCBpcyBtb3JlIGNsZWFyIHRoaXMgd2F5LiAgSSBndWVzcyBJIGRvbid0 DQp1bmRlcnN0YW5kIHdoeSBBY2VlIHdhbnRzIHRvIGhhdmUgYSBzaW5nbGUgbW9kdWxlPw0KDQoN Ci9tYXJ0aW4NCg== From nobody Tue Mar 8 00:09:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE4E12D4FF for ; Mon, 7 Mar 2016 23:45:28 -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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGPAdDts08lS for ; Mon, 7 Mar 2016 23:45:26 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4EC12D505 for ; Mon, 7 Mar 2016 23:45:24 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 578201CC0156; Tue, 8 Mar 2016 08:36:51 +0100 (CET) From: Ladislav Lhotka To: "Yingzhen Qu \(yiqu\)" , "Acee Lindem \(acee\)" , "'netmod\@ietf.org'" In-Reply-To: References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 08 Mar 2016 08:36:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] proposed change to ietf-routing 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, 08 Mar 2016 07:45:29 -0000 "Yingzhen Qu (yiqu)" writes: > Hi Lada, > > For ECMP, we can actually define the next-hop as a list, so if there is > only one element in the list it=C2=B9s the simple next-hop case, and for = ECMP > there are multiple elements in the list. RIB is more complete by adding > ECMP support. We already had ECMP nexthops in rev. 16 (look for "multipath-entry"): https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16 They were removed along with other fancy next-hops in the interest of finishing this data model soon/ever. I still think ECMP can be easily added via augments, but if there is consensus that ECMP is really ubiquitous, we can put that stuff back, perhaps conditionally using a feature (as it was in rev. 16). Lada > > Thanks, > Yingzhen > > On 3/4/16, 5:00 AM, "netmod on behalf of Ladislav Lhotka" > wrote: > >>"Acee Lindem (acee)" writes: >> >>> Hi Lada,=20 >>> >>> On 3/3/16, 8:01 AM, "Ladislav Lhotka" wrote: >>> >>>>"Acee Lindem (acee)" writes: >>>> >>>>> Hi Lada, NETMOD WG members, >>>>> >>>>> There are actually a number of changes that we would like to >>>>> see in the ietf-routing model: >>>>> >>>>> - Remove routing-instances since ietf-routing since it will be >>>>> =C2=B3mounted=C2=B2 at different points in the device hierarchy dep= endent >>>>> on the device requirements. >>>> >>>>Agreed. >>>> >>>>> >>>>> - Collapse it into one module supporting different address families >>>>> rather 3 modules (base, IPv4, and IPv6). >>>> >>>>This is possible, but we would have to introduce a mechanism for >>>>implementations supporting only one of them. It seems to me that it is >>>>easier to select modules for base + any combination of address families, >>>>and each family module inserts appropriate stuff to right places - and >>>>there is quite a bunch of them. What you are proposing probably means >>>>the >>>>(single) module would have if-features or whens in all those places. >>> >>> Are there planned implementations required YANG models where only IPv4 >>>or >>> IPv6 are supported? Maybe way off in the future, when you and I are both >>> sitting on a beach drinking beer there will be IPv6 only products but I >>> don=C2=B9t see it happening soon. >>> >> >>Maybe some experts in the embedded area could comment on this, but I >>believe in both 6LoWPAN and ZigBee IPv6-only networks are commonplace. >> >>> >>> >>>> >>>>> >>>>> - Remove the ND (RFC 4861) Router Advertisement protocol since it >>>>> doesn=C2=B9t need to be here. >>>> >>>>Well, RFC 4861 says: "A router MUST allow for the following conceptual >>>>variables to be configured by system management." >>>> >>>>So I don't think they can be considered optional. We could perhaps move >>>>them to a submodule so that they don't clutter the main module. >>> >>> I don=C2=B9t disagree - but why are they grouped with the main RIB and = infra >>> draft? Router Advertisement should be with the other RFC 4861 protocols. >>> It is out of place here. >> >>The idea is that any device that implements ietf-routing is required to >>support these configuration variables, which is what 4861 says. With a >>mechanism like Andy's packages we would have more flexibility, but for >>the time being the best solution seems to be to move RA stuff to a >>submodule. >> >>> >>> >>> >>>> >>>>> >>>>> - Support at least the next hop enhancements in >>>>> https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-00 >>>> >>>>They can be added via augments, and many potential users of the routing >>>>module (hosts and simple routers) don't support them. >>> >>> Are there hosts that don=C2=B9t support at least ECMP? >> >>I am not sure. If there is consensus that ECMP is really ubiquitous, >>then we can add it. >> >>> >>>> >>>>> >>>>> - Include at least ECMP in the static route configuration. >>>> >>>>Same as in the previous case: ietf-routing provides a choice node for >>>>next-hops in both RIBs and static routes, and ECMP is explicitly >>>>mentioned as a candidate for augmentation. Why is it such a big a >>>>problem? >>> >>> It is not but as long as we are changing the model, we might as well >>> handle the predominant use cases. >> >>My concern is that other groups may come up with their favourite >>cases. Any new stuff increases the likelihood that bugs or inadequacies >>will be discovered in the module after it is published, but then it will >>be a problem due to the draconian module update rules. So I'd prefer to >>keep this module really skinny. >> >>> >>> >>>> >>>>> >>>>> - Structure consistent with the operational state recommendation. >>>>> Even w/o having the final recommendation, this model seems to >>>>> branch between config and state at way too high a level. >>>> >>>>Could you outline the concrete changes that you propose here? The most >>>>significant part of state data in this module is the list of RIBs, and I >>>>don't see any way how it can be bundled with configuration somewhere >>>>deeper in the hierarchy. >>> >>> I guess we will discuss this in upstate call next week. However, no >>>matter >>> what solution we come up with, it seems keeping the derived state closer >>> to intended/applied config is better. >> >>OK. >> >>Lada >> >>> >>> Thanks,=20 >>> Acee=20 >>> >>> >>>> >>>>Lada >>>> >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> >>>>> On 2/26/16, 8:36 AM, "netmod on behalf of Ladislav Lhotka" >>>>> wrote: >>>>> >>>>>>Hi, >>>>>> >>>>>>as a part of synchronization of the routing data models that are being >>>>>>developed by the NETMOD and RTG working groups, the authors of >>>>>>draft-ietf-netmod-routing-cfg propose to remove the routing-instance >>>>>>level in the data hierarchy, and leave it to structural-mount/YSDL to >>>>>>provide a top level structure. >>>>>> >>>>>>Schematically, the configuration and state data subtrees of >>>>>>ietf-routing >>>>>>would be reduced to something like this: >>>>>> >>>>>>module: ietf-routing >>>>>> +--ro routing-state >>>>>> | +--ro router-id? yang:dotted-quad >>>>>> | +--ro interfaces >>>>>> | | +--ro interface* if:interface-state-ref >>>>>> | +--ro routing-protocols >>>>>> | | +--ro routing-protocol* [type name] >>>>>> | | ... >>>>>> | +--ro ribs >>>>>> | +--ro rib* [name] >>>>>> | ... >>>>>> +--rw routing >>>>>> +--rw router-id? yang:dotted-quad >>>>>> +--rw description? string >>>>>> +--rw routing-protocols >>>>>> | +--rw routing-protocol* [type name] >>>>>> | ... >>>>>> +--rw ribs >>>>>> +--rw rib* [name] >>>>>> ... >>>>>> >>>>>>Are there any objections to this change? >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Acee and Lada >>>>>>=20 >>>>>>-- >>>>>>Ladislav Lhotka, CZ.NIC Labs >>>>>>PGP Key ID: E74E8C0C >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>netmod mailing list >>>>>>netmod@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>> >>>>--=20 >>>>Ladislav Lhotka, CZ.NIC Labs >>>>PGP Key ID: E74E8C0C >>> >> >>--=20 >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C >> >>_______________________________________________ >>netmod mailing list >>netmod@ietf.org >>https://www.ietf.org/mailman/listinfo/netmod > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 8 03:08:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E839E12D65D for ; Tue, 8 Mar 2016 03:08:11 -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_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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUMaoVqXThPv for ; Tue, 8 Mar 2016 03:08:10 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970FD12D65A for ; Tue, 8 Mar 2016 03:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2102; q=dns/txt; s=iport; t=1457435290; x=1458644890; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BuWQRr2T9k4mi5aoeDzclqfgc8yGv/sale4QlnM9G9o=; b=T7eWpdZNswDKdJDOThE/PDd3VNhqzb00IZnwhgZsfe61s5TcNiyTS7QY DpspNj+xVXl2AeDgMoFCo5N2Vxr2O/ulHLvIeYpPVbQQQNYXqlbjGawXz NfCTN1NY+6B2ESCk9o795waeWoPjZF4l94e3rvZwKv67nLXBC0l3UCbtA M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeBQAvst5W/5hdJa1ZA4M6Um0GulOBa?= =?us-ascii?q?R2FcgIcgRo6EgEBAQEBAQFkHAuEQgEBBCMRRQ4CAgEIEAgCAiYCAgIZFxUQAgQ?= =?us-ascii?q?OBYgkrwaPLgEBAQEBAQEBAQEBAQEBAQEBAQEBARUEd4lahFALJoI5gToFlyoBj?= =?us-ascii?q?W2Oe45VAScGNYNkaohGJRZ+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,556,1449532800"; d="scan'208";a="80756204" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2016 11:07:57 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u28B7v1s013618 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Mar 2016 11:07:57 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Mar 2016 05:07:56 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Tue, 8 Mar 2016 05:07:56 -0600 From: "Acee Lindem (acee)" To: "j.schoenwaelder@jacobs-university.de" Thread-Topic: [netmod] proposed change to ietf-routing Thread-Index: AQHRcJq0RazNoMs9PkSzBYV8exAQ959GhjuAgAGWzACAAIJSAIABD6YAgAA7AYCABIh4AIAAZxkAgABcIgCAAFpkgP//9P0A Date: Tue, 8 Mar 2016 11:07:56 +0000 Message-ID: References: <3AA49C4C-3245-465F-A8D9-2AB87F5C3B3A@nic.cz> <50233540-A77D-4ABB-84ED-5D33E2FB1A4B@cisco.com> <20160308064719.GA5979@elstar.local> In-Reply-To: <20160308064719.GA5979@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.116.152.199] Content-Type: text/plain; charset="utf-8" Content-ID: <5387495ECA6326499D2416181BCB11ED@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] proposed change to ietf-routing 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, 08 Mar 2016 11:08:12 -0000 DQoNCk9uIDMvOC8xNiwgMTo0NyBBTSwgImouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0 eS5kZSINCjxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KDQo+ T24gVHVlLCBNYXIgMDgsIDIwMTYgYXQgMDE6MjM6NTBBTSArMDAwMCwgQWNlZSBMaW5kZW0gKGFj ZWUpIHdyb3RlOg0KPj4gDQo+PiBUaGUgdGhpbmcgYWJvdXQgdGhlIHN0YXRpYyByb3V0ZSBkZWZp bml0aW9uIGZvciBJUHY0IGFuZCBJUHY2IGlzIHRoYXQNCj4+dGhlaXIgUklCcyB3aWxsIGhhdmUg cHJldHR5IG11Y2ggdGhlIHNhbWUgc3RydWN0dXJlIG90aGVyIHRoYW4NCj4+ZGlmZmVyZW5jZXMg aW4gYWRkcmVzcyB0eXBlLiBGb3Igb3RoZXIgQUZzLCB0aGVyZSBtYXkgYmUgb3RoZXINCj4+ZGlm ZmVyZW5jZXMgYXMgd2VsbC4gRm9yIGV2ZXJ5IGF1Z21lbnRhdGlvbiwgd2XigJlyZSBlc3NlbnRp YWxseSBkb3VibGluZw0KPj50aGUgc3BlY2lmaWNhdGlvbiBlZmZvcnQuDQo+Pg0KPg0KPk9uZSBi ZW5lZml0IG9mIGhhdmluZyBzZXBhcmF0ZSBhdWdtZW50YXRpb25zIGlzIHRoYXQgdGhlIGRhdGEg dHlwZXMNCj5hcmUgdGlnaHRlci4gRm9yIGV4YW1wbGUsIHRoZSBkYXRhIG1vZGVsIGRvZXMgbm90 IGFsbG93IGFuIElQdjYgbmV4dA0KPmhvcCBmb3IgYW4gSVB2NCBwcmVmaXgsIGkuZS4sIHlvdSBj YW4ndCBtZXNzIHVwIGFkZHJlc3MgZmFtaWxpZXMgc2luY2UNCj50aGUgZGF0YSBtb2RlbCBmb3Jj ZXMgYSBjbGVhciBzZXBhcmF0aW9uIChhbmQgZ2VuZXJpYyB2YWxpZGF0aW9uIHdpbGwNCj5jYXRj aCB0aGF0IGluIGNvbnRyYXN0IHRvIGhhdmluZyB0aGUgcnVudGltZSBjYXRjaGluZyBpbmNvbnNp c3RlbnQNCj5hZGRyZXNzIGZhbWlseSBkYXRhKS4NCg0KQWN0dWFsbHkgdGhpcyBpcyBzdXBwb3J0 ZWQgb24gdGhlIGRhdGEgY2VudGVyIHByb2R1Y3QgdGhhdCBJIHdvcmsgb24gKHNlZQ0KUkZDIDU1 NDkpLiBIb3dldmVyLCBJIGFncmVlIG1peGluZyBBRnMgd2lsbCBub3QgYmUgdGhlIG5vcm0uDQoN Cg0KPg0KPkhvdyBtdWNoIHRoYXQgbWF0dGVycyBsaWtlbHkgY2FuIGJlIGRlYmF0ZWQuIEJ1dCBz b21laG93IGl0IGZlZWxzIGxpa2UNCj5rZWVwaW5nIHRoaW5ncyBzZXBhcmF0ZSBhbGxvd3MgZm9y IGluZGVwZW5kZW50IGV2b2x1dGlvbiwgd2hpY2ggbWF5DQo+cHJvb2YgdG8gYmUgdmVyeSBoYW5k eSBpbiB0aGUgZnV0dXJlLiBJIGtpbmQgb2YgbGlrZWQgTGFkYSdzIGFwcHJvYWNoDQo+dG8gbWFp bnRhaW4gdGhlIGFyY2hpdGVjdHVyYWwgc2VwYXJhdGlvbiBpbiB0aGUgZGF0YSBtb2RlbC4NCj4N Cj4vanMNCj4NCj4tLSANCj5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBV bml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAg Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj5GYXg6ICAgKzQ5IDQyMSAy MDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0K From nobody Tue Mar 8 03:09:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C13612D660 for ; Tue, 8 Mar 2016 03:08:59 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMSYkx2J-g35 for ; Tue, 8 Mar 2016 03:08:57 -0800 (PST) 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 BADEF12D65A for ; Tue, 8 Mar 2016 03:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2124; q=dns/txt; s=iport; t=1457435337; x=1458644937; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UFKw5SarFK2JPpaVCbZXRUCy9E+tBKzfeb+dgZZvVDI=; b=Dj3nz0tJHdBWjZAbLgZ933ET5FtnXV1+gcVhvok6KwCoeyIYPDjzT8iI LO5wARkcCsQQv9yCKn/MUHSrDfl1oC+XMETm6kUrJ3KfTD440iLRQUH3v nKlHHIJlFDThRItlDwRk9uf3vTwrz3f29d/nv8WIpaUImcj8uwzxvJz78 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbBQCesd5W/4ENJK1cgzqBPwa6U4Fph?= =?us-ascii?q?g8CHIEaORMBAQEBAQEBZCeEQgEBBCMRRRACAQgOAggCAiYCAgIwFRACBAENBYg?= =?us-ascii?q?krwWPLgEBAQEBAQEBAQEBAQEBAQEBAQEBARV7iVqHOoE6AQSXKgGNbY57jlUBI?= =?us-ascii?q?gI+g2RqiEYlFn4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,556,1449532800"; d="scan'208";a="245050936" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Mar 2016 11:08:56 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u28B8uJ3003335 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Mar 2016 11:08:56 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Mar 2016 05:08:55 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Tue, 8 Mar 2016 05:08:55 -0600 From: "Acee Lindem (acee)" To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [netmod] proposed change to ietf-routing Thread-Index: AQHRcJq0RazNoMs9PkSzBYV8exAQ959GhjuAgAGWzACAAIJSAIABD6YAgAA7AYCABIh4AIAAZxkAgABcIgCAAFpkgIAAAlKA///y8gA= Date: Tue, 8 Mar 2016 11:08:55 +0000 Message-ID: References: <50233540-A77D-4ABB-84ED-5D33E2FB1A4B@cisco.com> <20160308064719.GA5979@elstar.local> <20160308.075537.1138440427020216868.mbj@tail-f.com> In-Reply-To: <20160308.075537.1138440427020216868.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.116.152.199] Content-Type: text/plain; charset="utf-8" Content-ID: <622E240579170549B19136917C9A1C50@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] proposed change to ietf-routing 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, 08 Mar 2016 11:08:59 -0000 DQoNCk9uIDMvOC8xNiwgMTo1NSBBTSwgIk1hcnRpbiBCam9ya2x1bmQiIDxtYmpAdGFpbC1mLmNv bT4gd3JvdGU6DQoNCj5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNv YnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+PiBPbiBUdWUsIE1hciAwOCwgMjAxNiBhdCAwMToy Mzo1MEFNICswMDAwLCBBY2VlIExpbmRlbSAoYWNlZSkgd3JvdGU6DQo+PiA+IA0KPj4gPiBUaGUg dGhpbmcgYWJvdXQgdGhlIHN0YXRpYyByb3V0ZSBkZWZpbml0aW9uIGZvciBJUHY0IGFuZCBJUHY2 IGlzIHRoYXQNCj4+dGhlaXIgUklCcyB3aWxsIGhhdmUgcHJldHR5IG11Y2ggdGhlIHNhbWUgc3Ry dWN0dXJlIG90aGVyIHRoYW4NCj4+ZGlmZmVyZW5jZXMgaW4gYWRkcmVzcyB0eXBlLiBGb3Igb3Ro ZXIgQUZzLCB0aGVyZSBtYXkgYmUgb3RoZXINCj4+ZGlmZmVyZW5jZXMgYXMgd2VsbC4gRm9yIGV2 ZXJ5IGF1Z21lbnRhdGlvbiwgd2XigJlyZSBlc3NlbnRpYWxseSBkb3VibGluZw0KPj50aGUgc3Bl Y2lmaWNhdGlvbiBlZmZvcnQuDQo+PiA+DQo+PiANCj4+IE9uZSBiZW5lZml0IG9mIGhhdmluZyBz ZXBhcmF0ZSBhdWdtZW50YXRpb25zIGlzIHRoYXQgdGhlIGRhdGEgdHlwZXMNCj4+IGFyZSB0aWdo dGVyLiBGb3IgZXhhbXBsZSwgdGhlIGRhdGEgbW9kZWwgZG9lcyBub3QgYWxsb3cgYW4gSVB2NiBu ZXh0DQo+PiBob3AgZm9yIGFuIElQdjQgcHJlZml4LCBpLmUuLCB5b3UgY2FuJ3QgbWVzcyB1cCBh ZGRyZXNzIGZhbWlsaWVzIHNpbmNlDQo+PiB0aGUgZGF0YSBtb2RlbCBmb3JjZXMgYSBjbGVhciBz ZXBhcmF0aW9uIChhbmQgZ2VuZXJpYyB2YWxpZGF0aW9uIHdpbGwNCj4+IGNhdGNoIHRoYXQgaW4g Y29udHJhc3QgdG8gaGF2aW5nIHRoZSBydW50aW1lIGNhdGNoaW5nIGluY29uc2lzdGVudA0KPj4g YWRkcmVzcyBmYW1pbHkgZGF0YSkuDQo+PiANCj4+IEhvdyBtdWNoIHRoYXQgbWF0dGVycyBsaWtl bHkgY2FuIGJlIGRlYmF0ZWQuIEJ1dCBzb21laG93IGl0IGZlZWxzIGxpa2UNCj4+IGtlZXBpbmcg dGhpbmdzIHNlcGFyYXRlIGFsbG93cyBmb3IgaW5kZXBlbmRlbnQgZXZvbHV0aW9uLCB3aGljaCBt YXkNCj4+IHByb29mIHRvIGJlIHZlcnkgaGFuZHkgaW4gdGhlIGZ1dHVyZS4gSSBraW5kIG9mIGxp a2VkIExhZGEncyBhcHByb2FjaA0KPj4gdG8gbWFpbnRhaW4gdGhlIGFyY2hpdGVjdHVyYWwgc2Vw YXJhdGlvbiBpbiB0aGUgZGF0YSBtb2RlbC4NCj4NCj5JIGFncmVlLiAgSSB0aGluayB0aGUgbW9k ZWwgaXMgbW9yZSBjbGVhciB0aGlzIHdheS4gIEkgZ3Vlc3MgSSBkb24ndA0KPnVuZGVyc3RhbmQg d2h5IEFjZWUgd2FudHMgdG8gaGF2ZSBhIHNpbmdsZSBtb2R1bGU/DQoNCkkgd2FzIHRyeWluZyB0 byBlbGltaW5hdGUgdGhlIGVmZm9ydCBvZiB1cGRhdGluZyBib3RoIG1vZHVsZXMgd2l0aCB0aGUN CmV4YWN0IHNhbWUgYXVnbWVudGF0aW9ucy4gSG93ZXZlciwgSSBndWVzcyBJ4oCZbSByZWFkeSB0 byByZWxlbnQgb24gdGhpcw0KcG9pbnQuIA0KDQpUaGFua3MsDQpBY2VlIA0KDQoNCg0KPg0KPg0K Pi9tYXJ0aW4NCg0K From nobody Tue Mar 8 03:35:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B93912D66C for ; Tue, 8 Mar 2016 03:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXDTvpw-MBct for ; Tue, 8 Mar 2016 03:35:47 -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 DE68A12D681 for ; Tue, 8 Mar 2016 03:35:42 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:28bc:9327:f9f1:f16f] (unknown [IPv6:2001:718:1a02:1:28bc:9327:f9f1:f16f]) by mail.nic.cz (Postfix) with ESMTPSA id 3EDE9181BF1; Tue, 8 Mar 2016 12:35:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457436941; bh=aNLEqY/fBCwRUj1A5+tu8I2asCYVbCI/NTvuUD6Jwd0=; h=From:Date:To; b=BX3aQSA7ss/+JLYKcXolfmcoBnqyaPnJNmfeowbREUhToTI+JdFE1O3YcvzKPQANx xbL9qMRUKd+TJS1h+VdHweV/rvOWuLoRCjfSpk6XGwJlRASJtdZpr/XIE5Sf35MgAn QJf44GtEKv5P+RqMWq9LA4nVB/rHPf6i2CdgbGlo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 8 Mar 2016 12:35:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <658123A7-1DF0-474C-91D2-9D8F127ADED7@nic.cz> References: <50233540-A77D-4ABB-84ED-5D33E2FB1A4B@cisco.com> <20160308064719.GA5979@elstar.local> <20160308.075537.1138440427020216868.mbj@tail-f.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] proposed change to ietf-routing 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, 08 Mar 2016 11:35:50 -0000 > On 08 Mar 2016, at 12:08, Acee Lindem (acee) wrote: >=20 >=20 >=20 > On 3/8/16, 1:55 AM, "Martin Bjorklund" wrote: >=20 >> Juergen Schoenwaelder wrote: >>> On Tue, Mar 08, 2016 at 01:23:50AM +0000, Acee Lindem (acee) wrote: >>>>=20 >>>> The thing about the static route definition for IPv4 and IPv6 is = that >>> their RIBs will have pretty much the same structure other than >>> differences in address type. For other AFs, there may be other >>> differences as well. For every augmentation, we=E2=80=99re = essentially doubling >>> the specification effort. >>>>=20 >>>=20 >>> One benefit of having separate augmentations is that the data types >>> are tighter. For example, the data model does not allow an IPv6 next >>> hop for an IPv4 prefix, i.e., you can't mess up address families = since >>> the data model forces a clear separation (and generic validation = will >>> catch that in contrast to having the runtime catching inconsistent >>> address family data). >>>=20 >>> How much that matters likely can be debated. But somehow it feels = like >>> keeping things separate allows for independent evolution, which may >>> proof to be very handy in the future. I kind of liked Lada's = approach >>> to maintain the architectural separation in the data model. >>=20 >> I agree. I think the model is more clear this way. I guess I don't >> understand why Acee wants to have a single module? >=20 > I was trying to eliminate the effort of updating both modules with the > exact same augmentations. However, I guess I=E2=80=99m ready to relent = on this > point. OK, thanks. Do we want to post another revision before IETF 95? If so, = we should probably do most preparations this week because I will be on = vacation next week. Lada > =20 >=20 > Thanks, > Acee=20 >=20 >=20 >=20 >>=20 >>=20 >> /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 8 04:06:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AF012D532 for ; Tue, 8 Mar 2016 04:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rexlsM-dnP0 for ; Tue, 8 Mar 2016 04:06:33 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D2512D1E5 for ; Tue, 8 Mar 2016 04:06:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D5AQAAwN5W/yYyC4dSChkBAQEBDwEBAQGCPiErUm0GuDKCEwENgWmGDwIcgR04FAEBAQEBAQFkJ4RBAQEBAQMSCwYKQRsCAQYCDQQDAQEBCx0DAgICMBQJCAIEARIIGogCAZFwkkyKS48tAQEBAQEBAQECAQEBAQEBAQEBARaGGIQ9hAoGCwEeIBaCSiuBDwWXKgGPUYREgxmFOo5WHgEBQoIwgTRqiE00AX0BAQE X-IPAS-Result: A2D5AQAAwN5W/yYyC4dSChkBAQEBDwEBAQGCPiErUm0GuDKCEwENgWmGDwIcgR04FAEBAQEBAQFkJ4RBAQEBAQMSCwYKQRsCAQYCDQQDAQEBCx0DAgICMBQJCAIEARIIGogCAZFwkkyKS48tAQEBAQEBAQECAQEBAQEBAQEBARaGGIQ9hAoGCwEeIBaCSiuBDwWXKgGPUYREgxmFOo5WHgEBQoIwgTRqiE00AX0BAQE X-IronPort-AV: E=Sophos;i="5.22,556,1449550800"; d="scan'208,217";a="171731451" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Mar 2016 07:06:10 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 08 Mar 2016 07:06:04 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 8 Mar 2016 13:06:03 +0100 From: "Romascanu, Dan (Dan)" To: "Zhuangyan (Yan)" , Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft Thread-Index: AQHRc0XzOmgxKIY1jkmkuTyx7LV2V59Oz5EQgACuOVA= Date: Tue, 8 Mar 2016 12:06:02 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF83E4A@AZ-FFEXMB04.global.avaya.com> References: <9B4BC45FDEDDD84F813E9E4A5BAF8785941CF67E@nkgeml513-mbx.china.huawei.com> In-Reply-To: <9B4BC45FDEDDD84F813E9E4A5BAF8785941CF67E@nkgeml513-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA6BF83E4AAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft 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, 08 Mar 2016 12:06:36 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF83E4AAZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkNvbmNlcm5pbmcgY29vcGVyYXRpb24gd2l0aCB0aGUgSUVFRSwgd2UgaGF2ZSBpbiBw bGFjZSBhIG1lY2hhbmlzbSBvZiBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIElFVEYgYW5kIElF RUUgODAyLiBNYWhlc2ggSmV0aGFuYWRhbmkgYW5kIG15c2VsZiBhcmUgaW52b2x2ZWQuIFRoZSBr ZXkgdGhpbmcgaXMgdG8gc2VuZCBpbmZvcm1hdGlvbiBhYm91dCBpbXBvcnRhbnQgbWlsZXN0b25l cyAobGlrZSBMYXN0IENhbGxzKSB0byB0aGUgSUVFRSwgaXQgY2FuIGJlIGRvbmUgdmlhIGVtYWls LCBubyBuZWVkIGZvciBmb3JtYWwgbGlhaXNvbiBtZXNzYWdlcy4gSWYgd2UgaWRlbnRpZnkgdG91 Z2hlciBpc3N1ZXMgKGxpa2UgZHVwbGljYXRpb24sIG9yIGluY29uc2lzdGVuY2llcykgd2UgY2Fu IHNldCBzbWFsbCBzaGFyZWQgdGVhbXMgdG8gd29yayB0aGluZ3Mgb3V0Lg0KDQpSZWdhcmRzLA0K DQpEYW4NCg0KRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBaaHVhbmd5YW4gKFlhbikNClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDA4LCAyMDE2 IDU6MjYgQU0NClRvOiBLZW50IFdhdHNlbjsgbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W25ldG1vZF0gY2FsbCBmb3IgY29uc2Vuc3VzIHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2Qt aW50Zi1leHQteWFuZyBhcyBORVRNT0QgV0cgZHJhZnQNCg0KDQpTb3JyeSBmb3IgdGhlIGxhdGUg cmVzcG9uc2UuIEl0IHRvb2sgc29tZSB0aW1lIHRvIHJldmlldyB0aGlzIGRyYWZ0IGFuZCBtb2Rl bHMuICBBbmQgWWVzLCBJIHN1cHBvcnQgYWRvcHRpbmcgdGhpcyBkb2N1bWVudCBhcyBhIFdHIGl0 ZW0uDQoNClRvIG1lLCB0aGUgY29tbW9uIG1vZGVsIGlzIHNvbWV0aGluZyB1c2VmdWwuIFRoZXJl IHBlcmhhcHMgc29tZSBvdmVybGFwcyBpbiBFdGhlcm5ldC1saWtlIG1vZGVsIHdpdGggdGhpbmdz IGluIElFRUUuIElmIHllcywgd2XigJlsbCBzZWUgaG93IHRvIGNvb3BlcmF0ZS4NCg0KDQoNCkJl c3QgUmVnYXJkcywNCg0KDQoNCllhbg0KDQrlj5Hku7bkuro6IG5ldG1vZCBbbWFpbHRvOm5ldG1v ZC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggS2VudCBXYXRzZW4NCuWPkemAgeaXtumXtDogMjAx NuW5tDPmnIgx5pelIDc6MDcNCuaUtuS7tuS6ujogbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc+DQrkuLvpopg6IFJlOiBbbmV0bW9kXSBjYWxsIGZvciBjb25zZW5zdXMgdG8g YWRvcHQgZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIE5FVE1PRCBXRyBkcmFm dA0KDQoNClRoZSBjaGFpcnMgd2VyZSBqdXN0IHJldmlld2luZyBub3RlcyBhbmQgcmVhbGl6ZWQg dGhhdCB0aGlzIHRocmVhZCBuZXZlciBjbG9zZWQgcHJvcGVybHkuDQoNCkp1ZXJnZW4gaGFzIHNv bWUgY29uY2VybnMgcmVnYXJkaW5nIHJlYWxpc3RpYyBtaWxlc3RvbmVzLCB0aGF0IHdlcmUgbmV2 ZXIgYWRkcmVzc2VkLiAgUm9iZXJ0LCBjYW4geW91IHBsZWFzZSB0cnkgdG8gYWRkcmVzcyBKdWVy Z2Vu4oCZcyBjb25jZXJucyBub3c/DQoNCkFsc28sIHRoZXJlIHdlcmUgb25seSBhIHR3byByZXNw b25zZXMgYmVmb3JlIGluZGljYXRpbmcgd2lsbGluZ25lc3MgdG8gcmV2aWV3IHRoZSBkcmFmdCBh cyBpdCBwcm9ncmVzc2VzICh0aGFua3MgRGFuIGFuZCBNYXJ0aW4pLiAgQ2FuIG90aGVycyB0aGF0 IHN1cHBvcnQgdGhpcyBkcmFmdCBhbmQgd2lsbGluZyB0byByZXZpZXcgdGhpcyBkcmFmdCBzYXkg c28/DQoNClRoYW5rcywNCk5ldG1vZCBDaGFpcnMNCg0KDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFs ZiBvZiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5p cGVyLm5ldD4+DQpEYXRlOiBUdWVzZGF5LCBEZWNlbWJlciAxNSwgMjAxNSBhdCAxMTo0OCBBTQ0K VG86ICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4iIDxuZXRtb2RAaWV0 Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbbmV0bW9kXSBjYWxsIGZv ciBjb25zZW5zdXMgdG8gYWRvcHQgZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFz IE5FVE1PRCBXRyBkcmFmdA0KDQoNClRoZSBtaW51dGVzIGZvciBJRVRGIDk0IHNob3cgdGhhdCB0 aGVyZSB3YXMgaW4tcm9vbSBzdXBwb3J0IGZvciBhZG9wdGluZyBkcmFmdC13aWx0b24tbmV0bW9k LWludGYtZXh0LXlhbmcgYXMgYSBXRyBkcmFmdC4gICBUaGUgbWludXRlcyBhbHNvIHNob3cgdGhh dCB0aGlzIGRlY2lzaW9uIHdvdWxkIGJlIGNvbmZpcm1lZCBvbiB0aGUgbWFpbGluZyBsaXN0LCB3 aGljaCBJIGFtIGRvaW5nIG5vdy4NCg0KU2hvdWxkIHdlIG1vdmUgdG8gYWRvcHQgZHJhZnQtd2ls dG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIGEgV0cgaXRlbSBhbmQgY29ycmVzcG9uZGluZ2x5 IGFkZCB0aGlzIHRvIHRoZSBXRyBjaGFydGVyIGFzIGEgbWlsZXN0b25lPyAgUGxlYXNlIGNvbW1l bnQgYnkgVHVlc2RheSwgRGVjZW1iZXIgMjIsIDIwMTUgYXQgOUFNIEVTVCBhdCB3aGljaCB0aW1l IHRoZSBXRyBDaGFpcnMgd2lsbCBnYXVnZSB3aGV0aGVyIG9yIG5vdCB0aGVyZSBpcyBjb25zZW5z dXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhlIGRvY3VtZW50Lg0KDQpUaGFua3MsDQpLZW50DQoN Cg0K --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF83E4AAZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0 DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0 YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6 U2ltU3VuO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4 dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWlu IFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpwLmEsIGxpLmEsIGRpdi5hDQoJe21zby1zdHlsZS1uYW1lOuaJ ueazqOahhuaWh+acrDsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om5 5rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uRW1haWxT dHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpwLmEwLCBsaS5hMCwgZGl2LmEwDQoJ e21zby1zdHlsZS1uYW1lOue6r+aWh+acrDsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENo YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uQ2hhcjANCgl7bXNvLXN0eWxlLW5h bWU6Iue6r+aWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms657qv5paH5pysOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhp LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Q29uY2VybmluZyBjb29wZXJhdGlvbiB3aXRoIHRoZSBJRUVFLCB3ZSBoYXZl IGluIHBsYWNlIGEgbWVjaGFuaXNtIG9mIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgSUVURiBh bmQgSUVFRSA4MDIuIE1haGVzaCBKZXRoYW5hZGFuaSBhbmQgbXlzZWxmIGFyZSBpbnZvbHZlZC4N CiBUaGUga2V5IHRoaW5nIGlzIHRvIHNlbmQgaW5mb3JtYXRpb24gYWJvdXQgaW1wb3J0YW50IG1p bGVzdG9uZXMgKGxpa2UgTGFzdCBDYWxscykgdG8gdGhlIElFRUUsIGl0IGNhbiBiZSBkb25lIHZp YSBlbWFpbCwgbm8gbmVlZCBmb3IgZm9ybWFsIGxpYWlzb24gbWVzc2FnZXMuIElmIHdlIGlkZW50 aWZ5IHRvdWdoZXIgaXNzdWVzIChsaWtlIGR1cGxpY2F0aW9uLCBvciBpbmNvbnNpc3RlbmNpZXMp IHdlIGNhbiBzZXQgc21hbGwgc2hhcmVkIHRlYW1zDQogdG8gd29yayB0aGluZ3Mgb3V0LiA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlpodWFuZ3lhbiAoWWFuKTxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBNYXJjaCAwOCwgMjAxNiA1OjI2IEFNPGJyPg0KPGI+VG86PC9iPiBLZW50IFdhdHNl bjsgbmV0bW9kQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBjYWxs IGZvciBjb25zZW5zdXMgdG8gYWRvcHQgZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5n IGFzIE5FVE1PRCBXRyBkcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5Tb3JyeSBmb3IgdGhlIGxhdGUgcmVzcG9uc2UuIEl0IHRvb2sgc29tZSB0aW1l IHRvIHJldmlldyB0aGlzIGRyYWZ0IGFuZCBtb2RlbHMuICZuYnNwO0FuZCBZZXMsIEkgc3VwcG9y dCBhZG9wdGluZyB0aGlzIGRvY3VtZW50IGFzIGEgV0cgaXRlbS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VG8gbWUsIHRoZSBjb21tb24gbW9kZWwgaXMgc29t ZXRoaW5nIHVzZWZ1bC4gVGhlcmUgcGVyaGFwcyBzb21lIG92ZXJsYXBzIGluIEV0aGVybmV0LWxp a2UgbW9kZWwgd2l0aCB0aGluZ3MgaW4gSUVFRS4gSWYgeWVzLCB3ZeKAmWxsIHNlZSBob3cgdG8g Y29vcGVyYXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QmVzdCBS ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+WWFuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuWPkeS7tuS6ujwvc3Bhbj48 L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4gbmV0bW9kIFs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj48c3Bh biBsYW5nPSJaSC1DTiI+5Luj6KGoIDwvc3Bhbj48L2I+S2VudCBXYXRzZW48YnI+DQo8Yj48c3Bh biBsYW5nPSJaSC1DTiI+5Y+R6YCB5pe26Ze0PC9zcGFuPjo8L2I+IDIwMTY8c3BhbiBsYW5nPSJa SC1DTiI+5bm0PC9zcGFuPjM8c3BhbiBsYW5nPSJaSC1DTiI+5pyIPC9zcGFuPjE8c3BhbiBsYW5n PSJaSC1DTiI+5pelPC9zcGFuPiA3OjA3PGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaUtuS7 tuS6ujwvc3Bhbj46PC9iPiA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuS4u+mimDwvc3Bhbj46PC9i PiBSZTogW25ldG1vZF0gY2FsbCBmb3IgY29uc2Vuc3VzIHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1u ZXRtb2QtaW50Zi1leHQteWFuZyBhcyBORVRNT0QgV0cgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGUgY2hhaXJzIHdl cmUganVzdCByZXZpZXdpbmcgbm90ZXMgYW5kIHJlYWxpemVkIHRoYXQgdGhpcyB0aHJlYWQgbmV2 ZXIgY2xvc2VkIHByb3Blcmx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkp1ZXJnZW4gaGFzIHNvbWUg Y29uY2VybnMgcmVnYXJkaW5nIHJlYWxpc3RpYyBtaWxlc3RvbmVzLCB0aGF0IHdlcmUgbmV2ZXIg YWRkcmVzc2VkLiAmbmJzcDtSb2JlcnQsIGNhbiB5b3UgcGxlYXNlIHRyeSB0byBhZGRyZXNzIEp1 ZXJnZW7igJlzIGNvbmNlcm5zIG5vdz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5BbHNvLCB0aGVyZSB3 ZXJlIG9ubHkgYSB0d28gcmVzcG9uc2VzIGJlZm9yZSBpbmRpY2F0aW5nIHdpbGxpbmduZXNzIHRv IHJldmlldyB0aGUgZHJhZnQgYXMgaXQgcHJvZ3Jlc3NlcyAodGhhbmtzIERhbiBhbmQgTWFydGlu KS4gJm5ic3A7Q2FuIG90aGVycyB0aGF0DQogc3VwcG9ydCB0aGlzIGRyYWZ0IGFuZCB3aWxsaW5n IHRvIHJldmlldyB0aGlzIGRyYWZ0IHNheSBzbz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGFua3Ms PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+TmV0bW9kIENoYWlyczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPm5ldG1vZCAmbHQ7PGEgaHJlZj0ibWFpbHRv Om5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVu aXBlci5uZXQiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5U dWVzZGF5LCBEZWNlbWJlciAxNSwgMjAxNSBhdCAxMTo0OCBBTTxicj4NCjxiPlRvOiA8L2I+JnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W25ldG1vZF0gY2FsbCBmb3IgY29uc2Vuc3Vz IHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZyBhcyBORVRNT0QgV0cg ZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGUgbWludXRlcyBmb3IgSUVURiA5NCBzaG93IHRoYXQg dGhlcmUgd2FzIGluLXJvb20gc3VwcG9ydCBmb3IgYWRvcHRpbmcmbmJzcDtkcmFmdC13aWx0b24t bmV0bW9kLWludGYtZXh0LXlhbmcgYXMgYSBXRyBkcmFmdC4gJm5ic3A7IFRoZSBtaW51dGVzDQog YWxzbyBzaG93IHRoYXQgdGhpcyBkZWNpc2lvbiB3b3VsZCBiZSBjb25maXJtZWQgb24gdGhlIG1h aWxpbmcgbGlzdCwgd2hpY2ggSSBhbSBkb2luZyBub3cuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5TaG91bGQgd2UgbW92ZSB0byBhZG9wdCBkcmFmdC13aWx0b24tbmV0 bW9kLWludGYtZXh0LXlhbmcgYXMgYSBXRyBpdGVtIGFuZCBjb3JyZXNwb25kaW5nbHkgYWRkIHRo aXMgdG8gdGhlIFdHIGNoYXJ0ZXIgYXMgYSBtaWxlc3RvbmU/DQogJm5ic3A7UGxlYXNlIGNvbW1l bnQgYnkgVHVlc2RheSwgRGVjZW1iZXIgMjIsIDIwMTUgYXQgOUFNIEVTVCBhdCB3aGljaCB0aW1l IHRoZSBXRyBDaGFpcnMgd2lsbCBnYXVnZSB3aGV0aGVyIG9yIG5vdCB0aGVyZSBpcyBjb25zZW5z dXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5LZW50PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9904FB1B0159DA42B0B887B7FA8119CA6BF83E4AAZFFEXMB04globa_-- From nobody Tue Mar 8 07:11:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BC612D58F for ; Tue, 8 Mar 2016 07:11:06 -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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZZej7OxknZA for ; Tue, 8 Mar 2016 07:11:00 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2D09C12D769 for ; Tue, 8 Mar 2016 07:11:00 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id E1BC11AE0144 for ; Tue, 8 Mar 2016 16:10:58 +0100 (CET) Date: Tue, 08 Mar 2016 16:10:58 +0100 (CET) Message-Id: <20160308.161058.828037990479961793.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] mbj review of draft-ietf-netmod-syslog-model-06 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, 08 Mar 2016 15:11:06 -0000 Hi, I have reviewed this document. In general it is in good shape, but it needs some additional clarifying text. o The term VRF is defined but not used. UDP is defined, but not TCP. Consider removing the entire section (or replace with terms defined in this draft). o It seems that this model is targeted for syslog originators (also noted in an early review by Rainer Gerhard). I think this should be stated. o The document's intended status is Informational. Should this somehow be reflected in the YANG modules? o There was a long discussion about facilities as identities, starting at: https://mailarchive.ietf.org/arch/msg/netmod/gtGBR7EngO_6KWJhvYDuCVfOas4 The conclusion from that thread is not present in the draft. Specifially, the draft needs to explain why identities are used and how vendors are supposed to derive new identities. Also, it needs to be explained what will happen if the client configures a facility match on e.g. 'daemon', and the system generates a message with facility 'ex:my-daemon', where ex:my-daemon is derived from 'daemon'. The current text just says: description "This case specifies one or more specified facilities will match when comparing the Syslog message facility."; Since the leaf is an identityref, "match" needs to be explained. Does it mean "equality", "derived-from" or "derived-from-or-self"? I think it means the latter. o Section 3: Syslog consists of message producers, a group level suppression filter, and message distributors. These terms are not used in RFC 5424. Maybe say "This document models the syslog system as ..." or something similar. But see below. It is not entirely clear to me how these concepts ("filter" and "message distributor") relate to the YANG model. The YANG model has "log-actions", but that term in not used in the explanation in this section. o Section 3: The text says: The following digram shows syslog messages flowing from a message producer, through the group level suppression filter, and if passed by the group filter to message distributors where further suppression filtering can take place. But the picture does not show and "group level suppression filter". BTW, what does "group level" refer to? o more specific type The YANG model has: leaf name { type inet:uri; description "This leaf specifies the name of the log file which MUST use the uri scheme file:."; } consider using: type inet:uri { pattern 'file:.*' } o The model supports syslog over TCP. Needs a reference to RFC 6587, but should we really support this historic RFC? o The 'udp' transport should have a reference to RFC 5426. o Why doesn't the model support syslog over TLS, RFC 5425? (I think some of the earlier reviews suggested this as well.) o The ietf-syslog.yang module has the "reference" statement wrong: OLD: revision 2015-11-09 { description "Initial Revision"; reference "RFC 5424: The Syslog Protocol RFC 5848: Signed Syslog Messages"; } NEW: reference "RFC 5424: The Syslog Protocol RFC 5848: Signed Syslog Messages"; ... revision 2015-11-09 { description "Initial Revision"; reference "RFC XXXX: SYSLOG YANG Model"; } Ditto for ietf-syslog-types - but that module should not have the reference to RFC 5848. o severity-operator What does it mean to set: severity: all severity-operator: not-equals or severity: none severity-operator: equals ?? I think that the answer is that for 'all' and 'none', the severity-operator isn't applicable. If so, maybe we should add a 'when' expression: leaf severity { ... } leaf severity-operator { when '../severity != "all" and ../severity != "none"'; ... } o severity 'none' I don't understand the description of this value: This enum describes the case where no severities are requested. and: 'none' is a special case which means that no severity selection should occur. I think 'none' means that no message will ever match. Thus, this is an implict way to disable this particular filter. o buffer In your response to my earlier review https://mailarchive.ietf.org/arch/msg/netmod/gtGBR7EngO_6KWJhvYDuCVfOas4 you explained that when a buffer is used, there is supposedly some vendor-specific non-standard method to read the data from the buffers. I think this explanation should go into the document. Also, if the leafs 'buffer-size-bytes' are 'buffer-size-messages' are not supported, I assume that the intention is that an implementation is free to use some local mechanism to limit the buffer? This should be explained. (same for the other limits) o structured-data Why doesn't "buffer" have the leaf "structured-data"; why just "file"? o mandatory log-actions In the current model, all log-actions are mandatory to implement. Should some/all of them have features? What if my device doesn't have a file system? o container terminal choice terminal-scope { "This choice describes the option to specify all terminals or a specific terminal. The all terminals case implies that messages will be sent to all sessions on that terminal"; I cannot parse the last sentence. Somehow 'all terminals' refer to "that terminal"? Which terminal? The "per-terminal" case has a list of "devices" - what is a "device"? Shouldn't it simply be "terminal"? I suggest: OLD: list device-name NEW: list terminal OLD: leaf dname NEW: leaf name Also explain that how terminals are named is implementation-dependant, and how to discover which terminals are available is out of scope for this specification. o container session What is a "session"? NETCONF session? HTTP session? Probably not... I suggest: OLD: list user-name NEW: list user OLD: leaf uname NEW: leaf name we usually don't try to make such leafs (pseudo-)unique o choice user-scope I note that the design with a choice means that it is not possible to configure the system to send e.g. emergency messages to all users at the same time as debug messages to user 'alice'. Is this intentional? If not, it would be trivial to remove the choice. /martin From nobody Tue Mar 8 07:20:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37A812D769 for ; Tue, 8 Mar 2016 07:20:54 -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_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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbUycBhWocgh for ; Tue, 8 Mar 2016 07:20:53 -0800 (PST) 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 A690A12D5EA for ; Tue, 8 Mar 2016 07:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3248; q=dns/txt; s=iport; t=1457450452; x=1458660052; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fasVnIeLrybIN4VlyxIoiMSNUJ5ooO/ekoZhejoXomQ=; b=C4OzaL9BvYP+8CdiExmjZ2XV2fnXsBe64QRYOu1Iz6uYWI77dWe4Rys2 u3XG83r5NapbfUfy54+gK1fEoA0lWWYE2CW7rtRdDs081w5/1k+OfleVD 8U1SM5n15cHcUCN2OJL2tfk+DuG9WfVOoxwxU3oqtGZLJdTQ1ZwxJ14mM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAgBe7d5W/4oNJK1cgzpSbQa6RgENg?= =?us-ascii?q?WkXCoUkSgIcgSQ4FAEBAQEBAQFkJ4RBAQEBAwEBAQEgEToLEAIBCBAIAgImAgI?= =?us-ascii?q?CJQsVEAIEDgWIHAgOrwKPKgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEe4lehDiDA?= =?us-ascii?q?oE6BZcqAY1tjnuOVQEeAQFCg2RqiEYlFn4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,556,1449532800"; d="scan'208";a="246119799" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Mar 2016 15:20:51 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u28FKpYF028683 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Mar 2016 15:20:51 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Mar 2016 09:20:50 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Tue, 8 Mar 2016 09:20:50 -0600 From: "Acee Lindem (acee)" To: Ladislav Lhotka Thread-Topic: [netmod] proposed change to ietf-routing Thread-Index: AQHRcJq0RazNoMs9PkSzBYV8exAQ959GhjuAgAGWzACAAIJSAIABD6YAgAA7AYCABIh4AIAAZxkAgABcIgCAAFpkgIAAAlKA///y8gCAAFtOgP//6w8A Date: Tue, 8 Mar 2016 15:20:50 +0000 Message-ID: References: <50233540-A77D-4ABB-84ED-5D33E2FB1A4B@cisco.com> <20160308064719.GA5979@elstar.local> <20160308.075537.1138440427020216868.mbj@tail-f.com> <658123A7-1DF0-474C-91D2-9D8F127ADED7@nic.cz> In-Reply-To: <658123A7-1DF0-474C-91D2-9D8F127ADED7@nic.cz> 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.199] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] proposed change to ietf-routing 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, 08 Mar 2016 15:20:55 -0000 DQoNCk9uIDMvOC8xNiwgNjozNSBBTSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBuaWMuY3o+ IHdyb3RlOg0KDQo+DQo+PiBPbiAwOCBNYXIgMjAxNiwgYXQgMTI6MDgsIEFjZWUgTGluZGVtIChh Y2VlKSA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiANCj4+IA0KPj4gT24gMy84LzE2 LCAxOjU1IEFNLCAiTWFydGluIEJqb3JrbHVuZCIgPG1iakB0YWlsLWYuY29tPiB3cm90ZToNCj4+ IA0KPj4+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlPiB3cm90ZToNCj4+Pj4gT24gVHVlLCBNYXIgMDgsIDIwMTYgYXQgMDE6MjM6NTBB TSArMDAwMCwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPj4+Pj4gDQo+Pj4+PiBUaGUgdGhp bmcgYWJvdXQgdGhlIHN0YXRpYyByb3V0ZSBkZWZpbml0aW9uIGZvciBJUHY0IGFuZCBJUHY2IGlz IHRoYXQNCj4+Pj4gdGhlaXIgUklCcyB3aWxsIGhhdmUgcHJldHR5IG11Y2ggdGhlIHNhbWUgc3Ry dWN0dXJlIG90aGVyIHRoYW4NCj4+Pj4gZGlmZmVyZW5jZXMgaW4gYWRkcmVzcyB0eXBlLiBGb3Ig b3RoZXIgQUZzLCB0aGVyZSBtYXkgYmUgb3RoZXINCj4+Pj4gZGlmZmVyZW5jZXMgYXMgd2VsbC4g Rm9yIGV2ZXJ5IGF1Z21lbnRhdGlvbiwgd2XigJlyZSBlc3NlbnRpYWxseQ0KPj4+PmRvdWJsaW5n DQo+Pj4+IHRoZSBzcGVjaWZpY2F0aW9uIGVmZm9ydC4NCj4+Pj4+IA0KPj4+PiANCj4+Pj4gT25l IGJlbmVmaXQgb2YgaGF2aW5nIHNlcGFyYXRlIGF1Z21lbnRhdGlvbnMgaXMgdGhhdCB0aGUgZGF0 YSB0eXBlcw0KPj4+PiBhcmUgdGlnaHRlci4gRm9yIGV4YW1wbGUsIHRoZSBkYXRhIG1vZGVsIGRv ZXMgbm90IGFsbG93IGFuIElQdjYgbmV4dA0KPj4+PiBob3AgZm9yIGFuIElQdjQgcHJlZml4LCBp LmUuLCB5b3UgY2FuJ3QgbWVzcyB1cCBhZGRyZXNzIGZhbWlsaWVzIHNpbmNlDQo+Pj4+IHRoZSBk YXRhIG1vZGVsIGZvcmNlcyBhIGNsZWFyIHNlcGFyYXRpb24gKGFuZCBnZW5lcmljIHZhbGlkYXRp b24gd2lsbA0KPj4+PiBjYXRjaCB0aGF0IGluIGNvbnRyYXN0IHRvIGhhdmluZyB0aGUgcnVudGlt ZSBjYXRjaGluZyBpbmNvbnNpc3RlbnQNCj4+Pj4gYWRkcmVzcyBmYW1pbHkgZGF0YSkuDQo+Pj4+ IA0KPj4+PiBIb3cgbXVjaCB0aGF0IG1hdHRlcnMgbGlrZWx5IGNhbiBiZSBkZWJhdGVkLiBCdXQg c29tZWhvdyBpdCBmZWVscyBsaWtlDQo+Pj4+IGtlZXBpbmcgdGhpbmdzIHNlcGFyYXRlIGFsbG93 cyBmb3IgaW5kZXBlbmRlbnQgZXZvbHV0aW9uLCB3aGljaCBtYXkNCj4+Pj4gcHJvb2YgdG8gYmUg dmVyeSBoYW5keSBpbiB0aGUgZnV0dXJlLiBJIGtpbmQgb2YgbGlrZWQgTGFkYSdzIGFwcHJvYWNo DQo+Pj4+IHRvIG1haW50YWluIHRoZSBhcmNoaXRlY3R1cmFsIHNlcGFyYXRpb24gaW4gdGhlIGRh dGEgbW9kZWwuDQo+Pj4gDQo+Pj4gSSBhZ3JlZS4gIEkgdGhpbmsgdGhlIG1vZGVsIGlzIG1vcmUg Y2xlYXIgdGhpcyB3YXkuICBJIGd1ZXNzIEkgZG9uJ3QNCj4+PiB1bmRlcnN0YW5kIHdoeSBBY2Vl IHdhbnRzIHRvIGhhdmUgYSBzaW5nbGUgbW9kdWxlPw0KPj4gDQo+PiBJIHdhcyB0cnlpbmcgdG8g ZWxpbWluYXRlIHRoZSBlZmZvcnQgb2YgdXBkYXRpbmcgYm90aCBtb2R1bGVzIHdpdGggdGhlDQo+ PiBleGFjdCBzYW1lIGF1Z21lbnRhdGlvbnMuIEhvd2V2ZXIsIEkgZ3Vlc3MgSeKAmW0gcmVhZHkg dG8gcmVsZW50IG9uIHRoaXMNCj4+IHBvaW50Lg0KPg0KPk9LLCB0aGFua3MuIERvIHdlIHdhbnQg dG8gcG9zdCBhbm90aGVyIHJldmlzaW9uIGJlZm9yZSBJRVRGIDk1PyBJZiBzbywgd2UNCj5zaG91 bGQgcHJvYmFibHkgZG8gbW9zdCBwcmVwYXJhdGlvbnMgdGhpcyB3ZWVrIGJlY2F1c2UgSSB3aWxs IGJlIG9uDQo+dmFjYXRpb24gbmV4dCB3ZWVrLg0KDQpJIHRoaW5rIHdlIHNob3VsZCBhdCBsZWFz dCB0cnkgYW5kIGdldCB0aGUgc3RydWN0dXJhbCBjaGFuZ2VzIHBvc3RlZA0KYmVmb3JlIElFVEYg OTUuIFdlIGNhbiBtZWV0IG9uIG5leHQgaG9wcyBhdCBJRVRGIDk1Lg0KDQpUaGFua3MsDQpBY2Vl DQoNCg0KDQo+DQo+TGFkYQ0KPg0KPj4gIA0KPj4gDQo+PiBUaGFua3MsDQo+PiBBY2VlIA0KPj4g DQo+PiANCj4+IA0KPj4+IA0KPj4+IA0KPj4+IC9tYXJ0aW4NCj4+IA0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxp c3QNCj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QNCj4NCj4tLQ0KPkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj5Q R1AgS2V5IElEOiBFNzRFOEMwQw0KPg0KPg0KPg0KPg0KDQo= From nobody Tue Mar 8 07:36:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAAE12D791 for ; Tue, 8 Mar 2016 07:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6gWk5c3lqkb for ; Tue, 8 Mar 2016 07:36:35 -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 4157012D793 for ; Tue, 8 Mar 2016 07:36:28 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:28bc:9327:f9f1:f16f] (unknown [IPv6:2001:718:1a02:1:28bc:9327:f9f1:f16f]) by mail.nic.cz (Postfix) with ESMTPSA id C46951804E3; Tue, 8 Mar 2016 16:36:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457451386; bh=6jtxlissMX9ZFx6aTUksbXw2aLZiL78SeXqwIURZh00=; h=From:Date:To; b=m72MiyvcbD8dnSUc79XnazQqkjdLlApOuPeq8ZlVD1VdLPqfpNsMO7WhEO3WQC4Xs g85L3wqyHXLSUAXwy/0DKGJ2Hbp6k0lKjMv2bUxG6wB0clho1P8Nn1HMJOsNovsvC6 cYSFe8jxtX9FUaN6allWA72YonlCOYF/XB2hZJno= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 8 Mar 2016 16:36:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0256B018-CCE0-4A87-8A38-D176BEEA69E0@nic.cz> References: <50233540-A77D-4ABB-84ED-5D33E2FB1A4B@cisco.com> <20160308064719.GA5979@elstar.local> <20160308.075537.1138440427020216868.mbj@tail-f.com> <658123A7-1DF0-474C-91D2-9D8F127ADED7@nic.cz> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] proposed change to ietf-routing 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, 08 Mar 2016 15:36:37 -0000 > On 08 Mar 2016, at 16:20, Acee Lindem (acee) wrote: >=20 >=20 >=20 > On 3/8/16, 6:35 AM, "Ladislav Lhotka" wrote: >=20 >>=20 >>> On 08 Mar 2016, at 12:08, Acee Lindem (acee) wrote: >>>=20 >>>=20 >>>=20 >>> On 3/8/16, 1:55 AM, "Martin Bjorklund" wrote: >>>=20 >>>> Juergen Schoenwaelder wrote: >>>>> On Tue, Mar 08, 2016 at 01:23:50AM +0000, Acee Lindem (acee) = wrote: >>>>>>=20 >>>>>> The thing about the static route definition for IPv4 and IPv6 is = that >>>>> their RIBs will have pretty much the same structure other than >>>>> differences in address type. For other AFs, there may be other >>>>> differences as well. For every augmentation, we=E2=80=99re = essentially >>>>> doubling >>>>> the specification effort. >>>>>>=20 >>>>>=20 >>>>> One benefit of having separate augmentations is that the data = types >>>>> are tighter. For example, the data model does not allow an IPv6 = next >>>>> hop for an IPv4 prefix, i.e., you can't mess up address families = since >>>>> the data model forces a clear separation (and generic validation = will >>>>> catch that in contrast to having the runtime catching inconsistent >>>>> address family data). >>>>>=20 >>>>> How much that matters likely can be debated. But somehow it feels = like >>>>> keeping things separate allows for independent evolution, which = may >>>>> proof to be very handy in the future. I kind of liked Lada's = approach >>>>> to maintain the architectural separation in the data model. >>>>=20 >>>> I agree. I think the model is more clear this way. I guess I = don't >>>> understand why Acee wants to have a single module? >>>=20 >>> I was trying to eliminate the effort of updating both modules with = the >>> exact same augmentations. However, I guess I=E2=80=99m ready to = relent on this >>> point. >>=20 >> OK, thanks. Do we want to post another revision before IETF 95? If = so, we >> should probably do most preparations this week because I will be on >> vacation next week. >=20 > I think we should at least try and get the structural changes posted > before IETF 95. We can meet on next hops at IETF 95. OK, so let's do it. Thanks, Lada >=20 > Thanks, > Acee >=20 >=20 >=20 >>=20 >> Lada >>=20 >>>=20 >>>=20 >>> Thanks, >>> Acee=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> /martin >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 8 08:25:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F8B12D798; Tue, 8 Mar 2016 08:25:12 -0800 (PST) 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EKAKMV9Rwnu; Tue, 8 Mar 2016 08:25:11 -0800 (PST) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE7D12D7F3; Tue, 8 Mar 2016 08:25:10 -0800 (PST) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud2.xs4all.net with ESMTP id TUR71s00r3vXPcr01UR84Y; Tue, 08 Mar 2016 17:25:08 +0100 To: draft-ietf-netmod-yang-metadata@ietf.org From: "Bert Wijnen (IETF)" Message-ID: <56DEFCE3.4040909@bwijnen.net> Date: Tue, 8 Mar 2016 17:25:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ops-dir@ietf.org" , NETMOD Working Group Subject: [netmod] OPS-DIR review for draft-ietf-netmod-yang-metadata-04 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, 08 Mar 2016 16:25:12 -0000 Hi, I did OPS directorate review for draft-ietf-netmod-yang-metadata-04. I think the document is in good shape and ready for publication as a standards track RFC. If anything (operations wise), this document will help to add metadata to YANG defined Data Models in a standardized way. So that is goodness in my view. Bert From nobody Tue Mar 8 10:00:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46C712D62C; Tue, 8 Mar 2016 10:00:20 -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] autolearn=unavailable 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdGLsgJnqTWB; Tue, 8 Mar 2016 10:00:19 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0128.outbound.protection.outlook.com [104.47.0.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B04512D926; Tue, 8 Mar 2016 09:54:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8nQeeNRgqHHQ2lrec10JSwcprGn2f08+ju3hzVm48E4=; b=EJP5lFfLLnZNRdUT28eC0Vh5dreNmD/BeIo+jPw7mamN8HeDC2+g7f+iakX9FpDWMjkPMjwQ1tvK/lrvqKdpPYqWafC+Y6Qy9/lEXsfzo5i2Dcf1KuCvLWA9A8Ku9E4xWYTh57bq6HnNS/5Nddc2XxmdxnKG8A9hM8Vd/J3hAFA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.167.153.133) by HE1PR07MB1628.eurprd07.prod.outlook.com (10.166.124.24) with Microsoft SMTP Server (TLS) id 15.1.434.11; Tue, 8 Mar 2016 17:54:12 +0000 Message-ID: <016b01d17962$fa416280$4001a8c0@gateway.2wire.net> From: t.petch To: netmod WG , Lou Berger References: <56D4AF14.3020903@labn.net> Date: Tue, 8 Mar 2016 17:48:05 +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.167.153.133] X-ClientProxiedBy: DB4PR06CA0029.eurprd06.prod.outlook.com (25.160.40.157) To HE1PR07MB1628.eurprd07.prod.outlook.com (25.166.124.24) X-MS-Office365-Filtering-Correlation-Id: 3053364b-24fd-42cf-9b33-08d3477aa8d2 X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1628; 2:EkJBWdFKbrFW+dzxRAvqM220otKCF0QpMu3sKYSv11J7+E9evGZd4hNBotbcAcU4MvJ1ULJ9VTDUgVgub+hMQ62/fayFV+iAe24wmDTpCRdcm174zGmaDpW1ibXtbCEYFDMeWoCQWqe2w86WO+afvyZIXEuuTHBMb+7+aw/DMFFSixWZ4ekhce9ODjzz6OMo; 3:pBlrSjbFJj5aGB2Co7ygmcl0KwriIxit38mFxkMoSNaJPFd0m4oGfzuhOs3/jEHPj5IJ3ixQKqRIijBh1urR9/hiOnffn+PVEs/R6EEWmB6Vtlldyd8M0ghOZMnkhakK; 25:J+mEB9y65BFgfsVtht6LPbjFi3b7hmTNl3sJyM+zeo7uMV5OVx3ZwS0mJ6sr8ADV5lUyPKkORLZu1szeelM3pEUmWBqXcD3dbyDYHYejTeuE1ItLFijWCWz1hAouXp1Qu300vmRB/DoslihRPAcaVupf+qj4l4YsVyw0a2dHvY0B7UgKK5p6xskP8vuhZ5ZIJ7l6KGbpjCYze9BKgm3916LmREVVcSyLVEIeiTrbGl4dZuzXYtU5q5tVajy/jpY6GYWhpsU5im1d/+7ILsaSDezoxKBg+qWEm3PhrHtMhxZqbTpWpozvurgWuMkgPjX8T/jxdsepcTlZxMtDUQ/8aQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1628; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR07MB1628; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1628; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1628; 4:+/9mu298shu9FtEltUzHLNJc7L35CSLLQpjDCXaloPXLl+DdTY/ntFhQD6q9YwqRNlupqVcLzeb1HMDvVn3t44FjKvqDBauk0bqJhG9LBEORTpfdTFGDBo+HhaBv/KIuBXoRc3UMuAp9mqg/3vD+yFWLNtLcbyXfbDKu1dn09QK6UfrZHoRU9UFsNuca9FHOA1uLR2X0Rw3QsgqqCbKlvsrS8ZjVXCySg6GXCXq4Pd4fexU/IM7enwytVHiCNlINpQ3kdYsKGLJgdJ5LSO0WBJEXrw8Ur3iav9wlZrUHYRLtPdXoyaZLonCciHr8yfaOJuIFpC+5mp0+TpHgYn048MOfMVU7YPUJJtgtZiAgbV1PPB1a4X9sol/lgYqkfFnb X-Forefront-PRVS: 08756AC3C8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(377454003)(51444003)(66066001)(47776003)(81686999)(76176999)(50986999)(86362001)(62236002)(15975445007)(44716002)(81816999)(1456003)(5004730100002)(33646002)(61296003)(92566002)(230783001)(77096005)(23756003)(116806002)(1556002)(42186005)(44736004)(50226001)(122386002)(40100003)(14496001)(189998001)(5001770100001)(1096002)(586003)(230700001)(19580395003)(19580405001)(6116002)(3846002)(4326007)(87976001)(5008740100001)(50466002)(2906002)(84392002)(81166005)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1628; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR07MB1628; 23:IIDUfaJbRk5sWztOj+8W1GLO4wBRiTD5sJ8uqAL?= =?iso-8859-1?Q?AxVFTG7v8+ntA0JFxqd/BVoAva7t8ElLgYVoR1QEW9q7FeCDTFbWel4Ue7?= =?iso-8859-1?Q?VmAkp2PhODlos3om+OnsbYT/I+9sbnE0gZ+cEQ8FzjAq/lHmaVzbn0a69C?= =?iso-8859-1?Q?FlPIpzoDAIGkI8yRMM64hLW3ZEHVNz+QIoFBIdD40tBd6ME/7lCtMYNYFe?= =?iso-8859-1?Q?VgXmY3MAbH6uyDXbCzVuNXpC80kRZwdtvLd/cz7bMGcIxUJ3XfjFtldKjf?= =?iso-8859-1?Q?E4nQ7NKG039q/5j4NzYdm+vTpQxhNuiicODhYcWM32EpMCBhGGHldtMw6K?= =?iso-8859-1?Q?dAbaVPu/qKXCy+sJSztoHqqneaSFhw/k/fofKeX1v9GEz+qSJnoQ3sFboN?= =?iso-8859-1?Q?Qj1GtOlZRIHjyQ5d2qDmbisJZQf3/VktDlVLnQVSirLtYuJrObI/p9sHzM?= =?iso-8859-1?Q?/1mHyr+PVuG8YY4Q7RkymViLqhuZlo/pLIKupaJJ+0x7Z5IyncGKI7Wbla?= =?iso-8859-1?Q?Xp3xEE89gXLmzkl7lvOvL35hytO88ch9OBOilwXY1whcjeDG6QZI1vHf8S?= =?iso-8859-1?Q?I97cIm9OJLJAUW4jOypqxgY8Td2Z09DFLHPyTDy9W6QhsG31PzEodxmjcr?= =?iso-8859-1?Q?J918UxpRux3ggGx5Z3IHm2JrS4ysyIjnYA5pr4MjCYjS/4aL1aexVlVT6U?= =?iso-8859-1?Q?zSwD2WwIqR+zgHNuEguAbmF1I3IEqk5k2UiMeM+jl8iTa5eddskPj78tT5?= =?iso-8859-1?Q?xtKPX8Znw0YDKvqv12eWDE4Fz69GGBDXNdz36RRxHJhvwwMTdLIiG/PFkJ?= =?iso-8859-1?Q?pR+6ZnEdGXC/E6pF0njlTOoC9VtnrkpL8VSnxYnLeU3lRWbkZYJCWTj8bW?= =?iso-8859-1?Q?2fjwJa0hbVeaqOvKhrzB3f+ixjz3lov6i4cNyuRhaKKaInJVOEHjNw+Q9R?= =?iso-8859-1?Q?2yOcftSw+AoPIIqb3EIEIWz3xwthnpHSkIMb2E/1uDhtuQ/bfMBF7AF7e9?= =?iso-8859-1?Q?xBSeLOvnXMi+DUepyMXKyOwgBZddSa6jw03dM02gfB/u5abyA64WJZNw5f?= =?iso-8859-1?Q?QiyNAms9yQSBf/apUCaofW6fBfZuYuwNpIbZaSriUzWzM2ah2K+Rkn79NU?= =?iso-8859-1?Q?vEKNdw079ngpCKyuBAXY0IMvhuFXuO53OYVrvp1vjeRi+kqChhsxYXIl/N?= =?iso-8859-1?Q?CEUrHyGmLs4ZY6SSHcH4o0yOy7xpucQXrgKv8RJpybaZK1T0pZohMJmw0W?= =?iso-8859-1?Q?hgv2RIVn/NwjwzV1twCdxAAENbg3N8pfQN/Lhkm/l/1u5JrciwHvGZlacM?= =?iso-8859-1?Q?oOJCXawU10nJc3in0OmsuMD?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1628; 5:/Jc8dvmK+3MBvCybzjWa91iwDbVZb+6Ii7O1K4Koe7eFYYvHEWb6Do7Yt8wJbTMdnz/i/fNoPxoGZSWxiIPHeIqfMzH7RmaCvy8IIJMfHx3ngMiZU5uxejRnKp6HgjVc/YxtJjU9e5zShCtSkVGd5Q==; 24:M4tpqGEdzO5n8V464lrC2Wnlfv+NP2F4iAKjX+VIHtwiJEsPaigsAVx0hrA+S985ysCsCcLSEr7IQASB2+PAZUH7agqIXDf99LDcchRJeF0= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2016 17:54:12.8328 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1628 Archived-At: Cc: netmod-chairs@ietf.org, draft-ietf-netmod-syslog-model@ietf.org Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-syslog-model-06 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, 08 Mar 2016 18:00:20 -0000 I have reviewed this and do not believe it is ready for publication. - draft appears in several places - TBD occurs in one - it would seem that there are two modules in this I-D but only one is registered in s.7 - in s.7 I read prefix: syslog reference: which I found odd - ah, it means prefix: syslog reference: formatting could be better. - VRF I know what it means but do not know if your definition is the same as mine - is there a definition anywhere in an RFC to reference? - s.3 " The following digram shows syslog messages flowing from a message producer, through the group level suppression filter, and if passed by the group filter to message distributors where further suppression filtering can take place." Well yes, I see a digram of message producer and message distributors but no group level suppression filter (which would, I suppose, make it a trigram) - s.3.1 what is the merit of using this explanation of the module as opposed to the standard one? - enumeration {selector-severity-operator-config}? string {selector-match-processing-config}? spill over the line (many times) which reflects the fact that they are looooong - I think that this does not aid understanding nor accuracy of implementation 4.1 prefix syslogtypes; again, long, especially for a prefix WG Chairs - who are they at present? I have lost track:-) 4.1 What a lot of features? Again, makes things more complex, more error prone - are they all really needed? I have to get into the detail of the module. Tom Petch ----- Original Message ----- From: "Lou Berger" To: "netmod WG" Cc: ; Sent: Monday, February 29, 2016 8:50 PM Subject: [netmod] WG Last Call: draft-ietf-netmod-syslog-model-06 > All, > This starts a two-week working group last call on > draft-ietf-netmod-syslog-model-06. > > The working group last call ends on March 14. Please send your comments > to the netmod mailing list. > > Positive comments, e.g., "I've reviewed this document and > believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thank you, > Netmod Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 8 11:01:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E8212D9F7 for ; Tue, 8 Mar 2016 11:01:29 -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=kuatrotechnology.onmicrosoft.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP05j5N_L-xT for ; Tue, 8 Mar 2016 11:01:27 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0087.outbound.protection.outlook.com [104.47.0.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514F212DA01 for ; Tue, 8 Mar 2016 11:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q4ZfqQ0A6N/tmr0soNR6qVRYOTf/EWi0ddwYTDl3IXk=; b=a3CZiORi2wYau0PmORiX4FHBAk74Hcux7QEv5BYsXZRmHiuHU+J3zBD0AWswuR36WDZEaBY/O0iHhd56zlCqEei5EemEc72d4C+WqmlYjBibgVNNdLk7JGXR9LB/V6Pynnks8V6BbC2+qTU05ZlcsWNbO7KH8IO5PZGtcYs4Msw= Received: from AM4PR06MB1474.eurprd06.prod.outlook.com (10.164.80.28) by AM4PR06MB1473.eurprd06.prod.outlook.com (10.164.80.27) with Microsoft SMTP Server (TLS) id 15.1.434.16; Tue, 8 Mar 2016 19:01:08 +0000 Received: from AM4PR06MB1474.eurprd06.prod.outlook.com ([10.164.80.28]) by AM4PR06MB1474.eurprd06.prod.outlook.com ([10.164.80.28]) with mapi id 15.01.0427.019; Tue, 8 Mar 2016 19:01:08 +0000 From: Athanasios Kyparlis To: Ladislav Lhotka , Kent Watsen Thread-Topic: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft Thread-Index: AQHRc0XzOmgxKIY1jkmkuTyx7LV2V59GPZAAgAmzUyA= Date: Tue, 8 Mar 2016 19:01:08 +0000 Message-ID: References: <9211B380-B0EE-43C5-964C-7884351BE498@nic.cz> In-Reply-To: <9211B380-B0EE-43C5-964C-7884351BE498@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: db8a19fa-be3f-4479-85ea-08d347840214 x-microsoft-exchange-diagnostics: 1; AM4PR06MB1473; 5:S1d7a97DOXu3d7y7NpzaMIOtY22WvTpDxgS4yyU4y0x6EqA/L33IPtpOVDUExDIBSCj+qMaUKHI82yB96ubneWgjqJemeezc1lCgEZLXzyUWlWRqnv/tod5Hur+loLT8x5dZT7RCerBssyjlJ+DN+A==; 24:jpzs8Bu5bS622+Hgj9pkrEFpbuHw1+UBTHzjL1VAFX5uxsDHCZ2RC54VD0czh/pWKfTsiKnRWwei+lb/CO2Z0CN8VLPqOkf+A86A3ld8Kqw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR06MB1473; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM4PR06MB1473; BCL:0; PCL:0; RULEID:; SRVR:AM4PR06MB1473; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(164054003)(377454003)(13464003)(3660700001)(92566002)(77096005)(10400500002)(5001770100001)(1941001)(66066001)(2900100001)(2950100001)(15975445007)(54356999)(3280700002)(87936001)(1220700001)(1096002)(19580405001)(76176999)(2906002)(86362001)(19580395003)(230783001)(5008740100001)(102836003)(6116002)(4326007)(106116001)(76576001)(33656002)(3846002)(50986999)(11100500001)(74316001)(575784001)(586003)(81166005)(5002640100001)(122556002)(5003600100002)(189998001)(40100003)(5004730100002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR06MB1473; H:AM4PR06MB1474.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2016 19:01:08.4588 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR06MB1473 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft 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, 08 Mar 2016 19:01:29 -0000 U29ycnkgZm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlLiBJIHN1cHBvcnQgYWRvcHRpbmcgdGhpcyBk b2N1bWVudCBhcyBhIFdHIGl0ZW0gYW5kIEkgd2lsbCBwYXJ0aWNpcGF0ZSBpbiBmdXJ0aGVyIHJl dmlld3MuIA0KDQpUaGFua3MsDQpBdGhhbmFzaW9zIEt5cGFybGlzDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIExhZGlzbGF2IExob3RrYQ0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAy LCAyMDE2IDk6NDUgQU0NClRvOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NCkNj OiBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBjYWxsIGZvciBjb25zZW5z dXMgdG8gYWRvcHQgZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIE5FVE1PRCBX RyBkcmFmdA0KDQoNCj4gT24gMDEgTWFyIDIwMTYsIGF0IDAwOjA3LCBLZW50IFdhdHNlbiA8a3dh dHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+IA0KPiANCj4gVGhlIGNoYWlycyB3ZXJlIGp1c3Qg cmV2aWV3aW5nIG5vdGVzIGFuZCByZWFsaXplZCB0aGF0IHRoaXMgdGhyZWFkIG5ldmVyIGNsb3Nl ZCBwcm9wZXJseS4NCj4gDQo+IEp1ZXJnZW4gaGFzIHNvbWUgY29uY2VybnMgcmVnYXJkaW5nIHJl YWxpc3RpYyBtaWxlc3RvbmVzLCB0aGF0IHdlcmUgbmV2ZXIgYWRkcmVzc2VkLiAgUm9iZXJ0LCBj YW4geW91IHBsZWFzZSB0cnkgdG8gYWRkcmVzcyBKdWVyZ2Vu4oCZcyBjb25jZXJucyBub3c/DQo+ IA0KPiBBbHNvLCB0aGVyZSB3ZXJlIG9ubHkgYSB0d28gcmVzcG9uc2VzIGJlZm9yZSBpbmRpY2F0 aW5nIHdpbGxpbmduZXNzIHRvIHJldmlldyB0aGUgZHJhZnQgYXMgaXQgcHJvZ3Jlc3NlcyAodGhh bmtzIERhbiBhbmQgTWFydGluKS4gIENhbiBvdGhlcnMgdGhhdCBzdXBwb3J0IHRoaXMgZHJhZnQg YW5kIHdpbGxpbmcgdG8gcmV2aWV3IHRoaXMgZHJhZnQgc2F5IHNvPw0KDQpTb3JyeSBJIGhhdmVu J3QgcmVzcG9uZGVkIGVhcmxpZXIuIEkgc3VwcG9ydCBhZG9wdGluZyB0aGlzIGRvY3VtZW50IGFz IGEgV0cgaXRlbSwgYW5kIEkgd2lsbCByZXZpZXcgaXQuDQoNCkxhZGENCg0KPiANCj4gVGhhbmtz LA0KPiBOZXRtb2QgQ2hhaXJzDQo+IA0KPiANCj4gRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0 Pg0KPiBEYXRlOiBUdWVzZGF5LCBEZWNlbWJlciAxNSwgMjAxNSBhdCAxMTo0OCBBTQ0KPiBUbzog Im5ldG1vZEBpZXRmLm9yZyIgPG5ldG1vZEBpZXRmLm9yZz4NCj4gU3ViamVjdDogW25ldG1vZF0g Y2FsbCBmb3IgY29uc2Vuc3VzIHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQt eWFuZyBhcyBORVRNT0QgV0cgZHJhZnQNCj4gDQo+IA0KPiBUaGUgbWludXRlcyBmb3IgSUVURiA5 NCBzaG93IHRoYXQgdGhlcmUgd2FzIGluLXJvb20gc3VwcG9ydCBmb3IgYWRvcHRpbmcgZHJhZnQt d2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIGEgV0cgZHJhZnQuICAgVGhlIG1pbnV0ZXMg YWxzbyBzaG93IHRoYXQgdGhpcyBkZWNpc2lvbiB3b3VsZCBiZSBjb25maXJtZWQgb24gdGhlIG1h aWxpbmcgbGlzdCwgd2hpY2ggSSBhbSBkb2luZyBub3cuICANCj4gDQo+IFNob3VsZCB3ZSBtb3Zl IHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZyBhcyBhIFdHIGl0ZW0g YW5kIGNvcnJlc3BvbmRpbmdseSBhZGQgdGhpcyB0byB0aGUgV0cgY2hhcnRlciBhcyBhIG1pbGVz dG9uZT8gIFBsZWFzZSBjb21tZW50IGJ5IFR1ZXNkYXksIERlY2VtYmVyIDIyLCAyMDE1IGF0IDlB TSBFU1QgYXQgd2hpY2ggdGltZSB0aGUgV0cgQ2hhaXJzIHdpbGwgZ2F1Z2Ugd2hldGhlciBvciBu b3QgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBkb2N1bWVudC4N Cj4gDQo+IFRoYW5rcywNCj4gS2VudA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9k QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k DQoNCi0tDQpMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQpQR1AgS2V5IElEOiBFNzRFOEMw Qw0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Wed Mar 9 03:32:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8407C12D7FF; Wed, 9 Mar 2016 03:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvTB7-wrlFEd; Wed, 9 Mar 2016 03:32:13 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14EC12D631; Wed, 9 Mar 2016 03:32:12 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BcAwAyCeBW/yYyC4dcGQEBAQEPAQEBAYJgK1JtBrg3ghMBDYFpIYVuAoFLOBQBAQEBAQEBZCdBEgGDbQEBAQECARILHT8MBAIBCA0EBAEBCxQFBAcyFAcBAQUDAQEEAQ0FCBqHeggBDaU+mgUBAQEBAQEBAwEBAQEBAQEBAQEBFYYZhEGBN4MDMoJ5gQ8FlzcBhWSJcUuDeoMZhTqOXh4BAUKCMIE0aoI7hhoBfQEBAQ X-IPAS-Result: A2BcAwAyCeBW/yYyC4dcGQEBAQEPAQEBAYJgK1JtBrg3ghMBDYFpIYVuAoFLOBQBAQEBAQEBZCdBEgGDbQEBAQECARILHT8MBAIBCA0EBAEBCxQFBAcyFAcBAQUDAQEEAQ0FCBqHeggBDaU+mgUBAQEBAQEBAwEBAQEBAQEBAQEBFYYZhEGBN4MDMoJ5gQ8FlzcBhWSJcUuDeoMZhTqOXh4BAUKCMIE0aoI7hhoBfQEBAQ X-IronPort-AV: E=Sophos;i="5.24,311,1454994000"; d="scan'208";a="164642497" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Mar 2016 06:32:11 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 09 Mar 2016 06:32:11 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 9 Mar 2016 12:32:09 +0100 From: "Romascanu, Dan (Dan)" To: "ieee-ietf-coord@ietf.org" , "netmod@ietf.org" Thread-Topic: [STDS-802-3] Consensus building presentation for the IEEE 802.3 YANG data model(s) CFI now available Thread-Index: AdF583Yi6tLMQfTXS065Z+9hEYSvrAAArrNQ Date: Wed, 9 Mar 2016 11:32:08 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF855FF@AZ-FFEXMB04.global.avaya.com> References: <343C1AD0083FE14A9EC98C07251B979F2C67425F@G9W0721.americas.hpqcorp.net> In-Reply-To: <343C1AD0083FE14A9EC98C07251B979F2C67425F@G9W0721.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Law, David" Subject: [netmod] FW: [STDS-802-3] Consensus building presentation for the IEEE 802.3 YANG data model(s) CFI now available 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, 09 Mar 2016 11:32:14 -0000 Hi, Please see the information below about a Call For Interest (CFI) about Ethe= rnet YANG models which will be discussed at the IEEE 802 LMSC March 2016 P= lenary meeting in Macao SAR, P.R. China (next week). A Call for Interest in= IEEE 802 is approximatively the equivalent of a non-WG forming BOF, and us= ually results in the formation of a Study Group which will look at the tech= nical feasibility and market aspects and prepare the charter of a future pr= oject.=20 I will attend the IEEE 802 Plenary next week. Please let me know if there a= re any questions, comments or concerns.=20 Thanks and Regards, Dan > -----Original Message----- > From: Law, David [mailto:dlaw@HPE.COM] > Sent: Wednesday, March 09, 2016 1:07 PM > To: STDS-802-3@LISTSERV.IEEE.ORG > Subject: [STDS-802-3] Consensus building presentation for the IEEE 802.3 > YANG data model(s) CFI now available >=20 > Dear Colleagues, >=20 > The consensus building presentations for the for the IEEE 802.3 YANG data > model(s) CFI is now available on http://ieee802.org/3/cfi/request_0316_1.html >=20 > Best regards, > David From nobody Wed Mar 9 08:11:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5275D12DF9E; Wed, 9 Mar 2016 08:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-rtNNgSaHSw; Wed, 9 Mar 2016 08:10:17 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAD612E0F2; Wed, 9 Mar 2016 08:02:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AGAgD+qt9W/xUHmMZcGQEBAQEPAQEBAYJfK4E/BrhKghMBDYFphg8CgUE4FAEBAQEBAQFkHAuEQQEBAQECARIoNAsFBwQCAQgNBAQBAQsUBQQHMhQJCAIEDgUIGod6CAGlMpl4AQEBAQEBAQMBAQEBAQEBAQEBARWGGIRBhDqDK4EPBZcrAY9ThESDGYU6jloeAQFCgjCBNGqIRiUWAX0BAQE X-IPAS-Result: A2AGAgD+qt9W/xUHmMZcGQEBAQEPAQEBAYJfK4E/BrhKghMBDYFphg8CgUE4FAEBAQEBAQFkHAuEQQEBAQECARIoNAsFBwQCAQgNBAQBAQsUBQQHMhQJCAIEDgUIGod6CAGlMpl4AQEBAQEBAQMBAQEBAQEBAQEBARWGGIRBhDqDK4EPBZcrAY9ThESDGYU6jloeAQFCgjCBNGqIRiUWAX0BAQE X-IronPort-AV: E=Sophos;i="5.24,310,1454994000"; d="scan'208";a="146006384" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Mar 2016 11:02:20 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 09 Mar 2016 11:02:19 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Wed, 9 Mar 2016 17:02:18 +0100 From: "Romascanu, Dan (Dan)" To: "ietf@ietf.org" Thread-Topic: Last Call: (Defining and Using Metadata with YANG) to Proposed Standard Thread-Index: AQHRbw42QO6jzW2l30iNn8jwXjUBNp9RW4UQ Date: Wed, 9 Mar 2016 16:02:16 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BF85B79@AZ-FFEXMB04.global.avaya.com> References: <20160224141730.8516.29327.idtracker@ietfa.amsl.com> In-Reply-To: <20160224141730.8516.29327.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod-chairs@ietf.org" , "draft-ietf-netmod-yang-metadata@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Last Call: (Defining and Using Metadata with YANG) to Proposed Standard 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, 09 Mar 2016 16:10:20 -0000 This documents looks fine to me.=20 I have one comment though.=20 In Section 6:=20 > [RFC6110] defines the standard mapping of YANG data models to Document Schema Definition Languages (DSDL) [ISO.19757-1]. This section specifies the mapping for the extension statement "md:annotation" (Section 7), which enables validation of XML instance documents containing metadata annotations. > The first step of the DSDL mapping procedure, i.e., the transformation of the YANG data model to the hybrid schema (see sec. 6 in [RFC6110]), is modified as follows: ... Does not this mean that the document updated RFC 6110 and this should be me= ntioned in the header?=20 Regards, Dan > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of > The IESG > Sent: Wednesday, February 24, 2016 4:18 PM > To: IETF-Announce > Cc: bclaise@cisco.com; netmod-chairs@ietf.org; draft-ietf-netmod-yang- > metadata@ietf.org; kwatsen@juniper.net; netmod@ietf.org > Subject: Last Call: (Defining an= d > Using Metadata with YANG) to Proposed Standard >=20 >=20 > The IESG has received a request from the NETCONF Data Modeling Language > WG (netmod) to consider the following document: > - 'Defining and Using Metadata with YANG' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits fin= al > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2016-03-09. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the beginnin= g of > the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document defines a YANG extension statement that allows for > defining metadata annotations in YANG modules. The document also > specifies XML and JSON encoding of annotations and other rules for > annotating instances of YANG data nodes. >=20 >=20 >=20 From nobody Wed Mar 9 08:46:35 2016 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 E6DA212D7C5; Wed, 9 Mar 2016 08:44:07 -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.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160309164407.23530.21492.idtracker@ietfa.amsl.com> Date: Wed, 09 Mar 2016 08:44:07 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-09.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: Wed, 09 Mar 2016 16:44:08 -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 : JSON Encoding of Data Modeled with YANG Author : Ladislav Lhotka Filename : draft-ietf-netmod-yang-json-09.txt Pages : 21 Date : 2016-03-09 Abstract: This document defines encoding rules for representing configuration data, state data, parameters of RPC operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-json-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-json-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 9 08:49:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1E512D7F5 for ; Wed, 9 Mar 2016 08:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_tWvXWXrI8J for ; Wed, 9 Mar 2016 08:47:15 -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 0D2EE12D9B3 for ; Wed, 9 Mar 2016 08:47:06 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:b88b:50ac:7db8:5b48] (unknown [IPv6:2001:718:1a02:1:b88b:50ac:7db8:5b48]) by mail.nic.cz (Postfix) with ESMTPSA id 8A0B31804E5 for ; Wed, 9 Mar 2016 17:47:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457542024; bh=QD+nsBkxJ4gRsnsS91uO/bBmjb99i9XPv8jYdHwoMVE=; h=From:Date:To; b=QIBvQJ/dtwsmi3uu/CE4KuFSypv9h+5UaJ5D+O2I2bK0O5O9W/ibKsVL0+JyG0WdW rP0/lzvX9afW3xDh477wQF1qhbbFoVoGlm1YpNbSdBhs4kmd2YBEW6EaQw/gFZ96Po FNdg7KmIYkAPpPKGMmNiANQaHBfGVRxPX0Wr7lSY= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2016 17:47:13 +0100 References: <20160309164408.23530.61087.idtracker@ietfa.amsl.com> To: NETMOD WG Message-Id: <599AB3E0-883F-470E-A43B-4E3A686ADD1E@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-09.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, 09 Mar 2016 16:47:18 -0000 Hi, changes in this revision are based on IETF LC comments. Lada > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-netmod-yang-json-09.txt > Date: 9 March 2016 at 17:44:08 GMT+1 > To: "Ladislav Lhotka" >=20 >=20 > A new version of I-D, draft-ietf-netmod-yang-json-09.txt > has been successfully submitted by Ladislav Lhotka and posted to the > IETF repository. >=20 > Name: draft-ietf-netmod-yang-json > Revision: 09 > Title: JSON Encoding of Data Modeled with YANG > Document date: 2016-03-09 > Group: netmod > Pages: 21 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-json-09.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-netmod-yang-json-09 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-json-09 >=20 > Abstract: > This document defines encoding rules for representing configuration > data, state data, parameters of RPC operations or actions, and > notifications defined using YANG as JavaScript Object Notation = (JSON) > text. >=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 9 09:06:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE4212D877; Wed, 9 Mar 2016 09:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5lnuBQ0Tdfq; Wed, 9 Mar 2016 09:04:06 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CA84A12DBD8; Wed, 9 Mar 2016 09:04:01 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 309891CC035F; Wed, 9 Mar 2016 18:04:01 +0100 (CET) From: Ladislav Lhotka To: Robert Sparks , General Area Review Team , "ietf\@ietf.org" , netmod@ietf.org, draft-ietf-netmod-yang-metadata.all@ietf.org In-Reply-To: <56D60EF5.7020001@nostrum.com> References: <56D60EF5.7020001@nostrum.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 09 Mar 2016 18:04:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04 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, 09 Mar 2016 17:04:08 -0000 Hi Robert, thanks for the review, I apologize for replying late, please see my responses inline: Robert Sparks writes: > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-netmod-yang-metadata-04 > Reviewer: Robert Sparks > Review Date: 1Mar2016 > IETF LC End Date: 9Mar2016 > IESG Telechat date: not yet scheduled > > Summary: Ready with nits > > 1) I might be missing something obvious, but the introduction has two > statements that don't seem aligned: > > " Values of annotations are not limited to strings; any YANG built-in or > derived type may be used for them" > and > "annotations are scalar values and cannot be further structured". These two statements are not in conflict: YANG data types (built-in or derived) apply to scalar values. > > If I'm not missing something, that may be more of an open issue than a nit. > > 2) The shepherd writeup calls out the tension in figuring out whether to > make this an extension or a new built-in statement. Please consider > capturing the reasoning for the path you chose in the draft itself. I will try, the main reason was that most people felt that introducing a new built-in statement is too big a change for the upcoming maintenance version of YANG (1.1) and YANG 2.0 is nowhere in sight. Thanks, Lada > > > > > > > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 9 09:10:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55D212E07B; Wed, 9 Mar 2016 09:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09-vnZYJ0jQL; Wed, 9 Mar 2016 09:07:49 -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 B3D9512E07D; Wed, 9 Mar 2016 09:07:11 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:b88b:50ac:7db8:5b48] (unknown [IPv6:2001:718:1a02:1:b88b:50ac:7db8:5b48]) by mail.nic.cz (Postfix) with ESMTPSA id 3B52A180313; Wed, 9 Mar 2016 18:07:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457543230; bh=TJzTKJehSGByyC1H2rRdshYuA2EAeuh+ksOTgtzIId4=; h=From:Date:To; b=gHk20Dy0A4s0Te5rLxSiPAxKMjRd939FMdNZGfNvAKY4A6RPANR7WHYQU3IzCgdW/ DW+v/wpu1aq/S7hWlqlNYwLVNoC2trxcF/RM0TitOw7cTaP5sUFOci2ynfQ4DJXNMs afRvwIVLtS6qHfLvBTLPQH7lT4XCeJ4kV8yvpgIs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF85B79@AZ-FFEXMB04.global.avaya.com> Date: Wed, 9 Mar 2016 18:07:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7113D59B-42A0-4E9E-8DFB-A77BF3F8134B@nic.cz> References: <20160224141730.8516.29327.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA6BF85B79@AZ-FFEXMB04.global.avaya.com> To: Dan Romascanu X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod-chairs@ietf.org" , "ietf@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-yang-metadata@ietf.org" Subject: Re: [netmod] Last Call: (Defining and Using Metadata with YANG) to Proposed Standard 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, 09 Mar 2016 17:07:51 -0000 Hi Dan, thanks for reviewing the document. > On 09 Mar 2016, at 17:02, Romascanu, Dan (Dan) = wrote: >=20 > This documents looks fine to me.=20 >=20 > I have one comment though.=20 >=20 > In Section 6:=20 >=20 >> [RFC6110] defines the standard mapping of YANG data models to > Document Schema Definition Languages (DSDL) [ISO.19757-1]. This > section specifies the mapping for the extension statement > "md:annotation" (Section 7), which enables validation of XML = instance > documents containing metadata annotations. >=20 >> The first step of the DSDL mapping procedure, i.e., the > transformation of the YANG data model to the hybrid schema (see > sec. 6 in [RFC6110]), is modified as follows: >=20 > ... >=20 > Does not this mean that the document updated RFC 6110 and this should = be mentioned in the header?=20 This is correct, and a good catch! I will update the header accordingly = in the next revision. =20 Lada >=20 > Regards, >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf = Of >> The IESG >> Sent: Wednesday, February 24, 2016 4:18 PM >> To: IETF-Announce >> Cc: bclaise@cisco.com; netmod-chairs@ietf.org; = draft-ietf-netmod-yang- >> metadata@ietf.org; kwatsen@juniper.net; netmod@ietf.org >> Subject: Last Call: = (Defining and >> Using Metadata with YANG) to Proposed Standard >>=20 >>=20 >> The IESG has received a request from the NETCONF Data Modeling = Language >> WG (netmod) to consider the following document: >> - 'Defining and Using Metadata with YANG' >> as Proposed Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits = final >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2016-03-09. Exceptionally, comments = may be >> sent to iesg@ietf.org instead. In either case, please retain the = beginning of >> the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> This document defines a YANG extension statement that allows for >> defining metadata annotations in YANG modules. The document also >> specifies XML and JSON encoding of annotations and other rules for >> annotating instances of YANG data nodes. >>=20 >>=20 >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 9 14:54:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBC012DAE3 for ; Wed, 9 Mar 2016 14:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, 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 sGoR6i3-6E9d for ; Wed, 9 Mar 2016 14:53:59 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id A042A12DAD0 for ; Wed, 9 Mar 2016 14:53:57 -0800 (PST) Received: (qmail 15108 invoked by uid 0); 9 Mar 2016 22:53:57 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 9 Mar 2016 22:53:57 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id U5tr1s00G2SSUrH015tuL4; Wed, 09 Mar 2016 22:53:54 -0700 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=MyQsoDTLrxAKGCqcPhoA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:To:Subject:From; bh=laWqiGDdnsfOFWuqfmSjAs9sUWXpF//TtQQTrT2lnQE=; b=Yzd/ETUqBfOIY1AHtLr8WU+ohI BknC/Z4CCSts/Em1lKSZCN0zipWIQq9SmRot+yeeZBo9cdbmRxL+/Tf+Q+oKmMSHYdjR7h7+S7avR W+xBTlo3UDDQ84+pr7bzOjsYZ; Received: from box313.bluehost.com ([69.89.31.113]:40661 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1admzK-0004CK-2w; Wed, 09 Mar 2016 15:53:54 -0700 From: Lou Berger To: "Eric Voit (evoit)" , netmod WG , "netmod-chairs@ietf.org" References: <56D4ACA6.40208@labn.net> Message-ID: <56E0A97E.7010304@labn.net> Date: Wed, 9 Mar 2016 17:53:50 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [netmod] Moving the WG discussion on mount forward 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, 09 Mar 2016 22:54:01 -0000 Eric, Great comments -- see below On 3/1/2016 5:56 PM, Eric Voit (evoit) wrote: > What I would like to see: > > (1) Terminology included which unambiguously partitions the functions of the three different type of mount options discussed in this WG (i.e., structural mount, alias mount, and peer mount). This would be needed even if only the structural mount technology itself is specified in the draft. I think this is a good topic to track / update as the solution captured in the document evolves. One question I have is what the WG draft on this topic should be called. I'm (without hat) leaning towards nemod-schema-mount in order to avoid the discussion/association with a particular solution approach. > (2) Agreement from draft authors that any Mount options build off of a common, extensible syntax. I'm pretty sure I heard all parties say that this was a good idea -- and I'd expect the WG to ensure that the WG solution heads that way (unless some agreed upon reason leads the WG away from this position.) > (3) Agreement from OpenDaylight developers that the peer mount definition corresponds to the meaning of their "Mount" I think this is something that will have to come from WG participants who are also (or can represent) ODL developers. Thanks, Lou > Eric > >> From: netmod, February 29, 2016 3:40 PM >> >> >> All, >> >> At last week's interim, Martin committed to update his document based on the >> meeting and then work with the other mount document authors (i.e., Lada and >> Alex) on a future version. Martin has now published this version: >> https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-02 >> >> Lada also said that he was okay with using Martin's document as a starting point >> for the working group document on this topic. (Keep in mind a -00 WG >> document is a starting point, not and end point.) >> >> We'd now like to ask for additional feedback from other WG contributors on >> their opinions on what they would like see added to base document in order for >> it to be accepted as a WG document. >> So please review the document and send comments to the list -- again on what >> areas need to be covered for the document to be accepted as a -00 WG draft. >> We're hoping for comments within the next week or so. >> >> Thank you, >> Netmod chairs >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Mar 10 00:37:10 2016 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 9F7AA12D5AF; Thu, 10 Mar 2016 00:37:06 -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.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160310083706.31153.14894.idtracker@ietfa.amsl.com> Date: Thu, 10 Mar 2016 00:37:06 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-metadata-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: Thu, 10 Mar 2016 08:37:07 -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 : Defining and Using Metadata with YANG Author : Ladislav Lhotka Filename : draft-ietf-netmod-yang-metadata-05.txt Pages : 20 Date : 2016-03-10 Abstract: This document defines a YANG extension statement that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-metadata-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 Thu Mar 10 00:44:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF95A12D5BC for ; Thu, 10 Mar 2016 00:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 vE09HCwZql9q for ; Thu, 10 Mar 2016 00:44:07 -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 D6A0312D5BB for ; Thu, 10 Mar 2016 00:44:06 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:dc65:c852:ec70:ab8a] (unknown [IPv6:2001:718:1a02:1:dc65:c852:ec70:ab8a]) by mail.nic.cz (Postfix) with ESMTPSA id 30305181A87 for ; Thu, 10 Mar 2016 09:44:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457599445; bh=6AlcxMGx3XhFhc9xR384hkzlw6KWOarQuXummmQ+l4E=; h=From:Date:To; b=YswzDxPa1MW8PmA+DChZ7KHt1aMmj0V+hC9KbNZHFK4RJggvRNd2uk8GRWZtCTkUX pjd+B3uvcBqFxBojXud0gzbIcWYDuGzTdG5MC8uqOrxsDZLTFX6jj5vSfuOCSmamUg 5f8l8IG+eyQY6giQ56yXtjcy2CTjh5WpYQc5Cm3I= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2016 09:44:04 +0100 References: <20160310083707.31153.2324.idtracker@ietfa.amsl.com> To: NETMOD WG Message-Id: <16BCE940-8DA3-4AC8-A8BE-BC2D6D98CF79@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.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, 10 Mar 2016 08:44:13 -0000 Hi, this revision is based on the IETF LC. In particular, Robert Sparks = suggested in his Gen-ART LC review to include an explanation as to why = we chose a YANG extension rather than a built-in statement. I added a = paragraph at the end of Introduction, please have a look, I hope it's a = fair account that shouldn't cause any controversy. Thanks, Lada > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-netmod-yang-metadata-05.txt > Date: 10 March 2016 at 09:37:07 GMT+1 > To: "Ladislav Lhotka" >=20 >=20 > A new version of I-D, draft-ietf-netmod-yang-metadata-05.txt > has been successfully submitted by Ladislav Lhotka and posted to the > IETF repository. >=20 > Name: draft-ietf-netmod-yang-metadata > Revision: 05 > Title: Defining and Using Metadata with YANG > Document date: 2016-03-10 > Group: netmod > Pages: 20 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-metadata-05.tx= t > Status: = https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-05 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-metadata-05 >=20 > Abstract: > This document defines a YANG extension statement that allows for > defining metadata annotations in YANG modules. The document also > specifies XML and JSON encoding of annotations and other rules for > annotating instances of YANG data nodes. >=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 10 01:18:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E962412D610 for ; Thu, 10 Mar 2016 01:18:17 -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 eRK9SzzNBIXB for ; Thu, 10 Mar 2016 01:18:16 -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 4E49B12D5DD for ; Thu, 10 Mar 2016 01:18:16 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1B2FE1103; Thu, 10 Mar 2016 10:18:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 293y-785HuN3; Thu, 10 Mar 2016 10:17:58 +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, 10 Mar 2016 10:18:14 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5438F2003C; Thu, 10 Mar 2016 10:18:14 +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 MQuAOszCeO3N; Thu, 10 Mar 2016 10:18:13 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC1D62003A; Thu, 10 Mar 2016 10:18:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D29843A2C1DB; Thu, 10 Mar 2016 10:18:11 +0100 (CET) Date: Thu, 10 Mar 2016 10:18:11 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160310091811.GB6652@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD WG References: <20160310083707.31153.2324.idtracker@ietfa.amsl.com> <16BCE940-8DA3-4AC8-A8BE-BC2D6D98CF79@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16BCE940-8DA3-4AC8-A8BE-BC2D6D98CF79@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD WG Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.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: Thu, 10 Mar 2016 09:18:18 -0000 On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka wrote: > Hi, > > this revision is based on the IETF LC. In particular, Robert Sparks suggested in his Gen-ART LC review to include an explanation as to why we chose a YANG extension rather than a built-in statement. I added a paragraph at the end of Introduction, please have a look, I hope it's a fair account that shouldn't cause any controversy. > I think it is a feature to use extensions for new statements that do not have to be in the core. Modularity is a good thing, the YANG 1.1. specification is already 200 papges. When adding new statements, we should rather ask the question 'can this not also be done using extensions'? /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 10 01:49:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008E412D5F4 for ; Thu, 10 Mar 2016 01:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 E-Zjq43hMOTf for ; Thu, 10 Mar 2016 01:49:36 -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 9C31212D62E for ; Thu, 10 Mar 2016 01:49:35 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:dc65:c852:ec70:ab8a] (unknown [IPv6:2001:718:1a02:1:dc65:c852:ec70:ab8a]) by mail.nic.cz (Postfix) with ESMTPSA id 6DAA3181B4B; Thu, 10 Mar 2016 10:49:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457603373; bh=zVCSvbC3y2T4wpZ/bI/9aNzPaUI4rRIOfhuBzuws3Bs=; h=From:Date:To; b=Vtd6NW8czmMWTvAdiCZckm/jbnZAgj7eonhP07k4X6c3/kgKpgkKAfX3ktxrrdS+z doIjfmadQBQxHzZeKb85xQIjKMiFjoTyZiXdhyw/GBgU3fyU5TMI0+Y/JKNKQ4VO5k VVKPNcsESZsIru8SpggTvWb+wI3v7UFi/Bvru8dw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160310091811.GB6652@elstar.local> Date: Thu, 10 Mar 2016 10:49:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <805898F5-C6F1-493A-A2BE-A017DED42AF3@nic.cz> References: <20160310083707.31153.2324.idtracker@ietfa.amsl.com> <16BCE940-8DA3-4AC8-A8BE-BC2D6D98CF79@nic.cz> <20160310091811.GB6652@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD WG Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.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, 10 Mar 2016 09:49:39 -0000 > On 10 Mar 2016, at 10:18, Juergen Schoenwaelder = wrote: >=20 > On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka wrote: >> Hi, >>=20 >> this revision is based on the IETF LC. In particular, Robert Sparks = suggested in his Gen-ART LC review to include an explanation as to why = we chose a YANG extension rather than a built-in statement. I added a = paragraph at the end of Introduction, please have a look, I hope it's a = fair account that shouldn't cause any controversy. >>=20 >=20 > I think it is a feature to use extensions for new statements that do > not have to be in the core. Modularity is a good thing, the YANG > 1.1. specification is already 200 papges. When adding new statements, > we should rather ask the question 'can this not also be done using > extensions'? I am not convinced about that. If we have a host of "standard" = extensions (annotation, complex-type and co., mount-point, mount-module, = you name them), every module author then may choose a subset of = extensions for use in the module, and then the value of YANG as a = standard data modelling language would be gone. This explains the glacial pace of development of schema languages - = there is a good reason for it. The following facts also don't help: - there is no way for indicating which extensions are supported; - sec. 11 in 6020bis allows extensions to be added in a new revision of = a module (it is not clear though whether this means definitions of = extensions, uses of extensions, or both). 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: E74E8C0C From nobody Thu Mar 10 02:16:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F5912D65C for ; Thu, 10 Mar 2016 02:16:29 -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 ynMZPtBvqHSP for ; Thu, 10 Mar 2016 02:16: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 F03E812D65A for ; Thu, 10 Mar 2016 02:16: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 6E61D1915; Thu, 10 Mar 2016 11:16:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rEsVv1ASuzLs; Thu, 10 Mar 2016 11:16:07 +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, 10 Mar 2016 11:16:23 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 920CE2003C; Thu, 10 Mar 2016 11:16:23 +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 PwLqpfMKwJRH; Thu, 10 Mar 2016 11:16:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09E032003A; Thu, 10 Mar 2016 11:16:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 987AB3A2C33A; Thu, 10 Mar 2016 11:16:20 +0100 (CET) Date: Thu, 10 Mar 2016 11:16:19 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160310101617.GA6973@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD WG References: <20160310083707.31153.2324.idtracker@ietfa.amsl.com> <16BCE940-8DA3-4AC8-A8BE-BC2D6D98CF79@nic.cz> <20160310091811.GB6652@elstar.local> <805898F5-C6F1-493A-A2BE-A017DED42AF3@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <805898F5-C6F1-493A-A2BE-A017DED42AF3@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD WG Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.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: Thu, 10 Mar 2016 10:16:29 -0000 On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka wrote: > > > On 10 Mar 2016, at 10:18, Juergen Schoenwaelder wrote: > > > > On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka wrote: > >> Hi, > >> > >> this revision is based on the IETF LC. In particular, Robert Sparks suggested in his Gen-ART LC review to include an explanation as to why we chose a YANG extension rather than a built-in statement. I added a paragraph at the end of Introduction, please have a look, I hope it's a fair account that shouldn't cause any controversy. > >> > > > > I think it is a feature to use extensions for new statements that do > > not have to be in the core. Modularity is a good thing, the YANG > > 1.1. specification is already 200 papges. When adding new statements, > > we should rather ask the question 'can this not also be done using > > extensions'? > > I am not convinced about that. If we have a host of "standard" extensions (annotation, complex-type and co., mount-point, mount-module, you name them), every module author then may choose a subset of extensions for use in the module, and then the value of YANG as a standard data modelling language would be gone. > There will be a natural filter; things that are widely used will be widely supported, things that are not widely supported will not be widely used. We have the same with protocols and protocol extensions, some gain more traction than others. /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 10 02:28:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F4C12D654 for ; Thu, 10 Mar 2016 02:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 Ktn0msbuLBOW for ; Thu, 10 Mar 2016 02:28:28 -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 6EA7B12D679 for ; Thu, 10 Mar 2016 02:28:16 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 59F8118180A; Thu, 10 Mar 2016 11:28:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457605693; bh=MTQvV9ZTM0fOV24UNQZhm62ZwQup9MYKjk6ePB8mTLY=; h=From:Date:To; b=nNMmv56H8pWvn51X0M1tzajjetyV5VZ1owXbTX/+frEywotTxE+/bfMwaVkvyz9Ak Y+1DpC7UaseGW3tctIAfUqdsl2utnEprNaRjV623oj8A32E7rDQuaVP4hu4qbACCzk IjszuAl/6lTOkz2Ax/3fcLEg93x8Qj4EaXmq3ojU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160310101617.GA6973@elstar.local> Date: Thu, 10 Mar 2016 11:28:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160310083707.31153.2324.idtracker@ietfa.amsl.com> <16BCE940-8DA3-4AC8-A8BE-BC2D6D98CF79@nic.cz> <20160310091811.GB6652@elstar.local> <805898F5-C6F1-493A-A2BE-A017DED42AF3@nic.cz> <20160310101617.GA6973@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD WG Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.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, 10 Mar 2016 10:28:33 -0000 > On 10 Mar 2016, at 11:16, Juergen Schoenwaelder = wrote: >=20 > On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka wrote: >>=20 >>> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder = wrote: >>>=20 >>> On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> this revision is based on the IETF LC. In particular, Robert Sparks = suggested in his Gen-ART LC review to include an explanation as to why = we chose a YANG extension rather than a built-in statement. I added a = paragraph at the end of Introduction, please have a look, I hope it's a = fair account that shouldn't cause any controversy. >>>>=20 >>>=20 >>> I think it is a feature to use extensions for new statements that do >>> not have to be in the core. Modularity is a good thing, the YANG >>> 1.1. specification is already 200 papges. When adding new = statements, >>> we should rather ask the question 'can this not also be done using >>> extensions'? >>=20 >> I am not convinced about that. If we have a host of "standard" = extensions (annotation, complex-type and co., mount-point, mount-module, = you name them), every module author then may choose a subset of = extensions for use in the module, and then the value of YANG as a = standard data modelling language would be gone. >>=20 >=20 > There will be a natural filter; things that are widely used will be > widely supported, things that are not widely supported will not be > widely used. We have the same with protocols and protocol extensions, Asymptotically, yes. But the modules developed in the meantime will be a = mess. > some gain more traction than others. Protocols are very different because they usually have means for = signalling/negotiating extensions. A schema, ideally, is a static = specification against which instance documents can be validated. With = some YANG extensions that are looming around this may not be the case = anymore. 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: E74E8C0C From nobody Thu Mar 10 03:19:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E641012D668 for ; Thu, 10 Mar 2016 03:19:56 -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 T80xXseCAon9 for ; Thu, 10 Mar 2016 03:19:54 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AF13312D69C for ; Thu, 10 Mar 2016 03:19:54 -0800 (PST) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 4565B1AE0308; Thu, 10 Mar 2016 12:19:53 +0100 (CET) Date: Thu, 10 Mar 2016 12:19:44 +0100 (CET) Message-Id: <20160310.121944.2299024553175685923.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <805898F5-C6F1-493A-A2BE-A017DED42AF3@nic.cz> <20160310101617.GA6973@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] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.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, 10 Mar 2016 11:19:57 -0000 Ladislav Lhotka wrote: > > > On 10 Mar 2016, at 11:16, Juergen Schoenwaelder > > wrote: > > > > On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka wrote: > >> > >>> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder > >>> wrote: > >>> > >>> On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka wrote: > >>>> Hi, > >>>> > >>>> this revision is based on the IETF LC. In particular, Robert Sparks > >>>> suggested in his Gen-ART LC review to include an explanation as to why > >>>> we chose a YANG extension rather than a built-in statement. I added a > >>>> paragraph at the end of Introduction, please have a look, I hope it's > >>>> a fair account that shouldn't cause any controversy. > >>>> > >>> > >>> I think it is a feature to use extensions for new statements that do > >>> not have to be in the core. Modularity is a good thing, the YANG > >>> 1.1. specification is already 200 papges. When adding new statements, > >>> we should rather ask the question 'can this not also be done using > >>> extensions'? > >> > >> I am not convinced about that. If we have a host of "standard" > >> extensions (annotation, complex-type and co., mount-point, > >> mount-module, you name them), every module author then may choose a > >> subset of extensions for use in the module Sure. The author will use the subset of core statement + extensions that is needed. If the module doesn't need meta-data, it won't be used regardless of if it's a core statement or an extension. > >> and then the value of YANG > >> as a standard data modelling language would be gone. > >> > > > > There will be a natural filter; things that are widely used will be > > widely supported, things that are not widely supported will not be > > widely used. We have the same with protocols and protocol extensions, > > Asymptotically, yes. But the modules developed in the meantime will be > a mess. I disagree. I agree w/ Juergen that defining extensions when it is possible is a feature. /martin > > some gain more traction than others. > > Protocols are very different because they usually have means for > signalling/negotiating extensions. A schema, ideally, is a static > specification against which instance documents can be validated. With > some YANG extensions that are looming around this may not be the case > anymore. > > 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: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Mar 10 03:34:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FB312D6A5 for ; Thu, 10 Mar 2016 03:34:44 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 enBLdBzdSMu9 for ; Thu, 10 Mar 2016 03:34:42 -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 0EF5312D644 for ; Thu, 10 Mar 2016 03:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2461; q=dns/txt; s=iport; t=1457609682; x=1458819282; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=BSB09MwPj3yswUvN9UuUlnw0lCFbW/I+I8NdBbPvMt0=; b=gwLhygzFZQxaFriUdWGskULWaj+Owh2cCFuvHHiUgekGUzJFeFRTlZ7W 2HT5dyJVMwWcrS79etqdquMIVnQTsa4G+QCtHxHmLuCaOLAa7vud6cBlt UQ7sDdTuf3k5apiy7yNbYfKGSiMFaeQkDVHKndC3WhLDFXCw5pukdErWo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQBsW+FW/xbLJq1ehH26XAENgW2GD?= =?us-ascii?q?wKBdxQBAQEBAQEBZCeEQgEBBDg/AQEQCw4CCAkMCg8JAwIBAgFFBgEMBgIBAYg?= =?us-ascii?q?gvScBAQEBAQEBAQEBAQEBAQEBAQEYhhiEQoR5g3sBBI0zigmNeIFkhEeDAoVSj?= =?us-ascii?q?moeAQFCgjCBNDwuiVMBAQE?= X-IronPort-AV: E=Sophos;i="5.24,315,1454976000"; d="scan'208";a="675461844" 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; 10 Mar 2016 11:34:39 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2ABYdqr024153; Thu, 10 Mar 2016 11:34:39 GMT To: Martin Bjorklund , lhotka@nic.cz References: <805898F5-C6F1-493A-A2BE-A017DED42AF3@nic.cz> <20160310101617.GA6973@elstar.local> <20160310.121944.2299024553175685923.mbj@tail-f.com> From: Robert Wilton Message-ID: <56E15BCF.5070305@cisco.com> Date: Thu, 10 Mar 2016 11:34:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160310.121944.2299024553175685923.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] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.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, 10 Mar 2016 11:34:44 -0000 On 10/03/2016 11:19, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>> On 10 Mar 2016, at 11:16, Juergen Schoenwaelder >>> wrote: >>> >>> On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka wrote: >>>>> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder >>>>> wrote: >>>>> >>>>> On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka wrote: >>>>>> Hi, >>>>>> >>>>>> this revision is based on the IETF LC. In particular, Robert Sparks >>>>>> suggested in his Gen-ART LC review to include an explanation as to why >>>>>> we chose a YANG extension rather than a built-in statement. I added a >>>>>> paragraph at the end of Introduction, please have a look, I hope it's >>>>>> a fair account that shouldn't cause any controversy. >>>>>> >>>>> I think it is a feature to use extensions for new statements that do >>>>> not have to be in the core. Modularity is a good thing, the YANG >>>>> 1.1. specification is already 200 papges. When adding new statements, >>>>> we should rather ask the question 'can this not also be done using >>>>> extensions'? >>>> I am not convinced about that. If we have a host of "standard" >>>> extensions (annotation, complex-type and co., mount-point, >>>> mount-module, you name them), every module author then may choose a >>>> subset of extensions for use in the module > Sure. The author will use the subset of core statement + extensions > that is needed. If the module doesn't need meta-data, it won't be > used regardless of if it's a core statement or an extension. > >>>> and then the value of YANG >>>> as a standard data modelling language would be gone. >>>> >>> There will be a natural filter; things that are widely used will be >>> widely supported, things that are not widely supported will not be >>> widely used. We have the same with protocols and protocol extensions, >> Asymptotically, yes. But the modules developed in the meantime will be >> a mess. > I disagree. I agree w/ Juergen that defining extensions when it is > possible is a feature. I actually also agree with Juergen and Martin. I see that the one of the advantages of using extensions is that it allows them to evolve independently and more quickly than the base draft. And I would think that it is easier to deprecate an old extension if it was superseded by a better approach. Rob From nobody Thu Mar 10 03:39:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B582412D6AA for ; Thu, 10 Mar 2016 03:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 QK5LCxs31nJl for ; Thu, 10 Mar 2016 03:39:12 -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 DC3EA12D69E for ; Thu, 10 Mar 2016 03:39:11 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:dc65:c852:ec70:ab8a] (unknown [IPv6:2001:718:1a02:1:dc65:c852:ec70:ab8a]) by mail.nic.cz (Postfix) with ESMTPSA id D42DB180D64; Thu, 10 Mar 2016 12:39:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457609949; bh=9y27RbMOzPsyWtACunpjNOwfIF5vxH+4u0VYcXNfcJM=; h=From:Date:To; b=wmK2mM9rQ8P/kfQt69Sku89S6EolQjFSwmKh67AjSJJheSH2rQGKw4YAht3k5e5ti LmCef42gxiXyO/QCnzSLBuvK2jNQMv5WmZcXm3rNuqnp2wBQOqjoNcBVRWB5EEGBDb RZINP//cj1YFAGP28BJRrO2kx+NPGpyqPo5f3NLQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160310.121944.2299024553175685923.mbj@tail-f.com> Date: Thu, 10 Mar 2016 12:39:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58C02DBE-1A52-46AF-A828-7D9BBEE0B3BC@nic.cz> References: <805898F5-C6F1-493A-A2BE-A017DED42AF3@nic.cz> <20160310101617.GA6973@elstar.local> <20160310.121944.2299024553175685923.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.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, 10 Mar 2016 11:39:14 -0000 > On 10 Mar 2016, at 12:19, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 10 Mar 2016, at 11:16, Juergen Schoenwaelder >>> wrote: >>>=20 >>> On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka wrote: >>>>=20 >>>>> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder >>>>> wrote: >>>>>=20 >>>>> On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka wrote: >>>>>> Hi, >>>>>>=20 >>>>>> this revision is based on the IETF LC. In particular, Robert = Sparks >>>>>> suggested in his Gen-ART LC review to include an explanation as = to why >>>>>> we chose a YANG extension rather than a built-in statement. I = added a >>>>>> paragraph at the end of Introduction, please have a look, I hope = it's >>>>>> a fair account that shouldn't cause any controversy. >>>>>>=20 >>>>>=20 >>>>> I think it is a feature to use extensions for new statements that = do >>>>> not have to be in the core. Modularity is a good thing, the YANG >>>>> 1.1. specification is already 200 papges. When adding new = statements, >>>>> we should rather ask the question 'can this not also be done using >>>>> extensions'? >>>>=20 >>>> I am not convinced about that. If we have a host of "standard" >>>> extensions (annotation, complex-type and co., mount-point, >>>> mount-module, you name them), every module author then may choose a >>>> subset of extensions for use in the module >=20 > Sure. The author will use the subset of core statement + extensions > that is needed. If the module doesn't need meta-data, it won't be > used regardless of if it's a core statement or an extension. If it is a built-in statement, implementations have no excuse to ignore = it. Even with metadata, an implementation that uses DSDL validation but = ignores some annotation definitions will find instance documents = containing them invalid. >=20 >>>> and then the value of YANG >>>> as a standard data modelling language would be gone. >>>>=20 >>>=20 >>> There will be a natural filter; things that are widely used will be >>> widely supported, things that are not widely supported will not be >>> widely used. We have the same with protocols and protocol = extensions, >>=20 >> Asymptotically, yes. But the modules developed in the meantime will = be >> a mess. >=20 > I disagree. I agree w/ Juergen that defining extensions when it is > possible is a feature. OK, so what about complex-type, that Balazs has just asked about? Do you = encourage authors of standard track modules to use it if they feel they = need it? Lada >=20 >=20 > /martin >=20 >>> some gain more traction than others. >>=20 >> Protocols are very different because they usually have means for >> signalling/negotiating extensions. A schema, ideally, is a static >> specification against which instance documents can be validated. With >> some YANG extensions that are looming around this may not be the case >> anymore. >>=20 >> Lada >>=20 >>>=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 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=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: E74E8C0C From nobody Thu Mar 10 03:42:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A5C12D6B8 for ; Thu, 10 Mar 2016 03:42:43 -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 XPrLWh2hR0cz for ; Thu, 10 Mar 2016 03:42:41 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1B16712D6B3 for ; Thu, 10 Mar 2016 03:42:41 -0800 (PST) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 315B21AE0308; Thu, 10 Mar 2016 12:42:40 +0100 (CET) Date: Thu, 10 Mar 2016 12:42:40 +0100 (CET) Message-Id: <20160310.124240.1736217873596240253.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <58C02DBE-1A52-46AF-A828-7D9BBEE0B3BC@nic.cz> References: <20160310.121944.2299024553175685923.mbj@tail-f.com> <58C02DBE-1A52-46AF-A828-7D9BBEE0B3BC@nic.cz> 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] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.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, 10 Mar 2016 11:42:44 -0000 Ladislav Lhotka wrote: > > > On 10 Mar 2016, at 12:19, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 10 Mar 2016, at 11:16, Juergen Schoenwaelder > >>> wrote: > >>> > >>> On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka wrote: > >>>> > >>>>> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder > >>>>> wrote: > >>>>> > >>>>> On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka wrote: > >>>>>> Hi, > >>>>>> > >>>>>> this revision is based on the IETF LC. In particular, Robert Sparks > >>>>>> suggested in his Gen-ART LC review to include an explanation as to why > >>>>>> we chose a YANG extension rather than a built-in statement. I added a > >>>>>> paragraph at the end of Introduction, please have a look, I hope it's > >>>>>> a fair account that shouldn't cause any controversy. > >>>>>> > >>>>> > >>>>> I think it is a feature to use extensions for new statements that do > >>>>> not have to be in the core. Modularity is a good thing, the YANG > >>>>> 1.1. specification is already 200 papges. When adding new statements, > >>>>> we should rather ask the question 'can this not also be done using > >>>>> extensions'? > >>>> > >>>> I am not convinced about that. If we have a host of "standard" > >>>> extensions (annotation, complex-type and co., mount-point, > >>>> mount-module, you name them), every module author then may choose a > >>>> subset of extensions for use in the module > > > > Sure. The author will use the subset of core statement + extensions > > that is needed. If the module doesn't need meta-data, it won't be > > used regardless of if it's a core statement or an extension. > > If it is a built-in statement, implementations have no excuse to > ignore it. Even with metadata, an implementation that uses DSDL > validation but ignores some annotation definitions will find instance > documents containing them invalid. > > > > >>>> and then the value of YANG > >>>> as a standard data modelling language would be gone. > >>>> > >>> > >>> There will be a natural filter; things that are widely used will be > >>> widely supported, things that are not widely supported will not be > >>> widely used. We have the same with protocols and protocol extensions, > >> > >> Asymptotically, yes. But the modules developed in the meantime will be > >> a mess. > > > > I disagree. I agree w/ Juergen that defining extensions when it is > > possible is a feature. > > OK, so what about complex-type, that Balazs has just asked about? Do > you encourage authors of standard track modules to use it if they feel > they need it? No - but not because it is an extension, but because it is Experimental. /martin From nobody Thu Mar 10 04:18:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0938012D6DC for ; Thu, 10 Mar 2016 04:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 pyZY07olEuq7 for ; Thu, 10 Mar 2016 04:18:06 -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 EE86512D6CF for ; Thu, 10 Mar 2016 04:18:05 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:dc65:c852:ec70:ab8a] (unknown [IPv6:2001:718:1a02:1:dc65:c852:ec70:ab8a]) by mail.nic.cz (Postfix) with ESMTPSA id 47C02181A70; Thu, 10 Mar 2016 13:18:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457612283; bh=N/P+DM0O+gTbpdWvl4y6G+FrCXFjwe0xvwgYck7JnrU=; h=From:Date:To; b=OetqsC0AOMvrGP4PLIsNXa4cKIuirIyq9Hdedwi9b+Iu/CSgcTZ/XOV2uDf54zWy3 J9Mm3yfYYKkHcQyQTRRsSy3xs6mTLkrruoHnknqNgcewkrkHFrEXEbqdsiayBJDqY7 mu0EUTActmq1qyK++Zo4FKoGnvNxGPhTVdnTfQiA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56E15BCF.5070305@cisco.com> Date: Thu, 10 Mar 2016 13:18:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9F528E97-A9BD-4C0B-A91A-22D39FA115D8@nic.cz> References: <805898F5-C6F1-493A-A2BE-A017DED42AF3@nic.cz> <20160310101617.GA6973@elstar.local> <20160310.121944.2299024553175685923.mbj@tail-f.com> <56E15BCF.5070305@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.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, 10 Mar 2016 12:18:09 -0000 > On 10 Mar 2016, at 12:34, Robert Wilton wrote: >=20 >=20 >=20 > On 10/03/2016 11:19, Martin Bjorklund wrote: >> Ladislav Lhotka wrote: >>>> On 10 Mar 2016, at 11:16, Juergen Schoenwaelder >>>> wrote: >>>>=20 >>>> On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka wrote: >>>>>> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder >>>>>> wrote: >>>>>>=20 >>>>>> On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> this revision is based on the IETF LC. In particular, Robert = Sparks >>>>>>> suggested in his Gen-ART LC review to include an explanation as = to why >>>>>>> we chose a YANG extension rather than a built-in statement. I = added a >>>>>>> paragraph at the end of Introduction, please have a look, I hope = it's >>>>>>> a fair account that shouldn't cause any controversy. >>>>>>>=20 >>>>>> I think it is a feature to use extensions for new statements that = do >>>>>> not have to be in the core. Modularity is a good thing, the YANG >>>>>> 1.1. specification is already 200 papges. When adding new = statements, >>>>>> we should rather ask the question 'can this not also be done = using >>>>>> extensions'? >>>>> I am not convinced about that. If we have a host of "standard" >>>>> extensions (annotation, complex-type and co., mount-point, >>>>> mount-module, you name them), every module author then may choose = a >>>>> subset of extensions for use in the module >> Sure. The author will use the subset of core statement + extensions >> that is needed. If the module doesn't need meta-data, it won't be >> used regardless of if it's a core statement or an extension. >>=20 >>>>> and then the value of YANG >>>>> as a standard data modelling language would be gone. >>>>>=20 >>>> There will be a natural filter; things that are widely used will be >>>> widely supported, things that are not widely supported will not be >>>> widely used. We have the same with protocols and protocol = extensions, >>> Asymptotically, yes. But the modules developed in the meantime will = be >>> a mess. >> I disagree. I agree w/ Juergen that defining extensions when it is >> possible is a feature. > I actually also agree with Juergen and Martin. >=20 > I see that the one of the advantages of using extensions is that it = allows them to evolve independently and more quickly than the base = draft. And I would think that it is easier to deprecate an old = extension if it was superseded by a better approach. This would all be fine as long as modules developed with such extensions = stay experimental, too. Lada >=20 > Rob -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 10 04:31:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB4812D6CD for ; Thu, 10 Mar 2016 04:31:32 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, WEIRD_PORT=0.001] autolearn=unavailable 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 zcRLieQ2DISK for ; Thu, 10 Mar 2016 04:31:29 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE3D12D705 for ; Thu, 10 Mar 2016 04:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SlDrt9neDzSYBpORvf4YBgG9NtEBlROg7t65vc2JJU8=; b=OgQfkSOWujO/cr0G19pPdSCPwsVn+axD4LLcfrlog1ycM/KFEUJQ41/ZGkTZ50c7omLrPWtkTrqNE6628XKBzFhVvqaV+7J637XNnEZVrTsQ+9+ZjG8FPH81PMeX/g/kTICeNGOG4Q8Ax7aXihscd8OeKKSmG/taVyrZBsYAV3c= 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.167.153.133) by AM4PR07MB1619.eurprd07.prod.outlook.com (10.166.132.149) with Microsoft SMTP Server (TLS) id 15.1.434.11; Thu, 10 Mar 2016 12:31:07 +0000 Message-ID: <02ec01d17ac8$2b2be580$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder , Benoit Claise References: <56D9630B.8060609@cisco.com> <20160304103343.GB35694@elstar.local> Date: Thu, 10 Mar 2016 12:25:12 +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.167.153.133] X-ClientProxiedBy: AM3PR02CA0056.eurprd02.prod.outlook.com (25.163.180.24) To AM4PR07MB1619.eurprd07.prod.outlook.com (25.166.132.149) X-MS-Office365-Filtering-Correlation-Id: 1e0ef995-92db-4fb8-29cf-08d348dfdb01 X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1619; 2:yeJOq6hluh517c4VewrBnZoFDJZKGr1WYuCrsp7/DcsT8KBdr/upD4D6P88YMMfURZbTYIVNGVdrwA6+v2Dl1PmRoxQz0zTPORz66yLSSM6g/o4VVXI8EoC3bgg0CijJwy0fRMtuwRH8KrfLjJuNp8oSe7cibiZsgLPbLH5ci22igkamFtxH5xJxiSioDCRN; 3:8tsI5RhFbUDbZ5BHHlOP4W3rxfl6I6HHtlYjPr6/D3NrZ1o5+ZeavWr8NFQlJX9OlAHT+Sj5QsV2dLBHWtCypKRIz8HHAuIo6vpt3J40XPv1LT/3Uox+92dTCU//wCa2; 25:tJUnvt3ye0ebkvNc/bXXYyHA3tSewW+bf0d7zPxcn41qUMT+TALLJhhJVbHh3jfEJ8da2DOhIeS4H+1tRWeUAW7uYopE3D4/NbxM3Phar1x6Xb1MGf0RRaaFjqacPZeDL4zM2/YaEDY9zpBommssKAhPQA4Ucky5RI05WGjK3n4eShcUMjL2JWms6g1fY83vQR8DbECOcSJp/ua4SZJCdz2rzX89QEIRA8NdYBS9dC5WYAsL0d8pLDDlcVI+qiuPe0O+AWbvX9Nh6Acmln3O90GeTk/Du1ZHKl27oPrs0uH8KpxrrhrOlZYhyxfqHzztbVZTlI2za3Eu1rQ0BTU9uQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1619; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM4PR07MB1619; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1619; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1619; 4:z1nyIO95eyPO8mvA+akN0b8nD+/qdTaEMbJ0PjPEl5KdAEw/sA77vYyc4Jp9Bipg59nGNJuk4VWww+3t0EBEDLj23uo9vSealAbmc2ydILEfXjde3QxjuTSAx8E51bJfQk3VFEgjFYdh4yIdm+UuKj941bNQAm4UPlU2py+DptscMmKxaqubMduLMrTfjGLHFOwj+xEEt7WDPi5gCxsBCkZkHZWeifWivNbUTdEpIa7WMEkA+MVHCQ44JPlP9o/nsrunjdrAV5Sh1PXERG4NrSyW8GLuJN+kg2LtAJDtWHhmotTevGmwmygsKCr5N/008kiHo2PqkKQyixzo1EkSnVqsLsWH4oWJRAEt59QcVIkwgtwAHAYNCBg8rRzL9K/09msONna6Su2GUXCqjsMWDRFnxepC6OJLQD0WZK2sj+g= X-Forefront-PRVS: 08770259B4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(279900001)(377454003)(13464003)(377424004)(24454002)(2473001)(15975445007)(77096005)(81686999)(81816999)(5001770100001)(19625305001)(230783001)(50226001)(5004730100002)(42186005)(44716002)(44736004)(97736004)(230700001)(116806002)(1556002)(1456003)(92566002)(23756003)(86362001)(14496001)(81166005)(50986999)(66066001)(76176999)(61296003)(106356001)(50466002)(33646002)(62236002)(19580405001)(189998001)(19580395003)(3846002)(6116002)(1096002)(47776003)(5008740100001)(586003)(84392002)(2906002)(4326007)(74416001)(7726001)(24704002)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1619; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM4PR07MB1619; 23:1bG3bGKNbRcQOjFclzFUKUk8M4a6c56bIn043bh?= =?iso-8859-1?Q?DWScC2Rdb13l6TfZ+S0n31Y2i9uuXpuxUwzgSZHAr7RwHRGVoKhffcXYFC?= =?iso-8859-1?Q?FnwTgOVyRqlhXiCqgeU/QO2OHjm/bztZyrREJqcUkLKXGNisy8YFsKj+rx?= =?iso-8859-1?Q?U+p50E0CaCo1mVY71EDr4255h7bjThMAQXdDqB9GaV6H6DE0F0jQ9hdFV9?= =?iso-8859-1?Q?UzCbSp+BhKSuFdibMkmcCZ49WrgxoX5oksHv4fusqfgA9V6xT97Z8DRHW/?= =?iso-8859-1?Q?j3FpZeoshpKuMruQKTje5HmmAUL/X9bOYUs0FsyWtTswwuJ8BwHwdKbpne?= =?iso-8859-1?Q?TBg7nKCR+v33o3VevG5vUIPEpOBQLq/LYAd6RLopMyG9c+h5oe/kE6AidI?= =?iso-8859-1?Q?eludX6XKp6UM6p5UJnSKoaAnq4LIEd2/jbsT1CrHh4OjkdgBNblbbyXkJL?= =?iso-8859-1?Q?kJTeNTlbjM1AN1r4+uF2eAIDUnIxed6JZt8OgRfQwY9fFZtL8Y1Mq+Ud5H?= =?iso-8859-1?Q?VPqzoMMGgtA/g0Yo31tm/plPnoKlhkn9n2qHrTqY1CoK98yf8Rg8nQe476?= =?iso-8859-1?Q?EsWeJRYpz0AqDuxSvPz3sE7vhaUOTR9Tc0tc9LZ+lxs3BLpGSukx9EqVVU?= =?iso-8859-1?Q?JCv5cB9CPRPZSuHjFPPWS6T2lQAmB9K9gBnAV8x6OLFM2gAiJe7IyzK6so?= =?iso-8859-1?Q?kqJ0GDZW0tskYcZ6FCJgEpMx3/QrzRol0WHXq/tX5jkNB7BGCqWdJkrz0K?= =?iso-8859-1?Q?zPBDBSYy+MH7zvENcbPaniBpWF/fikWH9ahDXI8vrN3oWH3GMwzOVAix8b?= =?iso-8859-1?Q?cpRE5HCgJeDCU2fkw9ACrBVwRcOqHsjVcGcQCvclM33JoA+041+dvvFEH6?= =?iso-8859-1?Q?4vExPkEEyFcqi9pC+TAD98/hEMaybFOXnUMMzEW2BqvLUBza+ww06rpvBV?= =?iso-8859-1?Q?zNBgdXKxl8EgN6f6neT4duWIjJMO4nlVHvUuXEaR1ij04Jl4WDyvxUW8F1?= =?iso-8859-1?Q?IFCofhHN+h8VFipJb0WcT7C7BkNPh0XlnfJowAGX7zg3zxUv0R+Sd9mOMj?= =?iso-8859-1?Q?PmExKDZSKoKSad514vZUU1eOlXdIhzFH8rkOQsk7iox0zc6+0cf13riJHO?= =?iso-8859-1?Q?+LqwbHeaiL5HAy4CRXE8pAeSQX5LSNz7iCQXHFuu6/tc8fPYeycObGeTx7?= =?iso-8859-1?Q?oh/+bO+7eJCY8Ry953BHk9p+phw8SFpt37Rqgh1sxPD3hCQUxQlxUDAgSk?= =?iso-8859-1?Q?kWjxeqT55//9KbUn37+uYhtHeAhtEH9tyoJcZhfmQzYovvv10pFgnby/XO?= =?iso-8859-1?Q?fpJlxMjod0tisFYGr5PCN9R4ULI/gD/7uF9sOxv9/EjdbjC/MizyolE7hK?= =?iso-8859-1?Q?ebAY8QT2qhKrgFCYkjCA3j6+3K6rcTmLG3yOyIXrbwKvHXkW4y2syiXTdr?= =?iso-8859-1?Q?9pWahkPG4rQgBw=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1619; 5:QB2n5QqvinsSvw9gOgA+w7yuV5VKAiMHxaVQMCOJcrt+a1GiVXjirVdOxWZU+JsjWgBNflmkCOgKp73tdSayiJrLzdARHIhpglw0VvfCY/xE71fBiJuwXF96BGKyAzMaYw7fZvCeTg3mTGP10rdRXg==; 24:K5jNTDK7goz0rqawAKl8WEY5U/a9ccKi2wFmyTqjtrjXIx9QFX439hBHAMewLam+TgYTaom9nA9r+S3r+kMCuEXduOD302J15XGcvPU5Xdk= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2016 12:31:07.5440 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1619 Archived-At: Cc: rtgwg-chairs@tools.ietf.org, NETMOD Working Group Subject: Re: [netmod] Fwd: Re: [Rtg-dt-yang-arch] I-D Action: draft-rtgyangdt-rtgwg-device-model-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: Thu, 10 Mar 2016 12:31:32 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Benoit Claise" Cc: ; "NETMOD Working Group" Sent: Friday, March 04, 2016 10:33 AM Subject: Re: [netmod] Fwd: Re: [Rtg-dt-yang-arch] I-D Action: draft-rtgyangdt-rtgwg-device-model-03.txt > Is the rtgyangdt chartered to define a structure that potentially > affects all YANG models produced in the IETF? Even if it were so chartered, I question the competence of it to do so. The vast majority of managed devices in the world are not network devices (for any widely used management architecture). One of the weaknesses of SNMP is that it started life as routing only, and had all the other managed devices added later so the structure has never been quite right for the common case (unless you are only concerned with the routing area). This I-D does make it clear how limited it is "we consider network devices that support protocols and functions defined within the IETF Routing Area" so it is clearly excluding most managed devices. It is understandable, if unfortunate, that SNMP suffers from having started out with a limited remit. It would be unforgiveable to build that limitation into YANG. Tom Petch > /js > > On Fri, Mar 04, 2016 at 11:27:23AM +0100, Benoit Claise wrote: > > Dear all, > > > > This draft is extremely important because it doesn't only cover routing > > information but it wants to impose a structure for all YANG models. > > Please review and comment. > > > > > > Regards, Benoit > > -------- Forwarded Message -------- > > Subject: Re: [Rtg-dt-yang-arch] I-D Action: > > draft-rtgyangdt-rtgwg-device-model-03.txt > > Date: Thu, 25 Feb 2016 17:55:31 +0000 > > From: Jeff Tantsura > > To: Lou Berger > > CC: Routing Area YANG Architecture DT , > > Routing WG > > > > > > > > Hi RTGWG, > > > > Given the importance of the document, please do review and provide your > > comments, suggestions and in case you wouldn't support it as is - what > > should be changed/missing. > > > > Thanks! > > > > Regards, > > Jeff > > > > >On Feb 23, 2016, at 6:40 PM, Lou Berger wrote: > > > > > > > > >Hello, > > > This draft has been updated to use an emerging yang capability > > >called 'schema-mount' [1] which translates to a significant > > >simplification. To quote the draft: > > > > > > Schema Mount enables a dramatic simplification of the presented > > > device model, particularly for "lower-end" devices which are unlikely > > > to support multiple network instances or logical network elements. > > > Should structural-mount/YSDL not be available, the more explicit tree > > > structure presented in earlier versions of this document will need to > > > be utilized. > > > > > >As it looks like there will soon be a netmod WG draft on schema mount, > > >we think it's time to ask the WG to consider adopting our draft as a RTG > > >WG draft. > > > > > >[1] There was a netmod interim on schema mount on Monday, see > > >http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222 > > > > > >Our slides from that meeting are available at > > >https://www.ietf.org/proceedings/interim/2016/02/22/netmod/slides/slide s-interim-2016-netmod-1-1.pptx > > >and it gives a brief overview of the current draft. > > > > > >Lou (and co-authors) > > >-------- Forwarded Message -------- > > >Subject: I-D Action: draft-rtgyangdt-rtgwg-device-model-03.txt > > >Date: Tue, 23 Feb 2016 18:29:51 -0800 > > >From: internet-drafts@ietf.org > > >Reply-To: internet-drafts@ietf.org > > >To: i-d-announce@ietf.org > > > > > > > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > > >directories. > > > > > > > > > Title : Network Device YANG Organizational Models > > > Authors : Acee Lindem > > > Lou Berger > > > Dean Bogdanovic > > > Christan Hopps > > > Filename : draft-rtgyangdt-rtgwg-device-model-03.txt > > > Pages : 36 > > > Date : 2016-02-23 > > > > > >Abstract: > > > This document presents an approach for organizing YANG models in a > > > comprehensive structure that may be used to configure and operate > > > network devices. The structure is itself represented as a YANG > > > model, with all of the related component models logically organized > > > in a way that is operationally intuitive, but this model is not > > > expected to be implemented. The identified component modules are > > > expected to be defined and implemented on common network devices. > > > > > > This document also defines two modules that can be used to model the > > > logical and virtual resource representations that may be present on a > > > network device. Examples of common industry terms for logical > > > resource representations are Logical Systems or Routers. Examples of > > > of common industry terms for virtual resource representations are > > > Virtual Routing and Forwarding (VRF) instances and Virtual Switch > > > Instances (VSIs). > > > > > > This document is derived from work submitted to the IETF by members > > > of the informal OpenConfig working group of network operators and is > > > a product of the Routing Area YANG Architecture design team. > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-rtgyangdt-rtgwg-device-model/ > > > > > >There's also a htmlized version available at: > > >https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-03 > > > > > >A diff from the previous version is available at: > > >https://www.ietf.org/rfcdiff?url2=draft-rtgyangdt-rtgwg-device-model-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/ > > > > > >_______________________________________________ > > >I-D-Announce mailing list > > >I-D-Announce@ietf.org > > >https://www.ietf.org/mailman/listinfo/i-d-announce > > >Internet-Draft directories: http://www.ietf.org/shadow.html > > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > >_______________________________________________ > > >rtgwg mailing list > > >rtgwg@ietf.org > > >https://www.ietf.org/mailman/listinfo/rtgwg > > > > _______________________________________________ > > Rtg-dt-yang-arch mailing list > > Rtg-dt-yang-arch@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > . > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Mar 10 07:38:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D3512D82E for ; Thu, 10 Mar 2016 07:38:46 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] 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 0W0JN9ScHwKH for ; Thu, 10 Mar 2016 07:38:42 -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 1B87A12D919 for ; Thu, 10 Mar 2016 07:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11758; q=dns/txt; s=iport; t=1457624318; x=1458833918; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ADOpUVupyTZ9QqLpWoPesBqStOI9BCvuqEF0Tyq6E5A=; b=S27WCVIhVKvbKQ0sL0TnaeZMil31y9oJyrMIRQFJXoisV7MLF7qKl7Ja 1wY4/4baiB75xPK96V0Q7sbOCAFY/3cyzxX5YPt2htl67/JeftRtHuWI2 FseuNrMOMlMgrqWb/5koZTNO4DU/y8tGevIGdPy0aMXkETAIyFiqThRZ5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDBQC4k+FW/xbLJq1bA4QQbQa5YoJxF?= =?us-ascii?q?wqFDxVKAhyBcAEBAQEBAWUnhEEBAQEEAQEBIBEzBwsMAgICAQgQAQECAQEBAQI?= =?us-ascii?q?CJgICAhkMCxQBAgYIAgQBDQUJEIgLDq4ajyQBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEVBHiJXoIrgWkkGAsmgjmBOgWXPAGFaYgOgWRLg3yHOoEahy2HPAFigjCBNGo?= =?us-ascii?q?BiBc9fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,316,1454976000"; d="scan'208";a="636151843" 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; 10 Mar 2016 15:38:35 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u2AFcYaB011255 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Mar 2016 15:38:35 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Mar 2016 10:38:34 -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.1104.009; Thu, 10 Mar 2016 10:38:34 -0500 From: "Acee Lindem (acee)" To: "t.petch" , Juergen Schoenwaelder , "Benoit Claise (bclaise)" Thread-Topic: [netmod] Fwd: Re: [Rtg-dt-yang-arch] I-D Action: draft-rtgyangdt-rtgwg-device-model-03.txt Thread-Index: AQHRdgB7MYjgvjdeFESjYbsQBT4ZCZ9JezsAgAkqZhSAADQxgA== Date: Thu, 10 Mar 2016 15:38:34 +0000 Message-ID: References: <56D9630B.8060609@cisco.com> <20160304103343.GB35694@elstar.local> <02ec01d17ac8$2b2be580$4001a8c0@gateway.2wire.net> In-Reply-To: <02ec01d17ac8$2b2be580$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: [10.116.152.199] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtgwg-chairs@tools.ietf.org" , NETMOD Working Group Subject: Re: [netmod] Fwd: Re: [Rtg-dt-yang-arch] I-D Action: draft-rtgyangdt-rtgwg-device-model-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: Thu, 10 Mar 2016 15:38:46 -0000 SGV5IFRvbSwgDQoNCk9uIDMvMTAvMTYsIDc6MjUgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIHQu cGV0Y2giDQo8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGlldGZjQGJ0Y29u bmVjdC5jb20+IHdyb3RlOg0KDQo+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZyb206 ICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGU+DQo+VG86ICJCZW5vaXQgQ2xhaXNlIiA8YmNsYWlzZUBjaXNjby5jb20+DQo+Q2M6IDxy dGd3Zy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyAiTkVUTU9EIFdvcmtpbmcgR3JvdXAiDQo+PG5l dG1vZEBpZXRmLm9yZz4NCj5TZW50OiBGcmlkYXksIE1hcmNoIDA0LCAyMDE2IDEwOjMzIEFNDQo+ U3ViamVjdDogUmU6IFtuZXRtb2RdIEZ3ZDogUmU6IFtSdGctZHQteWFuZy1hcmNoXSBJLUQgQWN0 aW9uOg0KPmRyYWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDMudHh0DQo+DQo+DQo+ PiBJcyB0aGUgcnRneWFuZ2R0IGNoYXJ0ZXJlZCB0byBkZWZpbmUgYSBzdHJ1Y3R1cmUgdGhhdCBw b3RlbnRpYWxseQ0KPj4gYWZmZWN0cyBhbGwgWUFORyBtb2RlbHMgcHJvZHVjZWQgaW4gdGhlIElF VEY/DQo+DQo+RXZlbiBpZiBpdCB3ZXJlIHNvIGNoYXJ0ZXJlZCwgSSBxdWVzdGlvbiB0aGUgY29t cGV0ZW5jZSBvZiBpdCB0byBkbyBzby4NCj5UaGUgdmFzdCBtYWpvcml0eSBvZiBtYW5hZ2VkIGRl dmljZXMgaW4gdGhlIHdvcmxkIGFyZSBub3QgbmV0d29yaw0KPmRldmljZXMgKGZvciBhbnkgd2lk ZWx5IHVzZWQgbWFuYWdlbWVudCBhcmNoaXRlY3R1cmUpLiAgT25lIG9mIHRoZQ0KPndlYWtuZXNz ZXMgb2YgU05NUCBpcyB0aGF0IGl0IHN0YXJ0ZWQgbGlmZSBhcyByb3V0aW5nIG9ubHksIGFuZCBo YWQgYWxsDQo+dGhlIG90aGVyIG1hbmFnZWQgZGV2aWNlcyBhZGRlZCBsYXRlciBzbyB0aGUgc3Ry dWN0dXJlIGhhcyBuZXZlciBiZWVuDQo+cXVpdGUgcmlnaHQgZm9yIHRoZSBjb21tb24gY2FzZSAo dW5sZXNzIHlvdSBhcmUgb25seSBjb25jZXJuZWQgd2l0aCB0aGUNCj5yb3V0aW5nIGFyZWEpLg0K Pg0KPlRoaXMgSS1EIGRvZXMgbWFrZSBpdCBjbGVhciBob3cgbGltaXRlZCBpdCBpcw0KPiJ3ZSBj b25zaWRlciBuZXR3b3JrIGRldmljZXMgdGhhdCBzdXBwb3J0IHByb3RvY29scw0KPiAgIGFuZCBm dW5jdGlvbnMgZGVmaW5lZCB3aXRoaW4gdGhlIElFVEYgUm91dGluZyBBcmVhIg0KPnNvIGl0IGlz IGNsZWFybHkgZXhjbHVkaW5nIG1vc3QgbWFuYWdlZCBkZXZpY2VzLg0KPg0KPkl0IGlzIHVuZGVy c3RhbmRhYmxlLCBpZiB1bmZvcnR1bmF0ZSwgdGhhdCBTTk1QIHN1ZmZlcnMgZnJvbSBoYXZpbmcN Cj5zdGFydGVkIG91dCB3aXRoIGEgbGltaXRlZCByZW1pdC4gIEl0IHdvdWxkIGJlIHVuZm9yZ2l2 ZWFibGUgdG8gYnVpbGQNCj50aGF0IGxpbWl0YXRpb24gaW50byBZQU5HLg0KDQpPbmUgb2YgdGhl IHByaW1hcnkgWUFORyBSb3V0aW5nIERlc2lnbiBUZWFtIHdvcmsgaXRlbXMgaXMgdG8gYWR2YW5j ZQ0KbWVjaGFuaXNtcyAoc3RydWN0dXJhbCBtb3VudCBvciBZU0RMKSB0byBhbGxvdyBwbGFjZW1l bnQgb2YgSUVURiBZQU5HDQptb2R1bGVzIGF0IGRpZmZlcmVudCBsZXZlbHMgb2YgdGhlIGRldmlj ZSBoaWVyYXJjaHkgZGVwZW5kZW50IG9uIHRoZQ0KcmVxdWlyZW1lbnRzIG9mIHRoYXQgZGV2aWNl LiAgSSB0aGluayB0aGlzIGlzIGNvbnNpc3RlbnQgd2l0aCBtYWtpbmcgWUFORw0KYW5kLCBldmVu IHRoZSBJRVRGIGRhdGEgbW9kZWxzLCByZXVzYWJsZSBmb3IgYW55IGNsYXNzIG9mIHRoZSBkZXZp Y2UuDQpIb3dldmVyLCB0aGUgZGV2aWNlIHRhcmdldGVkIGluIHRoZSBkZXZpY2UgbW9kZWwgZHJh ZnQgaXMsIGluIGZhY3QsIGENCmNhcnJpZXIgY2xhc3MgbmV0d29ya2luZyBkZXZpY2UuIEkgYmVs aWV2ZSBpdCB3b3VsZCBiZSBmb29saXNoIHRvIHRyeSBhbmQNCmRlZmluZSBhIOKAnG9uZSBzaXpl IGZpdHMgYWxs4oCdIGRldmljZSBtb2RlbC4NCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCj4NCj5Ub20g UGV0Y2gNCj4NCj4+IC9qcw0KPj4NCj4+IE9uIEZyaSwgTWFyIDA0LCAyMDE2IGF0IDExOjI3OjIz QU0gKzAxMDAsIEJlbm9pdCBDbGFpc2Ugd3JvdGU6DQo+PiA+IERlYXIgYWxsLA0KPj4gPg0KPj4g PiBUaGlzIGRyYWZ0IGlzIGV4dHJlbWVseSBpbXBvcnRhbnQgYmVjYXVzZSBpdCBkb2Vzbid0IG9u bHkgY292ZXINCj5yb3V0aW5nDQo+PiA+IGluZm9ybWF0aW9uIGJ1dCBpdCB3YW50cyB0byBpbXBv c2UgYSBzdHJ1Y3R1cmUgZm9yIGFsbCBZQU5HIG1vZGVscy4NCj4+ID4gUGxlYXNlIHJldmlldyBh bmQgY29tbWVudC4NCj4+ID4NCj4+ID4NCj4+ID4gUmVnYXJkcywgQmVub2l0DQo+PiA+IC0tLS0t LS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQo+PiA+IFN1YmplY3Q6IFJlOiBbUnRnLWR0 LXlhbmctYXJjaF0gSS1EIEFjdGlvbjoNCj4+ID4gZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmlj ZS1tb2RlbC0wMy50eHQNCj4+ID4gRGF0ZTogVGh1LCAyNSBGZWIgMjAxNiAxNzo1NTozMSArMDAw MA0KPj4gPiBGcm9tOiBKZWZmIFRhbnRzdXJhIDxqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbT4N Cj4+ID4gVG86IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQo+PiA+IENDOiBSb3V0aW5n IEFyZWEgWUFORyBBcmNoaXRlY3R1cmUgRFQgPHJ0Zy1kdC15YW5nLWFyY2hAaWV0Zi5vcmc+LA0K Pj4gPiBSb3V0aW5nIFdHIDxydGd3Z0BpZXRmLm9yZz4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4g SGkgUlRHV0csDQo+PiA+DQo+PiA+IEdpdmVuIHRoZSBpbXBvcnRhbmNlIG9mIHRoZSBkb2N1bWVu dCwgcGxlYXNlIGRvIHJldmlldyBhbmQgcHJvdmlkZQ0KPnlvdXINCj4+ID4gY29tbWVudHMsIHN1 Z2dlc3Rpb25zIGFuZCBpbiBjYXNlIHlvdSB3b3VsZG4ndCBzdXBwb3J0IGl0IGFzIGlzICAtDQo+ d2hhdA0KPj4gPiBzaG91bGQgYmUgY2hhbmdlZC9taXNzaW5nLg0KPj4gPg0KPj4gPiBUaGFua3Mh DQo+PiA+DQo+PiA+IFJlZ2FyZHMsDQo+PiA+IEplZmYNCj4+ID4NCj4+ID4gPk9uIEZlYiAyMywg MjAxNiwgYXQgNjo0MCBQTSwgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+ PiA+ID4NCj4+ID4gPg0KPj4gPiA+SGVsbG8sDQo+PiA+ID4gICBUaGlzIGRyYWZ0IGhhcyBiZWVu IHVwZGF0ZWQgdG8gdXNlIGFuIGVtZXJnaW5nIHlhbmcgIGNhcGFiaWxpdHkNCj4+ID4gPmNhbGxl ZCAnc2NoZW1hLW1vdW50JyBbMV0gd2hpY2ggdHJhbnNsYXRlcyB0byBhIHNpZ25pZmljYW50DQo+ PiA+ID5zaW1wbGlmaWNhdGlvbi4gIFRvIHF1b3RlIHRoZSBkcmFmdDoNCj4+ID4gPg0KPj4gPiA+ ICBTY2hlbWEgTW91bnQgZW5hYmxlcyBhIGRyYW1hdGljIHNpbXBsaWZpY2F0aW9uIG9mIHRoZSBw cmVzZW50ZWQNCj4+ID4gPiAgZGV2aWNlIG1vZGVsLCBwYXJ0aWN1bGFybHkgZm9yICJsb3dlci1l bmQiIGRldmljZXMgd2hpY2ggYXJlDQo+dW5saWtlbHkNCj4+ID4gPiAgdG8gc3VwcG9ydCBtdWx0 aXBsZSBuZXR3b3JrIGluc3RhbmNlcyBvciBsb2dpY2FsIG5ldHdvcmsNCj5lbGVtZW50cy4NCj4+ ID4gPiAgU2hvdWxkIHN0cnVjdHVyYWwtbW91bnQvWVNETCBub3QgYmUgYXZhaWxhYmxlLCB0aGUg bW9yZSBleHBsaWNpdA0KPnRyZWUNCj4+ID4gPiAgc3RydWN0dXJlIHByZXNlbnRlZCBpbiBlYXJs aWVyIHZlcnNpb25zIG9mIHRoaXMgZG9jdW1lbnQgd2lsbA0KPm5lZWQgdG8NCj4+ID4gPiAgYmUg dXRpbGl6ZWQuDQo+PiA+ID4NCj4+ID4gPkFzIGl0IGxvb2tzIGxpa2UgdGhlcmUgd2lsbCBzb29u IGJlIGEgbmV0bW9kIFdHIGRyYWZ0IG9uIHNjaGVtYQ0KPm1vdW50LA0KPj4gPiA+d2UgdGhpbmsg aXQncyB0aW1lIHRvIGFzayB0aGUgV0cgdG8gY29uc2lkZXIgYWRvcHRpbmcgb3VyIGRyYWZ0IGFz DQo+YSBSVEcNCj4+ID4gPldHIGRyYWZ0Lg0KPj4gPiA+DQo+PiA+ID5bMV0gVGhlcmUgd2FzIGEg bmV0bW9kIGludGVyaW0gb24gc2NoZW1hIG1vdW50IG9uIE1vbmRheSwgc2VlDQo+PiA+ID5odHRw Oi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmc6OTAwMC9wL25ldG1vZC1pbnRlcmltLTIwMTYwMjIy DQo+PiA+ID4NCj4+ID4gPk91ciBzbGlkZXMgZnJvbSB0aGF0IG1lZXRpbmcgYXJlIGF2YWlsYWJs ZSBhdA0KPj4gPg0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIw MTYvMDIvMjIvbmV0bW9kL3NsaWRlcy9zbGlkZQ0KPnMtaW50ZXJpbS0yMDE2LW5ldG1vZC0xLTEu cHB0eA0KPj4gPiA+YW5kIGl0IGdpdmVzIGEgYnJpZWYgb3ZlcnZpZXcgb2YgdGhlIGN1cnJlbnQg ZHJhZnQuDQo+PiA+ID4NCj4+ID4gPkxvdSAoYW5kIGNvLWF1dGhvcnMpDQo+PiA+ID4tLS0tLS0t LSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KPj4gPiA+U3ViamVjdDogICAgSS1EIEFjdGlv bjogZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmljZS1tb2RlbC0wMy50eHQNCj4+ID4gPkRhdGU6 ICAgIFR1ZSwgMjMgRmViIDIwMTYgMTg6Mjk6NTEgLTA4MDANCj4+ID4gPkZyb206ICAgIGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZw0KPj4gPiA+UmVwbHktVG86ICAgIGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZw0KPj4gPiA+VG86ICAgIGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPj4gPiA+DQo+PiA+ ID4NCj4+ID4gPg0KPj4gPiA+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+PiA+ID5kaXJlY3Rvcmllcy4NCj4+ID4gPg0K Pj4gPiA+DQo+PiA+ID4gICAgICAgVGl0bGUgICAgICAgICAgIDogTmV0d29yayBEZXZpY2UgWUFO RyBPcmdhbml6YXRpb25hbCBNb2RlbHMNCj4+ID4gPiAgICAgICBBdXRob3JzICAgICAgICAgOiBB Y2VlIExpbmRlbQ0KPj4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgIExvdSBCZXJnZXINCj4+ ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICBEZWFuIEJvZ2Rhbm92aWMNCj4+ID4gPiAgICAg ICAgICAgICAgICAgICAgICAgICBDaHJpc3RhbiBIb3Bwcw0KPj4gPiA+ICAgRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmljZS1tb2RlbC0wMy50eHQNCj4+ID4gPiAg IFBhZ2VzICAgICAgICAgICA6IDM2DQo+PiA+ID4gICBEYXRlICAgICAgICAgICAgOiAyMDE2LTAy LTIzDQo+PiA+ID4NCj4+ID4gPkFic3RyYWN0Og0KPj4gPiA+ICBUaGlzIGRvY3VtZW50IHByZXNl bnRzIGFuIGFwcHJvYWNoIGZvciBvcmdhbml6aW5nIFlBTkcgbW9kZWxzIGluDQo+YQ0KPj4gPiA+ ICBjb21wcmVoZW5zaXZlIHN0cnVjdHVyZSB0aGF0IG1heSBiZSB1c2VkIHRvIGNvbmZpZ3VyZSBh bmQgb3BlcmF0ZQ0KPj4gPiA+ICBuZXR3b3JrIGRldmljZXMuICBUaGUgc3RydWN0dXJlIGlzIGl0 c2VsZiByZXByZXNlbnRlZCBhcyBhIFlBTkcNCj4+ID4gPiAgbW9kZWwsIHdpdGggYWxsIG9mIHRo ZSByZWxhdGVkIGNvbXBvbmVudCBtb2RlbHMgbG9naWNhbGx5DQo+b3JnYW5pemVkDQo+PiA+ID4g IGluIGEgd2F5IHRoYXQgaXMgb3BlcmF0aW9uYWxseSBpbnR1aXRpdmUsIGJ1dCB0aGlzIG1vZGVs IGlzIG5vdA0KPj4gPiA+ICBleHBlY3RlZCB0byBiZSBpbXBsZW1lbnRlZC4gIFRoZSBpZGVudGlm aWVkIGNvbXBvbmVudCBtb2R1bGVzIGFyZQ0KPj4gPiA+ICBleHBlY3RlZCB0byBiZSBkZWZpbmVk IGFuZCBpbXBsZW1lbnRlZCBvbiBjb21tb24gbmV0d29yayBkZXZpY2VzLg0KPj4gPiA+DQo+PiA+ ID4gIFRoaXMgZG9jdW1lbnQgYWxzbyBkZWZpbmVzIHR3byBtb2R1bGVzIHRoYXQgY2FuIGJlIHVz ZWQgdG8gbW9kZWwNCj50aGUNCj4+ID4gPiAgbG9naWNhbCBhbmQgdmlydHVhbCByZXNvdXJjZSBy ZXByZXNlbnRhdGlvbnMgdGhhdCBtYXkgYmUgcHJlc2VudA0KPm9uIGENCj4+ID4gPiAgbmV0d29y ayBkZXZpY2UuICBFeGFtcGxlcyBvZiBjb21tb24gaW5kdXN0cnkgdGVybXMgZm9yIGxvZ2ljYWwN Cj4+ID4gPiAgcmVzb3VyY2UgcmVwcmVzZW50YXRpb25zIGFyZSBMb2dpY2FsIFN5c3RlbXMgb3Ig Um91dGVycy4NCj5FeGFtcGxlcyBvZg0KPj4gPiA+ICBvZiBjb21tb24gaW5kdXN0cnkgdGVybXMg Zm9yIHZpcnR1YWwgcmVzb3VyY2UgcmVwcmVzZW50YXRpb25zIGFyZQ0KPj4gPiA+ICBWaXJ0dWFs IFJvdXRpbmcgYW5kIEZvcndhcmRpbmcgKFZSRikgaW5zdGFuY2VzIGFuZCBWaXJ0dWFsIFN3aXRj aA0KPj4gPiA+ICBJbnN0YW5jZXMgKFZTSXMpLg0KPj4gPiA+DQo+PiA+ID4gIFRoaXMgZG9jdW1l bnQgaXMgZGVyaXZlZCBmcm9tIHdvcmsgc3VibWl0dGVkIHRvIHRoZSBJRVRGIGJ5DQo+bWVtYmVy cw0KPj4gPiA+ICBvZiB0aGUgaW5mb3JtYWwgT3BlbkNvbmZpZyB3b3JraW5nIGdyb3VwIG9mIG5l dHdvcmsgb3BlcmF0b3JzIGFuZA0KPmlzDQo+PiA+ID4gIGEgcHJvZHVjdCBvZiB0aGUgUm91dGlu ZyBBcmVhIFlBTkcgQXJjaGl0ZWN0dXJlIGRlc2lnbiB0ZWFtLg0KPj4gPiA+DQo+PiA+ID4NCj4+ ID4gPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K Pj4gPg0KPj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ydGd5YW5nZHQt cnRnd2ctZGV2aWNlLW1vZGVsLw0KPj4gPiA+DQo+PiA+ID5UaGVyZSdzIGFsc28gYSBodG1saXpl ZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+ID4gPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNlLW1vZGVsLTAzDQo+PiA+ID4NCj4+ID4gPkEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+ID4NCj4+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1k ZXZpY2UtbW9kZWwtMDMNCj4+ID4gPg0KPj4gPiA+DQo+PiA+ID5QbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4gPiA+c3Vi bWlzc2lvbg0KPj4gPiA+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdA0KPnRvb2xzLmlldGYub3JnLg0KPj4gPiA+DQo+PiA+ID5JbnRlcm5ldC1EcmFm dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiA+ID5mdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4gPiA+DQo+PiA+ID5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiA+SS1ELUFubm91bmNlIG1h aWxpbmcgbGlzdA0KPj4gPiA+SS1ELUFubm91bmNlQGlldGYub3JnDQo+PiA+ID5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPj4gPiA+SW50ZXJuZXQt RHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4+ID4g Pm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+PiA+ID4NCj4+ ID4gPg0KPj4gPiA+DQo+PiA+ID4NCj4+ID4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiA+ID5ydGd3ZyBtYWlsaW5nIGxpc3QNCj4+ID4gPnJ0Z3dn QGlldGYub3JnDQo+PiA+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Z3dnDQo+PiA+DQo+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiA+IFJ0Zy1kdC15YW5nLWFyY2ggbWFpbGluZyBsaXN0DQo+PiA+IFJ0Zy1kdC15 YW5nLWFyY2hAaWV0Zi5vcmcNCj4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGctZHQteWFuZy1hcmNoDQo+PiA+IC4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+DQo+PiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+IG5l dG1vZCBtYWlsaW5nIGxpc3QNCj4+ID4gbmV0bW9kQGlldGYub3JnDQo+PiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+Pg0KPj4NCj4+IC0tDQo+PiBKdWVy Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SA0KPj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3 NTkgQnJlbWVuIHwgR2VybWFueQ0KPj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8 aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+Pg0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QN Cj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= From nobody Thu Mar 10 09:00:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DD112DB26 for ; Thu, 10 Mar 2016 09:00:13 -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 1OWrA4KiBEpx for ; Thu, 10 Mar 2016 09:00:06 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 DF57D12DA73 for ; Thu, 10 Mar 2016 08:57:03 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id k15so122108702lbg.0 for ; Thu, 10 Mar 2016 08:57:03 -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:date:message-id:subject:from:to :cc; bh=iL6jKywC0CgrAY83OhKmW/8qJsQymH5s8o6dAoPXex0=; b=DuXZTYb8oxT4rCIWLVYhfGkph45iewY6nPWzoyStbGE7bCm55OExxe8es/mV3nOMvX VrvIuhAsuBxH74P4WtGcHnZd2ZtEFrokwHOfRsF4rMNAxNTQLe0BgoEz2yuKJIJKW0gS bWHq914RGmkTZOuE+kJ/YUISn4MTPdSrg2Qoa32LgiE76oGR8iMJ6Q9hnAPO6QNvfSv9 PIyr1u3yazaAPTuECLPLW3XC6FhuJuGcmL+3RZduyhD65Et6DL+YHbIQ6fsCjAVMWrFs Ly8cnNHz1yUGUVPdgMycX6hbg+VgJoWbJ+yrsNqgBBaAPGPAyGnkuEIgNgC7i4MfUO6H ppdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=iL6jKywC0CgrAY83OhKmW/8qJsQymH5s8o6dAoPXex0=; b=XCv0RelmMw1wophiW4WihdIi+7B/F17bf8vepCC2xVOLxa8fbR+JDuJ0XdepVrCjA0 UNy8WxF8SI5NdD+1ei2j2nL2Ow69lKKgrPfJHQKHEQhv4E+vWAi5m4HmXLP87uVmfdNX ItlKScDPzvdBc0ymvs0pCacJWut1okCQXsx7t8PJ4tx5He+zGbtlNnTnT3J1W1BIglnd BrZWSn+IIDT9Sh/K1G5zkXkIUSuUeF13mv1JYsTjhPHwpH3raBBOsqX8X4GFrjdXWu7t haCvO2BLjQqOZ6OejzkxEZ1gRq5cmnNeyfVBiejXz+u6cPyfm8UXsUue5rIAKqbMIFv+ zIUg== X-Gm-Message-State: AD7BkJKkoIW9fXLTagA4nCwB+6AYK+U8a8ERCLITp8aC0sWepIyoRS1S+FbYN0dh9Ah95lj8UeyzFXMRWAcpWg== MIME-Version: 1.0 X-Received: by 10.25.30.73 with SMTP id e70mr1622918lfe.13.1457629020323; Thu, 10 Mar 2016 08:57:00 -0800 (PST) Received: by 10.112.132.65 with HTTP; Thu, 10 Mar 2016 08:57:00 -0800 (PST) In-Reply-To: <9F528E97-A9BD-4C0B-A91A-22D39FA115D8@nic.cz> References: <805898F5-C6F1-493A-A2BE-A017DED42AF3@nic.cz> <20160310101617.GA6973@elstar.local> <20160310.121944.2299024553175685923.mbj@tail-f.com> <56E15BCF.5070305@cisco.com> <9F528E97-A9BD-4C0B-A91A-22D39FA115D8@nic.cz> Date: Thu, 10 Mar 2016 08:57:00 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11402758f896ad052db4b37e Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.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, 10 Mar 2016 17:00:14 -0000 --001a11402758f896ad052db4b37e Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2016 at 4:18 AM, Ladislav Lhotka wrote: > > > On 10 Mar 2016, at 12:34, Robert Wilton wrote: > > > > > > > > On 10/03/2016 11:19, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: > >>>> On 10 Mar 2016, at 11:16, Juergen Schoenwaelder > >>>> wrote: > >>>> > >>>> On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka wrote: > >>>>>> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder > >>>>>> wrote: > >>>>>> > >>>>>> On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> this revision is based on the IETF LC. In particular, Robert Sparks > >>>>>>> suggested in his Gen-ART LC review to include an explanation as to > why > >>>>>>> we chose a YANG extension rather than a built-in statement. I > added a > >>>>>>> paragraph at the end of Introduction, please have a look, I hope > it's > >>>>>>> a fair account that shouldn't cause any controversy. > >>>>>>> > >>>>>> I think it is a feature to use extensions for new statements that do > >>>>>> not have to be in the core. Modularity is a good thing, the YANG > >>>>>> 1.1. specification is already 200 papges. When adding new > statements, > >>>>>> we should rather ask the question 'can this not also be done using > >>>>>> extensions'? > >>>>> I am not convinced about that. If we have a host of "standard" > >>>>> extensions (annotation, complex-type and co., mount-point, > >>>>> mount-module, you name them), every module author then may choose a > >>>>> subset of extensions for use in the module > >> Sure. The author will use the subset of core statement + extensions > >> that is needed. If the module doesn't need meta-data, it won't be > >> used regardless of if it's a core statement or an extension. > >> > >>>>> and then the value of YANG > >>>>> as a standard data modelling language would be gone. > >>>>> > >>>> There will be a natural filter; things that are widely used will be > >>>> widely supported, things that are not widely supported will not be > >>>> widely used. We have the same with protocols and protocol extensions, > >>> Asymptotically, yes. But the modules developed in the meantime will be > >>> a mess. > >> I disagree. I agree w/ Juergen that defining extensions when it is > >> possible is a feature. > > I actually also agree with Juergen and Martin. > > > > I see that the one of the advantages of using extensions is that it > allows them to evolve independently and more quickly than the base draft. > And I would think that it is easier to deprecate an old extension if it was > superseded by a better approach. > > This would all be fine as long as modules developed with such extensions > stay experimental, too. > I think standard extensions can be in standard YANG modules. My problem with extensions is that they become mandatory-to-implement if the module is advertised. IMO, YANG 1.1 MUST require that if-feature-stmt can appear within an external statement. There is currently no way to create an optional extension. We have also received customer requests to allow the if-feature-stmt inside the deviation-stmt, which would be a really useful addition to YANG 1.1. > > Lada > > > > > Rob > Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11402758f896ad052db4b37e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 10, 2016 at 4:18 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 10 Mar 2016, at 12:34, Robert Wilton <rwilton@cisco.com> wrote:
>
>
>
> On 10/03/2016 11:19, Martin Bjorklund wrote:
>> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>>>> On 10 Mar 2016, at 11:16, Juergen Schoenwaelder
>>>> <j.schoenwaelder@jacobs-university.de> wrote:
>>>>
>>>> On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka = wrote:
>>>>>> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder >>>>>> <j.schoenwaelder@jacobs-university.de> wrote:
>>>>>>
>>>>>> On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav= Lhotka wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> this revision is based on the IETF LC. In part= icular, Robert Sparks
>>>>>>> suggested in his Gen-ART LC review to include = an explanation as to why
>>>>>>> we chose a YANG extension rather than a built-= in statement. I added a
>>>>>>> paragraph at the end of Introduction, please h= ave a look, I hope it's
>>>>>>> a fair account that shouldn't cause any co= ntroversy.
>>>>>>>
>>>>>> I think it is a feature to use extensions for new = statements that do
>>>>>> not have to be in the core. Modularity is a good t= hing, the YANG
>>>>>> 1.1. specification is already 200 papges. When add= ing new statements,
>>>>>> we should rather ask the question 'can this no= t also be done using
>>>>>> extensions'?
>>>>> I am not convinced about that. If we have a host of &q= uot;standard"
>>>>> extensions (annotation, complex-type and co., mount-po= int,
>>>>> mount-module, you name them), every module author then= may choose a
>>>>> subset of extensions for use in the module
>> Sure.=C2=A0 The author will use the subset of core statement + ext= ensions
>> that is needed.=C2=A0 If the module doesn't need meta-data, it= won't be
>> used regardless of if it's a core statement or an extension. >>
>>>>> and then the value of YANG
>>>>> as a standard data modelling language would be gone. >>>>>
>>>> There will be a natural filter; things that are widely use= d will be
>>>> widely supported, things that are not widely supported wil= l not be
>>>> widely used. We have the same with protocols and protocol = extensions,
>>> Asymptotically, yes. But the modules developed in the meantime= will be
>>> a mess.
>> I disagree.=C2=A0 I agree w/ Juergen that defining extensions when= it is
>> possible is a feature.
> I actually also agree with Juergen and Martin.
>
> I see that the one of the advantages of using extensions is that it al= lows them to evolve independently and more quickly than the base draft.=C2= =A0 And I would think that it is easier to deprecate an old extension if it= was superseded by a better approach.

This would all be fine as long as modules developed with such extensions st= ay experimental, too.


I think standard extensions can be in standard YANG modules.
My problem with extensions is that they become mandatory-to-implem= ent
if the module is advertised.

IMO, YA= NG 1.1 MUST require that if-feature-stmt can appear within an external stat= ement.
There is currently no way to create an optional extension.=

We have also received customer requests to allow = the if-feature-stmt inside
the deviation-stmt, which would be a r= eally useful addition to YANG 1.1.

=C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0

Lada

>
> Rob


Andy
= =C2=A0

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




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

--001a11402758f896ad052db4b37e-- From nobody Thu Mar 10 13:40:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA4F12DCAD for ; Thu, 10 Mar 2016 13:40: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=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 sWX5Zj_xp_Dn for ; Thu, 10 Mar 2016 13:39:59 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 2AF2812D6D8 for ; Thu, 10 Mar 2016 13:39:59 -0800 (PST) Received: (qmail 15813 invoked by uid 0); 10 Mar 2016 21:39:57 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 10 Mar 2016 21:39:57 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id UMft1s0122SSUrH01MfwJA; Thu, 10 Mar 2016 14:39:57 -0700 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=FTs38tw59TpTOJZZ52IA:9 a=QEXdDO2ut3YA:10 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:Cc:Subject:From:To; bh=Fcyx+n0enYralwflfP8hJYKoe7qfsPb/Pp+b7JU4pik=; b=cChoQfgy4fwbaYP+IXdaZ6tvWT gMs5xfx1OsQJxyIy7wjYQeHwfVpY9xNdfYz/JqIgN2/T+J0jMGQEd/2exzfCBeG4C3ZMvNEVekNHJ 1m9ThI59WVDyfG6OWgpndGyto; Received: from box313.bluehost.com ([69.89.31.113]:46244 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1ae8JF-0006bB-M6; Thu, 10 Mar 2016 14:39:53 -0700 To: netmod WG From: Lou Berger Message-ID: <56E1E9A4.20508@labn.net> Date: Thu, 10 Mar 2016 16:39:48 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod WG chairs Subject: [netmod] proposed change to WG IPR process 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, 10 Mar 2016 21:40:01 -0000 Hi, I'd like to propose that the WG follow the same process that I've used in other WGs with respect to IPR polling. In particular, that the template included below be sent to all authors and contributors named in a draft as part of: 1) WG acceptance (this is new for the WG), and 2) WG last call (only the template format is new) Please send any concerns/comments you may have to the list. We will start using this process in about a week assuming no objections. Thank you, Lou (new NETMOD co-chair) The template is as follows: To: <...> cc: WG, chairs Subject: Regarding IPR on Authors, Contributors, WG, As part of the preparation for WG Last Call Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, NETMOD WG Chairs PS Please include all listed in the headers of this message in your response. From nobody Thu Mar 10 14:04:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EA212D8C1 for ; Thu, 10 Mar 2016 14:04:48 -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 i2qv6R7Sm_Zb for ; Thu, 10 Mar 2016 14:04:47 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 2A90E12D6B7 for ; Thu, 10 Mar 2016 14:04:47 -0800 (PST) Received: (qmail 4616 invoked by uid 0); 10 Mar 2016 21:58:07 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 10 Mar 2016 21:58:07 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id UMy41s00v2SSUrH01My7ZT; Thu, 10 Mar 2016 14:58:07 -0700 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7OsogOcEt9IA:10 a=GQ0f6r4B8bqj_wv-yVwA:9 a=ul3Tf57cz-EJRdw2:21 a=hvdP-7uyRybEJj5E:21 a=QEXdDO2ut3YA:10 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; bh=HGw3G5PL41jNJSuhcR3JpNQR5RS3fIJui7XIPZvu3MA=; b=gLdTY0pgpySqrurKjIks3mrMhn saHfwXujyn8BqxHEotD/hwFLQZDkHIxJ+38tk7zrl18U6T704CtL7MBNiisk4Ma37v9ggQnidFZlz WQCpPVoc8OW7hpuoCiBm09Ly5; Received: from box313.bluehost.com ([69.89.31.113]:55897 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1ae8aq-0003Ps-G0; Thu, 10 Mar 2016 14:58:04 -0700 To: netmod WG References: <56D4AF14.3020903@labn.net> From: Lou Berger Message-ID: <56E1EDE7.5040907@labn.net> Date: Thu, 10 Mar 2016 16:57:59 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D4AF14.3020903@labn.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "netmod-chairs@ietf.org" , draft-ietf-netmod-syslog-model@ietf.org Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-syslog-model-06 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, 10 Mar 2016 22:04:48 -0000 All, It looks like we've already received sufficient comments that indicate that the document isn't ready for publication. Given the comments, we're looking to the authors to address comments received and any more that may be forthcoming. We're ending a little early to give the authors extra time before the meeting cut-off to address comments in a draft update that, hopefully, can be discussed in BA. Thank you, Lou (and Kent) On 2/29/2016 3:50 PM, Lou Berger wrote: > All, > This starts a two-week working group last call on > draft-ietf-netmod-syslog-model-06. > > The working group last call ends on March 14. Please send your comments > to the netmod mailing list. > > Positive comments, e.g., "I've reviewed this document and > believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thank you, > Netmod Chairs > > From nobody Thu Mar 10 14:21:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B8B12DE28; Thu, 10 Mar 2016 14:21:04 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 fBEeWzTqm-GK; Thu, 10 Mar 2016 14:21:03 -0800 (PST) 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 EEA8612DE17; Thu, 10 Mar 2016 14:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2012; q=dns/txt; s=iport; t=1457648463; x=1458858063; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=A5VgQ6beVL+lHVAntDWpcMsJ1pfJnK/hvTC/HwKznYI=; b=GnWgslOHHAWIMG68SCmKYRw5RJV+pmdenLYuR6RPEgS2+qzXCIqBE42W tTCOK56rJXir9W6FfwwW6UMZqBKM5vIJHgOgwu+a4C1yeQZJTy7+rakuR Kf66aGxqqDuXotB1KI+v1DKcKW8rp+lw8OnWdJsaGnw0F9HJizBfSXZw1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AgDi8uFW/4UNJK1egz6BPwZNq0iOS?= =?us-ascii?q?AENgW0xhV4CHIErOBQBAQEBAQEBZCdBEgGDbgEBBCMROgsQAgEIDgoCAiYCAgI?= =?us-ascii?q?wFRACBAENBYgjAa5JjxsBAQEBAQEBAQEBAQEBAQEBAQEBAQEVfIUcgXOCT4Q4G?= =?us-ascii?q?IJqK4EPAQSXPAGNd4FkhEeIVIYAiGkBHgEBQoNkaoJ2hl0BfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,317,1454976000"; d="scan'208";a="247153565" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2016 22:21:01 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u2AML1md031021 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Mar 2016 22:21:01 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Mar 2016 16:21:01 -0600 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.1104.009; Thu, 10 Mar 2016 16:21:01 -0600 From: "Clyde Wildes (cwildes)" To: Lou Berger , netmod WG Thread-Topic: WG Last Call: draft-ietf-netmod-syslog-model-06 Thread-Index: AQHRczL4SYFE8jI4BEq9VU5qEeNW859TrgCA//+AUgA= Date: Thu, 10 Mar 2016 22:21:01 +0000 Message-ID: References: <56D4AF14.3020903@labn.net> <56E1EDE7.5040907@labn.net> In-Reply-To: <56E1EDE7.5040907@labn.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: [171.69.106.27] Content-Type: text/plain; charset="utf-8" Content-ID: <812A5E26BE88794E9AC728EFB6F89BED@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod-chairs@ietf.org" , "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "draft-ietf-netmod-syslog-model@ietf.org" Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-syslog-model-06 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, 10 Mar 2016 22:21:04 -0000 TG91LA0KDQpXZSBhcmUgd29ya2luZyBvbiBhIHJldmlzaW9uIHRvIHRoZSBkb2N1bWVudCB0byBh ZGRyZXNzIHRoZSBjb25jZXJucyB0aGF0IE1hcnRpbiBhbmQgVG9tIHJhaXNlZC4NCg0KVGhlcmUg aXMgb25lIGlzc3VlIHRoYXQgSSBuZWVkIHRvIHJhaXNlIHRvIHRoZSBOZXRtb2QgY2hhaXJzIGZv ciBhZHZpY2U6IGFsbCBvdXIgZHJhZnRzIHNpbmNlIHRoZSBvcmlnaW5hbCBkcmFmdCBoYXZlICJJ bnRlbmRlZCBzdGF0dXM6IEluZm9ybWF0aW9uYWwiIGF0IHRoZSB0b3Agb2YgdGhlIGRyYWZ0LiBN YXJ0aW4gaW5kaWNhdGVkIHRoYXQgdGhpcyBzaG91bGQgYmUgIkludGVuZGVkIHN0YXR1czogU3Rh bmRhcmRzIFRyYWNrIiBhbmQgdGhhdCB0aGUgV0cgd2lsbCBoYXZlIHRvIGF1dGhvcml6ZSB0aGlz IGNoYW5nZSBpbiBzdGF0dXMuIFBsZWFzZSBhZHZpc2UuDQoNClRoYW5rcywNCg0KQ2x5ZGUNCg0K DQoNCk9uIDMvMTAvMTYsIDE6NTcgUE0sICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldD4g d3JvdGU6DQoNCj5BbGwsDQo+ICAgIEl0IGxvb2tzIGxpa2Ugd2UndmUgYWxyZWFkeSByZWNlaXZl ZCBzdWZmaWNpZW50IGNvbW1lbnRzIHRoYXQNCj5pbmRpY2F0ZSB0aGF0IHRoZSBkb2N1bWVudCBp c24ndCByZWFkeSBmb3IgcHVibGljYXRpb24uICBHaXZlbiB0aGUNCj5jb21tZW50cywgd2UncmUg bG9va2luZyB0byB0aGUgYXV0aG9ycyB0byBhZGRyZXNzIGNvbW1lbnRzIHJlY2VpdmVkIGFuZA0K PmFueSBtb3JlIHRoYXQgbWF5IGJlIGZvcnRoY29taW5nLiAgV2UncmUgZW5kaW5nIGEgbGl0dGxl IGVhcmx5IHRvIGdpdmUNCj50aGUgYXV0aG9ycyBleHRyYSB0aW1lIGJlZm9yZSB0aGUgbWVldGlu ZyBjdXQtb2ZmIHRvIGFkZHJlc3MgY29tbWVudHMgaW4NCj5hIGRyYWZ0IHVwZGF0ZSB0aGF0LCBo b3BlZnVsbHksIGNhbiBiZSBkaXNjdXNzZWQgaW4gQkEuIA0KPg0KPlRoYW5rIHlvdSwNCj4NCj5M b3UgKGFuZCBLZW50KQ0KPg0KPk9uIDIvMjkvMjAxNiAzOjUwIFBNLCBMb3UgQmVyZ2VyIHdyb3Rl Og0KPj4gQWxsLA0KPj4gVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBvbg0KPj4gZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTA2Lg0KPj4NCj4+IFRo ZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIE1hcmNoIDE0LiBQbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzDQo+PiB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4NCj4+DQo+PiBQb3Np dGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQNCj4+ IGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwgYXJlIHdlbGNvbWUhDQo+PiBU aGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy4NCj4+DQo+PiBU aGFuayB5b3UsDQo+PiBOZXRtb2QgQ2hhaXJzDQo+Pg0KPj4NCj4NCj4NCg== From nobody Thu Mar 10 15:57:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7901712DEEB; Thu, 10 Mar 2016 15:57:26 -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] 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 vvkVxpLPAj4D; Thu, 10 Mar 2016 15:57:24 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BA6E712DEE6; Thu, 10 Mar 2016 15:57:24 -0800 (PST) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2ANvNLL059725 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Thu, 10 Mar 2016 17:57:24 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: Ladislav Lhotka , General Area Review Team , "ietf@ietf.org" , netmod@ietf.org, draft-ietf-netmod-yang-metadata.all@ietf.org References: <56D60EF5.7020001@nostrum.com> From: Robert Sparks Message-ID: <56E209E3.4030805@nostrum.com> Date: Thu, 10 Mar 2016 17:57:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 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] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04 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, 10 Mar 2016 23:57:26 -0000 On 3/9/16 11:04 AM, Ladislav Lhotka wrote: > Hi Robert, > > thanks for the review, I apologize for replying late, please see my responses inline: > > Robert Sparks writes: > >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-netmod-yang-metadata-04 >> Reviewer: Robert Sparks >> Review Date: 1Mar2016 >> IETF LC End Date: 9Mar2016 >> IESG Telechat date: not yet scheduled >> >> Summary: Ready with nits >> >> 1) I might be missing something obvious, but the introduction has two >> statements that don't seem aligned: >> >> " Values of annotations are not limited to strings; any YANG built-in or >> derived type may be used for them" >> and >> "annotations are scalar values and cannot be further structured". > These two statements are not in conflict: YANG data types (built-in or > derived) apply to scalar values. I don't know what it means for a data type to apply to a value. Can you say that more simply? I think this is just a language thing, and being precise in the text will get past it. Are you saying all YANG data types (built-in or derived) have only scalar values? If so, you could change the second point in the document to say "Since annotations have only built-in or derived types, they can only have scalar values." But then, placing the point under "This document deliberately adopts some restrictions" doesn't make sense, and I suggest restructuring the discussion to only call out the restrictions (which appears to be to not place annotations on lists or leaf-lists) below that sentence. > >> If I'm not missing something, that may be more of an open issue than a nit. >> >> 2) The shepherd writeup calls out the tension in figuring out whether to >> make this an extension or a new built-in statement. Please consider >> capturing the reasoning for the path you chose in the draft itself. > I will try, the main reason was that most people felt that introducing a > new built-in statement is too big a change for the upcoming maintenance > version of YANG (1.1) and YANG 2.0 is nowhere in sight. > > Thanks, Lada > >> >> >> >> >> >> >> >> From nobody Thu Mar 10 15:59:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921D112DC09; Thu, 10 Mar 2016 15:59:44 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqGZxGOCG0wH; Thu, 10 Mar 2016 15:59:42 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.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 0DB3412DEE6; Thu, 10 Mar 2016 15:59:41 -0800 (PST) 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 (TLS) id 15.1.415.20; Thu, 10 Mar 2016 23:59:37 +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.0434.016; Thu, 10 Mar 2016 23:59:37 +0000 From: Kent Watsen To: Lou Berger , netmod WG Thread-Topic: [netmod] proposed change to WG IPR process Thread-Index: AQHRexVotIWGHAy94k+F1XtzpmL3yZ9TB88A Date: Thu, 10 Mar 2016 23:59:37 +0000 Message-ID: <3486928B-A032-4F64-8816-256DBB54428A@juniper.net> References: <56E1E9A4.20508@labn.net> In-Reply-To: <56E1E9A4.20508@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; 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; 5:eFig3vOioDOvH1h+oLZdyKCOaw6E0/bWr+/mGpPF3HXCJ+HiW7zJxS22/X0q4TZHXTWzR0gdUcdU/XidJWliTlRUTSsvquAS1tPNA5PYGNHw+3HETOEw/+CygF5RctrqPtH/rmeLMWx1nvNjLUQnew==; 24:9cypecVkKJ0Z4ihAkrQwiCt2+70I9x7mOx6DJPCXo1rE5wZJs45fgunEfcHRKJcNbvBbXjwuNVrJ5BEFgajAdfYmWfo/cqpWaCHvL24280Q= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: 9e810182-7c80-429a-b962-08d3494009a6 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 08770259B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(479174004)(164054003)(2900100001)(15975445007)(2950100001)(54356999)(81166005)(3660700001)(5002640100001)(5004730100002)(76176999)(50986999)(66066001)(11100500001)(1220700001)(3846002)(83716003)(99286002)(6116002)(4326007)(3280700002)(92566002)(586003)(189998001)(4001350100001)(19580405001)(86362001)(1096002)(102836003)(33656002)(10400500002)(5008740100001)(19580395003)(87936001)(77096005)(106116001)(5001770100001)(36756003)(2906002)(122556002)(82746002)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0C04588237AC6647ABC43BF6377FEE37@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2016 23:59:37.6777 (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: Cc: netmod WG chairs Subject: Re: [netmod] proposed change to WG IPR process 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, 10 Mar 2016 23:59:44 -0000 DQpDb250ZXh0OiB3ZSBhbHJlYWR5IGRpZCB0aGUgY2FsbCBmb3IgYWRvcHRpb24gb246DQoNCiAg ZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nDQogIGRyYWZ0LWVudGl0eWR0LW5ldG1v ZC1lbnRpdHkNCg0KDQpBbmQgbm93IHdlIG1heSB3YW50IHRvIHZlcmlmeSBJUFIgb24gdGhlbSBh cyB3ZWxsLi4uDQoNCkkgZm9yIG9uZSB0aGluayB0aGF0IGl04oCZcyBhIGZpbmUgaWRlYSBhbmQg d2FudCB0byB0aGFuayBMb3UgZm9yIHN1Z2dlc3RpbmcgaXQuDQoNCg0KDQpUaGFua3MsDQpLZW50 DQoNCg0KT24gMy8xMC8xNiwgNDozOSBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTG91IEJlcmdl ciIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsYmVyZ2VyQGxhYm4ubmV0 PiB3cm90ZToNCg0KPkhpLA0KPiAgICBJJ2QgbGlrZSB0byBwcm9wb3NlIHRoYXQgdGhlIFdHIGZv bGxvdyB0aGUgc2FtZSBwcm9jZXNzIHRoYXQgSSd2ZQ0KPnVzZWQgaW4gb3RoZXIgV0dzIHdpdGgg cmVzcGVjdCB0byBJUFIgcG9sbGluZy4gIEluIHBhcnRpY3VsYXIsIHRoYXQgdGhlDQo+dGVtcGxh dGUgaW5jbHVkZWQgYmVsb3cgYmUgc2VudCB0byBhbGwgYXV0aG9ycyBhbmQgY29udHJpYnV0b3Jz IG5hbWVkIGluDQo+YSBkcmFmdCBhcyBwYXJ0IG9mOg0KPjEpIFdHIGFjY2VwdGFuY2UgKHRoaXMg aXMgbmV3IGZvciB0aGUgV0cpLCBhbmQNCj4yKSBXRyBsYXN0IGNhbGwgKG9ubHkgdGhlIHRlbXBs YXRlIGZvcm1hdCBpcyBuZXcpDQo+DQo+UGxlYXNlIHNlbmQgYW55IGNvbmNlcm5zL2NvbW1lbnRz IHlvdSBtYXkgaGF2ZSB0byB0aGUgbGlzdC4gIFdlIHdpbGwNCj5zdGFydCB1c2luZyB0aGlzIHBy b2Nlc3MgaW4gYWJvdXQgYSB3ZWVrIGFzc3VtaW5nIG5vIG9iamVjdGlvbnMuDQo+DQo+VGhhbmsg eW91LA0KPkxvdQ0KPihuZXcgTkVUTU9EIGNvLWNoYWlyKQ0KPg0KPlRoZSB0ZW1wbGF0ZSBpcyBh cyBmb2xsb3dzOg0KPg0KPlRvOiA8aW5kaXZpZHVhbF9lbWFpbHNfaW5fZHJhZnQ+IDwuLi4+DQo+ Y2M6IFdHLCBjaGFpcnMNCj5TdWJqZWN0OiBSZWdhcmRpbmcgSVBSIG9uIDxkcmFmdC1uZXRtb2Qt Li4uPg0KPg0KPkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0csDQo+DQo+QXMgcGFydCBvZiB0aGUg cHJlcGFyYXRpb24gZm9yIFdHIExhc3QgQ2FsbA0KPg0KPkFyZSB5b3UgYXdhcmUgb2YgYW55IElQ UiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92ZT8NCj4NCj5QbGVhc2Ugc3Rh dGUgZWl0aGVyOg0KPg0KPiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGll cyB0byB0aGlzIGRyYWZ0Ig0KPm9yDQo+IlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxp ZXMgdG8gdGhpcyBkcmFmdCINCj4NCj5JZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2Vk IGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KPihzZWUgUkZDcyAzOTc5LCA0ODc5 LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KPg0KPklmIHllcyB0byB0aGUgYWJv dmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6DQo+DQo+IlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNj bG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0KPm9yDQo+Ik5vLCB0aGUg SVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQo+DQo+SWYgeW91IGFuc3dlciBubywgcGxlYXNl IHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsNCj5hcHByb3ByaWF0ZS4N Cj4NCj5JZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRv ciBwbGVhc2UgYW5zd2VyIHRoZQ0KPmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCBy ZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUNCj5hd2FyZSBvZiBhbnkgcmVsZXZh bnQgSVBSLiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQNCj5zdGFn ZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5k IGxpc3RlZA0KPmNvbnRyaWJ1dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBM SVNURUQgSU4gVEhJUyBNRVNTQUdFJ1MNCj5UTyBMSU5FUy4NCj4NCj5JZiB5b3UgYXJlIG9uIHRo ZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQN Cj5hcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxp Z2F0aW9ucyB1bmRlcg0KPnRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0 byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZQ0KPmF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24g YW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbQ0KPnBhcnRpY2lwYXRpbmcg aW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91cg0KPnVuZGlz Y2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlz dGVkIGFib3ZlDQo+YW5kDQo+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90 cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQo+DQo+VGhhbmsgeW91LA0KPk5FVE1PRCBX RyBDaGFpcnMNCj4NCj5QUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJz IG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQo+cmVzcG9uc2UuDQo+DQo+DQo+DQo+DQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFp bGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCg== From nobody Thu Mar 10 18:13:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC08712DFBE for ; Thu, 10 Mar 2016 18:13:02 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVxiKQGxLcOs for ; Thu, 10 Mar 2016 18:13:00 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.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 9D43512DFBC for ; Thu, 10 Mar 2016 18:13:00 -0800 (PST) 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 (TLS) id 15.1.434.16; Fri, 11 Mar 2016 02:12: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.0434.016; Fri, 11 Mar 2016 02:12:58 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: yang-next Thread-Index: AQHRezuHCjOy1QqTn0qmzv3NK6P/5w== Date: Fri, 11 Mar 2016 02:12:58 +0000 Message-ID: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 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: fd67145f-1018-41da-dcd2-08d34952aa43 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:f5/Qjrc3pgPVrmwVMAYMb2mS5HETYmsIUniOcX/ZAYRzBfMrTR62YSNdrhlGX/rKTYOiij/m8sdPsU44yt/EoMNpaMtOLTCnQU6lJdbyXGRvAu+GrGJu3sQ6S28Uas62IO417je9cGTnAoDqdoGzQw==; 24:HlhlMU1SbGINDNtnwdbQsKyjaJ84L1w9Wn+79Hv0CgMZQdpBxHXkCTSoKToKGKWDrFrp0R2IPcuahr3pgKmciOK+EmUkxSWiHYmEUUX+QTQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 087894CD3C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52044002)(19580395003)(5004730100002)(83506001)(82746002)(50986999)(54356999)(36756003)(87936001)(86362001)(83716003)(5008740100001)(11100500001)(10400500002)(1220700001)(2900100001)(1096002)(2351001)(586003)(2906002)(102836003)(3846002)(1730700002)(6116002)(15975445007)(77096005)(16236675004)(107886002)(106116001)(92566002)(99286002)(189998001)(110136002)(229853001)(4001350100001)(2501003)(5002640100001)(81166005)(33656002)(3280700002)(450100001)(5640700001)(66066001)(122556002)(3660700001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_30334F54346144B2B19E0C512ADFD802junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2016 02:12:58.1466 (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: [netmod] yang-next 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, 11 Mar 2016 02:13:02 -0000 --_000_30334F54346144B2B19E0C512ADFD802junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpBbGwsDQoNCkkgc2VlIHRvbyBtYW55IGVtYWlscyBnbyBieSB3aGVyZSBzb21lb25lIGhhcyBh biBpZGVhIHRoYXQgdGhleeKAmWQgbGlrZSB0byBnZXQgaW50byBhIGZ1dHVyZSB2ZXJzaW9uIG9m IFlBTkcsIGFuZCBrZWVwIHdpc2hpbmcgdGhhdCB0aGVyZSB3ZXJlIGFuIGVhc3kgd2F5IHRvIGNh cHR1cmUgdGhlc2UgZmVhdHVyZSByZXF1ZXN0cy4gIFdpdGggdGhhdCBpbiBtaW5kIEkgY3JlYXRl ZCBhIG5ldyBHaXRodWIgcmVwb3NpdG9yeSBjYWxsZWQgInlhbmctbmV4dOKAnS4gICAgVGhpcyBy ZXBvc2l0b3J5IGlzIG5vdCBmb3IgYSBkcmFmdCwgeWV0LCBpdHMgY3VycmVudCBleGlzdGVuY2Ug aXMgc29sZWx5IHRvIGhhdmUgYSBwdWJsaWNseSBlZGl0YWJsZSBpc3N1ZSB0cmFja2VyLiAgIFBs ZWFzZSBmZWVsIGZyZWUgdG8gYWRkIGFsbCB5b3VyIGdvb2QgaWRlYXMgKGp1c3Qgb25lIGlkZWEg cGVyIGlzc3VlIHBsZWFzZSkgaGVyZTogaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy95YW5n LW5leHQvaXNzdWVzLg0KDQpDaGVlcnMsDQpLZW50DQoNCg0KDQoNCg== --_000_30334F54346144B2B19E0C512ADFD802junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <2B1B5AF79F6BC143AEF1C860C48382B9@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+QWxsLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBzZWUgdG9vIG1h bnkgZW1haWxzIGdvIGJ5IHdoZXJlIHNvbWVvbmUgaGFzIGFuIGlkZWEgdGhhdCB0aGV54oCZZCBs aWtlIHRvIGdldCBpbnRvIGEgZnV0dXJlIHZlcnNpb24gb2YgWUFORywgYW5kIGtlZXAgd2lzaGlu ZyB0aGF0IHRoZXJlIHdlcmUgYW4gZWFzeSB3YXkgdG8gY2FwdHVyZSB0aGVzZSBmZWF0dXJlIHJl cXVlc3RzLiAmbmJzcDtXaXRoIHRoYXQgaW4gbWluZCBJIGNyZWF0ZWQgYSBuZXcgR2l0aHViIHJl cG9zaXRvcnkgY2FsbGVkICZxdW90O3lhbmctbmV4dOKAnS4NCiAmbmJzcDsgJm5ic3A7VGhpcyBy ZXBvc2l0b3J5IGlzIG5vdCBmb3IgYSBkcmFmdCwgeWV0LCBpdHMgY3VycmVudCBleGlzdGVuY2Ug aXMgc29sZWx5IHRvIGhhdmUgYSBwdWJsaWNseSBlZGl0YWJsZSBpc3N1ZSB0cmFja2VyLiAmbmJz cDsgUGxlYXNlIGZlZWwgZnJlZSB0byBhZGQgYWxsIHlvdXIgZ29vZCBpZGVhcyAoanVzdCBvbmUg aWRlYSBwZXIgaXNzdWUgcGxlYXNlKSBoZXJlOiBodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdn L3lhbmctbmV4dC9pc3N1ZXMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaGVlcnMs PC9kaXY+DQo8ZGl2PktlbnQ8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBp ZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_30334F54346144B2B19E0C512ADFD802junipernet_-- From nobody Thu Mar 10 18:29:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CE212DC51 for ; Thu, 10 Mar 2016 18:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, 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 02vVIfJEDEr2 for ; Thu, 10 Mar 2016 18:29:10 -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 4F4DB12DCAB for ; Thu, 10 Mar 2016 18:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8242; q=dns/txt; s=iport; t=1457663350; x=1458872950; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=vKAvmU2Tn39BtoiEGmjAYi3JvccgMMgwSGBYG6zpv6A=; b=X/kKod0c2N3v9AfVOQ2ZiBM/OvkVTwMUB6W7Me3p46njSCgYZwpgLkSm OnFeQ8sFq9rcqCUrCU8yMHEJt0dDTNCVvVLIPeX98mctxColL+NpwfvI0 yrTJd2eYWR/Lg3F7CHpfiY5nfSWBBU0g87AHc+nls4h1Vh/HpdG5xBk8c s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApBQDbLOJW/51dJa1egnJMUm0GujGBb?= =?us-ascii?q?SGFbgIcgSU6EgEBAQEBAQFkJ4RBAQEBBCMKXAIBCA4DBAEBKAMCAgIwFAkIAgQ?= =?us-ascii?q?BEgiIHA6uNo8iAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSKWoRnCYJKgToFlz0Bh?= =?us-ascii?q?WuICIFrhEeIVI5rAScBOoNkaolTAX0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,318,1454976000"; d="scan'208,217";a="246567041" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2016 02:29:09 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u2B2T8AK005083 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Mar 2016 02:29:09 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Mar 2016 21:29:08 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Thu, 10 Mar 2016 21:29:08 -0500 From: "Alexander Clemm (alex)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: yang-next Thread-Index: AQHRezuHCjOy1QqTn0qmzv3NK6P/559ThNdA Date: Fri, 11 Mar 2016 02:29:08 +0000 Message-ID: <365d3bcd9bfd4e1e8aeb9c1f5517eda6@XCH-RTP-001.cisco.com> References: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> In-Reply-To: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> 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: [128.107.151.15] Content-Type: multipart/alternative; boundary="_000_365d3bcd9bfd4e1e8aeb9c1f5517eda6XCHRTP001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] yang-next 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, 11 Mar 2016 02:29:12 -0000 --_000_365d3bcd9bfd4e1e8aeb9c1f5517eda6XCHRTP001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93IGFib3V0IGNhbGxpbmcgaXQgWUFOR05HPw0KQ2hlZXJzDQotLS0gQWxleA0KDQpGcm9tOiBu ZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtlbnQg V2F0c2VuDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTAsIDIwMTYgNjoxMyBQTQ0KVG86IG5ldG1v ZEBpZXRmLm9yZw0KU3ViamVjdDogW25ldG1vZF0geWFuZy1uZXh0DQoNCg0KQWxsLA0KDQpJIHNl ZSB0b28gbWFueSBlbWFpbHMgZ28gYnkgd2hlcmUgc29tZW9uZSBoYXMgYW4gaWRlYSB0aGF0IHRo ZXnigJlkIGxpa2UgdG8gZ2V0IGludG8gYSBmdXR1cmUgdmVyc2lvbiBvZiBZQU5HLCBhbmQga2Vl cCB3aXNoaW5nIHRoYXQgdGhlcmUgd2VyZSBhbiBlYXN5IHdheSB0byBjYXB0dXJlIHRoZXNlIGZl YXR1cmUgcmVxdWVzdHMuICBXaXRoIHRoYXQgaW4gbWluZCBJIGNyZWF0ZWQgYSBuZXcgR2l0aHVi IHJlcG9zaXRvcnkgY2FsbGVkICJ5YW5nLW5leHTigJ0uICAgIFRoaXMgcmVwb3NpdG9yeSBpcyBu b3QgZm9yIGEgZHJhZnQsIHlldCwgaXRzIGN1cnJlbnQgZXhpc3RlbmNlIGlzIHNvbGVseSB0byBo YXZlIGEgcHVibGljbHkgZWRpdGFibGUgaXNzdWUgdHJhY2tlci4gICBQbGVhc2UgZmVlbCBmcmVl IHRvIGFkZCBhbGwgeW91ciBnb29kIGlkZWFzIChqdXN0IG9uZSBpZGVhIHBlciBpc3N1ZSBwbGVh c2UpIGhlcmU6IGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cveWFuZy1uZXh0L2lzc3Vlcy4N Cg0KQ2hlZXJzLA0KS2VudA0KDQoNCg0KDQo= --_000_365d3bcd9bfd4e1e8aeb9c1f5517eda6XCHRTP001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ib3cgYWJvdXQgY2FsbGluZyBpdCBZQU5HTkc/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLS0gQWxleDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gbmV0bW9kIFttYWlsdG86bmV0bW9kLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPktlbnQgV2F0c2VuPGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAxMCwgMjAxNiA2OjEzIFBNPGJyPg0KPGI+VG86PC9i PiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW25ldG1vZF0geWFuZy1uZXh0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5BbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgc2VlIHRvbyBtYW55IGVtYWlscyBnbyBieSB3aGVy ZSBzb21lb25lIGhhcyBhbiBpZGVhIHRoYXQgdGhleeKAmWQgbGlrZSB0byBnZXQgaW50byBhIGZ1 dHVyZSB2ZXJzaW9uIG9mIFlBTkcsIGFuZCBrZWVwIHdpc2hpbmcgdGhhdCB0aGVyZSB3ZXJlIGFu IGVhc3kgd2F5IHRvIGNhcHR1cmUNCiB0aGVzZSBmZWF0dXJlIHJlcXVlc3RzLiAmbmJzcDtXaXRo IHRoYXQgaW4gbWluZCBJIGNyZWF0ZWQgYSBuZXcgR2l0aHViIHJlcG9zaXRvcnkgY2FsbGVkICZx dW90O3lhbmctbmV4dOKAnS4gJm5ic3A7ICZuYnNwO1RoaXMgcmVwb3NpdG9yeSBpcyBub3QgZm9y IGEgZHJhZnQsIHlldCwgaXRzIGN1cnJlbnQgZXhpc3RlbmNlIGlzIHNvbGVseSB0byBoYXZlIGEg cHVibGljbHkgZWRpdGFibGUgaXNzdWUgdHJhY2tlci4gJm5ic3A7IFBsZWFzZSBmZWVsIGZyZWUg dG8gYWRkIGFsbCB5b3VyIGdvb2QNCiBpZGVhcyAoanVzdCBvbmUgaWRlYSBwZXIgaXNzdWUgcGxl YXNlKSBoZXJlOiA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL3lhbmctbmV4 dC9pc3N1ZXMiPg0KaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy95YW5nLW5leHQvaXNzdWVz PC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ S2VudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_365d3bcd9bfd4e1e8aeb9c1f5517eda6XCHRTP001ciscocom_-- From nobody Thu Mar 10 18:40:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6761F12DCC5 for ; Thu, 10 Mar 2016 18:40:38 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 0De1jIbm5HxX for ; Thu, 10 Mar 2016 18:40:36 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::748]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18DF12DC28 for ; Thu, 10 Mar 2016 18:40:35 -0800 (PST) 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 (TLS) id 15.1.415.20; Fri, 11 Mar 2016 02:40: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.0434.016; Fri, 11 Mar 2016 02:40:13 +0000 From: Kent Watsen To: "Alexander Clemm (alex)" , "netmod@ietf.org" Thread-Topic: yang-next Thread-Index: AQHRezuHCjOy1QqTn0qmzv3NK6P/559ThNdA//+vjIA= Date: Fri, 11 Mar 2016 02:40:13 +0000 Message-ID: References: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> <365d3bcd9bfd4e1e8aeb9c1f5517eda6@XCH-RTP-001.cisco.com> In-Reply-To: <365d3bcd9bfd4e1e8aeb9c1f5517eda6@XCH-RTP-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 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; BN3PR0501MB1444; 5:KFdRFgA+3NFFFsaA/N7ha2550nLOh6qDqikO1ENtCbgcCGvV7i0OwwJbhKZsifUqRSOzZhgP86uxqwIRSPeHn1Ke8ypzTPE49ret+Y29y25zyPpKMCDQtHW9DK295aSG1dY2RvzlazGGF123MYe6yQ==; 24:qNIIgelV1yQTuCnoGs9407Tm8Oij1MAVUPhqSsAsxHxZEsmw/uIzqKV+83nkgRxwgkHADVUOO/ocgQ3kfNBnDoqbnZPCg4cPNLINQIWbDLk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: 736fec20-929f-47a3-bf7e-08d34956793b x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 087894CD3C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(52044002)(377454003)(102836003)(33656002)(87936001)(107886002)(16236675004)(10400500002)(5008740100001)(19580395003)(189998001)(586003)(86362001)(1096002)(4001350100001)(19580405001)(122556002)(82746002)(83506001)(2906002)(77096005)(19625215002)(19617315012)(36756003)(106116001)(5001770100001)(19300405004)(2900100001)(2950100001)(15975445007)(3660700001)(81166005)(2501003)(1220700001)(6116002)(99286002)(83716003)(3846002)(11100500001)(3280700002)(92566002)(54356999)(5002640100001)(790700001)(66066001)(5004730100002)(50986999)(76176999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F4378A55781D4422A7A67F3AFBE2291Fjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2016 02:40:13.8408 (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-next 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, 11 Mar 2016 02:40:38 -0000 --_000_F4378A55781D4422A7A67F3AFBE2291Fjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIHdhcyBqdXN0IHRoaW5raW5nIGFib3V0IGhvdyB3ZSBhbHdheXMgdGFsayBhYm91dCB5YW5n LTEuMSwgeWFuZy0xLjIsIHlhbmctMi4wLCBzbyBJIGZpZ3VyZWQgeWFuZy1uZXh0ICA7KQ0KDQoN CkZyb206ICJBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpIiA8YWxleEBjaXNjby5jb208bWFpbHRvOmFs ZXhAY2lzY28uY29tPj4NCkRhdGU6IFRodXJzZGF5LCBNYXJjaCAxMCwgMjAxNiBhdCA5OjI5IFBN DQpUbzogS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVu aXBlci5uZXQ+PiwgIm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPiIgPG5l dG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiB5YW5n LW5leHQNCg0KSG93IGFib3V0IGNhbGxpbmcgaXQgWUFOR05HPw0KQ2hlZXJzDQotLS0gQWxleA0K DQpGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEtlbnQgV2F0c2VuDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTAsIDIwMTYgNjoxMyBQTQ0K VG86IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogW25l dG1vZF0geWFuZy1uZXh0DQoNCg0KQWxsLA0KDQpJIHNlZSB0b28gbWFueSBlbWFpbHMgZ28gYnkg d2hlcmUgc29tZW9uZSBoYXMgYW4gaWRlYSB0aGF0IHRoZXnigJlkIGxpa2UgdG8gZ2V0IGludG8g YSBmdXR1cmUgdmVyc2lvbiBvZiBZQU5HLCBhbmQga2VlcCB3aXNoaW5nIHRoYXQgdGhlcmUgd2Vy ZSBhbiBlYXN5IHdheSB0byBjYXB0dXJlIHRoZXNlIGZlYXR1cmUgcmVxdWVzdHMuICBXaXRoIHRo YXQgaW4gbWluZCBJIGNyZWF0ZWQgYSBuZXcgR2l0aHViIHJlcG9zaXRvcnkgY2FsbGVkICJ5YW5n LW5leHTigJ0uICAgIFRoaXMgcmVwb3NpdG9yeSBpcyBub3QgZm9yIGEgZHJhZnQsIHlldCwgaXRz IGN1cnJlbnQgZXhpc3RlbmNlIGlzIHNvbGVseSB0byBoYXZlIGEgcHVibGljbHkgZWRpdGFibGUg aXNzdWUgdHJhY2tlci4gICBQbGVhc2UgZmVlbCBmcmVlIHRvIGFkZCBhbGwgeW91ciBnb29kIGlk ZWFzIChqdXN0IG9uZSBpZGVhIHBlciBpc3N1ZSBwbGVhc2UpIGhlcmU6IGh0dHBzOi8vZ2l0aHVi LmNvbS9uZXRtb2Qtd2cveWFuZy1uZXh0L2lzc3Vlcy4NCg0KQ2hlZXJzLA0KS2VudA0KDQoNCg0K DQo= --_000_F4378A55781D4422A7A67F3AFBE2291Fjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pkkgd2FzIGp1c3QgdGhpbmtpbmcgYWJvdXQgaG93IHdlIGFsd2F5cyB0 YWxrIGFib3V0IHlhbmctMS4xLCB5YW5nLTEuMiwgeWFuZy0yLjAsIHNvIEkgZmlndXJlZCB5YW5n LW5leHQgJm5ic3A7Oyk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0i TUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9y OmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBu b25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdI VDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRp dW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+RnJvbTogPC9zcGFuPiZxdW90O0FsZXhhbmRlciBDbGVtbSAoYWxleCkmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzphbGV4QGNpc2NvLmNvbSI+YWxleEBjaXNjby5jb208L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXksIE1h cmNoIDEwLCAyMDE2IGF0IDk6MjkgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+VG86IDwvc3Bhbj5LZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVu aXBlci5uZXQiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFp bHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJFOiB5YW5nLW5l eHQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl OndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQv MTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPG1ldGEg bmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVk aXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5Ib3cgYWJvdXQgY2FsbGluZyBpdCBZQU5HTkc/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyI+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+LS0tIEFsZXg8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4gbmV0bW9kIFs8YSBocmVmPSJtYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPktlbnQgV2F0c2VuPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBNYXJjaCAxMCwgMjAxNiA2OjEzIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86 bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFtuZXRtb2RdIHlhbmctbmV4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogYmxhY2s7Ij5BbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+SSBzZWUgdG9vIG1hbnkgZW1haWxzIGdvIGJ5IHdoZXJl IHNvbWVvbmUgaGFzIGFuIGlkZWEgdGhhdCB0aGV54oCZZCBsaWtlIHRvIGdldCBpbnRvIGEgZnV0 dXJlIHZlcnNpb24gb2YgWUFORywgYW5kIGtlZXAgd2lzaGluZyB0aGF0IHRoZXJlIHdlcmUgYW4g ZWFzeSB3YXkgdG8NCiBjYXB0dXJlIHRoZXNlIGZlYXR1cmUgcmVxdWVzdHMuICZuYnNwO1dpdGgg dGhhdCBpbiBtaW5kIEkgY3JlYXRlZCBhIG5ldyBHaXRodWIgcmVwb3NpdG9yeSBjYWxsZWQgJnF1 b3Q7eWFuZy1uZXh04oCdLiAmbmJzcDsgJm5ic3A7VGhpcyByZXBvc2l0b3J5IGlzIG5vdCBmb3Ig YSBkcmFmdCwgeWV0LCBpdHMgY3VycmVudCBleGlzdGVuY2UgaXMgc29sZWx5IHRvIGhhdmUgYSBw dWJsaWNseSBlZGl0YWJsZSBpc3N1ZSB0cmFja2VyLiAmbmJzcDsgUGxlYXNlIGZlZWwgZnJlZSB0 byBhZGQgYWxsIHlvdXINCiBnb29kIGlkZWFzIChqdXN0IG9uZSBpZGVhIHBlciBpc3N1ZSBwbGVh c2UpIGhlcmU6IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cveWFuZy1uZXh0 L2lzc3VlcyI+DQpodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL3lhbmctbmV4dC9pc3N1ZXM8 L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBi bGFjazsiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5LZW50PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IGJsYWNrOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F4378A55781D4422A7A67F3AFBE2291Fjunipernet_-- From nobody Fri Mar 11 00:33:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FAD12D56E for ; Fri, 11 Mar 2016 00:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 gRqDwl0HW38L for ; Fri, 11 Mar 2016 00:33: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 AD6B512D571 for ; Fri, 11 Mar 2016 00:33:36 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:78b3:e555:d573:5b15] (unknown [IPv6:2001:718:1a02:1:78b3:e555:d573:5b15]) by mail.nic.cz (Postfix) with ESMTPSA id 1899E181BC1; Fri, 11 Mar 2016 09:33:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457685214; bh=qfieqL6am1k9UbfvuClc0UztDrrW7VJylSoPixohx6g=; h=From:Date:To; b=Z5lv/6UHYFZOl4OL9c1Pt5uTbVv/iz+8QywTX2W1cq8mwjp3jp289L5v7qE7oEQy7 YdWQhare9/+NFlfNqcTlT57oUVWMha+8QW2Lx0jfESHBRT9VrgYNMwxumooPrAUBDf jYUS4AZq/JyHfJawRqKd+Aqm9T8lzUpsUtDZNciM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 11 Mar 2016 09:33:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <60F41468-69E3-4853-8488-FF07CB07F5C6@nic.cz> References: <805898F5-C6F1-493A-A2BE-A017DED42AF3@nic.cz> <20160310101617.GA6973@elstar.local> <20160310.121944.2299024553175685923.mbj@tail-f.com> <56E15BCF.5070305@cisco.com> <9F528E97-A9BD-4C0B-A91A-22D39FA115D8@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.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: Fri, 11 Mar 2016 08:33:40 -0000 > On 10 Mar 2016, at 17:57, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Mar 10, 2016 at 4:18 AM, Ladislav Lhotka = wrote: >=20 > > On 10 Mar 2016, at 12:34, Robert Wilton wrote: > > > > > > > > On 10/03/2016 11:19, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: > >>>> On 10 Mar 2016, at 11:16, Juergen Schoenwaelder > >>>> wrote: > >>>> > >>>> On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka wrote: > >>>>>> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder > >>>>>> wrote: > >>>>>> > >>>>>> On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka = wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> this revision is based on the IETF LC. In particular, Robert = Sparks > >>>>>>> suggested in his Gen-ART LC review to include an explanation = as to why > >>>>>>> we chose a YANG extension rather than a built-in statement. I = added a > >>>>>>> paragraph at the end of Introduction, please have a look, I = hope it's > >>>>>>> a fair account that shouldn't cause any controversy. > >>>>>>> > >>>>>> I think it is a feature to use extensions for new statements = that do > >>>>>> not have to be in the core. Modularity is a good thing, the = YANG > >>>>>> 1.1. specification is already 200 papges. When adding new = statements, > >>>>>> we should rather ask the question 'can this not also be done = using > >>>>>> extensions'? > >>>>> I am not convinced about that. If we have a host of "standard" > >>>>> extensions (annotation, complex-type and co., mount-point, > >>>>> mount-module, you name them), every module author then may = choose a > >>>>> subset of extensions for use in the module > >> Sure. The author will use the subset of core statement + = extensions > >> that is needed. If the module doesn't need meta-data, it won't be > >> used regardless of if it's a core statement or an extension. > >> > >>>>> and then the value of YANG > >>>>> as a standard data modelling language would be gone. > >>>>> > >>>> There will be a natural filter; things that are widely used will = be > >>>> widely supported, things that are not widely supported will not = be > >>>> widely used. We have the same with protocols and protocol = extensions, > >>> Asymptotically, yes. But the modules developed in the meantime = will be > >>> a mess. > >> I disagree. I agree w/ Juergen that defining extensions when it is > >> possible is a feature. > > I actually also agree with Juergen and Martin. > > > > I see that the one of the advantages of using extensions is that it = allows them to evolve independently and more quickly than the base = draft. And I would think that it is easier to deprecate an old = extension if it was superseded by a better approach. >=20 > This would all be fine as long as modules developed with such = extensions stay experimental, too. >=20 >=20 >=20 > I think standard extensions can be in standard YANG modules. > My problem with extensions is that they become mandatory-to-implement > if the module is advertised. I don't agree - this doesn't happen automatically. There must be some = extra mechanism for an extension to become mandatory to implement, e.g. = a special protocol, or a negotiated capability in an existing protocol. For example, if my RESTCONF implementation uses future modules that = happen to contain the "mount-point" extension, I don't want = structural-mount to become mandatory to implement. >=20 > IMO, YANG 1.1 MUST require that if-feature-stmt can appear within an = external statement. > There is currently no way to create an optional extension. >=20 > We have also received customer requests to allow the if-feature-stmt = inside > the deviation-stmt, which would be a really useful addition to YANG = 1.1. IMO it is way too late to consider such new features for inclusion in = YANG 1.1. Lada >=20 > =20 >=20 > Lada >=20 > > > > Rob >=20 >=20 > Andy > =20 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=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: E74E8C0C From nobody Fri Mar 11 01:32:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DBB12D5D6; Fri, 11 Mar 2016 01:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 KStG_X0HoBrZ; Fri, 11 Mar 2016 01:32:12 -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 1DA7712D5DF; Fri, 11 Mar 2016 01:32:09 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 19A4D180AFC; Fri, 11 Mar 2016 10:32:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457688727; bh=fg1Fc15BAdCchSyMkb+m5xLmNtZ8Lu9Q6AtduvYLD0o=; h=From:Date:To; b=R/GHkOQ7sYOeVS+wQaIi6xLKjwgBZzj3sjDO8iRrj04E79QyY2MnLq+Cs9KOHiYx+ +QUNbnBYrj7Bf0lliaYt3GAAE4MWFMYx5knJLwXGP9hHhiHQ84GG3dJ4Woo4E3pJ0C ZUF0uO1Dgxmm4NopIIRWJZOfPwBxYxVbfzI63YNY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56E209E3.4030805@nostrum.com> Date: Fri, 11 Mar 2016 10:32:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <415C6558-F5D2-4575-B380-C082171DFA21@nic.cz> References: <56D60EF5.7020001@nostrum.com> <56E209E3.4030805@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: General Area Review Team , "ietf@ietf.org" , netmod@ietf.org, draft-ietf-netmod-yang-metadata.all@ietf.org Subject: Re: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04 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, 11 Mar 2016 09:32:14 -0000 > On 11 Mar 2016, at 00:57, Robert Sparks wrote: >=20 >=20 >=20 > On 3/9/16 11:04 AM, Ladislav Lhotka wrote: >> Hi Robert, >>=20 >> thanks for the review, I apologize for replying late, please see my = responses inline: >>=20 >> Robert Sparks writes: >>=20 >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>>=20 >>> For more information, please see the FAQ at >>>=20 >>> . >>>=20 >>> Document: draft-ietf-netmod-yang-metadata-04 >>> Reviewer: Robert Sparks >>> Review Date: 1Mar2016 >>> IETF LC End Date: 9Mar2016 >>> IESG Telechat date: not yet scheduled >>>=20 >>> Summary: Ready with nits >>>=20 >>> 1) I might be missing something obvious, but the introduction has = two >>> statements that don't seem aligned: >>>=20 >>> " Values of annotations are not limited to strings; any YANG = built-in or >>> derived type may be used for them" >>> and >>> "annotations are scalar values and cannot be further structured". >> These two statements are not in conflict: YANG data types (built-in = or >> derived) apply to scalar values. > I don't know what it means for a data type to apply to a value. Can = you say that more simply? Every leaf node definition must define the leaf's type - built-in or = derived. Annotations can use exactly the same types. YANG types are = analogical to what "datatype" means in W3C XML Schema or RELAX NG - it = represents constraints for a *scalar* value (or text in XML terms). I = think you are confusing categories of YANG data nodes (leaf, container, = list, leaf-list, anyxml, anydata) with types (string, boolean, int8, = etc.). >=20 > I think this is just a language thing, and being precise in the text = will get past it. The Terminology section now refers to definitions of "built-in type" and = "derived type" in draft-ietf-netmod-rfc6020bis, and the latter document = is a normative reference. So understanding these terms is a prerequisite = for the present document. In my view, the formulations are quite = precise, but I am open to suggestions for improvements. >=20 > Are you saying all YANG data types (built-in or derived) have only = scalar values? No, data types represent constraints on scalar values. >=20 > If so, you could change the second point in the document to say > "Since annotations have only built-in or derived types, they can only = have scalar values." >=20 > But then, placing the point under "This document deliberately adopts = some restrictions" doesn't make sense, and I suggest restructuring the = discussion to only call out the restrictions (which appears to be to not = place annotations on lists or leaf-lists) below that sentence. The logic is this: it would be trivial to extend the mechanism of this = document to allow for annotations being arbitrarily complex data trees = with containers, lists, etc. It is also not difficult to imagine use = cases where it would come handy. However, the WG consensus was that at = his time we don't want to give up the convenience of XML attributes in = the XML encoding, and that's why we adopted extra restrictions that = mirror the restrictions of XML attributes. I believe the text in the = Introduction captures this quite well: In the XML encoding, XML attributes are a natural instrument for attaching annotations to data node instances. This document deliberately adopts some restrictions in order to remain compatible with the XML encoding of YANG data node instances and limitations of XML attributes. Specifically, o annotations are scalar values and cannot be further structured; o annotations cannot be attached to a whole list or leaf-list instance, only to individual list or leaf-list entries. If it turns out that structured annotations are needed, another document = (or an update to this one) can introduce them, including appropriate XML = encoding rules. Thanks, Lada >=20 >=20 >>=20 >>> If I'm not missing something, that may be more of an open issue than = a nit. >>>=20 >>> 2) The shepherd writeup calls out the tension in figuring out = whether to >>> make this an extension or a new built-in statement. Please consider >>> capturing the reasoning for the path you chose in the draft itself. >> I will try, the main reason was that most people felt that = introducing a >> new built-in statement is too big a change for the upcoming = maintenance >> version of YANG (1.1) and YANG 2.0 is nowhere in sight. >>=20 >> Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 11 02:14:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FE012D617 for ; Fri, 11 Mar 2016 02:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.94 X-Spam-Level: X-Spam-Status: No, score=-3.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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 u0H46n7l4Teg for ; Fri, 11 Mar 2016 02:14:28 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [IPv6:2001:1900:3001:11::28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8700112D60F for ; Fri, 11 Mar 2016 02:14:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C8D8C1E5D5C; Fri, 11 Mar 2016 02:14:09 -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 shLrb3GR2Tsy; Fri, 11 Mar 2016 02:14:09 -0800 (PST) Received: from [192.168.1.100] (host5-81-222-249.range5-81.btcentralplus.com [5.81.222.249]) by c8a.amsl.com (Postfix) with ESMTPSA id 418171E5D59; Fri, 11 Mar 2016 02:14:09 -0800 (PST) From: William Lupton Content-Type: multipart/alternative; boundary="Apple-Mail=_C27DD9E6-250A-4AD2-8507-C9E2A5ADA59C" Date: Fri, 11 Mar 2016 10:14:26 +0000 To: netmod@ietf.org Message-Id: <0FDD7C94-51C2-411A-82BB-B08E45812129@broadband-forum.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [netmod] Broadband Forum questions about announcing capabilities 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, 11 Mar 2016 10:14:31 -0000 --Apple-Mail=_C27DD9E6-250A-4AD2-8507-C9E2A5ADA59C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, BBF has a question about how to announce capabilities. This is = illustrated by a specific example but it=E2=80=99s a general question. = There is some overlap with past =E2=80=9CBroadband Forum questions on = RFC 6087bis = = =E2=80=9D and =E2=80=9CRestricting interface name maximum length and = character set = = =E2=80=9D threads. Here=E2=80=99s the example. We have a list of profiles and we want the = server to be able to indicate the maximum number of supported profiles. = The two ways that we have considered doing this are: Add a leaf that indicates the maximum number of supported profiles. Use a deviation to indicate max-elements on the profile list. We have got the impression from the RFCs and past discussion (cited = above) that NETMOD=E2=80=99s preferred approach is the first one, and = you would not approve of the second one. Is that correct? Any other = thoughts? Note that use of deviations in this way is not contravening RFC = 6020bis=E2=80=99s =E2=80=9Cdeviations MUST never be part of a published = standard=E2=80=9D because our published YANG will not include = deviations. We would be using them only in the sense that they would be = the recommended way for an implementation to announce its capabilities. = Strictly (in the example given above) this is a deviation from the = standard because an unspecified max-elements statement defaults to = =E2=80=9Cunbounded=E2=80=9D. Thanks, William Lupton= --Apple-Mail=_C27DD9E6-250A-4AD2-8507-C9E2A5ADA59C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All,

BBF = has a question about how to announce capabilities. This is illustrated = by a specific example but it=E2=80=99s a general question. There is some = overlap with past =E2=80=9CBroadband Forum questions on RFC 6087bis=E2=80=9D = and =E2=80=9CRestricting interface name maximum length and = character set=E2=80=9D threads.

Here=E2=80=99s the example. We have a = list of profiles and we want the server to be able to indicate the = maximum number of supported profiles. The two ways that we have = considered doing this are:
  1. Add a leaf that indicates the = maximum number of supported profiles.
  2. Use a deviation = to indicate max-elements on the profile list.
We have got the impression from = the RFCs and past discussion (cited above) that NETMOD=E2=80=99s = preferred approach is the first one, and you would not approve of the = second one. Is that correct? Any other thoughts?

Note that use of deviations in this way = is not contravening RFC 6020bis=E2=80=99s =E2=80=9Cdeviations MUST never = be part of a published standard=E2=80=9D because our published YANG will = not include deviations. We would be using them only in the sense that = they would be the recommended way for an implementation to announce its = capabilities. Strictly (in the example given above) this is a deviation = from the standard because an unspecified max-elements statement defaults = to =E2=80=9Cunbounded=E2=80=9D.

Thanks,
William = Lupton
= --Apple-Mail=_C27DD9E6-250A-4AD2-8507-C9E2A5ADA59C-- From nobody Fri Mar 11 02:17:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C539612D62D for ; Fri, 11 Mar 2016 02:17:52 -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 AG48msCfGIwR for ; Fri, 11 Mar 2016 02:17:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7D612D62B for ; Fri, 11 Mar 2016 02:17:51 -0800 (PST) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 5251F1AE0144; Fri, 11 Mar 2016 11:17:49 +0100 (CET) Date: Fri, 11 Mar 2016 11:17:49 +0100 (CET) Message-Id: <20160311.111749.461139040057688947.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> References: <30334F54-3461-44B2-B19E-0C512ADFD802@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-next 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, 11 Mar 2016 10:17:53 -0000 SGksDQoNCktlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+IEFs bCwNCj4gDQo+IEkgc2VlIHRvbyBtYW55IGVtYWlscyBnbyBieSB3aGVyZSBzb21lb25lIGhhcyBh biBpZGVhIHRoYXQgdGhleeKAmWQgbGlrZQ0KPiB0byBnZXQgaW50byBhIGZ1dHVyZSB2ZXJzaW9u IG9mIFlBTkcsIGFuZCBrZWVwIHdpc2hpbmcgdGhhdCB0aGVyZSB3ZXJlDQo+IGFuIGVhc3kgd2F5 IHRvIGNhcHR1cmUgdGhlc2UgZmVhdHVyZSByZXF1ZXN0cy4gIFdpdGggdGhhdCBpbiBtaW5kIEkN Cj4gY3JlYXRlZCBhIG5ldyBHaXRodWIgcmVwb3NpdG9yeSBjYWxsZWQgInlhbmctbmV4dOKAnS4g IFRoaXMgcmVwb3NpdG9yeQ0KPiBpcyBub3QgZm9yIGEgZHJhZnQsIHlldCwgaXRzIGN1cnJlbnQg ZXhpc3RlbmNlIGlzIHNvbGVseSB0byBoYXZlIGENCj4gcHVibGljbHkgZWRpdGFibGUgaXNzdWUg dHJhY2tlci4gIFBsZWFzZSBmZWVsIGZyZWUgdG8gYWRkIGFsbCB5b3VyDQo+IGdvb2QgaWRlYXMg KGp1c3Qgb25lIGlkZWEgcGVyIGlzc3VlIHBsZWFzZSkgaGVyZToNCj4gaHR0cHM6Ly9naXRodWIu Y29tL25ldG1vZC13Zy95YW5nLW5leHQvaXNzdWVzLg0KDQpJIHRoaW5rIGl0IGlzIGEgZ29vZCBp ZGVhIHRvIGNhcHR1cmUgaWRlYXMgbGlrZSB0aGlzLCBidXQgSSBhbHNvIHRoaW5rDQp0aGF0IHN1 Y2ggaWRlYXMgc2hvdWxkIGJlIGRpc2N1c3NlZCBvbiB0aGUgTUwuICBCdXQgbWF5YmUgdGhhdCdz IHdoYXQNCnlvdSBtZWFudC4NCg0KDQovbWFydGluDQo= From nobody Fri Mar 11 02:43:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B045E12E0D4 for ; Fri, 11 Mar 2016 02:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 tX-qoq6hi-wT for ; Fri, 11 Mar 2016 02:43:11 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A606F12E0BC for ; Fri, 11 Mar 2016 02:43:09 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 600B76718388F; Fri, 11 Mar 2016 10:43:05 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2BAh6kQ025082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2016 10:43:07 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2BAgvPo024605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Mar 2016 11:43:04 +0100 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.252]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 11 Mar 2016 11:43:00 +0100 From: "Bogaert, Bart (Nokia - BE)" To: EXT William Lupton , "netmod@ietf.org" Thread-Topic: [netmod] Broadband Forum questions about announcing capabilities Thread-Index: AQHRe37SS7szXfiy5E6cmMrIIVrQGZ9UDS8w Date: Fri, 11 Mar 2016 10:43:00 +0000 Message-ID: References: <0FDD7C94-51C2-411A-82BB-B08E45812129@broadband-forum.org> In-Reply-To: <0FDD7C94-51C2-411A-82BB-B08E45812129@broadband-forum.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0416_01D17B8B.28BD72F0" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Broadband Forum questions about announcing capabilities 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, 11 Mar 2016 10:43:14 -0000 ------=_NextPart_000_0416_01D17B8B.28BD72F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0417_01D17B8B.28BD72F0" ------=_NextPart_001_0417_01D17B8B.28BD72F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 It is my understanding that =E2=80=9Cnarrowing=E2=80=9D the = possibilities (e.g. range) of a leaf is acceptable and even the Best = Practices document RFC6087bis-05 suggests this in section 5.19. So why = would this approach not be approved? These limitations could be the = result of e.g. memory constraints of the box and one might want to = expose this to the client accepting configurations changes in case the = target device would temporarily not be available (some kind of = pre-provisioning by the NETCONF client running on a network management = platform). =20 Best regards - Vriendelijke groeten, Bart Bogaert System Architect Data-Centric SW Architectures=20 Fixed Networks - Broadband Access BU, Nokia Contact number +32 3 2408310 (+32 477 673952) =20 From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of EXT William = Lupton Sent: 11 March 2016 11:14 To: netmod@ietf.org Subject: [netmod] Broadband Forum questions about announcing = capabilities =20 All, =20 BBF has a question about how to announce capabilities. This is = illustrated by a specific example but it=E2=80=99s a general question. = There is some overlap with past =E2=80=9CBroadband Forum questions on = RFC 6087bis = =E2=80=9D and =E2=80=9CRestricting interface name maximum length and = character set = =E2=80=9D threads. =20 Here=E2=80=99s the example. We have a list of profiles and we want the = server to be able to indicate the maximum number of supported profiles. = The two ways that we have considered doing this are: 1. Add a leaf that indicates the maximum number of supported profiles. 2. Use a deviation to indicate max-elements on the profile list. =20 We have got the impression from the RFCs and past discussion (cited = above) that NETMOD=E2=80=99s preferred approach is the first one, and = you would not approve of the second one. Is that correct? Any other = thoughts? =20 Note that use of deviations in this way is not contravening RFC = 6020bis=E2=80=99s =E2=80=9Cdeviations MUST never be part of a published = standard=E2=80=9D because our published YANG will not include = deviations. We would be using them only in the sense that they would be = the recommended way for an implementation to announce its capabilities. = Strictly (in the example given above) this is a deviation from the = standard because an unspecified max-elements statement defaults to = =E2=80=9Cunbounded=E2=80=9D. =20 Thanks, William Lupton ------=_NextPart_001_0417_01D17B8B.28BD72F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

It is my understanding that =E2=80=9Cnarrowing=E2=80=9D the = possibilities (e.g. range) of a leaf is acceptable and even the Best = Practices document RFC6087bis-05 suggests this in section 5.19.=C2=A0 So = why would this approach not be approved? These limitations could be the = result of e.g. memory constraints of the box and one might want to = expose this to the client accepting configurations changes in case the = target device would temporarily not be available (some kind of = pre-provisioning by the NETCONF client running on a network management = platform).

 

Best regards - Vriendelijke groeten,

Bart Bogaert

System Architect Data-Centric SW Architectures

Fixed Networks - Broadband Access BU,=C2=A0 = Nokia

Contact number +32 3 2408310 (+32 477 = 673952)

 

From:= = netmod [mailto:netmod-bounces@ietf.org] On Behalf Of EXT William = Lupton
Sent: 11 March 2016 11:14
To: = netmod@ietf.org
Subject: [netmod] Broadband Forum questions = about announcing capabilities

 

All,

 

BBF has a question about how to announce capabilities. = This is illustrated by a specific example but it=E2=80=99s a general = question. There is some overlap with past =E2=80=9CBroadband Forum questions on RFC 6087bis=E2=80=9D and = =E2=80=9CRestricting interface name maximum length and character = set=E2=80=9D threads.

 

Here=E2=80=99s the example. We have a list of profiles = and we want the server to be able to indicate the maximum number of = supported profiles. The two ways that we have considered doing this = are:

  1. Add a leaf that indicates the maximum number of supported = profiles.
  2. Use a deviation to indicate max-elements on the profile = list.

 

We have got the impression from the RFCs and past = discussion (cited above) that NETMOD=E2=80=99s preferred approach is the = first one, and you would not approve of the second one. Is that correct? = Any other thoughts?

 

Note that use of deviations in this way is not = contravening RFC 6020bis=E2=80=99s =E2=80=9Cdeviations MUST never be = part of a published standard=E2=80=9D because our published YANG will = not include deviations. We would be using them only in the sense that = they would be the recommended way for an implementation to announce its = capabilities. Strictly (in the example given above) this is a deviation = from the standard because an unspecified max-elements statement defaults = to =E2=80=9Cunbounded=E2=80=9D.

 

Thanks,

William Lupton

------=_NextPart_001_0417_01D17B8B.28BD72F0-- ------=_NextPart_000_0416_01D17B8B.28BD72F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzExMTA0MjU4WjAjBgkqhkiG9w0B CQQxFgQUpSRbA3fWcYtC8MPiDeCnjD9RRhIwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQBg Y6fp31V9Lbr/az/spvXh+gUnIZy8YbA9aE1okCiy2DdcJC1iddVWYEQEo2cEB9wya2DxTKJKiGQI xOxHUYRrEmGyYpsNi03R2MhP7qWdgP5BZfTY20MOIbrMz3wJWCZys796qwALO30usUpOnFTiU1GD AEWvFtexktgMUo7igXI/DrU7mjil95Er0dgG+ILU5Aew1v+JWf2tTTdl9Ue0eOIIeHuX/+hbeiE9 s4D8SPfD0R85Zg5195WPSXmp6LQDGABo2LOO4iP+nOE45Xb0RRmlF1irKR1MDosx/cQo33fxMCaa Vn4BQWWkwY58iwu33r9AB0OTUVbcQIWJsyA7AAAAAAAA ------=_NextPart_000_0416_01D17B8B.28BD72F0-- From nobody Fri Mar 11 04:32:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83D512D113 for ; Fri, 11 Mar 2016 04:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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] 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 hJRxBhUrhAGf for ; Fri, 11 Mar 2016 04:32:06 -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 B303D12D6B1 for ; Fri, 11 Mar 2016 04:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fsvRZOAYIXpsxHyXvjbVzaIRhOcdHWAhnRryrlA1DPA=; b=c/P/GybxnopYhaA4bqYlBYzdPieAR5eBkzioS6DBoQGMk+nMjShVkH9/4mfXaQLgtwZVryf/gd5ewnV7WxJXsxfhytaq9b8+lGxIQ/B7Tst/QVduI2fWO2crDETV8tdXNvCOY9Rm9uFX8gN04geC500fdjfZ8v84JihIr4tE2wg= 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.167.153.133) by DB5PR07MB1621.eurprd07.prod.outlook.com (10.166.12.148) with Microsoft SMTP Server (TLS) id 15.1.434.11; Fri, 11 Mar 2016 12:31:58 +0000 Message-ID: <033801d17b91$73c4b280$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , References: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> Date: Fri, 11 Mar 2016 12:10:09 +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.167.153.133] X-ClientProxiedBy: HE1PR08CA0002.eurprd08.prod.outlook.com (25.161.112.12) To DB5PR07MB1621.eurprd07.prod.outlook.com (25.166.12.148) X-MS-Office365-Filtering-Correlation-Id: b4d2095e-470f-4e5e-431c-08d349a9241e X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 2:IGQNJ1MEOr6uW12FbXyx8ZU0bsJ9Rl547QoRKhnErQAxiog8MNbFsET1nWhLoA6Xd943HvHoIZoFbAU+erggskB75wkk0Qs01HIsbGQ4q+9BnRT5hUMggw8jiyhBseIAbZNxixH08ylFP86UT91q4i2By6gJKIiurvdtuTRyXbNiz73uf1ui47u1jLz1eTU3; 3:3vWc/R8L0pHtpqAeRQW8xRf27XF+FmG3UUWP3U89Xn2g8qdr0KzCrcMimSJEpQ/lksRKtIS3XNN6e7pMcCCYc+yflpoM++d33KS24tCH25oUoi/9G0YojeMnUvXYZRFb; 25:nJjGo5AE+jGYjIFo7cVmbbQlkTNMC/rfGK95yhm6SFl62Cb3uszB9CSvbFfjmrfau4m/+ZYCKR9oHYCHTkDCaHKfieOCuaOaztLDus4MnHKfJnRgkJo/Sk3S64H3KzrIKiVNde8c5MzJwy7YWRuG/KGCSnB8JLlcFTQ4GkmnDtJEBwkWllzT8zrrxMV1N55pjkHk/YCVO0O0MqOk8ADUF405tjCXt33eAsmLdj44GlSniluFvuficxwAxTZHNEjV5MnGtlFhttpquHEVSX6TIfsWrg4dESluGwIMznTtfmZaMjWjzamoPBdpXedDGKPTeKYkTDPcX/m0q9iz1MDEd6TReeinTCrWnOeJIRlSziwnuaZzu5jumrOkylfhK67T X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1621; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB5PR07MB1621; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1621; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 4:QfS2KC9J3NfBSPD1MqyXaBWhNw0CFHyzZKUNel2bjx59kIJQt0iTGLThP0JGbFW882J5qF+faegIWEqZkMLh6cbbDjPpte9tNhuFZkaMhA3z5bJ4yDwu5lgIl+rGBjQLoBA1p+aCViD3DUyxwu60aK6O/FxpZfWMPMTOtsKa5LFg3iimL3+lADNSrgCIhLWzgsF9XkKsepcV7ziMAOSnW2Ce+fPvj9eU7O+5dslSQwa8FMk1uvQbybrEjtwA0iahD0/toO3DjNGEm5DF4XN03VduYYmb7rQ4C8Mb+2pL8xvC70MUXbdHuleoV5wQ0xd8RyiFdxR5vOMzzgRQLp7gi3i5l6pn0nPepcdbhmhKUHrI16IyXij2mv/om42jAoN2 X-Forefront-PRVS: 087894CD3C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(81816999)(1941001)(81166005)(81686999)(107886002)(84392002)(586003)(5001770100001)(6116002)(92566002)(229853001)(116806002)(3846002)(76176999)(77096005)(1456003)(5004730100002)(230700001)(50986999)(189998001)(1096002)(5008740100001)(44736004)(42186005)(66066001)(44716002)(14496001)(86362001)(50226001)(1556002)(61296003)(47776003)(50466002)(2906002)(23676002)(62236002)(33646002)(74416001)(7059030)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1621; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIxNjIxOzIzOjZhU3B4WS9KaWJIQnZGZHlLbjVJVXBPNGlD?= =?utf-8?B?ZjZpVUllZG5lZTdMeDN5UzF6dUNSc0pXTzFwVjB1WnVZazhHVUhxUVBLZmFm?= =?utf-8?B?aUlrSVhGN1V3dFA1TlU1ZkFEZUFWWEkwdlUzb3JEbklpVXNTZ3NlU080MjdJ?= =?utf-8?B?bFJuZ3VHYXRSU3dSWVJSRzljQ0pmL2ZZb3NSZVdnUFFEK0tIbnpwQWkySG8v?= =?utf-8?B?VXk2UlJmZ0ZRWE5sUWxueTJJMTRjNWJLdjY5MzNYNlpta3NRd0MvZ2xuM0sv?= =?utf-8?B?akZ0MEdwTXlxM2pqbTZYOVNlSndWQ2gzY2FCZlB1V2VsOFQ1ZEFWTGtRbE1u?= =?utf-8?B?QVZ0eXBKWE9ZcjBDTU1qa1h3cTdEWW1INkdUanBLbkdiK0xsejN6SlJKdzk0?= =?utf-8?B?SHZtRWNxYkFXY2RQWWxMTGxjcHFQVHdiRGp5QjF5aGs2clpIVDZNOUs3c0JK?= =?utf-8?B?eUlkM05GRTVYRldnUy8rS2F1TmhGUnRWQktkcmU4aWUvU1dyczNGb01idlFK?= =?utf-8?B?STJQVkVCbFZMRnZpczVYL25LSjlUa0Q0WU9MNVdWUmxORHRweDZiTG9KUkkr?= =?utf-8?B?cFNFa3YzRG5aTWxuZkJGOGt1QlhCZG0zcmtoUDdYRmJrUzA0VzZsOThMWnE3?= =?utf-8?B?cnFuWVdEUVlNaUhCbWloVFE1d1MrUU1QQlI0OGF1STQxb0dkbC96aXI2UTlj?= =?utf-8?B?cjZFSVlqR1ovOTM1dlFPWWVhUTVYLzVkYUNZUnVNVmpmbndydWFlWnd6NDcv?= =?utf-8?B?RWxyVmY2SlNDVHpob05IQmdnWTJ2SXVlWktTcjRpMTlsYno4RzJRUmw0Y1c1?= =?utf-8?B?WmxLWVhYTGcwbDh4V09vZEZIcFVrZUlpeGZKOW00dnM4angzQzNoVWIyRDJL?= =?utf-8?B?QkdFbUVXSWZvUS96WjFVWnFJUE5wbVFoM05BeUM5SzZGUGtYcWNGVHg3elNM?= =?utf-8?B?N0xSNG5nTUkrK21oMjFDV3RmUnEwZXAwbFV5bnlWam1KWDdwOW1JUGVpSXpi?= =?utf-8?B?dTNGVGQrTDdPL01VRjRnTGM5M2g2dy9UNld6QjVhM2x1bnVEWE0yOGlNbTIv?= =?utf-8?B?ekxSemprVVhuUTBKSmVVVUN4b1hRSkVQZHEyaUNCNDM3a0dVQkhpZmhwaGFz?= =?utf-8?B?OXJ4aDRYQ3A2MXBwWU40SnZMOHd0NEh5dytOQzlMbzg0L1ZkQ1l2d09YWTly?= =?utf-8?B?bW1rWExnWEtqVjk4K252T2RCQzBoelR0MXpZbTJHNmlwSi9FVjdiMVJaZnFZ?= =?utf-8?B?N2FoTVhyZkk5VWFRSWdWOFJobzlrMFB0Ti83TUVJeExYRmozOVdldjVtVHE4?= =?utf-8?B?NHREZ212V20yWXFjK01kYklEbW1PeGVYR3kxbjk4L3lCdlZJR0pBcU9wQnIv?= =?utf-8?B?QWNCTkdUSlhOeG1KdUVZb0YvK2Vmb3hPYThPdHRpM1IrU1BQU2Q5MFpqTGt1?= =?utf-8?B?YWw1cEVSUFREU0RhWWJKbzVvV0Evd3JGRm5uK1AzZjVneHM3Y2JtM1VhbGdP?= =?utf-8?Q?GGAmO4NCZ/wB9a+VYuZVfcqCo=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 5:1r0PbEXYOOKEIW4+412MB6c3LA22Ux1+f2GZVHddJBjIOc7jWjwkKTFbg99O4EPBsncJr8IP4WWWSdMgmuyEcGQfS+nKuE2bOpPA3pviCv3BuxOEhe8mA62p7D67zI40fKSoWyohex/qDVjFqPXNhg==; 24:fXqgGqCaYF0GKmVkegfrrLRPMTxG+xox2WEXEIUf1lnFH8lWD2Q4rVdMvQPqm9yzJH+Aa5yTGX+SofWASP2xQ72S7y2/sPAFEgo0TtJkE70= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2016 12:31:58.9416 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1621 Archived-At: Subject: [netmod] features - a Cartesian explosion 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, 11 Mar 2016 12:32:08 -0000 One of my comments on syslog was that it had 10 features. Assuming that each can be present or absent, that would seem to allow over 1000 different possible implementations, almost all of which will likely never be seen in the field. And yet, if there are 1000 possible implementations, does not that mean having to code 1000 different paths, having to test 1000 different possibilities, never having two interworking boxes unless they are the same model with the same software level from the same manufacturer? It is so easy to add 'feature' to a YANG model; is some restraint called for? Tom Petch From nobody Fri Mar 11 04:57:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A1F12D6C5; Fri, 11 Mar 2016 04:32:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 gV22NwyprU6d; Fri, 11 Mar 2016 04:32:19 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BACD912E0DB; Fri, 11 Mar 2016 04:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HH5lxafEFep6wkUzMcO15vvS+g9Hq6dLaft9Em8Z5bk=; b=M0uEeaECrDi09I9eE8JSBfKTY7qzSv7lM3oBvlPxmIPiPMl720wFUsVprZ4CJYmGvdaHTD+WwhlmSc2LB8GDjO/oLArAcQptZfu+GHLlNxT+d9e+y+6L8ZPPUbtkmVawaCgIMSV0iiWluDsSjGKTrPI75R5uwXJRO/E10huD5qQ= 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.167.153.133) by HE1PR07MB1561.eurprd07.prod.outlook.com (10.169.123.11) with Microsoft SMTP Server (TLS) id 15.1.434.11; Fri, 11 Mar 2016 12:31:53 +0000 Message-ID: <033701d17b91$710ce580$4001a8c0@gateway.2wire.net> From: tom p. To: Ladislav Lhotka , Robert Sparks References: <56D60EF5.7020001@nostrum.com> <56E209E3.4030805@nostrum.com> <415C6558-F5D2-4575-B380-C082171DFA21@nic.cz> Date: Fri, 11 Mar 2016 11:15:28 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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.167.153.133] X-ClientProxiedBy: HE1PR08CA0005.eurprd08.prod.outlook.com (25.161.112.15) To HE1PR07MB1561.eurprd07.prod.outlook.com (25.169.123.11) X-MS-Office365-Filtering-Correlation-Id: d436bc26-31fb-4ad0-9d06-08d349a92137 X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1561; 2:jE+lB+EHSsn6wppuwvz1ZrmI2IyTIwD9VcUn1xbMF57YY05wCHhFFZbMOYI1D12bqY2BMHmJBv4iLKVI3fgnUKt9G1v3R8qOS1V/I2Sa64c7JEf0j4Dw9DxuB2/5rLik4uh4gicB+EftMxKE8AKFo7S842p2I0+ia/HV46rG3fNAqJ7/SuJzBeUY8y4R3XzO; 3:KgaHcq8eRvF/k0ofjmmZLiNmJ8yK6/EWViS3PVCPvuYGbczTCxmoRXxv3+Y/Z6Gb3saPNPgOu2GIgPVRExyvBw+wcg0yqmOzYh48Q1sxVrIJFqvfVGTOeRxQ0tgRMdPl; 25:HahNV9DuRNRgB4/jp8Pju13C6tJHOcGIrh8vS7AcbHagQLy+/w0+d/CNYtEeVsNvzXEwIH4jo6OMRt/BKbAMUJJ0RJQVXULrBhtPxKv6GGEjdYDCOS2pDEK9d76adPIP+Vmjq443X8YZ28BhLaL+34pLcHIZoX9my3bqOBsRxqu/HsQ8xHhJDB7FdwIwxXQxfxuAefJHWNj1C3eraSe9ecZ5m7VzysK9duReWkg21TdO+lLd2bniaREyV1bjm410HaML8RZ1msmvP0mS+TVvltxQC4ZUXmx4Sgzbo0Zm162EPb8sDg+5EhstS37PhexeRZwqFBVml91AsQwrRY5Qcg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1561; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:HE1PR07MB1561; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1561; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1561; 4:nCLFtX8K/EkCvkIww4u+2N5W2Vv2eXB45OqBtF5MAC/QJ4qb4ywiHIaeR44+Sj1w2lG0fCqOvwUwbvCStqKxh4PAEviDvVA+e2jGP93Dg9Vd5rR/Vg+PUbVV4BzBcAwehHXTEFCL573MiiiQw8me+oTIVspr9d1ZUzO0VjuuHXgawXWFx/fPjPTiwEauFf69+cmC1mI0egkvQo8jTMrKTlxffFLhxJUSQ/c6QBya5sDqk7mw+DNv8jfeMsD5BUzJGTkMzMQ3pFJpx7DlpjvNfsIP9Cs47azLKaY/H2j1qUZrchyHXj56e1bnOdeRvpZKHlx7BmXgxriA/tDXzYG2POvgod8SJiOBsV2KdsolVoSH3c/JtAfHItz2OoP2I3tC X-Forefront-PRVS: 087894CD3C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(164054003)(24454002)(377454003)(479174004)(13464003)(81686999)(15975445007)(77096005)(42186005)(189998001)(586003)(66066001)(1096002)(5004730100002)(2906002)(3846002)(23746002)(575784001)(4326007)(5008740100001)(6116002)(50466002)(86362001)(1556002)(61296003)(47776003)(230700001)(14496001)(44736004)(50226001)(93886004)(44716002)(92566002)(62236002)(81816999)(5890100001)(19580395003)(5001770100001)(19580405001)(116806002)(81166005)(76176999)(33646002)(230783001)(50986999)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1561; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; HE1PR07MB1561; 23:7zGHsetyQNfOau+TXQ9Kki0rmMs+32VAmEWeo?= =?Windows-1252?Q?ejh9R9O2UstfI0fCB53RfZAn+Ovy+owo8iYd67tm8YGyJ25tCdk1kR4l?= =?Windows-1252?Q?lqMFSMOMRcn7uZ824o28ErBY6+6P9aG751idY3wS5XP5jRimf3Ctpm/4?= =?Windows-1252?Q?5aWTTRU6eR3ApwGn2+51QF5ebXsFbNqnxxT8mm/Y0hifbTR3+IyMmTK8?= =?Windows-1252?Q?r4lcuzuPJSCgs2LeIP7IVkUWSL1TYyaWEA6VhGXW4dxOEcPz5jg+GySY?= =?Windows-1252?Q?Q5ctbHunI7h2Jp+6HUc/b9oUbFqIUKDWeKPqKUAUORT/YdkN7zGB6w0H?= =?Windows-1252?Q?ST7cJbIVNG8oefQi2/VT3++qxK1waCKMv6P3WR9MCPNXIZGaEuMEMNHS?= =?Windows-1252?Q?Y9ATIF09A+uogDafmYryrOquZ8I4rSIUZjQA94ELkZ7vnTSltefViWxE?= =?Windows-1252?Q?+51CNs6wViO7ViLm7zkTms2OSSAMdLjhzLI6d93w2/hIfVK+Q9NQfSVo?= =?Windows-1252?Q?Z2Q/2lIM24QKWW+ZGAOrmOcdTc+c9U2dWMfyf/RwQ34AmiMDyOU12/zy?= =?Windows-1252?Q?WOtpVu5me9t7D6s7UXHAzv0DcPXBvH9FrwEb/gG/de5yg+20KBOHHTN7?= =?Windows-1252?Q?+Ziyk7yvKvW+3IDCg3aSRL7KcC8f89pbNQGnMGvyFg+1LEV04kAFfMUF?= =?Windows-1252?Q?Z3zzmpegNuy12+tGW/nNb7ckMJve1SAODvmpgbKHRNYAi385Dj6769Vz?= =?Windows-1252?Q?PQrh7TjV2PTfmdrBpbWuToNYI0j3yz4BnmezJ46Lx6R6B9MFwLVEW81T?= =?Windows-1252?Q?eWShHZ9nxHJ1ArhdpqmACgc1xpx3/7niwJtmesHpWEue93WB3J1a49hO?= =?Windows-1252?Q?vbC12qD/4+qw3FLuWfSOWutzMeUhX2neATYRXYSISKeCTRkHgyaKM+J4?= =?Windows-1252?Q?qpjpVwd9eXaXF3JaP3w/wZhbm9FVdHg9qSyJJn/d+8+r8IcX4KS5RIFF?= =?Windows-1252?Q?gwY+a9QfPSlgVosjK7dSmcxQ4LfQQm+TbtIXaOzAVmxQkf/vYJkvqS2z?= =?Windows-1252?Q?pGQdeZFVYy0l0Cl9pWm5aEVRN22cuPYQFDJee1LTIXr2QNa7v3pFn5dr?= =?Windows-1252?Q?Sh2pKp08VTbVl47e4kPG3yQ3qlEyWKWSa/msUd2UJDeuFt91UudM70H7?= =?Windows-1252?Q?NbRbuHnIXHMbsOy+Yl7ycQFTVV0OaVJODAqBX5jMYp2U/NhqiNp8TUrf?= =?Windows-1252?Q?ajvAhrz5K/9JPSrV11qP8S+X93SwHgosnDi1FWviK3RNKUO6PGFUzhTJ?= =?Windows-1252?Q?kcLbxnNQCZA3HLvGv7PQJ7rn+umFSaghIaqkkiZOXCHCJkvSRSvKgtbG?= =?Windows-1252?Q?GUvjMTvwHNVFNDCZI3MSyWD21GiLwEy1A=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1561; 5:GI07H4LzMpEfCClY4x3IDKksI5aaYsvqx/WRJ/E5Q4Twtm3TBFXsrRgg8IxMsR6vAqJ0ue6WgbjzQSBhGERfNL2nyw9A9eXLgg0dqXAW+tz+m9dQRfSnIkdu822J3MCaPGN2H+VoKRD5N4SMtTSkAg==; 24:yovKe7FjUtBroaNM3HXS9qi8kB9ukmSqiETSZ77HdVXrW55VaNQOl4S3luP1QSn4ATpgonD2bkrpk5mozY/4sA0wgzT7v3p0TEenKhv5coU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2016 12:31:53.9965 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1561 Archived-At: X-Mailman-Approved-At: Fri, 11 Mar 2016 04:57:25 -0800 Cc: General Area Review Team , ietf@ietf.org, netmod@ietf.org, draft-ietf-netmod-yang-metadata.all@ietf.org Subject: Re: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04 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, 11 Mar 2016 12:32:21 -0000 Lada, Robert The other angle from which this might be approached is that the I-D already says " Using the "type" statement, a type is specified for the annotation value according to the same rules as for YANG "leaf" type. " while rfc6020bis says " The "leaf" statement is used to define a scalar variable of a particular built-in or derived type." so if you know your YANG off by heart, then you will know that annotations must be scalar. I agree that the text needs to be clearer. Perhaps, OLD " o annotations are scalar values and cannot be further structured;" NEW "Annotations obey the same rules as for a YANG "leaf" type [rfc6020bis s.7.6] and so are limited to scalar variables." Tom Petch ----- Original Message ----- From: "Ladislav Lhotka" To: "Robert Sparks" Cc: "General Area Review Team" ; ; ; Sent: Friday, March 11, 2016 9:32 AM > On 11 Mar 2016, at 00:57, Robert Sparks wrote: > > > > On 3/9/16 11:04 AM, Ladislav Lhotka wrote: >> Hi Robert, >> >> thanks for the review, I apologize for replying late, please see my responses inline: >> >> Robert Sparks writes: >> >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>> >>> For more information, please see the FAQ at >>> >>> . >>> >>> Document: draft-ietf-netmod-yang-metadata-04 >>> Reviewer: Robert Sparks >>> Review Date: 1Mar2016 >>> IETF LC End Date: 9Mar2016 >>> IESG Telechat date: not yet scheduled >>> >>> Summary: Ready with nits >>> >>> 1) I might be missing something obvious, but the introduction has two >>> statements that don't seem aligned: >>> >>> " Values of annotations are not limited to strings; any YANG built-in or >>> derived type may be used for them" >>> and >>> "annotations are scalar values and cannot be further structured". >> These two statements are not in conflict: YANG data types (built-in or >> derived) apply to scalar values. > I don't know what it means for a data type to apply to a value. Can you say that more simply? Every leaf node definition must define the leaf's type - built-in or derived. Annotations can use exactly the same types. YANG types are analogical to what "datatype" means in W3C XML Schema or RELAX NG - it represents constraints for a *scalar* value (or text in XML terms). I think you are confusing categories of YANG data nodes (leaf, container, list, leaf-list, anyxml, anydata) with types (string, boolean, int8, etc.). > > I think this is just a language thing, and being precise in the text will get past it. The Terminology section now refers to definitions of "built-in type" and "derived type" in draft-ietf-netmod-rfc6020bis, and the latter document is a normative reference. So understanding these terms is a prerequisite for the present document. In my view, the formulations are quite precise, but I am open to suggestions for improvements. > > Are you saying all YANG data types (built-in or derived) have only scalar values? No, data types represent constraints on scalar values. > > If so, you could change the second point in the document to say > "Since annotations have only built-in or derived types, they can only have scalar values." > > But then, placing the point under "This document deliberately adopts some restrictions" doesn't make sense, and I suggest restructuring the discussion to only call out the restrictions (which appears to be to not place annotations on lists or leaf-lists) below that sentence. The logic is this: it would be trivial to extend the mechanism of this document to allow for annotations being arbitrarily complex data trees with containers, lists, etc. It is also not difficult to imagine use cases where it would come handy. However, the WG consensus was that at his time we don't want to give up the convenience of XML attributes in the XML encoding, and that's why we adopted extra restrictions that mirror the restrictions of XML attributes. I believe the text in the Introduction captures this quite well: In the XML encoding, XML attributes are a natural instrument for attaching annotations to data node instances. This document deliberately adopts some restrictions in order to remain compatible with the XML encoding of YANG data node instances and limitations of XML attributes. Specifically, o annotations are scalar values and cannot be further structured; o annotations cannot be attached to a whole list or leaf-list instance, only to individual list or leaf-list entries. If it turns out that structured annotations are needed, another document (or an update to this one) can introduce them, including appropriate XML encoding rules. Thanks, Lada > > >> >>> If I'm not missing something, that may be more of an open issue than a nit. >>> >>> 2) The shepherd writeup calls out the tension in figuring out whether to >>> make this an extension or a new built-in statement. Please consider >>> capturing the reasoning for the path you chose in the draft itself. >> I will try, the main reason was that most people felt that introducing a >> new built-in statement is too big a change for the upcoming maintenance >> version of YANG (1.1) and YANG 2.0 is nowhere in sight. >> >> Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 11 04:58:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062F212D6CB; Fri, 11 Mar 2016 04:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 KPjS8CG-7q55; Fri, 11 Mar 2016 04:58:26 -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 75AF912D6C6; Fri, 11 Mar 2016 04:58:26 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:78b3:e555:d573:5b15] (unknown [IPv6:2001:718:1a02:1:78b3:e555:d573:5b15]) by mail.nic.cz (Postfix) with ESMTPSA id A4704181B37; Fri, 11 Mar 2016 13:58:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457701104; bh=i/zFx6awqT/lZnLatdRdXQZRg2OdECEY277GphGOpUw=; h=From:Date:To; b=Lfo47cHxkwSXnGT0EE4T3zNZbKFDZQ4BvQe7aV07gBORq232qesJ6RjoJleORIcJo ttl6yFDvYFMYYKjg9kUzUCj1dFaT54xsqCPh3G+3l8vj/64BDDzBVDwuGkYunwoVQN LBD0Vie8hiMVEPYtxBvTeR8GyzMpO+VLaqO12GTM= Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <033701d17b91$710ce580$4001a8c0@gateway.2wire.net> Date: Fri, 11 Mar 2016 13:58:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <52538EAC-7C3D-4EEF-8E78-F202FB68CB2A@nic.cz> References: <56D60EF5.7020001@nostrum.com> <56E209E3.4030805@nostrum.com> <415C6558-F5D2-4575-B380-C082171DFA21@nic.cz> <033701d17b91$710ce580$4001a8c0@gateway.2wire.net> To: "tom p." X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: General Area Review Team , draft-ietf-netmod-yang-metadata.all@ietf.org, ietf@ietf.org, netmod@ietf.org, Robert Sparks Subject: Re: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04 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, 11 Mar 2016 12:58:29 -0000 > On 11 Mar 2016, at 12:15, tom p. wrote: >=20 > Lada, Robert >=20 > The other angle from which this might be approached is that the I-D > already says >=20 > " Using the "type" statement, a type is specified for the annotation > value according to the same rules as for YANG "leaf" type. " >=20 > while rfc6020bis says >=20 > " The "leaf" statement is used to define a scalar variable of a > particular built-in or derived type." >=20 > so if you know your YANG off by heart, then you will know that > annotations must be scalar. I agree that the text needs to be = clearer. > Perhaps, > OLD > " o annotations are scalar values and cannot be further = structured;" > NEW > "Annotations obey the same rules as for a YANG "leaf" type [rfc6020bis This is again confusing, "leaf" is a data node, not type. But even then, = there are some things that may be defined for leafs but not for = annotations, such as a default value or "must" expression. As you rightly said, 6020(bis) is quite clear: types only pertain to = scalar values. I believe the problem is in carrying over the meaning = that "type" has in programming languages (array or struct type) to YANG. Lada=20 > s.7.6] and so are limited to scalar variables." >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "Robert Sparks" > Cc: "General Area Review Team" ; ; > ; > Sent: Friday, March 11, 2016 9:32 AM >=20 >> On 11 Mar 2016, at 00:57, Robert Sparks wrote: >>=20 >>=20 >>=20 >> On 3/9/16 11:04 AM, Ladislav Lhotka wrote: >>> Hi Robert, >>>=20 >>> thanks for the review, I apologize for replying late, please see my > responses inline: >>>=20 >>> Robert Sparks writes: >>>=20 >>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>> by the IESG for the IETF Chair. Please treat these comments just >>>> like any other last call comments. >>>>=20 >>>> For more information, please see the FAQ at >>>>=20 >>>> . >>>>=20 >>>> Document: draft-ietf-netmod-yang-metadata-04 >>>> Reviewer: Robert Sparks >>>> Review Date: 1Mar2016 >>>> IETF LC End Date: 9Mar2016 >>>> IESG Telechat date: not yet scheduled >>>>=20 >>>> Summary: Ready with nits >>>>=20 >>>> 1) I might be missing something obvious, but the introduction has > two >>>> statements that don't seem aligned: >>>>=20 >>>> " Values of annotations are not limited to strings; any YANG > built-in or >>>> derived type may be used for them" >>>> and >>>> "annotations are scalar values and cannot be further structured". >>> These two statements are not in conflict: YANG data types (built-in > or >>> derived) apply to scalar values. >> I don't know what it means for a data type to apply to a value. Can > you say that more simply? >=20 > Every leaf node definition must define the leaf's type - built-in or > derived. Annotations can use exactly the same types. YANG types are > analogical to what "datatype" means in W3C XML Schema or RELAX NG - it > represents constraints for a *scalar* value (or text in XML terms). I > think you are confusing categories of YANG data nodes (leaf, = container, > list, leaf-list, anyxml, anydata) with types (string, boolean, int8, > etc.). >=20 >>=20 >> I think this is just a language thing, and being precise in the text > will get past it. >=20 > The Terminology section now refers to definitions of "built-in type" = and > "derived type" in draft-ietf-netmod-rfc6020bis, and the latter = document > is a normative reference. So understanding these terms is a = prerequisite > for the present document. In my view, the formulations are quite > precise, but I am open to suggestions for improvements. >=20 >>=20 >> Are you saying all YANG data types (built-in or derived) have only > scalar values? >=20 > No, data types represent constraints on scalar values. >=20 >>=20 >> If so, you could change the second point in the document to say >> "Since annotations have only built-in or derived types, they can only > have scalar values." >>=20 >> But then, placing the point under "This document deliberately adopts > some restrictions" doesn't make sense, and I suggest restructuring the > discussion to only call out the restrictions (which appears to be to = not > place annotations on lists or leaf-lists) below that sentence. >=20 > The logic is this: it would be trivial to extend the mechanism of this > document to allow for annotations being arbitrarily complex data trees > with containers, lists, etc. It is also not difficult to imagine use > cases where it would come handy. However, the WG consensus was that at > his time we don't want to give up the convenience of XML attributes in > the XML encoding, and that's why we adopted extra restrictions that > mirror the restrictions of XML attributes. I believe the text in the > Introduction captures this quite well: >=20 > In the XML encoding, XML attributes are a natural instrument for > attaching annotations to data node instances. This document > deliberately adopts some restrictions in order to remain compatible > with the XML encoding of YANG data node instances and limitations of > XML attributes. Specifically, >=20 > o annotations are scalar values and cannot be further structured; >=20 > o annotations cannot be attached to a whole list or leaf-list > instance, only to individual list or leaf-list entries. >=20 > If it turns out that structured annotations are needed, another = document > (or an update to this one) can introduce them, including appropriate = XML > encoding rules. >=20 > Thanks, Lada >=20 >>=20 >>=20 >>>=20 >>>> If I'm not missing something, that may be more of an open issue = than > a nit. >>>>=20 >>>> 2) The shepherd writeup calls out the tension in figuring out > whether to >>>> make this an extension or a new built-in statement. Please consider >>>> capturing the reasoning for the path you chose in the draft itself. >>> I will try, the main reason was that most people felt that > introducing a >>> new built-in statement is too big a change for the upcoming > maintenance >>> version of YANG (1.1) and YANG 2.0 is nowhere in sight. >>>=20 >>> Thanks, Lada >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 11 05:07:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D785912D69A; Fri, 11 Mar 2016 05:07:14 -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 9R64Une7E-FE; Fri, 11 Mar 2016 05:07:12 -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 21D4C12D536; Fri, 11 Mar 2016 05:07:12 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D8EDE1975; Fri, 11 Mar 2016 14:07:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id SvzA_vr3qycn; Fri, 11 Mar 2016 14:06:48 +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, 11 Mar 2016 14:07:10 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD3492003D; Fri, 11 Mar 2016 14:07:09 +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 eSRABD0LAFuF; Fri, 11 Mar 2016 14:07:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 026392003A; Fri, 11 Mar 2016 14:07:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E3C083A2DE5A; Fri, 11 Mar 2016 14:07:07 +0100 (CET) Date: Fri, 11 Mar 2016 14:07:07 +0100 From: Juergen Schoenwaelder To: "tom p." Message-ID: <20160311130707.GA10591@elstar.local> Mail-Followup-To: "tom p." , Ladislav Lhotka , Robert Sparks , General Area Review Team , ietf@ietf.org, netmod@ietf.org, draft-ietf-netmod-yang-metadata.all@ietf.org References: <56D60EF5.7020001@nostrum.com> <56E209E3.4030805@nostrum.com> <415C6558-F5D2-4575-B380-C082171DFA21@nic.cz> <033701d17b91$710ce580$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <033701d17b91$710ce580$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-ietf-netmod-yang-metadata.all@ietf.org, netmod@ietf.org, General Area Review Team , Robert Sparks , ietf@ietf.org Subject: Re: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04 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, 11 Mar 2016 13:07:15 -0000 On Fri, Mar 11, 2016 at 11:15:28AM +0000, tom p. wrote: > Lada, Robert > > The other angle from which this might be approached is that the I-D > already says > > " Using the "type" statement, a type is specified for the annotation > value according to the same rules as for YANG "leaf" type. " > > while rfc6020bis says > > " The "leaf" statement is used to define a scalar variable of a > particular built-in or derived type." > > so if you know your YANG off by heart, then you will know that > annotations must be scalar. I agree that the text needs to be clearer. > Perhaps, > OLD > " o annotations are scalar values and cannot be further structured;" > NEW > "Annotations obey the same rules as for a YANG "leaf" type [rfc6020bis > s.7.6] and so are limited to scalar variables." There is no 'leaf type' in YANG. YANG has leaf nodes in the schema tree. An annotation is not a node in the schema tree. Perhaps something like this: An annotation carries a single value. The type substatement, which must be present, takes as an argument the name of an existing built-in or derived type and the value of the annotation must match this type. See Section 7.4 of [RFC6020bis] for details. /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 11 07:04:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41BD12D7F0; Fri, 11 Mar 2016 07:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 43mJ7lx4zH9F; Fri, 11 Mar 2016 07:04:44 -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 C6D7F12D7A5; Fri, 11 Mar 2016 07:04:43 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:78b3:e555:d573:5b15] (unknown [IPv6:2001:718:1a02:1:78b3:e555:d573:5b15]) by mail.nic.cz (Postfix) with ESMTPSA id 58E4D180C61; Fri, 11 Mar 2016 16:04:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457708682; bh=UQpkKPunZgUBmASqsQqiyQx4A9tPdfwtryl/F8TAw2U=; h=From:Date:To; b=utzc9nLmfAttDAXZJ0lXzNwE/+1a4LVAKZK67hOuxB10IhxSedR9oa8pQxIHjZsoj u0uJ+x8AKcZDlUl02/Ky6gnkjMjxO86z6f4j9EMfimdvDcXNsRu944YdraiIZm6V3A cHV7yPOsb65meWp0ZBQTBguuqKGXbqR0eOZAKVEM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160311130707.GA10591@elstar.local> Date: Fri, 11 Mar 2016 16:04:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47A0C6CB-1B26-48E0-ADF4-A7D6E4AA47C0@nic.cz> References: <56D60EF5.7020001@nostrum.com> <56E209E3.4030805@nostrum.com> <415C6558-F5D2-4575-B380-C082171DFA21@nic.cz> <033701d17b91$710ce580$4001a8c0@gateway.2wire.net> <20160311130707.GA10591@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: draft-ietf-netmod-yang-metadata.all@ietf.org, NETMOD WG , General Area Review Team , Robert Sparks , "tom p." , ietf@ietf.org Subject: Re: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04 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, 11 Mar 2016 15:04:46 -0000 > On 11 Mar 2016, at 14:07, Juergen Schoenwaelder = wrote: >=20 > On Fri, Mar 11, 2016 at 11:15:28AM +0000, tom p. wrote: >> Lada, Robert >>=20 >> The other angle from which this might be approached is that the I-D >> already says >>=20 >> " Using the "type" statement, a type is specified for the = annotation >> value according to the same rules as for YANG "leaf" type. " >>=20 >> while rfc6020bis says >>=20 >> " The "leaf" statement is used to define a scalar variable of a >> particular built-in or derived type." >>=20 >> so if you know your YANG off by heart, then you will know that >> annotations must be scalar. I agree that the text needs to be = clearer. >> Perhaps, >> OLD >> " o annotations are scalar values and cannot be further = structured;" >> NEW >> "Annotations obey the same rules as for a YANG "leaf" type = [rfc6020bis >> s.7.6] and so are limited to scalar variables." >=20 > There is no 'leaf type' in YANG. YANG has leaf nodes in the schema > tree. An annotation is not a node in the schema tree. Perhaps > something like this: >=20 > An annotation carries a single value. The type substatement, which > must be present, takes as an argument the name of an existing > built-in or derived type and the value of the annotation must match > this type. See Section 7.4 of [RFC6020bis] for details. Looks good, thanks. Robert, Tom, do you think this text is sufficient?=20= 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: E74E8C0C From nobody Fri Mar 11 07:16:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3106112D529; Fri, 11 Mar 2016 07:16:22 -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] 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 i6D3l5Fkxo9d; Fri, 11 Mar 2016 07:16:20 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3DB4812D7A5; Fri, 11 Mar 2016 07:16:20 -0800 (PST) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2BFGJIe080892 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 11 Mar 2016 09:16:19 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: Ladislav Lhotka , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= References: <56D60EF5.7020001@nostrum.com> <56E209E3.4030805@nostrum.com> <415C6558-F5D2-4575-B380-C082171DFA21@nic.cz> <033701d17b91$710ce580$4001a8c0@gateway.2wire.net> <20160311130707.GA10591@elstar.local> <47A0C6CB-1B26-48E0-ADF4-A7D6E4AA47C0@nic.cz> From: Robert Sparks Message-ID: <56E2E143.6060309@nostrum.com> Date: Fri, 11 Mar 2016 09:16:19 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <47A0C6CB-1B26-48E0-ADF4-A7D6E4AA47C0@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: NETMOD WG , General Area Review Team , ietf@ietf.org, "tom p." , draft-ietf-netmod-yang-metadata.all@ietf.org Subject: Re: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04 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, 11 Mar 2016 15:16:22 -0000 Yes, thanks. On 3/11/16 9:04 AM, Ladislav Lhotka wrote: >> On 11 Mar 2016, at 14:07, Juergen Schoenwaelder wrote: >> >> On Fri, Mar 11, 2016 at 11:15:28AM +0000, tom p. wrote: >>> Lada, Robert >>> >>> The other angle from which this might be approached is that the I-D >>> already says >>> >>> " Using the "type" statement, a type is specified for the annotation >>> value according to the same rules as for YANG "leaf" type. " >>> >>> while rfc6020bis says >>> >>> " The "leaf" statement is used to define a scalar variable of a >>> particular built-in or derived type." >>> >>> so if you know your YANG off by heart, then you will know that >>> annotations must be scalar. I agree that the text needs to be clearer. >>> Perhaps, >>> OLD >>> " o annotations are scalar values and cannot be further structured;" >>> NEW >>> "Annotations obey the same rules as for a YANG "leaf" type [rfc6020bis >>> s.7.6] and so are limited to scalar variables." >> There is no 'leaf type' in YANG. YANG has leaf nodes in the schema >> tree. An annotation is not a node in the schema tree. Perhaps >> something like this: >> >> An annotation carries a single value. The type substatement, which >> must be present, takes as an argument the name of an existing >> built-in or derived type and the value of the annotation must match >> this type. See Section 7.4 of [RFC6020bis] for details. > Looks good, thanks. Robert, Tom, do you think this text is sufficient? > > 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: E74E8C0C > > > > From nobody Fri Mar 11 07:24:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFDE12D79B for ; Fri, 11 Mar 2016 07:24:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 vBGxwWKDU67H for ; Fri, 11 Mar 2016 07:24:15 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7EB412D7DC for ; Fri, 11 Mar 2016 07:24:03 -0800 (PST) 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 (TLS) id 15.1.415.20; Fri, 11 Mar 2016 15:23: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.0434.016; Fri, 11 Mar 2016 15:23:46 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: [netmod] yang-next Thread-Index: AQHRezuHCjOy1QqTn0qmzv3NK6P/559UCA+AgAABqIA= Date: Fri, 11 Mar 2016 15:23:46 +0000 Message-ID: References: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> <20160311.111749.461139040057688947.mbj@tail-f.com> In-Reply-To: <20160311.111749.461139040057688947.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 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.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:KdCvIDQW+7UJ71DEVWYro1rYwofzjMeU/62riq9nCShYpF3ZiQ3cbXe93mQjiZhUfN5DLX03efeqlFJYv6VtME7OL9VUhUibUOq/5LtypzGMq14FDb1+xmqBbSCjz8JtWo2KiT1lI/iMzjp55E25NQ==; 24:wZ47tcYOHAKFjUTdV6WwIshehIrpYKa8xvsYjW86FG80w8qdnbENy3MLEciBlTKnwGWO8hiNpIPiKcidvFlus6OJ1Oo72rOvaTNJnU850Cw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: a33e9829-3692-4d07-c63d-08d349c123e2 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 087894CD3C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(102836003)(33656002)(10400500002)(87936001)(5008740100001)(189998001)(586003)(3846002)(6116002)(110136002)(86362001)(1096002)(4001350100001)(122556002)(82746002)(2906002)(83506001)(77096005)(36756003)(106116001)(2900100001)(2950100001)(81166005)(3660700001)(1220700001)(99286002)(83716003)(5004730100002)(92566002)(4326007)(3280700002)(5002640100001)(66066001)(50986999)(54356999)(76176999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0742EB8BD629FF48942D5FFDD833EBFA@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2016 15:23:46.7545 (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: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-next 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, 11 Mar 2016 15:24:17 -0000 DQoNCg0KDQoNCj5JIHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVhIHRvIGNhcHR1cmUgaWRlYXMgbGlr ZSB0aGlzLCBidXQgSSBhbHNvIHRoaW5rDQo+dGhhdCBzdWNoIGlkZWFzIHNob3VsZCBiZSBkaXNj dXNzZWQgb24gdGhlIE1MLiAgQnV0IG1heWJlIHRoYXQncyB3aGF0DQo+eW91IG1lYW50Lg0KDQoN Ck15IHRob3VnaHQgaXMgdG8gZGVmZXIgYW55IGRpc2N1c3Npb24gb24gdGhlIE1MIHVudGlsIHdl IGFjdHVhbGx5IHdhbnQgdG8gc3RhcnQgd29ya2luZyBvbiB5YW5nLW5leHQuICBUaGF0IHNhaWQs IGl0IHdvdWxkIGJlIGdvb2QgdG8gZW5zdXJlIHRoYXQgYW55IGlzc3VlcyBwb3N0ZWQgaW4gdGhl IGludGVyaW0gYXJlIHN1aXRhYmx5IGNhcHR1cmVkOyB0aGF0IHdoYXTigJlzIGJlaW5nIGFza2Vk IGZvciBpcyBjbGVhcmx5IHVuZGVyc3Rvb2QuICAgT2YgY291cnNlLCB3ZSBjb3VsZCBhdCBhIGxh dGVyIHBvaW50IGluIHRpbWUgcmVhY2ggb3V0IHRvIHRoZSBnaXRodWIgdXNlcmlkIHRvIGFzayBm b3IgYSBjbGFyaWZpY2F0aW9uIGFuZCwgaW4gdGhlIGNhc2Ugb2Ygbm8gcmVzcG9uc2UsIGVpdGhl ciBkbyBvdXIgYmVzdCBvciBkcm9wIGl0LiAgVG8gbWUsIGl0IGlzIHN1ZmZpY2llbnQgdG8ganVz dCBjYXB0dXJlIHRoZSBpZGVhcywgd2l0aCBubyBkaXNjdXNzaW9uIGhhcHBlbmluZyB1bnRpbCBs YXRlciBhbmQgdGhlbiwgb2YgY291cnNlLCB0aGV5IHdvdWxkIGJlIG9uIHRoZSBNTC4NCg0KVGhh bmtzLA0KS2VudA0KDQo= From nobody Fri Mar 11 07:57:42 2016 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 A1BD212D89A; Fri, 11 Mar 2016 07:57:41 -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.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311155741.32174.86489.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 07:57:41 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-metadata-06.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: Fri, 11 Mar 2016 15:57:41 -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 : Defining and Using Metadata with YANG Author : Ladislav Lhotka Filename : draft-ietf-netmod-yang-metadata-06.txt Pages : 20 Date : 2016-03-11 Abstract: This document defines a YANG extension statement that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-metadata-06 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 Fri Mar 11 07:59:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDD212D777 for ; Fri, 11 Mar 2016 07:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 eEbcFiHrJcbG for ; Fri, 11 Mar 2016 07:59:36 -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 6C21112D71B for ; Fri, 11 Mar 2016 07:58:57 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:78b3:e555:d573:5b15] (unknown [IPv6:2001:718:1a02:1:78b3:e555:d573:5b15]) by mail.nic.cz (Postfix) with ESMTPSA id 1CBFE180879 for ; Fri, 11 Mar 2016 16:58:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457711936; bh=hpsUX1h/MavPCKhfi4j+pQjeO3MB/S6b03Q5S72iBLs=; h=From:Date:To; b=Hz5L4G7GI2OAM7SI+ebR1aa3c8dLpzlsFid/+y5ZxnxFiwXcoZGEgds3HZmgCVPB/ cgWpg1BnMTwpbnJ4rp44nv+bbp26lJXDxKaCuq0Qveg5GoKlkmSFmQhW3xWSyL2tdI /hYi5DzCHVn7Fqma5aAiHeC78qht/s9OTO6rcDO4= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Mar 2016 16:58:59 +0100 References: <20160311155742.32174.9808.idtracker@ietfa.amsl.com> To: NETMOD WG Message-Id: <3A070EF1-BA45-4DFE-98C1-71475A929A9D@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-06.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: Fri, 11 Mar 2016 15:59:39 -0000 Hi, this revision contains minor clarifications regarding the type of = annotations, mainly based on Juergen's suggestion. Thanks, Lada > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-netmod-yang-metadata-06.txt > Date: 11 March 2016 at 16:57:42 GMT+1 > To: "Ladislav Lhotka" >=20 >=20 > A new version of I-D, draft-ietf-netmod-yang-metadata-06.txt > has been successfully submitted by Ladislav Lhotka and posted to the > IETF repository. >=20 > Name: draft-ietf-netmod-yang-metadata > Revision: 06 > Title: Defining and Using Metadata with YANG > Document date: 2016-03-11 > Group: netmod > Pages: 20 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-metadata-06.tx= t > Status: = https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-06 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-metadata-06 >=20 > Abstract: > This document defines a YANG extension statement that allows for > defining metadata annotations in YANG modules. The document also > specifies XML and JSON encoding of annotations and other rules for > annotating instances of YANG data nodes. >=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 11 08:12:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0735912D8F1 for ; Fri, 11 Mar 2016 08:12:46 -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 gIpaj3yMOK5l for ; Fri, 11 Mar 2016 08:12:44 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id BC89312D913 for ; Fri, 11 Mar 2016 08:11:52 -0800 (PST) Received: (qmail 13193 invoked by uid 0); 11 Mar 2016 16:11:51 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 11 Mar 2016 16:11:51 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id UnBe1s00Z2SSUrH01nBhfZ; Fri, 11 Mar 2016 16:11:48 -0700 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=Lh_ONR24_viMmw4lDPkA:9 a=QEXdDO2ut3YA:10 a=1SkHfpfvLsYA:10 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; bh=DTEV+uh3REZMElUPAYZ+NdgTkJxvMdi6p7blXAXtgWU=; b=Ha2/2uxRNux6SddYE+shd/OysC quuRoicEpGgnZzdWg6DJAB6xPPGEriewB4l85INBDhShhGk4dLCo521M1UMFFDLanOC7d2If6lGWe pqyJ6Z5jDTHFo37D0XhuW5GDQ; Received: from box313.bluehost.com ([69.89.31.113]:33239 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1aePfB-0003yL-5C; Fri, 11 Mar 2016 09:11:41 -0700 To: Martin Bjorklund , kwatsen@juniper.net References: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> <20160311.111749.461139040057688947.mbj@tail-f.com> From: Lou Berger Message-ID: <56E2EE36.6050900@labn.net> Date: Fri, 11 Mar 2016 11:11:34 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160311.111749.461139040057688947.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-next 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, 11 Mar 2016 16:12:46 -0000 I tried and failed to the repo to email events to the list. If anyone knows how to do this, please send mail to netmod-chairs@ietf.org. Thanks, Lou On 3/11/2016 5:17 AM, Martin Bjorklund wrote: > I think it is a good idea to capture ideas like this, but I also think > that such ideas should be discussed on the ML. From nobody Fri Mar 11 09:02:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0BD12D971; Fri, 11 Mar 2016 09:02:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 KtNXQj_HXmNc; Fri, 11 Mar 2016 09:02:43 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14CC12D995; Fri, 11 Mar 2016 09:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h05LEyDnl+WfautV6rbz4JmL8Hx9udDEH6z53U4OVi0=; b=Q7kvw4Say9B2xtWMN40GjLbZGekM8zLMVWxNTZrSoGxiU1QGN8LDxa+HopndeGanz0twi/BQRaHvp2PpBQZRsZlbreOFfle0QQO4rQ+UdJLYfaxg44ul7Gk6QmlSRTIITLsEu+TDNxcgb+BCu4xR8xhE67jrPYouYnY8s2q+qkM= 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.147.17.222) by AM4PR07MB1553.eurprd07.prod.outlook.com (10.165.249.9) with Microsoft SMTP Server (TLS) id 15.1.443.7; Fri, 11 Mar 2016 17:01:57 +0000 Message-ID: <014101d17bb7$2a799de0$4001a8c0@gateway.2wire.net> From: tom p. To: Juergen Schoenwaelder References: <56D60EF5.7020001@nostrum.com> <56E209E3.4030805@nostrum.com> <415C6558-F5D2-4575-B380-C082171DFA21@nic.cz> <033701d17b91$710ce580$4001a8c0@gateway.2wire.net> <20160311130707.GA10591@elstar.local> Date: Fri, 11 Mar 2016 16:39: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.147.17.222] X-ClientProxiedBy: AM4PR02CA0019.eurprd02.prod.outlook.com (25.165.239.157) To AM4PR07MB1553.eurprd07.prod.outlook.com (25.165.249.9) X-MS-Office365-Filtering-Correlation-Id: c88e8f4a-1df9-4911-1b45-08d349cedb46 X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1553; 2:sSb/IP+ftCmAKA85FtP59QMKFBWAjae+9Y9w47oXQfEFmqzWIyCw4skQJdCtyQbxKZ5MYpJdjA7ovmJy0K5KUuZp2exFgKJfRdO18GHXnkOSo5fgdpEjan9EZj4Vvnav7u4P0mHdJKrb1IUMlWFjFMOlZb3sLUuws58CM8BiiABhin5MTVtcrH2Qm8bEzAFn; 3:nZ1I+Per++mmWdUrbvMusRse629k7/19lFQVuJz79fXVAYbn7hXpjevpL2EMqy8mOwodO0HMTLXzI9rSR2WsITwlFAmA24Mi8jLkz33G3iU54cMQLTvXUdr8Q7M0Wqua; 25:8/veubDNkmigvgaTO1S0scsr5Lgtsi5mmccZrnwPfhZZq3O0GjmOKfgpx16pGT+P4gphRW0QEI2ue+fgoSUvzU3h+Z724EU8wMjg7khOFDq7lsm9H47ymQCJlX5ahJBvWdReWRw+HhnlwZwooZ4b9y+mjO2XJ8MJoPGPvEsFy07yeYMEvfgrMaMYfKqrGe6UqIeaVSZUju5ut55zU+oePZM/VXQgJoynH1jTk/FtGgPtSWQyHq7IqFz/ruiD+Qv2MKgmfblhq1b5ngNd0ejZaOWu00O/eOncZ5Aiu/DeD9R+U3YFPf/bBpgVsjIjRsa+Cknvp8ENmz/MAbPQO/5a/w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1553; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM4PR07MB1553; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1553; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1553; 4:57CxPe15geQ3OK7cuUZm88AQuED52ROFYWoXhcWzh3TltxEtdH7iA2hkSRdCZJuay0D8E7yQIkGu3e+BIJjCbNOGPDp1yfzcNdOKgMnDvVFRC7wJ2S6AxageHIB8wTZw44JLxZpdJCoMhV0CylS4dr0L/DP7qq1YZ7v299hhohgi5k5F+2nvbOqHzqYYcUXoOkVLjI7LcQDYB9fkVw3HauVp89uBS3kDQ+x0naN4ZxcIZe0wBGbqM1izoxl91xcaRh/I8L3yavj7QeNPVziTbP3lQSmcTl2Qt68MQaxRF+oNISk7G79ufCQ7mn17qArwg6OCZmUpUUiEtRkRkm4oYZ/cOnSCf3JTBq6Zss4EjQAtLU7ktVcVFY9b49qmxyQj X-Forefront-PRVS: 087894CD3C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(24454002)(377454003)(81166005)(93886004)(47776003)(62236002)(44716002)(2906002)(586003)(23756003)(84392002)(50466002)(5008740100001)(42186005)(66066001)(33646002)(4326007)(77096005)(1456003)(61296003)(44736004)(110136002)(189998001)(230700001)(6116002)(3846002)(230783001)(50226001)(5004730100002)(86362001)(50986999)(116806002)(1556002)(92566002)(76176999)(19580395003)(14496001)(81816999)(19580405001)(81686999)(1096002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1553; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM4PR07MB1553; 23:PR37wTn9QHO+ASMI00dCIJe18MKrlnRtq27P5Y2?= =?iso-8859-1?Q?UA0rs8SulJrO65zEMYOUMrNykjO17nfLbpa/fFzDkIThrF9/XpYSHBpZ3T?= =?iso-8859-1?Q?URk8QY4bNzMOP2O7gBDSm51tJAz/ZT+AfzvnVHqfGvkLDRfdcZ3V66qxdA?= =?iso-8859-1?Q?M87BLgRPAKPAiCW9vWm+bOQiwr6IJZo++W9+AxifICO+ZZb3womu+1ryTf?= =?iso-8859-1?Q?8DtYcE+VudgK+3lmIhtSfHlWRgmC3virtMNddxu51SvtUdoAz9hzLkCdCC?= =?iso-8859-1?Q?xgWbaetnPlpzM5/lkQs4OzowEBghRnRqNVXhbcP0/ZLhIZLVVDC0+W/dqR?= =?iso-8859-1?Q?+SBYZFwAwTB7UfC43zKKS8S5Y2KjhvVuT2WM09ZayppBJGstJhxNbrD8M9?= =?iso-8859-1?Q?JeSWNGOAzzVX//P/DgT/Pwo5LqwofLBgU2JTRJ93peo2Dgy470Scbwl0qf?= =?iso-8859-1?Q?mBTzRsHxthGyB7gnQ4DoXPiyBai7n57FtA2fYT3B67G04CCC7iphLGtQaE?= =?iso-8859-1?Q?mPWVfp1R0yxBsM4r80ggmyWGIpesosNxxZ02sqNp6+7+/H2cunHUBPBadn?= =?iso-8859-1?Q?2WU2QvAn7PtVgUrB/1Q3zLhTR+JPfGlWMdX60m2n85b/YFhqw/vsENpowD?= =?iso-8859-1?Q?1Y69XBGAyi5kgK2bPMTvSAFlTCcNGbbnnxnRGBcKx2MNlJ8LaGSnflx+WW?= =?iso-8859-1?Q?BBXCM30wC3aHKio+dc4zHn4HAJFOrvnI2t62dNfQLQ1GTig7WB2DyOoI5B?= =?iso-8859-1?Q?CVLvj1JQ+wxX6KO5Ztcpx+u65BdrSbh1L/jOeBA1QB9n2H+7duDjEaeoC3?= =?iso-8859-1?Q?tevC4UbkgaIA1y+Ix2vgllALqOLXo59DLwkwuQyI23GYkS52bmobd5yP7R?= =?iso-8859-1?Q?BcDOhldnfMszuKQsMIzODaNySke+l0XLCovcmeecuUSn3Sarf4pl06O0En?= =?iso-8859-1?Q?PxC4nw3QmEAhNjwJH5PG0DtXE3fYYxDqBeyG09MWrCgVkultpJSEerONvL?= =?iso-8859-1?Q?TI/4xi7KTDvDS869m7Kq5cibNJ6AyVtpCv7WcFw4rIplci+k7QVANIJu+U?= =?iso-8859-1?Q?GQGwYcrogimXtvaLhMlNrCcQCA8qQuTKQ8AbC6TP1yGRuwiqQpiPs56kFu?= =?iso-8859-1?Q?nl96biqjk8UtLaeJXR0n3L+wk8HW9cRWwO34eZNhlQefI9EZgmPlPnM9i5?= =?iso-8859-1?Q?qX3UZ4OjD+2SYMeAWSwPTGx5vY69u74n/SKOkoGgE+kf5IGbsIrUWpp8ko?= =?iso-8859-1?Q?gh5rX/ITUTYcSlV4A?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1553; 5:dGJj79NYrm+5FC+AHyFRtDGLaOKhq/qy25u54svdQp+BVK1h5Bd1/Q/lTiLkCsW8Z2zPLjDPa4K50fJTXfzyM3lNW44M+6Okp2qmDS/xdeg2gor+H8rBAeJ3sUjGrTrf/F+VvfyvlT4AvGN27PfmXg==; 24:26/5Hlj5gl88YXJG+a3RLt8UM+WZ7KvIcHmVrpTIR/xl+WXZzsRAuaRA3GqxnG+MLg+DOzJObdOS7FjNLPvgMiC5XCAHZ/Q3yFsqnNlhkoM= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2016 17:01:57.7611 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1553 Archived-At: Cc: draft-ietf-netmod-yang-metadata.all@ietf.org, netmod@ietf.org, General Area Review Team , Robert Sparks , ietf@ietf.org Subject: Re: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04 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, 11 Mar 2016 17:02:47 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Sent: Friday, March 11, 2016 1:07 PM > On Fri, Mar 11, 2016 at 11:15:28AM +0000, tom p. wrote: > > Lada, Robert > > > > The other angle from which this might be approached is that the I-D > > already says > > > > " Using the "type" statement, a type is specified for the annotation > > value according to the same rules as for YANG "leaf" type. " > > > > while rfc6020bis says > > > > " The "leaf" statement is used to define a scalar variable of a > > particular built-in or derived type." > > > > so if you know your YANG off by heart, then you will know that > > annotations must be scalar. I agree that the text needs to be clearer. > > Perhaps, > > OLD > > " o annotations are scalar values and cannot be further structured;" > > NEW > > "Annotations obey the same rules as for a YANG "leaf" type [rfc6020bis > > s.7.6] and so are limited to scalar variables." > > There is no 'leaf type' in YANG. YANG has leaf nodes in the schema > tree. An annotation is not a node in the schema tree. Perhaps > something like this: Juergen Well, I know, but I was quoting directly from yang-metadata-04 s.3, namely "Using the "type" statement, a type is specified for the annotation value according to the same rules as for YANG "leaf" type. " which is why I gave a reference to s7.6 of RFC6020bis rather than s.7.4. Perhaps change s.3 in addition to your change OLD Using the "type" statement, a type is specified for the annotation value according to the same rules as for YANG "leaf" type. NEW Using the "type" statement, a type is specified for the annotation value according to the same rules as for the type of a YANG "leaf"[RFC6020bis s.7.6]. I do think that that mention of leaf is helpful - as you say, the WG agreed to this restriction as opposed to allowing more complex annotations and referencing "leaf" for me makes that clearer. Tom Petch > An annotation carries a single value. The type substatement, which > must be present, takes as an argument the name of an existing > built-in or derived type and the value of the annotation must match > this type. See Section 7.4 of [RFC6020bis] for details. > > /js > From nobody Fri Mar 11 09:16:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1059312D995 for ; Fri, 11 Mar 2016 09:16:18 -0800 (PST) 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=[BAYES_20=-0.001, 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] 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 IflbnDzSiYje for ; Fri, 11 Mar 2016 09:16:17 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0127.outbound.protection.outlook.com [104.47.2.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C68612D971 for ; Fri, 11 Mar 2016 09:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8m7CrCDYHKjuzKRU7LpvWOQ+aKS4GtDGrk/P2HFLF5k=; b=g60AyUomid2DBhYS5fEJWNkolUmdyzbOjLge8OveJTfW4zDtfQlyJVvcMFbJlWLkkPqXURrxZpXcBaqFv9po7Mr/F2Ub766K2LmUbmE0DH4WwId4jMrly+bINT0v+VKFFH7nca2o9axt3Oz17QTJuSIpb0uWtucWpXNplA7a4Ug= 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.147.17.222) by VI1PR07MB1629.eurprd07.prod.outlook.com (10.166.142.147) with Microsoft SMTP Server (TLS) id 15.1.443.7; Fri, 11 Mar 2016 17:16:13 +0000 Message-ID: <017301d17bb9$288005e0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Date: Fri, 11 Mar 2016 17:11:56 +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.147.17.222] X-ClientProxiedBy: AM4PR02CA0023.eurprd02.prod.outlook.com (25.165.239.161) To VI1PR07MB1629.eurprd07.prod.outlook.com (25.166.142.147) X-MS-Office365-Filtering-Correlation-Id: aab160c5-023e-4326-110a-08d349d0d949 X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1629; 2:kPWpFbpUL0yRbET7RQvdRDxvm0UT/XCKH/+ys4cp6UV/H3WzE6smvInL6qPXuKFcNaZmLmYneLEpyunt4rlWhHYTftAyj42raZx6WGGpea78zMJRuh7jIS1IR0iI7ycMkW2xtnKnCHUnBB0dgsyv0egC3CNprn740NIjhxFhiyFuzJJUUGiOaI9MOF9da4HA; 3:S672OVHC7iGfboM6bc77z2xlrnDCvwgxW8NIeMz7lawKPwldAQgt5rnzeQmbBGMWkRLni63aylJOvyveYalRmoyxqGxCfjbpk1lr4hrQPl6ULEZbEMjqQzVPxnSs2wvk; 25:IwmJ6HSR4gpG+hlYH4v/1aAnZTI0np5hJ2A4iyfOT/4EJszaZoSxefHtK7cxDLGG1JQQq8wVXzD2qXZRU8Z5OIV6/0nFjLM7ysPsi934BvOZ36lXv4uxxzfGPOaCwCqtpfGxjX0eiAniT3j4EXBJ3YwRZ0ttQMmHrWDooYsj7w0JSPvBvr2H0AT5u7YZGVwui/l9Ca923Y4JLjJWwtvXBgg59AGfQIOs43/b3xR8q/K85QPQkmJjP1KRQnavV1fjWLEk4BazVM0QYvVUAzQOjPEp5y55Alx3aZ8JgIgrWfmWFANMBea7vAYKdKvkmJ/481GoeA9Tr4AssJJXF6AaQw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1629; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR07MB1629; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1629; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1629; 4:FE1Ff7wdhgSe5jF1wI83ZrTYI6iQwaZIM7ntaOUM5t2fF+F7SxDfYEH7gh9A1V4SCrA0fBC7Y4udR2RY5Ei05w3Uklv3VSx+vPdWJGJvjPn8YcZdTT+wh9FXQ01joOb5Bol/pP89NXuxs67Y+Zbvow21NYs+5MPCy7L4RW+eP6F8Fulz79Q0ypb3OMQARXqzgnTWNYO3YaPN9CFhueA4iLLx/3vSBo4kpryrSSbN8CbBVvyKtHf1qOGLdxLHNKISV/6I5ZAaFQ7jwGGrO8t+Gj8l14Cj6rY6zkjDPrOoLW4dpdJ8FnXHXWeuu2vlUMnnQUzgC1AltfbBi4RETeyquBl6Q40fCumcJJqbhw8Lxr0qHfdvAiRLAAP1UKJVoktr X-Forefront-PRVS: 087894CD3C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(50986999)(23676002)(81686999)(81816999)(66066001)(5008740100001)(586003)(1096002)(1456003)(77096005)(2906002)(3846002)(1556002)(6116002)(3480700003)(230700001)(84392002)(50466002)(86362001)(116806002)(1941001)(189998001)(107886002)(61296003)(42186005)(33646002)(62236002)(44716002)(47776003)(44736004)(14496001)(5004730100002)(81166005)(92566002)(5001770100001)(229853001)(50226001)(7059030)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1629; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIxNjI5OzIzOllWS0xZZnQ0em5OWDJJOFFlUFgrclluZC9T?= =?utf-8?B?RnVHZnpsd0JmZC9oYzZCYnpuNmVxeEQzdWN1Vzg5WHNoSGFqVlJFVkhUMmY3?= =?utf-8?B?b053cUh3YjhOTzI0ZU5MWUw5cjhISFJKZ1BTN1BPbEdrSmZnTE9xaGtVRjBs?= =?utf-8?B?NTdwa3FUMUxiblg0ODUzaGxYaXNGU1l0OHowSms2YmtsV1JiUnUwS1Qzclkz?= =?utf-8?B?Q1ZzTTlPKzZheVM2R0RHa2M3TnpjeXlURTNxMi9iVnFFVHRFWVRMTkt0U0Yw?= =?utf-8?B?SjQyR2hjSXp4eXRCb0tYc05DU1hoZ3Q2MmtwWVB5YkczaGFzVGFXR0lMenRz?= =?utf-8?B?eUMyRnNkRm9VSmlObFJvelFKTlZaQ3NJS0FIQ3NZWGdQS1h1WEoxWWF5TnpQ?= =?utf-8?B?aFZzTXZqTkV4bG5aQmxwS3pNd2F3ZmtTZEpBcFEwNllyaSt4V0VkVkF5Tklq?= =?utf-8?B?YzdDRGJEOENYam5uSG1VWjd2cG1MYlRqenoySlZ1bDJGVjBjaHFReE5vOUhO?= =?utf-8?B?d0pjWXFOQnpTblNqWFQvV2dMMVlTS1QrdGhRMlcyQ1ViK3RaeTFuOUZ5aHJo?= =?utf-8?B?U3plZEJDMGI5YnlCbyt2bzNadFFKaGNYY2d3Q09vVHRXTUJyVktPTC84UWcz?= =?utf-8?B?dDRUbGtzUmpSVExubGcwUVhKbWRXTm15MmsvVnpHVjlTQW9pYUREK3JCZlBk?= =?utf-8?B?QnRBMFh6bDRqQ2p1UlJXb1BFOHg1NmR1azBwOFVhSldrYm5helE3UWxsR0I0?= =?utf-8?B?TGVlMEU1amNXSVM0OTZhbGFodVpmTGxxendnWDNzMW1mTVBxVjRGcGV2cll1?= =?utf-8?B?b25tVEl6bGZQWEJhV1hheGgwNlB6T1d2aWpUU0MwSk5acmhsMkJJUFFXZXNl?= =?utf-8?B?NjY1Qk5aQlB1S3A5ZzlUd1lGbW5OcGVJUG1udUxUR0xLanBQbkZRcVhJNUNk?= =?utf-8?B?K3dmMElEZCtmSFZwSUxWRHQ2QTVxQ0llWXppTURsOHgvTEhHeCt1MlRzNlNn?= =?utf-8?B?RE1WV3k4U3UvSFlCQ2hzSkZDMjlvUTV3L0ZBTjdQVUh3aW56czNoakJuT294?= =?utf-8?B?ZE03QjdodXBOa3RpK05DSmRUMDh3eEovSlp3Zm9yMDk2a1kzN3ZqbTB2RTQv?= =?utf-8?B?YzdhTTBGTDFqeDBrZDdseEFWOG11a0luRUlYbzdHWEwwakRGNEprTnVoNU9t?= =?utf-8?B?WnhGbnhVNUV6YVZkOVlLSng5MGRiQ3o0Ni95NTc4MnBGdEdmYzdNUHgzZFdz?= =?utf-8?B?ZXNJcW13R2EvQ2ZRTFp4SnhPL3FEanZGSnhYNjFId0tkVkRtYVZPKzUxT3h2?= =?utf-8?B?eVA5Ykhsa2VJMEIvZ250Y3BSL0IwcDVHSWQ1OWlMcFp6VVBpbnpCamdZZlNV?= =?utf-8?B?akRuUEc1aE5oeDVuOUJJWTI4SWNuaisyUHhRbCtpNldTTjYyYUh1Vy9rRXRH?= =?utf-8?B?cXdXZjFkOGJvRlNzZzV6OWR6SFE3SDNEdnpxVkdPeENYaEozMzNBSU1IZUwv?= =?utf-8?Q?OJw/NmrZbrNn8wz5Ep2nDsfwo=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1629; 5:WV7450kzOPvr1oTSFx1+1XWMdVTMPbJx8LcjcDeetexsaPS2hyJDFKneTuyYrpesNY01Ht/+C8dgbj3ek280ICq5/OO/4GK4bVKZ8lnUfZYwrh7WYzZpoUW7dGc/+ZPgqboZiOEwAgKGb+JyixZiaA==; 24:CbnyeLicarzSY0KDP27+sWogZjf3oTiajmBy67ReI8FuuVNycYUf7oxXpCipvWn5UKjKVyvgPlbAAHYJjBoBYNsOOzDEzBP2/Ymv8/XoILA= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2016 17:16:13.4810 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1629 Archived-At: Subject: [netmod] action and mandatory node 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, 11 Mar 2016 17:16:19 -0000 Given container... list... action with the usual twiddly brackets, and a separate mandatory data node alongside the list in the top level container, is there a requirement to include that mandatory data node in the XML RPC? 6020bis s.7.15.2 says " The "action" element contains an hierarchy of nodes that identifies the node in the datastore. It MUST contain all containers and list nodes from the top level down to the list or container containing the action. " which suggests, without quite clearly telling me, that it is only the nodes in the direct path from the top level that have to be included, not any off to one side in the tree. If that is correct, I suggest OLD "It MUST contain all containers and list nodes from the top level down to the list or container containing the action. " NEW " It MUST contain all containers and list nodes in the direct path from the top level down to the list or container containing the action (node). " Tom Petch From nobody Fri Mar 11 09:16:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8F212D9BE; Fri, 11 Mar 2016 09:16:42 -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 bfzfPtjLbUfv; Fri, 11 Mar 2016 09:16:40 -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 8AA3E12D995; Fri, 11 Mar 2016 09:16:39 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DBD7F1975; Fri, 11 Mar 2016 18:16:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id R59nQBzr_BTf; Fri, 11 Mar 2016 18:16: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; Fri, 11 Mar 2016 18:16:36 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D87172003D; Fri, 11 Mar 2016 18:16:36 +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 N01f7KPIVcKs; Fri, 11 Mar 2016 18:16: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 255032003A; Fri, 11 Mar 2016 18:16:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 190073A2E0FC; Fri, 11 Mar 2016 18:16:35 +0100 (CET) Date: Fri, 11 Mar 2016 18:16:35 +0100 From: Juergen Schoenwaelder To: "tom p." Message-ID: <20160311171634.GA10970@elstar.local> Mail-Followup-To: "tom p." , Ladislav Lhotka , Robert Sparks , General Area Review Team , ietf@ietf.org, netmod@ietf.org, draft-ietf-netmod-yang-metadata.all@ietf.org References: <56D60EF5.7020001@nostrum.com> <56E209E3.4030805@nostrum.com> <415C6558-F5D2-4575-B380-C082171DFA21@nic.cz> <033701d17b91$710ce580$4001a8c0@gateway.2wire.net> <20160311130707.GA10591@elstar.local> <014101d17bb7$2a799de0$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <014101d17bb7$2a799de0$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-ietf-netmod-yang-metadata.all@ietf.org, netmod@ietf.org, General Area Review Team , Robert Sparks , ietf@ietf.org Subject: Re: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04 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, 11 Mar 2016 17:16:43 -0000 I assume 'An annotation carries a single value.' should be clear enough. A reference to section 7.6 is actually misleading since that section deals with many more things that are not applicable to leafs. But I think we are already done with this. /js On Fri, Mar 11, 2016 at 04:39:54PM +0000, tom p. wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > Sent: Friday, March 11, 2016 1:07 PM > > > > On Fri, Mar 11, 2016 at 11:15:28AM +0000, tom p. wrote: > > > Lada, Robert > > > > > > The other angle from which this might be approached is that the I-D > > > already says > > > > > > " Using the "type" statement, a type is specified for the > annotation > > > value according to the same rules as for YANG "leaf" type. " > > > > > > while rfc6020bis says > > > > > > " The "leaf" statement is used to define a scalar variable of a > > > particular built-in or derived type." > > > > > > so if you know your YANG off by heart, then you will know that > > > annotations must be scalar. I agree that the text needs to be > clearer. > > > Perhaps, > > > OLD > > > " o annotations are scalar values and cannot be further > structured;" > > > NEW > > > "Annotations obey the same rules as for a YANG "leaf" type > [rfc6020bis > > > s.7.6] and so are limited to scalar variables." > > > > There is no 'leaf type' in YANG. YANG has leaf nodes in the schema > > tree. An annotation is not a node in the schema tree. Perhaps > > something like this: > > Juergen > > Well, I know, but I was quoting directly from yang-metadata-04 s.3, > namely > > "Using the "type" statement, a type is specified for the annotation > value according to the same rules as for YANG "leaf" type. " > > which is why I gave a reference to s7.6 of RFC6020bis rather than s.7.4. > > Perhaps change s.3 in addition to your change > > OLD > Using the "type" statement, a type is specified for the annotation > value according to the same rules as for YANG "leaf" type. > NEW > Using the "type" statement, a type is specified for the annotation > value according to the same rules as for the type of a YANG > "leaf"[RFC6020bis s.7.6]. > > I do think that that mention of leaf is helpful - as you say, the WG > agreed to this restriction as opposed to allowing more complex > annotations and referencing "leaf" for me makes that clearer. > > Tom Petch > > > An annotation carries a single value. The type substatement, which > > must be present, takes as an argument the name of an existing > > built-in or derived type and the value of the annotation must match > > this type. See Section 7.4 of [RFC6020bis] for details. > > > > /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 11 09:34:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E8012D829 for ; Fri, 11 Mar 2016 09:34:42 -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 QsiGruDz4AnH for ; Fri, 11 Mar 2016 09:34:40 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 9739712D716 for ; Fri, 11 Mar 2016 09:34:39 -0800 (PST) Received: by mail-lb0-x22e.google.com with SMTP id xr8so159804846lbb.1 for ; Fri, 11 Mar 2016 09:34:39 -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:date:message-id:subject:from:to :cc; bh=9UtTA07+ovkVPuqADDz8KHdN3P0Obiq1tBGNc/CD1BU=; b=yLTO55I1BzRGlPk3B/kNl6RWi3M1qi9NdmIBUBupWYJkuKHAa822Ti5ljztiaTSlJc kGPRZHn7VbgYF0U3PCQkTOig3bajbaUx/QIwuUTRPzqrlXnAIdYk6Ojv+xVuMvm7mZxx RNayzsm5oFLOxNDICDCsrer8NFbZUDnUT9Ksj54XAFohsy6mueyIc+KE1mBOr+pbk77a Vgm4RRsK7L2OK4Wbo7JYaslUtpoBLqW41LCCTSgJisDilcvEz0YGXKc68D9CtRLoeHR0 kjK6kUI72HU1YvHCQ3PTsDD125snEPDt/mRIiBji6ZlBUPU7OwA6wAYI8JtEU1HRwcg1 wqBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9UtTA07+ovkVPuqADDz8KHdN3P0Obiq1tBGNc/CD1BU=; b=Zf35X7Ps1sLCQYwKmZL20E7wv4qstCl76O07cnU09qTUDXMsQBex9J/5Jkyvb4MuBI CNCN9RW3a6CUS0aYXO7QE2/BoHs1rma1MFgT8Gt4T+3LzB2Iw+aCpeaJo52X1bJ/MaZt zcEve93nSQt/y8q4PIA+5kLFQA3MFbOxMwDBJs4Se9PoB/Vc9+xXGHYiO4I39huZJ5+D co0OZlnxqsYRyrWa5sRmVp3De/Y2fsKIhXOp0x0OfGGxUNrfJGk7mY9/1d1+3ZpKmSFX R07qXeUDc9Gtph35gU6YH9chAjDXjHOzwUlTqrihAn9KGz7PxFOhm37pXu73C3Qo+N80 ZoVw== X-Gm-Message-State: AD7BkJLvdZ+HKTy3tZNXSphf2E1bEKlR/o6CGW6d5GwYJaRTzT5bVXNlrmsqMj+yBdbXXgVA75AKN5DA25zCtA== MIME-Version: 1.0 X-Received: by 10.112.170.68 with SMTP id ak4mr2911792lbc.94.1457717677580; Fri, 11 Mar 2016 09:34:37 -0800 (PST) Received: by 10.112.132.65 with HTTP; Fri, 11 Mar 2016 09:34:37 -0800 (PST) In-Reply-To: <017301d17bb9$288005e0$4001a8c0@gateway.2wire.net> References: <017301d17bb9$288005e0$4001a8c0@gateway.2wire.net> Date: Fri, 11 Mar 2016 09:34:37 -0800 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c259a85b17b9052dc95862 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] action and mandatory node 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, 11 Mar 2016 17:34:42 -0000 --001a11c259a85b17b9052dc95862 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 11, 2016 at 9:11 AM, t.petch wrote: > Given > > container... list... action > > with the usual twiddly brackets, and a separate mandatory data node > alongside the list in the top level container, is there a requirement to > include that mandatory data node in the XML RPC? > > 6020bis s.7.15.2 says > > " The "action" element contains an hierarchy of nodes that identifies > the node in the datastore. It MUST contain all containers and list > nodes from the top level down to the list or container containing the > action. " > > which suggests, without quite clearly telling me, that it is only the > nodes in the direct path from the top level that have to be included, > not any off to one side in the tree. > > If that is correct, I suggest > > OLD > "It MUST contain all containers and list > nodes from the top level down to the list or container containing the > action. " > NEW > " It MUST contain all containers and list > nodes in the direct path from the top level down to the list or > container containing the action (node). " > > The more precise term in YANG Xpath would be "ancestor data nodes" > Tom Petch > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c259a85b17b9052dc95862 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 11, 2016 at 9:11 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
Given

container... list... action

with the usual twiddly brackets, and a separate mandatory data node
alongside the list in the top level container, is there a requirement to include that mandatory data node in the XML RPC?

6020bis s.7.15.2 says

" The "action" element contains an hierarchy of nodes that i= dentifies
=C2=A0 =C2=A0the node in the datastore.=C2=A0 It MUST contain all container= s and list
=C2=A0 =C2=A0nodes from the top level down to the list or container contain= ing the
=C2=A0 =C2=A0action.=C2=A0 "

which suggests, without quite clearly telling me, that it is only the
nodes in the direct path from the top level that have to be included,
not any off to one side in the tree.

If that is correct, I suggest

OLD
"It MUST contain all containers and list
=C2=A0 =C2=A0nodes from the top level down to the list or container contain= ing the
=C2=A0 =C2=A0action.=C2=A0 "
NEW
" It MUST contain all containers and list
=C2=A0 =C2=A0nodes in the direct path from the top level down to the list o= r
container containing the=C2=A0 action (node).=C2=A0 "


The more precise term in YANG Xpath wo= uld be "ancestor data nodes"

=C2=A0
Tom Petch



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

--001a11c259a85b17b9052dc95862-- From nobody Fri Mar 11 09:59:34 2016 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 9AB4312D62E; Fri, 11 Mar 2016 09:59:30 -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.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311175930.27595.10104.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 09:59:30 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-07.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: Fri, 11 Mar 2016 17:59:30 -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-07.txt Pages : 27 Date : 2016-03-11 Abstract: This document describes a data model of Access Control List (ACL) basic building blocks. 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-07 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 Fri Mar 11 15:40:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B38D12DD87 for ; Fri, 11 Mar 2016 15:40:13 -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, HTML_MESSAGE=0.001, 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 gpZpagjayzk1 for ; Fri, 11 Mar 2016 15:40:10 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2529312DD93 for ; Fri, 11 Mar 2016 15:40:08 -0800 (PST) Received: from [166.170.46.50] (helo=latte) by cappuccino.rob.sh with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1aeWeq-0004ZM-2l; Fri, 11 Mar 2016 23:39:48 +0000 Date: Fri, 11 Mar 2016 16:40:01 -0700 From: Rob Shakir To: Ladislav Lhotka , netmod@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Airmail Beta (352) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="56e35751_2bd8925_8142" Archived-At: Subject: Re: [netmod] 'Namespace Qualified' in draft-ietf-netmod-yang-json-08 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, 11 Mar 2016 23:40:13 -0000 --56e35751_2bd8925_8142 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thanks Lada and others for the responses here. Much clearer to me. r. On 4 March, 2016 at 5:05:03 AM, Ladislav Lhotka (lhotka=40nic.cz) wrote: Hi Rob, =20 Rob Shakir writes: =20 > Hi NETMOD, =20 > =20 > I am in the process of implementing draft-ietf-netmod-yang-json=E2=80=93= 08, and had some queries as to the content. Hopefully there is some misun= derstanding on my part, or it helps to clean up the text for future peopl= e reviewing/implementing. =20 > =20 > The phrase =E2=80=98namespace-qualified=E2=80=99 seems to have some amb= iguity through the document. =46or example, in the case that we have two = modules: =20 > =20 > module mod-a =7B =20 > prefix =22pfx-a=22; =20 > namespace =22http://a.tld=22; =20 > =20 > container container-a =7B =20 > leaf leaf-a =7B =20 > type string; =20 > =7D =20 > =20 > leaf ref-a =7B =20 > type identityref =7B =20 > base SOME=5FIDENTITY; =20 > =7D =20 > =7D =20 > =7D =20 > =7D =20 > =20 > module mod-b =7B =20 > prefix =22pfx-b=22; =20 > namespace =22http://b.tld=22; =20 > =20 > container container-b =7B =20 > leaf leaf-b =7B =20 > type string; =20 > =7D =20 > =20 > leaf ref-b =7B =20 > type identityref =7B =20 > base SOME=5FIDENTITY; =20 > =7D =20 > =7D =20 > =7D =20 > =7D =20 > Then, AIUI, the encoding needs to specify the names of the modules for = =20 > both container-a and container-b (since they sit at the =20 > root; and are in different namespaces) - so we encode =20 > these as JSON objects named mod-a:container-a and =20 > mod-b:container-b as per Section 4 of the document. =20 Correct. =20 > =20 > In this case, we never use the actual namespace (i.e., http://a.tld =20 > and http://b.tld) so calling it =E2=80=98namespace qualified=E2=80=99 a= ppears =20 > ambiguous. Should it be simply referred to as =E2=80=98module-qualified= =E2=80=99=3F =20 Namespaces (=3D sets of names) as defined by YANG are =20 encoding-independent. However, XML and JSON use different namespace =20 identifiers. XML uses naturally the mechanism of =5BXML-NAMES=5D, i.e. na= mespace URIs =20 and references via declared prefixes. JSON in general doesn't support =20 namespaced member names, but we could conveniently use the module name =20 as the namespace identifier. So this is what Sec. 4 defines: =20 The name of a module determines the namespace of all data node names =20 defined in that module. If a data node is defined in a submodule, =20 then the namespace-qualified member name uses the name of the main =20 module to which the submodule belongs. =20 This is then later extended to other named entities such as identities. =20 > =20 > Secondarily, the example in Section 6.8 does not actually use the name = =20 > of the module, it rather uses the prefix (if for the interface-type =20 > leaf). This doesn=E2=80=99t seem to be explained anywhere within the te= xt. Is =20 > this a mistake=3F =20 No, it's correct. YANG adopted the XML namespace rules, so declared =20 prefixes are used in YANG modules. The JSON-encoded name of the identity = =20 uses the rules of the yang-json document, i.e. module name as the =20 namespace identifier. =20 > It seems to me that using the module name consistently throughout the =20 > encoding is preferable, since this cannot be different in a number of =20 > places; and isn=E2=80=99t as long as the namespace value to make readab= ility =20 > worse. =20 Module name is used consistently in JSON encoding, but we have to use =20 YANG rules when dealing with YANG modules. =20 It is somewhat confusing but I believe this is the best solution we =20 could come up with. =20 > =20 > I also didn=E2=80=99t understand why an identityref value encodes the =20 > namespace in the actual value=3F It seems like the =E2=80=9Cbase=E2=80=9D= of the =20 > identityref should qualify all possible values here; with the only =20 > case that we would ever need this is one where we have: =20 I think Per explained this part nicely. =20 Thanks, Lada =20 > =20 > leaf some-reference =7B =20 > type union =7B =20 > type identityref =7B =20 > base =22a=22; =20 > =7D =20 > type identityref =7B =20 > base =22b=22; =20 > =7D =20 > =7D =20 > =7D =20 > And a and b both define a value with the same name (where one needs the= prefix to be able to refer to the b version). =20 > =20 > Thanks, =20 > r. =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 > netmod mailing list =20 > netmod=40ietf.org =20 > https://www.ietf.org/mailman/listinfo/netmod =20 -- =20 Ladislav Lhotka, CZ.NIC Labs =20 PGP Key ID: E74E8C0C =20 --56e35751_2bd8925_8142 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Dear Yang = specialists,

 

I have a question concerning what is possible in must = statements in case of recursive models.  Assume the following = “limits” depending on a plugable board (just arbitrary = examples):

 

+------------+---------+----------------+

| Board type = | # ports | max VLAN ports |

+------------+---------+----------------+

|      A     |  = 8      |  = 80            = |

|      = B     |  4      = |  = 40            = |

|      = C     |  2      = |  = 40            = |

|      = D     |  16     |  100 =           |<= /span>

+------------+---------+----------------+

 

The entity model = is a recursive one where you start from the root (below is just an = example to depict the nature of the problem):

 

/entity

    | = [Contains]

    + chassis

        | = [contains]
        + = Board

    =          | = [Contains]

       =       +  Port

          =        |

           &= nbsp;     | reference to = /interfaces/interface

 

/interfaces

     = |

     + = interface

          | various = augments depending on the if-type but

          | no = “back-reference” to port in /entity

 

Problem is = two-fold:

-          = Recursiveness needs to be expressed in the XPATH = statement: when a client wants to create a port it needs to perform a = check based on the board identification.  So in case of Board A the = maximum number of ports that the client should be allowed to make is 8, = for B it is 4, for D it is 16

-          = From the interfaces table (for the VLAN port = case) there is no back reference to the entity table, so how would one = retrieve the “board” on top of which this interface has been = defined in order to pick up the max VLAN ports value if we would like to = perform a must check in this (as the value depends on the board = identification).  So 100 in case the interface is defined and an = port of board D, 40 in case the interface is defined on a port of board = C (or B).  Should we then have to add a backwards leafref to the = port in /entity (otherwise this must statement will end up in a complete = /entity table look-up to find the port leafref matching the instance = from /interfaces)?

 

Is this = something that can be expressed in YANG with XPATH expressions?  = How will that look like (and will that be understandable…)?  = Don’t we need XQUERY to do this (which is not part of = YANG)?

What is the performance of = this (so in fact what is the impact on the server)?  Is it = recommended to do it that way and if not: how would you suggest to model = these kind of restrictions?

 

Thanks in = advance.

 

Best regards - = Vriendelijke groeten,

Bart = Bogaert

 

------=_NextPart_001_005B_01D17E99.4B059C50-- ------=_NextPart_000_005A_01D17E99.4B059C50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzE1MDgwMTQyWjAjBgkqhkiG9w0B CQQxFgQU1hrxLfMAz/AsX9g6H/AeYFpMEDwwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQAb T4H1eapE3IONBHxK2V6hLB2HIPds7WmonRfTlHT5PlveaWqJYgk7cU7qXka087ogg/thTPulEaMV kCuHO9dr7b6Hdnfyh3NDyhTKDbq45U0e6MlYmSTmOqbXiUNPA6DlEGDdny9bM2H4N7ebZ3/q7hgd wEk6Ooteq0bjE8i23ujiMCGVJ7wx1nPuBKwhehuYWNkZwTFCTo+7lbsJ+TT13fvCOSSmXjWchUaJ g/xkTVAeYODTGHn/6XSeMk93tmtwSarGBHo40Lc2RpA3Kt64NYiP1W8CQzgddHH1zhFxBqrj5t06 N4BhfJq6sUGTKARItDQrdc+gdiRAoaaCegOIAAAAAAAA ------=_NextPart_000_005A_01D17E99.4B059C50-- From nobody Tue Mar 15 01:58:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2B512D970 for ; Tue, 15 Mar 2016 01:58:57 -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 UReSjntZBmFp for ; Tue, 15 Mar 2016 01:58: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 D41F712D90B for ; Tue, 15 Mar 2016 01:58:55 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id CC6F91AE03CA; Tue, 15 Mar 2016 09:58:53 +0100 (CET) Date: Tue, 15 Mar 2016 09:58:55 +0100 (CET) Message-Id: <20160315.095855.447134777226792207.mbj@tail-f.com> To: bart.bogaert@nokia.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] Question on modeling of restriction using YANG capabilities 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, 15 Mar 2016 08:58:57 -0000 Hi, "Bogaert, Bart (Nokia - BE)" wrote: > Dear Yang specialists, > > > > I have a question concerning what is possible in must statements in case of > recursive models. What do you mean when you write "recursive model"? > Assume the following "limits" depending on a plugable > board (just arbitrary examples): > > > > +------------+---------+----------------+ > > | Board type | # ports | max VLAN ports | > > +------------+---------+----------------+ > > | A | 8 | 80 | > > | B | 4 | 40 | > > | C | 2 | 40 | > > | D | 16 | 100 | > > +------------+---------+----------------+ > > > > The entity model is a recursive one where you start from the root (below is > just an example to depict the nature of the problem): > > > > /entity > > | [Contains] > > + chassis > > | [contains] > + Board > > | [Contains] > > + Port > > | > > | reference to /interfaces/interface > > > > /interfaces > > | > > + interface > > | various augments depending on the if-type but > > | no "back-reference" to port in /entity > > > > Problem is two-fold: > > - Recursiveness needs to be expressed in the XPATH statement: when > a client wants to create a port it needs to perform a check based on the > board identification. So in case of Board A the maximum number of ports > that the client should be allowed to make is 8, for B it is 4, for D it is > 16 I can't answer this until I know what you mean with "recursive model", see above. > - From the interfaces table (for the VLAN port case) there is no > back reference to the entity table, so how would one retrieve the "board" on > top of which this interface has been defined in order to pick up the max > VLAN ports value if we would like to perform a must check in this (as the > value depends on the board identification). So 100 in case the interface is > defined and an port of board D, 40 in case the interface is defined on a > port of board C (or B). Should we then have to add a backwards leafref to > the port in /entity (otherwise this must statement will end up in a complete > /entity table look-up to find the port leafref matching the instance from > /interfaces)? > > > > Is this something that can be expressed in YANG with XPATH > expressions? Probably. > How > will that look like (and will that be understandable.)? Don't we need > XQUERY to do this (which is not part of YANG)? > > What is the performance of this (so in fact what is the impact on the > server)? Is it recommended to do it that way and if not: how would you > suggest to model these kind of restrictions? The performance is implementation-dependent. An implementation that uses a plain XPath evaluator might be slow if you have 1000s or 10000s "entities". Some implementations supports specification of secondary indexes to speed up things like this. And some implementations lets you (or forces you) to implement the constraint yourself in code. It is not a good idea to add "back-references" to the model in order to solve implementation-specific problems. /martin > > > > Thanks in advance. > > > > Best regards - Vriendelijke groeten, > > Bart Bogaert > > > From nobody Tue Mar 15 02:03:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB0112D90B for ; Tue, 15 Mar 2016 02:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 IRXlS2oFtXUf for ; Tue, 15 Mar 2016 02:03:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 174E512D940 for ; Tue, 15 Mar 2016 02:03:40 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 756F38282AE5; Tue, 15 Mar 2016 09:03:37 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2F93cpn026342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Mar 2016 09:03:38 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u2F93Was009508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Mar 2016 10:03:38 +0100 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 15 Mar 2016 10:02:43 +0100 From: "Bogaert, Bart (Nokia - BE)" To: EXT Martin Bjorklund Thread-Topic: [netmod] Question on modeling of restriction using YANG capabilities Thread-Index: AdF+kOk7Mu/8N02FSMa3htoCCAR63////ziA///u5DA= Date: Tue, 15 Mar 2016 09:02:43 +0000 Message-ID: References: <20160315.095855.447134777226792207.mbj@tail-f.com> In-Reply-To: <20160315.095855.447134777226792207.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D5_01D17EA1.CF802010" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Question on modeling of restriction using YANG capabilities 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, 15 Mar 2016 09:03:46 -0000 ------=_NextPart_000_00D5_01D17EA1.CF802010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Martin, Thanks for the reply. This is from the entity model: $ pyang -f tree ietf-entity.yang -p .. module: ietf-entity +--ro entity-state | +--ro last-change? yang:date-and-time | +--ro physical-entity* [name] | +--ro name string | +--ro class identityref | +--ro physical-index? int32 {entity-mib}? | +--ro description? string | +--ro contained-in* -> ../../physical-entity/name | +--ro contains-child* -> ../../physical-entity/name | +--ro parent-rel-pos? int32 | +--ro hardware-rev? string | +--ro firmware-rev? string So contained-in and contains-child define a containment of entities within entities, hence my reference to recursive Best regards - Vriendelijke groeten, Bart Bogaert -----Original Message----- From: EXT Martin Bjorklund [mailto:mbj@tail-f.com] Sent: 15 March 2016 09:59 To: Bogaert, Bart (Nokia - BE) Cc: netmod@ietf.org Subject: Re: [netmod] Question on modeling of restriction using YANG capabilities Hi, "Bogaert, Bart (Nokia - BE)" wrote: > Dear Yang specialists, > > > > I have a question concerning what is possible in must statements in > case of recursive models. What do you mean when you write "recursive model"? > Assume the following "limits" depending on a plugable board (just > arbitrary examples): > > > > +------------+---------+----------------+ > > | Board type | # ports | max VLAN ports | > > +------------+---------+----------------+ > > | A | 8 | 80 | > > | B | 4 | 40 | > > | C | 2 | 40 | > > | D | 16 | 100 | > > +------------+---------+----------------+ > > > > The entity model is a recursive one where you start from the root > (below is just an example to depict the nature of the problem): > > > > /entity > > | [Contains] > > + chassis > > | [contains] > + Board > > | [Contains] > > + Port > > | > > | reference to /interfaces/interface > > > > /interfaces > > | > > + interface > > | various augments depending on the if-type but > > | no "back-reference" to port in /entity > > > > Problem is two-fold: > > - Recursiveness needs to be expressed in the XPATH statement: when > a client wants to create a port it needs to perform a check based on > the board identification. So in case of Board A the maximum number of > ports that the client should be allowed to make is 8, for B it is 4, > for D it is > 16 I can't answer this until I know what you mean with "recursive model", see above. > - From the interfaces table (for the VLAN port case) there is no > back reference to the entity table, so how would one retrieve the > "board" on top of which this interface has been defined in order to > pick up the max VLAN ports value if we would like to perform a must > check in this (as the value depends on the board identification). So > 100 in case the interface is defined and an port of board D, 40 in > case the interface is defined on a port of board C (or B). Should we > then have to add a backwards leafref to the port in /entity (otherwise > this must statement will end up in a complete /entity table look-up to > find the port leafref matching the instance from /interfaces)? > > > > Is this something that can be expressed in YANG with XPATH > expressions? Probably. > How > will that look like (and will that be understandable.)? Don't we need > XQUERY to do this (which is not part of YANG)? > > What is the performance of this (so in fact what is the impact on the > server)? Is it recommended to do it that way and if not: how would > you suggest to model these kind of restrictions? The performance is implementation-dependent. An implementation that uses a plain XPath evaluator might be slow if you have 1000s or 10000s "entities". Some implementations supports specification of secondary indexes to speed up things like this. And some implementations lets you (or forces you) to implement the constraint yourself in code. It is not a good idea to add "back-references" to the model in order to solve implementation-specific problems. /martin > > > > Thanks in advance. > > > > Best regards - Vriendelijke groeten, > > Bart Bogaert > > > ------=_NextPart_000_00D5_01D17EA1.CF802010 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzE1MDkwMjQwWjAjBgkqhkiG9w0B CQQxFgQU+FRuWUs19RkIXJJxUada4aLyjNMwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQAy I6PWATrE3sj+qoCxrlLmo62Ih/IyS2EnkeWH94suiaws3xY4FUMJgMBbklWLRkKgZVN6Ya4Mj/OO P43kmwPdEk7eGk+zeHZcBhO+pMCtI/EqGe6OkdOYHTXkv1SqmLzRrazStZjXdB73b5M8/zMaqNwy oijbfLNVnUfRbfmAajzTuxTHTxHmsnWQhwZWsItAFCuLEym4NsDY2fscTUsmGwDjcHlUbMe96AAv T/jCAeYsxDWOcTIE4OdtKle25tXmwbbZjJ7Y5vo2G9wvlLva2quAE68TaMGqiF1WtGu5bFoDBLXV +a/l+v2zi7fePYmaB24bctUMyBz+AgSqslEyAAAAAAAA ------=_NextPart_000_00D5_01D17EA1.CF802010-- From nobody Tue Mar 15 20:59:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561DB12D810 for ; Tue, 15 Mar 2016 20:59: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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 k60cxkY4RVs8 for ; Tue, 15 Mar 2016 20:59:54 -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 274B212D7D2 for ; Tue, 15 Mar 2016 20:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2145; q=dns/txt; s=iport; t=1458100794; x=1459310394; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=5UlK2GkzhrzZzlIArKuoorUkp96XrCvqMIyg0ZLaUUc=; b=OxBqvRhyMrXYp4OQSwAKKwzsnXujl2REZly37umCcSl+eHpHK4dPf5HQ IKf8aWx6Glxh1KhqatKo+noVZtZEKNcK+ShN2bBLdF1J0UwC68eX5hhV6 efAXOqhafy+zA4jytK/SVp+8oQ9NRrWuRzSvPjw5ibF7yzfHw8DbkSTjd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmBACP2ehW/xbLJq1ehQ68F4gaAQEBA?= =?us-ascii?q?QEBZSeESIELAYEAJgEEARqIH78EAQEBBwEBAQEchhqNNwWHYIYSiV0BjXmPDI5?= =?us-ascii?q?+AWKDZYoUJRZ+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,342,1454976000"; d="scan'208";a="634474440" 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; 16 Mar 2016 03:59:52 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2G3xpwb008868 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 03:59:51 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 23:59:50 -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.1104.009; Tue, 15 Mar 2016 23:59:50 -0400 From: "Eric Voit (evoit)" To: "netmod@ietf.org" , "Martin Bjorklund (mbjorklu)" , Lou Berger , "lhotka@nic.cz" , "Acee Lindem (acee)" , "Alexander Clemm (alex)" , "Ambika Prasad Tripathy (ambtripa)" Thread-Topic: Differentiating the types of Mount Thread-Index: AdF/OD2NJ3Cq4cCSQLyujReGzdHIoQ== Date: Wed, 16 Mar 2016 03:59:50 +0000 Message-ID: <84d0c3c5331c4b5e9d0883f890a87a40@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.231] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [netmod] Differentiating the types of Mount 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, 16 Mar 2016 03:59:56 -0000 To help differentiate between concepts and drafts, below are strawman defin= itions for the various types of Mount which we have been discussing over th= e last year in Netmod. Thoughts/suggestions? YANG Mount ---------------- =20 Definition: An abstracted term for a mechanism that a parent YANG model can= use to link in YANG information defined or located elsewhere. =20 Purpose: Provides model flexibility by enabling the growth of YANG trees vi= a an explicit reference to other YANG information and structures.=20 Schema Mount ------------------- Definition: A type of YANG Mount where a new YANG Schema is constructed by = inserting any existing YANG schema under a parent model within a local data= store. Objects populated into the mounted schema are only instantiated as= part of the parent's hierarchy. =20 Purpose: This allows reuse of existing model definitions to facilitate impl= ementation of alternative model structures in multiple contexts. In effect= , it allows to define models which reuse other model definitions as if they= had been defined as a special kind of grouping. =20 Alias Mount --------------- Definition: A type of YANG Mount=A0which allows to=A0provide an alternative= path to local objects of YANG data.=A0=A0 Purpose: Enables=A0multiple concurrent=A0context specific object models wit= hout replicating instance data.=A0 This allows programmers access common ob= jects via the hierarchies that best make sense to them. (E.g. Symbolic link= in a file system.) Peer Mount -------------- Definition: A type of YANG Mount which enables=A0access to=A0remote objects= =A0as if they were contained=A0within a local datastore dynamically. Purpose: Provides an=A0on-demand virtual federated datastore that provides = visibility and location transparency of YANG-data across device boundaries.= =A0=A0Retains clear authoritative ownership.=A0=A0Eliminates many tasks=A0o= therwise=A0needed to synchronize,=A0reconcile=A0aggregate, validate=A0infor= mation replicated across these devices. (E.g. File share to remote host in = a file system.) Thanks,=20 Eric From nobody Wed Mar 16 04:23:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B79912D535 for ; Wed, 16 Mar 2016 04:23:39 -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 HG_cOt6SekOF for ; Wed, 16 Mar 2016 04:23: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 57A2312D540 for ; Wed, 16 Mar 2016 04:23:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 13BA322A0; Wed, 16 Mar 2016 12:23:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hlf95KC6oKzh; Wed, 16 Mar 2016 12:23:21 +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, 16 Mar 2016 12:23:33 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 30F2520043; Wed, 16 Mar 2016 12:23:33 +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 h41iYsQlC8SI; Wed, 16 Mar 2016 12:23: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 1BE732003D; Wed, 16 Mar 2016 12:23:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 092303A37C6B; Wed, 16 Mar 2016 12:23:30 +0100 (CET) Date: Wed, 16 Mar 2016 12:23:29 +0100 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Message-ID: <20160316112329.GB39598@elstar.local> Mail-Followup-To: "Eric Voit (evoit)" , "netmod@ietf.org" , "Martin Bjorklund (mbjorklu)" , Lou Berger , "lhotka@nic.cz" , "Acee Lindem (acee)" , "Alexander Clemm (alex)" , "Ambika Prasad Tripathy (ambtripa)" References: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" , "Martin Bjorklund \(mbjorklu\)" Subject: Re: [netmod] Differentiating the types of Mount 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, 16 Mar 2016 11:23:39 -0000 On Wed, Mar 16, 2016 at 03:59:50AM +0000, Eric Voit (evoit) wrote: > To help differentiate between concepts and drafts, below are strawman definitions for the various types of Mount which we have been discussing over the last year in Netmod. Thoughts/suggestions? > > YANG Mount > ---------------- > Definition: An abstracted term for a mechanism that a parent YANG model can use to link in YANG information defined or located elsewhere. > Purpose: Provides model flexibility by enabling the growth of YANG trees via an explicit reference to other YANG information and structures. Trying to rewrite the definition to be more consistent with existing terminology: The abstract concept of incorporating a YANG-defined data tree (the mounted data tree) into a existing YANG-defined data tree (the parent data tree). Well, this is not really correct, perhaps we have to just say 'tree' instead of 'data tree' since a schema mount (as I understand it) seems to incorporate a schema tree into another schema tree while the other two mounts incorporate a data tree into a data tree. So perhaps the general definition is something like this: The abstract concept of incorporating a YANG-defined data tree or schema tree (the mounted data or schema tree) into a existing YANG-defined data tree or schema tree (the parent data tree). The schema mount then essentially removes data tree and the other two mounts remove the schema tree from this definition. Is your alias mount simply a special case of a peer mount where the peer is local? Or is there more to it? In other words, would it be reasonable to think of the terms in this way: +-> schema (tree) mount | mount -> | +-> local data tree (alias) mount +-> data (tree) mount -> | +-> remote data tree (peer) mount /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 16 05:30:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C4312D8C9 for ; Wed, 16 Mar 2016 05:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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] 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 AoLvHJfUfTz7 for ; Wed, 16 Mar 2016 05:30:45 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0110.outbound.protection.outlook.com [104.47.2.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 C3BBC12D91B for ; Wed, 16 Mar 2016 05:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=A3njwwbwt0nTrFbjGMYkvB1/rcRa0vUdKeKPdZpVRfc=; b=ZCbmcQGOG9afJhTGpi3YB5DIJj+SB2KRsUTtpGKJFbSGH+RI8PqUEYCz1dINAbwU+ANvoz0nfSHkKJpznxcskQvEFX+USHWzxzsIWoB7NwyOXRW5iasY9R7KtvNziAER74n5eLcHsyKjqmbJMTQ03Z0S2aBDaO3xF1nfqqLWRfM= 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 (81.132.199.159) by VI1PR07MB1631.eurprd07.prod.outlook.com (10.166.142.149) with Microsoft SMTP Server (TLS) id 15.1.443.7; Wed, 16 Mar 2016 12:30:34 +0000 Message-ID: <01bd01d17f7f$116bb2e0$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder , STUART VENTERS References: <1220E2C537595D439C5D026E83751866E7B4940C@ex-mb1.corp.adtran.com> <20160304165219.GA36535@elstar.local> Date: Wed, 16 Mar 2016 12:26:17 +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: [81.132.199.159] X-ClientProxiedBy: AM4PR02CA0006.eurprd02.prod.outlook.com (25.165.239.144) To VI1PR07MB1631.eurprd07.prod.outlook.com (25.166.142.149) X-MS-Office365-Filtering-Correlation-Id: 75b94a10-4381-4043-dd9b-08d34d96c5b6 X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 2:qnic1fzRMfPbbv/QqObBIfSsW1+U7M+rH0vr9452I8HQhAlPf8DXLVhIx/9JRBK/qc9mPSBV2U0BAzLt8He4hUsyOaCrCgS5ursEXOHXObGTMq34xZzt2g9d2ykH1AoHfwLjsUwgXia3mXyb9X+Y/eETwur9Bz6xua7BFbSbts0kmPkkTOjRRVn7u1R8OTc5; 3:x0R2sVtL62SskxpDSS05Uow+bMDV9T/JXqDZLq3ImWNHF7rw/WrD51akp6gityc9x0GvI6gWxlaxiVt0BeyBk6aUq8AKgxZsjFtH4FE4/lUwcVTncs1d0vdCb5lyTrnQ; 25:5hbfwlwvPN3eNlLY8r+YZWshF62VnF9tueqLxvjUeV27yGVejQZ9FcHaA/WUDNKPaOuzWQKsYsESbSWY7xRawAZS8Ht8KvVUPcoxeqjAV/3q4WazQw3VoXnsbQUUI2m+DKYkvy9vT5/G+Fit5pj98tbkJOw1o6Ee0u4CorFgWUeu9MwELS+JfxjM+7Gk7rngcAKYTU99OT0Ebp7a+aelMeNwFpcI7/18tSxHJN4JCdnMcZ7aaPZ+ixyMAiwC5FxSLpg1JfivhlHVNjk1ljquukakyBS4XWX+HapqFxwDiQsr/SnG5Tv5wE12fxvenQqh X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1631; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR07MB1631; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1631; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 4:Qhmd++SdV81jSRTIcYkACuF0epIXIu00GxARpYmtdGa4BiRfUlh9sPzwA+ZcD62YR+FaUvuSJt1y+8/xzrQDAxUH9HaLJqlQt3fP9IlXtEqpYxNf5WBjqqoz53QickVsXMr3cOMD0C7YEgImqojImn9DBLQjSRUzVtujD1S4TqLvQ60atcPadbMBNBoVkm/o8FpAzGnkMJ6iL3Q4K1dPmxnIhitgLDME95V8N/v6PJ4N/EwHHAAAFEdIArM3E+lj/x6BzkS2h5zzRemrUuWKBN2Fb5FEifkPZzDG6uTsI6eIFKOop2JlhkfNrI/Ta1eQJvIvTGvvOgntKjRFVvOlThk5eTr6hZYxoBfLKb1SANEe2VdQtyx94x4D4qJTczld X-Forefront-PRVS: 08831F51DC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(24454002)(377454003)(586003)(4326007)(230700001)(61296003)(3846002)(6116002)(50986999)(47776003)(23756003)(5004730100002)(76176999)(86362001)(81166005)(2906002)(84392002)(50226001)(66066001)(33646002)(189998001)(19580395003)(81816999)(42186005)(5008740100001)(230783001)(50466002)(81686999)(44736004)(62236002)(116806002)(44716002)(5001770100001)(77096005)(92566002)(19580405001)(1096002)(15975445007)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1631; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR07MB1631; 23:Wqd7DU4HU8Znk4jDN85Yg+ENCghQ1I5ZH+v3hol?= =?iso-8859-1?Q?JLkIcdfX0fRmGD6E7RjHDOjfb+pqEeh+ydDdXFYwmzAwZqnPwrwFnlM7LK?= =?iso-8859-1?Q?kasvFYiBMIjE8rpbNul++tM7QmnV8xX+/np5LqkMpxojG6aaLOodC58NKi?= =?iso-8859-1?Q?GoBlaDEtGbFlEAbX5KNn+47SrPMaG+X9gvjZZnf0M9veTxWQ2nxh+xN/mQ?= =?iso-8859-1?Q?cqTXLyWpbDEc5RW3XA27BUzQfVqA2EkF9oMpWxS81Z+duosT1qMFgsUXx6?= =?iso-8859-1?Q?AttdQQmUQ92qeQPxvyeLdK5A8gv4cuSNRVONPypAWcDTT33JgKwOdiEAqQ?= =?iso-8859-1?Q?oSvoSeCsaYCAfEpN0BeX9ZWYC2fm/KPOaPgtdjy2EJhoLJwA8m2iHt0SF9?= =?iso-8859-1?Q?yoSMWCpfJAFfqu+Y9Guf5AJjrFK4I/2KoANa3TqT0dxCKkX+zcfTglmPlN?= =?iso-8859-1?Q?vAVTjU0KzAB6YyDb9z2u5WGTOTut9qp1n3OELl/mO5woTQ9aBkNbuCIjQ5?= =?iso-8859-1?Q?6DO2GIBkSVY3mQONOYDDw8FCpnxSO6EAZ+gSKUAbkP3WfeXXl+q9QQcq6b?= =?iso-8859-1?Q?ALUjbwr/dyCUbyp0LleOGMBtTcqNwFNdF29EB3fk8BQQ+6xFrU/N4utWjP?= =?iso-8859-1?Q?WZQnw441PRWJOfCGi/DgsEiE7q+t0FlYUv09X7MM9z+7sUWlImw3dzB+Td?= =?iso-8859-1?Q?G8JKA31IALg6dsAqF+LISmgCyFkbCStp9UuEL+wTMcey4NIi8BARIsSZtk?= =?iso-8859-1?Q?8n4JcrCZ5ooBOHu54Q5jr4esVf4S7mkfOxMY4z5XLigcdmNMUnkY/DGM6r?= =?iso-8859-1?Q?0eLOX2k8QI9lSbwKymFD0V3S1mjtZwH27RLpLVEravIJ7K6kn+N6SeFla4?= =?iso-8859-1?Q?K2k0LvG0TKVdeomk5ZjdG3b7/gWbbCifNoF92kl2qMpTBHVP5nPKg4bxO1?= =?iso-8859-1?Q?9YBzpAcNhAkRTyQyiIlQ+jCgdqTJJuqAy4QtYiVWViPCXC9Gj3p8ed0Nu1?= =?iso-8859-1?Q?L/pqjc8SBcNx5NfR8dEK8dV3giP5wQJH/YgOlYB3cTZTJ5sNBq8VD+tmtj?= =?iso-8859-1?Q?rpoMQqJ16n9ilOmA+jVRTFEXBMkvzOV4Qc2mR9KQ0FIqQ3fypekhDaZtG1?= =?iso-8859-1?Q?Ji6978phSWWEyi/cIjfQJ1TwNEBSvUDPV+BsEBKgWxQUwc8JuWvZHuxCPC?= =?iso-8859-1?Q?1E4EnbNpjEf6tqD6PFx62Wa1yARr0g2ZQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 5:bVb+0ze/Nun7fGXITvQAfhe6RRhRGgDLthqb1IcVRdInAGFMXOu0B4wcsEn8b4YLLzyjuAIN4IoczzfSfYRA6TIPvoSFDzkAqxxGLRqy8Clvarf4ZwvRsQqwEkee5DHey4yWw3TBTbCxWHATWl0lBQ==; 24:jhNdTUa03u0qZJcfkztgihWHJ5xfSEQEAP+oAzOCR3/dm6khXWXmKetBDf+A1+3J4w+FXCsUzLjPjTfxwWnwhNZONMftI99UPK5gNFJUibk= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2016 12:30:34.3932 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1631 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification 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, 16 Mar 2016 12:30:48 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Sent: Friday, March 04, 2016 4:52 PM > On Fri, Mar 04, 2016 at 04:25:37PM +0000, STUART VENTERS wrote: > > > > 2) Allow the 'rpc' and 'notification' nouns to be used in other places in the schema tree besides at the top module level. > > This is already part of YANG 1.1. Looking at rfc6020bis-11 s.14, I see 'notification-stmt' appearing in many places so indeed it is allowed in other places but only see 'rpc-stmt' appear in 'body-stmts' . Which, if I understand aright, means that 'rpc-stmt' can still only appear at the top level. Tom Petch > /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 16 07:08:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CAE12D96D for ; Wed, 16 Mar 2016 07:08:34 -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 a62zaOerxZ_A for ; Wed, 16 Mar 2016 07:08: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 1663F12D5A8 for ; Wed, 16 Mar 2016 07:08: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 CC50F229C; Wed, 16 Mar 2016 15:08:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cPPGjc_8XpW4; Wed, 16 Mar 2016 15:08: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; Wed, 16 Mar 2016 15:08:31 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21A242004E; Wed, 16 Mar 2016 15:08:31 +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 CEKzT0nI60GD; Wed, 16 Mar 2016 15:08: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 E8F9320047; Wed, 16 Mar 2016 15:08:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BAB333A37DEE; Wed, 16 Mar 2016 15:08:28 +0100 (CET) Date: Wed, 16 Mar 2016 15:08:28 +0100 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20160316140828.GC39819@elstar.local> Mail-Followup-To: "t. petch" , STUART VENTERS , netmod@ietf.org, Martin Bjorklund References: <1220E2C537595D439C5D026E83751866E7B4940C@ex-mb1.corp.adtran.com> <20160304165219.GA36535@elstar.local> <01bd01d17f7f$116bb2e0$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01bd01d17f7f$116bb2e0$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification 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, 16 Mar 2016 14:08:34 -0000 On Wed, Mar 16, 2016 at 12:26:17PM +0000, t. petch wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > Sent: Friday, March 04, 2016 4:52 PM > > > > On Fri, Mar 04, 2016 at 04:25:37PM +0000, STUART VENTERS wrote: > > > > > > 2) Allow the 'rpc' and 'notification' nouns to be used in other > places in the schema tree besides at the top module level. > > > > This is already part of YANG 1.1. > > Looking at rfc6020bis-11 s.14, I see 'notification-stmt' appearing in > many places so indeed it is allowed in other places but only see > 'rpc-stmt' appear in 'body-stmts' . Which, if I understand aright, > means that 'rpc-stmt' can still only appear at the top level. > Yep. But there is a new action-stmt and in section 1.1 it says: o Added a new statement "action" that is used to define operations tied to data nodes. /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 16 07:58:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A851C12D6F5 for ; Wed, 16 Mar 2016 07:58: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, RCVD_IN_MSPIKE_H2=-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 rmn0JbL5aXOs for ; Wed, 16 Mar 2016 07:58:33 -0700 (PDT) Received: from s12p02o148.mxlogic.net (s12p02o148.mxlogic.net [208.65.145.71]) (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 2E77812D9AF for ; Wed, 16 Mar 2016 07:58:31 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO s12p02o148.mxlogic.net) by s12p02o148.mxlogic.net(mxl_mta-8.5.0-8) with ESMTP id 89479e65.7f28957fb700.60320.00-532.186796.s12p02o148.mxlogic.net (envelope-from ); Wed, 16 Mar 2016 08:58:32 -0600 (MDT) X-MXL-Hash: 56e974981e65aaff-e1a1ceb279fa15d044c050cc17ba983db70bf422 Received: from unknown [76.164.174.82] by s12p02o148.mxlogic.net(mxl_mta-8.5.0-8) over TLS secured channel with SMTP id 98479e65.0.59441.00-378.185844.s12p02o148.mxlogic.net (envelope-from ); Wed, 16 Mar 2016 08:58:24 -0600 (MDT) X-MXL-Hash: 56e974907868e1f6-268939e9e0ba0dfa5c0352c6c376ccea37535434 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.0266.001; Wed, 16 Mar 2016 09:58:08 -0500 From: STUART VENTERS To: 'Juergen Schoenwaelder' Thread-Topic: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification Thread-Index: AQHRf3+l7z9M94Im7kGWJzNDQhHyXp9cb3IA//+zOuA= Date: Wed, 16 Mar 2016 14:58:08 +0000 Message-ID: <1220E2C537595D439C5D026E83751866E7B4C079@ex-mb1.corp.adtran.com> References: <1220E2C537595D439C5D026E83751866E7B4940C@ex-mb1.corp.adtran.com> <20160304165219.GA36535@elstar.local> <01bd01d17f7f$116bb2e0$4001a8c0@gateway.2wire.net> <20160316140828.GC39819@elstar.local> In-Reply-To: <20160316140828.GC39819@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.118.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=LIBgNci9 c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=0eaKXOXVzoQA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=7OsogOcEt9IA:10 a=48vgC7m] X-AnalysisOut: [UAAAA:8 a=j3Z76cjpAAAA:8 a=WCc4bjrZaKS0dxqx4WEA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8] X-AnalysisOut: [oA:10 a=NWVoK91CQyQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2016031609); S=0.206(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification 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, 16 Mar 2016 14:58:37 -0000 Interesting, this highlights a concern I have with Yang. It's highlevel goals and progress are great, but at a detail level, instead of using one general purpose language construct per feature, it = seems to be evolving to use many. For a new language evolving in an old problem area, this doesn't seem right= . RFC6020bis-11 section 7.15 gives some clue as to the reasoning behind this. "The difference between an action and an rpc is that an action is tied to a node in the datastore, whereas an rpc is not." To me, this feels like a protocol or implementation issue is causing an unn= ecessary language addition. I wonder if an alternative strategy could be to say that you can use an rpc= in a node, but when you do the name of the rpc on the wire becomes some co= mbination of the node name and the rpc name? -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, March 16, 2016 9:08 AM To: t. petch Cc: STUART VENTERS; netmod@ietf.org; Martin Bjorklund Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible si= mplification On Wed, Mar 16, 2016 at 12:26:17PM +0000, t. petch wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > Sent: Friday, March 04, 2016 4:52 PM >=20 >=20 > > On Fri, Mar 04, 2016 at 04:25:37PM +0000, STUART VENTERS wrote: > > > > > > 2) Allow the 'rpc' and 'notification' nouns to be used in other > places in the schema tree besides at the top module level. > > > > This is already part of YANG 1.1. >=20 > Looking at rfc6020bis-11 s.14, I see 'notification-stmt' appearing in=20 > many places so indeed it is allowed in other places but only see=20 > 'rpc-stmt' appear in 'body-stmts' . Which, if I understand aright,=20 > means that 'rpc-stmt' can still only appear at the top level. > Yep. But there is a new action-stmt and in section 1.1 it says: o Added a new statement "action" that is used to define operations tied to data nodes. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 16 08:08:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AD312D59E for ; Wed, 16 Mar 2016 08: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 Wqok6_CFB0RX for ; Wed, 16 Mar 2016 08: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 E0B5F12D928 for ; Wed, 16 Mar 2016 08:08:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A60CF227C; Wed, 16 Mar 2016 16:08:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 468StTFg9yzM; Wed, 16 Mar 2016 16:07:47 +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, 16 Mar 2016 16:07:59 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1D1920043; Wed, 16 Mar 2016 16:07:59 +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 StrFIF2fbDze; Wed, 16 Mar 2016 16:07:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0812D2003D; Wed, 16 Mar 2016 16:07:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F09E23A37F00; Wed, 16 Mar 2016 16:07:57 +0100 (CET) Date: Wed, 16 Mar 2016 16:07:57 +0100 From: Juergen Schoenwaelder To: STUART VENTERS Message-ID: <20160316150757.GA40102@elstar.local> Mail-Followup-To: STUART VENTERS , "netmod@ietf.org" , Martin Bjorklund References: <1220E2C537595D439C5D026E83751866E7B4940C@ex-mb1.corp.adtran.com> <20160304165219.GA36535@elstar.local> <01bd01d17f7f$116bb2e0$4001a8c0@gateway.2wire.net> <20160316140828.GC39819@elstar.local> <1220E2C537595D439C5D026E83751866E7B4C079@ex-mb1.corp.adtran.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1220E2C537595D439C5D026E83751866E7B4C079@ex-mb1.corp.adtran.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification 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, 16 Mar 2016 15:08:49 -0000 Speaking with my WG chair hat on, I think it is a bit late to discuss the design of actions. The WG has been working on YANG 1.1 for almost two years and unless something is really broken in the specification I am not going to take the specification back from where it is now, namely the processing pipeline of the IESG. It is time to deliver and then use all the good stuff that is in YANG 1.1. /js On Wed, Mar 16, 2016 at 02:58:08PM +0000, STUART VENTERS wrote: > Interesting, this highlights a concern I have with Yang. > It's highlevel goals and progress are great, but at a detail level, > instead of using one general purpose language construct per feature, it seems to be evolving to use many. > For a new language evolving in an old problem area, this doesn't seem right. > > RFC6020bis-11 section 7.15 gives some clue as to the reasoning behind this. > "The difference between an action and an rpc is that an action is tied > to a node in the datastore, whereas an rpc is not." > > To me, this feels like a protocol or implementation issue is causing an unnecessary language addition. > > I wonder if an alternative strategy could be to say that you can use an rpc in a node, but when you do the name of the rpc on the wire becomes some combination of the node name and the rpc name? > > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, March 16, 2016 9:08 AM > To: t. petch > Cc: STUART VENTERS; netmod@ietf.org; Martin Bjorklund > Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification > > On Wed, Mar 16, 2016 at 12:26:17PM +0000, t. petch wrote: > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > Sent: Friday, March 04, 2016 4:52 PM > > > > > > > On Fri, Mar 04, 2016 at 04:25:37PM +0000, STUART VENTERS wrote: > > > > > > > > 2) Allow the 'rpc' and 'notification' nouns to be used in other > > places in the schema tree besides at the top module level. > > > > > > This is already part of YANG 1.1. > > > > Looking at rfc6020bis-11 s.14, I see 'notification-stmt' appearing in > > many places so indeed it is allowed in other places but only see > > 'rpc-stmt' appear in 'body-stmts' . Which, if I understand aright, > > means that 'rpc-stmt' can still only appear at the top level. > > > > Yep. But there is a new action-stmt and in section 1.1 it says: > > o Added a new statement "action" that is used to define operations > tied to data nodes. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- 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 16 08:12:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D58212D97C for ; Wed, 16 Mar 2016 08:12: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_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 skfuJ2OREurW for ; Wed, 16 Mar 2016 08:12:17 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E4A12D928 for ; Wed, 16 Mar 2016 08:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2901; q=dns/txt; s=iport; t=1458141129; x=1459350729; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p/BRNMBK7VwFYjrEPBTu7b88c9r1MgzQQVUVBQA4NcM=; b=gb5OrcwtUkGw5clQTqusxycFOSdgJhSInQXDc1zpgMhTBEkr4mquLvry iZIQAU6Uiu91zhxTB5vD/hy3XSwU8ap2RT7FPpRNswdELNyLh/HswXVmy S7xUBCHm5tToE8GWkU3pS2Q7Xc/ZibsuStP78YWv3cnHdeZ619Rym4Jz1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQCBd+lW/4UNJK1bA4NGU3S5fAENg?= =?us-ascii?q?W8dhXACgT04FAEBAQEBAQFkJ4RBAQEBAwEnEz8FCQICAQgOAgUDHhAbFyUBAQQ?= =?us-ascii?q?ODYgXCL9cAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQSGGoREhF0mg3MFh2CLJIRNA?= =?us-ascii?q?Y15jwyOfgEeAQFCg2WKT34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,345,1454976000"; d="scan'208";a="250056798" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Mar 2016 15:12:08 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u2GFC8dL030218 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 15:12:08 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Mar 2016 11:12:07 -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.1104.009; Wed, 16 Mar 2016 11:12:07 -0400 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder Thread-Topic: [netmod] Differentiating the types of Mount Thread-Index: AdF/OD2NJ3Cq4cCSQLyujReGzdHIoQAX41GAAAGL/6A= Date: Wed, 16 Mar 2016 15:12:07 +0000 Message-ID: <21332d7a3dfd41009fb5023ca94baa94@XCH-RTP-013.cisco.com> References: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> <20160316112329.GB39598@elstar.local> In-Reply-To: <20160316112329.GB39598@elstar.local> 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.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" , "Martin Bjorklund \(mbjorklu\)" Subject: Re: [netmod] Differentiating the types of Mount 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, 16 Mar 2016 15:12:23 -0000 > From: Juergen Schoenwaelder , March 16, 2016 7:23 AM >=20 > On Wed, Mar 16, 2016 at 03:59:50AM +0000, Eric Voit (evoit) wrote: > > To help differentiate between concepts and drafts, below are strawman > definitions for the various types of Mount which we have been discussing = over > the last year in Netmod. Thoughts/suggestions? > > > > YANG Mount > > ---------------- > > Definition: An abstracted term for a mechanism that a parent YANG model= can > use to link in YANG information defined or located elsewhere. > > Purpose: Provides model flexibility by enabling the growth of YANG tree= s via > an explicit reference to other YANG information and structures. >=20 > Trying to rewrite the definition to be more consistent with existing > terminology: >=20 > The abstract concept of incorporating a YANG-defined data tree (the > mounted data tree) into a existing YANG-defined data tree (the > parent data tree). >=20 > Well, this is not really correct, perhaps we have to just say 'tree' > instead of 'data tree' since a schema mount (as I understand it) seems to > incorporate a schema tree into another schema tree while the other two > mounts incorporate a data tree into a data tree. So perhaps the general > definition is something like this: >=20 > The abstract concept of incorporating a YANG-defined data tree or > schema tree (the mounted data or schema tree) into a existing > YANG-defined data tree or schema tree (the parent data tree). This works for me. > The schema mount then essentially removes data tree and the other two > mounts remove the schema tree from this definition. >=20 > Is your alias mount simply a special case of a peer mount where the peer = is > local? Or is there more to it?=20 >From a syntax standpoint, peer mount is more general. But underneath, thin= gs get more complicated. For example, many of the initial concerns about peer mount were on the impl= ications of synchronizing objects across distributed systems. (I.e., Event= ual consistency is not appropriate when attempting to manage some type of o= bjects.) Alias mount shouldn't have this issue. Eric > In other words, would it be reasonable to think of the terms in this way: > +-> schema (tree) mount > | > mount -> | +-> local data tree (alias) mount > +-> data (tree) mount -> | > +-> remote data tree (peer) mount The formatting came through mixed up, and I didn't want to make any assumpt= ions by doing my own reformatting. If the answer above doesn't suffice, re= send the example. Eric > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Wed Mar 16 08:34:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6015012D9E9 for ; Wed, 16 Mar 2016 08:34:11 -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_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 KXvujOlXz7Ns for ; Wed, 16 Mar 2016 08:34:10 -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 40B9112D78A for ; Wed, 16 Mar 2016 08:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=928; q=dns/txt; s=iport; t=1458142394; x=1459351994; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZRAT/60il/+Ur/9143TZrFvdCDxwstXEKtAHXBjFAqg=; b=e875+xVcnenHY6ns8vy2kIYnY8zpu66BUNnMaMJ72aGdvM8MBVsvHDR5 TxQTtwKOl6cPo5a/xtF38Il1N3wcZsm2EMAmcvFYu/cVdGXrq0MXy09yW nj5PwAyQtHeA9xP95U7JtMdpL/0840PJqvxEfurrrk1zS8s/O2avD/w04 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQCUe+lW/4oNJK1eg0aBR7l9AQ2Bb?= =?us-ascii?q?4YNAoE9OBQBAQEBAQEBZCeEQQEBAQMBOj8QAgEINhAyJQEBBAENDYgXCL9pAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBFYpihCSEUgEEl1EBjXmBbIdvhTGOfgEeAQFCg?= =?us-ascii?q?2WKT34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,345,1454976000"; d="scan'208";a="250190541" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Mar 2016 15:33:13 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u2GFXCDQ024286 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 15:33:12 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Mar 2016 11:33:11 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Wed, 16 Mar 2016 11:33:12 -0400 From: "Alexander Clemm (alex)" To: "Eric Voit (evoit)" , Juergen Schoenwaelder Thread-Topic: [netmod] Differentiating the types of Mount Thread-Index: AdF/OD2NJ3Cq4cCSQLyujReGzdHIoQAX41GAAAGL/6AAAV8hMA== Date: Wed, 16 Mar 2016 15:33:11 +0000 Message-ID: <3db0d2e918eb41cfab310c24aba9f619@XCH-RTP-001.cisco.com> References: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> <20160316112329.GB39598@elstar.local> <21332d7a3dfd41009fb5023ca94baa94@XCH-RTP-013.cisco.com> In-Reply-To: <21332d7a3dfd41009fb5023ca94baa94@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.24.92.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" , "Martin Bjorklund \(mbjorklu\)" Subject: Re: [netmod] Differentiating the types of Mount 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, 16 Mar 2016 15:34:11 -0000 Hi, I have one addition on top of Eric's response --- Alex >=20 > Is your alias mount simply a special case of a peer mount where the=20 > peer is local? Or is there more to it? >From a syntax standpoint, peer mount is more general. But underneath, thin= gs get more complicated. For example, many of the initial concerns about peer mount were on the impl= ications of synchronizing objects across distributed systems. (I.e., Event= ual consistency is not appropriate when attempting to manage some type of o= bjects.) Alias mount shouldn't have this issue. So, yes, alias mount is a special and simple case. Perhaps the most= relevant aspect to characterize this is that the authoritative owner in al= ias mount is the same Netconf server, whereas in peer mount authoritative o= wners will be different. For this reason, peer mount will be better suited= for read-only views. From nobody Wed Mar 16 08:36:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3994712D52B for ; Wed, 16 Mar 2016 08:36:32 -0700 (PDT) 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 kXCUOAUyjnM9 for ; Wed, 16 Mar 2016 08:36:29 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A02D12D9D5 for ; Wed, 16 Mar 2016 08:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2hmHj7KMFtfg4ZaA98J4Z3eEfM+QemAa6Vt64hIedLg=; b=j1PLY78lHDwCQfd90VVn1FvEKoNB/II5APP3KINZevNHG17W474yGuKAapPZ4R/IsxbY9Vwfj0IEZmpgDfPphu9m8Bwf144omeHkh+PfBm0MNPwjksMSsYjekg+evlswfKQaKEyk4+rqyglG8/btRFhhmf9sPzD6jbWCDtM8v4E= 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 (TLS) id 15.1.434.16; Wed, 16 Mar 2016 15:35: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.0434.019; Wed, 16 Mar 2016 15:35:25 +0000 From: Kent Watsen To: "Eric Voit (evoit)" , Juergen Schoenwaelder Thread-Topic: [netmod] Differentiating the types of Mount Thread-Index: AdF/OD2NJ3Cq4cCSQLyujReGzdHIoQAPgYyAAAf8JID//8NwAA== Date: Wed, 16 Mar 2016 15:35:24 +0000 Message-ID: <24F4C6F2-3F59-4B71-A9D4-963371FE1EE6@juniper.net> References: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> <20160316112329.GB39598@elstar.local> <21332d7a3dfd41009fb5023ca94baa94@XCH-RTP-013.cisco.com> In-Reply-To: <21332d7a3dfd41009fb5023ca94baa94@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 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-ms-office365-filtering-correlation-id: 9f859a14-424e-451f-da83-08d34db09811 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:PtXphvoFE+rSg0NI0KAbj6B4zmxw3q+J14KPGJsh7rWGVFPEPgAwSvi+RkBqhS+Cdx/0CNTUCx0FMpmwzg2+Mu8o/UB2LTAzdWPZ7E4yIhZob2j5dMWhPqAyjKuW4t2Nrvg9K35BdL3ie2SGuGce2g==; 24:yPpPIVzMwR+dui3n5VtV1q1FpIxNoDZn7nXCFc53Gsu6yeuc+ILjKpVdjcHkn7+URqegdaL08IwiUKsb3seAd0QTXL8+EdgbaNaXfU8b7HA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(479174004)(3660700001)(5002640100001)(99286002)(11100500001)(81166005)(66066001)(83506001)(3280700002)(122556002)(4326007)(82746002)(5004730100002)(2906002)(83716003)(86362001)(36756003)(5008740100001)(87936001)(5001770100001)(33656002)(586003)(10400500002)(1220700001)(1096002)(2950100001)(4001350100001)(102836003)(2900100001)(3846002)(6116002)(76176999)(54356999)(50986999)(15975445007)(92566002)(189998001)(19580395003)(77096005)(19580405001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0E6FDBB7CFAD044D8BDE11E40DED42A3@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 15:35:24.9167 (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: "Martin Bjorklund \(mbjorklu\)" , "netmod@ietf.org" Subject: Re: [netmod] Differentiating the types of Mount 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, 16 Mar 2016 15:36:32 -0000 DQpUaGFuayB5b3UgRXJpYyBhbmQgSnVlcmdlbiwgdGhpcyBpcyByZWFsbHkgaGVscGZ1bCwgZXNw ZWNpYWxseSB0aGUgZGlhZ3JhbS4NCg0KSXMgdGhlcmUgYW4gaW1wbGVtZW50YXRpb24gZGlzdGlu Y3Rpb24gYmV0d2VlbiBhbGlhcy1tb3VudCBhbmQgcGVlci1tb3VudD8gIEnigJltIGhvcGluZyB0 aGF0IHRoZXJlIGlzIG9uZSBzb2x1dGlvbiBmb3IgYm90aC4gIElzIHRoZXJlIGEgZGlmZmVyZW5j ZSB3aXRoIGVkaXRzPyAgRS5nLiwgYSByZW1vdGUgZGF0YSBtb3VudCBpcyByZWFkLW9ubHksIHdo ZXJlYXMgYSBsb2NhbCBkYXRhIG1vdW50IGlzIHJlYWQtd3JpdGU/DQoNCg0KDQoNCktlbnQNCg0K DQoNCk9uIDMvMTYvMTYsIDExOjEyIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBFcmljIFZvaXQg KGV2b2l0KSIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBldm9pdEBjaXNj by5jb20+IHdyb3RlOg0KDQo+PiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgLCBNYXJjaCAx NiwgMjAxNiA3OjIzIEFNDQo+PiANCj4+IE9uIFdlZCwgTWFyIDE2LCAyMDE2IGF0IDAzOjU5OjUw QU0gKzAwMDAsIEVyaWMgVm9pdCAoZXZvaXQpIHdyb3RlOg0KPj4gPiBUbyBoZWxwIGRpZmZlcmVu dGlhdGUgYmV0d2VlbiBjb25jZXB0cyBhbmQgZHJhZnRzLCBiZWxvdyBhcmUgc3RyYXdtYW4NCj4+ IGRlZmluaXRpb25zIGZvciB0aGUgdmFyaW91cyB0eXBlcyBvZiBNb3VudCB3aGljaCB3ZSBoYXZl IGJlZW4gZGlzY3Vzc2luZyBvdmVyDQo+PiB0aGUgbGFzdCB5ZWFyIGluIE5ldG1vZC4gICBUaG91 Z2h0cy9zdWdnZXN0aW9ucz8NCj4+ID4NCj4+ID4gWUFORyBNb3VudA0KPj4gPiAtLS0tLS0tLS0t LS0tLS0tDQo+PiA+IERlZmluaXRpb246IEFuIGFic3RyYWN0ZWQgdGVybSBmb3IgYSBtZWNoYW5p c20gdGhhdCBhIHBhcmVudCBZQU5HIG1vZGVsIGNhbg0KPj4gdXNlIHRvIGxpbmsgaW4gWUFORyBp bmZvcm1hdGlvbiBkZWZpbmVkIG9yIGxvY2F0ZWQgZWxzZXdoZXJlLg0KPj4gPiBQdXJwb3NlOiBQ cm92aWRlcyBtb2RlbCBmbGV4aWJpbGl0eSBieSBlbmFibGluZyB0aGUgZ3Jvd3RoIG9mIFlBTkcg dHJlZXMgdmlhDQo+PiBhbiBleHBsaWNpdCByZWZlcmVuY2UgdG8gb3RoZXIgWUFORyBpbmZvcm1h dGlvbiBhbmQgc3RydWN0dXJlcy4NCj4+IA0KPj4gVHJ5aW5nIHRvIHJld3JpdGUgdGhlIGRlZmlu aXRpb24gdG8gYmUgbW9yZSBjb25zaXN0ZW50IHdpdGggZXhpc3RpbmcNCj4+IHRlcm1pbm9sb2d5 Og0KPj4gDQo+PiAgIFRoZSBhYnN0cmFjdCBjb25jZXB0IG9mIGluY29ycG9yYXRpbmcgYSBZQU5H LWRlZmluZWQgZGF0YSB0cmVlICh0aGUNCj4+ICAgbW91bnRlZCBkYXRhIHRyZWUpIGludG8gYSBl eGlzdGluZyBZQU5HLWRlZmluZWQgZGF0YSB0cmVlICh0aGUNCj4+ICAgcGFyZW50IGRhdGEgdHJl ZSkuDQo+PiANCj4+IFdlbGwsIHRoaXMgaXMgbm90IHJlYWxseSBjb3JyZWN0LCBwZXJoYXBzIHdl IGhhdmUgdG8ganVzdCBzYXkgJ3RyZWUnDQo+PiBpbnN0ZWFkIG9mICdkYXRhIHRyZWUnIHNpbmNl IGEgc2NoZW1hIG1vdW50IChhcyBJIHVuZGVyc3RhbmQgaXQpIHNlZW1zIHRvDQo+PiBpbmNvcnBv cmF0ZSBhIHNjaGVtYSB0cmVlIGludG8gYW5vdGhlciBzY2hlbWEgdHJlZSB3aGlsZSB0aGUgb3Ro ZXIgdHdvDQo+PiBtb3VudHMgaW5jb3Jwb3JhdGUgYSBkYXRhIHRyZWUgaW50byBhIGRhdGEgdHJl ZS4gU28gcGVyaGFwcyB0aGUgZ2VuZXJhbA0KPj4gZGVmaW5pdGlvbiBpcyBzb21ldGhpbmcgbGlr ZSB0aGlzOg0KPj4gDQo+PiAgIFRoZSBhYnN0cmFjdCBjb25jZXB0IG9mIGluY29ycG9yYXRpbmcg YSBZQU5HLWRlZmluZWQgZGF0YSB0cmVlIG9yDQo+PiAgIHNjaGVtYSB0cmVlICh0aGUgbW91bnRl ZCBkYXRhIG9yIHNjaGVtYSB0cmVlKSBpbnRvIGEgZXhpc3RpbmcNCj4+ICAgWUFORy1kZWZpbmVk IGRhdGEgdHJlZSBvciBzY2hlbWEgdHJlZSAodGhlIHBhcmVudCBkYXRhIHRyZWUpLg0KPg0KPlRo aXMgd29ya3MgZm9yIG1lLg0KPg0KPj4gVGhlIHNjaGVtYSBtb3VudCB0aGVuIGVzc2VudGlhbGx5 IHJlbW92ZXMgZGF0YSB0cmVlIGFuZCB0aGUgb3RoZXIgdHdvDQo+PiBtb3VudHMgcmVtb3ZlIHRo ZSBzY2hlbWEgdHJlZSBmcm9tIHRoaXMgZGVmaW5pdGlvbi4NCj4+IA0KPj4gSXMgeW91ciBhbGlh cyBtb3VudCBzaW1wbHkgYSBzcGVjaWFsIGNhc2Ugb2YgYSBwZWVyIG1vdW50IHdoZXJlIHRoZSBw ZWVyIGlzDQo+PiBsb2NhbD8gT3IgaXMgdGhlcmUgbW9yZSB0byBpdD8gDQo+DQo+PkZyb20gYSBz eW50YXggc3RhbmRwb2ludCwgcGVlciBtb3VudCBpcyBtb3JlIGdlbmVyYWwuICBCdXQgdW5kZXJu ZWF0aCwgdGhpbmdzIGdldCBtb3JlIGNvbXBsaWNhdGVkLg0KPg0KPkZvciBleGFtcGxlLCBtYW55 IG9mIHRoZSBpbml0aWFsIGNvbmNlcm5zIGFib3V0IHBlZXIgbW91bnQgd2VyZSBvbiB0aGUgaW1w bGljYXRpb25zIG9mIHN5bmNocm9uaXppbmcgb2JqZWN0cyBhY3Jvc3MgZGlzdHJpYnV0ZWQgc3lz dGVtcy4gIChJLmUuLCBFdmVudHVhbCBjb25zaXN0ZW5jeSBpcyBub3QgYXBwcm9wcmlhdGUgd2hl biBhdHRlbXB0aW5nIHRvIG1hbmFnZSBzb21lIHR5cGUgb2Ygb2JqZWN0cy4pICBBbGlhcyBtb3Vu dCBzaG91bGRuJ3QgaGF2ZSB0aGlzIGlzc3VlLg0KPg0KPkVyaWMNCj4NCj4+IEluIG90aGVyIHdv cmRzLCB3b3VsZCBpdCBiZSByZWFzb25hYmxlIHRvIHRoaW5rIG9mIHRoZSB0ZXJtcyBpbiB0aGlz IHdheToNCj4+ICAgICAgICAgICstPiBzY2hlbWEgKHRyZWUpIG1vdW50DQo+PiAJIHwNCj4+IG1v dW50IC0+IHwgICAgICAgICAgICAgICAgICAgICAgICArLT4gbG9jYWwgZGF0YSB0cmVlIChhbGlh cykgbW91bnQNCj4+ICAgICAgICAgICstPiBkYXRhICh0cmVlKSBtb3VudCAtPiB8DQo+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0+IHJlbW90ZSBkYXRhIHRyZWUgKHBlZXIp IG1vdW50DQo+DQo+VGhlIGZvcm1hdHRpbmcgY2FtZSB0aHJvdWdoIG1peGVkIHVwLCBhbmQgSSBk aWRuJ3Qgd2FudCB0byBtYWtlIGFueSBhc3N1bXB0aW9ucyBieSBkb2luZyBteSBvd24gcmVmb3Jt YXR0aW5nLiAgSWYgdGhlIGFuc3dlciBhYm92ZSBkb2Vzbid0IHN1ZmZpY2UsIHJlc2VuZCB0aGUg ZXhhbXBsZS4NCj4NCj5FcmljDQo+DQo+PiAvanMNCj4+IA0KPj4gLS0NCj4+IEp1ZXJnZW4gU2No b2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+PiBQ aG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVt ZW4gfCBHZXJtYW55DQo+PiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8v d3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0 Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Wed Mar 16 09:28:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E1C12D59E for ; Wed, 16 Mar 2016 09:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 0Mef9zCLVJsu for ; Wed, 16 Mar 2016 09:28:45 -0700 (PDT) Received: from p02c11o145.mxlogic.net (p02c11o145.mxlogic.net [208.65.144.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BAA12D625 for ; Wed, 16 Mar 2016 09:28:45 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c11o145.mxlogic.net(mxl_mta-8.5.0-8) with ESMTP id db989e65.2acce7e52940.227007.00-503.610171.p02c11o145.mxlogic.net (envelope-from ); Wed, 16 Mar 2016 10:28:45 -0600 (MDT) X-MXL-Hash: 56e989bd27bbc060-7d5a5bf48ee51c4f83e42acb4a11505dd324e3ef Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c11o145.mxlogic.net(mxl_mta-8.5.0-8) over TLS secured channel with ESMTP id 5b989e65.0.226935.00-236.609934.p02c11o145.mxlogic.net (envelope-from ); Wed, 16 Mar 2016 10:28:43 -0600 (MDT) X-MXL-Hash: 56e989bb47c6c5cd-a09a849af4494fcc2926f602f6ddd32923282f72 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.0266.001; Wed, 16 Mar 2016 11:28:37 -0500 From: STUART VENTERS To: 'Juergen Schoenwaelder' Thread-Topic: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification Thread-Index: AQHRf3+l7z9M94Im7kGWJzNDQhHyXp9cb3IA//+zOuCAAF1kgP//rY4g Date: Wed, 16 Mar 2016 16:28:36 +0000 Message-ID: <1220E2C537595D439C5D026E83751866E7B4C0D5@ex-mb1.corp.adtran.com> References: <1220E2C537595D439C5D026E83751866E7B4940C@ex-mb1.corp.adtran.com> <20160304165219.GA36535@elstar.local> <01bd01d17f7f$116bb2e0$4001a8c0@gateway.2wire.net> <20160316140828.GC39819@elstar.local> <1220E2C537595D439C5D026E83751866E7B4C079@ex-mb1.corp.adtran.com> <20160316150757.GA40102@elstar.local> In-Reply-To: <20160316150757.GA40102@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.118.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=XrT8TAx9 c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=0eaKXOXVzoQA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=7OsogOcEt9IA:10 a=48vgC7m] X-AnalysisOut: [UAAAA:8 a=j3Z76cjpAAAA:8 a=SJdXaTmaJ3iGhucLqpkA:9 a=DSl7vI] X-AnalysisOut: [d7ponIJACA:21 a=8iSO8Cc20BKueszT:21 a=CjuIK1q_8ugA:10 a=Fv] X-AnalysisOut: [gKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK9] X-AnalysisOut: [1CQyQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2016031610); S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification 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, 16 Mar 2016 16:28:48 -0000 Juergen, Agreed, given where you are in the process, the Yang1.1/action ship has sai= led.=20 At this point, if the feedback is valid (consensus for which hasn't been s= hown),=20 it only provides an Occam's Razor reminder for thinking about how to ad= d future features. If the mount ship has not sailed, then mount might be one of those future f= eatures. Cheers, Stuart -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, March 16, 2016 10:08 AM To: STUART VENTERS Cc: netmod@ietf.org; Martin Bjorklund Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible si= mplification Speaking with my WG chair hat on, I think it is a bit late to discuss the d= esign of actions. The WG has been working on YANG 1.1 for almost two years = and unless something is really broken in the specification I am not going t= o take the specification back from where it is now, namely the processing p= ipeline of the IESG. It is time to deliver and then use all the good stuff = that is in YANG 1.1. /js On Wed, Mar 16, 2016 at 02:58:08PM +0000, STUART VENTERS wrote: > Interesting, this highlights a concern I have with Yang. > It's highlevel goals and progress are great, but at a detail level, > instead of using one general purpose language construct per feature, i= t seems to be evolving to use many. > For a new language evolving in an old problem area, this doesn't seem rig= ht. >=20 > RFC6020bis-11 section 7.15 gives some clue as to the reasoning behind thi= s. > "The difference between an action and an rpc is that an action is tied > to a node in the datastore, whereas an rpc is not." >=20 > To me, this feels like a protocol or implementation issue is causing an u= nnecessary language addition. >=20 > I wonder if an alternative strategy could be to say that you can use an r= pc in a node, but when you do the name of the rpc on the wire becomes some = combination of the node name and the rpc name? >=20 >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, March 16, 2016 9:08 AM > To: t. petch > Cc: STUART VENTERS; netmod@ietf.org; Martin Bjorklund > Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount /=20 > possible simplification >=20 > On Wed, Mar 16, 2016 at 12:26:17PM +0000, t. petch wrote: > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > Sent: Friday, March 04, 2016 4:52 PM > >=20 > >=20 > > > On Fri, Mar 04, 2016 at 04:25:37PM +0000, STUART VENTERS wrote: > > > > > > > > 2) Allow the 'rpc' and 'notification' nouns to be used in othe= r > > places in the schema tree besides at the top module level. > > > > > > This is already part of YANG 1.1. > >=20 > > Looking at rfc6020bis-11 s.14, I see 'notification-stmt' appearing=20 > > in many places so indeed it is allowed in other places but only see=20 > > 'rpc-stmt' appear in 'body-stmts' . Which, if I understand aright,=20 > > means that 'rpc-stmt' can still only appear at the top level. > > >=20 > Yep. But there is a new action-stmt and in section 1.1 it says: >=20 > o Added a new statement "action" that is used to define operations > tied to data nodes. >=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 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 16 09:58:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A98C12D569 for ; Wed, 16 Mar 2016 09:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 m2jtw9-8zg4A for ; Wed, 16 Mar 2016 09:58:26 -0700 (PDT) Received: from s12p02o143.mxlogic.net (s12p02o143.mxlogic.net [208.65.145.66]) (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 960D812D518 for ; Wed, 16 Mar 2016 09:58:26 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by s12p02o143.mxlogic.net(mxl_mta-8.5.0-8) with ESMTP id 2b099e65.7ff35a1fc700.61837.00-584.183675.s12p02o143.mxlogic.net (envelope-from ); Wed, 16 Mar 2016 10:58:26 -0600 (MDT) X-MXL-Hash: 56e990b235069f52-15db05b2deac6de7547a3a939e417478e35c6eea Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by s12p02o143.mxlogic.net(mxl_mta-8.5.0-8) over TLS secured channel with ESMTP id 9a099e65.0.61651.00-122.183187.s12p02o143.mxlogic.net (envelope-from ); Wed, 16 Mar 2016 10:58:24 -0600 (MDT) X-MXL-Hash: 56e990b0685c5067-51f74bab6b1b79352b6c4dccd97e0a39e0664ae9 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.0266.001; Wed, 16 Mar 2016 11:58:12 -0500 From: STUART VENTERS To: 'Juergen Schoenwaelder' , "Eric Voit (evoit)" Thread-Topic: [netmod] Differentiating the types of Mount Thread-Index: AdF/OD2NJ3Cq4cCSQLyujReGzdHIoQAZ+8KAAACU0PA= Date: Wed, 16 Mar 2016 16:58:11 +0000 Message-ID: <1220E2C537595D439C5D026E83751866E7B4C101@ex-mb1.corp.adtran.com> References: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> <20160316112329.GB39598@elstar.local> In-Reply-To: <20160316112329.GB39598@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.118.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=POIJjKeC c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=0eaKXOXVzoQA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=7OsogOcEt9IA:10 a=48vgC7m] X-AnalysisOut: [UAAAA:8 a=j3Z76cjpAAAA:8 a=OCM4CDYJNLJQ-D5Haa0A:9 a=5dU66M] X-AnalysisOut: [r8LEQ73UBn:21 a=-mkwRyczlgZDIEss:21 a=CjuIK1q_8ugA:10 a=Fv] X-AnalysisOut: [gKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK9] X-AnalysisOut: [1CQyQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2016031611); S=0.498(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: Cc: "Martin Bjorklund \(mbjorklu\)" , "netmod@ietf.org" Subject: Re: [netmod] Differentiating the types of Mount 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, 16 Mar 2016 16:58:29 -0000 Defining a schema-tree seems Yang's strong suite. I'm not sure if the suite extends to defining what goes into a data-tree go= verned by the schema-tree. Perhaps: YANG Mount ---------------- Definition: An abstracted term for a YANG mechanism that grafts a sibling = schema-tree as a subtree of a parent schema-tree. Purpose: Provides flexibility by enabling the growth of YANG models via an= explicit reference to other YANG models defined elsewhere. Given the ability to specify a combined schema-tree, maybe something at the= protocol level could specify what data to use to populate the grafted tree= . This could provide a place to specify details like who has ownership of the= data, if it is RW, etc. NETCONF Mount ------------------ Definition: An abstracted term for a NETCONF mechanism to construct a combi= ned data-tree according to a schema defined with YANG mount. Purpose: ... -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwa= elder Sent: Wednesday, March 16, 2016 6:23 AM To: Eric Voit (evoit) Cc: netmod@ietf.org; Martin Bjorklund (mbjorklu) Subject: Re: [netmod] Differentiating the types of Mount On Wed, Mar 16, 2016 at 03:59:50AM +0000, Eric Voit (evoit) wrote: > To help differentiate between concepts and drafts, below are strawman def= initions for the various types of Mount which we have been discussing over = the last year in Netmod. Thoughts/suggestions? >=20 > YANG Mount > ---------------- > Definition: An abstracted term for a mechanism that a parent YANG model c= an use to link in YANG information defined or located elsewhere. =20 > Purpose: Provides model flexibility by enabling the growth of YANG trees = via an explicit reference to other YANG information and structures. Trying to rewrite the definition to be more consistent with existing terminology: The abstract concept of incorporating a YANG-defined data tree (the mounted data tree) into a existing YANG-defined data tree (the parent data tree). Well, this is not really correct, perhaps we have to just say 'tree' instead of 'data tree' since a schema mount (as I understand it) seems to i= ncorporate a schema tree into another schema tree while the other two mount= s incorporate a data tree into a data tree. So perhaps the general definiti= on is something like this: The abstract concept of incorporating a YANG-defined data tree or schema tree (the mounted data or schema tree) into a existing YANG-defined data tree or schema tree (the parent data tree). The schema mount then essentially removes data tree and the other two mount= s remove the schema tree from this definition. Is your alias mount simply a special case of a peer mount where the peer is= local? Or is there more to it? In other words, would it be reasonable to t= hink of the terms in this way: +-> schema (tree) mount | mount -> | +-> local data tree (alias) mount +-> data (tree) mount -> | +-> remote data tree (peer) mount /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 Wed Mar 16 10:19:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8010A12DA10 for ; Wed, 16 Mar 2016 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_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 gquxu3c-63dK for ; Wed, 16 Mar 2016 10:19:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9738F12D506 for ; Wed, 16 Mar 2016 10:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4244; q=dns/txt; s=iport; t=1458148782; x=1459358382; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+JTMPLNNgJj0RmQ1uFCtPj188yye4ucEddeVLXe73bI=; b=XRVMPXEUWCiIYwScrOCJJKGmeQCmM9RCjUKx7Rs/mDiOCR1tdC7e8g9h +pBiJSyi/uzKwUh5tstBkXy8SUgN8JY80DOq83y4NS4PtbRdBdnAe57SK GQs7kVqhmAl40gKWu4JeR3OPGpJ0Pus4CAlqP8mgb/w8cj05LrFl3LbbP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgDRlOlW/5xdJa1bA4NGU24GuX8BD?= =?us-ascii?q?YFvFwqFIkoCgUM4FAEBAQEBAQFkJ4RBAQEBAwEBAQEkEzQLBQcCAgIBCBABBAE?= =?us-ascii?q?BAR4JBxsMCxQJCAEBBA4FCIgXCA6/egEBAQEBAQEBAQEBAQEBAQEBAQEBARUEh?= =?us-ascii?q?hqERIRdJoNzBYdgj3EBhW6IC4I3jFWOfgEeAQFCg2VqiWV+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,345,1454976000"; d="scan'208";a="81377378" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2016 17:19:40 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u2GHJd8f031740 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 17:19:39 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Mar 2016 13:19:38 -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.1104.009; Wed, 16 Mar 2016 13:19:38 -0400 From: "Eric Voit (evoit)" To: STUART VENTERS Thread-Topic: [netmod] Differentiating the types of Mount Thread-Index: AdF/OD2NJ3Cq4cCSQLyujReGzdHIoQAX41GAAAuwc4AACCa0AA== Date: Wed, 16 Mar 2016 17:19:37 +0000 Message-ID: <020f5d85b38d46d5a09940e8e89cc37e@XCH-RTP-013.cisco.com> References: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> <20160316112329.GB39598@elstar.local> <1220E2C537595D439C5D026E83751866E7B4C101@ex-mb1.corp.adtran.com> In-Reply-To: <1220E2C537595D439C5D026E83751866E7B4C101@ex-mb1.corp.adtran.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.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Martin Bjorklund \(mbjorklu\)" , "netmod@ietf.org" Subject: Re: [netmod] Differentiating the types of Mount 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, 16 Mar 2016 17:19:52 -0000 > From: STUART VENTERS, March 16, 2016 12:58 PM >=20 > Defining a schema-tree seems Yang's strong suite. > I'm not sure if the suite extends to defining what goes into a data-tree = governed > by the schema-tree. Hi Stuart, Open Daylight has found Mounting YANG data from one device to another has p= roven central to their effort. Doing a quick Google search for "mount site= :opendaylight.org" gives 800+ results. Based on that, I was hoping that being defining the variants of Mount acros= s different constituencies would help us not collide as the technologies ev= olve. This includes a shared definition of "YANG Mount" which shows what i= s common across all efforts. Thanks, Eric =20 > Perhaps: >=20 > YANG Mount > ---------------- > Definition: An abstracted term for a YANG mechanism that grafts a siblin= g > schema-tree as a subtree of a parent schema-tree. > Purpose: Provides flexibility by enabling the growth of YANG models via = an > explicit reference to other YANG models defined elsewhere. >=20 > Given the ability to specify a combined schema-tree, maybe something at t= he > protocol level could specify what data to use to populate the grafted tre= e. > This could provide a place to specify details like who has ownership of t= he data, > if it is RW, etc. >=20 > NETCONF Mount > ------------------ > Definition: An abstracted term for a NETCONF mechanism to construct a > combined data-tree according to a schema defined with YANG mount. > Purpose: ... >=20 >=20 >=20 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, March 16, 2016 6:23 AM > To: Eric Voit (evoit) > Cc: netmod@ietf.org; Martin Bjorklund (mbjorklu) > Subject: Re: [netmod] Differentiating the types of Mount >=20 > On Wed, Mar 16, 2016 at 03:59:50AM +0000, Eric Voit (evoit) wrote: > > To help differentiate between concepts and drafts, below are strawman > definitions for the various types of Mount which we have been discussing = over > the last year in Netmod. Thoughts/suggestions? > > > > YANG Mount > > ---------------- > > Definition: An abstracted term for a mechanism that a parent YANG model= can > use to link in YANG information defined or located elsewhere. > > Purpose: Provides model flexibility by enabling the growth of YANG tree= s via > an explicit reference to other YANG information and structures. >=20 > Trying to rewrite the definition to be more consistent with existing > terminology: >=20 > The abstract concept of incorporating a YANG-defined data tree (the > mounted data tree) into a existing YANG-defined data tree (the > parent data tree). >=20 > Well, this is not really correct, perhaps we have to just say 'tree' > instead of 'data tree' since a schema mount (as I understand it) seems to > incorporate a schema tree into another schema tree while the other two > mounts incorporate a data tree into a data tree. So perhaps the general > definition is something like this: >=20 > The abstract concept of incorporating a YANG-defined data tree or > schema tree (the mounted data or schema tree) into a existing > YANG-defined data tree or schema tree (the parent data tree). >=20 > The schema mount then essentially removes data tree and the other two > mounts remove the schema tree from this definition. >=20 > Is your alias mount simply a special case of a peer mount where the peer = is > local? Or is there more to it? In other words, would it be reasonable to = think of > the terms in this way: >=20 > +-> schema (tree) mount > | > mount -> | +-> local data tree (alias) mount > +-> data (tree) mount -> | > +-> remote data tree (peer) mount >=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 From nobody Wed Mar 16 11:18:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187E212D65C; Wed, 16 Mar 2016 11:18:35 -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, 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 KiRb3UqTuD9s; Wed, 16 Mar 2016 11:18:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.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 6255A12DA4C; Wed, 16 Mar 2016 11:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kUUjBaJAxP9aNEyBejuVyJ4KUnJbc6EWMdMrREdx2IM=; b=jCy+1SnxvENXWoZR3yUDCbVQSrb5yG3vyjABccOhycPLZjZd94IJSumDCHNr1YVZ+1Of5xwbE8tRp89guGwyyh0hNYh7lVXzUIRinhie3CrcfBGEoIzhPeNJoZLVu00L8OPuF7WImljwR5HZYGXoXlCUY6iTQIHHOwMZjxXtbaE= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1769.namprd05.prod.outlook.com (10.163.140.27) with Microsoft SMTP Server (TLS) id 15.1.443.12; Wed, 16 Mar 2016 18:18:30 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0434.016; Wed, 16 Mar 2016 18:18:31 +0000 From: Kent Watsen To: "rwilton@cisco.com" , "daviball@cisco.com" , Tapraj Singh , Selvakumar Sivaraj Thread-Topic: Regarding IPR on draft-wilton-netmod-intf-ext-yang Thread-Index: AQHRf7A+AZD2nUTCQUCEoTWNgXQELg== Date: Wed, 16 Mar 2016 18:18:30 +0000 Message-ID: <255CBF2A-E225-4B37-AE62-35D0BFC2BEFD@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 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-ms-office365-filtering-correlation-id: 40ead2f2-1bd4-4ba2-65cb-08d34dc760fc x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1769; 5:7vjgQ6rUu7ORi5M63yJea/Gc5/wZ1jpl4T5d9GxfvhJD/pvhz7kebj4NNAYjLkOL03SZqEGkT+YSL1xcnXYblij20M8htGRDLVJrHsJk5NIX50dCp8UVxkTicDr8UtzxKAcO1f6JIAR/yDb14GkiaA==; 24:G5ag0wWfCmHAkzvEm4h0bKbrzxfP/6/YMjWoBl1rKUb2Os/pAUEn0eO/w3J3sVhbiCwmPmSHCVJuT0w2ENd5uXsPjlNq6OmTsbkfhBzF4DM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1769; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR0501MB1769; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1769; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(3660700001)(122556002)(5001770100001)(2906002)(4326007)(10400500002)(66066001)(36756003)(5008740100001)(4001450100002)(3280700002)(2501003)(3846002)(102836003)(229853001)(99286002)(15975445007)(77096005)(82746002)(6116002)(19617315012)(230783001)(83506001)(33656002)(16236675004)(19580395003)(1220700001)(586003)(106116001)(1096002)(5004730100002)(87936001)(81166005)(189998001)(4001350100001)(86362001)(83716003)(2900100001)(5002640100001)(50986999)(54356999)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1769; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_255CBF2AE2254B37AE6235D0BFC2BEFDjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 18:18:30.8793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1769 Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: [netmod] Regarding IPR on draft-wilton-netmod-intf-ext-yang 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, 16 Mar 2016 18:18:35 -0000 --_000_255CBF2AE2254B37AE6235D0BFC2BEFDjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W1RoaXMgcmVnYXJkcyB0aGUgbmV3IHByZS1hZG9wdGlvbiBwcm9jZXNzIGRlc2NyaWJlZCBieSBo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTU1 MjAuaHRtbF0NCg0KQXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCg0KQXMgcGFydCBvZiB0aGUg cHJlcGFyYXRpb24gZm9yIFdHIExhc3QgQ2FsbCwgYXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRo YXQgYXBwbGllcyB0byBkcmFmdCBpZGVudGlmaWVkIGFib3ZlPyAgUGxlYXNlIHN0YXRlIGVpdGhl cjoNCg0KICAgICJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0 aGlzIGRyYWZ0Ig0Kb3INCiAgICAiWWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0 byB0aGlzIGRyYWZ0Ig0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNv bXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2Njkg YW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/ICBJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ug c3RhdGUgZWl0aGVyOg0KDQogICAgIlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4g Y29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0Kb3INCiAgICAiTm8sIHRoZSBJUFIgaGFz IG5vdCBiZWVuIGRpc2Nsb3NlZCINCg0KSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUg YW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsNCmFwcHJvcHJpYXRlLg0KDQpJZiB5b3Ug YXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5z d2VyIHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3 aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9j dW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNl IGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRv ci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FH ReKAmVMgVE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0 ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJp YnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUgSUVURiBJ UFIgcnVsZXMgd2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBh cmUgYXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8g cmVmcmFpbiBmcm9tIHBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNz aW9uIHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9u LCBwbGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZSBhbmQgaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQoNClRo YW5rIHlvdSwNCk5FVE1PRCBXRyBDaGFpcnMNCg0KUFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3Rl ZCBpbiB0aGUgaGVhZGVycyBvZiB0aGlzIG1lc3NhZ2UgaW4geW91ciByZXNwb25zZS4NCg0K --_000_255CBF2AE2254B37AE6235D0BFC2BEFDjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+W1RoaXMgcmVnYXJkcyB0aGUgbmV3IHByZS1hZG9w dGlvbiBwcm9jZXNzIGRlc2NyaWJlZCBieSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTU1MjAuaHRtbF08L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQ291cmllcjsiPkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0csPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IENvdXJpZXI7Ij5BcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFzdCBD YWxsLCBhcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50 aWZpZWQgYWJvdmU/ICZuYnNwO1BsZWFzZSBzdGF0ZSBlaXRoZXI6PC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IENvdXJpZXI7Ij4mbmJzcDsgJm5ic3A7ICZxdW90O05vLCBJJ20gbm90IGF3YXJlIG9m IGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVvdDs8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+b3I8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBDb3VyaWVyOyI+Jm5ic3A7ICZuYnNwOyAmcXVvdDtZZXMsIEknbSBhd2FyZSBvZiBJUFIg dGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVvdDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog Q291cmllcjsiPklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5j ZSB3aXRoIElFVEYgSVBSIHJ1bGVzPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291 cmllcjsiPihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFp bHMpPyAmbmJzcDtJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+Jm5ic3A7ICZuYnNwOyAmcXVvdDtZZXMsIHRo ZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxl cyZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5vcjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij4mbmJzcDsgJm5ic3A7ICZxdW90 O05vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQmcXVvdDs8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQ291cmllcjsiPklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBh ZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQ291cmllcjsiPmFwcHJvcHJpYXRlLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENvdXJpZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVy OyI+SWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3Ig cGxlYXNlIGFuc3dlciB0aGUgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2Fy ZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBS LiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwN CiBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3Rl ZCBjb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElO IFRISVMgTUVTU0FHReKAmVMgVE8gTElORVMuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJp ZXI7Ij5JZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5n cyBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1p bmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzIHdoaWNo IGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQ Ug0KIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9t IHBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQg dG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2Vl IHRoZSBSRkNzIGxpc3RlZCBhYm92ZSBhbmQmbmJzcDs8YSBocmVmPSJodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eSI+aHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFs UHJvcGVydHk8L2E+LjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij48 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+VGhhbmsgeW91 LDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5ORVRNT0QgV0cgQ2hh aXJzPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5QUyBQbGVhc2UgaW5jbHVkZSBh bGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNl LjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19P VVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_255CBF2AE2254B37AE6235D0BFC2BEFDjunipernet_-- From nobody Wed Mar 16 11:20:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01B112DA80; Wed, 16 Mar 2016 11:20: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, 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 EN3ZPREUpqx3; Wed, 16 Mar 2016 11:20:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0131.outbound.protection.outlook.com [65.55.169.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 5EF5912DA5D; Wed, 16 Mar 2016 11:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uWeVGlEN/OA26vD84NJInOaDNJ7+awIBy/2q0NpHgQE=; b=jsarW0KMq8dneVIbQ7moykOA2RsBHhRUOg4H6XBiYUVatVvoDmqBAD22FmOYP4aNH3NLJgKMM6Xdxa26BW3xjUzbPES/+FtxQCJAtX6jucdsgL7ZJtiJT99KOGi2ruaawDQjX5gYGomRr5X5vGkf5XsJr/8pziurMIDzbk3vnNs= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 18:19:57 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0434.016; Wed, 16 Mar 2016 18:19:57 +0000 From: Kent Watsen To: "andy@yumaworks.com" , "mbj@tail-f.com" , "jie.dong@huawei.com" , "dromasca@avaya.com" Thread-Topic: Regarding IPR on draft-entitydt-netmod-entity Thread-Index: AQHRf7BxxemTCcwE1U6mVSvZjJQneg== Date: Wed, 16 Mar 2016 18:19:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 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-ms-office365-filtering-correlation-id: c19848d2-b670-4e1f-3b61-08d34dc7946a x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 5:eBjWkJ7pHzV9bvdbL/sXhDZfHmg7OFzqJPQ25xfWDhsJd16kQzgZbn9H/8qcCouZYVO9DC20XTjGrQusdqcKfqWNNySv+nFR8EGS+i/xqBMwvrNUC5MsdqPs2ddBnyS/MWAkOPQ1mU2UYT7l4Ut7nw==; 24:qp/y5jxWV2cisKWO592el3UwC84OnCPzQhhlx2q30KDE6xa0LGnaB9VSGupTW4qC/qmLQdVOQrBI8CosstTxXC/kBZK+aAb/bMBfXpsN3jA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(3846002)(2501003)(2906002)(33656002)(50986999)(3280700002)(15975445007)(5002640100001)(3660700001)(54356999)(4326007)(87936001)(5008740100001)(106116001)(10400500002)(36756003)(19580395003)(122556002)(189998001)(5004730100002)(19617315012)(77096005)(99286002)(11100500001)(4001350100001)(229853001)(83506001)(2900100001)(82746002)(586003)(6116002)(5001770100001)(86362001)(230783001)(1096002)(66066001)(92566002)(16236675004)(81166005)(83716003)(102836003)(1220700001)(2201001)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F9182F8A52B54A78A592C93B99577EFDjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 18:19:57.1629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452 Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: [netmod] Regarding IPR on draft-entitydt-netmod-entity 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, 16 Mar 2016 18:20:09 -0000 --_000_F9182F8A52B54A78A592C93B99577EFDjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W1RoaXMgcmVnYXJkcyB0aGUgbmV3IHByZS1hZG9wdGlvbiBwcm9jZXNzIGRlc2NyaWJlZCBieSBo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTU1 MjAuaHRtbF0NCg0KDQpBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0KDQpBcyBwYXJ0IG9mIHRo ZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFzdCBDYWxsLCBhcmUgeW91IGF3YXJlIG9mIGFueSBJUFIg dGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZpZWQgYWJvdmU/ICBQbGVhc2Ugc3RhdGUgZWl0 aGVyOg0KDQogICAgIk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRv IHRoaXMgZHJhZnQiDQpvcg0KICAgICJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVz IHRvIHRoaXMgZHJhZnQiDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4g Y29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2 OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8gIElmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFz ZSBzdGF0ZSBlaXRoZXI6DQoNCiAgICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBp biBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQpvcg0KICAgICJObywgdGhlIElQUiBo YXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlk ZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluaw0KYXBwcm9wcmlhdGUuDQoNCklmIHlv dSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBh bnN3ZXIgdGhlIGFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9m IHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBk b2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9u c2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1 dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNT QUdF4oCZUyBUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBh dHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250 cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRG IElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91 IGFyZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0 byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1 c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRp b24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZCBodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCg0K VGhhbmsgeW91LA0KTkVUTU9EIFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlz dGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNlLg0KDQo= --_000_F9182F8A52B54A78A592C93B99577EFDjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <719FB7560BBA6245A043AD94FAF95971@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPg0KPGRpdj5bVGhpcyByZWdhcmRzIHRoZSBuZXcg cHJlLWFkb3B0aW9uIHByb2Nlc3MgZGVzY3JpYmVkIGJ5IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cxNTUyMC5odG1sXTwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij48 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+QXV0aG9ycywg Q29udHJpYnV0b3JzLCBXRyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVy OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPkFzIHBh cnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGwsIGFyZSB5b3UgYXdhcmUgb2Yg YW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92ZT8gJm5ic3A7UGxl YXNlIHN0YXRlIGVpdGhlcjo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVy OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPiZuYnNw OyAmbmJzcDsgJnF1b3Q7Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMg dG8gdGhpcyBkcmFmdCZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJp ZXI7Ij5vcjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij4mbmJzcDsg Jm5ic3A7ICZxdW90O1llcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBk cmFmdCZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij48YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+SWYgc28sIGhhcyB0 aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXM8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+KHNlZSBSRkNzIDM5Nzks IDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/ICZuYnNwO0lmIHllcyB0byB0 aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENv dXJpZXI7Ij4mbmJzcDsgJm5ic3A7ICZxdW90O1llcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9z ZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzJnF1b3Q7PC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPm9yPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ291cmllcjsiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7Tm8sIHRoZSBJUFIgaGFzIG5vdCBi ZWVuIGRpc2Nsb3NlZCZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJp ZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+SWYg eW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3Ug dGhpbms8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+YXBwcm9wcmlh dGUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5JZiB5b3UgYXJlIGxpc3RlZCBh cyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZSBhYm92 ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5v dCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1lbnQgd2lsbCBu b3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbA0KIGEgcmVzcG9uc2UgaGFzIGJlZW4g cmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1dG9yLiBOT1RFOiBU SElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdF4oCZUyBUTyBM SU5FUy48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPklmIHlvdSBhcmUgb24gdGhl IFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZCBh cyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0 aW9ucyB1bmRlciB0aGUgSUVURiBJUFIgcnVsZXMgd2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90 aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUgYXdhcmUgb2YgSVBSDQogb2Ygb3RoZXJzIG9uIGFuIElF VEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkg Y29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQ Ui4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3Zl IGFuZCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cv dHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Ij5odHRwOi8vdHJhYy50b29scy5pZXRmLm9y Zy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eTwvYT4uPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5UaGFuayB5b3UsPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQ291cmllcjsiPk5FVE1PRCBXRyBDaGFpcnM8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ291cmllcjsiPlBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRl cnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIgcmVzcG9uc2UuPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_F9182F8A52B54A78A592C93B99577EFDjunipernet_-- From nobody Wed Mar 16 11:27:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2796212DA8B for ; Wed, 16 Mar 2016 11:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 IxWb1YKcADvL for ; Wed, 16 Mar 2016 11:27:50 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB4412DA89 for ; Wed, 16 Mar 2016 11:27:49 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id l202so25768117lfl.2 for ; Wed, 16 Mar 2016 11:27:49 -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:date:message-id:subject:from:cc; bh=lCjsFzBRFDnghHmjX1s9WzvUqpM2VC1YsiDiIwtuTTQ=; b=kQhXFEcI8UGwHZEFIz2oi3ig4sewRBEsvZ+IWeXGRr8lxk/kyV/YFSqoOWcY2jSY1F YJZvjgF6sOQejVfb2/+SQERIEvDMsibjH0FkVTa0AI2ojjw+q94zW0XbVCavsDISxRlI LWrcS/jTiPviEIS36ThHWQDfzCZhQZJ/eh5McDFDFEK+otdRSJXxl8wcW3dCvfFcQMle PNU5q89CZOyr9LZvC8ocDW5Ioyto77YWxDg0UCzN8fXjIeArU9UdaTJC3DdtSROf69gM A57K8eTt6JYzqu36dxmgu1S64EY1apOqWQDj5Mnvwp6NaEsORbGNrDt0Xc9Vr5/A+/yL j8Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc; bh=lCjsFzBRFDnghHmjX1s9WzvUqpM2VC1YsiDiIwtuTTQ=; b=McGwy7fnT00txnxXLQAR9weZDowD01kHW+7GaF2mked3aindQW8saaYM0YMlDuTNI9 pDeJKk1f/cGQzlwwszg/Pg4MF1KhnCWHOvZ2asYejkzlkHDFtcwhULV2J9WSOEH5ReXH VzffxmMrA5q//83c7ol0qbyYAcz2BehilzOuCLqoF5Aes9DwhqBUMJ1oZy7elMFGvZH6 7xeUn3aXid57SqvFQwVzCm/YUIQjcypRtt1uBUb1TSyYKPQeWS8DRG9E5QKYdP9xSf8i yhIu3mjBmpSGln+z/gtG2IAunjUzfXNakaTtHwn9QtqRUUSpQDbX/ZpemX5OcCcAmJeo 1/JA== X-Gm-Message-State: AD7BkJIotSU2W+H7QOIfXhgj9kZkONE/15yyitXvenkSqPFGlb91eR+LbYFUk7pI3GnDg5URX0qZWrOd0kUWGg== MIME-Version: 1.0 X-Received: by 10.25.148.71 with SMTP id w68mt72184lfd.23.1458152867884; Wed, 16 Mar 2016 11:27:47 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Wed, 16 Mar 2016 11:27:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Mar 2016 11:27:47 -0700 Message-ID: From: Andy Bierman Content-Type: multipart/alternative; boundary=001a11401494bac37a052e2eabfe Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Regarding IPR on draft-entitydt-netmod-entity 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, 16 Mar 2016 18:27:52 -0000 --001a11401494bac37a052e2eabfe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, No, I'm not aware of any IPR that applies to this draft Andy On Wed, Mar 16, 2016 at 11:19 AM, Kent Watsen wrote: > [This regards the new pre-adoption process described by > http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html] > > > Authors, Contributors, WG, > > As part of the preparation for WG Last Call, are you aware of any IPR tha= t > applies to draft identified above? Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the > above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next sta= ge > until a response has been received from each author and listed contributo= r. > NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE=E2=80=99S TO LINE= S. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under the > IETF IPR rules which encourages you to notify the IETF if you are aware o= f > IPR of others on an IETF contribution, or to refrain from participating i= n > any contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NETMOD WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > --001a11401494bac37a052e2eabfe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

No, I'm not aware of any IPR that appl= ies to this draft


Andy

On Wed, Mar 16, 2016 at 11:19 AM, Kent W= atsen <kwatsen@juniper.net> wrote:
[This regards the new pre-adoption process described by http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html]


Authors, Contributors, WG,

As part of the preparation for WG Last C= all, are you aware of any IPR that applies to draft identified above?=C2=A0= Please state either:

=C2=A0 =C2=A0 "No, I'm not awar= e of any IPR that applies to this draft"
or
=C2=A0 =C2=A0 "Yes, I'm aware o= f IPR that applies to this draft"

If so, has this IPR been disclosed in co= mpliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for = more details)?=C2=A0 If yes to the above, please state either:

=C2=A0 =C2=A0 "Yes, the IPR has bee= n disclosed in compliance with IETF IPR rules"
or
=C2=A0 =C2=A0 "No, the IPR has not = been disclosed"

If you answer no, please provide any add= itional details you think
appropriate.

If you are listed as a document author o= r contributor please answer the above by responding to this email regardles= s of whether or not you are aware of any relevant IPR. This document will n= ot advance to the next stage until a response has been received from each author and listed contributor. NOTE= : THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE=E2=80=99S TO LINES.


--001a11401494bac37a052e2eabfe-- From nobody Wed Mar 16 11:53:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2AD12DA90; Wed, 16 Mar 2016 11:53:00 -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=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 QbMKBA8vqL2m; Wed, 16 Mar 2016 11:52:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::780]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C174D12DAAA; Wed, 16 Mar 2016 11:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zUhIrmN997JfKmvZKTkkNnmY4DemmGvOZLIHiE6PaRg=; b=Ax0KJrSa+v95xYXRo5LFJ1cKFcyGcdZF4H/3L8Wsm/FydP7kXPTvGaAnFQ38gOA70eGV3eUKH+sbVvCTkF3NUnnbWbRK3Ph1/FjqU3YLALamEMlZsTCfj5ZRieL7OFIEamiwfWu8iy3xbsZoi2B8VtDTaQnKFcllOI+oYA97vsU= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CO2PR0501MB1000.namprd05.prod.outlook.com (10.160.10.139) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 18:52:37 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0434.016; Wed, 16 Mar 2016 18:52:36 +0000 From: Kent Watsen To: "rwilton@cisco.com" , "daviball@cisco.com" , Selvakumar Sivaraj Thread-Topic: Regarding IPR on draft-wilton-netmod-intf-vlan-yang Thread-Index: AQHRf7UBKZSP0lcWWUeZHr8YytB+kw== Date: Wed, 16 Mar 2016 18:52:36 +0000 Message-ID: <1C382F23-CC30-42CC-BF4D-BB6D3BF0DE51@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 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-ms-office365-filtering-correlation-id: 09892e54-82bf-4572-7634-08d34dcc2479 x-microsoft-exchange-diagnostics: 1; CO2PR0501MB1000; 5:1urb2R9AXD1jD31sQCocQBB1/4UqmyKLjA297iZsLD2p/XpfRAuJ1xTN8UoZh70aiJG0wVtfHLnljW2+9cyRS/RMiITP/YM5uoajBO1VQOi2uPCIiIZqtgtASSFWdWySNj4TsHjM8UhJXVw1m07/Qw==; 24:3ACZZfi3O+rH/gGZOLp5VaBot3OnZlcMa/4tqU8PLjiMLK5wWIDsGp1wf3Q0mZSl0/twmYY86XXvs1oYtZ7tzwDn8IC21OXBZcURdUXtwKw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB1000; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:CO2PR0501MB1000; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0501MB1000; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(10400500002)(19580395003)(87936001)(6116002)(1220700001)(1096002)(102836003)(3846002)(5008740100001)(33656002)(82746002)(83506001)(122556002)(36756003)(83716003)(4001450100002)(586003)(5004730100002)(4326007)(3280700002)(3660700001)(81166005)(2906002)(106116001)(229853001)(2501003)(5002640100001)(19617315012)(4001350100001)(5001770100001)(16236675004)(189998001)(66066001)(77096005)(15975445007)(2900100001)(54356999)(50986999)(92566002)(230783001)(86362001)(99286002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB1000; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_1C382F23CC3042CCBF4DBB6D3BF0DE51junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 18:52:36.9353 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0501MB1000 Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: [netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang 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, 16 Mar 2016 18:53:00 -0000 --_000_1C382F23CC3042CCBF4DBB6D3BF0DE51junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W1RoaXMgcmVnYXJkcyB0aGUgbmV3IHByZS1hZG9wdGlvbiBwcm9jZXNzIGRlc2NyaWJlZCBieSBo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTU1 MjAuaHRtbF0NCg0KDQpBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0KDQpBcyBwYXJ0IG9mIHRo ZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFzdCBDYWxsLCBhcmUgeW91IGF3YXJlIG9mIGFueSBJUFIg dGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZpZWQgYWJvdmU/ICBQbGVhc2Ugc3RhdGUgZWl0 aGVyOg0KDQogICAgIk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRv IHRoaXMgZHJhZnQiDQpvcg0KICAgICJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVz IHRvIHRoaXMgZHJhZnQiDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4g Y29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2 OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8gIElmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFz ZSBzdGF0ZSBlaXRoZXI6DQoNCiAgICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBp biBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQpvcg0KICAgICJObywgdGhlIElQUiBo YXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlk ZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluaw0KYXBwcm9wcmlhdGUuDQoNCklmIHlv dSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBh bnN3ZXIgdGhlIGFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9m IHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBk b2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9u c2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1 dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNT QUdF4oCZUyBUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBh dHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250 cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRG IElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91 IGFyZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0 byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1 c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRp b24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZCBodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCg0K VGhhbmsgeW91LA0KTkVUTU9EIFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlz dGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNlLg0KDQo= --_000_1C382F23CC3042CCBF4DBB6D3BF0DE51junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <7D5A33EAB47EDB469B2082507E2F9F07@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+W1RoaXMgcmVn YXJkcyB0aGUgbmV3IHByZS1hZG9wdGlvbiBwcm9jZXNzIGRlc2NyaWJlZCBieSZuYnNwOzxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9t c2cxNTUyMC5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9k L2N1cnJlbnQvbXNnMTU1MjAuaHRtbDwvYT5dPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJp ZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+QXV0 aG9ycywgQ29udHJpYnV0b3JzLCBXRyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD b3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsi PkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGwsIGFyZSB5b3UgYXdh cmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92ZT8gJm5i c3A7UGxlYXNlIHN0YXRlIGVpdGhlcjo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD b3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsi PiZuYnNwOyAmbmJzcDsgJnF1b3Q7Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFw cGxpZXMgdG8gdGhpcyBkcmFmdCZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENvdXJpZXI7Ij5vcjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij4m bmJzcDsgJm5ic3A7ICZxdW90O1llcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8g dGhpcyBkcmFmdCZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7 Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+SWYgc28s IGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIg cnVsZXM8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+KHNlZSBSRkNz IDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/ICZuYnNwO0lmIHll cyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6PC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IENvdXJpZXI7Ij4mbmJzcDsgJm5ic3A7ICZxdW90O1llcywgdGhlIElQUiBoYXMgYmVlbiBk aXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzJnF1b3Q7PC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPm9yPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQ291cmllcjsiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7Tm8sIHRoZSBJUFIgaGFz IG5vdCBiZWVuIGRpc2Nsb3NlZCZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENvdXJpZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVy OyI+SWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWls cyB5b3UgdGhpbms8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+YXBw cm9wcmlhdGUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5JZiB5b3UgYXJlIGxp c3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRo ZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVy IG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1lbnQg d2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbA0KIGEgcmVzcG9uc2UgaGFz IGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1dG9yLiBO T1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdF4oCZ UyBUTyBMSU5FUy48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPklmIHlvdSBhcmUg b24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxp c3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBv YmxpZ2F0aW9ucyB1bmRlciB0aGUgSUVURiBJUFIgcnVsZXMgd2hpY2ggZW5jb3VyYWdlcyB5b3Ug dG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUgYXdhcmUgb2YgSVBSDQogb2Ygb3RoZXJzIG9u IGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBp biBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xv c2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVk IGFib3ZlIGFuZCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3Vw L2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Ij5odHRwOi8vdHJhYy50b29scy5p ZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eTwvYT4uPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5UaGFuayB5b3UsPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPk5FVE1PRCBXRyBDaGFpcnM8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQ291cmllcjsiPlBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhl IGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIgcmVzcG9uc2UuPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19T SUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_1C382F23CC3042CCBF4DBB6D3BF0DE51junipernet_-- From nobody Wed Mar 16 11:53:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6816712DAA7; Wed, 16 Mar 2016 11:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=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 AfRnKyZniNDV; Wed, 16 Mar 2016 11:53:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C1512DAB6; Wed, 16 Mar 2016 11:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tdKTXL5GyLuoGawQfBM7eSKmYQNxfuQZpEUPY9+Drk0=; b=WYCb2yqAUnQUhnRYoHzR6zJxa7pIcXmkRaZHWugdUeN1kxA+qGUkwljDF9wMp9xNcPISpL6Zb+DUGBm5k+BE0ZVKMwncR1AleQm4/9HDR/8A0F4eLt7gm8aLP/c4s9T8r1K9HVYgrY9ktnrSCnMA/HbVqXzmBUD7BuKz9E3evIk= Received: from SN2PR0501MB1006.namprd05.prod.outlook.com (10.160.57.140) by BY1PR0501MB1448.namprd05.prod.outlook.com (10.160.108.12) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 18:53:06 +0000 Received: from SN2PR0501MB1006.namprd05.prod.outlook.com ([10.160.57.140]) by SN2PR0501MB1006.namprd05.prod.outlook.com ([10.160.57.140]) with mapi id 15.01.0427.021; Wed, 16 Mar 2016 18:53:06 +0000 From: Selvakumar Sivaraj To: Kent Watsen , "rwilton@cisco.com" , "daviball@cisco.com" , Tapraj Singh Thread-Topic: Regarding IPR on draft-wilton-netmod-intf-ext-yang Thread-Index: AQHRf7UTAZD2nUTCQUCEoTWNgXQELg== Date: Wed, 16 Mar 2016 18:53:06 +0000 Message-ID: <4AF30285-9E82-4418-AE83-DDA3B0684378@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-ms-office365-filtering-correlation-id: b3973c53-610c-4fcb-50fd-08d34dcc35d8 x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1448; 5:4HuiLvJt7rom/bccXx8z5PBpH8Sus5pZ72VJf4UJoyZoLXPdPCNjuJQkvXo3oLDNXUca7xFu8xoZtQDls31M0H9AeE+3flUAmHO17leZFX04/vB0vmVjF68vIdYVbKgtg0rT4y6qmOMZl5RTZkvygQ==; 24:4kmBc/l1AvJHJMEpZgcY/mV6c71TFw1ioX7aoWVh9HntgTDMtvQ6jz9NMj8ULi87AiPmFk6VLSpe6bTqX35NNWJGYBrPpKCe23a5o+WJMpc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1448; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY1PR0501MB1448; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1448; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(164054003)(54356999)(5004730100002)(3280700002)(81166005)(36756003)(83506001)(82746002)(230783001)(99286002)(5008740100001)(77096005)(5001770100001)(4001450100002)(50986999)(16236675004)(86362001)(2201001)(4001350100001)(106116001)(33656002)(66066001)(11100500001)(92566002)(15975445007)(122556002)(19617315012)(87936001)(2501003)(3660700001)(5002640100001)(1096002)(189998001)(1220700001)(586003)(3846002)(19580395003)(19580405001)(2906002)(2900100001)(4326007)(102836003)(10400500002)(6116002)(83716003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1448; H:SN2PR0501MB1006.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_4AF302859E824418AE83DDA3B0684378junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 18:53:06.0470 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1448 Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-ext-yang 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, 16 Mar 2016 18:53:40 -0000 --_000_4AF302859E824418AE83DDA3B0684378junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMg ZHJhZnQuDQoNClRoYW5rcywNClNlbHZha3VtYXINCg0KDQpGcm9tOiBLZW50IFdhdHNlbiA8a3dh dHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+DQpEYXRlOiBXZWRu ZXNkYXksIE1hcmNoIDE2LCAyMDE2IGF0IDExOjE4IEFNDQpUbzogInJ3aWx0b25AY2lzY28uY29t PG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4iIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndp bHRvbkBjaXNjby5jb20+PiwgImRhdmliYWxsQGNpc2NvLmNvbTxtYWlsdG86ZGF2aWJhbGxAY2lz Y28uY29tPiIgPGRhdmliYWxsQGNpc2NvLmNvbTxtYWlsdG86ZGF2aWJhbGxAY2lzY28uY29tPj4s IFRhcHJhaiBTaW5naCA8dHNpbmdoQGp1bmlwZXIubmV0PG1haWx0bzp0c2luZ2hAanVuaXBlci5u ZXQ+PiwgU2VsdmFrdW1hciBTaXZhcmFqIDxzc2l2YXJhakBqdW5pcGVyLm5ldDxtYWlsdG86c3Np dmFyYWpAanVuaXBlci5uZXQ+Pg0KQ2M6ICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBp ZXRmLm9yZz4iIDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+LCAibmV0 bW9kLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz4iIDxuZXRt b2QtY2hhaXJzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtY2hhaXJzQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nDQoN CltUaGlzIHJlZ2FyZHMgdGhlIG5ldyBwcmUtYWRvcHRpb24gcHJvY2VzcyBkZXNjcmliZWQgYnkg aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzE1 NTIwLmh0bWxdDQoNCkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0csDQoNCkFzIHBhcnQgb2YgdGhl IHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGwsIGFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0 aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92ZT8gIFBsZWFzZSBzdGF0ZSBlaXRo ZXI6DQoNCiAgICAiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8g dGhpcyBkcmFmdCINCm9yDQogICAgIlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMg dG8gdGhpcyBkcmFmdCINCg0KSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBj b21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5 IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPyAgSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNl IHN0YXRlIGVpdGhlcjoNCg0KICAgICJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGlu IGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCm9yDQogICAgIk5vLCB0aGUgSVBSIGhh cyBub3QgYmVlbiBkaXNjbG9zZWQiDQoNCklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRl IGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rDQphcHByb3ByaWF0ZS4NCg0KSWYgeW91 IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFu c3dlciB0aGUgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRv Y3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25z ZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQgY29udHJpYnV0 b3IuIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NB R0XigJlTIFRPIExJTkVTLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0 dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRy aWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYg SVBSIHJ1bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3Ug YXJlIGF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRv IHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vz c2lvbiByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlv biwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kIGh0dHA6Ly90cmFjLnRvb2xz LmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpU aGFuayB5b3UsDQpORVRNT0QgV0cgQ2hhaXJzDQoNClBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0 ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIgcmVzcG9uc2UuDQoNCg== --_000_4AF302859E824418AE83DDA3B0684378junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <92EF4AF2DCCB23438FBBF174A6CE1B1A@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jywgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPkhpLDwvc3Bhbj48 L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9z cGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5Obywg SSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ljwvc3Bh bj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0K PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5U aGFua3MsPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJp ZXI7Ij5TZWx2YWt1bWFyPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IENvdXJpZXI7Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09V VExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29s b3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVt IG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJ R0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1l ZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5Gcm9tOiA8L3NwYW4+S2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprd2F0c2Vu QGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSwgTWFyY2ggMTYsIDIw MTYgYXQgMTE6MTggQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwv c3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iPnJ3aWx0b25AY2lz Y28uY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIj5y d2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZGF2aWJhbGxA Y2lzY28uY29tIj5kYXZpYmFsbEBjaXNjby5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86ZGF2aWJhbGxAY2lzY28uY29tIj5kYXZpYmFsbEBjaXNjby5jb208L2E+Jmd0OywNCiBUYXBy YWogU2luZ2ggJmx0OzxhIGhyZWY9Im1haWx0bzp0c2luZ2hAanVuaXBlci5uZXQiPnRzaW5naEBq dW5pcGVyLm5ldDwvYT4mZ3Q7LCBTZWx2YWt1bWFyIFNpdmFyYWogJmx0OzxhIGhyZWY9Im1haWx0 bzpzc2l2YXJhakBqdW5pcGVyLm5ldCI+c3NpdmFyYWpAanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9 Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7LCAm cXVvdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9yZyI+bmV0bW9kLWNoYWly c0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtY2hhaXJzQGll dGYub3JnIj5uZXRtb2QtY2hhaXJzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlZ2FyZGluZyBJUFIgb24gZHJhZnQt d2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nDQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIg c3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFS R0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb3VyaWVyOyI+W1RoaXMgcmVnYXJkcyB0aGUgbmV3IHByZS1hZG9wdGlvbiBwcm9jZXNzIGRl c2NyaWJlZCBieQ0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L25ldG1vZC9jdXJyZW50L21zZzE1NTIwLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cxNTUyMC5odG1sPC9hPl08L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQ291cmllcjsiPkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0csPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5BcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3Ig V0cgTGFzdCBDYWxsLCBhcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRy YWZ0IGlkZW50aWZpZWQgYWJvdmU/ICZuYnNwO1BsZWFzZSBzdGF0ZSBlaXRoZXI6PC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij4mbmJzcDsgJm5ic3A7ICZxdW90O05vLCBJJ20gbm90 IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVvdDs8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+b3I8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+Jm5ic3A7ICZuYnNwOyAmcXVvdDtZZXMsIEknbSBhd2Fy ZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVvdDs8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQ291cmllcjsiPklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4g Y29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ291cmllcjsiPihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBt b3JlIGRldGFpbHMpPyAmbmJzcDtJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0 aGVyOjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij48YnI+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+Jm5ic3A7ICZuYnNwOyAmcXVv dDtZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRG IElQUiBydWxlcyZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7 Ij5vcjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij4mbmJzcDsgJm5i c3A7ICZxdW90O05vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQmcXVvdDs8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92 aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQ291cmllcjsiPmFwcHJvcHJpYXRlLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IENvdXJpZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb3VyaWVyOyI+SWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29u dHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVt YWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVs ZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3Rh Z2UgdW50aWwNCiBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3Ig YW5kIGxpc3RlZCBjb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1Ug TElTVEVEIElOIFRISVMgTUVTU0FHReKAmVMgVE8gTElORVMuPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IENvdXJpZXI7Ij5JZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBX RyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9y LCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1 bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3 YXJlIG9mIElQUg0KIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVm cmFpbiBmcm9tIHBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9u IHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBw bGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZSBhbmQmbmJzcDs8YSBocmVmPSJodHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9w ZXJ0eSI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50 ZWxsZWN0dWFsUHJvcGVydHk8L2E+LjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENv dXJpZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+ VGhhbmsgeW91LDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5ORVRN T0QgV0cgQ2hhaXJzPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5QUyBQbGVhc2Ug aW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3Vy IHJlc3BvbnNlLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg aWQ9IiI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3Nw YW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4AF302859E824418AE83DDA3B0684378junipernet_-- From nobody Wed Mar 16 11:56:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3011212DAA7; Wed, 16 Mar 2016 11:56:07 -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=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 45SduvwAw72P; Wed, 16 Mar 2016 11:56:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB0412DA8F; Wed, 16 Mar 2016 11:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CBPGBUFcitKdhnAIOMsDx9sF5hMPM6ef7xT3jgFlzkg=; b=YyENYgiVlG5vnjqwZtB4p/qWx/ueY3KUGFSIDQS6wURIFVXLk4gIhzdqnU5TfVm+LaGucqVKhNzaTPQ+O8CIsbjHVEPL729d47VUcgMniDuddLkgzOAT9XXyGQMtkxHW2DN0pEsfB34fKKsmO4i/OfNHGPIFZFkikYkFuYjAmvU= Received: from SN2PR0501MB1006.namprd05.prod.outlook.com (10.160.57.140) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 18:55:40 +0000 Received: from SN2PR0501MB1006.namprd05.prod.outlook.com ([10.160.57.140]) by SN2PR0501MB1006.namprd05.prod.outlook.com ([10.160.57.140]) with mapi id 15.01.0427.021; Wed, 16 Mar 2016 18:55:40 +0000 From: Selvakumar Sivaraj To: Kent Watsen , "rwilton@cisco.com" , "daviball@cisco.com" Thread-Topic: Regarding IPR on draft-wilton-netmod-intf-vlan-yang Thread-Index: AQHRf7UBKZSP0lcWWUeZHr8YytB+k59b9hsA Date: Wed, 16 Mar 2016 18:55:40 +0000 Message-ID: <4DE4A5BB-19E6-4A34-8914-2C31E26E71EA@juniper.net> References: <1C382F23-CC30-42CC-BF4D-BB6D3BF0DE51@juniper.net> In-Reply-To: <1C382F23-CC30-42CC-BF4D-BB6D3BF0DE51@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-ms-office365-filtering-correlation-id: 9923fb6d-5567-4df2-53ac-08d34dcc91f2 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 5:a8BRviA1g6eh0shyDxkACyUTIrctMxgS4G5gXYFv8n6yNvZr2FBv1vssno0uL3soHsBYFRmQhpsJOfsnwM7PEZ8peAMJ66iam5SXFR6rfrCDAY+qpGW+FqBf5T/AqqtD4f0g4nat9ikoMWw5GqXeXw==; 24:mnCKE8DXEzu3tSyVDuTMjgvg8sv9kfbSFCkF4OV5432hBoBWpmCmpGrvckszguHq01Vuf/WWAjxcpt2FzdfzKUYhmSpe5DieOU5bWxp7ENE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1450; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(377454003)(5001770100001)(586003)(83506001)(82746002)(15975445007)(122556002)(4001350100001)(66066001)(77096005)(3660700001)(189998001)(230783001)(5008740100001)(106116001)(2501003)(1096002)(11100500001)(1220700001)(87936001)(99286002)(50986999)(36756003)(5004730100002)(2900100001)(2950100001)(6116002)(81166005)(4326007)(102836003)(3846002)(5002640100001)(10400500002)(76176999)(19580395003)(92566002)(83716003)(3280700002)(86362001)(2906002)(2201001)(19580405001)(19617315012)(54356999)(16236675004)(33656002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:SN2PR0501MB1006.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_4DE4A5BB19E64A3489142C31E26E71EAjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 18:55:40.5685 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1450 Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang 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, 16 Mar 2016 18:56:07 -0000 --_000_4DE4A5BB19E64A3489142C31E26E71EAjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Ik5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQi DQoNClRoYW5rcywNClNlbHZha3VtYXINCg0KDQpGcm9tOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBq dW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+DQpEYXRlOiBXZWRuZXNkYXks IE1hcmNoIDE2LCAyMDE2IGF0IDExOjUyIEFNDQpUbzogInJ3aWx0b25AY2lzY28uY29tPG1haWx0 bzpyd2lsdG9uQGNpc2NvLmNvbT4iIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBj aXNjby5jb20+PiwgImRhdmliYWxsQGNpc2NvLmNvbTxtYWlsdG86ZGF2aWJhbGxAY2lzY28uY29t PiIgPGRhdmliYWxsQGNpc2NvLmNvbTxtYWlsdG86ZGF2aWJhbGxAY2lzY28uY29tPj4sIFNlbHZh a3VtYXIgU2l2YXJhaiA8c3NpdmFyYWpAanVuaXBlci5uZXQ8bWFpbHRvOnNzaXZhcmFqQGp1bmlw ZXIubmV0Pj4NCkNjOiAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8 bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+PiwgIm5ldG1vZC1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc+IiA8bmV0bW9kLWNoYWlyc0Bp ZXRmLm9yZzxtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZWdhcmRp bmcgSVBSIG9uIGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi12bGFuLXlhbmcNCg0KW1RoaXMgcmVn YXJkcyB0aGUgbmV3IHByZS1hZG9wdGlvbiBwcm9jZXNzIGRlc2NyaWJlZCBieSBodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTU1MjAuaHRtbF0N Cg0KDQpBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0KDQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJh dGlvbiBmb3IgV0cgTGFzdCBDYWxsLCBhcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBs aWVzIHRvIGRyYWZ0IGlkZW50aWZpZWQgYWJvdmU/ICBQbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQog ICAgIk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJh ZnQiDQpvcg0KICAgICJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMg ZHJhZnQiDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5j ZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3 OCBmb3IgbW9yZSBkZXRhaWxzKT8gIElmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBl aXRoZXI6DQoNCiAgICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlh bmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQpvcg0KICAgICJObywgdGhlIElQUiBoYXMgbm90IGJl ZW4gZGlzY2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRk aXRpb25hbCBkZXRhaWxzIHlvdSB0aGluaw0KYXBwcm9wcmlhdGUuDQoNCklmIHlvdSBhcmUgbGlz dGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBhbnN3ZXIgdGhl IGFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIg b3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1bWVudCB3 aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJl ZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1dG9yLiBOT1RF OiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdF4oCZUyBU TyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cg bWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwg d2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxl cyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2Fy ZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWlu IGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVs YXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFz ZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZCBodHRwOi8vdHJhYy50b29scy5pZXRmLm9y Zy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCg0KVGhhbmsgeW91 LA0KTkVUTU9EIFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRo ZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNlLg0KDQo= --_000_4DE4A5BB19E64A3489142C31E26E71EAjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <770D113578571B44838A8786B1C17E6F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jywgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPiZxdW90O05vLCBJ J20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVvdDs8 L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPjxi cj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVy OyI+VGhhbmtzLDwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBD b3VyaWVyOyI+U2VsdmFrdW1hcjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1B Q19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7 IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1l ZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElO Ry1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hU OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPktlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a3dh dHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIE1hcmNoIDE2 LCAyMDE2IGF0IDExOjUyIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRv OiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIj5yd2lsdG9u QGNpc2NvLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNv bSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRhdmli YWxsQGNpc2NvLmNvbSI+ZGF2aWJhbGxAY2lzY28uY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmRhdmliYWxsQGNpc2NvLmNvbSI+ZGF2aWJhbGxAY2lzY28uY29tPC9hPiZndDssDQog U2VsdmFrdW1hciBTaXZhcmFqICZsdDs8YSBocmVmPSJtYWlsdG86c3NpdmFyYWpAanVuaXBlci5u ZXQiPnNzaXZhcmFqQGp1bmlwZXIubmV0PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYu b3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9k QGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRv Om5ldG1vZC1jaGFpcnNAaWV0Zi5vcmciPm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9yZyI+bmV0bW9kLWNoYWly c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1 YmplY3Q6IDwvc3Bhbj5SZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi12 bGFuLXlhbmc8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0i TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAj YjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb3VyaWVyOyI+W1RoaXMgcmVnYXJkcyB0aGUgbmV3IHByZS1hZG9wdGlvbiBwcm9jZXNzIGRl c2NyaWJlZCBieSZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9uZXRtb2QvY3VycmVudC9tc2cxNTUyMC5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTU1MjAuaHRtbDwvYT5dPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb3VyaWVyOyI+QXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRyw8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQ291cmllcjsiPkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBM YXN0IENhbGwsIGFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQg aWRlbnRpZmllZCBhYm92ZT8gJm5ic3A7UGxlYXNlIHN0YXRlIGVpdGhlcjo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQ291cmllcjsiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7Tm8sIEknbSBub3QgYXdh cmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCZxdW90OzwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5vcjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IENvdXJpZXI7Ij4mbmJzcDsgJm5ic3A7ICZxdW90O1llcywgSSdtIGF3YXJlIG9m IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IENvdXJpZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBDb3VyaWVyOyI+SWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21w bGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXM8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb3VyaWVyOyI+KHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUg ZGV0YWlscyk/ICZuYnNwO0lmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6 PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij4mbmJzcDsgJm5ic3A7ICZxdW90O1ll cywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBS IHJ1bGVzJnF1b3Q7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPm9y PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPiZuYnNwOyAmbmJzcDsg JnF1b3Q7Tm8sIHRoZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCZxdW90OzwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+SWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUg YW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbms8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb3VyaWVyOyI+YXBwcm9wcmlhdGUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENv dXJpZXI7Ij5JZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmli dXRvciBwbGVhc2UgYW5zd2VyIHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwg cmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFu dCBJUFIuIFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1 bnRpbA0KIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQg bGlzdGVkIGNvbnRyaWJ1dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNU RUQgSU4gVEhJUyBNRVNTQUdF4oCZUyBUTyBMSU5FUy48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog Q291cmllcjsiPklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1l ZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdl IHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUgSUVURiBJUFIgcnVsZXMg d2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUgYXdhcmUg b2YgSVBSDQogb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWlu IGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVs YXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFz ZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90cmFj LnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5 Ij5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxl Y3R1YWxQcm9wZXJ0eTwvYT4uPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmll cjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5UaGFu ayB5b3UsPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPk5FVE1PRCBX RyBDaGFpcnM8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPlBTIFBsZWFzZSBpbmNs dWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIgcmVz cG9uc2UuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IGlkPSIiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4DE4A5BB19E64A3489142C31E26E71EAjunipernet_-- From nobody Wed Mar 16 12:19:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06C812D624; Wed, 16 Mar 2016 11:39:33 -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=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 XaIGnVgwd1MR; Wed, 16 Mar 2016 11:39:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA81812D610; Wed, 16 Mar 2016 11:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fSbjA8D2VXw9JnH5zelkr5jJmCGSTdeEyFhMqgp+QZc=; b=PiAshsUtkqb5IOcJIIBD+w0Nb7c+uXqDrlceWKbShkHQTdFly6PXYTToShfKAtr5WWGeI6R+8H9TnYWbprLmgKpQa4NCwBx/g+P0kXQNkGsaJy0xeRPW7rgwhFwPkHilfiijosc0oyiyds9NrSah6DoUSM9bXgOLd5IXBPBXboY= Received: from BLUPR0501MB1761.namprd05.prod.outlook.com (10.163.120.28) by BLUPR0501MB0994.namprd05.prod.outlook.com (10.160.34.12) with Microsoft SMTP Server (TLS) id 15.1.443.12; Wed, 16 Mar 2016 18:39:13 +0000 Received: from BLUPR0501MB1761.namprd05.prod.outlook.com ([10.163.120.28]) by BLUPR0501MB1761.namprd05.prod.outlook.com ([10.163.120.28]) with mapi id 15.01.0434.019; Wed, 16 Mar 2016 18:39:13 +0000 From: Tapraj Singh To: Kent Watsen Thread-Topic: Regarding IPR on draft-wilton-netmod-intf-ext-yang Thread-Index: AQHRf7A+AZD2nUTCQUCEoTWNgXQELp9cZuXh Date: Wed, 16 Mar 2016 18:39:13 +0000 Message-ID: <356434E4-FF21-4848-BD32-8BC38D98CA9F@juniper.net> References: <255CBF2A-E225-4B37-AE62-35D0BFC2BEFD@juniper.net> In-Reply-To: <255CBF2A-E225-4B37-AE62-35D0BFC2BEFD@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; x-originating-ip: [73.189.111.142] x-ms-office365-filtering-correlation-id: cd60db38-a0fe-47a0-19d8-08d34dca45c2 x-microsoft-exchange-diagnostics: 1; BLUPR0501MB0994; 5:9rFPQgcwzq6M+DJOjn1nFe/lVprKFIDTIzLPcJuxBA4Gha3V0Q93Njy9gayINZq3VYuEwgfpobTYxho2WRSSVL58NhJeSbc+sbVWSwbfRUpZOk+Mbj9kSql7Pxy1lfisIt6XZw/AApbODl4ONI59Vg==; 24:KHvjJ1i35MErtOCbUSWsmezxISeXO1JBx8VMOvShIcFYVhz+XIRROv+3KIx+H53A92fRv8cGvbHc9VRdds/z3iwZQLMMLKYocKJaz4SfllU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB0994; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR0501MB0994; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB0994; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(53754006)(92566002)(3280700002)(36756003)(81166005)(16236675004)(110136002)(82746002)(2906002)(189998001)(122556002)(33656002)(5004730100002)(10400500002)(4001450100002)(3660700001)(5002640100001)(19617315012)(83716003)(99286002)(86362001)(1096002)(1220700001)(106116001)(87936001)(5008740100001)(54356999)(4326007)(15975445007)(76176999)(230783001)(11100500001)(77096005)(50986999)(2950100001)(3846002)(19580405001)(19580395003)(2900100001)(586003)(66066001)(6116002)(102836003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB0994; H:BLUPR0501MB1761.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_356434E4FF214848BD328BC38D98CA9Fjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 18:39:13.7712 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB0994 Archived-At: X-Mailman-Approved-At: Wed, 16 Mar 2016 12:19:05 -0700 Cc: "daviball@cisco.com" , "netmod@ietf.org" , "netmod-chairs@ietf.org" Subject: Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-ext-yang 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, 16 Mar 2016 18:39:34 -0000 --_000_356434E4FF214848BD328BC38D98CA9Fjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I am not aware of any IPR. I fully support this draft as a co author. Thanks Tapraj On Mar 16, 2016, at 11:18 AM, Kent Watsen > wrote: [This regards the new pre-adoption process described by http://www.ietf.org= /mail-archive/web/netmod/current/msg15520.html] Authors, Contributors, WG, As part of the preparation for WG Last Call, are you aware of any IPR that = applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above= , please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until = a response has been received from each author and listed contributor. NOTE:= THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF= IPR rules which encourages you to notify the IETF if you are aware of IPR = of others on an IETF contribution, or to refrain from participating in any = contribution or discussion related to your undisclosed IPR. For more inform= ation, please see the RFCs listed above and http://trac.tools.ietf.org/grou= p/iesg/trac/wiki/IntellectualProperty. Thank you, NETMOD WG Chairs PS Please include all listed in the headers of this message in your respons= e. --_000_356434E4FF214848BD328BC38D98CA9Fjunipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
  I am not aware of any IPR. 
I fully support this draft as a co author.

Thanks
Tapraj

On Mar 16, 2016, at 11:18 AM, Kent Watsen <kwatsen@juniper.net> wrote:

[This regards the new pre-adoption pro= cess described by http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html]<= /div>

Authors, Contributors, WG,

As part of the preparation for WG Last= Call, are you aware of any IPR that applies to draft identified above? &nb= sp;Please state either:

    "No, I'm not aware = of any IPR that applies to this draft"
or
    "Yes, I'm aware of = IPR that applies to this draft"

If so, has this IPR been disclosed in = compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 fo= r more details)?  If yes to the above, please state either:

    "Yes, the IPR has b= een disclosed in compliance with IETF IPR rules"
or
    "No, the IPR has no= t been disclosed"

If you answer no, please provide any a= dditional details you think
appropriate.

If you are listed as a document author= or contributor please answer the above by responding to this email regardl= ess of whether or not you are aware of any relevant IPR. This document will= not advance to the next stage until a response has been received from each author and listed contributor. NOTE= : THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE’S TO LINES.

If you are on the WG email list or att= end WG meetings but are not listed as an author or contributor, we remind y= ou of your obligations under the IETF IPR rules which encourages you to not= ify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any= contribution or discussion related to your undisclosed IPR. For more infor= mation, please see the RFCs listed above and http://trac.tools.i= etf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NETMOD WG Chairs

PS Please include all listed in the he= aders of this message in your response.

--_000_356434E4FF214848BD328BC38D98CA9Fjunipernet_-- From nobody Wed Mar 16 12:37:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDB912D744; Wed, 16 Mar 2016 12:37:32 -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 pUaz0NYn30_w; Wed, 16 Mar 2016 12:37:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A6A0612D6CF; Wed, 16 Mar 2016 12:37:30 -0700 (PDT) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 8D6E31AE0290; Wed, 16 Mar 2016 20:37:29 +0100 (CET) Date: Wed, 16 Mar 2016 20:37:29 +0100 (CET) Message-Id: <20160316.203729.1064760217658660830.mbj@tail-f.com> To: kwatsen@juniper.net 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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org Subject: Re: [netmod] Regarding IPR on draft-entitydt-netmod-entity 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, 16 Mar 2016 19:37:33 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuDQoNCltCVFcs IHlvdSBzaG91bGQgY2hhbmdlIHRoZSB0ZXh0IGZyb20gInByZXBhcmF0aW9uIGZvciBXRyBMYXN0 IENhbGwiDQp0byAicHJlcGFyYXRpb24gZm9yIFdHIGFkb3B0aW9uIiBvciBzb21ldGhpbmcuXQ0K DQoNCi9tYXJ0aW4NCg0KDQpLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6 DQo+IFtUaGlzIHJlZ2FyZHMgdGhlIG5ldyBwcmUtYWRvcHRpb24gcHJvY2VzcyBkZXNjcmliZWQg YnkgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21z ZzE1NTIwLmh0bWxdDQo+IA0KPiANCj4gQXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCj4gDQo+ IEFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGwsIGFyZSB5b3UgYXdh cmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92ZT8gIFBs ZWFzZSBzdGF0ZSBlaXRoZXI6DQo+IA0KPiAgICAgIk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJ UFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQo+IG9yDQo+ICAgICAiWWVzLCBJJ20gYXdh cmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KPiANCj4gSWYgc28sIGhhcyB0 aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMN Cj4gKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/ ICBJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0KPiANCj4gICAgICJZ ZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQ UiBydWxlcyINCj4gb3INCj4gICAgICJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2Vk Ig0KPiANCj4gSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwg ZGV0YWlscyB5b3UgdGhpbmsNCj4gYXBwcm9wcmlhdGUuDQo+IA0KPiBJZiB5b3UgYXJlIGxpc3Rl ZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZSBh Ym92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9y IG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1lbnQgd2ls bCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVu IHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRvci4gTk9URTog VEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHReKAmVMgVE8g TElORVMuDQo+IA0KPiBJZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBX RyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9y LCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1 bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3 YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJh aW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiBy ZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxl YXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYu b3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KPiANCj4gVGhh bmsgeW91LA0KPiBORVRNT0QgV0cgQ2hhaXJzDQo+IA0KPiBQUyBQbGVhc2UgaW5jbHVkZSBhbGwg bGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNlLg0K PiANCg== From nobody Wed Mar 16 12:49:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D1E12D695 for ; Wed, 16 Mar 2016 12:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 Aon8fhmqPtHI for ; Wed, 16 Mar 2016 12:49:12 -0700 (PDT) Received: from s12p02o149.mxlogic.net (s12p02o149.mxlogic.net [208.65.145.72]) (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 82C6A12D6A9 for ; Wed, 16 Mar 2016 12:48:56 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by s12p02o149.mxlogic.net(mxl_mta-8.5.0-8) with ESMTP id 8a8b9e65.7fa1c35fe700.116435.00-522.347798.s12p02o149.mxlogic.net (envelope-from ); Wed, 16 Mar 2016 13:48:56 -0600 (MDT) X-MXL-Hash: 56e9b8a8455e5616-3340ea299574ae0dce68a884a8a26d1d3a74efdd Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by s12p02o149.mxlogic.net(mxl_mta-8.5.0-8) over TLS secured channel with ESMTP id 5a8b9e65.0.116350.00-270.347515.s12p02o149.mxlogic.net (envelope-from ); Wed, 16 Mar 2016 13:48:55 -0600 (MDT) X-MXL-Hash: 56e9b8a70cda379f-436317e99d3105681c904a27bddd3bca7c938742 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0266.001; Wed, 16 Mar 2016 14:48:50 -0500 From: STUART VENTERS To: "'Eric Voit (evoit)'" Thread-Topic: [netmod] Differentiating the types of Mount Thread-Index: AdF/OD2NJ3Cq4cCSQLyujReGzdHIoQAZ+8KAAACU0PAAC9tEgAAH75xA Date: Wed, 16 Mar 2016 19:48:50 +0000 Message-ID: <1220E2C537595D439C5D026E83751866E7B4C20C@ex-mb1.corp.adtran.com> References: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> <20160316112329.GB39598@elstar.local> <1220E2C537595D439C5D026E83751866E7B4C101@ex-mb1.corp.adtran.com> <020f5d85b38d46d5a09940e8e89cc37e@XCH-RTP-013.cisco.com> In-Reply-To: <020f5d85b38d46d5a09940e8e89cc37e@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.118.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=YJeZvEyx c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=0eaKXOXVzoQA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=7OsogOcEt9IA:10 a=OUixTkr] X-AnalysisOut: [4AAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8] X-AnalysisOut: [ a=ctln6_MMGif9rZKV0rYA:9 a=0VwNEXvxz8D-2UrO:21 a=VnkF6kAX] X-AnalysisOut: [1a-BOEtW:21 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJ] X-AnalysisOut: [tCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10] X-Spam: [F=0.5100000000; CM=0.500; MH=0.510(2016031613); S=0.434(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: Cc: "Martin Bjorklund \(mbjorklu\)" , "netmod@ietf.org" Subject: Re: [netmod] Differentiating the types of Mount 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, 16 Mar 2016 19:49:15 -0000 Eric, I did the suggested OpenDaylight (ODL)search, and yes there is a lot of ac= tivity there. There are a lot of trees in that forest. The best overview I found seems to be here. https://wiki.opendaylight.org/view/OpenDaylight_Controller:_SAL_Architectur= e_Overview#Nested_Subsystems Mapping my words to ODL, My Sibling is the ODL Nested system. My Parent might be ODL Top-level Subsystem? Having had lunch to think about it, I don't think I should have picked NetC= onf as a place to choose what data to mount. I suspect it should be somewhere in the application, separate for both Yang= and Netconf. ODL appears to use the Northbound Restconf interface to do this function Stepping back, for this mounting stuff, there are at least 3 issues: 1) Specifying a where in the Parent schema to put the sibling schema. 2) Specifying the type of the sibling. 3) Specifying what sibling data instance to put at a specific parent node d= ata instance. I think Yang would be a great place to do 1 and 2, but I think the applica= tion should handle 3. ODL appears to put 1) in Yang, I'm not sure about 2), and 3) in the applic= ation. Your proposed definition's mention of data-tree appears to put 3 into Yang = with appears to conflict with ODL. Since you clearly don't want however Yang turns out to collide with ODL, bu= t appear to be proposing something that collides, I must not understand? Another use case: ODL Yang device mounting is about grafting and removing whole, existing dev= ices as branches in a single tree on a running system. For this, there may be some benefit in treating the grafted branch as a spe= cial sort of node in the tree. Having a special keyword like 'mount' might help this, or the application f= unction that does 3) above could handle it. Another use case is simply making a big device model by grafting together s= maller, whole, existing models. In this case, the benefit may be to make the grafted branch look like a non= -special vanilla node in the tree. In this case, I don't see the benefit over a special keyword like 'mount' o= ver an existing one like 'uses'. Regards, Stuart -----Original Message----- From: Eric Voit (evoit) [mailto:evoit@cisco.com]=20 Sent: Wednesday, March 16, 2016 12:20 PM To: STUART VENTERS Cc: netmod@ietf.org; Martin Bjorklund (mbjorklu); 'Juergen Schoenwaelder' Subject: RE: [netmod] Differentiating the types of Mount > From: STUART VENTERS, March 16, 2016 12:58 PM >=20 > Defining a schema-tree seems Yang's strong suite. > I'm not sure if the suite extends to defining what goes into a=20 > data-tree governed by the schema-tree. Hi Stuart, Open Daylight has found Mounting YANG data from one device to another has p= roven central to their effort. Doing a quick Google search for "mount site= :opendaylight.org" gives 800+ results. Based on that, I was hoping that being defining the variants of Mount acros= s different constituencies would help us not collide as the technologies ev= olve. This includes a shared definition of "YANG Mount" which shows what i= s common across all efforts. Thanks, Eric =20 > Perhaps: >=20 > YANG Mount > ---------------- > Definition: An abstracted term for a YANG mechanism that grafts a=20 > sibling schema-tree as a subtree of a parent schema-tree. > Purpose: Provides flexibility by enabling the growth of YANG models=20 > via an explicit reference to other YANG models defined elsewhere. >=20 > Given the ability to specify a combined schema-tree, maybe something=20 > at the protocol level could specify what data to use to populate the graf= ted tree. > This could provide a place to specify details like who has ownership=20 > of the data, if it is RW, etc. >=20 > NETCONF Mount > ------------------ > Definition: An abstracted term for a NETCONF mechanism to construct a=20 > combined data-tree according to a schema defined with YANG mount. > Purpose: ... >=20 >=20 >=20 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: Wednesday, March 16, 2016 6:23 AM > To: Eric Voit (evoit) > Cc: netmod@ietf.org; Martin Bjorklund (mbjorklu) > Subject: Re: [netmod] Differentiating the types of Mount >=20 > On Wed, Mar 16, 2016 at 03:59:50AM +0000, Eric Voit (evoit) wrote: > > To help differentiate between concepts and drafts, below are=20 > > strawman > definitions for the various types of Mount which we have been discussing = over > the last year in Netmod. Thoughts/suggestions? > > > > YANG Mount > > ---------------- > > Definition: An abstracted term for a mechanism that a parent YANG=20 > > model can > use to link in YANG information defined or located elsewhere. > > Purpose: Provides model flexibility by enabling the growth of YANG=20 > > trees via > an explicit reference to other YANG information and structures. >=20 > Trying to rewrite the definition to be more consistent with existing > terminology: >=20 > The abstract concept of incorporating a YANG-defined data tree (the > mounted data tree) into a existing YANG-defined data tree (the > parent data tree). >=20 > Well, this is not really correct, perhaps we have to just say 'tree' > instead of 'data tree' since a schema mount (as I understand it) seems=20 > to incorporate a schema tree into another schema tree while the other=20 > two mounts incorporate a data tree into a data tree. So perhaps the=20 > general definition is something like this: >=20 > The abstract concept of incorporating a YANG-defined data tree or > schema tree (the mounted data or schema tree) into a existing > YANG-defined data tree or schema tree (the parent data tree). >=20 > The schema mount then essentially removes data tree and the other two=20 > mounts remove the schema tree from this definition. >=20 > Is your alias mount simply a special case of a peer mount where the=20 > peer is local? Or is there more to it? In other words, would it be=20 > reasonable to think of the terms in this way: >=20 > +-> schema (tree) mount > | > mount -> | +-> local data tree (alias) mount > +-> data (tree) mount -> | > +-> remote data tree (peer) mount >=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 From nobody Wed Mar 16 15:35:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CE512D591 for ; Wed, 16 Mar 2016 15:35: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_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 AGZVNjOdmb10 for ; Wed, 16 Mar 2016 15:35:48 -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 C2CB812D568 for ; Wed, 16 Mar 2016 15:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8281; q=dns/txt; s=iport; t=1458167748; x=1459377348; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2YE0AfSiaiN6z5y9FYw/Nfd3MQcXfRF9zug1lQjvLbA=; b=l/4GnR3MzqgG6fU8I/oJHnncbt5zsC14uQ/V71QA6DTAyOwyR8c8ZDZV XBYQ3pLETLQTrRicm7kj4lN4WQN5Afo24zForHq2RyegB/s2TPkvPnnPz mGhGiNjA/LCGa/3q9L9/QQ8V96Q3ppSHIHQ/xvhroPWYaoJFKumniTyjq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgB93ulW/4QNJK1bA4NGU24GugYBD?= =?us-ascii?q?YFvFwyFIEoCgUI4FAEBAQEBAQFkJ4RBAQEBAwEBAQEkEzQLBQcCAgIBCBABBAE?= =?us-ascii?q?BAR4JBxsMCxQJCAEBBA4FCBGIBggOwF0BAQEBAQEBAQEBAQEBAQEBAQEBAQEVB?= =?us-ascii?q?IYag0V/hEsSJoNzBYdgj3EBhW6IC4I3jFWOfgEeAQFCggMZgUlqiWV+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,346,1454976000"; d="scan'208";a="83584471" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Mar 2016 22:35:47 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u2GMZkba026788 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 22:35:47 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Mar 2016 18:35:46 -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.1104.009; Wed, 16 Mar 2016 18:35:46 -0400 From: "Eric Voit (evoit)" To: STUART VENTERS Thread-Topic: [netmod] Differentiating the types of Mount Thread-Index: AdF/OD2NJ3Cq4cCSQLyujReGzdHIoQAX41GAAAuwc4AACCa0AP//7ngAgAAh1pA= Date: Wed, 16 Mar 2016 22:35:46 +0000 Message-ID: <878f650eb3d8414c970313e0403d8964@XCH-RTP-013.cisco.com> References: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> <20160316112329.GB39598@elstar.local> <1220E2C537595D439C5D026E83751866E7B4C101@ex-mb1.corp.adtran.com> <020f5d85b38d46d5a09940e8e89cc37e@XCH-RTP-013.cisco.com> <1220E2C537595D439C5D026E83751866E7B4C20C@ex-mb1.corp.adtran.com> In-Reply-To: <1220E2C537595D439C5D026E83751866E7B4C20C@ex-mb1.corp.adtran.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.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Martin Bjorklund \(mbjorklu\)" , "netmod@ietf.org" Subject: Re: [netmod] Differentiating the types of Mount 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, 16 Mar 2016 22:35:51 -0000 Hi Stuart, Thanks for the thoughts. More in-line... > From: STUART VENTERS. March 16, 2016 3:49 PM >=20 > Eric, >=20 > I did the suggested OpenDaylight (ODL)search, and yes there is a lot of = activity > there. There are a lot of trees in that forest. >=20 > The best overview I found seems to be here. > https://wiki.opendaylight.org/view/OpenDaylight_Controller:_SAL_Architect= ure > _Overview#Nested_Subsystems >=20 > Mapping my words to ODL, > My Sibling is the ODL Nested system. > My Parent might be ODL Top-level Subsystem? >=20 > Having had lunch to think about it, I don't think I should have picked Ne= tConf as > a place to choose what data to mount. > I suspect it should be somewhere in the application, separate for both Ya= ng and > Netconf. > ODL appears to use the Northbound Restconf interface to do this function > >=20 > Stepping back, for this mounting stuff, there are at least 3 issues: > 1) Specifying a where in the Parent schema to put the sibling schema. > 2) Specifying the type of the sibling. > 3) Specifying what sibling data instance to put at a specific parent node= data > instance. >=20 > I think Yang would be a great place to do 1 and 2, but I think the appli= cation > should handle 3. > ODL appears to put 1) in Yang, I'm not sure about 2), and 3) in the appl= ication. > Your proposed definition's mention of data-tree appears to put 3 into Yan= g with > appears to conflict with ODL. ODL Mounts instance data. One example showing how applications can get to = that can be seen at: http://sdntutorials.com/how-to-access-data-in-md-sal-from-mount-point/ > Since you clearly don't want however Yang turns out to collide with ODL, = but > appear to be proposing something that collides, I must not understand? I don't see the collision of (3) with the originally proposed definition fo= r "Peer Mount". It might be worth looking at: https://tools.ietf.org/html/draft-clemm-netmod-mount-03=20 which was used an initial seed for ODL's implementation of Peer Mount. > Another use case: > ODL Yang device mounting is about grafting and removing whole, existing > devices as branches in a single tree on a running system. Grafting, yes. Not sure about removing as the Mount is a reference, not an= actual relocation. > For this, there may be some benefit in treating the grafted branch as a s= pecial > sort of node in the tree. > Having a special keyword like 'mount' might help this, or the application= function > that does 3) above could handle it. There certainly are trade-offs between application-centric data representat= ion and infrastructure-centric representation. Open Daylight is a good tes= t-case here as it provides network-wide abstractions to a diverse applicati= on set. (I.e., the end-goal of Peer Mount always has been simplifying lif= e for the application developer, and these network-wide abstractions are in= tended for this purpose.) =20 > Another use case is simply making a big device model by grafting together > smaller, whole, existing models. > In this case, the benefit may be to make the grafted branch look like a n= on- > special vanilla node in the tree. > In this case, I don't see the benefit over a special keyword like 'mount'= over an > existing one like 'uses'. Peer Mount and Alias Mount are intended to enable the referencing of existi= ng, populated data trees. =20 Eric =20 > Regards, >=20 > Stuart >=20 >=20 > -----Original Message----- > From: Eric Voit (evoit) [mailto:evoit@cisco.com] > Sent: Wednesday, March 16, 2016 12:20 PM > To: STUART VENTERS > Cc: netmod@ietf.org; Martin Bjorklund (mbjorklu); 'Juergen Schoenwaelder' > Subject: RE: [netmod] Differentiating the types of Mount >=20 > > From: STUART VENTERS, March 16, 2016 12:58 PM > > > > Defining a schema-tree seems Yang's strong suite. > > I'm not sure if the suite extends to defining what goes into a > > data-tree governed by the schema-tree. >=20 > Hi Stuart, >=20 > Open Daylight has found Mounting YANG data from one device to another has > proven central to their effort. Doing a quick Google search for "mount > site:opendaylight.org" gives 800+ results. >=20 > Based on that, I was hoping that being defining the variants of Mount acr= oss > different constituencies would help us not collide as the technologies ev= olve. > This includes a shared definition of "YANG Mount" which shows what is com= mon > across all efforts. >=20 > Thanks, > Eric >=20 > > Perhaps: > > > > YANG Mount > > ---------------- > > Definition: An abstracted term for a YANG mechanism that grafts a > > sibling schema-tree as a subtree of a parent schema-tree. > > Purpose: Provides flexibility by enabling the growth of YANG models > > via an explicit reference to other YANG models defined elsewhere. > > > > Given the ability to specify a combined schema-tree, maybe something > > at the protocol level could specify what data to use to populate the gr= afted > tree. > > This could provide a place to specify details like who has ownership > > of the data, if it is RW, etc. > > > > NETCONF Mount > > ------------------ > > Definition: An abstracted term for a NETCONF mechanism to construct a > > combined data-tree according to a schema defined with YANG mount. > > Purpose: ... > > > > > > > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Wednesday, March 16, 2016 6:23 AM > > To: Eric Voit (evoit) > > Cc: netmod@ietf.org; Martin Bjorklund (mbjorklu) > > Subject: Re: [netmod] Differentiating the types of Mount > > > > On Wed, Mar 16, 2016 at 03:59:50AM +0000, Eric Voit (evoit) wrote: > > > To help differentiate between concepts and drafts, below are > > > strawman > > definitions for the various types of Mount which we have been discussin= g over > > the last year in Netmod. Thoughts/suggestions? > > > > > > YANG Mount > > > ---------------- > > > Definition: An abstracted term for a mechanism that a parent YANG > > > model can > > use to link in YANG information defined or located elsewhere. > > > Purpose: Provides model flexibility by enabling the growth of YANG > > > trees via > > an explicit reference to other YANG information and structures. > > > > Trying to rewrite the definition to be more consistent with existing > > terminology: > > > > The abstract concept of incorporating a YANG-defined data tree (the > > mounted data tree) into a existing YANG-defined data tree (the > > parent data tree). > > > > Well, this is not really correct, perhaps we have to just say 'tree' > > instead of 'data tree' since a schema mount (as I understand it) seems > > to incorporate a schema tree into another schema tree while the other > > two mounts incorporate a data tree into a data tree. So perhaps the > > general definition is something like this: > > > > The abstract concept of incorporating a YANG-defined data tree or > > schema tree (the mounted data or schema tree) into a existing > > YANG-defined data tree or schema tree (the parent data tree). > > > > The schema mount then essentially removes data tree and the other two > > mounts remove the schema tree from this definition. > > > > Is your alias mount simply a special case of a peer mount where the > > peer is local? Or is there more to it? In other words, would it be > > reasonable to think of the terms in this way: > > > > +-> schema (tree) mount > > | > > mount -> | +-> local data tree (alias) mount > > +-> data (tree) mount -> | > > +-> remote data tree (peer) mount > > > > /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 16 16:12:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AB412D70D; Wed, 16 Mar 2016 16:12:52 -0700 (PDT) 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 LLAnZzyhgzR0; Wed, 16 Mar 2016 16:12:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E63912D63C; Wed, 16 Mar 2016 16:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YAlYUH8VSD3hUOx2UpFkZV9nRRNtgCLI07HsmcOYKbg=; b=b980+Qq3JgldoPePajqrIdpBdcqAI1n5w5sNGDsgjrVKIBv8wlJx14CgxE/aIDVxVIHAgx2t+Mucnp37j98SB/dyl5Gqm7uplEuZUgykJv3pnprTm7JEX3T+RytG/RffGo9BDqwaWNir/k4HAO8nK0VMAPUx5k9cV4XyuSOghiQ= 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 (TLS) id 15.1.434.16; Wed, 16 Mar 2016 23:12: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.0434.019; Wed, 16 Mar 2016 23:12:47 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: Regarding IPR on draft-entitydt-netmod-entity Thread-Index: AQHRf7BxxemTCcwE1U6mVSvZjJQnep9cdyyA///5GAA= Date: Wed, 16 Mar 2016 23:12:47 +0000 Message-ID: <7C79E09D-D583-43D3-A488-13E1F86295E8@juniper.net> References: <20160316.203729.1064760217658660830.mbj@tail-f.com> In-Reply-To: <20160316.203729.1064760217658660830.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 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.14] x-ms-office365-filtering-correlation-id: 7d60f3c4-ff07-427d-090e-08d34df07ce5 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:wLHH+/WA8e2T2cxl6I4vQvtal9LR/AnLApcKRilwUQuBw8UuDBGvtTsWIOwQbIXXtPgtoDByUSKz2h3ECVMgnq2B6jt88ud6uv9nnq+gCRZY1QVveEgzWL3ZkYIdvwniLzL2WzUFhS2+ClpamfjU/Q==; 24:L1u/h/1rl8hpLMGDKDYe5zkB9AiApTFCQPmTGg2sHknSbLYehRN/S217fAKh3YbWB/WLPly22zMzL7Dm08IcN5vvd/VGg/6CxNziE6DPQi0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(377454003)(164054003)(36756003)(230783001)(81166005)(19580395003)(19580405001)(106116001)(86362001)(66066001)(83716003)(122556002)(99286002)(33656002)(5004730100002)(10400500002)(83506001)(82746002)(1096002)(1220700001)(5008740100001)(4326007)(2906002)(586003)(2900100001)(92566002)(2950100001)(102836003)(3846002)(6116002)(11100500001)(5002640100001)(87936001)(3660700001)(3280700002)(4001350100001)(50986999)(110136002)(189998001)(15975445007)(54356999)(76176999)(77096005)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9347CF7C96BB2D41B2C93E42A106246A@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 23:12:47.0840 (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" , "netmod@ietf.org" Subject: Re: [netmod] Regarding IPR on draft-entitydt-netmod-entity 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, 16 Mar 2016 23:12:52 -0000 DQpNeSBtaXN0YWtlLCBJIHNpbXBseSBjb3BpZWQgdGhhdCB0ZXh0IGZyb20gdGhlIHJlZmVyZW5j ZWQgZW1haWwgd2l0aG91dCB0aGlua2luZyBhYm91dCBjaGFuZ2luZyB0aGF0IHRleHQuICBJdCB3 b3VsZOKAmXZlIGhlbHBlZCBpZiB0aGUgdGVtcGxhdGUgSSB1c2VkIHJlcGxhY2VkIOKAnFdHIExh c3QgQ2FsbOKAnSB3aXRoIOKAnFdHIDxMYXN0IENhbGx8QWRvcHRpb24+4oCdLiAgDQoNCkxvdSwg aGF2ZSB5b3UgcG9zdGVkIHRoZSB0ZW1wbGF0ZSBhbnl3aGVyZSB5ZXQ/DQoNClRoYW5rcywNCktl bnQNCg0KDQoNCg0KDQoNCk9uIDMvMTYvMTYsIDM6MzcgUE0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8 bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KDQo+SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxh dGVkIHRvIHRoaXMgZHJhZnQuDQo+DQo+W0JUVywgeW91IHNob3VsZCBjaGFuZ2UgdGhlIHRleHQg ZnJvbSAicHJlcGFyYXRpb24gZm9yIFdHIExhc3QgQ2FsbCINCj50byAicHJlcGFyYXRpb24gZm9y IFdHIGFkb3B0aW9uIiBvciBzb21ldGhpbmcuXQ0KPg0KPg0KPi9tYXJ0aW4NCj4NCj4NCj5LZW50 IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+PiBbVGhpcyByZWdhcmRzIHRo ZSBuZXcgcHJlLWFkb3B0aW9uIHByb2Nlc3MgZGVzY3JpYmVkIGJ5IGh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cxNTUyMC5odG1sXQ0KPj4gDQo+ PiANCj4+IEF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0csDQo+PiANCj4+IEFzIHBhcnQgb2YgdGhl IHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGwsIGFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0 aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92ZT8gIFBsZWFzZSBzdGF0ZSBlaXRo ZXI6DQo+PiANCj4+ICAgICAiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxp ZXMgdG8gdGhpcyBkcmFmdCINCj4+IG9yDQo+PiAgICAgIlllcywgSSdtIGF3YXJlIG9mIElQUiB0 aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCj4+IA0KPj4gSWYgc28sIGhhcyB0aGlzIElQUiBi ZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCj4+IChzZWUg UkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPyAgSWYgeWVz IHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCj4+IA0KPj4gICAgICJZZXMsIHRo ZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxl cyINCj4+IG9yDQo+PiAgICAgIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQo+ PiANCj4+IElmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRl dGFpbHMgeW91IHRoaW5rDQo+PiBhcHByb3ByaWF0ZS4NCj4+IA0KPj4gSWYgeW91IGFyZSBsaXN0 ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUg YWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBv ciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50IHdp bGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVl biByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQgY29udHJpYnV0b3IuIE5PVEU6 IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0XigJlTIFRP IExJTkVTLg0KPj4gDQo+PiBJZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVu ZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1 dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBS IHJ1bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJl IGF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJl ZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lv biByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwg cGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kIGh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KPj4gDQo+ PiBUaGFuayB5b3UsDQo+PiBORVRNT0QgV0cgQ2hhaXJzDQo+PiANCj4+IFBTIFBsZWFzZSBpbmNs dWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIgcmVz cG9uc2UuDQo+PiANCg== From nobody Thu Mar 17 02:27:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D119812D5AA; Thu, 17 Mar 2016 02:27:57 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 xnsTfZ01cFEw; Thu, 17 Mar 2016 02:27:55 -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 B72FC12D7AA; Thu, 17 Mar 2016 02:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6796; q=dns/txt; s=iport; t=1458206875; x=1459416475; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=QCCHj5BPIxaCuql56N+Ej1c1Bw9/s4ikcxOg2D7KE8U=; b=aZZZxvp6te/SgfhGBs2XvTrMDpCBk407fSBJws85QLXlqJCmqbK6jHUt auf1fR8yPCb2QbRq50UF5xYdXCFPQUqHDXI9pgxmeH3mARM1KASVTKAIP l5T2fCg38T2LO7e2lCBlDaVIV+RajaGqoe4NsrMNmtnShvAIO/ZprDKgy I=; X-IronPort-AV: E=Sophos;i="5.24,349,1454976000"; d="scan'208,217";a="634515540" 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; 17 Mar 2016 09:27:53 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2H9RqcI015697; Thu, 17 Mar 2016 09:27:52 GMT To: Kent Watsen , "daviball@cisco.com" , Tapraj Singh , Selvakumar Sivaraj References: <255CBF2A-E225-4B37-AE62-35D0BFC2BEFD@juniper.net> From: Robert Wilton Message-ID: <56EA7898.1030906@cisco.com> Date: Thu, 17 Mar 2016 09:27:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <255CBF2A-E225-4B37-AE62-35D0BFC2BEFD@juniper.net> Content-Type: multipart/alternative; boundary="------------030606020403080302070908" Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-ext-yang 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, 17 Mar 2016 09:27:58 -0000 This is a multi-part message in MIME format. --------------030606020403080302070908 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit No, I'm not aware of any IPR that applies to this draft. Thanks, Rob On 16/03/2016 18:18, Kent Watsen wrote: > [This regards the new pre-adoption process described by > http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html] > > Authors, Contributors, WG, > > As part of the preparation for WG Last Call, are you aware of any IPR > that applies to draft identified above? Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the > above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer > the above by responding to this email regardless of whether or not you > are aware of any relevant IPR. This document will not advance to the > next stage until a response has been received from each author and > listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE’S TO LINES. > > If you are on the WG email list or attend WG meetings but are not > listed as an author or contributor, we remind you of your obligations > under the IETF IPR rules which encourages you to notify the IETF if > you are aware of IPR of others on an IETF contribution, or to refrain > from participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed > above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NETMOD WG Chairs > > PS Please include all listed in the headers of this message in your > response. > --------------030606020403080302070908 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit No, I'm not aware of any IPR that applies to this draft.

Thanks,
Rob


On 16/03/2016 18:18, Kent Watsen wrote:
[This regards the new pre-adoption process described by http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html]

Authors, Contributors, WG,

As part of the preparation for WG Last Call, are you aware of any IPR that applies to draft identified above?  Please state either:

    "No, I'm not aware of any IPR that applies to this draft"
or
    "Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?  If yes to the above, please state either:

    "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
    "No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE’S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NETMOD WG Chairs

PS Please include all listed in the headers of this message in your response.


--------------030606020403080302070908-- From nobody Thu Mar 17 02:28:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F8312D7AA; Thu, 17 Mar 2016 02:28:30 -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_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 ZeUReOcC4GW0; Thu, 17 Mar 2016 02:28:28 -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 E70C412D5AA; Thu, 17 Mar 2016 02:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7574; q=dns/txt; s=iport; t=1458206908; x=1459416508; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=qzAQXvVNAILI8pIoYBgsbQpqu/4W00al/P4K4ZPugT8=; b=ROFvoyj0Kso/OrOySPzKcqasr8FDPMnazJuRxihCw59qLk4xd/qfdUCA dI6mLssAcsFEw6LdDkbDl0adgnU7W2ZXKxY6KrK8jN6b6iVgqGh+Nr7yP QxOCi0oBQ8/wpevNdZnGe/anI4qG1eSwwgLRvGoan72tASO+pZfm1MfLs w=; X-IronPort-AV: E=Sophos;i="5.24,349,1454976000"; d="scan'208,217";a="636328839" 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; 17 Mar 2016 09:28:26 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2H9SPea019276; Thu, 17 Mar 2016 09:28:26 GMT To: Kent Watsen , "daviball@cisco.com" , Selvakumar Sivaraj References: <1C382F23-CC30-42CC-BF4D-BB6D3BF0DE51@juniper.net> From: Robert Wilton Message-ID: <56EA78B9.3060405@cisco.com> Date: Thu, 17 Mar 2016 09:28:25 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1C382F23-CC30-42CC-BF4D-BB6D3BF0DE51@juniper.net> Content-Type: multipart/alternative; boundary="------------020005070202010109080509" Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang 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, 17 Mar 2016 09:28:30 -0000 This is a multi-part message in MIME format. --------------020005070202010109080509 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit No, I'm not aware of any IPR that applies to this draft. Thanks, Rob On 16/03/2016 18:52, Kent Watsen wrote: > [This regards the new pre-adoption process described by > http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html] > > > Authors, Contributors, WG, > > As part of the preparation for WG Last Call, are you aware of any IPR > that applies to draft identified above? Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the > above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer > the above by responding to this email regardless of whether or not you > are aware of any relevant IPR. This document will not advance to the > next stage until a response has been received from each author and > listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE’S TO LINES. > > If you are on the WG email list or attend WG meetings but are not > listed as an author or contributor, we remind you of your obligations > under the IETF IPR rules which encourages you to notify the IETF if > you are aware of IPR of others on an IETF contribution, or to refrain > from participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed > above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NETMOD WG Chairs > > PS Please include all listed in the headers of this message in your > response. > --------------020005070202010109080509 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit No, I'm not aware of any IPR that applies to this draft.

Thanks,
Rob


On 16/03/2016 18:52, Kent Watsen wrote:
[This regards the new pre-adoption process described by http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html]


Authors, Contributors, WG,

As part of the preparation for WG Last Call, are you aware of any IPR that applies to draft identified above?  Please state either:

    "No, I'm not aware of any IPR that applies to this draft"
or
    "Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?  If yes to the above, please state either:

    "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
    "No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE’S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NETMOD WG Chairs

PS Please include all listed in the headers of this message in your response.


--------------020005070202010109080509-- From nobody Thu Mar 17 02:29:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A02312D6EA; Thu, 17 Mar 2016 02:29: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] 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 zxroC6faj8gt; Thu, 17 Mar 2016 02:29:35 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 652D212D5AA; Thu, 17 Mar 2016 02:29:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B5D0F2CC9A; Thu, 17 Mar 2016 11:29:34 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY76ES7QcWsZ; Thu, 17 Mar 2016 11:29:34 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 8FB3E2CE21; Thu, 17 Mar 2016 11:29:31 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_20DD53F6-2AC5-465F-B328-51CA40A69B54"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Jari Arkko In-Reply-To: <56E2E143.6060309@nostrum.com> Date: Thu, 17 Mar 2016 08:54:51 +0000 Message-Id: <7B638CB8-1073-47B9-9FE4-381D561E4C67@piuha.net> References: <56D60EF5.7020001@nostrum.com> <56E209E3.4030805@nostrum.com> <415C6558-F5D2-4575-B380-C082171DFA21@nic.cz> <033701d17b91$710ce580$4001a8c0@gateway.2wire.net> <20160311130707.GA10591@elstar.local> <47A0C6CB-1B26-48E0-ADF4-A7D6E4AA47C0@nic.cz> <56E2E143.6060309@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: ietf@ietf.org, NETMOD WG , General Area Review Team , "tom p." , draft-ietf-netmod-yang-metadata.all@ietf.org Subject: Re: [netmod] [Gen-art] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04 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, 17 Mar 2016 09:29:38 -0000 --Apple-Mail=_20DD53F6-2AC5-465F-B328-51CA40A69B54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks, Robert and all. I have balloted no-objection for this draft on tonights=92s IESG = telechat. Jari --Apple-Mail=_20DD53F6-2AC5-465F-B328-51CA40A69B54 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW6nDbAAoJEM80gCTQU46qqjIQAKymF2E1eEUOu3Y0K6Kb9yBS jTRM4p9zvLxsk3Ftb8GY/3f8NySBX5gbxG1Rvi7VLMyfPnLIoMf1NWQGgBFfoAYr ZTFca2+CQzvncpiMu5VbpmrR9vsvoCua+31xaM8H6nP7Xul9qLpGHvrSDKwvmL6N LAVDNaBGyHpdnCsDF0DaJ+kdzoRbkRz9RUlb151H8WB/IkdyFigu0rbeyVrjpZgk WUTLinWEJI8ICTpxeDtTwoE6HAcgmANMnR4cZEbXH1FB1F/xrEtStvsqxNEMLba2 OUiVAsYz9aI23tcP4F1Z1IdwLp7Xi99gfhxK8aIUxOIbFM7bcm54CBTwYnj217IN OGNKu4ASXU2Glj7pWCqWMkQVSCRIIGuZVFYalSxp6tA2nniH/U5DAcJi3H8wnbcq Ci8d3SCrt4bwczrhOf0OAJ7e8hHAd1ZokIwklxegO9lsTQKkYPDYOS09yXGmnOzw 8dM/vTc6rD6YSLwMV3SKrXFnFqmSwOU75OzdlNhb4PLMdMW2uZuwp06RUvtlRk7X 2qiNZ9M9ukn5rQ/aga/GxH90eDhyj5m4VhlR8lIibvv8IeaMpTJ4wHziNgn7mef/ YQFpw/qowrZYKg2oquc45uph3G384TwF4qYZqpzr+yIXLTpCrxPOqVsiVUh0ZGbZ aiUrUpNYlr1Z+va6X08x =HjSz -----END PGP SIGNATURE----- --Apple-Mail=_20DD53F6-2AC5-465F-B328-51CA40A69B54-- From nobody Thu Mar 17 02:44:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F0C12D5E9; Thu, 17 Mar 2016 02:39:56 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 6Rah_8u78QY8; Thu, 17 Mar 2016 02:39:53 -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 A2C7F12D5AA; Thu, 17 Mar 2016 02:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6975; q=dns/txt; s=iport; t=1458207592; x=1459417192; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=fPRQBKu2tfZzqLzrxpz3yjr00+/UTWWs4htjm92NBBk=; b=D8jzMnzlNB2x3hNbF3EgO7q/donqZM8fc1vlt95TEaP8CTuT3sO/BgmC VtKFU32fE6jdC0IzpJ6ypkzraw2RbRjyI5EjmIkNQVvE7eOeuc72Dp5nH Z5wcxZ5q7cdFUn0PL2RYxhFglO0h2vFbpSGO6BcHM3oNKo3gCEG0GcZ1J U=; X-IronPort-AV: E=Sophos;i="5.24,349,1454976000"; d="scan'208,217";a="634515864" 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 2016 09:39:51 +0000 Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u2H9doer030751; Thu, 17 Mar 2016 09:39:50 GMT To: Kent Watsen , "rwilton@cisco.com" , Tapraj Singh , Selvakumar Sivaraj References: <255CBF2A-E225-4B37-AE62-35D0BFC2BEFD@juniper.net> From: David Ball Message-ID: <56EA7B66.80309@cisco.com> Date: Thu, 17 Mar 2016 09:39:50 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <255CBF2A-E225-4B37-AE62-35D0BFC2BEFD@juniper.net> Content-Type: multipart/alternative; boundary="------------020109090202080508060801" Archived-At: X-Mailman-Approved-At: Thu, 17 Mar 2016 02:44:05 -0700 Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-ext-yang 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, 17 Mar 2016 09:39:56 -0000 This is a multi-part message in MIME format. --------------020109090202080508060801 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit No, I'm not aware of any IPR that applies to this draft David On 16/03/2016 18:18, Kent Watsen wrote: > [This regards the new pre-adoption process described by > http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html] > > Authors, Contributors, WG, > > As part of the preparation for WG Last Call, are you aware of any IPR > that applies to draft identified above? Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the > above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer > the above by responding to this email regardless of whether or not you > are aware of any relevant IPR. This document will not advance to the > next stage until a response has been received from each author and > listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE’S TO LINES. > > If you are on the WG email list or attend WG meetings but are not > listed as an author or contributor, we remind you of your obligations > under the IETF IPR rules which encourages you to notify the IETF if > you are aware of IPR of others on an IETF contribution, or to refrain > from participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed > above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NETMOD WG Chairs > > PS Please include all listed in the headers of this message in your > response. > -- David Ball --------------020109090202080508060801 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit No, I'm not aware of any IPR that applies to this draft

    David

On 16/03/2016 18:18, Kent Watsen wrote:
[This regards the new pre-adoption process described by http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html]

Authors, Contributors, WG,

As part of the preparation for WG Last Call, are you aware of any IPR that applies to draft identified above?  Please state either:

    "No, I'm not aware of any IPR that applies to this draft"
or
    "Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?  If yes to the above, please state either:

    "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
    "No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE’S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NETMOD WG Chairs

PS Please include all listed in the headers of this message in your response.


-- 
David Ball
<daviball@cisco.com>
--------------020109090202080508060801-- From nobody Thu Mar 17 02:44:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB90412D7D6; Thu, 17 Mar 2016 02:40:27 -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_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 MbkvyQa1Blhb; Thu, 17 Mar 2016 02:40:26 -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 7BE7E12D5AA; Thu, 17 Mar 2016 02:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7755; q=dns/txt; s=iport; t=1458207625; x=1459417225; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=UhACxixpk0f+5/Ivgs652WPGeXdQGOgeNeA8hNvEWaQ=; b=XAP5vErLAw7nfIOYL5TTpdM1xSf9leHlDieu2KC2vH0CbLozw0xf5jvD hu4E+UxhZkBdIMK7w0LFqJzz4CTX+6MGYkw6fMcqyeiG9WOrfOLKNIPma 1+tP5ZHTp1x95vdqkv6Vk/axriJNJyOP1EpMBLKA/cCmnrNrwAKfSExuQ Y=; X-IronPort-AV: E=Sophos;i="5.24,349,1454976000"; d="scan'208,217";a="676080099" 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; 17 Mar 2016 09:40:23 +0000 Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2H9eNvr019056; Thu, 17 Mar 2016 09:40:23 GMT To: Kent Watsen , "rwilton@cisco.com" , Selvakumar Sivaraj References: <1C382F23-CC30-42CC-BF4D-BB6D3BF0DE51@juniper.net> From: David Ball Message-ID: <56EA7B87.6020702@cisco.com> Date: Thu, 17 Mar 2016 09:40:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1C382F23-CC30-42CC-BF4D-BB6D3BF0DE51@juniper.net> Content-Type: multipart/alternative; boundary="------------070107040205090105090503" Archived-At: X-Mailman-Approved-At: Thu, 17 Mar 2016 02:44:05 -0700 Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang 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, 17 Mar 2016 09:40:28 -0000 This is a multi-part message in MIME format. --------------070107040205090105090503 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit No, I'm not aware of any IPR that applies to this draft. David On 16/03/2016 18:52, Kent Watsen wrote: > [This regards the new pre-adoption process described by > http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html] > > > Authors, Contributors, WG, > > As part of the preparation for WG Last Call, are you aware of any IPR > that applies to draft identified above? Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the > above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer > the above by responding to this email regardless of whether or not you > are aware of any relevant IPR. This document will not advance to the > next stage until a response has been received from each author and > listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE’S TO LINES. > > If you are on the WG email list or attend WG meetings but are not > listed as an author or contributor, we remind you of your obligations > under the IETF IPR rules which encourages you to notify the IETF if > you are aware of IPR of others on an IETF contribution, or to refrain > from participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed > above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NETMOD WG Chairs > > PS Please include all listed in the headers of this message in your > response. > -- David Ball --------------070107040205090105090503 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit No, I'm not aware of any IPR that applies to this draft.

    David

On 16/03/2016 18:52, Kent Watsen wrote:
[This regards the new pre-adoption process described by http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html]


Authors, Contributors, WG,

As part of the preparation for WG Last Call, are you aware of any IPR that applies to draft identified above?  Please state either:

    "No, I'm not aware of any IPR that applies to this draft"
or
    "Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?  If yes to the above, please state either:

    "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
    "No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE’S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NETMOD WG Chairs

PS Please include all listed in the headers of this message in your response.


-- 
David Ball
<daviball@cisco.com>
--------------070107040205090105090503-- From nobody Thu Mar 17 04:33:50 2016 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 D878A12D62D; Thu, 17 Mar 2016 04:33:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 04:33:47 -0700 Archived-At: Cc: netmod-chairs@ietf.org, draft-ietf-netmod-yang-json@ietf.org, netmod@ietf.org Subject: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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: Thu, 17 Mar 2016 11:33:48 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-netmod-yang-json-09: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I would have thought that it'd be useful to point out any issues with round-tripping, e.g. going from XML to JSON and back to XML or vice-versa. But I didn't see any mention of that. How come? - I'm not sure if anyone has considered XMLDSIG or use of JOSE with YANG. If one did, then this kind of mapping would not allow one to preserve digital signatures without a lot of work. I assume that that's considered ok. (Which it can be, depending on how one does object level security, if one does object level security.) - It's not clear to me if the discussion of the secdir review [1] concluded. It seemed to just stall. Is there more to be said? (If so, be great if the shepherd would kick that discussion.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06408.html From nobody Thu Mar 17 04:41:51 2016 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 8447012D566; Thu, 17 Mar 2016 04:41:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317114149.21786.70223.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 04:41:49 -0700 Archived-At: Cc: netmod-chairs@ietf.org, draft-ietf-netmod-yang-metadata@ietf.org, netmod@ietf.org Subject: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-metadata-06: (with COMMENT) 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: Thu, 17 Mar 2016 11:41:49 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-netmod-yang-metadata-06: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 9: You could maybe add a sentence recommending to not store security or privacy sensitive information in annotations (unless it's really needed). From nobody Thu Mar 17 05:06:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D7212D92B for ; Thu, 17 Mar 2016 05:06:47 -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, 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 yip7Jn7Fs7bn for ; Thu, 17 Mar 2016 05:06:45 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 73B7C12D923 for ; Thu, 17 Mar 2016 05:06:45 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id u110so69395207qge.3 for ; Thu, 17 Mar 2016 05:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:references:to:message-id:mime-version; bh=BpvSkv4yQ7BGT4dZ0l530wkpgljvqt1uAj2sVE0Xyuo=; b=cQpKtNw7+OwCcTtJKTiV8rLN73vgt8x6lgMI5j1NC0z5bQpdL8oD+rkQoEjUW7U2XS nmGQeWxg0/o4HNFh/JLX09IVWG6d3rFWQ6YlAqAzpPSjUDZwTOuNt4i7x3sL/zp6dQYf ubKsCXcTRYH2flJekE+rQZjdECy8/c271hrLvZD4xMXmXW7SME6OMJg2X6CnSBobpvSo 1prDo1KPLiAYTIyhSWMSZvZtyR/azjT3t7UXcifzWu0qvvd8PjrGCtslqA6HpzyZG2ny QLicNzhSmraJV/2TwAS7jfgDbqlyPfcmv87MjSAkvoexTpfxwVvaZ496GaXsDn3XO78i cMtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:references:to:message-id :mime-version; bh=BpvSkv4yQ7BGT4dZ0l530wkpgljvqt1uAj2sVE0Xyuo=; b=aOT/HtiaUSEqethvCSSnPmgpQZjv9CK58jxaiiKeY9rib76G10AqqMnERBn+hWINf3 qFqQgNT9FjZ6t9+5N0QUebiLrIOFJcmPhKcLtxEqJ5UkNuhRRJ+BKUAc4ocOLql7z219 H2Bc9u5a7ypxes85zfIpcXZ1EBO85EDm3zBoKr1CE0yAF5djcVOlzNP672TJLNX4aQ1t 5IxhPdwFgTSv1gVd6MkwWwb2acZ+3JIQkuajf8YwBu3aH3uAVG54lFomIW71SySCn+6V J93pjg17tEp7Cv3wia8kML/EIZ+Il6aj2kc5lhsCnjjHN9psBVSxxtPOMm+UMgiM5p7z 8t8g== X-Gm-Message-State: AD7BkJK4VQsCZJ0vUPK6J6Hck+E7LSv3zcmc/o5hXrAD9WE+/M6E2Wnvq4UnIntdyaMxyg== X-Received: by 10.140.133.133 with SMTP id 127mr14308268qhf.42.1458216404502; Thu, 17 Mar 2016 05:06:44 -0700 (PDT) Received: from [10.0.1.3] (c-75-68-179-118.hsd1.ma.comcast.net. [75.68.179.118]) by smtp.gmail.com with ESMTPSA id p80sm3655840qge.0.2016.03.17.05.06.43 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Mar 2016 05:06:44 -0700 (PDT) From: Dean Bogdanovic Content-Type: multipart/alternative; boundary="Apple-Mail=_C4395AB5-405C-4199-8A49-EE50CAF1CD5F" Date: Thu, 17 Mar 2016 08:06:43 -0400 References: <20160311175930.27595.10104.idtracker@ietfa.amsl.com> To: NETMOD Working Group Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [netmod] Fwd: I-D Action: draft-ietf-netmod-acl-model-07.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, 17 Mar 2016 12:06:47 -0000 --Apple-Mail=_C4395AB5-405C-4199-8A49-EE50CAF1CD5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The ver 07 has incorporated comments from the WG LC and it has been = moved to YANG 1.1 Dean > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-07.txt > Date: March 11, 2016 at 12:59:30 PM EST > To: > Cc: netmod@ietf.org >=20 >=20 > 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 : Network Access Control List (ACL) YANG Data = Model > Authors : Dean Bogdanovic > Kiran Agrahara Sreenivasa > Lisa Huang > Dana Blair > Filename : draft-ietf-netmod-acl-model-07.txt > Pages : 27 > Date : 2016-03-11 >=20 > Abstract: > This document describes a data model of Access Control List (ACL) > basic building blocks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-netmod-acl-model-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model-07 >=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 --Apple-Mail=_C4395AB5-405C-4199-8A49-EE50CAF1CD5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The ver 07 has incorporated comments from the WG LC and it = has been moved to YANG 1.1

Dean

Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = [netmod] I-D = Action: draft-ietf-netmod-acl-model-07.txt
Date: = March 11, 2016 at 12:59:30 PM = EST
To: = <i-d-announce@ietf.org>
Cc: netmod@ietf.org


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
=             &n= bsp;           &nbs= p;Kiran Agrahara Sreenivasa
=             &n= bsp;           &nbs= p;Lisa Huang
=             &n= bsp;           &nbs= p;Dana Blair
Filename =        : = draft-ietf-netmod-acl-model-07.txt
Pages =           : 27
= Date =            : = 2016-03-11

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


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-07

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model= -07


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

= --Apple-Mail=_C4395AB5-405C-4199-8A49-EE50CAF1CD5F-- From nobody Thu Mar 17 05:43:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E7F12DBD8 for ; Thu, 17 Mar 2016 05:43:03 -0700 (PDT) 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 UP-MGTBOzYrT for ; Thu, 17 Mar 2016 05:43:00 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id B498912D7C8 for ; Thu, 17 Mar 2016 05:42:55 -0700 (PDT) Received: (qmail 11830 invoked by uid 0); 17 Mar 2016 12:42:47 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 17 Mar 2016 12:42:47 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id X0ib1s00h2SSUrH010ierP; Thu, 17 Mar 2016 06:42:47 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=uzSlmYvlyRAA:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=QEXdDO2ut3YA:10 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:Cc:To:From; bh=ZZTMF2/jZaBEB404gwLWcp/chEB9FLfng0GQOKjxLMM=; b=PBbJQWX17rYo+NXcGexe1B+w5j Aj8oshcX1jb2gpPAl90UAvgiE8tcGIstUEZG1D9eWcAOVIsUQR7o1/4aM3dvU7V1/j7l0RklJM0YI KSTPe4VmoClxReKd3uUGJUdWv; Received: from box313.bluehost.com ([69.89.31.113]:33316 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1agXG7-0002fr-MY; Thu, 17 Mar 2016 06:42:35 -0600 From: Lou Berger To: Martin Bjorklund , Ladislav Lhotka Message-ID: <56EAA638.1000406@labn.net> Date: Thu, 17 Mar 2016 08:42:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "netmod-chairs@ietf.org" , netmod WG Subject: [netmod] Regarding IPR on draft-bjorklund-netmod-structural-mount and draft-lhotka-netmod-ysdl 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, 17 Mar 2016 12:43:03 -0000 Authors, Contributors, WG, As part of the preparation for WG Adoption Are you aware of any IPR that applies to drafts identified above? [NOTE: Adoption poll will be on the first draft, but authors have agreed that -01 WG revision will be based on both.] Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, NETMOD WG Chairs PS Please include all listed in the headers of this message in your response. From nobody Thu Mar 17 05:59:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B81912D519; Thu, 17 Mar 2016 05:59:53 -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 HjNhknKjkyyq; Thu, 17 Mar 2016 05:59:50 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC6712D537; Thu, 17 Mar 2016 05:59:49 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 3BE1E1AE041A; Thu, 17 Mar 2016 13:59:48 +0100 (CET) Date: Thu, 17 Mar 2016 13:59:50 +0100 (CET) Message-Id: <20160317.135950.817854898340587984.mbj@tail-f.com> To: lberger@labn.net From: Martin Bjorklund In-Reply-To: <56EAA638.1000406@labn.net> References: <56EAA638.1000406@labn.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-chairs@ietf.org, netmod@ietf.org Subject: Re: [netmod] Regarding IPR on draft-bjorklund-netmod-structural-mount and draft-lhotka-netmod-ysdl 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, 17 Mar 2016 12:59:53 -0000 No, I'm not aware of any IPR that applies to this draft /martin Lou Berger wrote: > Authors, Contributors, WG, > > As part of the preparation for WG Adoption > > Are you aware of any IPR that applies to drafts identified above? > > [NOTE: Adoption poll will be on the first draft, but authors have agreed that -01 WG revision will be based on both.] > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NETMOD WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > > From nobody Thu Mar 17 07:47:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5544112DBFD for ; Thu, 17 Mar 2016 07:47:52 -0700 (PDT) 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 198P8uMD8sLG for ; Thu, 17 Mar 2016 07:47:49 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id D2DD712DBF4 for ; Thu, 17 Mar 2016 07:47:49 -0700 (PDT) Received: (qmail 10400 invoked by uid 0); 17 Mar 2016 14:47:45 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 17 Mar 2016 14:47:45 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id X2ng1s0142SSUrH012njSv; Thu, 17 Mar 2016 08:47:43 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=Q9fys5e9bTEA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=E1R-V3ATAAAA:8 a=F44FKoiqJ921vItUO4UA:9 a=PUjeQqilurYA:10 a=UJPwqTOgIDgA:10 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:To:Cc:References:Subject; bh=vzn0hMJeZfCGx6dZNAG9fTc4FI/HE5YY//cbPnKmT0E=; b=gn1bDdGIdoFpLwkI51qfsDOCkf A692I2nkO2I7Gp/+WuPmbKVeLB+IwssYBRNHG29ZL5QV/7lv0Sl7Oa8fOEroFQc15ckhSmYLz1ZKV ftQVISlNCQUUvdDruKaUDnVA9; Received: from box313.bluehost.com ([69.89.31.113]:34205 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1agZDC-00055V-B9; Thu, 17 Mar 2016 08:47:42 -0600 References: <56E6E889.60702@meetecho.com> To: Netmod WG From: Lou Berger X-Forwarded-Message-Id: <56E6E889.60702@meetecho.com> Message-ID: <56EAC389.9000802@labn.net> Date: Thu, 17 Mar 2016 10:47:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56E6E889.60702@meetecho.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "netmod-chairs@ietf.org" Subject: [netmod] Fwd: Cutoff date for requesting remote presentations support 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, 17 Mar 2016 14:47:52 -0000 Please let us (netmod-chairs@ietf.org) if you plan to present remotely for the BA meeting. Thanks, Lou -------- Forwarded Message -------- Subject: Cutoff date for requesting remote presentations support Date: Mon, 14 Mar 2016 17:36:25 +0100 From: Meetecho IETF support To: wgchairs@ietf.org Dear chairs, if you plan to have remote presentations in Buenos Aires, you're kindly requested to fill in the following form: https://ietf95.conf.meetecho.com/index.php/Remote_presentations *The cutoff date for remote presentations support requests is April 2.* Thanks, the Meetecho team From nobody Thu Mar 17 07:50:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3C712DBEE for ; Thu, 17 Mar 2016 07:50:25 -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_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 GDKGiOIYkpGa for ; Thu, 17 Mar 2016 07:50:24 -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 C09C712DBF8 for ; Thu, 17 Mar 2016 07:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2533; q=dns/txt; s=iport; t=1458226223; x=1459435823; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=qIMGaEB7AOex8UJlns8b/qNCK2tTnsAI//hrsgwy120=; b=ARfh+OFN/g7gOEdXD19TwnboO0T8DAg6d1BOlA6RxzV7yFpXzDKycOjA 07ue8fru1akegskfeaDur5wcBETqAc4WlKD+Mj3osk180Zk4+2q++3ZQp JgvDHj11JFoIYqbki9RCexxodevkUSd7TCgGtiMJ5qDb7CYUR0sV2e/DE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgCsw+pW/4MNJK1eg0VTbrd2gg8BD?= =?us-ascii?q?YFvI4VqAoE1OBQBAQEBAQEBZCeEQQEBAQQjVREPDQMBAgoWCwICCQMCAQIBOwI?= =?us-ascii?q?IBg0GAgEBiCMOsR+PQQEBAQEBAQEBAQEBAQEBAQEBAQETBIYehESEXIJggToFj?= =?us-ascii?q?i+EVYRQjgGJMoVUjwMeAQFChAUcLopjAQEB?= X-IronPort-AV: E=Sophos;i="5.24,350,1454976000"; d="scan'208,217";a="250455281" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Mar 2016 14:50:22 +0000 Received: from [10.24.63.92] ([10.24.63.92]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2HEoM5a012751 for ; Thu, 17 Mar 2016 14:50:22 GMT References: <56EAC3FC.7010801@cisco.com> To: NETMOD Working Group From: Benoit Claise X-Forwarded-Message-Id: <56EAC3FC.7010801@cisco.com> Message-ID: <56EAC42E.5070609@cisco.com> Date: Thu, 17 Mar 2016 07:50:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56EAC3FC.7010801@cisco.com> Content-Type: multipart/alternative; boundary="------------030605030303090009080901" Archived-At: Subject: [netmod] Fwd: Blog: YANG Data Models in the Industry: Current State of Affairs 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, 17 Mar 2016 14:50:26 -0000 This is a multi-part message in MIME format. --------------030605030303090009080901 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Forwarded here, in case you don't look at the IETF-Discussion list Regards, B. -------- Forwarded Message -------- Subject: Blog: YANG Data Models in the Industry: Current State of Affairs Date: Thu, 17 Mar 2016 07:49:32 -0700 From: Benoit Claise To: IETF-Discussion list Dear all, https://www.ietf.org/blog/2016/03/yang-data-models-in-the-industry-current-state-of-affairs/ Enjoy. Regards, Benoit --------------030605030303090009080901 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Forwarded here, in case you don't look at the IETF-Discussion list

Regards, B.
-------- Forwarded Message --------
Subject: Blog: YANG Data Models in the Industry: Current State of Affairs
Date: Thu, 17 Mar 2016 07:49:32 -0700
From: Benoit Claise <bclaise@cisco.com>
To: IETF-Discussion list <ietf@ietf.org> 


Dear all,

https://www.ietf.org/blog/2016/03/yang-data-models-in-the-industry-current-state-of-affairs/ 

Enjoy.

Regards, Benoit


--------------030605030303090009080901-- From nobody Thu Mar 17 08:09:06 2016 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 7B27712D53D; Thu, 17 Mar 2016 08:09: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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317150902.19295.86328.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 08:09:02 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-21.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: Thu, 17 Mar 2016 15:09: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 : A YANG Data Model for Routing Management Authors : Ladislav Lhotka Acee Lindem Filename : draft-ietf-netmod-routing-cfg-21.txt Pages : 68 Date : 2016-03-17 Abstract: This document contains a specification of three YANG modules and one submodule. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for routing protocols, route filters and other functions. The core routing data model provides common building blocks for such extensions - routes, routing information bases (RIB), and routing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-21 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 Thu Mar 17 12:40:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0364012D676 for ; Thu, 17 Mar 2016 12:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 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, 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 F_S5VYsNJWw2 for ; Thu, 17 Mar 2016 12:40:31 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 44B6412D5BB for ; Thu, 17 Mar 2016 12:40:31 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2HJLwNf032626 for ; Thu, 17 Mar 2016 15:40:26 -0400 Received: from mdwexght02.ciena.com (lin1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 21mg7jc27n-2 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 17 Mar 2016 15:40:26 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 17 Mar 2016 15:40:25 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by MDWEXCHCGSIHT01.ciena.com (10.4.140.106) with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 17 Mar 2016 15:40:25 -0400 Received: from ONWVEXCHMB03.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Thu, 17 Mar 2016 15:40:24 -0400 From: "Larsson, Gustav" To: "netmod@ietf.org" Date: Thu, 17 Mar 2016 15:40:23 -0400 Thread-Topic: deviation that changes config true to false: deviate add or replace? Thread-Index: AdF/053/yueP5tBtR6uogTbt3XKUlAAsMukw Message-ID: <23FD825DF7C2A6489CA3B5077FB1DC8603B47F7F83@ONWVEXCHMB03.ciena.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22200.002 X-TM-AS-Result: No--6.890500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-17_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603170250 Archived-At: Subject: [netmod] deviation that changes config true to false: deviate add or replace? 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, 17 Mar 2016 19:40:33 -0000 (Originally posted to the netconf mailing list in error. My apologies.) Hello, When a node defaults to config true and a deviation changes it to config fa= lse, should "deviate add" or "deviate replace" be used? Some YANG implement= ations allow either, some allow only "deviate replace". Perhaps some allow = only "deviate add" but we have not yet seen that. Consider these definitions: =A0 container x { =A0=A0=A0 leaf y { =A0=A0=A0=A0=A0 type string; =A0=A0=A0 } =A0 } =A0 deviation /x/y { =A0=A0=A0 deviate replace {=A0 =A0=A0=A0<--=A0 Should this be add or replac= e? =A0=A0=A0=A0=A0 config false; =A0=A0=A0 } =A0 } Section 7.18.3.2 of RFC 6020 says: =A0=A0 The argument "add" adds properties to the target node.=A0 The =A0=A0 properties to add are identified by substatements to the "deviate" =A0=A0 statement.=A0 If a property can only appear once, the property MUST = NOT =A0=A0 exist in the target node. =A0=A0 The argument "replace" replaces properties of the target node.=A0 Th= e =A0=A0 properties to replace are identified by substatements to the =A0=A0 "deviate" statement.=A0 The properties to replace MUST exist in the =A0=A0 target node. /x/y is config true by default even though config is not explictly given. S= ection 7.19.1 of RFC 6020 is not clear about whether config is considered t= o exist when defaulted. If config is considered to exist, then "deviate replace" is correct. Otherw= ise, "deviate add" is correct. Technically, RFC 6020 allows only one or the= other but not both in this case, but perhaps a robust implementation shoul= d accept both. YANG file authors need to pick one or the other, so clear guidance would be= helpful. Thanks, Gustav From nobody Thu Mar 17 13:32:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D52812D688 for ; Thu, 17 Mar 2016 13:32:23 -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 pkx2lsxe0MNE for ; Thu, 17 Mar 2016 13:32:21 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1006012D67E for ; Thu, 17 Mar 2016 13:32:20 -0700 (PDT) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id C818A1AE041A; Thu, 17 Mar 2016 21:32:18 +0100 (CET) Date: Thu, 17 Mar 2016 21:32:18 +0100 (CET) Message-Id: <20160317.213218.2303351254263780998.mbj@tail-f.com> To: glarsson@ciena.com From: Martin Bjorklund In-Reply-To: <23FD825DF7C2A6489CA3B5077FB1DC8603B47F7F83@ONWVEXCHMB03.ciena.com> References: <23FD825DF7C2A6489CA3B5077FB1DC8603B47F7F83@ONWVEXCHMB03.ciena.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / 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] deviation that changes config true to false: deviate add or replace? 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, 17 Mar 2016 20:32:23 -0000 "Larsson, Gustav" wrote: > (Originally posted to the netconf mailing list in error. My > apologies.) > = > Hello, > = > When a node defaults to config true and a deviation changes it to > config false, should "deviate add" or "deviate replace" be used? Some= > YANG implementations allow either, some allow only "deviate > replace". Perhaps some allow only "deviate add" but we have not yet > seen that. > = > Consider these definitions: > = > =A0 container x { > =A0=A0=A0 leaf y { > =A0=A0=A0=A0=A0 type string; > =A0=A0=A0 } > =A0 } > = > =A0 deviation /x/y { > =A0=A0=A0 deviate replace {=A0 =A0=A0=A0<--=A0 Should this be add or = replace? > =A0=A0=A0=A0=A0 config false; > =A0=A0=A0 } > =A0 } > = > Section 7.18.3.2 of RFC 6020 says: > = > =A0=A0 The argument "add" adds properties to the target node.=A0 The > =A0=A0 properties to add are identified by substatements to the "devi= ate" > =A0=A0 statement.=A0 If a property can only appear once, the property= MUST > NOT > =A0=A0 exist in the target node. All nodes in the data tree has a "config" value; if it isn't explicitly specified it is inherited from the parent, and if the top-level node doesn't have an explicit statement it defaults to "true". So in order to change this property, it should be deviated with 'replace'. > =A0=A0 The argument "replace" replaces properties of the target node.= =A0 The > =A0=A0 properties to replace are identified by substatements to the > =A0=A0 "deviate" statement.=A0 The properties to replace MUST exist i= n the > =A0=A0 target node. > = > /x/y is config true by default even though config is not explictly > given. Section 7.19.1 of RFC 6020 is not clear about whether config i= s > considered to exist when defaulted. Don't you think it is clear how the config value is inherited? If "config" is not specified, the default is the same as the parent schema node's "config" value. If the parent node is a "case" node, the value is the same as the "case" node's parent "choice" node. If the top node does not specify a "config" statement, the default is= "true". This text doesn't use the words "config property", this could probably be clarified. /martin > = > If config is considered to exist, then "deviate replace" is > correct. Otherwise, "deviate add" is correct. Technically, RFC 6020 > allows only one or the other but not both in this case, but perhaps a= > robust implementation should accept both. > = > YANG file authors need to pick one or the other, so clear guidance > would be helpful. > = > Thanks, > Gustav > = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > = From nobody Thu Mar 17 14:41:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1598212D92E; Thu, 17 Mar 2016 14:41:01 -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 9Ix11BPHBBMk; Thu, 17 Mar 2016 14:40:53 -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 6A8B512D8D8; Thu, 17 Mar 2016 14:40:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGH05801; Thu, 17 Mar 2016 21:40:49 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 17 Mar 2016 21:40:48 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Fri, 18 Mar 2016 05:40:43 +0800 From: "Dongjie (Jimmy)" To: Kent Watsen , "andy@yumaworks.com" , "mbj@tail-f.com" , "dromasca@avaya.com" Thread-Topic: Regarding IPR on draft-entitydt-netmod-entity Thread-Index: AQHRf7BxxemTCcwE1U6mVSvZjJQnep9eK6aQ Date: Thu, 17 Mar 2016 21:40:42 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92774E4121B@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.64.37] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C92774E4121BNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.56EB2462.002C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bd98e2bec0ada5bcf445adb7f96201fc Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: [netmod] =?utf-8?b?562U5aSNOiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWVu?= =?utf-8?q?titydt-netmod-entity?= 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, 17 Mar 2016 21:41:02 -0000 --_000_76CD132C3ADEF848BD84D028D243C92774E4121BNKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFm dC4NCg0KQmVzdCByZWdhcmRzLA0KSmllDQoNCuWPkeS7tuS6ujogS2VudCBXYXRzZW4gW21haWx0 bzprd2F0c2VuQGp1bmlwZXIubmV0XQ0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0M+aciDE35pelIDI6 MjANCuaUtuS7tuS6ujogYW5keUB5dW1hd29ya3MuY29tOyBtYmpAdGFpbC1mLmNvbTsgRG9uZ2pp ZSAoSmltbXkpOyBkcm9tYXNjYUBhdmF5YS5jb20NCuaKhOmAgTogbmV0bW9kQGlldGYub3JnOyBu ZXRtb2QtY2hhaXJzQGlldGYub3JnDQrkuLvpopg6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtZW50 aXR5ZHQtbmV0bW9kLWVudGl0eQ0KDQpbVGhpcyByZWdhcmRzIHRoZSBuZXcgcHJlLWFkb3B0aW9u IHByb2Nlc3MgZGVzY3JpYmVkIGJ5IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9uZXRtb2QvY3VycmVudC9tc2cxNTUyMC5odG1sXQ0KDQoNCkF1dGhvcnMsIENvbnRyaWJ1dG9y cywgV0csDQoNCkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGwsIGFy ZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBh Ym92ZT8gIFBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiAgICAiTm8sIEknbSBub3QgYXdhcmUgb2Yg YW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCm9yDQogICAgIlllcywgSSdtIGF3 YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCg0KSWYgc28sIGhhcyB0aGlz IElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCihz ZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPyAgSWYg eWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KICAgICJZZXMsIHRoZSBJ UFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyIN Cm9yDQogICAgIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQoNCklmIHlvdSBh bnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5r DQphcHByb3ByaWF0ZS4NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Ig b3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0 aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBh bnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5l eHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0 aG9yIGFuZCBsaXN0ZWQgY29udHJpYnV0b3IuIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0Yg WU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0XigJlTIFRPIExJTkVTLg0KDQpJZiB5b3UgYXJlIG9u IHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0 ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2Js aWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRv IG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4g SUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFu eSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQg SVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJv dmUgYW5kIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0lu dGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpORVRNT0QgV0cgQ2hhaXJzDQoNClBT IFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdl IGluIHlvdXIgcmVzcG9uc2UuDQoNCg== --_000_76CD132C3ADEF848BD84D028D243C92774E4121BNKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAz IDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkn bSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KaWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8 L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiBLZW50IFdhdHNlbiBbbWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXRdDQo8YnI+DQo8L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkemAgeaXtumXtDxzcGFuIGxh bmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4gMjAxNjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjM8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjE3 PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4gMjoyMDxicj4NCjwvc3Bhbj48Yj7mlLbku7bk uro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBhbmR5 QHl1bWF3b3Jrcy5jb207IG1iakB0YWlsLWYuY29tOyBEb25namllIChKaW1teSk7IGRyb21hc2Nh QGF2YXlhLmNvbTxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBuZXRtb2RAaWV0Zi5vcmc7IG5ldG1vZC1jaGFpcnNA aWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1lbnRpdHlkdC1u ZXRtb2QtZW50aXR5PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5bVGhpcyByZWdh cmRzIHRoZSBuZXcgcHJlLWFkb3B0aW9uIHByb2Nlc3MgZGVzY3JpYmVkIGJ5DQo8YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTU1 MjAuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJy ZW50L21zZzE1NTIwLmh0bWw8L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTpDb3VyaWVyO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+QXV0aG9y cywgQ29udHJpYnV0b3JzLCBXRyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7 Y29sb3I6YmxhY2siPkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGws IGFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmll ZCBhYm92ZT8gJm5ic3A7UGxlYXNlIHN0YXRlIGVpdGhlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJnF1b3Q7Tm8sIEknbSBu b3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCZxdW90OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb3Vy aWVyO2NvbG9yOmJsYWNrIj5vcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZx dW90O1llcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCZxdW90 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTpDb3VyaWVyO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+SWYgc28s IGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIg cnVsZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+KHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5k IDUzNzggZm9yIG1vcmUgZGV0YWlscyk/ICZuYnNwO0lmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFz ZSBzdGF0ZSBlaXRoZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9y OmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZxdW90O1llcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9z ZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzJnF1b3Q7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6 YmxhY2siPm9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJnF1b3Q7Tm8sIHRo ZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+SWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3Zp ZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+ YXBwcm9wcmlhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJs YWNrIj5JZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRv ciBwbGVhc2UgYW5zd2VyIHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVn YXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudA0K IElQUi4gVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVu dGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlz dGVkIGNvbnRyaWJ1dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQg SU4gVEhJUyBNRVNTQUdF4oCZUyBUTyBMSU5FUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkNvdXJpZXI7Y29sb3I6YmxhY2siPklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3Ig YXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29u dHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUgSUVU RiBJUFIgcnVsZXMNCiB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYg eW91IGFyZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBv ciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRp c2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3Jt YXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZCZuYnNwOzxhIGhyZWY9 Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVj dHVhbFByb3BlcnR5Ij5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMv d2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eTwvYT4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5UaGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPk5F VE1PRCBXRyBDaGFpcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6 YmxhY2siPlBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhp cyBtZXNzYWdlIGluIHlvdXIgcmVzcG9uc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_76CD132C3ADEF848BD84D028D243C92774E4121BNKGEML515MBXchi_-- From nobody Fri Mar 18 02:17:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA68812D6D6 for ; Fri, 18 Mar 2016 02:17:20 -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 thsJ92xQGCQT for ; Fri, 18 Mar 2016 02:17:13 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id DF01312D538 for ; Fri, 18 Mar 2016 02:17:12 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id A02E3C00222F; Fri, 18 Mar 2016 10:17:11 +0100 (CET) To: Martin Bjorklund , glarsson@ciena.com References: <23FD825DF7C2A6489CA3B5077FB1DC8603B47F7F83@ONWVEXCHMB03.ciena.com> <20160317.213218.2303351254263780998.mbj@tail-f.com> From: Jernej Tuljak Message-ID: <56EBC795.70209@mg-soft.si> Date: Fri, 18 Mar 2016 10:17:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160317.213218.2303351254263780998.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] deviation that changes config true to false: deviate add or replace? 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, 18 Mar 2016 09:17:21 -0000 Martin Bjorklund je 17.3.2016 ob 21:32 napisal: > "Larsson, Gustav" wrote: >> (Originally posted to the netconf mailing list in error. My >> apologies.) >> >> Hello, >> >> When a node defaults to config true and a deviation changes it to >> config false, should "deviate add" or "deviate replace" be used? Some >> YANG implementations allow either, some allow only "deviate >> replace". Perhaps some allow only "deviate add" but we have not yet >> seen that. >> >> Consider these definitions: >> >> container x { >> leaf y { >> type string; >> } >> } >> >> deviation /x/y { >> deviate replace { <-- Should this be add or replace? >> config false; >> } >> } >> >> Section 7.18.3.2 of RFC 6020 says: >> >> The argument "add" adds properties to the target node. The >> properties to add are identified by substatements to the "deviate" >> statement. If a property can only appear once, the property MUST >> NOT >> exist in the target node. > All nodes in the data tree has a "config" value; if it isn't > explicitly specified it is inherited from the parent, and if the > top-level node doesn't have an explicit statement it defaults to > "true". So in order to change this property, it should be deviated > with 'replace'. > >> The argument "replace" replaces properties of the target node. The >> properties to replace are identified by substatements to the >> "deviate" statement. The properties to replace MUST exist in the >> target node. >> >> /x/y is config true by default even though config is not explictly >> given. Section 7.19.1 of RFC 6020 is not clear about whether config is >> considered to exist when defaulted. > Don't you think it is clear how the config value is inherited? > > If "config" is not specified, the default is the same as the parent > schema node's "config" value. If the parent node is a "case" node, > the value is the same as the "case" node's parent "choice" node. > > If the top node does not specify a "config" statement, the default is > "true". > > > This text doesn't use the words "config property", this could probably > be clarified. > What needs to be clarified is the definition of "property". I always read this as "substatement": "units", "default", "require-instance", "when", "if-feature", "ordered-by" are all being referred to as "properties" and those are not inherited. On the other hand, "mandatory" is never referred to as a "property". Also, "refine" statement text, which is practically analogous to "deviation", explicitly uses "statement" for refinements (config included). Our implementation requires "add", if no "config" substatement is present in the target node (as did early versions of pyang, if I'm not mistaken). Jernej > > /martin > > >> If config is considered to exist, then "deviate replace" is >> correct. Otherwise, "deviate add" is correct. Technically, RFC 6020 >> allows only one or the other but not both in this case, but perhaps a >> robust implementation should accept both. >> >> YANG file authors need to pick one or the other, so clear guidance >> would be helpful. >> >> Thanks, >> Gustav >> >> _______________________________________________ >> 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 18 05:35:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDD812DBBE for ; Fri, 18 Mar 2016 05:35:14 -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] 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 RQsQahm3vg0o for ; Fri, 18 Mar 2016 05:35:11 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0132.outbound.protection.outlook.com [104.47.2.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 E98E812DF5F for ; Fri, 18 Mar 2016 05:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=omV5JHPY6RN3BCcBCGGMbJUTQIyT7MYreBb6AKzj/eg=; b=WFoY8u0HThaAEvInEsbNhQaB7lFEnMPKPFVXfSonm/y3eXFyLiDzNGfympj2YGzTdA4wuSGyOpDJPnPHDdnaIUHfi4grBabubztghn8qun5uD6AWlXmvs3x64KdDR6lyEUYumnGtcn9TpexyTABl899YyOb8+Q+SeBXcTpXT9VQ= Authentication-Results: adtran.com; dkim=none (message not signed) header.d=none;adtran.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (81.132.199.159) by HE1PR07MB1626.eurprd07.prod.outlook.com (10.166.124.22) with Microsoft SMTP Server (TLS) id 15.1.447.10; Fri, 18 Mar 2016 12:31:09 +0000 Message-ID: <010f01d18111$b4eb4640$4001a8c0@gateway.2wire.net> From: t.petch To: STUART VENTERS , 'Juergen Schoenwaelder' References: <1220E2C537595D439C5D026E83751866E7B4940C@ex-mb1.corp.adtran.com> <20160304165219.GA36535@elstar.local> <01bd01d17f7f$116bb2e0$4001a8c0@gateway.2wire.net> <20160316140828.GC39819@elstar.local> <1220E2C537595D439C5D026E83751866E7B4C079@ex-mb1.corp.adtran.com> Date: Fri, 18 Mar 2016 12:27:51 +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: [81.132.199.159] X-ClientProxiedBy: DB5PR03CA0051.eurprd03.prod.outlook.com (25.164.34.19) To HE1PR07MB1626.eurprd07.prod.outlook.com (25.166.124.22) X-MS-Office365-Filtering-Correlation-Id: 5f1cd793-2b7e-4b03-03d1-08d34f292f77 X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 2:pvAx6vdfj9mxApQfrjWqzc8S3oXpSgsZskzJ2dQ/mxLhNBH/EKHPDzaCKOm/t8MrdZznfjdNHWkvfIQkHapno3zjP0WwAYJlREmRoKqQ58L0RPK6oeO0IPq6fLL3rY0Haz4LPRud3A14fuASw+N2p8pMHxQ0OrAga/b3QEaG1UtWZPxX1rEUt8dKryVIE6yp; 3:8ct6+Ks3qA1LzU/MT0QpiUQmyD0aXOL/IiPveYd+a6fADVS6IK/AZt5pHuNMGBnwG6v7LMeUvemHa/GiXHs33+Dyu9sOH2n6GxXkzMApZ3z8SGKhbQ3u/fE8WXYooEIz; 25:Q3fI8H6S7pjTLyTe4mly6pEfp06BJfqdcbW39Rhtlq2AtF27a/JO4qtQIOEZjdPLDROMR6dsDu5c0hlCxKEKokrZcw24RXjgaPWTpk2izK943IlsGdTziXOmZ8VA5a4h4jYc0dPHXcTx8OAcYleT/1umjpPwVTY+wwl87eKK5V6tNDLaJPf7e/CL/thGBNjxAX7Q4f3X/Un++Gh+I6ichNr3Z9RbT50sWqNXhcEPQ4ZpvRXxFwyZdCvCxPHD6cGDpGZZE87H5X7wiaAfX/loyyioA8ql+aUGQbZnJHDLsxg0rVXrcjfDOsT3AWJ2NOsV X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1626; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:HE1PR07MB1626; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1626; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 4:/3bboxw7oytNrT86pUcAqFfBPH7IKP6QLTQW3nc4IhUwpczkU8pf6B3ihjY0+xo9LIUIEDDPx0NNBCuxVQrznfcvPqNFIirxgPJ3Y59uCBlwPsf0ZX8ejnMZHOTl/F9/vtE84VwQFBRn9dKZqDh4DaKq0OsS2Sfatuw6edTNB7jfOOEBO21AsJFTgSY2wLVe1OonXDQIqr2PKryeriJprWxjHvn5h9tiNqpdE724nXaJQiiZLnwiYL0XY2aR3FlggmT9fgYsKSQU32wEcQxHtuv7mvN5Q06q2PPP1PPxijwWpCboUggCdzbeqUM6fjZwap4xsUWa1EZxs72kzG59PueOu4G6VbO11QoqNDWyxzg0+Wf6+dX/KyzEsJf8r2XY X-Forefront-PRVS: 088552DE73 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(24454002)(377454003)(13464003)(76176999)(92566002)(81166005)(2906002)(230700001)(50466002)(93886004)(77096005)(50226001)(189998001)(5004730100002)(4326007)(86362001)(44716002)(1096002)(14496001)(1556002)(62236002)(15975445007)(81816999)(5008740100001)(81686999)(50986999)(6116002)(61296003)(3846002)(19580405001)(230783001)(23756003)(47776003)(42186005)(19580395003)(33646002)(5001770100001)(66066001)(586003)(84392002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1626; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR07MB1626; 23:KD7RbsgI7gtjuNBMmwwHx+qUmJzhBA6PCdXVeyl?= =?iso-8859-1?Q?t92iQek+WuNlfYbVkdmpdI8xqjGqc4IxUcywfsQ00TDWROkZbxBbgKugxs?= =?iso-8859-1?Q?OkX7gQ2dRUbddUXhRfZVYTUZmtVHdh92HFav7sZ0aFEzVQNrFbXcjDoUZV?= =?iso-8859-1?Q?ZsIgEwKCKbdhOidpfNiPFkZ1BD8XtNweZ/v2YLm1eSpMBB7KvybgrY17a3?= =?iso-8859-1?Q?laQPT/qvw8MsUIalsbd8WA4dM/00eF2uyyXKcf5M+5resdpWSLyAWxBV+a?= =?iso-8859-1?Q?7viTFGfHr0rur65A65m6zv8VlXozKFushik6DSV+N5Xs7a39wH2gGv1LJb?= =?iso-8859-1?Q?Blq67QGqrn+TCAXztjY0vU3hSJrektkwVIPpN288GnXEVK7H3x3LSdqTf1?= =?iso-8859-1?Q?PDSJluYBXY+zbKmpOTT4IhEVILZviyYOlOpXWRPQ/2JnFQSjw/dExDQv6b?= =?iso-8859-1?Q?E0IlcDCKddKAg6Q6aeKJX5VtOb9BW4tHFjtAVHs6rc8SovTe9eGgU289CL?= =?iso-8859-1?Q?ZILiOuh86o/xMhjghzsd9RSbuggD6JFVpnQUJo/PibuXJC9TMeHG7Xk4gJ?= =?iso-8859-1?Q?OzBS2jXRwx+pSUpVVFPdhjWXMRiTHQ5xvaMFVZOACXNSvpONQHlh52u2Zh?= =?iso-8859-1?Q?w/S9+Btt4GcfZB6/e6jVBv8E3hfyqZxpcCUtDMmYb6uLl7SVx4tkj9wCQD?= =?iso-8859-1?Q?GTNwX15uE9wBR1mQmTVarnj7kmKJRPXnHN2DgXES/T5SXnVcK6uAw4Oz3p?= =?iso-8859-1?Q?ijAxHfA/cdQw4IDR4ZZD/TXymTgvOuJT/ol/i97UJQKB0RNDUNr7vQQeJm?= =?iso-8859-1?Q?cZMyNCWg/r7MKOekLg/WJvITc3X4QDDs3g13ZJIUpXkVR0NLC44VIkpixA?= =?iso-8859-1?Q?GykHx0Fx+cLBSWcLQ1OFqOm1xtakXPkKBvgpyWcG0LbmEaUlVDq1pDBDp+?= =?iso-8859-1?Q?AhxV9dK/Aye8Z8HbXwrLDAJxNkacSDHv/gHYpLA+/SD6kRfcNtIPw1DQvv?= =?iso-8859-1?Q?l43rb4W3aZLPjoeDRg0bw5hEpQW2C2+hDouWlMyEo/4L/dURwOIAo6WMLd?= =?iso-8859-1?Q?asbpsUcQqC0XlUlMh5/PfX8/4Ey23WIwKu/FPnIkfar+Al7kjNrB+zISAs?= =?iso-8859-1?Q?yJ5N0KQrenPihefseOcalBOkF3vL9cIPMCzvIJG/x0NH2FqqUBWEExqt5a?= =?iso-8859-1?Q?Yr+ZvIPVVVpHx2V650DEayUSZwsYX4U7g=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 5:LUcKuCLNqcn+pxy2QZoZV9gwB2Aibma48zw/Tdi62D0UxKjyix7/gflGgG+W2kU7YSyorK2Gr0XkAj+cZ6BrNN2RL1spZfgeVb24CCIuG5P+lEHhRyHhPpfLJKvCWZOuylLQcK2aXzEttBup2SEKQA==; 24:kbWlbq1p8JhFqomorBNJ9WjsBjXh+notV+5b7jiK2/iaXFFwrMSscbYbqfYD1JtUdeC6aQOxFe1bQxx6Shu3ehYDh1tewPDpt1AHF4bze9U= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2016 12:31:09.3579 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1626 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification 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, 18 Mar 2016 12:35:14 -0000 ----- Original Message ----- From: "STUART VENTERS" To: "'Juergen Schoenwaelder'" Cc: Sent: Wednesday, March 16, 2016 2:58 PM > Interesting, this highlights a concern I have with Yang. > It's highlevel goals and progress are great, but at a detail level, > instead of using one general purpose language construct per feature, it seems to be evolving to use many. > For a new language evolving in an old problem area, this doesn't seem right. > > RFC6020bis-11 section 7.15 gives some clue as to the reasoning behind this. > "The difference between an action and an rpc is that an action is tied > to a node in the datastore, whereas an rpc is not." > > To me, this feels like a protocol or implementation issue is causing an unnecessary language addition. > > I wonder if an alternative strategy could be to say that you can use an rpc in a node, but when you do the name of the rpc on the wire becomes some combination of the node name and the rpc name? Stuart Picking up on your earlier e-mail, I agree with your thoughts but accept Juergen's point that we should have got involved a year or two ago. What I think would be valuable now is more guidance on when to choose which option of the several available, like RFC6087 only more so. I think of this whenever I see a discussion on this list about e.g. identities, enumerations, derived types, ...references and such like. There are good reasons why one option is better than another but I struggle to understand them and rarely remember when I am looking at one of the dozens of YANG models that come out each month. Tom Petch > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, March 16, 2016 9:08 AM > To: t. petch > Cc: STUART VENTERS; netmod@ietf.org; Martin Bjorklund > Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification > > On Wed, Mar 16, 2016 at 12:26:17PM +0000, t. petch wrote: > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > Sent: Friday, March 04, 2016 4:52 PM > > > > > > > On Fri, Mar 04, 2016 at 04:25:37PM +0000, STUART VENTERS wrote: > > > > > > > > 2) Allow the 'rpc' and 'notification' nouns to be used in other > > places in the schema tree besides at the top module level. > > > > > > This is already part of YANG 1.1. > > > > Looking at rfc6020bis-11 s.14, I see 'notification-stmt' appearing in > > many places so indeed it is allowed in other places but only see > > 'rpc-stmt' appear in 'body-stmts' . Which, if I understand aright, > > means that 'rpc-stmt' can still only appear at the top level. > > > > Yep. But there is a new action-stmt and in section 1.1 it says: > > o Added a new statement "action" that is used to define operations > tied to data nodes. > > /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 18 11:44:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0877912D52E for ; Fri, 18 Mar 2016 11:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 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, 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 NkyYVWAndg06 for ; Fri, 18 Mar 2016 11:44:40 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (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 4DD6712D50C for ; Fri, 18 Mar 2016 11:44:40 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2IIhjuR017061; Fri, 18 Mar 2016 14:44:40 -0400 Received: from vawvcgsie2k1302.ciena.com (lin1-118-36-36.ciena.com [63.118.36.36]) by mx0a-00103a01.pphosted.com with ESMTP id 21rhakj0g2-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 18 Mar 2016 14:44:39 -0400 Received: from VAWVMDMAIL01.ciena.com (10.4.156.37) by VAWVCGSIE2K1302.ciena.com (10.4.62.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 18 Mar 2016 14:44:39 -0400 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by VAWVMDMAIL01.ciena.com (10.4.156.37) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 18 Mar 2016 14:44:38 -0400 Received: from ONWVEXCHMB03.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Fri, 18 Mar 2016 14:44:38 -0400 From: "Larsson, Gustav" To: Jernej Tuljak , Martin Bjorklund Date: Fri, 18 Mar 2016 14:44:37 -0400 Thread-Topic: [netmod] deviation that changes config true to false: deviate add or replace? Thread-Index: AdGA9vcH9Mwj4Ln2R1mF4PhPJNfqdgAR/EZw Message-ID: <23FD825DF7C2A6489CA3B5077FB1DC8603B47F848E@ONWVEXCHMB03.ciena.com> References: <23FD825DF7C2A6489CA3B5077FB1DC8603B47F7F83@ONWVEXCHMB03.ciena.com> <20160317.213218.2303351254263780998.mbj@tail-f.com> <56EBC795.70209@mg-soft.si> In-Reply-To: <56EBC795.70209@mg-soft.si> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-18_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603180253 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] deviation that changes config true to false: deviate add or replace? 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, 18 Mar 2016 18:44:42 -0000 Jernej Tuljak wrote: > Martin Bjorklund je 17.3.2016 ob 21:32 napisal: > > "Larsson, Gustav" wrote: > > The argument "replace" replaces properties of the target node. The > > > properties to replace are identified by substatements to the > > > "deviate" statement. The properties to replace MUST exist in the > > > target node. > > > > > > /x/y is config true by default even though config is not explictly=20 > > > given. Section 7.19.1 of RFC 6020 is not clear about whether config=20 > > > is considered to exist when defaulted. > > Don't you think it is clear how the config value is inherited? > > > > If "config" is not specified, the default is the same as the parent > > schema node's "config" value. If the parent node is a "case" node, > > the value is the same as the "case" node's parent "choice" node. > > > > If the top node does not specify a "config" statement, the default i= s > > "true". > > > > > > This text doesn't use the words "config property", this could probably= =20 > > be clarified. > > > > What needs to be clarified is the definition of "property". I always read > this as "substatement": "units", "default", "require-instance", "when", > "if-feature", "ordered-by" are all being referred to as "properties" and > those are not inherited. On the other hand, "mandatory" is never referred > to as a "property". > > Also, "refine" statement text, which is practically analogous to "deviati= on", > explicitly uses "statement" for refinements (config included). I agree that the definition of "property" needs to be clarified. Another way of looking at it is whether "property" refers to the (syntactic= ) substatement or the (semantic) value. When the config value is inherited, the config substatement is syntactically absent but the config value is semantically present. It is unclear whether the "config property" is considered to be (syntactically) absent or (semantically) present for the purposes of deviate statements. > Our implementation requires "add", if no "config" substatement is present > in the target node (as did early versions of pyang, if I'm not mistaken). > >Jernej That's what I was concerned about. The latest pyang (1.6) seems to take the opposite approach by requiring "replace". Gustav From nobody Fri Mar 18 14:25:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3D612D695 for ; Fri, 18 Mar 2016 14:25:20 -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_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 n45OAZcI4TIF for ; Fri, 18 Mar 2016 14:25:19 -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 BB93B12D690 for ; Fri, 18 Mar 2016 14:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=715; q=dns/txt; s=iport; t=1458336318; x=1459545918; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=buBv0iE4JH6H23DFY/Vw9CZFcnFJiHLqaSPxGELMV7Y=; b=ZVJ/8cf49lCjilGc627tdCNMHgymhvcxOji1nIpJ7Uraps05871ir/UC hHxZ8VCMdbuFh3KWu0+3Ik2sDj5ZAIHUle38zxfllQm2XPYMma+jbnWfH TZwKBWJSrM26Oly3Lffj1eDjOc2EKO7YT6T7VIZSngrMge+r9CYmjTZzZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBAAScexW/xbLJq1ehQ+8FYYNAoF9A?= =?us-ascii?q?QEBAQEBZRwLhEIBAQQ6TwIBCDYQMiUCBBuIH8BvAQEBAQEBBAEBAQEBARqGHoR?= =?us-ascii?q?EhAwRAYV0BZdXAY18jw6PBQFig2WKGzR+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,357,1454976000"; d="scan'208";a="636381895" 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; 18 Mar 2016 21:25:16 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2ILP1d1007818 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 18 Mar 2016 21:25:16 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.1104.5; Fri, 18 Mar 2016 17:25:01 -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.1104.009; Fri, 18 Mar 2016 17:25:01 -0400 From: "Eric Voit (evoit)" To: "netmod@ietf.org" Thread-Topic: [netmod] Differentiating the types of Mount Thread-Index: AdF/OD2NJ3Cq4cCSQLyujReGzdHIoQAX41GAAAuwc4AACCa0AP//7ngAgAAh1pD//Sm+MA== Date: Fri, 18 Mar 2016 21:25:01 +0000 Message-ID: References: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> <20160316112329.GB39598@elstar.local> <1220E2C537595D439C5D026E83751866E7B4C101@ex-mb1.corp.adtran.com> <020f5d85b38d46d5a09940e8e89cc37e@XCH-RTP-013.cisco.com> <1220E2C537595D439C5D026E83751866E7B4C20C@ex-mb1.corp.adtran.com> <878f650eb3d8414c970313e0403d8964@XCH-RTP-013.cisco.com> In-Reply-To: <878f650eb3d8414c970313e0403d8964@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.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Differentiating the types of Mount 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, 18 Mar 2016 21:25:20 -0000 I have placed the Mount definitions from the email discussion into: draft-voit-netmod-yang-mount-requirements-00 This -00 draft isn't really that new. It is just our recent email exchange= s incorporated into the last version of: draft-voit-netmod-peer-mount-requirements-03 But I renamed the -03 draft into an -00 one to acknowledge the growth of th= e mount concepts beyond Peer and Alias Mount. (I.e., it was a convenient p= lace to store the definitions/differentiations.) =20 At this point the authors don't plan on incorporating the full set of requi= rements from Schema/Structural Mount into this document unless there is WG = desire to consolidate Mount requirements in one place. Eric From nobody Sun Mar 20 08:10:09 2016 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 2C63C12D556; Sun, 20 Mar 2016 08:10:06 -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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160320151006.2321.64042.idtracker@ietfa.amsl.com> Date: Sun, 20 Mar 2016 08:10:06 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.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, 20 Mar 2016 15:10:06 -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 : SYSLOG YANG Model Authors : Clyde Wildes Kiran Koushik Filename : draft-ietf-netmod-syslog-model-07.txt Pages : 34 Date : 2016-03-20 Abstract: This document describes a data model for the Syslog protocol which is used to convey event notification messages. 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-07 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 20 11:53:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F9D12D571 for ; Sun, 20 Mar 2016 11:53: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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 sLQKqBK5v8pd for ; Sun, 20 Mar 2016 11:53: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 637C612D543 for ; Sun, 20 Mar 2016 11:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3190; q=dns/txt; s=iport; t=1458500007; x=1459709607; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/l5HF8KLphtubbn8pKh4p4GNuD0ezhli3giD4EYEOlc=; b=JfzNHkSGHGuyVFalx5FJw2GDpf6SM5qNRiCPqWC8KGaGiJ7hIxI6SvqY 3/9UboCoYjd05HiC8JJ//jfbLD6fMxxn2Crft51JD5GWouXES125Rc89F ZMBgN0k5uBU6BBkYXsfyqBf7BlML604zlK5fqm95qQPUGfAbk/xffYruq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgAJ8e5W/4MNJK1dgzNTcga6HAENg?= =?us-ascii?q?W8XCoUiSgIcgQQ4FAEBAQEBAQFkHAuEQgEBBAEBASAROgsQAgEIGgImAgICJQs?= =?us-ascii?q?VEAIEDgWIJw6vO48BAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXyFIoFzCIJJhDqDA?= =?us-ascii?q?iuCKwWXVwGFcIgTgWVLg3+HPYEbjwUBHgEBQoIDGYFJaokXfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,367,1454976000"; d="scan'208";a="249708275" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2016 18:53:26 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2KIrQZk024622 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 20 Mar 2016 18:53:26 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 20 Mar 2016 13:53: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.1104.009; Sun, 20 Mar 2016 13:53:25 -0500 From: "Clyde Wildes (cwildes)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.txt Thread-Index: AQHRgrqqbdiJAOKHdkK+l/uGNO0H6J9ijKMA Date: Sun, 20 Mar 2016 18:53:25 +0000 Message-ID: References: <20160320151006.2321.64042.idtracker@ietfa.amsl.com> In-Reply-To: <20160320151006.2321.64042.idtracker@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: [10.27.7.180] Content-Type: text/plain; charset="utf-8" Content-ID: <0E25B78B1EE5CF46B47D8CC6F9C0655C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.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: Sun, 20 Mar 2016 18:53:29 -0000 SGksDQoNClRoaXMgcmV2aXNpb24gaW5jb3Jwb3JhdGVzIGZlZWRiYWNrIGZyb20gTWFydGluIEJq b3JrbHVuayAoMTkgY29tbWVudHMpIGFuZCBUb20gUGV0Y2ggKDEwIGNvbW1lbnRzKS4gVGhhbmtz IHRvIGJvdGggb2YgeW91IGZvciB5b3VyIHZhbHVhYmxlIGZlZWRiYWNrIQ0KDQpSZWdhcmRpbmcg VG9tJ3MgY29tbWVudCAtICI0LjEgV2hhdCBhIGxvdCBvZiBmZWF0dXJlcz8gIEFnYWluLCBtYWtl cyB0aGluZ3MgbW9yZSBjb21wbGV4LCBtb3JlIGVycm9yIHByb25lIC0gYXJlIHRoZXkgYWxsIHJl YWxseSBuZWVkZWQ/IjogV2Ugc3RhcnRlZCB0aGUgZHJhZnQgdHdvIHllYXJzIGFnbyBhbmQgaXQg aGFzIGV2b2x2ZWQgZnJvbSBmZWVkYmFjayByZWNlaXZlZCBmcm9tIGFsbCBvZiB0aGUgZm9sa3Mg dGhhdCBhcHBlYXIgaW4gdGhlIEFja25vd2xlZGdlbWVudHMgc2VjdGlvbi4gUGxlYXNlIHJldmll dyB0aGUgY3VycmVudCBkcmFmdCB3aGVyZSBJIGJlbGlldmUgdGhhdCBJIGFkZHJlc3MgYWxsIG9m IHlvdXIgY29tbWVudHMgZXhjZXB0IHBvc3NpYmx5IHRoaXMgb25lLiBUaGUgdHJhZGVvZmYgaXMg dG8gbGVhdmUgdGhlIGZlYXR1cmUgc3BlY2lmaWMgZnVuY3Rpb25hbGl0eSBvdXQgb2YgdGhlIGRy YWZ0IGFuZCBsZWF2ZSBpdCB0byB0aGUgaW1wbGVtZW50YXRpb25zIHRvIGFkZCBiYWNrIHRocm91 Z2ggYXVnbWVudGF0aW9uLiBUaGF0IHNhaWQgbW9zdCBvZiB0aGUgZmVhdHVyZXMgdGhhdCBhcmUg Y2FsbGVkIG91dCBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgYnkgYXQgbGVhc3QgdHdvIHZlbmRvcnMs IGJ1dCBub3QgYWxsLCBsZWFkaW5nIHRvIHRoZSBmZWF0dXJlIGRlc2lnbmF0aW9uLg0KDQpUaGFu a3MsDQoNCkNseWRlDQoNCg0KDQpPbiAzLzIwLzE2LCA4OjEwIEFNLCAibmV0bW9kIG9uIGJlaGFs ZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cyBkaXJlY3Rvcmllcy4NCj5UaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBORVRD T05GIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2Ugb2YgdGhlIElFVEYuDQo+DQo+ICAgICAgICBUaXRs ZSAgICAgICAgICAgOiBTWVNMT0cgWUFORyBNb2RlbA0KPiAgICAgICAgQXV0aG9ycyAgICAgICAg IDogQ2x5ZGUgV2lsZGVzDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBLaXJhbiBLb3VzaGlr DQo+CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0wNy50 eHQNCj4JUGFnZXMgICAgICAgICAgIDogMzQNCj4JRGF0ZSAgICAgICAgICAgIDogMjAxNi0wMy0y MA0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgZGF0YSBtb2Rl bCBmb3IgdGhlIFN5c2xvZyBwcm90b2NvbCB3aGljaCBpcw0KPiAgIHVzZWQgdG8gY29udmV5IGV2 ZW50IG5vdGlmaWNhdGlvbiBtZXNzYWdlcy4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwvDQo+DQo+VGhlcmUncyBhbHNv IGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0wNw0KPg0KPkEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTA3DQo+DQo+ DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3Jn DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Sun Mar 20 13:57:14 2016 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 C30B012D515; Sun, 20 Mar 2016 13:57:10 -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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160320205710.8922.39702.idtracker@ietfa.amsl.com> Date: Sun, 20 Mar 2016 13:57:10 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-06.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, 20 Mar 2016 20:57:11 -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-06.txt Pages : 58 Date : 2016-03-20 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) 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-06 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 20 14:01:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8595112D67D for ; Sun, 20 Mar 2016 14:01:29 -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 6upkeU4qtpJ3 for ; Sun, 20 Mar 2016 14:01:27 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 8605D12D515 for ; Sun, 20 Mar 2016 14:01:27 -0700 (PDT) Received: by mail-lb0-x233.google.com with SMTP id k12so116347436lbb.1 for ; Sun, 20 Mar 2016 14:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=132p1IwpplqKXXIBObR/tyAq3U0jJ60rl0EKewEO/Vg=; b=MhRtND5YFjbu038WD2e7WUT5WzV6HK98iiZMkuvJpwtlgcxV/nRquaWtHUfAN+uGc1 kF7VC32PD8K574IdajiOv26gCOVuQnRPOADPXottgpNkiQsW0ldQSZ1fFRzablvukXcc Om5CHVUCh3BxfWC+sGkGfaipMY+JePKVZ5YHPIArz35abyW34MIw/ePGJxJNnc4ZOkQn qM0DcUZ/RWOrnBWvFWBMMeIenuXvOzK7GokzMV7kd3tCuanewNZXV2/NxVSk0NJXb34z lO70IF2dijNbwISNPwsi03f1gvkW48tL4cA9HhFSVuLZ2O/w83lEPMVYLqYvd6/pObwP eCLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=132p1IwpplqKXXIBObR/tyAq3U0jJ60rl0EKewEO/Vg=; b=XtWeBXc3ksbyykii2WMenUIoEc6Il0YJKWZ2Ae2xHk3PoMQln9TAaXH9mElH3H2z/g KdiFlE5P/jFxquaOYcvNiIHZyTx+43IEANcX1WmZHQkCplCdaw857u5BXCSYi+XhvVxD YlfoWWIusZi7x+N5DyomTT4BrVxEIZOok8XN0zfAnjgjGQPF2iBVsejXLoa4a8oPPn76 gFRqrRH/mJAyS9OBJKnvI8i7o2A/djxkDh3JVlQ8Oe1thTszirLSLQShN6BM/VpnOHZO 1ZLCmggUkUz1mRx31Mb3c5vQxUfQmXG8L32HDQac98dz/f4HeCGaXIkvVx6nbQm5EmAc wIEg== X-Gm-Message-State: AD7BkJLIABYv5PNgh1J98dzs4Pz7BofM1WIqeUNUvS1Ncwk3iPtOCMBrw5uwCIs4v4RrcumGetRjz3dMa9bPDQ== MIME-Version: 1.0 X-Received: by 10.112.147.101 with SMTP id tj5mr7714135lbb.119.1458507685713; Sun, 20 Mar 2016 14:01:25 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Sun, 20 Mar 2016 14:01:25 -0700 (PDT) Date: Sun, 20 Mar 2016 14:01:25 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a8bd2826e55052e814871 Archived-At: Subject: [netmod] YANG Guidelines -06 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, 20 Mar 2016 21:01:29 -0000 --047d7b3a8bd2826e55052e814871 Content-Type: text/plain; charset=UTF-8 Hi, Please review the latest version of the YANG Guidelines draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ There have been some updates based on the review comments: https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-06#appendix-A.1 This draft addresses all open issues found on github: https://github.com/netmod-wg/rfc6087bis/issues Andy --047d7b3a8bd2826e55052e814871 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please review the latest version of the Y= ANG Guidelines draft:

=
There have been some updates based on the r= eview comments:

This draft addresses a= ll open issues found on github:
--047d7b3a8bd2826e55052e814871-- From nobody Mon Mar 21 06:13:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D658912D719 for ; Mon, 21 Mar 2016 06:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 WPdh0eIfxSjc for ; Mon, 21 Mar 2016 06:13:38 -0700 (PDT) Received: from amalka.pantheon.sk (amalka.pantheon.sk [46.229.239.144]) by ietfa.amsl.com (Postfix) with ESMTP id 38BF912D553 for ; Mon, 21 Mar 2016 06:13:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id CB67B27E5A for ; Mon, 21 Mar 2016 14:13:35 +0100 (CET) X-Virus-Scanned: amavisd-new at pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6FZBBpMLLjb for ; Mon, 21 Mar 2016 14:13:34 +0100 (CET) Received: from XMBX1.pantheon.local (fw.pantheon.sk [46.229.239.141]) by amalka.pantheon.sk (Postfix) with ESMTPS for ; Mon, 21 Mar 2016 14:13:34 +0100 (CET) Received: from XMBX1.pantheon.local (10.10.4.5) by XMBX1.pantheon.local (10.10.4.5) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 21 Mar 2016 14:13:33 +0100 Received: from XMBX1.pantheon.local ([10.10.4.5]) by XMBX1.pantheon.local ([10.10.4.5]) with mapi id 15.00.1156.000; Mon, 21 Mar 2016 14:13:33 +0100 From: =?iso-8859-2?Q?Anton_Tk=E1=E8ik?= To: "netmod@ietf.org" Thread-Topic: draft-bjorklund-netmod-structural-mount: Namespace issues Thread-Index: AQHRg3IaunOXW/ExD02Y20Pxpc4UDA== Date: Mon, 21 Mar 2016 13:13:33 +0000 Message-ID: <1458566013189.55874@pantheon.tech> Accept-Language: sk-SK, en-US Content-Language: sk-SK X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [173.38.220.43] Content-Type: multipart/alternative; boundary="_000_145856601318955874pantheontech_" MIME-Version: 1.0 Archived-At: Subject: [netmod] draft-bjorklund-netmod-structural-mount: Namespace issues 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, 21 Mar 2016 13:13:41 -0000 --_000_145856601318955874pantheontech_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi, if I understand correctly netmod-structural-mount inlines "mounted" data di= rectly to container / list which is used, which brings up following issues: 1. It is possible to have identifier conflict between data from model defin= ing mount and mounted data (if mounted schema contains same model). e.g. module mount-under-mount { container mounts { list mount { key name; leaf name; container mounts { // List of discovered remote mounts } mnt:mount-point data; } }? } 2. Expanding data directly under container / list may be problematic for cl= ients which do not support netmod-structural-mount. I believe both can be solved elegantly by requiring mount-point extension t= o be used inside anydata element, which signifies to client that this may be any YANG modeled data (and client can omit proce= ssing it) and also provides isolation between data from module defining mount point and mounted data. E.g: list mount { key name; leaf name {...} // additional data anydata data { mnt:mount-point data { mnt:mount-yang-library;? } } } AntonTk=E1=E8ik Chief Software Architect Mlynsk=E9 Nivy 56 / 821 05 Bratislava / Slovakia +421 911 309 249 / anton.tkacik@pantheon.tech reception: +421 2 206 65 111 / www.pantheon.sk [logo] --_000_145856601318955874pantheontech_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable


Hi,

if I understand correctly netmod-structural-mount inlines "mou= nted" data directly to container / list which is used,

which brings up following issues:


1. It is possible to have identifier conflict between data from mod= el defining mount and mounted data (if mounted schema

contains same model).

e.g.

     &n= bsp;module mount-under-mount {

      &= nbsp;      container mounts {

      &= nbsp;            list mount {

      &= nbsp;                key name;

      &= nbsp;                leaf name;

 &nb=
sp;            =
            &nb=
sp;   container mounts {
         =
                           // List of discovered remote mounts
         =
                     }
         =
                     mnt:mount-point data;

      &= nbsp;            }

      &= nbsp;      }​

     &n= bsp;}


2. Expanding data directly under container / list may be problematic for= clients which do not support netmod-structural-mount.


I believe both can be solved elegantly by requiring mount-point extensio= n to be used inside anydata element, which signifies

to client that this may be any YANG modeled data (and client can omit pr= ocessing it) and also provides isolat= ion between 

data from module defining mount po= int and mounted data.


E.g:     

list mount {

    key name= ;

    leaf nam= e {...}

    // addit= ional data

    anydata = data {

      &= nbsp;  mnt:mount-point data {

      &= nbsp;       mnt:mount-yang-library;​

      &= nbsp;  }

    }

}

PT_signature

AntonTk=E1=E8ik

Chief = Software Architect

<= /o:p>=
<= o:p>Mlynsk=E9 Nivy 56 / 821 05 Bratislava / Slovakia
+421 911 309 249 / anton.tkacik@pantheon.tech
reception: +421 2 206 65 111 / www.pantheon.sk

3D"logo"

--_000_145856601318955874pantheontech_-- From nobody Mon Mar 21 08:07:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A15112D869; Mon, 21 Mar 2016 08:07:12 -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 O7EwkdeUOJb4; Mon, 21 Mar 2016 08:07:10 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 652AB12D799; Mon, 21 Mar 2016 08:07:10 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id BC8F11CC00C3; Mon, 21 Mar 2016 16:07:17 +0100 (CET) From: Ladislav Lhotka To: Stephen Farrell , The IESG In-Reply-To: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 21 Mar 2016 16:07:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod-chairs@ietf.org, draft-ietf-netmod-yang-json@ietf.org, netmod@ietf.org Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 21 Mar 2016 15:07:12 -0000 Hi Stephen, thanks for your comments, please see my responses inline. Stephen Farrell writes: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - I would have thought that it'd be useful to point out any > issues with round-tripping, e.g. going from XML to JSON and > back to XML or vice-versa. But I didn't see any mention of > that. How come? I believe fifth paragraph in sec. 3 is what you are asking for: With the exception of anyxml and schema-less anydata nodes, it is possible to map a JSON-encoded data tree to XML encoding as defined in [I-D.ietf-netmod-rfc6020bis], and vice versa. However, such conversions require the YANG data model to be available. > > - I'm not sure if anyone has considered XMLDSIG or use of JOSE > with YANG. If one did, then this kind of mapping would not > allow one to preserve digital signatures without a lot of > work. I assume that that's considered ok. (Which it can be, > depending on how one does object level security, if one does > object level security.) I am not an expert on digital signatures and their representations, but I'd say they could be modelled as YANG's "binary" type (and transferred base64-encoded). This should work equally well in XML and JSON, including round trips. > > - It's not clear to me if the discussion of the secdir review > [1] concluded. It seemed to just stall. Is there more to be > said? (If so, be great if the shepherd would kick that > discussion.) I don't have much more to say without seeing alternative proposals. Lada > > [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06408.html > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 21 08:11:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A8E12D5CA; Mon, 21 Mar 2016 08:11:16 -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 C88wWPy8sOfg; Mon, 21 Mar 2016 08:11:14 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3E87412D566; Mon, 21 Mar 2016 08:11:14 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 974A81CC049E; Mon, 21 Mar 2016 16:11:22 +0100 (CET) From: Ladislav Lhotka To: Lou Berger , Martin Bjorklund In-Reply-To: <56EAA638.1000406@labn.net> References: <56EAA638.1000406@labn.net> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 21 Mar 2016 16:11:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod-chairs@ietf.org" , netmod WG Subject: Re: [netmod] Regarding IPR on draft-bjorklund-netmod-structural-mount and draft-lhotka-netmod-ysdl 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, 21 Mar 2016 15:11:16 -0000 Hi, I am not aware of any IPR related to the two I-Ds in the subject. Lada Lou Berger writes: > Authors, Contributors, WG, > > As part of the preparation for WG Adoption > > Are you aware of any IPR that applies to drafts identified above? > > [NOTE: Adoption poll will be on the first draft, but authors have agreed that -01 WG revision will be based on both.] > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NETMOD WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 21 08:19:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9613112D566; Mon, 21 Mar 2016 08:19:24 -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 H6y-ZI5rXPjb; Mon, 21 Mar 2016 08:19:22 -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 2A113127058; Mon, 21 Mar 2016 08:19: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 407DE229A; Mon, 21 Mar 2016 16:19:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id V3S8NiVQgXtu; Mon, 21 Mar 2016 16:19:16 +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, 21 Mar 2016 16:19:19 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB9B120045; Mon, 21 Mar 2016 16:19:18 +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 njMNiewcFTCD; Mon, 21 Mar 2016 16:19:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BED6720044; Mon, 21 Mar 2016 16:19:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 715C13A4F547; Mon, 21 Mar 2016 16:19:15 +0100 (CET) Date: Mon, 21 Mar 2016 16:19:14 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160321151914.GA62880@elstar.local> Mail-Followup-To: Ladislav Lhotka , Stephen Farrell , The IESG , draft-ietf-netmod-yang-json@ietf.org, netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org, draft-ietf-netmod-yang-json@ietf.org, The IESG , Stephen Farrell Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 21 Mar 2016 15:19:24 -0000 On Mon, Mar 21, 2016 at 04:07:07PM +0100, Ladislav Lhotka wrote: > > - I'm not sure if anyone has considered XMLDSIG or use of JOSE > > with YANG. If one did, then this kind of mapping would not > > allow one to preserve digital signatures without a lot of > > work. I assume that that's considered ok. (Which it can be, > > depending on how one does object level security, if one does > > object level security.) > > I am not an expert on digital signatures and their representations, but > I'd say they could be modelled as YANG's "binary" type (and transferred > base64-encoded). This should work equally well in XML and JSON, > including round trips. Lada, I think Stephen asks about JSON encoded YANG-defined data that is signed, that is, the JSON serialization itself is signed. What happens to the signature if you convert the JSON to corresponding XML serialization. I think the answer is that the signature is broken in this case and I think this is quite natural. Object signatures so far never came up in the NETCONF/YANG context (well not quite correct, I think there is some related discussion aroud the zero-config draft) but even if they do, I think we will have to accept that signatures are encoding specific. And I think this is not a big deal; if I sign my HTML encoded email, then the signature likely won't apply to a text-only rendering of the same email. /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 21 08:30:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB33212D566; Mon, 21 Mar 2016 08:30:08 -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_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 QCo6NJRWQRNS; Mon, 21 Mar 2016 08:30:08 -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 20BFC127058; Mon, 21 Mar 2016 08:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2636; q=dns/txt; s=iport; t=1458574207; x=1459783807; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=rOTGfE/SmdzjkrXt6mGVCcGMcGI92JlFl6IauvhmJVI=; b=PKqr+/eSipbACNCmPgrgh0ySF5b2h4fxFpDeLhjSQR32czB9BVm48V9c 87Bo//w43AKPkyavSo555By06zliI3EYOLrIX+SKU8toecjj6sONatrbf o/qfsy+0EoSAnag9ojxoZ90AV61XaoC4eM96YUUQj8o63Uty2IShRyPjZ 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AgCVEvBW/xbLJq1evQ6CDw6BcIYNA?= =?us-ascii?q?oFeFAEBAQEBAQFkJ4RCAQEEI1URCxgJFgsCAgkDAgECAUUGAQwIAQGII7ACjxw?= =?us-ascii?q?BAQEBAQEBAwEBAQEBAQERCIpihAwRAYMeglYBBJdXgx6BZokAiTOFVI8GHgFDg?= =?us-ascii?q?jCBNjuJEYEyAQEB?= X-IronPort-AV: E=Sophos;i="5.24,372,1454976000"; d="asc'?scan'208";a="676192401" 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; 21 Mar 2016 15:30:05 +0000 Received: from [10.61.216.70] ([10.61.216.70]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u2LFU4QZ030406; Mon, 21 Mar 2016 15:30:04 GMT To: Ladislav Lhotka , Stephen Farrell , The IESG , draft-ietf-netmod-yang-json@ietf.org, netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> From: Eliot Lear Message-ID: <56F0137B.3090103@cisco.com> Date: Mon, 21 Mar 2016 16:30:03 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160321151914.GA62880@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="c9soHwVfm6Gq3GmbRLx5ULj6X1VmXMM10" Archived-At: Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 21 Mar 2016 15:30:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c9soHwVfm6Gq3GmbRLx5ULj6X1VmXMM10 Content-Type: multipart/mixed; boundary="OUsbJsp4sBlj2va95fQk38vM8VK3UdlCs" From: Eliot Lear To: Ladislav Lhotka , Stephen Farrell , The IESG , draft-ietf-netmod-yang-json@ietf.org, netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org Message-ID: <56F0137B.3090103@cisco.com> Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> In-Reply-To: <20160321151914.GA62880@elstar.local> --OUsbJsp4sBlj2va95fQk38vM8VK3UdlCs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/21/16 4:19 PM, Juergen Schoenwaelder wrote: > Lada, I think Stephen asks about JSON encoded YANG-defined data that > is signed, that is, the JSON serialization itself is signed. What > happens to the signature if you convert the JSON to corresponding XML > serialization. I think the answer is that the signature is broken in > this case and I think this is quite natural. > > Object signatures so far never came up in the NETCONF/YANG context > (well not quite correct, I think there is some related discussion > aroud the zero-config draft) but even if they do, I think we will have > to accept that signatures are encoding specific. And I think this is > not a big deal; if I sign my HTML encoded email, then the signature > likely won't apply to a text-only rendering of the same email. > However this goes, it should be well documented somewhere. This will not be the first time this comes up (he says, knowingly). Eliot --OUsbJsp4sBlj2va95fQk38vM8VK3UdlCs-- --c9soHwVfm6Gq3GmbRLx5ULj6X1VmXMM10 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJW8BN8AAoJEIe2a0bZ0noz8wIIAJyb1KteqIuxGmdpGKzvRUWs Z8tdJdw5CbFygVMUF+mpoAOk5P/Ao2UBXrK8oEdpErO3BXXxNt6EOICgF8V4EFwG UXauaFZwPteNjwDj/RDRnWXjhMRleeJHfHK5/MMrEoek4+jKBx8zbATIEuxK8QTD BonpVaav9AtWip6RuwIOYIzZy7mVaab1XOoSB7FT1iolFTb8irfx9b9IlS/UGpuX OV/CuU4rf4sqg7/1AFEL7+1BJktIbepfBdMtYW7KU3y7Zxz6QxwRlqT1NV3XI5fX fBAEF3icbHCUkQ+o4IS+jl/VCQaxaO31spDji5FtGmUxf3WmX1gvVxB6y6ynrOQ= =r3MF -----END PGP SIGNATURE----- --c9soHwVfm6Gq3GmbRLx5ULj6X1VmXMM10-- From nobody Mon Mar 21 08:43:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A4712D8C2; Mon, 21 Mar 2016 08:43:28 -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 QTceVDMKzudZ; Mon, 21 Mar 2016 08:43:27 -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 AA01412D8BA; Mon, 21 Mar 2016 08:43:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 67FBC22F1; Mon, 21 Mar 2016 16:43:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 63e4jl0vNJa4; Mon, 21 Mar 2016 16:43:21 +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, 21 Mar 2016 16:43:24 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7867620046; Mon, 21 Mar 2016 16:43:24 +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 BWwJk_dCAouC; Mon, 21 Mar 2016 16:43: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 6E6EB20045; Mon, 21 Mar 2016 16:43:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 64E263A4F5A8; Mon, 21 Mar 2016 16:43:22 +0100 (CET) Date: Mon, 21 Mar 2016 16:43:22 +0100 From: Juergen Schoenwaelder To: Eliot Lear Message-ID: <20160321154322.GA62960@elstar.local> Mail-Followup-To: Eliot Lear , Ladislav Lhotka , Stephen Farrell , The IESG , draft-ietf-netmod-yang-json@ietf.org, netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F0137B.3090103@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org, draft-ietf-netmod-yang-json@ietf.org, The IESG , Stephen Farrell Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 21 Mar 2016 15:43:29 -0000 On Mon, Mar 21, 2016 at 04:30:03PM +0100, Eliot Lear wrote: > > > On 3/21/16 4:19 PM, Juergen Schoenwaelder wrote: > > Lada, I think Stephen asks about JSON encoded YANG-defined data that > > is signed, that is, the JSON serialization itself is signed. What > > happens to the signature if you convert the JSON to corresponding XML > > serialization. I think the answer is that the signature is broken in > > this case and I think this is quite natural. > > > > Object signatures so far never came up in the NETCONF/YANG context > > (well not quite correct, I think there is some related discussion > > aroud the zero-config draft) but even if they do, I think we will have > > to accept that signatures are encoding specific. And I think this is > > not a big deal; if I sign my HTML encoded email, then the signature > > likely won't apply to a text-only rendering of the same email. > > > > However this goes, it should be well documented somewhere. This will > not be the first time this comes up (he says, knowingly). > I am somewhat surprised. Do people really expect that signatures computed over a certain encoding of some data can be applied to a different encoding of the same data? If I sign a tar archive and then convert the content to a zip archive, do people really assume the signature is still valid? If this is a surprise, perhaps object signature RFCs should say something about this. Does it make sense to have a statement in every data encoding RFC saying that 'if you transform the encoding to a different encoding, a signature calculated over the original encoding will not be valid anymore'? /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 21 08:53:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB53E12D89C; Mon, 21 Mar 2016 08:53:45 -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 rFDf4pggr6zd; Mon, 21 Mar 2016 08:53:43 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3828012D72D; Mon, 21 Mar 2016 08:53:42 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 3E4631CC00C3; Mon, 21 Mar 2016 16:53:50 +0100 (CET) From: Ladislav Lhotka To: Stephen Farrell , The IESG In-Reply-To: <20160317114149.21786.70223.idtracker@ietfa.amsl.com> References: <20160317114149.21786.70223.idtracker@ietfa.amsl.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 21 Mar 2016 16:53:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod-chairs@ietf.org, draft-ietf-netmod-yang-metadata@ietf.org, netmod@ietf.org Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-metadata-06: (with COMMENT) 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, 21 Mar 2016 15:53:46 -0000 Stephen Farrell writes: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Section 9: You could maybe add a sentence recommending > to not store security or privacy sensitive information > in annotations (unless it's really needed). I propose to extend second paragraph in section 9 with the following sentence: It is RECOMMENDED that security-sensitive or privacy-sensitive data be modeled as regular YANG data nodes rather than annotations. Is this sufficient? Thanks, Lada > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 21 08:54:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3912D8EE; Mon, 21 Mar 2016 08:53: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_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 cHJ6qvc8GMsl; Mon, 21 Mar 2016 08:53:50 -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 3279612D8D2; Mon, 21 Mar 2016 08:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2434; q=dns/txt; s=iport; t=1458575629; x=1459785229; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=ajzwX7G7zj6Z1vSgwAtXhw3LawaXqnfkVh4bfGWBzSg=; b=m3GoCZ7CPR12IuLFdkRcBlUxdpqHMOXG5IHIzLc3ivWJ+QcF2ZcSw3ii EQEc6EABlzEMQdTEJjYLNDW6bcrm8GSu2xPzdYp0NiNJDQUku13yv99PV qx/0uCTPDwwj+ws+4qg9IOROE6QODETw6OwAmkxqW4+dKIBZbdHbNYVel A=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AgB1GPBW/xbLJq1evQ+CDw6BcIYNA?= =?us-ascii?q?oFfFAEBAQEBAQFkJ4RCAQEDASNVEQshFgsCAgkDAgECAUUGAQwIAQGIGwiwAo8?= =?us-ascii?q?iAQEBAQEBAQMBAQEBAQEBEQiKYoc8glYBBJdXgx6BZokAiTOFVI8GHgFDgjCBN?= =?us-ascii?q?juKQwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,372,1454976000"; d="asc'?scan'208";a="676193213" 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 2016 15:53:47 +0000 Received: from [10.61.216.70] ([10.61.216.70]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2LFrlHa025532; Mon, 21 Mar 2016 15:53:47 GMT To: Ladislav Lhotka , Stephen Farrell , The IESG , draft-ietf-netmod-yang-json@ietf.org, netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> <20160321154322.GA62960@elstar.local> From: Eliot Lear Message-ID: <56F0190A.6000103@cisco.com> Date: Mon, 21 Mar 2016 16:53:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160321154322.GA62960@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1dPGsmuggh1RF2V2x1TRab0C6J2WoJPsH" Archived-At: Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 21 Mar 2016 15:53:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1dPGsmuggh1RF2V2x1TRab0C6J2WoJPsH Content-Type: multipart/mixed; boundary="7Uq1a1F45J2I6fRN2rNQ58wMIFTs7M8vq" From: Eliot Lear To: Ladislav Lhotka , Stephen Farrell , The IESG , draft-ietf-netmod-yang-json@ietf.org, netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org Message-ID: <56F0190A.6000103@cisco.com> Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> <20160321154322.GA62960@elstar.local> In-Reply-To: <20160321154322.GA62960@elstar.local> --7Uq1a1F45J2I6fRN2rNQ58wMIFTs7M8vq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Juergen, I think there is a miscommunication: On 3/21/16 4:43 PM, Juergen Schoenwaelder wrote: >> However this goes, it should be well documented somewhere. This will >> not be the first time this comes up (he says, knowingly). >> > I am somewhat surprised. Do people really expect that signatures > computed over a certain encoding of some data can be applied to a > different encoding of the same data? Not at all what I meant (sorry if I was confusing). I just meant that we should be explicit as to what architectural component is responsible for object signature and verification. And it would be nice if there were a few examples somewhere. Eliot --7Uq1a1F45J2I6fRN2rNQ58wMIFTs7M8vq-- --1dPGsmuggh1RF2V2x1TRab0C6J2WoJPsH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJW8BkKAAoJEIe2a0bZ0nozktwH/RKOAUd4lH2bdJa7Te5zdIhC Q7+vnBlbvhFLV0D4siSRRbqJDG4DCqqZ5T0VnabXmr4V7k/fp2kUco074rbtczAT FgPEk0YLBEdshY5v2jq2iQcyDHB9T4pqGUU0IyR4eztsIA2R3uc/akQuSnqIZ5zw oXCxvk3Z8al39suth9G6lxv5w4KupEf2YnPCUljdf4Ut+jWLKOWHxtAMe9tmnaRP XJTQ/RvXIwBoWWQor1tNr36bbgVdFpXOiYMurqO6uALIExzn+EFXXn1eMVpZGeC6 a+XESqd3iYOCwY9OK/wihsM97CrJ7Jls1jIoZLLrpnZzo8wn2geT6d2YYtBSKtM= =IqFi -----END PGP SIGNATURE----- --1dPGsmuggh1RF2V2x1TRab0C6J2WoJPsH-- From nobody Mon Mar 21 08:55:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB0B12D8D4; Mon, 21 Mar 2016 08:55: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, 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 pXj4Phlf7p3N; Mon, 21 Mar 2016 08:55:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0108.outbound.protection.outlook.com [65.55.169.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 AAA4C12D8E3; Mon, 21 Mar 2016 08:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WIfDnXE0FCE+g2YQd7nGUCndR0nRQ5l36vCxMKdDwwU=; b=FN2vhmEF3tLa8ZS7MhsIftVhUvM4CTTLgjgwCKBI2SAwgrkIIgT9TmKpkVUWMj5gwO5NdCf5wWzgWol8wBruyrUWi2XCNBVT4zqtZRfoPjbb39WMWZUbvjY0sbNYcPF66A9/xu4sSj6JifypJ2VtFr6Sv/Os5FOTMcN6HtYuWvk= 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 (TLS) id 15.1.434.16; Mon, 21 Mar 2016 15:55:01 +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.0434.021; Mon, 21 Mar 2016 15:55:02 +0000 From: Kent Watsen To: Eliot Lear Thread-Topic: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) Thread-Index: AQHRgEDgmK6nCarkZEauCAC72O2xP59kBimAgAADYwCAAAMFgIAABvu6 Date: Mon, 21 Mar 2016 15:55:01 +0000 Message-ID: <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local>,<56F0137B.3090103@cisco.com> In-Reply-To: <56F0137B.3090103@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=juniper.net; x-originating-ip: [199.76.14.70] x-ms-office365-filtering-correlation-id: b960a54c-ee37-438b-f482-08d351a129aa x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:OI+g38iSrGK3+POWKvIg2jUkDjXYA8dUewg6glIzTLq0ZSFmI24PRDpicL58wOdogPs5Xy9WAtGydSkca6FyxLMX9YS624FtfLTGc7mleFReUITGeGZbR1j2l8c/UPI7QcnO2jtvI7IQMtW2/hrRvQ==; 24:vT2C9bdL5PAhOBM7huC9lCFYtKxwEb99JYa1tcKVDlKcVmtmsDJtOYZPZ4LYPyKS1SnKMqsPyx8YFuTqYXxMkSsmkoSrz2zf/+3gZus49Wc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0888B1D284 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(164054003)(24454002)(377454003)(5008740100001)(66066001)(110136002)(16236675004)(92566002)(189998001)(36756003)(99286002)(106116001)(122556002)(33656002)(586003)(82746002)(19617315012)(19580405001)(3846002)(102836003)(230783001)(6116002)(1220700001)(83716003)(1096002)(19580395003)(81166005)(93886004)(86362001)(50986999)(15975445007)(76176999)(54356999)(77096005)(3280700002)(2906002)(3660700001)(5004730100002)(87936001)(2950100001)(5002640100001)(4326007)(10400500002)(2900100001)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_72154E943C00438BB17735DB9216DF03junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2016 15:55:01.8619 (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: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 21 Mar 2016 15:55:45 -0000 --_000_72154E943C00438BB17735DB9216DF03junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable the zerotouch draft uses object signing. XMLSIG was used in earlier draft= , but was replaced with a binary type leaf called 'signature' having the fo= llowing description: description "A PKCS #7 SignedData structure as specified by RFC 2315, Section 9.1 encoded usi= ng the ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690. This signature is generated using the owner's private private key and an owner-selected digest algorithm over the redirect-information or the bootstrap-information nodes, which ever is present, and in whatever encoding they are presented in (e.g., XML, JSON, etc.)."; // is there a canonical format? reference "RFC 2315: PKCS #7: Cryptographic Message Syntax Version 1.5 ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)."; } Note a question regarding canonical format. As the draft stands, no format= is canonical format is required. The data can be however the data is prov= ided, by the server when pulling on the RESTCONF resource URL, or how it is= encoded in a message buffer, or encoded to a file on disk. The use of PKCS #7 signing was selected to simplify implementations, especi= ally on resource-constrained devices. Use of DER encoded ASN.1 structure w= as selected to be consistent with other parts of the draft as well as parts= of the server-model draft (in the keychain section). Thanks, Kent On Mar 21, 2016, at 11:30 AM, Eliot Lear > wrote: On 3/21/16 4:19 PM, Juergen Schoenwaelder wrote: Lada, I think Stephen asks about JSON encoded YANG-defined data that is signed, that is, the JSON serialization itself is signed. What happens to the signature if you convert the JSON to corresponding XML serialization. I think the answer is that the signature is broken in this case and I think this is quite natural. Object signatures so far never came up in the NETCONF/YANG context (well not quite correct, I think there is some related discussion aroud the zero-config draft) but even if they do, I think we will have to accept that signatures are encoding specific. And I think this is not a big deal; if I sign my HTML encoded email, then the signature likely won't apply to a text-only rendering of the same email. However this goes, it should be well documented somewhere. This will not be the first time this comes up (he says, knowingly). Eliot --_000_72154E943C00438BB17735DB9216DF03junipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

the zerotouch draft uses object signing.   XMLSIG was used in ear= lier draft, but was replaced with a binary type leaf called 'signature' hav= ing the following description:



description
          "A PKCS #7 SignedData structure as specified by RFC
           2315, Section 9.1 encoded using the ASN.1 distinguished
           encoding rules (DER), as specified in ITU-T X.690.
           This signature is generated using the owner's private
           private key and an owner-selected digest algorithm over
           the redirect-information or the bootstrap-information
           nodes, which ever is present, and in whatever encoding
           they are presented in (e.g., XML, JSON, etc.).";
           // is there a canonical format?
        reference
          "RFC 2315:
              PKCS #7: Cryptographic Message Syntax Version 1.5
           ITU-T X.690:
              Information technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER),
              Canonical Encoding Rules (CER) and Distinguished
              Encoding Rules (DER).";
      }

<=
/font>

<=
/font>
Note a question regarding canonical format.  As the draft stands,= no format is canonical format is required.  The data can be however t= he data is provided, by the server when pulling on the RESTCONF resource UR= L, or how it is encoded in a message buffer, or encoded to a file on disk.

The use of PKCS #7 signing was selected to simplify implementations, e= specially on resource-constrained devices.  Use of DER encoded ASN.1 s= tructure was selected to be consistent with other parts of the draft as wel= l as parts of the server-model draft (in the keychain section). 

Thanks,
Kent


On 3/21/16 4:19 PM, Juergen Schoenwaelder wrote:
Lada, I think Stephen asks about JSON encod= ed YANG-defined data that
is signed, that is, the JSON serialization = itself is signed. What
happens to the signature if you convert the= JSON to corresponding XML
serialization. I think the answer is that t= he signature is broken in
this case and I think this is quite natural= .

Object signatures so far never came up in t= he NETCONF/YANG context
(well not quite correct, I think there is s= ome related discussion
aroud the zero-config draft) but even if th= ey do, I think we will have
to accept that signatures are encoding spec= ific. And I think this is
not a big deal; if I sign my HTML encoded e= mail, then the signature
likely won't apply to a text-only rendering= of the same email.


However this goes, it should be well documented somewhere.  This= will
not be the first time this comes up (he says, knowingly).

Eliot

--_000_72154E943C00438BB17735DB9216DF03junipernet_-- From nobody Mon Mar 21 09:18:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9205E12D8F6 for ; Mon, 21 Mar 2016 09:18:15 -0700 (PDT) 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 DmpRjvJ2MjF3 for ; Mon, 21 Mar 2016 09:18:11 -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 86A4412D8C9 for ; Mon, 21 Mar 2016 09:18:11 -0700 (PDT) Received: (qmail 4152 invoked by uid 0); 21 Mar 2016 16:18:10 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 21 Mar 2016 16:18:10 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id YgJ51s00D2SSUrH01gJ8Qw; Mon, 21 Mar 2016 10:18:08 -0600 X-Authority-Analysis: v=2.1 cv=G/WPTbU5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=uzSlmYvlyRAA:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7OsogOcEt9IA:10 a=1ovPIFsOv4x8aqmHbx0A:9 a=QEXdDO2ut3YA:10 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:To:Cc:Subject:From; bh=K/y/fmsZKB6m8vQXR7U4FW3bNCSzG1J+dzUFXfvQKdk=; b=dsF0/nAQM21iRtWA49hvZL8LD6 Yu3pICJm2zypg3r/F5SnNbQBgK4M2LA3GAq5DBli8+4ZrGl+07WKoJDhBoWzYfv3cJ5FxIxJG26qV FCes0fMN8ui0cs9JtHjzKuhNG; Received: from box313.bluehost.com ([69.89.31.113]:46164 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1ai2Ws-0007RE-7D; Mon, 21 Mar 2016 10:18:06 -0600 From: Lou Berger To: netmod WG Message-ID: <56F01EB7.5000804@labn.net> Date: Mon, 21 Mar 2016 12:17:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod chairs Subject: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount 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, 21 Mar 2016 16:18:17 -0000 All, This is start of a two week poll on making draft-bjorklund-netmod-structural-mount-02 a working group document with the name draft-ietf-netmod-schema-mount. This adoption is a little bit unusual in that, per our last interim, we know that this document is likely to see significant changes in technical (solution) details as it progresses through normal WG process. And the -01 version is expected to be done in combination with Lada/draft-lhotka-netmod-ysdl. Please send email to the list indicating "yes/support" or "no/do not support". Note that Yes indicates your support for working on a schema mount solution, rather than the specific solution. If you have specific technical proposals/suggestions that you'd like to voice please feel free to also do so - but please use a new/different thread so we can keep the process and technical discussions separate. The poll ends April 4, 2016 (after our in-person meeting, but authors / main contributors are not expected to be present in BA. So please discuss on list.) Thank you, NETMOD Chairs From nobody Mon Mar 21 09:25:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22C512D8ED for ; Mon, 21 Mar 2016 09:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 aL0av34iZ97e for ; Mon, 21 Mar 2016 09:25:02 -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 20B3D12D8B7 for ; Mon, 21 Mar 2016 09:25:02 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id AAB49180310; Mon, 21 Mar 2016 17:25:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1458577500; bh=yQP0zXK8oZlNh2eba+FuW8L7HMjlEmJzscYwQLVa3RY=; h=From:Date:To; b=gkESFcM940sNAOmkEc4aerEj0R+dakoV+TADGEAIrBgal2zme0UwrvUCmHv4sAo3Y LRQDseek225N7VgWzsmUmJa/Tb8vW6Ay9SeBt2fvsC3OCkOLcmJshYXPRLcWmcMmh9 FYh4rTQVpoxHXNT2GSAwS2OInKDooadDx8Omxogo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56F01EB7.5000804@labn.net> Date: Mon, 21 Mar 2016 17:24:59 +0100 Content-Transfer-Encoding: 7bit Message-Id: <42F95D4E-42C9-42F5-B75B-85D9099EBAF7@nic.cz> References: <56F01EB7.5000804@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod WG Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount 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, 21 Mar 2016 16:25:06 -0000 Support. Lada > On 21 Mar 2016, at 17:17, Lou Berger wrote: > > All, > > This is start of a two week poll on making > draft-bjorklund-netmod-structural-mount-02 a working group document with > the name draft-ietf-netmod-schema-mount. > > This adoption is a little bit unusual in that, per our last interim, we > know that this document is likely to see significant changes in > technical (solution) details as it progresses through normal WG process. > And the -01 version is expected to be done in combination with > Lada/draft-lhotka-netmod-ysdl. > > Please send email to the list indicating "yes/support" or "no/do not > support". Note that Yes indicates your support for working on a schema > mount solution, rather than the specific solution. If you have specific > technical proposals/suggestions that you'd like to voice please feel > free to also do so - but please use a new/different thread so we can > keep the process and technical discussions separate. > > The poll ends April 4, 2016 > (after our in-person meeting, but authors / main contributors are not > expected to be present in BA. So please discuss on list.) > > Thank you, > > NETMOD Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 21 09:31:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491D312D5BF; Mon, 21 Mar 2016 09:30: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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 fTVOZiCG-uB9; Mon, 21 Mar 2016 09:30:56 -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 E5DFA12D81F; Mon, 21 Mar 2016 09:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1906; q=dns/txt; s=iport; t=1458577855; x=1459787455; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HiWClrhXi0CcoT6z9RidsoUym4lbWUaeUMs4MMqKCCM=; b=IN9EQXLX3DbcixTLBSY6oErnYHd3r10y3pOPLTcfhLmVq3qv0hrt/qne KtydSMGgQxk5246WhFafVFc5X5jCukwsSZ5a8Osa0iuGKabpxLALH95Xl 87OaGED3Vsk1YH+x3iGl4PeN944EoI+Y9DbgXThvYcA61gGbY+6ijltp3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgBcIfBW/5RdJa1YBoM0U3IGuh8BD?= =?us-ascii?q?YFwFwqFIkoCHIEPOBQBAQEBAQEBZCeEQgEBBAEBASAROgsQAgEIDgwCHwcCAgI?= =?us-ascii?q?lCxUQAgQBDQUbiAwOr3iPJgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEfIlmhAwRA?= =?us-ascii?q?Q6DEIJWBY07ihwBjgOBZYRKiFiPBQEeAQFCgjCBNWqIYzR+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,372,1454976000"; d="scan'208";a="252016776" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2016 16:30:54 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u2LGUsWJ012636 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Mar 2016 16:30:54 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 21 Mar 2016 12:30:54 -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.1104.009; Mon, 21 Mar 2016 12:30:53 -0400 From: "Acee Lindem (acee)" To: Lou Berger , netmod WG Thread-Topic: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount Thread-Index: AQHRg41ZYFUqWSSzt0KTEai7KqCxQJ9kJ7cA Date: Mon, 21 Mar 2016 16:30:53 +0000 Message-ID: References: <56F01EB7.5000804@labn.net> In-Reply-To: <56F01EB7.5000804@labn.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.196] Content-Type: text/plain; charset="utf-8" Content-ID: <60B6B3F171EEF2498CC911B66FB6B2DF@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: netmod chairs Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount 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, 21 Mar 2016 16:30:59 -0000 U3VwcG9ydC4NCkFjZWUNCg0KT24gMy8yMS8xNiwgMTI6MTcgUE0sICJuZXRtb2Qgb24gYmVoYWxm IG9mIExvdSBCZXJnZXIiDQo8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxi ZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0KDQo+QWxsLA0KPg0KPlRoaXMgaXMgc3RhcnQgb2YgYSB0 d28gd2VlayBwb2xsIG9uIG1ha2luZw0KPmRyYWZ0LWJqb3JrbHVuZC1uZXRtb2Qtc3RydWN0dXJh bC1tb3VudC0wMiBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgd2l0aA0KPnRoZSBuYW1lIGRyYWZ0 LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudC4NCj4NCj5UaGlzIGFkb3B0aW9uIGlzIGEgbGl0dGxl IGJpdCB1bnVzdWFsIGluIHRoYXQsIHBlciBvdXIgbGFzdCBpbnRlcmltLCB3ZQ0KPmtub3cgdGhh dCB0aGlzIGRvY3VtZW50IGlzIGxpa2VseSB0byBzZWUgc2lnbmlmaWNhbnQgY2hhbmdlcyBpbg0K PnRlY2huaWNhbCAoc29sdXRpb24pIGRldGFpbHMgYXMgaXQgcHJvZ3Jlc3NlcyB0aHJvdWdoIG5v cm1hbCBXRyBwcm9jZXNzLg0KPiBBbmQgdGhlIC0wMSB2ZXJzaW9uIGlzIGV4cGVjdGVkIHRvIGJl IGRvbmUgaW4gY29tYmluYXRpb24gd2l0aA0KPkxhZGEvZHJhZnQtbGhvdGthLW5ldG1vZC15c2Rs Lg0KPg0KPlBsZWFzZSBzZW5kIGVtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgInllcy9zdXBw b3J0IiBvciAibm8vZG8gbm90DQo+c3VwcG9ydCIuICBOb3RlIHRoYXQgWWVzIGluZGljYXRlcyB5 b3VyIHN1cHBvcnQgZm9yIHdvcmtpbmcgb24gYSBzY2hlbWENCj5tb3VudCBzb2x1dGlvbiwgcmF0 aGVyIHRoYW4gdGhlIHNwZWNpZmljIHNvbHV0aW9uLiAgSWYgeW91IGhhdmUgc3BlY2lmaWMNCj50 ZWNobmljYWwgcHJvcG9zYWxzL3N1Z2dlc3Rpb25zIHRoYXQgeW91J2QgbGlrZSB0byB2b2ljZSBw bGVhc2UgZmVlbA0KPmZyZWUgdG8gYWxzbyBkbyBzbyAtIGJ1dCBwbGVhc2UgdXNlIGEgbmV3L2Rp ZmZlcmVudCB0aHJlYWQgc28gd2UgY2FuDQo+a2VlcCB0aGUgcHJvY2VzcyBhbmQgdGVjaG5pY2Fs IGRpc2N1c3Npb25zIHNlcGFyYXRlLg0KPg0KPlRoZSBwb2xsIGVuZHMgQXByaWwgNCwgMjAxNg0K PihhZnRlciBvdXIgaW4tcGVyc29uIG1lZXRpbmcsIGJ1dCBhdXRob3JzIC8gbWFpbiBjb250cmli dXRvcnMgYXJlIG5vdA0KPmV4cGVjdGVkIHRvIGJlIHByZXNlbnQgaW4gQkEuIFNvIHBsZWFzZSBk aXNjdXNzIG9uIGxpc3QuKQ0KPg0KPlRoYW5rIHlvdSwNCj4NCj5ORVRNT0QgQ2hhaXJzDQo+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2Qg bWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Mon Mar 21 09:36:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD9812D906; Mon, 21 Mar 2016 09:36:47 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 K9691SAPle5s; Mon, 21 Mar 2016 09:36:46 -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 4F07D12D787; Mon, 21 Mar 2016 09:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1344; q=dns/txt; s=iport; t=1458578198; x=1459787798; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Z39zMjACr07eSUp/2h1jnOG5vn4Q/DJ+40MEb0R5z3g=; b=KJEarcibQ9Upop65LrvUps5UhCVOOFq6MpOWTvudEuImXyApw/JwcOxj sd/rnn0U+9uwaekSvxSXLagjM7BOCT3jKvmxLJZMKK52wRFWzcwX87xhM e3p4FwbJW3DgpfwmXNPPdGlxJe4lewUNowJMK+XTpZEEhBKK9jKW7HBgT M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQCqIfBW/xbLJq1YBoQHcrolAQ2Bc?= =?us-ascii?q?BcKhSJKAoFjFAEBAQEBAQFkJ4RCAQEEAQEBNTYKEQsOCgkWBAsJAwIBAgEVMAY?= =?us-ascii?q?BDAYCAQEXiAwOvx4BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYehESEDBEBDoVmA?= =?us-ascii?q?QSNO4VJhFOOBIFlhEqDBIVUjwYeAQFCgjCBNTwuiGOBMgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,372,1454976000"; d="scan'208";a="633606983" 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; 21 Mar 2016 16:36:36 +0000 Received: from [10.63.23.100] (dhcp-ensft1-uk-vla370-10-63-23-100.cisco.com [10.63.23.100]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2LGaarB012588; Mon, 21 Mar 2016 16:36:36 GMT To: Lou Berger , netmod WG , netmod chairs References: <56F01EB7.5000804@labn.net> From: Robert Wilton Message-ID: <56F02314.7060907@cisco.com> Date: Mon, 21 Mar 2016 16:36:36 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F01EB7.5000804@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount 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, 21 Mar 2016 16:36:48 -0000 Support. Rob On 21/03/2016 16:17, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-bjorklund-netmod-structural-mount-02 a working group document with > the name draft-ietf-netmod-schema-mount. > > This adoption is a little bit unusual in that, per our last interim, we > know that this document is likely to see significant changes in > technical (solution) details as it progresses through normal WG process. > And the -01 version is expected to be done in combination with > Lada/draft-lhotka-netmod-ysdl. > > Please send email to the list indicating "yes/support" or "no/do not > support". Note that Yes indicates your support for working on a schema > mount solution, rather than the specific solution. If you have specific > technical proposals/suggestions that you'd like to voice please feel > free to also do so - but please use a new/different thread so we can > keep the process and technical discussions separate. > > The poll ends April 4, 2016 > (after our in-person meeting, but authors / main contributors are not > expected to be present in BA. So please discuss on list.) > > Thank you, > > NETMOD Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Mar 21 10:11:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1212D766; Mon, 21 Mar 2016 10:11:10 -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_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 XV0DVN9uyNKr; Mon, 21 Mar 2016 10:11:07 -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 2CB7112D90C; Mon, 21 Mar 2016 10:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13158; q=dns/txt; s=iport; t=1458580261; x=1459789861; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=hpVyo5XaCowhiYawYZ3WAATAS7sXrdb79xoSK5/CZLM=; b=TDYkednG5uPOBrM0M7M5QqqFbxFMsQ8T2JRUCr+JTExxQdhdJMq38TWd 6XWGOKDzsnrqJ1c80IscVnNSsvGlrk/Kkc7qpz2uaDHERIV3yEC+wasZy Ply+wAFME4O7Zwbp9cMwgfXP1u/cAScdTksOAs6H+6i3wB7DO3jA4mNui 8=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiBQDRKfBW/xbLJq1ehAcuRLU3gl+ED?= =?us-ascii?q?SGFbAKBdwEBAQEBAWUnhEIBAQQjSA0BEAsOCgkWCAMCAgkDAgECATQRBg0GAgE?= =?us-ascii?q?BiCMOr3ePJwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBIpihAwRAQaDGIJWBZdXg?= =?us-ascii?q?x6BZm2IE4kzhVSPBmKCMIE2Oy4BiGKBMgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,372,1454976000"; d="asc'?scan'208,217";a="636444584" 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; 21 Mar 2016 17:10:59 +0000 Received: from [10.61.216.70] ([10.61.216.70]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2LHAwa0023364; Mon, 21 Mar 2016 17:10:58 GMT To: Kent Watsen References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> From: Eliot Lear Message-ID: <56F02B21.3080103@cisco.com> Date: Mon, 21 Mar 2016 18:10:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TuR2vXPhoBwiQcLXhm9Etplm1I0nwKNDt" Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 21 Mar 2016 17:11:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TuR2vXPhoBwiQcLXhm9Etplm1I0nwKNDt Content-Type: multipart/mixed; boundary="d61pgAHPMwCKwotNJtBBVKcd8Sb2vlPxn" From: Eliot Lear To: Kent Watsen Cc: Ladislav Lhotka , Stephen Farrell , The IESG , "draft-ietf-netmod-yang-json@ietf.org" , "netmod-chairs@ietf.org" , "netmod@ietf.org" Message-ID: <56F02B21.3080103@cisco.com> Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> In-Reply-To: <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> --d61pgAHPMwCKwotNJtBBVKcd8Sb2vlPxn Content-Type: multipart/alternative; boundary="------------060405050406070804020301" This is a multi-part message in MIME format. --------------060405050406070804020301 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kent, Thanks for the pointer. The zeroconf draft is cool beans to be sure.=20 That describes an enrollment mechanism for devices that make use of 802.1AR. Very ANIMAesque. What I'm suggesting, and perhaps it's a bit late for this draft, is just a statement in this draft along the lines that "signing and verifying happens at the JSON level; see [ref] for how to do it", and for extra credit an example would be exceedingly cool.=20 That way we as developers know what to do (again, I'm neither a JSON nor netmod expert - just trying to make use of what's there for what I am expert at (or so I think)). Eliot On 3/21/16 4:55 PM, Kent Watsen wrote: > > the zerotouch draft uses object signing. XMLSIG was used in earlier > draft, but was replaced with a binary type leaf called 'signature' > having the following description: > > > > description "A PKCS #7 SignedData structure as specified by RFC > 2315 > , Section 9.1 > > encoded using the ASN.1 distinguished encoding rules (DER), as > specified in ITU-T X.690. This signature is generated using the > owner's private private key and an owner-selected digest algorithm > over the redirect-information or the bootstrap-information nodes, > which ever is present, and in whatever encoding they are presented in > (e.g., XML, JSON, etc.)."; // is there a canonical format? reference > "RFC 2315 : PKCS #7: > Cryptographic Message Syntax Version 1.5 ITU-T X.690: Information > technology - ASN.1 encoding rules: Specification of Basic Encoding > Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding > Rules (DER)."; } > Note a question regarding canonical format. As the draft stands, no > format is canonical format is required. The data can be however the > data is provided, by the server when pulling on the RESTCONF resource > URL, or how it is encoded in a message buffer, or encoded to a file on > disk. > > The use of PKCS #7 signing was selected to simplify implementations, > especially on resource-constrained devices. Use of DER encoded ASN.1 > structure was selected to be consistent with other parts of the draft > as well as parts of the server-model draft (in the keychain section).=20 > > Thanks, > Kent > > On Mar 21, 2016, at 11:30 AM, Eliot Lear > wrote: > >> >> >> On 3/21/16 4:19 PM, Juergen Schoenwaelder wrote: >>> Lada, I think Stephen asks about JSON encoded YANG-defined data that >>> is signed, that is, the JSON serialization itself is signed. What >>> happens to the signature if you convert the JSON to corresponding XML= >>> serialization. I think the answer is that the signature is broken in >>> this case and I think this is quite natural. >>> >>> Object signatures so far never came up in the NETCONF/YANG context >>> (well not quite correct, I think there is some related discussion >>> aroud the zero-config draft) but even if they do, I think we will hav= e >>> to accept that signatures are encoding specific. And I think this is >>> not a big deal; if I sign my HTML encoded email, then the signature >>> likely won't apply to a text-only rendering of the same email. >>> >> >> However this goes, it should be well documented somewhere. This will >> not be the first time this comes up (he says, knowingly). >> >> Eliot >> --------------060405050406070804020301 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kent,

Thanks for the pointer.=C2=A0 The zeroconf draft is cool beans to be sure.=C2=A0 That describes an enrollment mechanism for devices that m= ake use of 802.1AR.=C2=A0 Very ANIMAesque.=C2=A0 What I'm suggesting, and= perhaps it's a bit late for this draft, is just a statement in this draft along the lines that "signing and verifying happens at the JSON level; see [ref] for how to do it", and for extra credit an example would be exceedingly cool.=C2=A0 That way we as developers know what = to do (again, I'm neither a JSON nor netmod expert - just trying to make use of what's there for what I am expert at (or so I think)).
Eliot




On 3/21/16 4:55 PM, Kent Watsen wrote:=

the zerotouch draft uses object signing. =C2=A0 XMLSIG was use= d in earlier draft, but was replaced with a binary type leaf called 'signature' having the following description:



RFC
           2315, Section 9.1 =
encoded using the ASN.1 distinguished
           encoding rules (DER), as specified in ITU-T X.690.
           This signature is generated using the owner's private
           private key and an owner-selected digest algorithm over
           the redirect-information or the bootstrap-information
           nodes, which ever is present, and in whatever encoding
           they are presented in (e.g., XML, JSON, etc.).";
           // is there a canonical format?
        reference
          "RFC 2315:
              PKCS #7: Cryptographic Message Syntax Version 1.5
           ITU-T X.690:
              Information technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER),
              Canonical Encoding Rules (CER) and Distinguished
              Encoding Rules (DER).";
      }
lear@cisco.=
com>
        wrote:


On 3/21/16 4:19 PM, Juergen Schoenwaelder wrote:
Lada, I think Stephen asks abou= t JSON encoded YANG-defined data that
is signed, that is, the JSON serialization itself is signed. What
happens to the signature if you= convert the JSON to corresponding XML
serialization. I think the answer is that the signature is broken in
this case and I think this is quite natural.

Object signatures so far never came up in the NETCONF/YANG context
(well not quite correct, I thin= k there is some related discussion
aroud the zero-config draft) bu= t even if they do, I think we will have
to accept that signatures are encoding specific. And I think this is
not a big deal; if I sign my HTML encoded email, then the signature
likely won't apply to a text-only rendering of the same email.


However this goes, it should be well documented somewhere. =C2=A0This will
not be the first time this comes up (he says, knowingly).

Eliot


--------------060405050406070804020301-- --d61pgAHPMwCKwotNJtBBVKcd8Sb2vlPxn-- --TuR2vXPhoBwiQcLXhm9Etplm1I0nwKNDt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJW8CsiAAoJEIe2a0bZ0noz/vwH/3alhOtd4qZrtHLLlDwZtcwy f+La5/wKFCiVeDkuGus3Xv6NdS+ESxgilIxFW0DvVSiy1ofkQuiBV+TH7vR75r8O yecoYfYJmXdJeB1p7GEE/e2IrRMst/42Uuvik6HQzQp85z5NaQcVks+nWkSl9cgE VK5wXAUMV/yydkkjkdjodVZTuiU52gHQXUOhRU4igxPyV0V3I6TDS7MhfWEE1Sg1 ifm6ePlPvclDHp7BcKkSWoVA6fYVDV/LvrvxddLH1rcL4WUxUwjkLF0nYqpUldsv GoKYOzZaCVC2Krkk6nAZq4VvTLVceEQsFeeQZ3OvNifAowtr7qX+fjz5BNFdn0E= =s6cL -----END PGP SIGNATURE----- --TuR2vXPhoBwiQcLXhm9Etplm1I0nwKNDt-- From nobody Mon Mar 21 14:05:20 2016 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 D169E12DB75; Mon, 21 Mar 2016 14:05:00 -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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321210500.12239.60501.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 14:05:00 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-metadata-07.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, 21 Mar 2016 21:05:01 -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 : Defining and Using Metadata with YANG Author : Ladislav Lhotka Filename : draft-ietf-netmod-yang-metadata-07.txt Pages : 20 Date : 2016-03-21 Abstract: This document defines a YANG extension statement that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-metadata-07 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 21 14:08:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F5712DB24 for ; Mon, 21 Mar 2016 14:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 RrtQQOJUvWQ0 for ; Mon, 21 Mar 2016 14:08:41 -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 EDB2F12D535 for ; Mon, 21 Mar 2016 14:08:37 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:4493:a404:fff8:e618] (unknown [IPv6:2a01:5e0:29:ffff:4493:a404:fff8:e618]) by mail.nic.cz (Postfix) with ESMTPSA id A2E9D181765 for ; Mon, 21 Mar 2016 22:08:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1458594516; bh=z1nd8e/HiSCQT6eeETjEvdBX852pAoXJ7jMw1EOMQH0=; h=From:Date:To; b=pKPU7Ny6NN/QfWAo5PsCInEJVBTeNZjAEQedrtI/+Vx856Lcz9Wwpr+mh7AzfQLmz SRivZdCWm/IeQFZqXhfeXAuDjOkwNLE7VK2Qiel/S20f678vVzkYtLPtZWFkE5Qeo6 FaeuI5GGKozEIOch406WTR/DwxKJ8Z6QPIKhXdBQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160321210500.12239.60501.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 22:08:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9E6C980B-EDA1-4C32-8867-1016D9E7EF40@nic.cz> References: <20160321210500.12239.60501.idtracker@ietfa.amsl.com> To: NETMOD WG X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-metadata-07.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, 21 Mar 2016 21:08:43 -0000 Hi, compared to -06, there is only one change: following Stephen Farrell's = comment, I added this sentence to Security Considerations: It is RECOMMENDED that security-sensitive or privacy-sensitive data be = modeled as regular YANG data nodes rather than annotations. Lada > On 21 Mar 2016, at 22:05, internet-drafts@ietf.org wrote: >=20 >=20 > 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 : Defining and Using Metadata with YANG > Author : Ladislav Lhotka > Filename : draft-ietf-netmod-yang-metadata-07.txt > Pages : 20 > Date : 2016-03-21 >=20 > Abstract: > This document defines a YANG extension statement that allows for > defining metadata annotations in YANG modules. The document also > specifies XML and JSON encoding of annotations and other rules for > annotating instances of YANG data nodes. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-metadata-07 >=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 21 14:32:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB0412DB7B for ; Mon, 21 Mar 2016 14:32:40 -0700 (PDT) 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 Mo3OzwytfWsy for ; Mon, 21 Mar 2016 14:32:39 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id B7B9112DBB7 for ; Mon, 21 Mar 2016 14:32:23 -0700 (PDT) Received: (qmail 19844 invoked by uid 0); 21 Mar 2016 21:32:21 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy1.mail.unifiedlayer.com with SMTP; 21 Mar 2016 21:32:21 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id YlYG1s01W2SSUrH01lYKvH; Mon, 21 Mar 2016 15:32:19 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=U5ST3gmS5RaqjZVScDMA:9 a=QEXdDO2ut3YA:10 a=pLmDq2hpMWoA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To:Cc; bh=odXm3iA8HlQwOnA7slpxJx4xfuFlLH/7XJpixePEqMA=; b=d3lfTWao/9HZAdRmZNioZseRW5 8JQXR3T+B5wTXC+dsJeIElAUqGD+fuDf5YL0CK6iY9pw+P9EQsdHZjI11/x/8j8w4VbBDEjGsS8+1 GOosxM7AWYHBjLgOmi8QaBScX; Received: from box313.bluehost.com ([69.89.31.113]:36328 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1ai7Qw-0002OH-ON; Mon, 21 Mar 2016 15:32:18 -0600 To: netmod WG From: Lou Berger Message-ID: <56F0685C.4070204@labn.net> Date: Mon, 21 Mar 2016 17:32:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod chairs Subject: [netmod] Draft agenda posted 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, 21 Mar 2016 21:32:40 -0000 Hi, A draft agenda for BA has been posted at https://www.ietf.org/proceedings/95/agenda/agenda-95-netmod . Please review and let us know if we've missed something. Our schedule may look a bit unusual as we received more time than we requested, and there's a snack break in the middle of our back-to-back sessions. Thank you, NETMOD Chairs PS Kudos to Ashesh (our secretary) for consolidating the meeting requests. From nobody Mon Mar 21 14:33:57 2016 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 1546A12DACB; Mon, 21 Mar 2016 14:33:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321213352.12191.82884.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 14:33:52 -0700 Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org, draft-ietf-netmod-yang-metadata@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [netmod] Protocol Action: 'Defining and Using Metadata with YANG' to Proposed Standard (draft-ietf-netmod-yang-metadata-07.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, 21 Mar 2016 21:33:52 -0000 The IESG has approved the following document: - 'Defining and Using Metadata with YANG' (draft-ietf-netmod-yang-metadata-07.txt) as Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ Technical Summary This document defines a YANG extension statement that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. Working Group Summary There has been some controversy regarding the fact that metadata annotations are defined using a YANG extension, which means that they are by definition optional to implement. On the other hand, introducing a new built-in YANG statement was considered a big change that's not suited for inclusion in the minor (1.1) revision of YANG. Document Quality In the past, vendors of management software and networking devices introduced a number of proprietary metadata annotations for various purposes. This document allows for including information about annotations in YANG data models so that standard annotations can be defined in an interoperable way, and in both supported encodings (XML and JSON). The RESTCONF protocol document [draft-ietf-netconf-restconf] has a normative reference to this document for the encoding of metadata. Also, the widely used tool `pyang` has already been updated to support this draft. Personnel The Shepherd is Kent Watsen. The AD is Benoit Claise If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are Tim Bray, Martin Thomson (http://www.iana.org/assignments/xml-registry/xml-registry.xhtml) From nobody Mon Mar 21 19:36:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5241912D643; Mon, 21 Mar 2016 19:36:54 -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] 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 wyi8dFIy8p2v; Mon, 21 Mar 2016 19:36:52 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABE512D63C; Mon, 21 Mar 2016 19:36:52 -0700 (PDT) Received: from tops.chopps.org (24-247-68-31.dhcp.trcy.mi.charter.com [24.247.68.31]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A382F6021F; Tue, 22 Mar 2016 02:36:51 +0000 (UTC) References: <56F01EB7.5000804@labn.net> User-agent: mu4e 0.9.16; emacs 24.5.1 From: To: Lou Berger In-reply-to: <56F01EB7.5000804@labn.net> Date: Mon, 21 Mar 2016 22:36:50 -0400 Message-ID: <87twjzme65.fsf@tops.chopps.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: netmod chairs , netmod WG Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount 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, 22 Mar 2016 02:36:54 -0000 --=-=-= Content-Type: text/plain Support. Thanks, Chris. Lou Berger writes: > All, > > This is start of a two week poll on making > draft-bjorklund-netmod-structural-mount-02 a working group document with > the name draft-ietf-netmod-schema-mount. > > This adoption is a little bit unusual in that, per our last interim, we > know that this document is likely to see significant changes in > technical (solution) details as it progresses through normal WG process. > And the -01 version is expected to be done in combination with > Lada/draft-lhotka-netmod-ysdl. > > Please send email to the list indicating "yes/support" or "no/do not > support". Note that Yes indicates your support for working on a schema > mount solution, rather than the specific solution. If you have specific > technical proposals/suggestions that you'd like to voice please feel > free to also do so - but please use a new/different thread so we can > keep the process and technical discussions separate. > > The poll ends April 4, 2016 > (after our in-person meeting, but authors / main contributors are not > expected to be present in BA. So please discuss on list.) > > Thank you, > > NETMOD Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW8K/CAAoJEC4dgw7XuDAlN+MP/1VaOkblfd8dGK/UOpoI2+od kPTQehqRO/vk9snfitx2VZn88juS47To4Z757tdZH9qZtKGCWBtUWepzHnK2xvEN Medlu9pcy87aKMgNzUDq1BaxyHKnAwD9m7xsXExnnsf6sjvjO8KnLj78FSlt2oOP iZCbR6TtHcTxZK5xey/V3u4ju8kiYWf4/t3P6i3nvfpUz+vS4+UISxm0vdskBTE5 H1o4mV5Y69kovVcKXDD0rF9wtFgcGjcIoQDqmjLxOIz57rfX0flAvv9eCVrUqeAz DfwbbIgcoDO8xprP19F51PUY2sYLt80gGRBJ+Jl5ddnICtaFALzxKpKdbVTSoBHZ T1ZYpLCDcCnY0+DzrmiNutM3xgH8cgx5JKNA/Evf9T3KoTM6UyRyoP97Rpyhfsx2 eTV0wb90C7iwdBa8xiv4lDhFA3gz2Ci/7dP41PkTX5w2munzgJ+3PLIb5j06SH2H lJOq2y/8WbLIyaRWTHcl9fgUOe50HlTuFRvgabsJw9WcePttFEVuDbsl4CHjj8uo WGkpIPJYlhhsXn/wj0ThkxtqVO+NQv2M7Qcmuz4uZ+tzoQCNsMHWhUlTrakZrDEq H0isUcrogaiamwzaErvCNseVkTem88AIJqZcxhc2Fm1N/QJ74j6F1QX1lwHxdfRG dZ4t24kErBEj77by1d/O =dkIf -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 22 01:10:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9531812D660; Tue, 22 Mar 2016 01:10:50 -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 DtwhYE1xQcWA; Tue, 22 Mar 2016 01:10:48 -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 5CB8912D541; Tue, 22 Mar 2016 01:10:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 94D0F22CF; Tue, 22 Mar 2016 09:10:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pG7rPucJl7qD; Tue, 22 Mar 2016 09:10: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; Tue, 22 Mar 2016 09:10:45 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B811C20045; Tue, 22 Mar 2016 09:10:45 +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 f3rA4H-rxbWh; Tue, 22 Mar 2016 09:10:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D928220044; Tue, 22 Mar 2016 09:10:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C196A3A4FE33; Tue, 22 Mar 2016 09:10:43 +0100 (CET) Date: Tue, 22 Mar 2016 09:10:43 +0100 From: Juergen Schoenwaelder To: Eliot Lear Message-ID: <20160322081043.GA64402@elstar.local> Mail-Followup-To: Eliot Lear , Kent Watsen , Ladislav Lhotka , Stephen Farrell , The IESG , "draft-ietf-netmod-yang-json@ietf.org" , "netmod-chairs@ietf.org" , "netmod@ietf.org" References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> <56F02B21.3080103@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F02B21.3080103@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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: Tue, 22 Mar 2016 08:10:50 -0000 On Mon, Mar 21, 2016 at 06:10:57PM +0100, Eliot Lear wrote: > Hi Kent, > > Thanks for the pointer. The zeroconf draft is cool beans to be sure. > That describes an enrollment mechanism for devices that make use of > 802.1AR. Very ANIMAesque. What I'm suggesting, and perhaps it's a bit > late for this draft, is just a statement in this draft along the lines > that "signing and verifying happens at the JSON level; see [ref] for how > to do it", and for extra credit an example would be exceedingly cool. > That way we as developers know what to do (again, I'm neither a JSON nor > netmod expert - just trying to make use of what's there for what I am > expert at (or so I think)). > This I-D is an object encoding specification. Why would this document have to talk about possible object signatures? /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 22 01:47:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5E812D7F1; Tue, 22 Mar 2016 01:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 FqFiRraoCbsg; Tue, 22 Mar 2016 01:47:09 -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 C103812D7EC; Tue, 22 Mar 2016 01:47:08 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:b0ca:cea3:dd8b:f5c0] (unknown [IPv6:2001:718:1a02:1:b0ca:cea3:dd8b:f5c0]) by mail.nic.cz (Postfix) with ESMTPSA id 329A018031C; Tue, 22 Mar 2016 09:47:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1458636427; bh=mBl1jZW7+W+mo+eTrAoD78gPU+AxXoGcyfQAH0zvJN8=; h=From:Date:To; b=ZDBiNqcojRmAoiFG48Yrp1qAqbJWyhnQJNcYZbyndTaHks0a3jISHlw7Q7K8os2jG 3ejC6OXo6DwJ8N47faQsBiXhFPvWNkth6Nw1l6N6lUwTLvrEX7cmEXVKmIl845vhos xr9Ym4l62PdGJOQndoeL2lekQVJsAZFOjByz0caQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160322081043.GA64402@elstar.local> Date: Tue, 22 Mar 2016 09:47:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7DA81401-6AE5-4DCA-A8C7-3B41ED5B2C06@nic.cz> References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> <56F02B21.3080103@cisco.com> <20160322081043.GA64402@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 22 Mar 2016 08:47:11 -0000 > On 22 Mar 2016, at 09:10, Juergen Schoenwaelder = wrote: >=20 > On Mon, Mar 21, 2016 at 06:10:57PM +0100, Eliot Lear wrote: >> Hi Kent, >>=20 >> Thanks for the pointer. The zeroconf draft is cool beans to be sure.=20= >> That describes an enrollment mechanism for devices that make use of >> 802.1AR. Very ANIMAesque. What I'm suggesting, and perhaps it's a = bit >> late for this draft, is just a statement in this draft along the = lines >> that "signing and verifying happens at the JSON level; see [ref] for = how >> to do it", and for extra credit an example would be exceedingly cool.=20= >> That way we as developers know what to do (again, I'm neither a JSON = nor >> netmod expert - just trying to make use of what's there for what I am >> expert at (or so I think)). >>=20 >=20 > This I-D is an object encoding specification. Why would this document > have to talk about possible object signatures? +1 These issues are important but they should IMO be dealt with separately. Thanks, 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: E74E8C0C From nobody Tue Mar 22 07:55:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D02612DA17; Tue, 22 Mar 2016 07:54: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_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 yUZTqeGip5un; Tue, 22 Mar 2016 07:54:40 -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 0A0F212D9EF; Tue, 22 Mar 2016 07:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2063; q=dns/txt; s=iport; t=1458658480; x=1459868080; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=UeHUQuTTO/u6ZqClQiGskf3awy3KySx9Ho0tWZiStOA=; b=ZOPw0HMQzRb6VL0VBIZ4vOBdY6JIWKJT10dz0eaj5izceJVpnNYv1tsB nzZhFivftcCMUnWKjjrKanMvrpvKAY0l89wgxsirEb++dDiXgWAsYWHCk tPWLwYBwqGJFt+k3pDBNJhe6ykH5NBiG14KkqmKJ35sKVjRocIdejA+9x 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQAkXPFW/xbLJq1ehAZ6uDaCDwENg?= =?us-ascii?q?XAhhSJKAoF8FAEBAQEBAQFkJ4RCAQEEODMNARALIRYPCQMCAQIBRQYBCQMGAgE?= =?us-ascii?q?BiCMOwHIBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYehESEHQEBhXMBBIdgj3eOB?= =?us-ascii?q?IFlhEyDBIVUjwceAQFCggMZFIE2Oy4BiFOBMgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,377,1454976000"; d="scan'208";a="676222640" 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; 22 Mar 2016 14:54:37 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u2MEsbZc000786; Tue, 22 Mar 2016 14:54:37 GMT To: Ladislav Lhotka , Stephen Farrell , The IESG References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <56F15CAD.2010406@cisco.com> Date: Tue, 22 Mar 2016 15:54:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.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, draft-ietf-netmod-yang-json@ietf.org, netmod@ietf.org Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 22 Mar 2016 14:54:54 -0000 Dear all, > Hi Stephen, > > thanks for your comments, please see my responses inline. > > Stephen Farrell writes: > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - I would have thought that it'd be useful to point out any >> issues with round-tripping, e.g. going from XML to JSON and >> back to XML or vice-versa. But I didn't see any mention of >> that. How come? > I believe fifth paragraph in sec. 3 is what you are asking for: > > With the exception of anyxml and schema-less anydata nodes, it is > possible to map a JSON-encoded data tree to XML encoding as defined > in [I-D.ietf-netmod-rfc6020bis], and vice versa. However, such > conversions require the YANG data model to be available. Thanks. >> - I'm not sure if anyone has considered XMLDSIG or use of JOSE >> with YANG. If one did, then this kind of mapping would not >> allow one to preserve digital signatures without a lot of >> work. I assume that that's considered ok. (Which it can be, >> depending on how one does object level security, if one does >> object level security.) > I am not an expert on digital signatures and their representations, but > I'd say they could be modelled as YANG's "binary" type (and transferred > base64-encoded). This should work equally well in XML and JSON, > including round trips. I skipped this point above for now as the thread goes on. > >> - It's not clear to me if the discussion of the secdir review >> [1] concluded. It seemed to just stall. Is there more to be >> said? (If so, be great if the shepherd would kick that >> discussion.) > I don't have much more to say without seeing alternative proposals. I re-reviewed the security directory review, and from my vantage point, I believe that Lada addressed the review. Regards, Benoit > > Lada > >> [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06408.html >> >> From nobody Tue Mar 22 07:59:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73A412D641; Tue, 22 Mar 2016 07:59:17 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 3TW8Ws74ToX9; Tue, 22 Mar 2016 07:59:16 -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 E2D2612D913; Tue, 22 Mar 2016 07:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1489; q=dns/txt; s=iport; t=1458658751; x=1459868351; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=B/Mq11h+YoGjGJ3l4CLK9ZtEWm40ZBmtcTWtHPnGe84=; b=Mdcr6G2K5APvceFpFEs5FUqVhRClfuewGs+5p5vdGeKi7TQfntBtAF16 hzgGc4+cYu9Ak+h4Qx9QExGQXmUxKhDopgClCyPPXjHVvyMX4x2NxRvwT ZhfJWAXqV0qoYJovtqgfa0CHarHr/JO1En4IOLJjK4G2o1DmTsfCw/DBi k=; X-IronPort-AV: E=Sophos;i="5.24,377,1454976000"; d="scan'208";a="633635159" 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; 22 Mar 2016 14:59:09 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2MEx9Ih021320; Tue, 22 Mar 2016 14:59:09 GMT To: Ladislav Lhotka , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> <56F02B21.3080103@cisco.com> <20160322081043.GA64402@elstar.local> <7DA81401-6AE5-4DCA-A8C7-3B41ED5B2C06@nic.cz> From: Benoit Claise Message-ID: <56F15DBC.5050905@cisco.com> Date: Tue, 22 Mar 2016 15:59:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <7DA81401-6AE5-4DCA-A8C7-3B41ED5B2C06@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 22 Mar 2016 14:59:18 -0000 On 3/22/2016 9:47 AM, Ladislav Lhotka wrote: >> On 22 Mar 2016, at 09:10, Juergen Schoenwaelder wrote: >> >> On Mon, Mar 21, 2016 at 06:10:57PM +0100, Eliot Lear wrote: >>> Hi Kent, >>> >>> Thanks for the pointer. The zeroconf draft is cool beans to be sure. >>> That describes an enrollment mechanism for devices that make use of >>> 802.1AR. Very ANIMAesque. What I'm suggesting, and perhaps it's a bit >>> late for this draft, is just a statement in this draft along the lines >>> that "signing and verifying happens at the JSON level; see [ref] for how >>> to do it", and for extra credit an example would be exceedingly cool. >>> That way we as developers know what to do (again, I'm neither a JSON nor >>> netmod expert - just trying to make use of what's there for what I am >>> expert at (or so I think)). >>> >> This I-D is an object encoding specification. Why would this document >> have to talk about possible object signatures? > +1 > > These issues are important but they should IMO be dealt with separately. Ok. Where should it be described? RFC6087bis? Regards, Benoit > > Thanks, 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: E74E8C0C > > > > > . > From nobody Tue Mar 22 08:22:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9678D12DA10 for ; Tue, 22 Mar 2016 08:22:24 -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 E_pmFWf8m8kL for ; Tue, 22 Mar 2016 08:22:22 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 F003412DA40 for ; Tue, 22 Mar 2016 08:22:21 -0700 (PDT) Received: by mail-lb0-x231.google.com with SMTP id bc4so166722953lbc.2 for ; Tue, 22 Mar 2016 08:22: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:date:message-id:subject:from:to :cc; bh=wbn+B8rmWqpzhQv08hnpF2LGWfRwtaLKznVgJnbPlCU=; b=Jz8286+Ja/8EzVh1Stf5rlQRuEVjAD7rXYkLXi6Hkg1smg29dgwTrHEMt3da23aeo9 +1WyorbCoKvKuS0O/Kul1M6V7ulTCYpWWCIZHrwN2D5MeHHdUd4W7lUm83wNxb205NHQ iOwoY3t/Y4Yfu5bfldiKHL6gMh9tXFoStn6hrntwXuWsk5hYs/juT8DUgMfoLLlaLU+n I9nC/Mey4XI15HkgnCtoso62hwxBrPggszR0ePRBogZCvV7Zf2j47ZDkTT2/HAwIJhTK vKhjzp9mKNJA+CJfB1n7BWKPS9F2IY3ckKa4UaSuc4tm1Jx+/5ii+eu8VGclsQd9joKp ezlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wbn+B8rmWqpzhQv08hnpF2LGWfRwtaLKznVgJnbPlCU=; b=VbtDgbdyN9MQsVbVfvwHZb0N49TpU51SGD8ncM5DhYRVmGVqMaGXpLneR1Gq8SnGRs 2Lk+72gycONkfQOG+93EJhGVYiwZKCwvRbisAavZPG2x/cA34I34ap/ImI5+gXjP3CUe UuGE4QaZllYZrXD110oV2lcy9kIA07sfkQe05t2aoiy4ftrbwN5KUmZIUMGaIgULhkDF 0FEO5b9EfVU4Rx2rgjh93OI4BGIicIn4AMsp/ldtCMFg8tY/mEbxS1fMPzrLK1TZsYW6 k1s7o1tlNABH6vlV2AohY+GsUeTIEyWi6uLGwlKmOtv3f+4BkWHftNMCGUxk1+RLpaHI lVnw== X-Gm-Message-State: AD7BkJIYa1fKex5A3I1h/vMySMmEYXjxcDMAjzmxpJKXLKHIk/eYrbutpilozfr3E4Smh4pWA8mI1ymlLnf7ng== MIME-Version: 1.0 X-Received: by 10.25.85.145 with SMTP id j139mr13470387lfb.131.1458660139630; Tue, 22 Mar 2016 08:22:19 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Tue, 22 Mar 2016 08:22:19 -0700 (PDT) In-Reply-To: <23FD825DF7C2A6489CA3B5077FB1DC8603B47F848E@ONWVEXCHMB03.ciena.com> References: <23FD825DF7C2A6489CA3B5077FB1DC8603B47F7F83@ONWVEXCHMB03.ciena.com> <20160317.213218.2303351254263780998.mbj@tail-f.com> <56EBC795.70209@mg-soft.si> <23FD825DF7C2A6489CA3B5077FB1DC8603B47F848E@ONWVEXCHMB03.ciena.com> Date: Tue, 22 Mar 2016 08:22:19 -0700 Message-ID: From: Andy Bierman To: "Larsson, Gustav" Content-Type: multipart/alternative; boundary=001a11405936789429052ea4c7c7 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] deviation that changes config true to false: deviate add or replace? 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, 22 Mar 2016 15:22:24 -0000 --001a11405936789429052ea4c7c7 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 18, 2016 at 11:44 AM, Larsson, Gustav wrote: > Jernej Tuljak wrote: > > Martin Bjorklund je 17.3.2016 ob 21:32 napisal: > > > "Larsson, Gustav" wrote: > > > The argument "replace" replaces properties of the target node. The > > > > properties to replace are identified by substatements to the > > > > "deviate" statement. The properties to replace MUST exist in the > > > > target node. > > > > > > > > /x/y is config true by default even though config is not explictly > > > > given. Section 7.19.1 of RFC 6020 is not clear about whether config > > > > is considered to exist when defaulted. > > > Don't you think it is clear how the config value is inherited? > > > > > > If "config" is not specified, the default is the same as the parent > > > schema node's "config" value. If the parent node is a "case" node, > > > the value is the same as the "case" node's parent "choice" node. > > > > > > If the top node does not specify a "config" statement, the default > is > > > "true". > > > > > > > > > This text doesn't use the words "config property", this could probably > > > be clarified. > > > > > > > What needs to be clarified is the definition of "property". I always read > > this as "substatement": "units", "default", "require-instance", "when", > > "if-feature", "ordered-by" are all being referred to as "properties" and > > those are not inherited. On the other hand, "mandatory" is never referred > > to as a "property". > > > > Also, "refine" statement text, which is practically analogous to > "deviation", > > explicitly uses "statement" for refinements (config included). > > I agree that the definition of "property" needs to be clarified. > > Another way of looking at it is whether "property" refers to the > (syntactic) > substatement or the (semantic) value. When the config value is inherited, > the config substatement is syntactically absent but the config value is > semantically present. It is unclear whether the "config property" is > considered to be (syntactically) absent or (semantically) present for the > purposes of deviate statements. > > > Our implementation requires "add", if no "config" substatement is present > > in the target node (as did early versions of pyang, if I'm not mistaken). > > > >Jernej > > That's what I was concerned about. The latest pyang (1.6) seems to take > the opposite approach by requiring "replace". > > Our code doesn't care if it is "add" or "replace". Both will work. Forcing 1 or the other is rather fragile. I fail to see any value at all in making a distinction between add and replace. It is unclear whether it means the property (which always exists) or the statement (in which the actual stmt placement is irrelevant in some cases), It is also unclear what it means wrt/ multiple deviations from different modules changing the same thing. There is no order defined for applying multi-module deviations, so which one wins? Gustav > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11405936789429052ea4c7c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 18, 2016 at 11:44 AM, Larsson, Gustav <= ;glarsson@ciena.com= > wrote:
Jernej Tuljak wrot= e:
> Martin Bjorklund je 17.3.2016 ob 21:32 napisal:
> > "Larsson, Gustav" <glarsson@ciena.com> wrote:
> >=C2=A0 =C2=A0 =C2=A0The argument "replace" replaces prop= erties of the target node.=C2=A0 The
> > >=C2=A0 =C2=A0 =C2=A0properties to replace are identified by s= ubstatements to the
> > >=C2=A0 =C2=A0 =C2=A0"deviate" statement.=C2=A0 The = properties to replace MUST exist in the
> > >=C2=A0 =C2=A0 =C2=A0target node.
> > >
> > > /x/y is config true by default even though config is not exp= lictly
> > > given. Section 7.19.1 of RFC 6020 is not clear about whether= config
> > > is considered to exist when defaulted.
> > Don't you think it is clear how the config value is inherited= ?
> >
> >=C2=A0 =C2=A0 If "config" is not specified, the default = is the same as the parent
> >=C2=A0 =C2=A0 schema node's "config" value.=C2=A0 If= the parent node is a "case" node,
> >=C2=A0 =C2=A0 the value is the same as the "case" node&#= 39;s parent "choice" node.
> >
> >=C2=A0 =C2=A0 If the top node does not specify a "config"= ; statement, the default is
> >=C2=A0 =C2=A0 "true".
> >
> >
> > This text doesn't use the words "config property", = this could probably
> > be clarified.
> >
>
> What needs to be clarified is the definition of "property". = I always read
> this as "substatement": "units", "default&quo= t;, "require-instance", "when",
> "if-feature", "ordered-by" are all being referred = to as "properties" and
> those are not inherited. On the other hand, "mandatory" is n= ever referred
> to as a "property".
>
> Also, "refine" statement text, which is practically analogou= s to "deviation",
> explicitly uses "statement" for refinements (config included= ).

I agree that the definition of "property" needs to be clarified.<= br>
Another way of looking at it is whether "property" refers to the = (syntactic)
substatement or the (semantic) value. When the config value is inherited, the config substatement is syntactically absent but the config value is
semantically present. It is unclear whether the "config property"= is
considered to be (syntactically) absent or (semantically) present for the purposes of deviate statements.

> Our implementation requires "add", if no "config" = substatement is present
> in the target node (as did early versions of pyang, if I'm not mis= taken).
>
>Jernej

That's what I was concerned about. The latest pyang (1.6) seems to take=
the opposite approach by requiring "replace".


Our code doesn't care if it is &qu= ot;add" or "replace".=C2=A0 Both will work.
Forcin= g 1 or the other is rather fragile.

I fail to see = any value at all in making a distinction between add and replace.
It is unclear whether it means the property (which always exists)
or the statement (in which the actual stmt placement is irrelevant in som= e cases),

It is also unclear what it means wrt/ mu= ltiple deviations from different modules changing
the same thing.= =C2=A0 There is no order defined for applying multi-module deviations,
so which one wins?=C2=A0

Gustav

Andy
=C2=A0

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

--001a11405936789429052ea4c7c7-- From nobody Tue Mar 22 08:42:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C085C12D798; Tue, 22 Mar 2016 08:42:32 -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 Dy1EezdmtuNl; Tue, 22 Mar 2016 08:42: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 49C2712D9F4; Tue, 22 Mar 2016 08:42: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 6EE15F6C; Tue, 22 Mar 2016 16:42:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gpSE7lZW2cCt; Tue, 22 Mar 2016 16:42: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, 22 Mar 2016 16:42:27 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9607E20044; Tue, 22 Mar 2016 16:42:27 +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 Ury08HGXNTP7; Tue, 22 Mar 2016 16:42: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 D237920043; Tue, 22 Mar 2016 16:42:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A4A303A500C7; Tue, 22 Mar 2016 16:42:24 +0100 (CET) Date: Tue, 22 Mar 2016 16:42:23 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20160322154223.GA65166@elstar.local> Mail-Followup-To: Benoit Claise , Ladislav Lhotka , "netmod-chairs@ietf.org" , Kent Watsen , "netmod@ietf.org" , Eliot Lear , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> <56F02B21.3080103@cisco.com> <20160322081043.GA64402@elstar.local> <7DA81401-6AE5-4DCA-A8C7-3B41ED5B2C06@nic.cz> <56F15DBC.5050905@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F15DBC.5050905@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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: Tue, 22 Mar 2016 15:42:33 -0000 On Tue, Mar 22, 2016 at 03:59:08PM +0100, Benoit Claise wrote: > On 3/22/2016 9:47 AM, Ladislav Lhotka wrote: > >>On 22 Mar 2016, at 09:10, Juergen Schoenwaelder > >> wrote: > >> > >>On Mon, Mar 21, 2016 at 06:10:57PM +0100, Eliot Lear wrote: > >>>Hi Kent, > >>> > >>>Thanks for the pointer. The zeroconf draft is cool beans to be sure. > >>>That describes an enrollment mechanism for devices that make use of > >>>802.1AR. Very ANIMAesque. What I'm suggesting, and perhaps it's a bit > >>>late for this draft, is just a statement in this draft along the lines > >>>that "signing and verifying happens at the JSON level; see [ref] for how > >>>to do it", and for extra credit an example would be exceedingly cool. > >>>That way we as developers know what to do (again, I'm neither a JSON nor > >>>netmod expert - just trying to make use of what's there for what I am > >>>expert at (or so I think)). > >>> > >>This I-D is an object encoding specification. Why would this document > >>have to talk about possible object signatures? > >+1 > > > >These issues are important but they should IMO be dealt with separately. > Ok. Where should it be described? RFC6087bis? > I think such considerations belongs into documents making use of object signatures and close to 100% of the YANG models today don't so I do not even think this qualifies for RFC6087bis. /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 22 09:11:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0168712D89B; Tue, 22 Mar 2016 09:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MJSa46n9RGq; Tue, 22 Mar 2016 09:11:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DAF12D6C5; Tue, 22 Mar 2016 09:10:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 33567BE33; Tue, 22 Mar 2016 16:10:54 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QDOUwWtBoDp; Tue, 22 Mar 2016 16:10:48 +0000 (GMT) Received: from [192.150.181.133] (unknown [192.150.181.133]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2BF28BE35; Tue, 22 Mar 2016 16:10:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458663048; bh=rlahitxsf+qzh0W2ViqI9D2TmOdMj8qAW5SW3RjAqKk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jmgwJUT5BdFmyGDnkYwnps8LI9dJ4pFbDrso9WFCQlwTiTV/sLwo0xkJ1VAHUyjdm tQ2KceymJLSMmwWRT8dOdZgppS/J1//a9FY8QVjCwq8Wx7KZT5HRSSZT/Vpdc5/kGJ qGTz5O3fK1LWJ+pnxD+8O2aLcNAmYEo/RUU14ADw= To: Benoit Claise , Ladislav Lhotka , The IESG References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <56F15CAD.2010406@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F16E87.7070902@cs.tcd.ie> Date: Tue, 22 Mar 2016 16:10:47 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56F15CAD.2010406@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070909070705030301070402" Archived-At: Cc: netmod-chairs@ietf.org, draft-ietf-netmod-yang-json@ietf.org, netmod@ietf.org Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 22 Mar 2016 16:11:28 -0000 This is a cryptographically signed message in MIME format. --------------ms070909070705030301070402 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 22/03/16 14:54, Benoit Claise wrote: > I re-reviewed the security directory review, and from my vantage point,= > I believe that Lada addressed the review. In case it helps, I've no problems with that. S >=20 > Regards, Benoit --------------ms070909070705030301070402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjIx NjEwNDdaMC8GCSqGSIb3DQEJBDEiBCBPAgGLQ47/jVuJKJWnuSX3zTajby5B9wIustYRQCbv 7jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAJa7yTcjdVRMldygsixjSWQ5/zeb+jJzndlU7XkH+zJClnrhv5hb3D dJYQUFPwHPOwMaeuvTK+S5iCt8/3qedYlvWYmOND8boVKtpod9ha2LwvVn4gkJkOy/fEZt+R N0cpreZE8aMho+X2pHh+aMBbt6lF6Wuv+k2WjVC+JIgc2G+aMWJl/YysQV0OLrspwuHfvu14 u2cgDc0CPktJMWCnmJZGSARc4Z6Qm1GuwXFz1oTuNkqyE9iAcV6b9MQTrLRkMtDsl2CVaMJ/ UE+SdFULr8aFIjX3M6AeMM9s0YlNvFkZs98GXPfk85IToIYVIorEimzrZYstrf+/cPcQCQva AAAAAAAA --------------ms070909070705030301070402-- From nobody Tue Mar 22 09:12:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4981E12DB07 for ; Tue, 22 Mar 2016 09:12:34 -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_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 GzxHB_FG6raM for ; Tue, 22 Mar 2016 09:12:27 -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 4008D12DAEC for ; Tue, 22 Mar 2016 09:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5485; q=dns/txt; s=iport; t=1458663113; x=1459872713; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=lcrH1VbcLA9X2E5u5T50PEJlIyZLwtjA3ua20R0l4zo=; b=EAJy256IZVyChkCSYpnRJztdzs0NcFKU6Ml6B7bWsoL2glqZR9u2JriT llnmvaGM2lFV8xL+voxbLsFlMlOu56kiiuJ7CoKklrv1bK1IeULp8KDNf sF8t4YEsiNOdRLfJuaAKqhF2ApYMByY9HMOMdiZvF1l5DNLICU+6uHysp A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADBQB1bfFW/xbLJq1EGoQGerVXhmwjh?= =?us-ascii?q?WoCghQBAQEBAQFlJ4RBAQEBBHgRHAMBAgoWDwkDAgECATsCCAYNBgIBAYgjDiz?= =?us-ascii?q?AawEBAQEBAQEBAQEBAQEBAQEBAQEXhh6ERIRHFQyFKgWTBIRThXGFXII3gWUWN?= =?us-ascii?q?4N/gwSFVI8HYoIDGRSBNjsuAYoFAQEB?= X-IronPort-AV: E=Sophos;i="5.24,377,1454976000"; d="scan'208,217";a="636472654" 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; 22 Mar 2016 16:11:51 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u2MGBpCf009745 for ; Tue, 22 Mar 2016 16:11:51 GMT References: <20160322155645.2EEE018045A@rfc-editor.org> To: NETMOD Working Group From: Benoit Claise X-Forwarded-Message-Id: <20160322155645.2EEE018045A@rfc-editor.org> Message-ID: <56F16EC7.4080701@cisco.com> Date: Tue, 22 Mar 2016 17:11:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160322155645.2EEE018045A@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------010507090506060909030102" Archived-At: Subject: [netmod] Fwd: [RFC State] has been added to the RFC Editor database 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, 22 Mar 2016 16:12:34 -0000 This is a multi-part message in MIME format. --------------010507090506060909030102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Thank you all for this document. Regards, B. -------- Forwarded Message -------- Subject: [RFC State] has been added to the RFC Editor database Date: Tue, 22 Mar 2016 08:56:45 -0700 From: rfc-editor@rfc-editor.org To: lhotka@nic.cz CC: netmod-ads@ietf.org, netmod-chairs@ietf.org, rfc-editor@rfc-editor.org, kwatsen@juniper.net Author(s), We have received notice that your document draft-ietf-netmod-yang-metadata-07 has been approved for publication as an RFC. The document has been added to the RFC Editor queue and you can check the status at If you submitted your XML file using the I-D submission tool, we have already retrieved it. If you did not submit the XML file via the I-D submission tool, or if you have an updated version (e.g., updated contact information), please send us the XML file at this time. Please attach the file as draft-ietf-netmod-yang-metadata-07.xml, and specify any differences between the approved I-D and the document that the XML produces. We recommend using xml2rfc v2 to create your document. See the RSE's message about the RFC Editor's transition to xml2rfc v2 here . If you created this document using -ms nroff, please send us the source file. This should help increase the pace with which documents move through the RFC Editor queue. Please let us know if you have any questions. Thank you. The RFC Editor Team . --------------010507090506060909030102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Thank you all for this document.

Regards, B.


-------- Forwarded Message --------
Subject: [RFC State] <draft-ietf-netmod-yang-metadata-07> has been added to the RFC Editor database
Date: Tue, 22 Mar 2016 08:56:45 -0700
From: rfc-editor@rfc-editor.org
To: lhotka@nic.cz
CC: netmod-ads@ietf.org, netmod-chairs@ietf.org, rfc-editor@rfc-editor.org, kwatsen@juniper.net 


Author(s),

We have received notice that your document draft-ietf-netmod-yang-metadata-07 has
been approved for publication as an RFC.  The document has
been added to the RFC Editor queue and you can check the status at
<https://www.rfc-editor.org/current_queue.php>

If you submitted your XML file using the I-D submission tool, we have
already retrieved it.  If you did not submit the XML file via the I-D
submission tool, or if you have an updated version (e.g., updated
contact information), please send us the XML file at this time.  Please
attach the file as draft-ietf-netmod-yang-metadata-07.xml, and specify 
any differences between the approved I-D and the document that the XML
produces.  We recommend using xml2rfc v2 <http://xml2rfc.ietf.org/> to create
your document.  See the RSE's message about the RFC Editor's transition to
xml2rfc v2 here 
<https://www.rfc-editor.org/pipermail/rfc-interest/2013-December/005835.html>.

If you created this document using -ms nroff, please send us the
source file.

This should help increase the pace with which documents move through
the RFC Editor queue. 

Please let us know if you have any questions.

Thank you.

The RFC Editor Team

.


--------------010507090506060909030102-- From nobody Tue Mar 22 09:13:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8452E12DACE; Tue, 22 Mar 2016 09:13:01 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 xD35naTuDVtH; Tue, 22 Mar 2016 09:12:59 -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 010C112DAAC; Tue, 22 Mar 2016 09:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5138; q=dns/txt; s=iport; t=1458663148; x=1459872748; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=5RkxgFjtjSuINHFZCkSg955GLuIBwyiQYkPTC6GNMak=; b=g0+7UsPofY3tizaC3CmePeODXUdneNKLf6Btelrn+HsiHnOy2xG+SBXy 5pA8wnF+98ebLwOymq+zxGvOaqj6QPEz5iaVp30wnsOyvnKbxqCi9Tepg clJcCpOfWPGZjlQeUU+V2E9pyVHe7pK3hSt2Pxl19n85uC2lvxgVPlDzY c=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.24,377,1454976000"; d="asc'?scan'208,217";a="633636296" 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 2016 16:12:26 +0000 Received: from [10.61.203.45] ([10.61.203.45]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u2MGCPmp009884; Tue, 22 Mar 2016 16:12:25 GMT To: Benoit Claise , Ladislav Lhotka , "netmod-chairs@ietf.org" , Kent Watsen , "netmod@ietf.org" , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> <56F02B21.3080103@cisco.com> <20160322081043.GA64402@elstar.local> <7DA81401-6AE5-4DCA-A8C7-3B41ED5B2C06@nic.cz> <56F15DBC.5050905@cisco.com> <20160322154223.GA65166@elstar.local> From: Eliot Lear Message-ID: <56F16EE8.70703@cisco.com> Date: Tue, 22 Mar 2016 17:12:24 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160322154223.GA65166@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CHQXs2VF4nX4Gx9mbBRegm5EXJqrqkQfa" Archived-At: Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 22 Mar 2016 16:13:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CHQXs2VF4nX4Gx9mbBRegm5EXJqrqkQfa Content-Type: multipart/mixed; boundary="oS3wK0dp7gNS1Q86giEgaxqv3w6vh4F0f" From: Eliot Lear To: Benoit Claise , Ladislav Lhotka , "netmod-chairs@ietf.org" , Kent Watsen , "netmod@ietf.org" , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell Message-ID: <56F16EE8.70703@cisco.com> Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) References: <20160317113347.3650.38937.idtracker@ietfa.amsl.com> <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> <56F02B21.3080103@cisco.com> <20160322081043.GA64402@elstar.local> <7DA81401-6AE5-4DCA-A8C7-3B41ED5B2C06@nic.cz> <56F15DBC.5050905@cisco.com> <20160322154223.GA65166@elstar.local> In-Reply-To: <20160322154223.GA65166@elstar.local> --oS3wK0dp7gNS1Q86giEgaxqv3w6vh4F0f Content-Type: multipart/alternative; boundary="------------050606070208010902060200" This is a multi-part message in MIME format. --------------050606070208010902060200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Juergen, On 3/22/16 4:42 PM, Juergen Schoenwaelder wrote: > I think such considerations belongs into documents making use of > object signatures and close to 100% of the YANG models today don't > so I do not even think this qualifies for RFC6087bis. > I think there are AT LEAST two areas where signatures are going to be necessary: * There exist multi-level authorization schemes today that rely on signatures. Those have to be transported. * Manufacturer usage descriptions (MUDs) have extremely broad scope in terms of the number of devices that are intended to use the same description (think thousands to millions). And so an unauthorized change could have a similarly broad impact. Thus, wherever the YANG experts think signatures should happen in each encoding case is fine with me; but I'd suggest that I'm not the only person who's going to want to know. Is it THAT hard to at least add a reference? Because if it is, that would cause me to wonder if the mechanisms are really in place to do the right thing. Eliot --------------050606070208010902060200 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Juergen,

On 3/22/16 4:42 PM, Juergen Schoenwaelder wrote:
I think such considerations belongs into documents making use of
object signatures and close to 100% of the YANG models today don't
so I do not even think this qualifies for RFC6087bis.

I think there are AT LEAST two areas where signatures are going to be necessary:
  • There exist multi-level authorization schemes today that rely on signatures.=C2=A0 Those have to be transported.
  • Manufacturer usage descriptions (MUDs) have extremely broad scope in terms of the number of devices that are intended to use the same description (think thousands to millions).=C2=A0 And so = an unauthorized change could have a similarly broad impact.

Thus, wherever the YANG experts think signatures should happen in each encoding case is fine with me; but I'd suggest that I'm not the only person who's going to want to know.=C2=A0 Is it THAT hard to at least add a reference?=C2=A0 Because if it is, that would cause me to= wonder if the mechanisms are really in place to do the right thing.
Eliot

--------------050606070208010902060200-- --oS3wK0dp7gNS1Q86giEgaxqv3w6vh4F0f-- --CHQXs2VF4nX4Gx9mbBRegm5EXJqrqkQfa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJW8W7pAAoJEIe2a0bZ0nozrPgH/Ayaf5IYRq9h/KXpU0pDEzAG XSAjnYG/beKggq6yOB/CpfceRaTJ4SW7TZKPMz7gdbxePS0KIIRog/gj5s/fINFe RpqjbeNlZ78OJ7asQQJsXKfdhf1jn7xfNjDHt1EmAwWjlSsafa2qbIHU/DQlvwyL ITgX0CnP8VccG2n07MzlBQRS3y7Uuo6ZYRm8eE3aVTz0QpDNvHHjFO+/ZCcYbYAb cHtlpezWGWRrLSauP1BUP/EEJPdcoYQ4mWFwqdBPd7CB/4/77bX0kpzkUdh7ZG5s N9jKiWPOvlts+b8SD4x3tuLNQXNFqS4EtZd5ffpo7fTrAzD/pW4e3Ooo7NhdX0A= =ZyDq -----END PGP SIGNATURE----- --CHQXs2VF4nX4Gx9mbBRegm5EXJqrqkQfa-- From nobody Tue Mar 22 09:24:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8D312DAD7; Tue, 22 Mar 2016 09:24: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 JbwtAgAM0Dyd; Tue, 22 Mar 2016 09:24:26 -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 E147212DA7B; Tue, 22 Mar 2016 09:23: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 9D951A53; Tue, 22 Mar 2016 17:23:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Az_0n7gEza8H; Tue, 22 Mar 2016 17:23: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; Tue, 22 Mar 2016 17:23:38 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2E9020044; Tue, 22 Mar 2016 17:23:38 +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 UCmfjkhk8JRQ; Tue, 22 Mar 2016 17:23:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1AFC420043; Tue, 22 Mar 2016 17:23:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0F5013A50159; Tue, 22 Mar 2016 17:23:37 +0100 (CET) Date: Tue, 22 Mar 2016 17:23:37 +0100 From: Juergen Schoenwaelder To: Eliot Lear Message-ID: <20160322162336.GB65254@elstar.local> Mail-Followup-To: Eliot Lear , Benoit Claise , Ladislav Lhotka , "netmod-chairs@ietf.org" , Kent Watsen , "netmod@ietf.org" , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell References: <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> <56F02B21.3080103@cisco.com> <20160322081043.GA64402@elstar.local> <7DA81401-6AE5-4DCA-A8C7-3B41ED5B2C06@nic.cz> <56F15DBC.5050905@cisco.com> <20160322154223.GA65166@elstar.local> <56F16EE8.70703@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F16EE8.70703@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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: Tue, 22 Mar 2016 16:24:28 -0000 On Tue, Mar 22, 2016 at 05:12:24PM +0100, Eliot Lear wrote: > Hi Juergen, > > On 3/22/16 4:42 PM, Juergen Schoenwaelder wrote: > > I think such considerations belongs into documents making use of > > object signatures and close to 100% of the YANG models today don't > > so I do not even think this qualifies for RFC6087bis. > > > > I think there are AT LEAST two areas where signatures are going to be > necessary: > > * There exist multi-level authorization schemes today that rely on > signatures. Those have to be transported. > * Manufacturer usage descriptions (MUDs) have extremely broad scope in > terms of the number of devices that are intended to use the same > description (think thousands to millions). And so an unauthorized > change could have a similarly broad impact. > > > Thus, wherever the YANG experts think signatures should happen in each > encoding case is fine with me; but I'd suggest that I'm not the only > person who's going to want to know. Is it THAT hard to at least add a > reference? Because if it is, that would cause me to wonder if the > mechanisms are really in place to do the right thing. > Eliot, I simply fail to understand what the problem is and I fail to see which addition (ideally in concrete words) is proposed to fix the problem. /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 22 14:06:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792B912DA09 for ; Tue, 22 Mar 2016 14:06: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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 QQi-pTRf_Q81 for ; Tue, 22 Mar 2016 14:06:27 -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 C5B0412D9C0 for ; Tue, 22 Mar 2016 14:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3900; q=dns/txt; s=iport; t=1458680786; x=1459890386; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=XH6omRviZPDv1UZciRlryBAjMZw9RVTStEZmfkQ3cVc=; b=JcS68eIYSmkCQwv9PcbjTApzQf/XAEwLL6v/VhH4bSxFuqYmY/rdtzdu wBpJWhja82Bqu5yv1y1FMHcDEkczFbd5OZi35H9DaeNvz4XEmQHR5YCsB g7vvblYNamTbxvEKXa58SdoBEUc6SDrGfF/AdDR7zP/J2YNKP/f04WpYe w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAgBJs/FW/5pdJa1egzNTega6QwENg?= =?us-ascii?q?XAhhWwCHIEzOBQBAQEBAQEBZBwLhEEBAQEEIxFDAgwGARkEAQEDAiMDAgQwFAE?= =?us-ascii?q?ICQEEDgUIE4gMDq9kkHIBAQEBAQEBAQEBAQEBAQEBAQEBAQEVfIlmhCSDGIJWB?= =?us-ascii?q?Y07ihwBhXCIDIFsTYN/iFYCjwYBHgEBQoNlagGJB34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,379,1454976000"; d="scan'208";a="251772855" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2016 21:06:25 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u2ML6PGj005107 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 22 Mar 2016 21:06:25 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 22 Mar 2016 17:06:24 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 22 Mar 2016 17:06:24 -0400 From: "Alexander Clemm (alex)" To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-clemm-netmod-mount-04.txt Thread-Index: AdGEflNmdBbvDaljQkC/3mtsca64Bw== Date: Tue, 22 Mar 2016 21:06:24 +0000 Message-ID: <41a2946476ea4f54978a3abbf173ec47@XCH-RTP-001.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.154.163.59] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [netmod] FYI: New Version Notification for draft-clemm-netmod-mount-04.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: Tue, 22 Mar 2016 21:06:28 -0000 SGksDQoNCndlIGhhdmUgcG9zdGVkIGEgbmV3IHJldmlzaW9uIG9mIHRoZSBZQU5HLU1vdW50IGRy YWZ0LiAgDQoNClRoaXMgcGFydGljdWxhciBkcmFmdCBjb25jZXJucyB0aGUgZmxhdm9yIG9mIFlB TkctTW91bnQgdGhhdCBhbGxvd3MgdG8gbW91bnQgaW5zdGFuY2VzIG9mIFlBTkcgZGF0YSwgZWl0 aGVyIGxvY2FsIChBbGlhcy1Nb3VudCkgb3IgcmVtb3RlIChQZWVyLU1vdW50KS4gIFRoaXMgaXMg Y29tcGxlbWVudGFyeSB0byBTdHJ1Y3R1cmFsIC8gU2NoZW1hLU1vdW50LCB3aGljaCBhbGxvd3Mg dG8gbW91bnQgWUFORyBkZWZpbml0aW9ucyAoYXMgb3Bwb3NlZCB0byBkYXRhIGluc3RhbmNlcyks IGFkZHJlc3NpbmcgYSByZWxhdGVkIGJ1dCBzbGlnaHRseSBkaWZmZXJlbnQgcHJvYmxlbS4gIFRo ZSBzb2x1dGlvbiBhcHByb2FjaCAtIHdpdGggWUFORyBleHRlbnNpb25zIGFuZCBtb3VudHBvaW50 IG1hbmFnZW1lbnQgLSBzaG91bGQgYmUgY29tcGxlbWVudGFyeSBhcyB3ZWxsIGFuZCBhbGxvd3Mg dGhlbSB0byBidWlsZCBvbiBvbmUgYW5vdGhlci4gIA0KDQpLaW5kIHJlZ2FyZHMNCi0tLSBBbGV4 IChvbiBiZWhhbGYgb2YgdGhlIGNvYXV0aG9ycykNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIE1hcmNoIDIxLCAyMDE2IDQ6MzEgUE0NClRvOiBB bGV4YW5kZXIgQ2xlbW0gKGFsZXgpIDxhbGV4QGNpc2NvLmNvbT47IEVyaWMgVm9pdCAoZXZvaXQp IDxldm9pdEBjaXNjby5jb20+OyBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpIDxhbGV4QGNpc2NvLmNv bT47IEphbiBNZWR2ZWQgKGptZWR2ZWQpIDxqbWVkdmVkQGNpc2NvLmNvbT4NClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2xlbW0tbmV0bW9kLW1vdW50LTA0LnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1jbGVtbS1uZXRtb2QtbW91bnQtMDQu dHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWxleGFuZGVyIENsZW1tIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWNsZW1tLW5l dG1vZC1tb3VudA0KUmV2aXNpb246CTA0DQpUaXRsZToJCU1vdW50aW5nIFlBTkctRGVmaW5lZCBJ bmZvcm1hdGlvbiBmcm9tIFJlbW90ZSBEYXRhc3RvcmVzDQpEb2N1bWVudCBkYXRlOgkyMDE2LTAz LTIxDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkzNg0KVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jbGVtbS1u ZXRtb2QtbW91bnQtMDQudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtY2xlbW0tbmV0bW9kLW1vdW50Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jbGVtbS1uZXRtb2QtbW91bnQtMDQNCkRp ZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtY2xl bW0tbmV0bW9kLW1vdW50LTA0DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1 Y2VzIGNhcGFiaWxpdGllcyB0aGF0IGFsbG93IFlBTkcgZGF0YXN0b3JlcyB0bw0KICAgcmVmZXJl bmNlIGFuZCBpbmNvcnBvcmF0ZSBpbmZvcm1hdGlvbiBmcm9tIHJlbW90ZSBkYXRhc3RvcmVzLiAg VGhpcw0KICAgaXMgYWNjb21wbGlzaGVkIGJ5IGV4dGVuZGluZyBZQU5HIHdpdGggdGhlIGFiaWxp dHkgdG8gZGVmaW5lIG1vdW50DQogICBwb2ludHMgdGhhdCByZWZlcmVuY2UgZGF0YSBub2RlcyBp biBhbm90aGVyIFlBTkcgc3VidHJlZSwgYnkNCiAgIHN1YnNlcXVlbnRseSBhbGxvd2luZyB0aG9z ZSBkYXRhIG5vZGVzIHRvIGJlIGFjY2Vzc2VkIGJ5IGNsaWVudA0KICAgYXBwbGljYXRpb25zIGFz IGlmIHBhcnQgb2YgYW4gYWx0ZXJuYXRpdmUgZGF0YSBoaWVyYXJjaHksIGFuZCBieQ0KICAgcHJv dmlkaW5nIHRoZSBuZWNlc3NhcnkgbWVhbnMgdG8gbWFuYWdlIGFuZCBhZG1pbmlzdGVyIHRob3Nl IG1vdW50DQogICBwb2ludHMuICBUd28gZmxhdm9ycyBhcmUgZGVmaW5lZDogQWxpYXMtTW91bnQg YWxsb3dzIHRvIG1vdW50IGxvY2FsDQogICBzdWJ0cmVlcywgd2hpbGUgUGVlci1Nb3VudCBhbGxv d3Mgc3VidHJlZXMgdG8gcmVzaWRlIG9uIGFuZCBiZQ0KICAgYXV0aG9yaXRhdGl2ZWx5IG93bmVk IGJ5IGEgcmVtb3RlIHNlcnZlci4gIFlBTkctTW91bnQgZmFjaWxpdGF0ZXMgdGhlDQogICBkZXZl bG9wbWVudCBvZiBhcHBsaWNhdGlvbnMgdGhhdCBuZWVkIHRvIGFjY2VzcyBkYXRhIHRoYXQgdHJh bnNjZW5kcw0KICAgaW5kaXZpZHVhbCBuZXR3b3JrIGRldmljZXMgd2hpbGUgaW1wcm92aW5nIG5l dHdvcmstd2lkZSBvYmplY3QNCiAgIGNvbnNpc3RlbmN5LCBvciB0aGF0IHJlcXVpcmUgYW4gYWxp YXNpbmcgY2FwYWJpbGl0eSB0byBiZSBhYmxlIHRvDQogICBjcmVhdGUgb3ZlcmxheSBzdHJ1Y3R1 cmVzIGZvciBZQU5HIGRhdGEuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Mar 22 14:12:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC45512DA15; Tue, 22 Mar 2016 14:12:05 -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_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 XBolpaWtqjj6; Tue, 22 Mar 2016 14:12:04 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA9D12DA1A; Tue, 22 Mar 2016 14:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1738; q=dns/txt; s=iport; t=1458681124; x=1459890724; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Xzi/v0Ua5abssxJCLoEtVEDDXK9wJOqRV0NkU1oxkgs=; b=N3Pbymd+4LLmPFzcvBIR/tonwxyfguk84ZGat45d3jcoiar9qdwxQIod jawTRYIps7DlYyGSFmoqtah7s4rmZBwDFpcW70/ezWv/7epiyT7mphgMW JH97Z1qW/zjdCKcvfpDOZ66AklFRAa7W9Kjn4Ujk5tBelbn0ef4Gad7nK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAgAHtPFW/51dJa1YBoMzU3oGukMBD?= =?us-ascii?q?YFwFwqFIkoCgU84FAEBAQEBAQFkJ4RBAQEBBAEBATc0CwwEAgEIDgMEAQEfBQQ?= =?us-ascii?q?HJwsUCQgCBAENBQgTiAwOwFoBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIpihAwRA?= =?us-ascii?q?Q6FZgWNO4ocAY18gWyETIhYjwYBHgEBQoIwgTVqiFQ0fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,379,1454976000"; d="scan'208";a="83490113" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2016 21:12:03 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u2MLC3Uv004851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Mar 2016 21:12:03 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 22 Mar 2016 17:12:02 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 22 Mar 2016 17:12:02 -0400 From: "Alexander Clemm (alex)" To: Lou Berger , netmod WG Thread-Topic: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount Thread-Index: AQHRg41ZtV6UxB9BT0m4EaKwTt9fX59l9uPw Date: Tue, 22 Mar 2016 21:12:02 +0000 Message-ID: <1f9fbc96cb024a658449419b1189725c@XCH-RTP-001.cisco.com> References: <56F01EB7.5000804@labn.net> In-Reply-To: <56F01EB7.5000804@labn.net> 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.154.163.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: netmod chairs Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount 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, 22 Mar 2016 21:12:06 -0000 Support I would like to see this go in a direction where this can merge and be clea= rly complementary with Alias-Mount and Peer-Mount. =20 Thanks --- Alex -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger Sent: Monday, March 21, 2016 9:18 AM To: netmod WG Cc: netmod chairs Subject: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-= 02 as draft-ietf-netmod-schema-mount All, This is start of a two week poll on making draft-bjorklund-netmod-structural-mount-02 a working group document with th= e name draft-ietf-netmod-schema-mount. This adoption is a little bit unusual in that, per our last interim, we kno= w that this document is likely to see significant changes in technical (sol= ution) details as it progresses through normal WG process. And the -01 version is expected to be done in combination with Lada/draft-= lhotka-netmod-ysdl. Please send email to the list indicating "yes/support" or "no/do not suppor= t". Note that Yes indicates your support for working on a schema mount sol= ution, rather than the specific solution. If you have specific technical p= roposals/suggestions that you'd like to voice please feel free to also do s= o - but please use a new/different thread so we can keep the process and te= chnical discussions separate. The poll ends April 4, 2016 (after our in-person meeting, but authors / main contributors are not expec= ted to be present in BA. So please discuss on list.) Thank you, NETMOD Chairs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 22 20:57:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956EC12D8CA for ; Tue, 22 Mar 2016 20:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.291 X-Spam-Level: X-Spam-Status: No, score=-0.291 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, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=2.399] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=randy_presuhn@mindspring.com header.d=mindspring.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 K-Wbl2Ewlf96 for ; Tue, 22 Mar 2016 20:57:23 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 6772912D8AF for ; Tue, 22 Mar 2016 20:57:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YOoe/D0QZ6olPz3JGW0VT9+C0aShCPp56xZa8fkZu2hAKHP6EITOJVq8l05eByJP; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.47] (helo=elwamui-rubis.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aiZuy-000249-P9 for netmod@ietf.org; Tue, 22 Mar 2016 22:57:12 -0500 Received: from 76.254.50.119 by webmail.earthlink.net with HTTP; Tue, 22 Mar 2016 23:57:12 -0400 Message-ID: <33092781.1458705432558.JavaMail.wam@elwamui-rubis.atl.sa.earthlink.net> Date: Tue, 22 Mar 2016 20:57:12 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddcd934ed29ba77998a21a7fee972289924350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.47 Archived-At: Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 03:57:24 -0000 Hi - >From: Juergen Schoenwaelder >Sent: Mar 22, 2016 9:23 AM >To: Eliot Lear >Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell >Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) > >On Tue, Mar 22, 2016 at 05:12:24PM +0100, Eliot Lear wrote: >> Hi Juergen, >> >> On 3/22/16 4:42 PM, Juergen Schoenwaelder wrote: >> > I think such considerations belongs into documents making use of >> > object signatures and close to 100% of the YANG models today don't >> > so I do not even think this qualifies for RFC6087bis. >> > >> >> I think there are AT LEAST two areas where signatures are going to be >> necessary: >> >> * There exist multi-level authorization schemes today that rely on >> signatures. Those have to be transported. >> * Manufacturer usage descriptions (MUDs) have extremely broad scope in >> terms of the number of devices that are intended to use the same >> description (think thousands to millions). And so an unauthorized >> change could have a similarly broad impact. >> >> >> Thus, wherever the YANG experts think signatures should happen in each >> encoding case is fine with me; but I'd suggest that I'm not the only >> person who's going to want to know. Is it THAT hard to at least add a >> reference? Because if it is, that would cause me to wonder if the >> mechanisms are really in place to do the right thing. >> > >Eliot, > >I simply fail to understand what the problem is and I fail to see >which addition (ideally in concrete words) is proposed to fix the >problem. The problem is that the current approach does not address representing blobs of configuration data as (signed) documents independent of the protocol used for shoveling those blobs around. Randy From nobody Wed Mar 23 08:26:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56D412D579 for ; Wed, 23 Mar 2016 08:26:24 -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 ubA7pHPu0yDP for ; Wed, 23 Mar 2016 08:26:22 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6650712D1EB for ; Wed, 23 Mar 2016 08:26:22 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C454D1CC006C; Wed, 23 Mar 2016 16:26:30 +0100 (CET) From: Ladislav Lhotka To: Anton =?utf-8?B?VGvDocSNaWs=?= , "netmod\@ietf.org" In-Reply-To: <1458566013189.55874@pantheon.tech> References: <1458566013189.55874@pantheon.tech> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 23 Mar 2016 16:26:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount: Namespace issues 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, 23 Mar 2016 15:26:24 -0000 Hi Anton, Anton Tk=C3=A1=C4=8Dik writes: > Hi, > > if I understand correctly netmod-structural-mount inlines "mounted" data = directly to container / list which is used, > > which brings up following issues: > > > 1. It is possible to have identifier conflict between data from model > defining mount and mounted data (if mounted schema I think we need to eliminate all kinds of recursive mount, so this should not happen.=20 > > contains same model). > > e.g. > > module mount-under-mount { > > container mounts { > > list mount { > > key name; > > leaf name; > > container mounts { > > // List of discovered remote mounts > > } > > mnt:mount-point data; > > } > > }? > > } > > > 2. Expanding data directly under container / list may be problematic > for clients which do not support netmod-structural-mount. I don't think it can work if the client doesn't support the mount mechanism. > > > I believe both can be solved elegantly by requiring mount-point > extension to be used inside anydata element, which signifies This has been already discussed in the mailing list. IMO, the biggest problem of anydata (as it is currently defined, at least) is that it permits really anything, i.e. not only stuff contributed by the mounted modules. Lada > > to client that this may be any YANG modeled data (and client can omit pro= cessing it) and also provides isolation between > > data from module defining mount point and mounted data. > > > E.g: > > list mount { > > key name; > > leaf name {...} > > // additional data > > anydata data { > > mnt:mount-point data { > > mnt:mount-yang-library;? > > } > > } > > } > AntonTk=C3=A1=C4=8Dik > Chief Software Architect > > Mlynsk=C3=A9 Nivy 56 / 821 05 Bratislava / Slovakia > +421 911 309 249 / anton.tkacik@pantheon.tech > reception: +421 2 206 65 111 / www.pantheon.sk > [logo] > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 23 09:03:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFC512DAFA for ; Tue, 22 Mar 2016 09:51:38 -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=unavailable 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 h_CSsI97hTpN for ; Tue, 22 Mar 2016 09:51:36 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C48012DC25 for ; Tue, 22 Mar 2016 09:50:02 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id e196so39924842lfg.1 for ; Tue, 22 Mar 2016 09:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=I6zgiupFKidPlDOg4uO3ug2MUVbc6nHV/mPh2gzZCek=; b=PSg1SWlPhiP6kwIm9JqS2SF9j8qmBOmiuhmOFE314C01cB5lv3RQdk2+4bBPhEdx+S F6rVdAAXewkPCzC9i+37f8gGVD2bPqcJSmDuMDj/VXhO4jrSLDwUcX/0CMvf9E1F+Fy0 lZw4mmPvfVeMvHpP2y1HaXu2eUHcUbIVqSAbtPBoH2eX6PnJaNn1OHS5ak/pxPulflf1 qlVXqHhzmzvPT8zAnnRCara73yoiOJ0s03NvHlgaEWBgCYk49Le1tAllSfrFQ0lOMsWI /nuEc9+f1DOb91wCqd71BjiP/NfOifwHl6fBANTBR/kGyZFmKP1zs7QCTHlU/Bu0PCmq 9eQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=I6zgiupFKidPlDOg4uO3ug2MUVbc6nHV/mPh2gzZCek=; b=Bxu23XR+9RqHXyPDoUCMYN67UQxtujeOyAk3wknfSAHsY0PgJ3mxUhbc5Mtgw7fKFA Ls8NMAZJDxbHcJ+kHguadYmRlv8qQN63HDByyxgAIwunUXM95RKLSJSQ3+hjsByBFSJY j6pf9mVc1GxSHaMs8C42xzEgeP2J76O9kuMs0zqmfmIvCpmE/gzh5SH1J/vkwshUI30C j3QjzIAMu4vLeEKgPpXDV8tWX06nfc2UvBLr1LoY+HxHfr5LdeMAIaOt3GlSGeOCwTFi 3RJVZhlYoVjWJ336h1W+JHibSLNPIzm2C/arBzRvK2kQwUwSpkKFxE2p/GmArKzG9OJJ /Klw== X-Gm-Message-State: AD7BkJIc1+yUP2T8bgWR2Dlq5+E142AdbjF7EKw4DtqRI2u7sDV5KGs+kBQKSa6p6soEuflHJ4XFp9A9naoDfg== MIME-Version: 1.0 X-Received: by 10.25.85.145 with SMTP id j139mr13655603lfb.131.1458665400385; Tue, 22 Mar 2016 09:50:00 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Tue, 22 Mar 2016 09:50:00 -0700 (PDT) In-Reply-To: <20160322162336.GB65254@elstar.local> References: <20160321151914.GA62880@elstar.local> <56F0137B.3090103@cisco.com> <72154E94-3C00-438B-B177-35DB9216DF03@juniper.net> <56F02B21.3080103@cisco.com> <20160322081043.GA64402@elstar.local> <7DA81401-6AE5-4DCA-A8C7-3B41ED5B2C06@nic.cz> <56F15DBC.5050905@cisco.com> <20160322154223.GA65166@elstar.local> <56F16EE8.70703@cisco.com> <20160322162336.GB65254@elstar.local> Date: Tue, 22 Mar 2016 09:50:00 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Eliot Lear , Benoit Claise , Ladislav Lhotka , "netmod-chairs@ietf.org" , Kent Watsen , "netmod@ietf.org" , "draft-ietf-netmod-yang-json@ietf.org" , The IESG , Stephen Farrell Content-Type: multipart/alternative; boundary=001a114059360966bb052ea601d6 Archived-At: X-Mailman-Approved-At: Wed, 23 Mar 2016 09:03:28 -0700 Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 22 Mar 2016 16:51:38 -0000 --001a114059360966bb052ea601d6 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 22, 2016 at 9:23 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Mar 22, 2016 at 05:12:24PM +0100, Eliot Lear wrote: > > Hi Juergen, > > > > On 3/22/16 4:42 PM, Juergen Schoenwaelder wrote: > > > I think such considerations belongs into documents making use of > > > object signatures and close to 100% of the YANG models today don't > > > so I do not even think this qualifies for RFC6087bis. > > > > > > > I think there are AT LEAST two areas where signatures are going to be > > necessary: > > > > * There exist multi-level authorization schemes today that rely on > > signatures. Those have to be transported. > > * Manufacturer usage descriptions (MUDs) have extremely broad scope in > > terms of the number of devices that are intended to use the same > > description (think thousands to millions). And so an unauthorized > > change could have a similarly broad impact. > > > > > > Thus, wherever the YANG experts think signatures should happen in each > > encoding case is fine with me; but I'd suggest that I'm not the only > > person who's going to want to know. Is it THAT hard to at least add a > > reference? Because if it is, that would cause me to wonder if the > > mechanisms are really in place to do the right thing. > > > > Eliot, > > I simply fail to understand what the problem is and I fail to see > which addition (ideally in concrete words) is proposed to fix the > problem. > > This seems like a protocol issue, not a data modeling issue. NETCONF and RESTCONF both have very strict security requirements to protect the instance documents which are intended to conform to YANG schema. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114059360966bb052ea601d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 22, 2016 at 9:23 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Mar 22, 2016 at 05:12:24PM +0100, Eliot Lear= wrote:
> Hi Juergen,
>
> On 3/22/16 4:42 PM, Juergen Schoenwaelder wrote:
> > I think such considerations belongs into documents making use of<= br> > > object signatures and close to 100% of the YANG models today don&= #39;t
> > so I do not even think this qualifies for RFC6087bis.
> >
>
> I think there are AT LEAST two areas where signatures are going to be<= br> > necessary:
>
>=C2=A0 =C2=A0* There exist multi-level authorization schemes today that= rely on
>=C2=A0 =C2=A0 =C2=A0signatures.=C2=A0 Those have to be transported.
>=C2=A0 =C2=A0* Manufacturer usage descriptions (MUDs) have extremely br= oad scope in
>=C2=A0 =C2=A0 =C2=A0terms of the number of devices that are intended to= use the same
>=C2=A0 =C2=A0 =C2=A0description (think thousands to millions).=C2=A0 An= d so an unauthorized
>=C2=A0 =C2=A0 =C2=A0change could have a similarly broad impact.
>
>
> Thus, wherever the YANG experts think signatures should happen in each=
> encoding case is fine with me; but I'd suggest that I'm not th= e only
> person who's going to want to know.=C2=A0 Is it THAT hard to at le= ast add a
> reference?=C2=A0 Because if it is, that would cause me to wonder if th= e
> mechanisms are really in place to do the right thing.
>

Eliot,

I simply fail to understand what the problem is and I fail to see
which addition (ideally in concrete words) is proposed to fix the
problem.



This seems like a protocol issue, not= a data modeling issue.
NETCONF and RESTCONF both have very stric= t security requirements
to protect the instance documents which a= re intended to conform to YANG schema.

=C2=A0
/js


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

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

--001a114059360966bb052ea601d6-- From nobody Wed Mar 23 09:54:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4235512D785; Wed, 23 Mar 2016 09:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thZ7CHgo5f2J; Wed, 23 Mar 2016 09:54:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773E112D790; Wed, 23 Mar 2016 09:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1330; q=dns/txt; s=iport; t=1458752075; x=1459961675; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vR859EavJTSdRk3QoDFrYEhz6c5Zgv+hfbsMcw0JGto=; b=mYYdvFX1GIBh0Q28SjVr3BYCleWTkBy+mSVLAlqpi4VBYRG6gfj6iJy0 YfLXzXbIw0AnhMKZhe5Vf1WS/d20TT4XvHUuOMvesA8ppfQAwSHaH0YDd eI0yoZs0hAivXwlyD3sL7frG5/Zli/dbet71hpwhfpUXyCRHl0zw9fDzi Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgANyfJW/4ENJK1YBoMzU3oGumEBD?= =?us-ascii?q?YFwFwqFIkoCgT04FAEBAQEBAQFkJ4RBAQEBAwEBAQE3NAsFCwIBCA4oBQsnCyU?= =?us-ascii?q?CBAENBQgTiAQIDsElAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGHoREhAwRAQ6FZ?= =?us-ascii?q?gWNO4ofAY18gW2ETIhYjwYBHgEBQoIwgTVqiFk0fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,383,1454976000"; d="scan'208";a="89672482" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Mar 2016 16:54:34 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u2NGsYCK031075 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Mar 2016 16:54:34 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Mar 2016 12:54:33 -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.1104.009; Wed, 23 Mar 2016 12:54:33 -0400 From: "Eric Voit (evoit)" To: Lou Berger , netmod WG Thread-Topic: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount Thread-Index: AQHRg41ZSfoUwIVhsE2Fi67wQyLYv59nQayw Date: Wed, 23 Mar 2016 16:54:33 +0000 Message-ID: <22cc259fbd2a48afb98b4fd30f9649aa@XCH-RTP-013.cisco.com> References: <56F01EB7.5000804@labn.net> In-Reply-To: <56F01EB7.5000804@labn.net> 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.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: netmod chairs Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount 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, 23 Mar 2016 16:54:38 -0000 support > All, >=20 > This is start of a two week poll on making > draft-bjorklund-netmod-structural-mount-02 a working group document with > the name draft-ietf-netmod-schema-mount. >=20 > This adoption is a little bit unusual in that, per our last interim, we k= now that this > document is likely to see significant changes in technical (solution) det= ails as it > progresses through normal WG process. > And the -01 version is expected to be done in combination with Lada/draf= t- > lhotka-netmod-ysdl. >=20 > Please send email to the list indicating "yes/support" or "no/do not supp= ort". > Note that Yes indicates your support for working on a schema mount soluti= on, > rather than the specific solution. If you have specific technical > proposals/suggestions that you'd like to voice please feel free to also d= o so - but > please use a new/different thread so we can keep the process and technica= l > discussions separate. >=20 > The poll ends April 4, 2016 > (after our in-person meeting, but authors / main contributors are not exp= ected > to be present in BA. So please discuss on list.) >=20 > Thank you, >=20 > NETMOD Chairs >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 23 14:01:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC0412D566 for ; Wed, 23 Mar 2016 14:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opsLynAIUIvZ for ; Wed, 23 Mar 2016 14:01:21 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5668012D91B for ; Wed, 23 Mar 2016 14:01:17 -0700 (PDT) Received: from localhost (h-53-58.a165.priv.bahnhof.se [46.59.53.58]) by mail.tail-f.com (Postfix) with ESMTPSA id 973391AE0385; Wed, 23 Mar 2016 22:01:16 +0100 (CET) Date: Wed, 23 Mar 2016 22:01:16 +0100 (CET) Message-Id: <20160323.220116.2259282208531577772.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <1458566013189.55874@pantheon.tech> 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] draft-bjorklund-netmod-structural-mount: Namespace issues 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, 23 Mar 2016 21:01:23 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gSGkgQW50b24sDQo+IA0K PiBBbnRvbiBUa8OhxI1payA8YW50b24udGthY2lrQHBhbnRoZW9uLnRlY2g+IHdyaXRlczoNCj4g DQo+ID4gSGksDQo+ID4NCj4gPiBpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5IG5ldG1vZC1zdHJ1 Y3R1cmFsLW1vdW50IGlubGluZXMgIm1vdW50ZWQiIGRhdGEgZGlyZWN0bHkgdG8gY29udGFpbmVy IC8gbGlzdCB3aGljaCBpcyB1c2VkLA0KPiA+DQo+ID4gd2hpY2ggYnJpbmdzIHVwIGZvbGxvd2lu ZyBpc3N1ZXM6DQo+ID4NCj4gPg0KPiA+IDEuIEl0IGlzIHBvc3NpYmxlIHRvIGhhdmUgaWRlbnRp ZmllciBjb25mbGljdCBiZXR3ZWVuIGRhdGEgZnJvbSBtb2RlbA0KPiA+IGRlZmluaW5nIG1vdW50 IGFuZCBtb3VudGVkIGRhdGEgKGlmIG1vdW50ZWQgc2NoZW1hDQo+IA0KPiBJIHRoaW5rIHdlIG5l ZWQgdG8gZWxpbWluYXRlIGFsbCBraW5kcyBvZiByZWN1cnNpdmUgbW91bnQsIHNvIHRoaXMNCj4g c2hvdWxkIG5vdCBoYXBwZW4uIA0KPiANCj4gPg0KPiA+IGNvbnRhaW5zIHNhbWUgbW9kZWwpLg0K PiA+DQo+ID4gZS5nLg0KPiA+DQo+ID4gICAgICAgbW9kdWxlIG1vdW50LXVuZGVyLW1vdW50IHsN Cj4gPg0KPiA+ICAgICAgICAgICAgICBjb250YWluZXIgbW91bnRzIHsNCj4gPg0KPiA+ICAgICAg ICAgICAgICAgICAgICBsaXN0IG1vdW50IHsNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAg ICAga2V5IG5hbWU7DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgIGxlYWYgbmFtZTsN Cj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRhaW5lciBtb3VudHMg ew0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLy8gTGlzdCBv ZiBkaXNjb3ZlcmVkIHJlbW90ZSBtb3VudHMNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIH0NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1udDpt b3VudC1wb2ludCBkYXRhOw0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgIH0NCj4gPg0KPiA+ ICAgICAgICAgICAgICB9Pw0KPiA+DQo+ID4gICAgICAgfQ0KPiA+DQo+ID4NCj4gPiAyLiBFeHBh bmRpbmcgZGF0YSBkaXJlY3RseSB1bmRlciBjb250YWluZXIgLyBsaXN0IG1heSBiZSBwcm9ibGVt YXRpYw0KPiA+IGZvciBjbGllbnRzIHdoaWNoIGRvIG5vdCBzdXBwb3J0IG5ldG1vZC1zdHJ1Y3R1 cmFsLW1vdW50Lg0KPiANCj4gSSBkb24ndCB0aGluayBpdCBjYW4gd29yayBpZiB0aGUgY2xpZW50 IGRvZXNuJ3Qgc3VwcG9ydCB0aGUgbW91bnQgbWVjaGFuaXNtLg0KPiANCj4gPg0KPiA+DQo+ID4g SSBiZWxpZXZlIGJvdGggY2FuIGJlIHNvbHZlZCBlbGVnYW50bHkgYnkgcmVxdWlyaW5nIG1vdW50 LXBvaW50DQo+ID4gZXh0ZW5zaW9uIHRvIGJlIHVzZWQgaW5zaWRlIGFueWRhdGEgZWxlbWVudCwg d2hpY2ggc2lnbmlmaWVzDQo+IA0KPiBUaGlzIGhhcyBiZWVuIGFscmVhZHkgZGlzY3Vzc2VkIGlu IHRoZSBtYWlsaW5nIGxpc3QuIElNTywgdGhlIGJpZ2dlc3QNCj4gcHJvYmxlbSBvZiBhbnlkYXRh IChhcyBpdCBpcyBjdXJyZW50bHkgZGVmaW5lZCwgYXQgbGVhc3QpIGlzIHRoYXQgaXQNCj4gcGVy bWl0cyByZWFsbHkgYW55dGhpbmcsIGkuZS4gbm90IG9ubHkgc3R1ZmYgY29udHJpYnV0ZWQgYnkg dGhlIG1vdW50ZWQNCj4gbW9kdWxlcy4NCg0KVGhlIGZhY3QgdGhhdCBhbnlkYXRhIGNhbiByZXBy ZXNlbnQgInJlYWxseSBhbnl0aGluZyIgZG9lcyBub3QgbWVhbg0KdGhhdCBldmVyeSBzZXJ2ZXIg TVVTVCBhbGxvdyB0aGUgY2xpZW50IHRvIGNyZWF0ZSAicmVhbGx5IGFueXRoaW5nIg0KZm9yIGFs bCBhbnlkYXRhIGNvbmZpZyBub2Rlcy4gIEl0IHdpbGwgZGVwZW5kIG9uIHRoZSBzZW1hbnRpY3Mg b2YgZWFjaA0KcGFydGljdWxhciBhbnlkYXRhIG5vZGUuDQoNCkkgdGhpbmsgdGhhdCB1c2luZyBt b3VudC1wb2ludCBhcyBhIHN1YnN0YXRlbWVudCB0byBhbnlkYXRhIGlzIGluIGZhY3QNCnRoZSBv bmx5IHJlYWxseSBzYWZlIG9wdGlvbiB0byBtb3VudC4gIEJvdGggdGhlIHByb3Bvc2VkIHNvbHV0 aW9ucyBpbg0KdGhlIGN1cnJlbnQgc3RydWN0dXJhbCBtb3VudCBhbmQgeXNkbCBkcmFmdHMgYXJl IHVuc2FmZSBmb3IgY2xpZW50cw0KdGhhdCBkb24ndCB1bmRlcnN0YW5kIHRoZSBtb3VudC4NCg0K DQovbWFydGluDQo= From nobody Thu Mar 24 04:42:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CD712DA80 for ; Thu, 24 Mar 2016 04:42:43 -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 kselvceDx_40 for ; Thu, 24 Mar 2016 04:42:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0773.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:773]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324C512D824 for ; Thu, 24 Mar 2016 04:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NVVWAqM6AQ03LFFb3xOMG78iJX9aeleYucsV0+QSzK8=; b=IAoKxc3phQkymhbGAgVBlsAZ+MbbNncs56OXA5VUKtI4r8sqVmBO1SV0l8VYMUXkq1xPtE3V154oU1XLs6VslwU/Whwq4A9o+gNdA2b3pHg7tGZlFw9CfD1w9AyK++IiSX7RYjzA2JpSvHOwr3vepZX+ctGJ4QhLnWWokMvekS0= Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1456.namprd05.prod.outlook.com (10.161.224.153) with Microsoft SMTP Server (TLS) id 15.1.443.12; Thu, 24 Mar 2016 11:42:19 +0000 Received: from DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) by DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) with mapi id 15.01.0443.015; Thu, 24 Mar 2016 11:42:19 +0000 From: Kent Watsen To: Randy Presuhn Thread-Topic: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) Thread-Index: AQHRhLgUmK6nCarkZEauCAC72O2xP59oewEx Date: Thu, 24 Mar 2016 11:42:19 +0000 Message-ID: <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> References: <33092781.1458705432558.JavaMail.wam@elwamui-rubis.atl.sa.earthlink.net> In-Reply-To: <33092781.1458705432558.JavaMail.wam@elwamui-rubis.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mindspring.com; dkim=none (message not signed) header.d=none; mindspring.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [199.76.14.70] x-ms-office365-filtering-correlation-id: b226a0e1-1d3b-4d3e-acb3-08d353d95b4d x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1456; 5:qyRgVJokdfwBnH/DiEa1Sifw9Vjj7v0nSq9kVwyEZHT07bGZ+KkwC8X5ziSjxHgh34OHXAhI7Ef4b0F9Za/Pk3Vunnq0V/ai6w9dHun2Bif/TJyJ5E3bIpaetCSnk6Tg/xidbYmVTa2Uzb1g2RKoBA==; 24:ozaZbiOYe/M3bviE/iqqf0Ca328UOHJISLARvMEcfElwvvztir4FWe5YgJTPYKn9XaeIoGLTFrBoRFTEB7QEqIzav9/pUigA0tINzoMnNFI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DM2PR0501MB1456; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1456; x-forefront-prvs: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(106116001)(6116002)(586003)(82746002)(3846002)(10400500002)(36756003)(102836003)(86362001)(77096005)(99286002)(87936001)(5008740100001)(5002640100001)(2900100001)(2950100001)(230783001)(33656002)(189998001)(66066001)(1096002)(110136002)(92566002)(1220700001)(81166005)(3280700002)(54356999)(5004730100002)(4326007)(2906002)(50986999)(122556002)(76176999)(11100500001)(3660700001)(83716003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1456; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 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: 24 Mar 2016 11:42:19.2791 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1456 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 24 Mar 2016 11:42:43 -0000 All, I believe that this thread's issue is resolved if the following text is add= ed to the Security Considerations section: "This document defines a JSON encoding for YANG-defined data. It does not d= efined any mechanisms for signing or encrypting said data. Use of an exter= nal mechanism, such as PKCS #7 [RFC2315] or JOSE [RFC7515 and RFC7516], is = needed for such cases." Elliot, Randy, Stephen? Kent // document shepherd=20 From nobody Thu Mar 24 04:46:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7BE12DAB2 for ; Thu, 24 Mar 2016 04:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaFdI1PpTwtk for ; Thu, 24 Mar 2016 04:46:27 -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 593AB12DAAF for ; Thu, 24 Mar 2016 04:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2083; q=dns/txt; s=iport; t=1458819986; x=1460029586; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=0bqXOavzo9er4cRqJjSrm6dNiuPC6cZIdA8T8B+aJHc=; b=mMJfMnT1kxI3Y5F9vrw9GHTaBtOW244EiWLdG6wA4JrTslCbEpjYq5/q yOWpr7TOXbOQJRzw/RWmyBvvwTw4WUJWHJiQkR2oUWVOfWwUJ/zZBFgoC eOs3zIYqEWkp21UPe0ns/6PLYla7jPXmN6fC35Nan995gkgwJwOiZ+Lrj 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBACH0vNW/xbLJq1evUaEDYYNAoF5A?= =?us-ascii?q?QEBAQEBZSeEQgEBBCNVARALDgoJFgsCAgkDAgECAUUGAQwIAQGII7AZkGQBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBDwiKYoc8glYBBJdegx6BZokAgVCHZ4VUjwliggMZF?= =?us-ascii?q?IE2O4oEAQEB?= X-IronPort-AV: E=Sophos;i="5.24,385,1454976000"; d="asc'?scan'208";a="636506543" 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; 24 Mar 2016 11:46:24 +0000 Received: from [10.61.202.49] ([10.61.202.49]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2OBkNgT032586; Thu, 24 Mar 2016 11:46:23 GMT To: Kent Watsen , Randy Presuhn References: <33092781.1458705432558.JavaMail.wam@elwamui-rubis.atl.sa.earthlink.net> <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> From: Eliot Lear Message-ID: <56F3D38F.2040701@cisco.com> Date: Thu, 24 Mar 2016 12:46:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mNtJHcdPxql4k2Fq7ob2GJQLaCFUbgMnt" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 24 Mar 2016 11:46:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mNtJHcdPxql4k2Fq7ob2GJQLaCFUbgMnt Content-Type: multipart/mixed; boundary="39vPfg2btjV8hUvXm31iorOFWbw8FIlcX" From: Eliot Lear To: Kent Watsen , Randy Presuhn Cc: "netmod@ietf.org" Message-ID: <56F3D38F.2040701@cisco.com> Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) References: <33092781.1458705432558.JavaMail.wam@elwamui-rubis.atl.sa.earthlink.net> <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> In-Reply-To: <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> --39vPfg2btjV8hUvXm31iorOFWbw8FIlcX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/24/16 12:42 PM, Kent Watsen wrote: > All, > > I believe that this thread's issue is resolved if the following text is= added to the Security Considerations section: > > > "This document defines a JSON encoding for YANG-defined data. It does n= ot defined any mechanisms for signing or encrypting said data. Use of an= external mechanism, such as PKCS #7 [RFC2315] or JOSE [RFC7515 and RFC75= 16], is needed for such cases." WFM. Thank you! Eliot --39vPfg2btjV8hUvXm31iorOFWbw8FIlcX-- --mNtJHcdPxql4k2Fq7ob2GJQLaCFUbgMnt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJW89OPAAoJEIe2a0bZ0nozYfkH/Av0v5a8pS33OYBR/w3uYwP3 jxoJQi4dcPOQCz+wr+yMfWQnd4PczsNjNC7WvxTT4UkeHyjWWfPd7KRA+q8/+Jlm Iq3fTXJi6csY1z5l4pq/eanIvjniDWuKmT5VuG43VSHzkmzfya05h5JoQomrzcYD BxzSmxNH/MFUPLFmu+dWs3c27ibEKs0FeLCShyzcXWBYOmgw3n57twM0xLDirDoD upqKWvWVgYYpfOVKqt7iUWnytTmCdZYhiOc6lozpN5lkZfRW6rYrU2lrwGlZGsu5 mOYg1FlgpHru0aGIrrRf4jPTaH4iTE8Sy+yaggJousDwLjGQPaaEpSLzNm5/xgc= =3XnZ -----END PGP SIGNATURE----- --mNtJHcdPxql4k2Fq7ob2GJQLaCFUbgMnt-- From nobody Thu Mar 24 05:06:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0045112DADB for ; Thu, 24 Mar 2016 05:06: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=unavailable 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 DJsNeYo4H1jh for ; Thu, 24 Mar 2016 05:06:09 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 01CEC12DA8E for ; Thu, 24 Mar 2016 04:56:41 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 36B181CC035D; Thu, 24 Mar 2016 12:56:40 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20160323.220116.2259282208531577772.mbj@tail-f.com> References: <1458566013189.55874@pantheon.tech> <20160323.220116.2259282208531577772.mbj@tail-f.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 24 Mar 2016 12:56:40 +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] draft-bjorklund-netmod-structural-mount: Namespace issues 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, 24 Mar 2016 12:06:11 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> Hi Anton, >>=20 >> Anton Tk=C3=A1=C4=8Dik writes: >>=20 >> > Hi, >> > >> > if I understand correctly netmod-structural-mount inlines "mounted" da= ta directly to container / list which is used, >> > >> > which brings up following issues: >> > >> > >> > 1. It is possible to have identifier conflict between data from model >> > defining mount and mounted data (if mounted schema >>=20 >> I think we need to eliminate all kinds of recursive mount, so this >> should not happen.=20 >>=20 >> > >> > contains same model). >> > >> > e.g. >> > >> > module mount-under-mount { >> > >> > container mounts { >> > >> > list mount { >> > >> > key name; >> > >> > leaf name; >> > >> > container mounts { >> > >> > // List of discovered remote mounts >> > >> > } >> > >> > mnt:mount-point data; >> > >> > } >> > >> > }? >> > >> > } >> > >> > >> > 2. Expanding data directly under container / list may be problematic >> > for clients which do not support netmod-structural-mount. >>=20 >> I don't think it can work if the client doesn't support the mount mechan= ism. >>=20 >> > >> > >> > I believe both can be solved elegantly by requiring mount-point >> > extension to be used inside anydata element, which signifies >>=20 >> This has been already discussed in the mailing list. IMO, the biggest >> problem of anydata (as it is currently defined, at least) is that it >> permits really anything, i.e. not only stuff contributed by the mounted >> modules. > > The fact that anydata can represent "really anything" does not mean > that every server MUST allow the client to create "really anything" > for all anydata config nodes. It will depend on the semantics of each > particular anydata node. Schema validation is effectively disabled for anydata nodes. This may be a problem especially for implementations that perform validation as a separate step, perhaps automatically from the data model. And with schema validation out of the way, it is easier to exploit potential bugs in the server. > > I think that using mount-point as a substatement to anydata is in fact > the only really safe option to mount. Both the proposed solutions in Well, if safe means (partial) compatibility of old clients - and I am not even convinced about this. Otherwise it is IMO less safe because the schema is loosened. > the current structural mount and ysdl drafts are unsafe for clients > that don't understand the mount. True. Lada > > > /martin --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 24 05:12:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC6712DABC for ; Thu, 24 Mar 2016 05:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0A9XZnnA7-EA for ; Thu, 24 Mar 2016 05:12:06 -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 5321F12DA75 for ; Thu, 24 Mar 2016 05:12:06 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:45db:ad9a:f9e0:d864] (unknown [IPv6:2001:718:1a02:1:45db:ad9a:f9e0:d864]) by mail.nic.cz (Postfix) with ESMTPSA id 9A829180246; Thu, 24 Mar 2016 13:12:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1458821524; bh=ke5PGNs9AsUOTSLhl+oZBdPepVMDx81jiMOjf3UE/+A=; h=From:Date:To; b=SePUrrl8fCxX7VXc5FMxCGGXubt1P6ZVPg61Yk+WHgy38+qX9nLUbk0VYWSe/XKyL Q3gcX5J/fEnNCuyKqy8JoTA/iIVQ/zmtM4ZI6qyGIJfHJlIjwo0dxuElcMalZbI4q/ B4SjXleU4U1jjfCWwwdcO/wTP3r9+hd++VUL+BZM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> Date: Thu, 24 Mar 2016 13:12:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <33092781.1458705432558.JavaMail.wam@elwamui-rubis.atl.sa.earthlink.net> <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> To: Kent Watsen X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 24 Mar 2016 12:12:08 -0000 > On 24 Mar 2016, at 12:42, Kent Watsen wrote: >=20 >=20 > All, >=20 > I believe that this thread's issue is resolved if the following text = is added to the Security Considerations section: >=20 >=20 > "This document defines a JSON encoding for YANG-defined data. It does = not defined any mechanisms for signing or encrypting said data. Use of = an external mechanism, such as PKCS #7 [RFC2315] or JOSE [RFC7515 and = RFC7516], is needed for such cases." I am fine with adding this sentence although, as a matter of fact, the = document does not define an infinite number of other mechanisms. There = is no general requirement to support signing and encrypting for = YANG-modelled data, also because, as Andy pointed out, our protocols so = far demand a secure transport. I any case, we can make this edit only after IETF 95, right? Lada=20 >=20 > Elliot, Randy, Stephen? >=20 > Kent // document shepherd=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 24 06:15:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5608412DAD0 for ; Thu, 24 Mar 2016 06:15:38 -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, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqETIroOydGl for ; Thu, 24 Mar 2016 06:15:35 -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 426CA12DB63 for ; Thu, 24 Mar 2016 06:13:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C246A1D9B; Thu, 24 Mar 2016 14:13:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7rOEmrdk4xFn; Thu, 24 Mar 2016 14:12:47 +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, 24 Mar 2016 14:13:04 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id F28F920045; Thu, 24 Mar 2016 14:13:03 +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 a-bXToKrw9Jn; Thu, 24 Mar 2016 14:13: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 4F2A320043; Thu, 24 Mar 2016 14:13:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6A9C53A510AE; Thu, 24 Mar 2016 14:13:01 +0100 (CET) Date: Thu, 24 Mar 2016 14:13:00 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160324131300.GA69205@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <1458566013189.55874@pantheon.tech> <20160323.220116.2259282208531577772.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.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount: Namespace issues 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: Thu, 24 Mar 2016 13:15:38 -0000 On Thu, Mar 24, 2016 at 12:56:40PM +0100, Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > The fact that anydata can represent "really anything" does not mean > > that every server MUST allow the client to create "really anything" > > for all anydata config nodes. It will depend on the semantics of each > > particular anydata node. > > Schema validation is effectively disabled for anydata nodes. This may be > a problem especially for implementations that perform validation as a > separate step, perhaps automatically from the data model. > > And with schema validation out of the way, it is easier to exploit > potential bugs in the server. > Lada, as far as I recall you wrote an I-D that proposed to mount data anywhere. So what did change your mind that you now want strict schema validation? > > I think that using mount-point as a substatement to anydata is in fact > > the only really safe option to mount. Both the proposed solutions in > > Well, if safe means (partial) compatibility of old clients - and I am > not even convinced about this. Otherwise it is IMO less safe because the > schema is loosened. > > > the current structural mount and ysdl drafts are unsafe for clients > > that don't understand the mount. > > True. What do you mean with 'partial' compatibility? I also do not understand which schema is 'loosened'? Can you give me an example of 'partial' compatibility and 'loosened' schema? Do you have a counter proposal that avoids these issues? /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 24 06:18:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C87412D12D for ; Thu, 24 Mar 2016 06:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g935lgYKyU3 for ; Thu, 24 Mar 2016 06:18:15 -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 7F5D112D0D9 for ; Thu, 24 Mar 2016 06:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2592; q=dns/txt; s=iport; t=1458825494; x=1460035094; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=yjzkg8vOjOifmXMAiAnWaNRmZsBG4kaH7/IpWlbubfQ=; b=K7NZezQip3Uf/iP/z5hIHamcjJiyyRsmmh3IBV8JP5A+5hLkNZi4T9LR DGiK0J9J0DnvpsVPAVFnOW6YeOJjeCQfHRaKno6ZBLpAuZ7lPvWIKpx3v CsRlZj3p9CDP724Nb/3a9QwV0+9h7s/O+TqllvGhXbfhAitY6fB3FeXOD 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBABp6PNW/xbLJq1evUaEDYYNAoF5A?= =?us-ascii?q?QEBAQEBZSeEQgEBBCNVARALGAkWCwICCQMCAQIBRQYBDAgBAYgjsCKQZwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEPCIpihzyCVgEEl16DHoFmiQCJN4VUjwligjCBNjuKB?= =?us-ascii?q?AEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,385,1454976000"; d="asc'?scan'208";a="634696523" 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; 24 Mar 2016 13:18:12 +0000 Received: from [10.61.202.49] ([10.61.202.49]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u2ODIBrs022468; Thu, 24 Mar 2016 13:18:12 GMT To: Ladislav Lhotka , Kent Watsen References: <33092781.1458705432558.JavaMail.wam@elwamui-rubis.atl.sa.earthlink.net> <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> From: Eliot Lear Message-ID: <56F3E913.1070102@cisco.com> Date: Thu, 24 Mar 2016 14:18:11 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f99F3XIs06AwA0EPG59jsdUdUjjcgvMP2" Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 24 Mar 2016 13:18:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f99F3XIs06AwA0EPG59jsdUdUjjcgvMP2 Content-Type: multipart/mixed; boundary="SCOPi1x8RncQLpp22EbSfJhQrU72i9s8v" From: Eliot Lear To: Ladislav Lhotka , Kent Watsen Cc: Randy Presuhn , "netmod@ietf.org" Message-ID: <56F3E913.1070102@cisco.com> Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) References: <33092781.1458705432558.JavaMail.wam@elwamui-rubis.atl.sa.earthlink.net> <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> In-Reply-To: --SCOPi1x8RncQLpp22EbSfJhQrU72i9s8v Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Lada, On 3/24/16 1:12 PM, Ladislav Lhotka wrote: > I am fine with adding this sentence although, as a matter of fact, the > document does not define an infinite number of other mechanisms. There > is no general requirement to support signing and encrypting for > YANG-modelled data, also because, as Andy pointed out, our protocols > so far demand a secure transport. Just for context, encrypted transport addresses only in flight attack.=20 That's not always the only form that needs to be protected against. At least in the use case I'm dealing with, where an intermediary system =E2=80= =93 one that is storing files =E2=80=93 is attacked, and due to the scope of = the risk, we want an additional layer. This also allows files to be passed around without having to worry about the path. That's not in my specific use case today, but it is something that has been done. Eliot --SCOPi1x8RncQLpp22EbSfJhQrU72i9s8v-- --f99F3XIs06AwA0EPG59jsdUdUjjcgvMP2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJW8+kTAAoJEIe2a0bZ0nozKGsIAI5CLgzSeMz2omKD1zwPfnqG /Uzh/Qh4gXqCoLiW83lBDWUoJaqYe5QZGX4HMKY4RGs4y1sbUkUEKHN5wjzCGWV0 dl0DNThlzYu0slDp4XHA+ey6YvScszTKCFukzlGPB39nc83OL0HZiFFbRkPJ073q pbj7nxPBFSinU47SBGI+/cDtfw2PCoQg0Im0luXlFo/jabwaAu1pH5qRIANDgpBU QuZjQL36Q25cDP76UZRnI9v3swx0MhOUNuhO3dXOUWStVYD51HlK3mIbIxzYyNZ9 hnm+YsehrGVXBrc7xoEaqNUIjV6lOK9Mc+YLLbxCyx7r+vSi7YZk9VAnWIYXPGs= =GIcB -----END PGP SIGNATURE----- --f99F3XIs06AwA0EPG59jsdUdUjjcgvMP2-- From nobody Thu Mar 24 06:48:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7230412DB35 for ; Thu, 24 Mar 2016 06:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9E0qV3U2xuo for ; Thu, 24 Mar 2016 06:48: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 4C09A12DB37 for ; Thu, 24 Mar 2016 06:47:34 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:45db:ad9a:f9e0:d864] (unknown [IPv6:2001:718:1a02:1:45db:ad9a:f9e0:d864]) by mail.nic.cz (Postfix) with ESMTPSA id D5589187F88; Thu, 24 Mar 2016 14:47:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1458827252; bh=LuZ8nxAVSfS7yTb7llHQ1a181IuEqbwU2Gn817qpCHE=; h=From:Date:To; b=r2N0SlPM5tMXUy3C+ymSjBxrHbachjj9F8Jsf1c/MAw3VTOssWD/TSBVAx9INyx3s 1OL1IDftxMs4ryvs+Vxka2DelfkD4BLSDXmNJVHPQBHSyogI2Y0FHgGe27bJzXAFz+ jacx44lRhFPNL29LnHHOcPrB3oddshpq7r/JQ2l4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160324131300.GA69205@elstar.local> Date: Thu, 24 Mar 2016 14:47:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <56CC98F5-63FF-4ED8-8B8C-C3C8C305DC8C@nic.cz> References: <1458566013189.55874@pantheon.tech> <20160323.220116.2259282208531577772.mbj@tail-f.com> <20160324131300.GA69205@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount: Namespace issues 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, 24 Mar 2016 13:48:24 -0000 > On 24 Mar 2016, at 14:13, Juergen Schoenwaelder = wrote: >=20 > On Thu, Mar 24, 2016 at 12:56:40PM +0100, Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>> The fact that anydata can represent "really anything" does not mean >>> that every server MUST allow the client to create "really anything" >>> for all anydata config nodes. It will depend on the semantics of = each >>> particular anydata node. >>=20 >> Schema validation is effectively disabled for anydata nodes. This may = be >> a problem especially for implementations that perform validation as a >> separate step, perhaps automatically from the data model. >>=20 >> And with schema validation out of the way, it is easier to exploit >> potential bugs in the server. >>=20 >=20 > Lada, as far as I recall you wrote an I-D that proposed to mount data > anywhere. So what did change your mind that you now want strict schema > validation? With YSDL, the schema validation is absolutely strict: The server = provides a list of modules and revisions in yang-library, and a recipe = how the modules are combined. Everything is fixed and static, as it is = without YSDL, only some of the schema subtrees are attached to non-root = locations. As I said in the interim, YSDL is just an externally = specified augment. =20 >=20 >>> I think that using mount-point as a substatement to anydata is in = fact >>> the only really safe option to mount. Both the proposed solutions = in >>=20 >> Well, if safe means (partial) compatibility of old clients - and I am >> not even convinced about this. Otherwise it is IMO less safe because = the >> schema is loosened. >>=20 >>> the current structural mount and ysdl drafts are unsafe for clients >>> that don't understand the mount. >>=20 >> True. >=20 > What do you mean with 'partial' compatibility? I also do not Take the rtgyangdt model, for example. If a mounting mechanism is in = place, a client that doesn't understand it will only see a void = top-level structure, which is hardly useful. > understand which schema is 'loosened'? Can you give me an example of Loosened means exactly that anydata is used. For example, a rogue client = may use it to send data that test the robustness of the server's Unicode = implementation. For instance, a server implementor can place a rock-solid off-the-shelf = RELAX NG validator in front of the backend and rely on it to catch = everything that violates the schema. If anydata is involved, the RELAX = NG validator will, well, relax, and pass everything to the backend. > 'partial' compatibility and 'loosened' schema? Do you have a counter > proposal that avoids these issues? Sure: avoid anydata, and forget about supporting clients that don't = understand mounts. 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: E74E8C0C From nobody Thu Mar 24 07:05:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1C712DC06 for ; Thu, 24 Mar 2016 07:05:39 -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, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEh1SHu6EaqM for ; Thu, 24 Mar 2016 07:05: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 D6FD012DC09 for ; Thu, 24 Mar 2016 06:59:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9C65A1027; Thu, 24 Mar 2016 14:59:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gnbo6Z__DL8V; Thu, 24 Mar 2016 14:58:47 +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, 24 Mar 2016 14:59:04 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8805720044; Thu, 24 Mar 2016 14:59:04 +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 2rWf2NdbcO97; Thu, 24 Mar 2016 14:59: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 CB24620045; Thu, 24 Mar 2016 14:59:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7DC003A5111A; Thu, 24 Mar 2016 14:59:01 +0100 (CET) Date: Thu, 24 Mar 2016 14:59:00 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160324135859.GB69205@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , netmod@ietf.org References: <1458566013189.55874@pantheon.tech> <20160323.220116.2259282208531577772.mbj@tail-f.com> <20160324131300.GA69205@elstar.local> <56CC98F5-63FF-4ED8-8B8C-C3C8C305DC8C@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56CC98F5-63FF-4ED8-8B8C-C3C8C305DC8C@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount: Namespace issues 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: Thu, 24 Mar 2016 14:05:39 -0000 On Thu, Mar 24, 2016 at 02:47:33PM +0100, Ladislav Lhotka wrote: > > > On 24 Mar 2016, at 14:13, Juergen Schoenwaelder wrote: > > > > On Thu, Mar 24, 2016 at 12:56:40PM +0100, Ladislav Lhotka wrote: > >> Martin Bjorklund writes: > >> > >>> The fact that anydata can represent "really anything" does not mean > >>> that every server MUST allow the client to create "really anything" > >>> for all anydata config nodes. It will depend on the semantics of each > >>> particular anydata node. > >> > >> Schema validation is effectively disabled for anydata nodes. This may be > >> a problem especially for implementations that perform validation as a > >> separate step, perhaps automatically from the data model. > >> > >> And with schema validation out of the way, it is easier to exploit > >> potential bugs in the server. > >> > > > > Lada, as far as I recall you wrote an I-D that proposed to mount data > > anywhere. So what did change your mind that you now want strict schema > > validation? > > With YSDL, the schema validation is absolutely strict: The server provides a list of modules and revisions in yang-library, and a recipe how the modules are combined. Everything is fixed and static, as it is without YSDL, only some of the schema subtrees are attached to non-root locations. As I said in the interim, YSDL is just an externally specified augment. > But the same applies here. This discussion is about how to arrange things such that _old_ clients that do not understand mounts break. At least that is what I thought. > Take the rtgyangdt model, for example. If a mounting mechanism is in place, a client that doesn't understand it will only see a void top-level structure, which is hardly useful. Yes, but it does not _break_ an old client (which likely is not interested at all in the stuff it does not understand). > > understand which schema is 'loosened'? Can you give me an example of > > Loosened means exactly that anydata is used. For example, a rogue client may use it to send data that test the robustness of the server's Unicode implementation. We have been there. Since the server understands the model, the server will reject bad input. > For instance, a server implementor can place a rock-solid off-the-shelf RELAX NG validator in front of the backend and rely on it to catch everything that violates the schema. If anydata is involved, the RELAX NG validator will, well, relax, and pass everything to the backend. > Again, the server understands the data model, it will not implement anydata. > > 'partial' compatibility and 'loosened' schema? Do you have a counter > > proposal that avoids these issues? > > Sure: avoid anydata, and forget about supporting clients that don't understand mounts. So you propose a flag day from which on all clients must support mounts? Not very realistic I think. I believe not breaking existing clients is a key requirement in order to allow incremental deployment of new features. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 24 07:34:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76BA12DB47 for ; Thu, 24 Mar 2016 07:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DLpay5hMN6Z for ; Thu, 24 Mar 2016 07:34:17 -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 97F3012DC92 for ; Thu, 24 Mar 2016 07:23:19 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:45db:ad9a:f9e0:d864] (unknown [IPv6:2001:718:1a02:1:45db:ad9a:f9e0:d864]) by mail.nic.cz (Postfix) with ESMTPSA id 4D33618B1F0; Thu, 24 Mar 2016 15:23:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1458829398; bh=a/R3f+T2oJoJyCmYR0+R4PA3a1Ia+HyNEZHjlX7W8z4=; h=From:Date:To; b=PhzjUA6FA3oBFYXA3vQna49ODdtUuJuVPNFz5ho8xsThQLDC2IwDkJZpGhGFzQSZc 3WzeoJ4WX4NwJGthfYeii4pKBR6nzHO9/mFHLWZqXvhuZVgKR/FuWqT8JBmU4P0yDc QRP0w5KzEOZVHDh8/W9IEjsvT3nxm3u13l1VmB60= Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8716D292-CD39-4C53-9A3C-59F6671DCEDF"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: Ladislav Lhotka In-Reply-To: <56F3E913.1070102@cisco.com> Date: Thu, 24 Mar 2016 15:23:18 +0100 Message-Id: References: <33092781.1458705432558.JavaMail.wam@elwamui-rubis.atl.sa.earthlink.net> <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> <56F3E913.1070102@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 24 Mar 2016 14:34:19 -0000 --Apple-Mail=_8716D292-CD39-4C53-9A3C-59F6671DCEDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eliot, I agree it would be useful to be able to sign configuration data in an = encoding-independent way, but it is not an aim of this document to deal = with this problem. Encoding-specific approaches are of course available, = this probably needn't be mentioned. Lada > On 24 Mar 2016, at 14:18, Eliot Lear wrote: >=20 >=20 > Hi Lada, >=20 > On 3/24/16 1:12 PM, Ladislav Lhotka wrote: >> I am fine with adding this sentence although, as a matter of fact, = the >> document does not define an infinite number of other mechanisms. = There >> is no general requirement to support signing and encrypting for >> YANG-modelled data, also because, as Andy pointed out, our protocols >> so far demand a secure transport. >=20 > Just for context, encrypted transport addresses only in flight = attack. > That's not always the only form that needs to be protected against. = At > least in the use case I'm dealing with, where an intermediary system = =E2=80=93 > one that is storing files =E2=80=93 is attacked, and due to the scope = of the > risk, we want an additional layer. This also allows files to be = passed > around without having to worry about the path. That's not in my > specific use case today, but it is something that has been done. >=20 > Eliot >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C --Apple-Mail=_8716D292-CD39-4C53-9A3C-59F6671DCEDF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlbz+FcACgkQWQVCj+dOjAx+sQCeOAHGMtoUf7CSjUqnjPYhj4SJ QNkAoJjIXi8nH3Fl6527wd8Ecx8wKy1R =RNxa -----END PGP SIGNATURE----- --Apple-Mail=_8716D292-CD39-4C53-9A3C-59F6671DCEDF-- From nobody Thu Mar 24 08:21:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D0112DDB2 for ; Thu, 24 Mar 2016 08:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIKKvxEtjxLZ for ; Thu, 24 Mar 2016 08:21:57 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCD212DE06 for ; Thu, 24 Mar 2016 08:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2313; q=dns/txt; s=iport; t=1458831971; x=1460041571; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=PsSlPhaH5XK6/OZY2vyQjcSqP4zKMYqB/S/s3QIzt0U=; b=InbftiYExikRy2qiV/OAP/aA93+VlXrvcwss0209C8/uVPxPqIOGAFX5 UyLgGcjpafkKLOAZEMGRP96gpCGc5qjadb377CF6VTKdfkqF6wJJlqfsy jTuFNNJEhgAQSdJNAaU3p6Jeo96DZezYMsIhZLmRpgyZvGX/gK4sSGr9s M=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBAClAfRW/xbLJq1evUiCHYFwhg0Cg?= =?us-ascii?q?WkSAQEBAQEBAWQnhEIBAQQjVQEQCxgJFgsCAgkDAgECAUUGDQgBAYgjsBuQVgE?= =?us-ascii?q?BAQEBAQEBAgEBAQEBAQEBEAiKYoc8glYBBJdegx6BZokAgVCHZ4VUjwknBDeCM?= =?us-ascii?q?IE2O4oEAQEB?= X-IronPort-AV: E=Sophos;i="5.24,385,1454976000"; d="asc'?scan'208";a="676264272" 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; 24 Mar 2016 15:06:09 +0000 Received: from [10.61.201.213] ([10.61.201.213]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u2OF69VI016569; Thu, 24 Mar 2016 15:06:09 GMT To: Ladislav Lhotka References: <33092781.1458705432558.JavaMail.wam@elwamui-rubis.atl.sa.earthlink.net> <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> <56F3E913.1070102@cisco.com> From: Eliot Lear Message-ID: <56F40260.2090004@cisco.com> Date: Thu, 24 Mar 2016 16:06:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KeQgailv5U2VrUHBPXnTOG287RmL7pUuL" Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 24 Mar 2016 15:21:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KeQgailv5U2VrUHBPXnTOG287RmL7pUuL Content-Type: multipart/mixed; boundary="7qIfaiK0oF6KPjUv8p3aMM4p1hHpDrbl2" From: Eliot Lear To: Ladislav Lhotka Cc: Kent Watsen , Randy Presuhn , "netmod@ietf.org" Message-ID: <56F40260.2090004@cisco.com> Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) References: <33092781.1458705432558.JavaMail.wam@elwamui-rubis.atl.sa.earthlink.net> <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> <56F3E913.1070102@cisco.com> In-Reply-To: --7qIfaiK0oF6KPjUv8p3aMM4p1hHpDrbl2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Lada, On 3/24/16 3:23 PM, Ladislav Lhotka wrote: > Hi Eliot, > > I agree it would be useful to be able to sign configuration data in an = encoding-independent way, but it is not an aim of this document to deal w= ith this problem. Encoding-specific approaches are of course available, t= his probably needn't be mentioned. I totally understand, and I'm not even asking that this group take on coding that stuff in an independent way. A simple reference in security considerations along the lines that Kent suggested is fine. Eliot --7qIfaiK0oF6KPjUv8p3aMM4p1hHpDrbl2-- --KeQgailv5U2VrUHBPXnTOG287RmL7pUuL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJW9AJhAAoJEIe2a0bZ0nozNFwIAIrt9tbz3CMtX8vyOnYFDduV uzZpoqMcIam7uwFd/P25G/3lZf9cMShKYDgL5Dzb4rvTDLDKRHJ+8Dmjnvg3b5E8 XwSuYU7Ov/mvA8I50sLFsUbjIVbnF7NkmDXNZhsG2HusU6e81PlAQL7/xtyBBD3O EvjED0IBAZU17LtVB1Cp/DSrFgLWrPvBf7PgL7wpsoMW3nnWFS2UnVCFCHx4Jvqu k2XaW3HSyRwW9Wzrfa6qFe6bXR7kPJsUwkGGfgfGX+xCfZN5wzbhMg/mCK1VMzRh dPm7NsWIH6wXKknL3NowhssNrLTQs3q6V7J1CZsrZeGq6KfmJ3ug6dsuagecu/M= =q4B1 -----END PGP SIGNATURE----- --KeQgailv5U2VrUHBPXnTOG287RmL7pUuL-- From nobody Thu Mar 24 08:23:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4959612D562 for ; Thu, 24 Mar 2016 08:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsFc_hT_d4Hm for ; Thu, 24 Mar 2016 08:23:37 -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 8D06212DB6B for ; Thu, 24 Mar 2016 08:07:28 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:45db:ad9a:f9e0:d864] (unknown [IPv6:2001:718:1a02:1:45db:ad9a:f9e0:d864]) by mail.nic.cz (Postfix) with ESMTPSA id 2F8E7180228; Thu, 24 Mar 2016 16:07:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1458832047; bh=gctLIRd+hAGG+VzdTMe0hTTU3muvE/KwHQ912xvtHPI=; h=From:Date:To; b=I3RXRhctJQTHaQd6T4nIubOijl2LW+pV5/8kLUY1ju7D5gVxqsVbrN6zwBZ5jxpIW kLNj8Oq0SJGg9tFLtXSmwZULSTpVzHtFQKfrEehnk5clIeDb8ywKn6c1nTP80IQF4l 9rAym/YcHtQsx+Er5JM/yQaQwZBC0AtnX2SsGIj0= Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5D385DE6-A05D-46F1-8EA5-8B2F92BDE30F"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: Ladislav Lhotka In-Reply-To: <56F40260.2090004@cisco.com> Date: Thu, 24 Mar 2016 16:07:27 +0100 Message-Id: <34CDDD10-7404-4A30-A3FC-D632A9386BB6@nic.cz> References: <33092781.1458705432558.JavaMail.wam@elwamui-rubis.atl.sa.earthlink.net> <9530271B-7639-41EB-BFBA-E9772BB3F1F1@juniper.net> <56F3E913.1070102@cisco.com> <56F40260.2090004@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) 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, 24 Mar 2016 15:23:39 -0000 --Apple-Mail=_5D385DE6-A05D-46F1-8EA5-8B2F92BDE30F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 24 Mar 2016, at 16:06, Eliot Lear wrote: >=20 > Hi Lada, >=20 > On 3/24/16 3:23 PM, Ladislav Lhotka wrote: >> Hi Eliot, >>=20 >> I agree it would be useful to be able to sign configuration data in = an encoding-independent way, but it is not an aim of this document to = deal with this problem. Encoding-specific approaches are of course = available, this probably needn't be mentioned. >=20 > I totally understand, and I'm not even asking that this group take on > coding that stuff in an independent way. A simple reference in = security > considerations along the lines that Kent suggested is fine. OK, let's do it. Lada >=20 > Eliot >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C --Apple-Mail=_5D385DE6-A05D-46F1-8EA5-8B2F92BDE30F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlb0ArAACgkQWQVCj+dOjAxS0ACeMsrU0Zacq/LFHls17mWCMeIv QHgAnjDaPNyf5WW7IwC24LGYUh4nVhPy =Nz0e -----END PGP SIGNATURE----- --Apple-Mail=_5D385DE6-A05D-46F1-8EA5-8B2F92BDE30F-- From nobody Thu Mar 24 22:58:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA6312D63C for ; Thu, 24 Mar 2016 22:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=randy_presuhn@mindspring.com header.d=mindspring.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 iaXs6BZEdFnK for ; Thu, 24 Mar 2016 22:58:46 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF2612D621 for ; Thu, 24 Mar 2016 22:58:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=eDpE7nrXIQcFCsM1pU8WIGtP8rAZNvdJRXZTJck9pBFj1/K5X5j5QCwChpL6/y1f; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ajKlf-0000XJ-6r for netmod@ietf.org; Fri, 25 Mar 2016 01:58:43 -0400 Received: from 76.254.50.228 by webmail.earthlink.net with HTTP; Fri, 25 Mar 2016 01:58:43 -0400 Message-ID: <4196233.1458885523183.JavaMail.wam@elwamui-norfolk.atl.sa.earthlink.net> Date: Thu, 24 Mar 2016 22:58:43 -0700 (GMT-07:00) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc8123649b42cb6ae135b8f23a5b5d0725350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 Archived-At: Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 05:58:48 -0000 Hi - Works for me after fixing the English. The deficiency is IMO serious, but inherent to the netmod architecture, so attempted fixes do not belong in this document. Randy >From: Kent Watsen >Sent: Mar 24, 2016 4:42 AM >To: Randy Presuhn >Cc: "netmod@ietf.org" >Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT) > > >All, > >I believe that this thread's issue is resolved if the following text is added to the Security Considerations section: > > >"This document defines a JSON encoding for YANG-defined data. It does not defined any mechanisms for signing or encrypting said data. Use of an external mechanism, such as PKCS #7 [RFC2315] or JOSE [RFC7515 and RFC7516], is needed for such cases." > >Elliot, Randy, Stephen? > >Kent // document shepherd > From nobody Sat Mar 26 03:08:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC4C12D5AD for ; Sat, 26 Mar 2016 03:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 woPaLQjeSFWi for ; Sat, 26 Mar 2016 03:08:42 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BDAA12D5AB for ; Sat, 26 Mar 2016 03:08:42 -0700 (PDT) Received: from pps.filterd (m0048193.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u2QA5ZGl005442 for ; Sat, 26 Mar 2016 03:08:41 -0700 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 21s5g5y8q4-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Sat, 26 Mar 2016 03:08:41 -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.1104.5; Sat, 26 Mar 2016 04:08:40 -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.1104.5; Sat, 26 Mar 2016 11:08:38 +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.1104.000; Sat, 26 Mar 2016 11:08:38 +0100 From: William Ivory To: "netmod@ietf.org" Thread-Topic: Query about usage of local-name() in YANG XPATH expressions Thread-Index: AdGHRklYYu2WBbSoTmy8zANMZSgp7g== Date: Sat, 26 Mar 2016 10:08:16 +0000 Deferred-Delivery: Sat, 26 Mar 2016 10:07:55 +0000 Message-ID: <3f34012c40bc47ff87fe0aa944477979@EMEAWP-EXMB12.corp.brocade.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: [10.252.48.3] Content-Type: multipart/alternative; boundary="_000_3f34012c40bc47ff87fe0aa944477979EMEAWPEXMB12corpbrocade_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-26_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603260152 Archived-At: Subject: [netmod] Query about usage of local-name() in YANG XPATH expressions 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, 26 Mar 2016 10:08:43 -0000 --_000_3f34012c40bc47ff87fe0aa944477979EMEAWPEXMB12corpbrocade_ Content-Type: text/plain; charset="us-ascii" Hi, >From RFC 6087 (YANG Usage Guidelines), section 5.6.2, the following is noted about the use of the XPATH local-name() function: The 'local-name' function SHOULD NOT be used to reference local names outside of the YANG module defining the must or when expression containing the 'local-name' function. Example of a local-name function that should not be used: /*[local-name()='foo'] However, no explanation is given as to why this is a bad idea. We have a specific use case where local-name() would appear to allow us to massively simplify some rather cumbersome must expressions, but I wanted to check I'm not missing some 'gotcha' here. Is it simply that relying on a common node name across multiple modules is generally a bad design as it ties the modules together, or is there more to it? If so, then in our case this is a reasonable restriction. Thanks, William --_000_3f34012c40bc47ff87fe0aa944477979EMEAWPEXMB12corpbrocade_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
From RFC 6087 (YANG Usage Guidelines), section 5.6.2, the following is= noted about the use of the XPATH local-name() function:
 
   The 'local-name' function SHOULD NOT be used to reference= local names
   outside of the YANG module defining the must or when expr= ession
   containing the 'local-name' function.  Example of a = local-name
   function that should not be used:
 
      /*[local-name()=3D'foo']
 
However, no explanation is given as to why this is a bad idea.  W= e have a specific use case where local-name() would appear to allow us to m= assively simplify some rather cumbersome must expressions, but I wanted to = check I’m not missing some ‘gotcha’ here.  Is it simply that relying on a common node name across multiple modules is = generally a bad design as it ties the modules together, or is there more to= it?  If so, then in our case this is a reasonable restriction.
 
Thanks,
 
William
 
 --_000_3f34012c40bc47ff87fe0aa944477979EMEAWPEXMB12corpbrocade_-- From nobody Mon Mar 28 08:27:34 2016 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 2D87212DA57; Mon, 28 Mar 2016 08:27:30 -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.17.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160328152730.20337.4785.idtracker@ietfa.amsl.com> Date: Mon, 28 Mar 2016 08:27:30 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-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, 28 Mar 2016 15:27:30 -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 : JSON Encoding of Data Modeled with YANG Author : Ladislav Lhotka Filename : draft-ietf-netmod-yang-json-10.txt Pages : 21 Date : 2016-03-28 Abstract: This document defines encoding rules for representing configuration data, state data, parameters of RPC operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-json-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 28 09:26:09 2016 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 075A312DBD1; Mon, 28 Mar 2016 09:26:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160328162602.20392.73736.idtracker@ietfa.amsl.com> Date: Mon, 28 Mar 2016 09:26:02 -0700 Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org, draft-ietf-netmod-yang-json@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [netmod] Protocol Action: 'JSON Encoding of Data Modeled with YANG' to Proposed Standard (draft-ietf-netmod-yang-json-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, 28 Mar 2016 16:26:03 -0000 The IESG has approved the following document: - 'JSON Encoding of Data Modeled with YANG' (draft-ietf-netmod-yang-json-10.txt) as Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ Technical Summary This document defines encoding rules for representing configuration, state data, RPC operation or action input and output parameters, and notifications defined using YANG as JavaScript Object Notation (JSON) text. Working Group Summary The JSON encoding is one of the two media types supported by the RESTCONF protocol [draft-ietf-netconf-restconf]. This document was discussed multiple times during the RESTCONF specification process. The main issue has been around the encoding of the "anyxml" type, which YANG 1.1 no longer recommends using. The document went through 3 WG last calls, and there is broad consensus on the final version. Document Quality There are several existing RESTCONF implementations, and some others being worked on, that either support both XML and JSON encoding, or are JSON-only, for example: * YumaWork’s YumaPro platform's SDK * Linux Foundation’s OpenDaylight platform * Juniper’s Contrail Service Orchestration platform Other tools and libraries also support the JSON encoding defined in this document, including: * The popular `pyang` utility * The libyang library Personnel The Shepherd is Kent Watsen. The AD is Benoit Claise. From nobody Mon Mar 28 10:13:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5366312DBEF for ; Mon, 28 Mar 2016 10:12:58 -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] 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 bP5E10sykDEc for ; Mon, 28 Mar 2016 10:12:51 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0127.outbound.protection.outlook.com [104.47.1.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07EED12DBFE for ; Mon, 28 Mar 2016 10:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bzvylQZuQ4eoM6BwW8LzDM4Q0pwxJjSXiDjF3q18ROU=; b=aVsdjRsXlEv7QHNjhL6hkF81FXRjVO0cXZDH4MtIpaqEPaduwtsr7mOLqOFB3dQQDsOz9bOjnl+AzRujbNuDZL0z8ycZIRrbiqXSKLLkj4Ca917biLAMHydvdmFj5K2Joc8a4GndRH910ICF7qaisaai68GUFKzZzT297SA1Uzc= 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 (81.132.199.159) by VI1PR07MB1630.eurprd07.prod.outlook.com (10.166.142.148) with Microsoft SMTP Server (TLS) id 15.1.443.7; Mon, 28 Mar 2016 17:12:46 +0000 Message-ID: <01cb01d18914$ab13ae40$4001a8c0@gateway.2wire.net> From: t.petch To: "Clyde Wildes (cwildes)" , References: <20160320151006.2321.64042.idtracker@ietfa.amsl.com> Date: Mon, 28 Mar 2016 18:09:54 +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: [81.132.199.159] X-ClientProxiedBy: DB4PR06CA0008.eurprd06.prod.outlook.com (25.162.49.18) To VI1PR07MB1630.eurprd07.prod.outlook.com (25.166.142.148) X-MS-Office365-Filtering-Correlation-Id: 9146b86f-6238-49ba-725e-08d3572c2f24 X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1630; 2:KtvWQoeOcK6Rc2539aBf1feaLXyalAA6nmTW05a5hPd6kyTrECjC8ULaJNu11TWze1B0/An2F/1mNgXo4vdAUcKPGeWCf/7d2hGH1BK5yecuIXEgTzep1vWPpeoelF7+L90oHNBaAzFqND7+aqv1DHuDD9D4ROrQwfxSybAwVVDUB6WOXYMxQKOuxZMNG8Ro; 3:G0v5y22zFH5y3HMlNop+tVG7QM/rjG2RZWe/CH0MYu3le3+OOeh8QzNutQ1HxK9W3L4b/A89GYzGU+sUmMfexXJfnmAM9eY4av32BIroiEOUlNruXJNrPqX07nh8FclX X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1630; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1630; 25:fC7Dbfu9ioY4VYB2bINeE5cP8FkAzYhOKesXbR9qytXcZiB0VwL/1cMvhI0LjyHShXw/R0sdGVUgxlv+Rc7r+xx/Nr1mJg3+g4N3yChBdlPjGkZJp5GVAs8cl2z8SR6OJHXVtM7hubJ84eSHhstOBJ9uZ+aNW0vYNgemfgPqc//tQbQujQdETPr5UM69HwJIB8DH5DAXSSAK94VyCxiIooHQS5AWVsKMg13m7NLcna1RKrs7F2wfOTNbdo0F8CXjGP1wG0PnTjQQSlD0JmBOSi0EaQGmIVEqqWIM132vWwG3FXdPETj5cTwo+8RyGGJxEv8CdJSAwzRkZTVtYsyZuCuw935Vsv5HcMG4a+/u+z+wNZLzF7rn1znjtnTRkXVFcChtpZ7sAna5ggwHCXfJAHnWRIaafeb8/5bS89ot6jVwxI/wTHxvA3/uBVpyqJi5bYEHqLGzRR9Xn1Cmy2jOKhkTxta7gh1+G33CPL8hu2WnAK4hVFj/GX9UXZfqEHbEiBY7VJuEYKx+RWR7qKlLSh7vIMJd0mHsKfinCEdsLZNnjbEQCcaiNwMPtnbzY46SQnUtD8JUjZQLiz7nRIeZ5abHxFIg5ZQm3VUqWuRm8c8JYt1rY2XdtDr6CjAxQGrAtXfKLtrJTnnUWxuXQiXrO8UmbAXoZOxhewLE1treQfZ8rP89NuxkqcIu86RC9Zjg X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR07MB1630; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1630; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1630; 4:t6t5X0FxF2MrYwpe53OH+X6y+VoFax1kns0QLkZ03FFao8NOAxb7PH/B4SBUelynelAPW/15x/9NMVDM5hfGawU3G/AS5AXuM6VGTtsfKwvf3yewxSODDaNzJA7FpnHj8xPiXUEprK9N7oaz537e+pgfUqjQfT5sefOOZAYUwJm7yDa/Q9TyBkb7qZ0eB4l6N/clqc4SAn9LxiHzp5d6ozmmxvwNYSnwq0BRpnqxWdvTGpaZ2nxZduaySFO4xanViXRpzZgnfC6nPSlPJL3PRqnOaVv59XRhOW4Ro2SwYDIXgnBBwnyAwA1Njget4sgiY+lUsQ/ec2XS6mxxF5vkekXP9TwhLfEVWHMyWxiVzsbyfxdIPQkb0tN7Dmwqz+FTbJ25bHwZPMkTRqqubKJFMfdlew7SEvg+Hbg3aZkN2a4= X-Forefront-PRVS: 0895DF8FFD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(164054003)(24454002)(377424004)(377454003)(189998001)(50466002)(1096002)(81816999)(86362001)(81686999)(50986999)(76176999)(230783001)(19580395003)(19580405001)(5008740100001)(23676002)(66066001)(230700001)(5004730100002)(92566002)(42186005)(33646002)(5001770100001)(81166005)(47776003)(6116002)(1556002)(15975445007)(586003)(1456003)(50226001)(44716002)(61296003)(77096005)(2906002)(62236002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1630; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIxNjMwOzIzOlhqdnpOOGYwbjJsRmNCZHZ1ZmgrSmxkUWtZ?= =?utf-8?B?cXNycHJBMVJ3SWFOMjFxVTN4cGVRSGdVcGF2dVRYRW1CQUdFM1o0WkN1dXk3?= =?utf-8?B?emVVajVUQUhhR1lNbDFvNGNzMGRpOHgzNU9ETzFJY1Mzd0p0blVFamZ0NU9J?= =?utf-8?B?YlVPaFc3YlhEWVRBZDVuc0gzcUowcXRBZlpCMllaUmVFVlhZcXlwSU0rSlhv?= =?utf-8?B?UlFCdXU0Yy8xbWlsOGFiZWh0UTN5ajNRUU1ReUNCUmZyQmNJWis4QVpnR2dz?= =?utf-8?B?WGxERTJueXJRaXRLNGRTbHlGS292KzZjVXpDQncwNlFNa3dSYkprVFBxaEE1?= =?utf-8?B?QUlXQWs2bmQ2bUNUM3l0Wi9JUTZDK0Q4ZkxnNkcwSTBuRk4ybHY2M1VObXVm?= =?utf-8?B?Yy9mNXJMT3pFRHFmNTRjRWpDbFJORXB2YnpXalR1enZUUzJnanpnWTFNRkpr?= =?utf-8?B?Y0QrQTlld2s3VllxcitFWWMwV29ROTBrUmtBeUhBSnkyMkh2U1Zyam9OenJj?= =?utf-8?B?UVJVZzhUTU9Yemc1N2YyZmxiTXJSSEJ2QXk0L202MHJUejFUbWJkdXBFUUEv?= =?utf-8?B?NlVIR3BzVDhzOEZvaVZtM2FYbEFWZnR1SFBMbjdxa29CSlIwY0hoVlJmSEZK?= =?utf-8?B?N2pVTm1nYS9SOFFOaVdwbUMwWFZCOHVlU2N5SllLSlpDaUFvN2R4OXArOWNu?= =?utf-8?B?d2FmdFNqNlJHUEs3QWppVU52c0NsOHBRR0hnVUhhMkRRd2ZBd05tc2pDRUdU?= =?utf-8?B?UklNTEpCU2hlWnVLSlVTKzBRK2QzZFgvRlB4VmNIc25MdWNTdEZHQWZpLzNs?= =?utf-8?B?R1RxUndiMFVTZUFJVDcvSlNlY0hYVXdVVGtMdmJ5TkVZN2FuWWRnT2lMZVJQ?= =?utf-8?B?SmlRVGRuUjE3LzBOaGpuOFRva0tkN2Rkb3Zxajdpc292cVg0czNGYm92eTVH?= =?utf-8?B?Q0VBNkJQV3F1Wm5DQmtTK3hnUmlUZ3NIRlExRDRITVZmZFgwWmhxWGZ3ZnZU?= =?utf-8?B?RHJRWklNL3NNQzBTUWVtcEJHZ3BpV01OVmZEdHd4eE9qZFhmVHlodEU0d0FG?= =?utf-8?B?SzlMYlZCWEM3NTg0ZUpuVVBHTG9SWmtjRU93RGp3SG5pMFlBRWJLak1IWGZ1?= =?utf-8?B?ZTdvSmdZSEVkZ2wzdnhaQitCWkNIN2ZFamxvY2gzYW1OWlVwWDBnM01zQndZ?= =?utf-8?B?eGVJU0JwYyszSHZUa1hDK3Q5Ui9UbmQ2dDZSeEw5WmlLY1hyUCt2cHZybDZT?= =?utf-8?B?Mkd3MU84bWI3bm9SUEZUOUxsQi9YZlk1eUdKOEcxbkQrLzVJQ016a3RUMXM3?= =?utf-8?B?bXZiQ1JqclRhL1ZuZ3NsWXBPalcvUXJaWmNJWk5lOC9jRUtkRlNaUTU1UE1R?= =?utf-8?B?bGlmTjhnYjN3djFrVUdlOXo5akZtQjNHZDlEOWZRQVg2T29ZMlU1MS9GbEFp?= =?utf-8?B?My9FaVNvcnF3K2F0dW1vMS9jS1poSXNNNXdLSmhwQytGc1MxZ2gvRU1oMFk5?= =?utf-8?Q?1YOO4wIchD2Q4W86O/K3iJFDc=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1630; 5:15n0qp9GmIlJUPJuvjNWG59Ws66u3CiJasMvSaze8oybadpZYX0LhLvgr2aVWQD+VFv66tlbfblI52v6cKAMfhsjYv6jQtyIUF19TajvVInJzQVJlft1vpcHM77rl9/x6rN1H7YK5VgF3+us1F7Fjw==; 24:q5oSkMCleIDjD72a2J5HmISHvH0VrbhKUbKiuIOg1LaoQCub8HRfr7pHRoXI5Npa/CiWIZWPD18Zn2DWf5jOglzZkcF1vwPl/UZOeYeqAY8= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2016 17:12:46.6092 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1630 Archived-At: Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.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, 28 Mar 2016 17:12:58 -0000 ----- Original Message ----- From: "Clyde Wildes (cwildes)" To: Cc: "Martin Bjorklund" ; "t.petch" ; "Kiran Koushik Agrahara Sreenivasa (kkoushik)" Sent: Sunday, March 20, 2016 7:53 PM > Hi, > > This revision incorporates feedback from Martin Bjorklunk (19 comments) and Tom Petch (10 comments). Thanks to both of you for your valuable feedback! > > Regarding Tom's comment - "4.1 What a lot of features? Again, makes things more complex, more error prone - are they all really needed?": We started the draft two years ago and it has evolved from feedback received from all of the folks that appear in the Acknowledgements section. Please review the current draft where I believe that I address all of your comments except possibly this one. The tradeoff is to leave the feature specific functionality out of the draft and leave it to the implementations to add back through augmentation. That said most of the features that are called out have been implemented by at least two vendors, but not all, leading to the feature designation. Clyde Yeeees; I did a separate post on the topic thinking that an implementor might share my concerns about the large number of possible variations in an implementation when there were a large number of features, that perhaps there should be guidelines about it, but it did not get any traction. It is one those issues where I think, in a year or two's time, others might share my concern, but not yet:-(. I don't doubt that the variation exists and needs modelling, just that such use of 'features' may have unfortunate consequences - but I have no alternative suggestion. Tom Petch > Thanks, > > Clyde > > > > On 3/20/16, 8:10 AM, "netmod on behalf of 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 : SYSLOG YANG Model > > Authors : Clyde Wildes > > Kiran Koushik > > Filename : draft-ietf-netmod-syslog-model-07.txt > > Pages : 34 > > Date : 2016-03-20 > > > >Abstract: > > This document describes a data model for the Syslog protocol which is > > used to convey event notification messages. > > > > > >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-07 > > > >A diff from the previous version is available at: > >https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-07 > > > > > >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 28 12:51:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0898212DB35 for ; Mon, 28 Mar 2016 12:51:02 -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 SA9AwstlxwOQ for ; Mon, 28 Mar 2016 12:50:55 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 F406212DB5E for ; Mon, 28 Mar 2016 12:50:51 -0700 (PDT) Received: by mail-lb0-x22d.google.com with SMTP id bc4so87916597lbc.2 for ; Mon, 28 Mar 2016 12:50:51 -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:date:message-id:subject:from:to :cc; bh=ietApkqm535a0EeKbDY683X6q1aAL5Bfeyk74hTtFrs=; b=Xc3ji+VrhNXDuJ9oJD/RWQJTafIptUHGNOa6NuLqToBQ51hDpL6CsuszHUaAxBZqNC P0W7qRk4QNpMBZCrq70YWhmBJH9GyVppwvSCgV48GqowMpuJKgmkLQofqay+cNdyJD8k bu0VRRz7TKsq185vs+yp38ZtEEiDXu2ksVQqI4xrsrFshICbd2LAmMTqnVwkYLE8P0t7 fpPSW7tswfFqFwT1gxXqBgz3fiSxaBIPJ+O0eLcDYOykzINpYO2ZjiRAgvFiUIKgXpEZ j/S+/rpP40AabuHXPc5dzFb+0H/VAnSoJ6YKpO3SQlyRjD5WvDreJ0erBvHDl2AsQQMY Jheg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ietApkqm535a0EeKbDY683X6q1aAL5Bfeyk74hTtFrs=; b=UzjyBsQoy8X/VxHG/iLimk+CVOTYF8mJUwn9EKWqFzGMuqlc3pkwxwHCTYminED2lE 8jbhebSH7H/IKzjhpmE2hVTV4CgxyIeYRKU9vnkBKmDsF1Byi/w7ceQ4k/D1zkPfzBgF wgdV4uYDoytgbGqXDwJi6LFaOKM04wkc8dtHRRmITXu1xS6p9DNYHvER4szTlaukIJws 537UW+A43KRgNGBPuEYoW6vrIMAaQDXYjnyLz6iFJyfFpw0vdLxMcVyG/sJXf3/Ugzsj azcyR/vpeCd/4Mu+p1xs1QtsQj1pqULAzOO0zH4v5Z4nAeDMa9llwC0vaLgTcvSW0tqE awqA== X-Gm-Message-State: AD7BkJKz4cGIbeon2hw94FoxPI07/Bc66qBE9AnRUPMCvxv9dwJXitAIA9n0Y61tuYkFW/IkpbW4KrkItdu0bg== MIME-Version: 1.0 X-Received: by 10.112.56.43 with SMTP id x11mr8078126lbp.145.1459194650068; Mon, 28 Mar 2016 12:50:50 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Mon, 28 Mar 2016 12:50:50 -0700 (PDT) In-Reply-To: <3f34012c40bc47ff87fe0aa944477979@EMEAWP-EXMB12.corp.brocade.com> References: <3f34012c40bc47ff87fe0aa944477979@EMEAWP-EXMB12.corp.brocade.com> Date: Mon, 28 Mar 2016 12:50:50 -0700 Message-ID: From: Andy Bierman To: William Ivory Content-Type: multipart/alternative; boundary=001a1133a9eac6a158052f213a41 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Query about usage of local-name() in YANG XPATH expressions 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, 28 Mar 2016 19:51:02 -0000 --001a1133a9eac6a158052f213a41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, This was raised as a concern by Lada (see netmod WG email arourd July 2014) The issue is that the expression breaks module containment and will match depending on what other YANG modules are known to the YANG compiler. Andy On Sat, Mar 26, 2016 at 3:08 AM, William Ivory wrote: > Hi, > > From RFC 6087 (YANG Usage Guidelines), section 5.6.2, the following is > noted about the use of the XPATH local-name() function: > > The 'local-name' function SHOULD NOT be used to reference local names > outside of the YANG module defining the must or when expression > containing the 'local-name' function. Example of a local-name > function that should not be used: > > /*[local-name()=3D'foo'] > > However, no explanation is given as to why this is a bad idea. We have a > specific use case where local-name() would appear to allow us to massivel= y > simplify some rather cumbersome must expressions, but I wanted to check I= =E2=80=99m > not missing some =E2=80=98gotcha=E2=80=99 here. Is it simply that relyin= g on a common node > name across multiple modules is generally a bad design as it ties the > modules together, or is there more to it? If so, then in our case this i= s > a reasonable restriction. > > Thanks, > > William > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a1133a9eac6a158052f213a41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This was raised as a concern by Lad= a (see netmod WG email arourd July 2014)

The issue= is that the expression breaks module containment and will match
= depending on what other YANG modules are known to the YANG compiler.
<= div>

Andy


<= div class=3D"gmail_extra">
On Sat, Mar 26, 20= 16 at 3:08 AM, William Ivory <wivory@brocade.com> wrote:
Hi,
=C2=A0
From RFC 6087 (YANG Usage Guidelines), section 5.6.2, the following is= noted about the use of the XPATH local-name() function:
=C2=A0
=C2=A0=C2=A0 The 'local-name' function SHOULD NOT be used to r= eference local names
=C2=A0=C2=A0 outside of the YANG module defining the must or when expr= ession
=C2=A0=C2=A0 containing the 'local-name' function.=C2=A0 Examp= le of a local-name
=C2=A0=C2=A0 function that should not be used:
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /*[local-name()=3D'foo']
=C2=A0
However, no explanation is given as to why this is a bad idea.=C2=A0 W= e have a specific use case where local-name() would appear to allow us to m= assively simplify some rather cumbersome must expressions, but I wanted to = check I=E2=80=99m not missing some =E2=80=98gotcha=E2=80=99 here.=C2=A0 Is it simply that relying on a common node name across multiple modules is = generally a bad design as it ties the modules together, or is there more to= it?=C2=A0 If so, then in our case this is a reasonable restriction.
=C2=A0
Thanks,
=C2=A0
William
=C2=A0

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


--001a1133a9eac6a158052f213a41-- From nobody Mon Mar 28 12:57:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6E312DB32 for ; Mon, 28 Mar 2016 12:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3IW1uAO8Ub4 for ; Mon, 28 Mar 2016 12:57:13 -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 BE76D12D183 for ; Mon, 28 Mar 2016 12:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6360; q=dns/txt; s=iport; t=1459195033; x=1460404633; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=neE9PIfJfdNrD72b0C/e91uRxIPjbmXH+OPJbtv7N18=; b=JW5ZbXRQoii+5nSK4rsuivd9RuIeErttxGELWo4Gg3dYkA8rwkgLjYo9 Dp4rEmMx/DGcZAgyxYVXJNAp8QhannPur79VEu50Bm+4EvHlQzmvQ9m4K uTmAvmt1wtsLrLWxw76R/CPk4UzHgWEwU3OYj4VO/O5RWhsEmcHWk4jRQ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQCmi/lW/49dJa1dgy5TfQa6bgENg?= =?us-ascii?q?XAXCoUiSgIcgQc4FAEBAQEBAQFkJ4RBAQEBBAEBASAROAIIAwwEAgEIFQECAgI?= =?us-ascii?q?mAgICJQsVEAIEAQ0FiCYBDq9VkBMBAQEBAQEBAQEBAQEBAQEBAQEBAQEVfIUig?= =?us-ascii?q?XMIgkmEOoMCK4IrAQSXYQGFcIgVgWZNg3+DKIQWgRuDdIsVAR4BAUKCAxmBSWy?= =?us-ascii?q?HfAF9AQEB?= X-IronPort-AV: E=Sophos;i="5.24,408,1454976000"; d="scan'208";a="85640354" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2016 19:57:12 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u2SJvCLZ014350 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Mar 2016 19:57:12 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.1104.5; Mon, 28 Mar 2016 14:57:12 -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.1104.009; Mon, 28 Mar 2016 14:57:11 -0500 From: "Clyde Wildes (cwildes)" To: "t.petch" , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.txt Thread-Index: AQHRgrqqbdiJAOKHdkK+l/uGNO0H6J9ijKMAgAyYBbqAAAxjgA== Date: Mon, 28 Mar 2016 19:57:11 +0000 Message-ID: <0CA65B1D-6699-42BC-8FD9-1EBEB692EE55@cisco.com> References: <20160320151006.2321.64042.idtracker@ietfa.amsl.com> <01cb01d18914$ab13ae40$4001a8c0@gateway.2wire.net> In-Reply-To: <01cb01d18914$ab13ae40$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: [171.69.106.41] Content-Type: text/plain; charset="utf-8" Content-ID: <65BA45657CBC4B40A4C075D3FD016808@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.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, 28 Mar 2016 19:57:16 -0000 VG9tLA0KDQpJIHVuZGVyc3RhbmQgeW91ciBjb25jZXJuIHdpdGggdGhlIGNvbXBsZXhpdHkgb2Yg dGhlIG1vZGVsLiBUaGF0IHNhaWQsIGFzIHdlIHByb2dyZXNzZWQgd2UgZW5jb3VudGVyZWQgc29t ZSB2ZW5kb3JzIGFuZCBzb21lIElFVEYgUkZDIGF1dGhvcnMgd2hvIHJlcXVlc3RlZCB0aGF0IGEg cGFydGljdWxhciBmZWF0dXJlIG9mIGludGVyZXN0IGJlIGluY2x1ZGVkLiBXZSBmZWx0IHRoYXQg d2UgaGFkIHRvIG1ha2UgZmVhdHVyZXMgdGhhdCB3ZXJlIG5vdCBpbXBsZW1lbnRlZCBieSB0d28g b3IgbW9yZSB2ZW5kb3JzIGEgWUFORyBmZWF0dXJlIHRvIGdhaW4gYWNjZXB0YW5jZS4gV2hpY2gg aXMgcHJlZmVycmVkIGluIHRoaXMgY2FzZTogYXVnbWVudGF0aW9uIHRvIGFkZCBmZWF0dXJlczsg ZGV2aWF0aW9uIG5vdC1zdXBwb3J0ZWQgc3RhdGVtZW50cyB0byByZW1vdmUgZmVhdHVyZXM7IG9y IHRoZSB1c2Ugb2YgZmVhdHVyZSBzdGF0ZW1lbnRzPyBEdXJpbmcgZWFybHkgbW9kZWwgZGV2ZWxv cG1lbnQgb3VyIFlBTkcgZG9jdG9yIGFkdmlzb3IgYWR2b2NhdGVkIHVzaW5nIGZlYXR1cmUuDQoN CkkgcmVhZCB5b3VyIHBvc3Qgb24gImZlYXR1cmVzIC0gYSBDYXJ0ZXNpYW4gZXhwbG9zaW9uIiBw b3N0LiBOb3RlIHRoYXQgaW4gdGhlIGNhc2Ugb2YgdGhlIGxhdGVzdCBpZXRmLXN5c2xvZyBtb2Rl bCBmb3VyIG9mIHRoZSBmZWF0dXJlcyBhcmUgbmVzdGVkIHN1Y2ggdGhhdCB0aGV5IGFyZSBub3Qg ZW5jb3VudGVyZWQgdW5sZXNzIGEgaGlnaGVyIGxldmVsIGZlYXR1cmUgaXMgZW5hYmxlZC4gDQoN CldoYXQgd291bGQgeW91ciBwcmVmZXJlbmNlIGJlOg0KLSByZW1vdmUgdGhlIGZlYXR1cmUgc3Rh dGVtZW50cyBhbmQgYXNrIHZlbmRvcnMgdG8gc3VwcGx5IGRldmlhdGlvbiBzdGF0ZW1lbnRzIGZv ciB0aG9zZSBsZWF2ZXMgbm90IGltcGxlbWVudGVkDQotIHJlbW92ZSBhbGwgbGVhdmVzIGNvbmRp dGlvbmVkIGJ5IGZlYXR1cmUgYW5kIGFzayB2ZW5kb3JzIHRvIHN1cHBseSBhbm5vdGF0ZWQgbW9k ZWxzIHdpdGggYXVnbWVudGF0aW9uDQotIGxlYXZlIHRoaW5ncyBhcyB0aGV5IGFyZQ0KDQpJdCBz b3VuZHMgbGlrZSBCIHdvdWxkIGJlIHlvdXIgcHJlZmVyZW5jZT8NCg0KVGhhbmtzLA0KDQpDbHlk ZQ0KDQoNCg0KDQoNCk9uIDMvMjgvMTYsIDEwOjA5IEFNLCAidC5wZXRjaCIgPGlldGZjQGJ0Y29u bmVjdC5jb20+IHdyb3RlOg0KDQo+DQo+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZy b206ICJDbHlkZSBXaWxkZXMgKGN3aWxkZXMpIiA8Y3dpbGRlc0BjaXNjby5jb20+DQo+VG86IDxu ZXRtb2RAaWV0Zi5vcmc+DQo+Q2M6ICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5jb20+ OyAidC5wZXRjaCINCj48aWV0ZmNAYnRjb25uZWN0LmNvbT47ICJLaXJhbiBLb3VzaGlrIEFncmFo YXJhIFNyZWVuaXZhc2EgKGtrb3VzaGlrKSINCj48a2tvdXNoaWtAY2lzY28uY29tPg0KPlNlbnQ6 IFN1bmRheSwgTWFyY2ggMjAsIDIwMTYgNzo1MyBQTQ0KPg0KPj4gSGksDQo+Pg0KPj4gVGhpcyBy ZXZpc2lvbiBpbmNvcnBvcmF0ZXMgZmVlZGJhY2sgZnJvbSBNYXJ0aW4gQmpvcmtsdW5rICgxOQ0K PmNvbW1lbnRzKSBhbmQgVG9tIFBldGNoICgxMCBjb21tZW50cykuIFRoYW5rcyB0byBib3RoIG9m IHlvdSBmb3IgeW91cg0KPnZhbHVhYmxlIGZlZWRiYWNrIQ0KPj4NCj4+IFJlZ2FyZGluZyBUb20n cyBjb21tZW50IC0gIjQuMSBXaGF0IGEgbG90IG9mIGZlYXR1cmVzPyAgQWdhaW4sIG1ha2VzDQo+ dGhpbmdzIG1vcmUgY29tcGxleCwgbW9yZSBlcnJvciBwcm9uZSAtIGFyZSB0aGV5IGFsbCByZWFs bHkgbmVlZGVkPyI6IFdlDQo+c3RhcnRlZCB0aGUgZHJhZnQgdHdvIHllYXJzIGFnbyBhbmQgaXQg aGFzIGV2b2x2ZWQgZnJvbSBmZWVkYmFjaw0KPnJlY2VpdmVkIGZyb20gYWxsIG9mIHRoZSBmb2xr cyB0aGF0IGFwcGVhciBpbiB0aGUgQWNrbm93bGVkZ2VtZW50cw0KPnNlY3Rpb24uIFBsZWFzZSBy ZXZpZXcgdGhlIGN1cnJlbnQgZHJhZnQgd2hlcmUgSSBiZWxpZXZlIHRoYXQgSSBhZGRyZXNzDQo+ YWxsIG9mIHlvdXIgY29tbWVudHMgZXhjZXB0IHBvc3NpYmx5IHRoaXMgb25lLiBUaGUgdHJhZGVv ZmYgaXMgdG8gbGVhdmUNCj50aGUgZmVhdHVyZSBzcGVjaWZpYyBmdW5jdGlvbmFsaXR5IG91dCBv ZiB0aGUgZHJhZnQgYW5kIGxlYXZlIGl0IHRvIHRoZQ0KPmltcGxlbWVudGF0aW9ucyB0byBhZGQg YmFjayB0aHJvdWdoIGF1Z21lbnRhdGlvbi4gVGhhdCBzYWlkIG1vc3Qgb2YgdGhlDQo+ZmVhdHVy ZXMgdGhhdCBhcmUgY2FsbGVkIG91dCBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgYnkgYXQgbGVhc3Qg dHdvDQo+dmVuZG9ycywgYnV0IG5vdCBhbGwsIGxlYWRpbmcgdG8gdGhlIGZlYXR1cmUgZGVzaWdu YXRpb24uDQo+DQo+Q2x5ZGUNCj4NCj5ZZWVlZXM7IEkgZGlkIGEgc2VwYXJhdGUgcG9zdCBvbiB0 aGUgdG9waWMgdGhpbmtpbmcgdGhhdCBhbiBpbXBsZW1lbnRvcg0KPm1pZ2h0IHNoYXJlIG15IGNv bmNlcm5zIGFib3V0IHRoZSBsYXJnZSBudW1iZXIgb2YgcG9zc2libGUgdmFyaWF0aW9ucyBpbg0K PmFuIGltcGxlbWVudGF0aW9uIHdoZW4gdGhlcmUgd2VyZSBhIGxhcmdlIG51bWJlciBvZiBmZWF0 dXJlcywgdGhhdA0KPnBlcmhhcHMgdGhlcmUgc2hvdWxkIGJlIGd1aWRlbGluZXMgYWJvdXQgaXQs IGJ1dCBpdCBkaWQgbm90IGdldCBhbnkNCj50cmFjdGlvbi4gIEl0IGlzIG9uZSB0aG9zZSBpc3N1 ZXMgd2hlcmUgSSB0aGluaywgaW4gYSB5ZWFyIG9yIHR3bydzDQo+dGltZSwgb3RoZXJzIG1pZ2h0 IHNoYXJlIG15IGNvbmNlcm4sIGJ1dCBub3QgeWV0Oi0oLg0KPg0KPkkgZG9uJ3QgZG91YnQgdGhh dCB0aGUgdmFyaWF0aW9uIGV4aXN0cyBhbmQgbmVlZHMgbW9kZWxsaW5nLCBqdXN0IHRoYXQNCj5z dWNoIHVzZSBvZiAnZmVhdHVyZXMnIG1heSBoYXZlIHVuZm9ydHVuYXRlIGNvbnNlcXVlbmNlcyAt IGJ1dCBJIGhhdmUgbm8NCj5hbHRlcm5hdGl2ZSBzdWdnZXN0aW9uLg0KPg0KPlRvbSBQZXRjaA0K Pg0KPj4gVGhhbmtzLA0KPj4NCj4+IENseWRlDQo+Pg0KPj4NCj4+DQo+PiBPbiAzLzIwLzE2LCA4 OjEwIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciDQo+ PG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+IHdyb3RlOg0KPj4NCj4+ID4NCj4+ID5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj5kaXJlY3Rvcmllcy4NCj4+ ID5UaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBORVRDT05GIERhdGEgTW9kZWxpbmcg TGFuZ3VhZ2Ugb2YNCj50aGUgSUVURi4NCj4+ID4NCj4+ID4gICAgICAgIFRpdGxlICAgICAgICAg ICA6IFNZU0xPRyBZQU5HIE1vZGVsDQo+PiA+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBDbHlk ZSBXaWxkZXMNCj4+ID4gICAgICAgICAgICAgICAgICAgICAgICAgIEtpcmFuIEtvdXNoaWsNCj4+ ID4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTA3LnR4 dA0KPj4gPiBQYWdlcyAgICAgICAgICAgOiAzNA0KPj4gPiBEYXRlICAgICAgICAgICAgOiAyMDE2 LTAzLTIwDQo+PiA+DQo+PiA+QWJzdHJhY3Q6DQo+PiA+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYSBkYXRhIG1vZGVsIGZvciB0aGUgU3lzbG9nIHByb3RvY29sIHdoaWNoDQo+aXMNCj4+ID4g ICB1c2VkIHRvIGNvbnZleSBldmVudCBub3RpZmljYXRpb24gbWVzc2FnZXMuDQo+PiA+DQo+PiA+ DQo+PiA+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQo+PiA+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2Qt c3lzbG9nLW1vZGVsLw0KPj4gPg0KPj4gPlRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24g YXZhaWxhYmxlIGF0Og0KPj4gPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW5ldG1vZC1zeXNsb2ctbW9kZWwtMDcNCj4+ID4NCj4+ID5BIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0wNw0KPj4gPg0KPj4gPg0K Pj4gPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mDQo+c3VibWlzc2lvbg0KPj4gPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+PiA+DQo+PiA+SW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4g PmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+PiA+DQo+PiA+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5uZXRtb2QgbWFpbGlu ZyBsaXN0DQo+PiA+bmV0bW9kQGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QNCj4+DQo+DQo= From nobody Mon Mar 28 12:59:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CB212DB51 for ; Mon, 28 Mar 2016 12:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 71kiqKDVvfGC for ; Mon, 28 Mar 2016 12:59:49 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD63312DB46 for ; Mon, 28 Mar 2016 12:59:49 -0700 (PDT) Received: from pps.filterd (m0048193.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u2SJfNTx024721; Mon, 28 Mar 2016 12:59:49 -0700 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 21ws5862ht-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 28 Mar 2016 12:59:49 -0700 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Mar 2016 13:59:47 -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.1104.5; Mon, 28 Mar 2016 21:59:45 +0200 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.1104.000; Mon, 28 Mar 2016 21:59:45 +0200 From: William Ivory To: Andy Bierman Thread-Topic: [netmod] Query about usage of local-name() in YANG XPATH expressions Thread-Index: AdGHRklYYu2WBbSoTmy8zANMZSgp7gB1BQUAAARpIrA= Date: Mon, 28 Mar 2016 19:59:17 +0000 Deferred-Delivery: Mon, 28 Mar 2016 19:59:03 +0000 Message-ID: <7f1e5116ae024a9cbe4fb8be57333b1f@EMEAWP-EXMB12.corp.brocade.com> References: <3f34012c40bc47ff87fe0aa944477979@EMEAWP-EXMB12.corp.brocade.com> In-Reply-To: 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: [10.252.48.10] Content-Type: multipart/alternative; boundary="_000_7f1e5116ae024a9cbe4fb8be57333b1fEMEAWPEXMB12corpbrocade_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-28_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603280288 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Query about usage of local-name() in YANG XPATH expressions 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, 28 Mar 2016 19:59:51 -0000 --_000_7f1e5116ae024a9cbe4fb8be57333b1fEMEAWPEXMB12corpbrocade_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhhbmtzLiAgU28gaWYgd2UgaGF2ZSBhIHRpZ2h0bHkgY29udHJvbGxlZCBz ZXQgb2YgWUFORyBmaWxlcywgYW5kIHJlc3RyaWN0IHVzYWdlIHRvIGEgc3BlY2lmaWMgdXNlIGNh c2Ugd2hlcmUgd2UgaGF2ZSBhIHNldCBvZiBub2RlcyBhY3Jvc3MgbXVsdGlwbGUgbW9kdWxlcyB3 aXRoIHRoZSBzYW1lIG5hbWUsIHdlIHNob3VsZCBiZSBmaW5lLg0KDQpXaWxsaWFtDQoNCkZyb206 IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IDI4IE1hcmNo IDIwMTYgMjA6NTENClRvOiBXaWxsaWFtIEl2b3J5IDx3aXZvcnlAQnJvY2FkZS5jb20+DQpDYzog bmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gUXVlcnkgYWJvdXQgdXNhZ2Ug b2YgbG9jYWwtbmFtZSgpIGluIFlBTkcgWFBBVEggZXhwcmVzc2lvbnMNCg0KSGksDQoNClRoaXMg d2FzIHJhaXNlZCBhcyBhIGNvbmNlcm4gYnkgTGFkYSAoc2VlIG5ldG1vZCBXRyBlbWFpbCBhcm91 cmQgSnVseSAyMDE0KQ0KDQpUaGUgaXNzdWUgaXMgdGhhdCB0aGUgZXhwcmVzc2lvbiBicmVha3Mg bW9kdWxlIGNvbnRhaW5tZW50IGFuZCB3aWxsIG1hdGNoDQpkZXBlbmRpbmcgb24gd2hhdCBvdGhl ciBZQU5HIG1vZHVsZXMgYXJlIGtub3duIHRvIHRoZSBZQU5HIGNvbXBpbGVyLg0KDQoNCkFuZHkN Cg0KDQoNCk9uIFNhdCwgTWFyIDI2LCAyMDE2IGF0IDM6MDggQU0sIFdpbGxpYW0gSXZvcnkgPHdp dm9yeUBicm9jYWRlLmNvbTxtYWlsdG86d2l2b3J5QGJyb2NhZGUuY29tPj4gd3JvdGU6DQpIaSwN Cg0KRnJvbSBSRkMgNjA4NyAoWUFORyBVc2FnZSBHdWlkZWxpbmVzKSwgc2VjdGlvbiA1LjYuMiwg dGhlIGZvbGxvd2luZyBpcyBub3RlZCBhYm91dCB0aGUgdXNlIG9mIHRoZSBYUEFUSCBsb2NhbC1u YW1lKCkgZnVuY3Rpb246DQoNCiAgIFRoZSAnbG9jYWwtbmFtZScgZnVuY3Rpb24gU0hPVUxEIE5P VCBiZSB1c2VkIHRvIHJlZmVyZW5jZSBsb2NhbCBuYW1lcw0KICAgb3V0c2lkZSBvZiB0aGUgWUFO RyBtb2R1bGUgZGVmaW5pbmcgdGhlIG11c3Qgb3Igd2hlbiBleHByZXNzaW9uDQogICBjb250YWlu aW5nIHRoZSAnbG9jYWwtbmFtZScgZnVuY3Rpb24uICBFeGFtcGxlIG9mIGEgbG9jYWwtbmFtZQ0K ICAgZnVuY3Rpb24gdGhhdCBzaG91bGQgbm90IGJlIHVzZWQ6DQoNCiAgICAgIC8qW2xvY2FsLW5h bWUoKT0nZm9vJ10NCg0KSG93ZXZlciwgbm8gZXhwbGFuYXRpb24gaXMgZ2l2ZW4gYXMgdG8gd2h5 IHRoaXMgaXMgYSBiYWQgaWRlYS4gIFdlIGhhdmUgYSBzcGVjaWZpYyB1c2UgY2FzZSB3aGVyZSBs b2NhbC1uYW1lKCkgd291bGQgYXBwZWFyIHRvIGFsbG93IHVzIHRvIG1hc3NpdmVseSBzaW1wbGlm eSBzb21lIHJhdGhlciBjdW1iZXJzb21lIG11c3QgZXhwcmVzc2lvbnMsIGJ1dCBJIHdhbnRlZCB0 byBjaGVjayBJ4oCZbSBub3QgbWlzc2luZyBzb21lIOKAmGdvdGNoYeKAmSBoZXJlLiAgSXMgaXQg c2ltcGx5IHRoYXQgcmVseWluZyBvbiBhIGNvbW1vbiBub2RlIG5hbWUgYWNyb3NzIG11bHRpcGxl IG1vZHVsZXMgaXMgZ2VuZXJhbGx5IGEgYmFkIGRlc2lnbiBhcyBpdCB0aWVzIHRoZSBtb2R1bGVz IHRvZ2V0aGVyLCBvciBpcyB0aGVyZSBtb3JlIHRvIGl0PyAgSWYgc28sIHRoZW4gaW4gb3VyIGNh c2UgdGhpcyBpcyBhIHJlYXNvbmFibGUgcmVzdHJpY3Rpb24uDQoNClRoYW5rcywNCg0KV2lsbGlh bQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpu ZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9Q3dNRmFRJmM9SUxfWHFRV09qdWJnZnFJTmkyalR6 ZyZyPUdCeUxlZzlqWnZPdl9BbGdCbzl1dmREcnhpemxPUjdsX1NuVFhvd3lKVTgmbT1WWkdCMk5r YUU5LS02OG1vUGxnWk1fYWcxQ2dLdmpKcVN3d1oyaXcxZ2lvJnM9N0p1OTVYYk5LZGxnNHRQWkc5 YWhTZU1IVVRfbHFHRlB0aVp4Y1hldlR4dyZlPT4NCg0K --_000_7f1e5116ae024a9cbe4fb8be57333b1fEMEAWPEXMB12corpbrocade_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgQW5keSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlRoYW5rcy4mbmJzcDsgU28gaWYgd2UgaGF2ZSBhIHRpZ2h0bHkgY29udHJv bGxlZCBzZXQgb2YgWUFORyBmaWxlcywgYW5kIHJlc3RyaWN0IHVzYWdlIHRvIGEgc3BlY2lmaWMg dXNlIGNhc2Ugd2hlcmUgd2UgaGF2ZSBhIHNldCBvZiBub2Rlcw0KIGFjcm9zcyBtdWx0aXBsZSBt b2R1bGVzIHdpdGggdGhlIHNhbWUgbmFtZSwgd2Ugc2hvdWxkIGJlIGZpbmUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XaWxsaWFtPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5keSBCaWVybWFuIFtt YWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI4IE1hcmNoIDIw MTYgMjA6NTE8YnI+DQo8Yj5Ubzo8L2I+IFdpbGxpYW0gSXZvcnkgJmx0O3dpdm9yeUBCcm9jYWRl LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW25ldG1vZF0gUXVlcnkgYWJvdXQgdXNhZ2Ugb2YgbG9jYWwtbmFtZSgpIGluIFlB TkcgWFBBVEggZXhwcmVzc2lvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg d2FzIHJhaXNlZCBhcyBhIGNvbmNlcm4gYnkgTGFkYSAoc2VlIG5ldG1vZCBXRyBlbWFpbCBhcm91 cmQgSnVseSAyMDE0KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgaXNzdWUgaXMgdGhhdCB0aGUgZXhwcmVzc2lvbiBicmVha3MgbW9kdWxl IGNvbnRhaW5tZW50IGFuZCB3aWxsIG1hdGNoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kZXBlbmRpbmcgb24gd2hhdCBvdGhlciBZQU5HIG1vZHVs ZXMgYXJlIGtub3duIHRvIHRoZSBZQU5HIGNvbXBpbGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIE1hciAyNiwgMjAxNiBhdCAz OjA4IEFNLCBXaWxsaWFtIEl2b3J5ICZsdDs8YSBocmVmPSJtYWlsdG86d2l2b3J5QGJyb2NhZGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+d2l2b3J5QGJyb2NhZGUuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tIFJGQyA2MDg3IChZQU5HIFVzYWdlIEd1aWRlbGluZXMpLCBzZWN0 aW9uIDUuNi4yLCB0aGUgZm9sbG93aW5nIGlzIG5vdGVkIGFib3V0IHRoZSB1c2Ugb2YgdGhlIFhQ QVRIIGxvY2FsLW5hbWUoKSBmdW5jdGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IFRoZSAnbG9jYWwtbmFtZScgZnVuY3Rpb24gU0hP VUxEIE5PVCBiZSB1c2VkIHRvIHJlZmVyZW5jZSBsb2NhbCBuYW1lczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7IG91dHNpZGUgb2YgdGhlIFlBTkcgbW9kdWxlIGRlZmluaW5nIHRoZSBt dXN0IG9yIHdoZW4gZXhwcmVzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IGNv bnRhaW5pbmcgdGhlICdsb2NhbC1uYW1lJyBmdW5jdGlvbi4mbmJzcDsgRXhhbXBsZSBvZiBhIGxv Y2FsLW5hbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBmdW5jdGlvbiB0aGF0IHNo b3VsZCBub3QgYmUgdXNlZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8qW2xvY2FsLW5hbWUoKT0nZm9v J108bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SG93ZXZlciwg bm8gZXhwbGFuYXRpb24gaXMgZ2l2ZW4gYXMgdG8gd2h5IHRoaXMgaXMgYSBiYWQgaWRlYS4mbmJz cDsgV2UgaGF2ZSBhIHNwZWNpZmljIHVzZSBjYXNlIHdoZXJlIGxvY2FsLW5hbWUoKSB3b3VsZCBh cHBlYXIgdG8gYWxsb3cgdXMgdG8gbWFzc2l2ZWx5IHNpbXBsaWZ5IHNvbWUgcmF0aGVyIGN1bWJl cnNvbWUNCiBtdXN0IGV4cHJlc3Npb25zLCBidXQgSSB3YW50ZWQgdG8gY2hlY2sgSeKAmW0gbm90 IG1pc3Npbmcgc29tZSDigJhnb3RjaGHigJkgaGVyZS4mbmJzcDsgSXMgaXQgc2ltcGx5IHRoYXQg cmVseWluZyBvbiBhIGNvbW1vbiBub2RlIG5hbWUgYWNyb3NzIG11bHRpcGxlIG1vZHVsZXMgaXMg Z2VuZXJhbGx5IGEgYmFkIGRlc2lnbiBhcyBpdCB0aWVzIHRoZSBtb2R1bGVzIHRvZ2V0aGVyLCBv ciBpcyB0aGVyZSBtb3JlIHRvIGl0PyZuYnNwOyBJZiBzbywgdGhlbiBpbiBvdXIgY2FzZQ0KIHRo aXMgaXMgYSByZWFzb25hYmxlIHJlc3RyaWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM4ODg4 ODgiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij5XaWxsaWFtPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM4ODg4ODgiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRt b2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX25ldG1vZCZhbXA7ZD1Dd01GYVEmYW1wO2M9SUxfWHFRV09qdWJnZnFJ TmkyalR6ZyZhbXA7cj1HQnlMZWc5alp2T3ZfQWxnQm85dXZkRHJ4aXpsT1I3bF9TblRYb3d5SlU4 JmFtcDttPVZaR0IyTmthRTktLTY4bW9QbGdaTV9hZzFDZ0t2akpxU3d3WjJpdzFnaW8mYW1wO3M9 N0p1OTVYYk5LZGxnNHRQWkc5YWhTZU1IVVRfbHFHRlB0aVp4Y1hldlR4dyZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_7f1e5116ae024a9cbe4fb8be57333b1fEMEAWPEXMB12corpbrocade_-- From nobody Mon Mar 28 13:32:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC7E12D54D for ; Mon, 28 Mar 2016 13:32:39 -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 MEFlfKiBSQvv for ; Mon, 28 Mar 2016 13:32:36 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::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 4EDCD12DB70 for ; Mon, 28 Mar 2016 13:32:36 -0700 (PDT) Received: by mail-lb0-x22c.google.com with SMTP id u8so12343116lbk.0 for ; Mon, 28 Mar 2016 13:32:36 -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:date:message-id:subject:from:to :cc; bh=o0vMmXEwVX3/1rfrcjz1AtzMkhOdujNVUPnPiLhOrI8=; b=IdCFH4r3EhGygIAc2C3os4exX4pedQaXcqfkVZZyhYlTxNVIPBWSbY2zqP5Bu0d2wj 39WKMy9g2/WFkvs83By+ztqUxM0XE3LG3Ezssss+OuyShjCWiXXyLPC4wRm3gYTEbFDA Eh+RbIlGNSppH5GmrYmZQT7V5XeymAvPcAYlK8x4RDncLqov0Va6389dzB6gzt+lS354 bdHJjUwxNnfCFQjI5urgkCq6N4lJKw4b+Wcufhcd7FfKomvkB10NFKZMOZjqlO8dyx5T qB8okGTlN89Z5Yym/gTIbHm/kvgveWhuYGf//h58A+4Z0Hts1nGvXE4URLt47LfpVwD6 ZWxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=o0vMmXEwVX3/1rfrcjz1AtzMkhOdujNVUPnPiLhOrI8=; b=Fht3K6xCld6jIOs4aFpXFixzqkbmPtqXn9gReuB4PjWZKdcvrFu6YhPrtEfGxqfi6L zgQPIoR/7w84ibfudUNFTcq6WeMth0cNkUq4d/V6HFXi/O+R/QR/sBM62TvUWYXz6vrI IDlZqysMk2cX55yfLhkvzG+DxZXy4a+gH+cAs8CI0/+v7vh3FpQUADA4g1QRJxJY08Wi aVVd8nfqd1EXKhnN9N7rraq+QBFFDXppfrakBVWuDTBoJUuO+bKoeyUdrIvQxJQocTsl iZJ/FcEOdrk2VOJbu6zNyz97il2tHOgvijYpXT4UV9YFzWI2ji44TYWjE1c9SSVyMUA3 Dsxw== X-Gm-Message-State: AD7BkJKT5NBB6B+8rCm1Oxk2riXeWno1rN7ekAdNjSFYqreLftrInhLmbQngw2h7IKMNwKLMxus3Srmj7D9DZw== MIME-Version: 1.0 X-Received: by 10.112.147.101 with SMTP id tj5mr8740438lbb.119.1459197154478; Mon, 28 Mar 2016 13:32:34 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Mon, 28 Mar 2016 13:32:34 -0700 (PDT) In-Reply-To: <0CA65B1D-6699-42BC-8FD9-1EBEB692EE55@cisco.com> References: <20160320151006.2321.64042.idtracker@ietfa.amsl.com> <01cb01d18914$ab13ae40$4001a8c0@gateway.2wire.net> <0CA65B1D-6699-42BC-8FD9-1EBEB692EE55@cisco.com> Date: Mon, 28 Mar 2016 13:32:34 -0700 Message-ID: From: Andy Bierman To: "Clyde Wildes (cwildes)" Content-Type: multipart/alternative; boundary=047d7b3a8bd20ce21a052f21d0d9 Archived-At: Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.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, 28 Mar 2016 20:32:39 -0000 --047d7b3a8bd20ce21a052f21d0d9 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 28, 2016 at 12:57 PM, Clyde Wildes (cwildes) wrote: > Tom, > > I understand your concern with the complexity of the model. That said, as > we progressed we encountered some vendors and some IETF RFC authors who > requested that a particular feature of interest be included. We felt that > we had to make features that were not implemented by two or more vendors a > YANG feature to gain acceptance. Which is preferred in this case: > augmentation to add features; deviation not-supported statements to remove > features; or the use of feature statements? During early model development > our YANG doctor advisor advocated using feature. > > I read your post on "features - a Cartesian explosion" post. Note that in > the case of the latest ietf-syslog model four of the features are nested > such that they are not encountered unless a higher level feature is enabled. > > What would your preference be: > - remove the feature statements and ask vendors to supply deviation > statements for those leaves not implemented > - remove all leaves conditioned by feature and ask vendors to supply > annotated models with augmentation > - leave things as they are > > It sounds like B would be your preference? > > I agree with Tom. IMO if the functionality is not supported by at least 2 vendors then remove it from the standard. The vendor can write a module that augments the base module. Thanks, > > Clyde > > Andy > > > > > On 3/28/16, 10:09 AM, "t.petch" wrote: > > > > >----- Original Message ----- > >From: "Clyde Wildes (cwildes)" > >To: > >Cc: "Martin Bjorklund" ; "t.petch" > >; "Kiran Koushik Agrahara Sreenivasa (kkoushik)" > > > >Sent: Sunday, March 20, 2016 7:53 PM > > > >> Hi, > >> > >> This revision incorporates feedback from Martin Bjorklunk (19 > >comments) and Tom Petch (10 comments). Thanks to both of you for your > >valuable feedback! > >> > >> Regarding Tom's comment - "4.1 What a lot of features? Again, makes > >things more complex, more error prone - are they all really needed?": We > >started the draft two years ago and it has evolved from feedback > >received from all of the folks that appear in the Acknowledgements > >section. Please review the current draft where I believe that I address > >all of your comments except possibly this one. The tradeoff is to leave > >the feature specific functionality out of the draft and leave it to the > >implementations to add back through augmentation. That said most of the > >features that are called out have been implemented by at least two > >vendors, but not all, leading to the feature designation. > > > >Clyde > > > >Yeeees; I did a separate post on the topic thinking that an implementor > >might share my concerns about the large number of possible variations in > >an implementation when there were a large number of features, that > >perhaps there should be guidelines about it, but it did not get any > >traction. It is one those issues where I think, in a year or two's > >time, others might share my concern, but not yet:-(. > > > >I don't doubt that the variation exists and needs modelling, just that > >such use of 'features' may have unfortunate consequences - but I have no > >alternative suggestion. > > > >Tom Petch > > > >> Thanks, > >> > >> Clyde > >> > >> > >> > >> On 3/20/16, 8:10 AM, "netmod on behalf of 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 : SYSLOG YANG Model > >> > Authors : Clyde Wildes > >> > Kiran Koushik > >> > Filename : draft-ietf-netmod-syslog-model-07.txt > >> > Pages : 34 > >> > Date : 2016-03-20 > >> > > >> >Abstract: > >> > This document describes a data model for the Syslog protocol which > >is > >> > used to convey event notification messages. > >> > > >> > > >> >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-07 > >> > > >> >A diff from the previous version is available at: > >> >https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-07 > >> > > >> > > >> >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 > --047d7b3a8bd20ce21a052f21d0d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 28, 2016 at 12:57 PM, Clyde Wildes (cwildes) <cwildes@cisc= o.com> wrote:
Tom,

I understand your concern with the complexity of the model. That said, as w= e progressed we encountered some vendors and some IETF RFC authors who requ= ested that a particular feature of interest be included. We felt that we ha= d to make features that were not implemented by two or more vendors a YANG = feature to gain acceptance. Which is preferred in this case: augmentation t= o add features; deviation not-supported statements to remove features; or t= he use of feature statements? During early model development our YANG docto= r advisor advocated using feature.

I read your post on "features - a Cartesian explosion" post. Note= that in the case of the latest ietf-syslog model four of the features are = nested such that they are not encountered unless a higher level feature is = enabled.

What would your preference be:
- remove the feature statements and ask vendors to supply deviation stateme= nts for those leaves not implemented
- remove all leaves conditioned by feature and ask vendors to supply annota= ted models with augmentation
- leave things as they are

It sounds like B would be your preference?


I agree with Tom.
IMO if the= functionality is not supported by at least 2 vendors then
remove= it from the standard.=C2=A0 The vendor can write a module
that a= ugments the =C2=A0base module.



=
Thanks,

Clyde



Andy
=C2=A0




On 3/28/16, 10:09 AM, "t.petch" <ietfc@btconnect.com> wrote:

>
>----- Original Message -----
>From: "Clyde Wildes (cwildes)" <cwildes@cisco.com>
>To: <netmod@ietf.org>
>Cc: "Martin Bjorklund" <= mbj@tail-f.com>; "t.petch"
><ietfc@btconnect.com>;= "Kiran Koushik Agrahara Sreenivasa (kkoushik)"
><kkoushik@cisco.com> >Sent: Sunday, March 20, 2016 7:53 PM
>
>> Hi,
>>
>> This revision incorporates feedback from Martin Bjorklunk (19
>comments) and Tom Petch (10 comments). Thanks to both of you for your >valuable feedback!
>>
>> Regarding Tom's comment - "4.1 What a lot of features?=C2= =A0 Again, makes
>things more complex, more error prone - are they all really needed?&quo= t;: We
>started the draft two years ago and it has evolved from feedback
>received from all of the folks that appear in the Acknowledgements
>section. Please review the current draft where I believe that I address=
>all of your comments except possibly this one. The tradeoff is to leave=
>the feature specific functionality out of the draft and leave it to the=
>implementations to add back through augmentation. That said most of the=
>features that are called out have been implemented by at least two
>vendors, but not all, leading to the feature designation.
>
>Clyde
>
>Yeeees; I did a separate post on the topic thinking that an implementor=
>might share my concerns about the large number of possible variations i= n
>an implementation when there were a large number of features, that
>perhaps there should be guidelines about it, but it did not get any
>traction.=C2=A0 It is one those issues where I think, in a year or two&= #39;s
>time, others might share my concern, but not yet:-(.
>
>I don't doubt that the variation exists and needs modelling, just t= hat
>such use of 'features' may have unfortunate consequences - but = I have no
>alternative suggestion.
>
>Tom Petch
>
>> Thanks,
>>
>> Clyde
>>
>>
>>
>> On 3/20/16, 8:10 AM, "netmod on behalf of internet-drafts@ietf.org"
><netmod-bounces@ietf.org<= /a> on behalf of internet-draft= s@ietf.org> wrote:
>>
>> >
>> >A New Internet-Draft is available from the on-line Internet-Dr= afts
>directories.
>> >This draft is a work item of the NETCONF Data Modeling Languag= e of
>the IETF.
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: SYSLOG YANG Model
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: Clyde Wildes
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Kiran Koushik
>> > Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-netmod-syslo= g-model-07.txt
>> > Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 34
>> > Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2016-03-20 >> >
>> >Abstract:
>> >=C2=A0 =C2=A0This document describes a data model for the Sysl= og protocol which
>is
>> >=C2=A0 =C2=A0used to convey event notification messages.
>> >
>> >
>> >The IETF datatracker status page for this draft is:
>> >https://datatracker.iet= f.org/doc/draft-ietf-netmod-syslog-model/
>> >
>> >There's also a htmlized version available at:
>> >https://tools.ietf.org/htm= l/draft-ietf-netmod-syslog-model-07
>> >
>> >A diff from the previous version is available at:
>> >https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-netmod-syslog-model-07
>> >
>> >
>> >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/net= mod
>>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--047d7b3a8bd20ce21a052f21d0d9-- From nobody Mon Mar 28 13:35:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D3512DB70 for ; Mon, 28 Mar 2016 13:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 MPNKyGqSU5vk for ; Mon, 28 Mar 2016 13:35:40 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5945212DBEE for ; Mon, 28 Mar 2016 13:35:40 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id e133so43546147lfe.3 for ; Mon, 28 Mar 2016 13:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=nEy4esKgjxuW/oG9JP7DPDoHE5yz3UscROTg4uSgkVM=; b=V3KH+tbl/wIHJ3xKhoC1Ko70Q2y2OtpStIAe6jgbde/thu7pEgU0KRX93Hjscaiuk1 UNnz4RI25f92R93lWckBC0zADUDvVZx396k3yYRKJXsDWj6Ez2+7cxp0DZv6KZoAK8Hh Y+mewFYtz5PnMRZ1xz4sGheR+lMiazJP2jlryh9KnCboucG+LGZU5CqiDZ8gCX4347hD V1Tu+TpJ4HGSQx5LZ+tyBWpeajXz3hPUBxn8IGmKtPrOYUzje3JZbhVQC4eY9usSLfY6 vcfWHpXZBbTAL2VdvfGIG9w5OvRbZSlsDBoI5VgsGEm919HtBfq2PBipGEeF5tP5MFSx 7HUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nEy4esKgjxuW/oG9JP7DPDoHE5yz3UscROTg4uSgkVM=; b=FTpGh4Ge85RPjOJ5ReYKKYySd5HiwRrTdc2YHk2Dd7ICJTk2QfaB6zVnJwell7JnNf GiaIyGRFb397kzwa7N926uBJ3hXiRQlrgVelPUYWyAxPiVUcaOYRAhVD2LUR4CXfSXeK gopfkTlpeufBtbc2U8aO7T/8tKXPTrlM4ltl3rnRiGfHQSqPr1gThhdDh42kgZASX+1B K0RPdvxqcpSvWCp6uI+DnmkRO4dt0s0E2TrYNNIqM/b2TGjqf/kBANqbCGEREykySBdz r6QuDz1OZdKw6Ox1/ECXnlPw+54f54LMpFCdVW8DpAU4JvZWmF73RTUWDnK7c3dfx30d bVag== X-Gm-Message-State: AD7BkJKWZTIYnHpEe88I6f5UUrontt8angnZXAxbFMeCuej7G9WrWGELLiwtkbVwksJHVWfWoClHEn3grVezJA== MIME-Version: 1.0 X-Received: by 10.25.148.71 with SMTP id w68mr11015632lfd.23.1459197338564; Mon, 28 Mar 2016 13:35:38 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Mon, 28 Mar 2016 13:35:38 -0700 (PDT) In-Reply-To: <7f1e5116ae024a9cbe4fb8be57333b1f@EMEAWP-EXMB12.corp.brocade.com> References: <3f34012c40bc47ff87fe0aa944477979@EMEAWP-EXMB12.corp.brocade.com> <7f1e5116ae024a9cbe4fb8be57333b1f@EMEAWP-EXMB12.corp.brocade.com> Date: Mon, 28 Mar 2016 13:35:38 -0700 Message-ID: From: Andy Bierman To: William Ivory Content-Type: multipart/alternative; boundary=001a1140149405d21a052f21db16 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Query about usage of local-name() in YANG XPATH expressions 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, 28 Mar 2016 20:35:43 -0000 --001a1140149405d21a052f21db16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I added a new issue in github about open vs. closed systems https://github.com/netmod-wg/rfc6087bis/issues/32 Andy On Mon, Mar 28, 2016 at 12:59 PM, William Ivory wrote: > Hi Andy, > > > > Thanks. So if we have a tightly controlled set of YANG files, and > restrict usage to a specific use case where we have a set of nodes across > multiple modules with the same name, we should be fine. > > > > William > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* 28 March 2016 20:51 > *To:* William Ivory > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] Query about usage of local-name() in YANG XPATH > expressions > > > > Hi, > > > > This was raised as a concern by Lada (see netmod WG email arourd July 201= 4) > > > > The issue is that the expression breaks module containment and will match > > depending on what other YANG modules are known to the YANG compiler. > > > > > > Andy > > > > > > > > On Sat, Mar 26, 2016 at 3:08 AM, William Ivory wrote= : > > Hi, > > > > From RFC 6087 (YANG Usage Guidelines), section 5.6.2, the following is > noted about the use of the XPATH local-name() function: > > > > The 'local-name' function SHOULD NOT be used to reference local names > > outside of the YANG module defining the must or when expression > > containing the 'local-name' function. Example of a local-name > > function that should not be used: > > > > /*[local-name()=3D'foo'] > > > > However, no explanation is given as to why this is a bad idea. We have a > specific use case where local-name() would appear to allow us to massivel= y > simplify some rather cumbersome must expressions, but I wanted to check I= =E2=80=99m > not missing some =E2=80=98gotcha=E2=80=99 here. Is it simply that relyin= g on a common node > name across multiple modules is generally a bad design as it ties the > modules together, or is there more to it? If so, then in our case this i= s > a reasonable restriction. > > > > Thanks, > > > > William > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > --001a1140149405d21a052f21db16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I added a new issue in github about= open vs. closed systems


Andy


On Mon, Mar 28, 2016 at 12:59 PM= , William Ivory <wivory@brocade.com> wrote:

Hi Andy,

=C2=A0

Thanks.=C2=A0 So if we have a tightly contro= lled set of YANG files, and restrict usage to a specific use case where we = have a set of nodes across multiple modules with the same name, we should be fine.

=C2=A0

William

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: 28 March 2016 20:51
To: William Ivory <wivory@Brocade.com>
Cc: netmod@ietf= .org
Subject: Re: [netmod] Query about usage of local-name() in YANG XPAT= H expressions

=C2=A0

Hi,

=C2=A0

This was raised as a concern by Lada (see netmod WG = email arourd July 2014)

=C2=A0

The issue is that the expression breaks module conta= inment and will match

depending on what other YANG modules are known to th= e YANG compiler.

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

On Sat, Mar 26, 2016 at 3:08 AM, William Ivory <<= a href=3D"mailto:wivory@brocade.com" target=3D"_blank">wivory@brocade.com> wrote:

Hi,

=C2=A0

From RFC 6087 (YANG Usage Guidelines), section 5.6.2, the followi= ng is noted about the use of the XPATH local-name() function:=

=C2=A0

=C2=A0=C2=A0 The 'local-name' function SHOULD NOT be used= to reference local names

=C2=A0=C2=A0 outside of the YANG module defining the must or when= expression

=C2=A0=C2=A0 containing the 'local-name' function.=C2=A0 = Example of a local-name

=C2=A0=C2=A0 function that should not be used:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /*[local-name()=3D'foo']

=C2=A0

However, no explanation is given as to why this is a bad idea.=C2= =A0 We have a specific use case where local-name() would appear to allow us= to massively simplify some rather cumbersome must expressions, but I wanted to check I=E2=80=99m not missing some =E2= =80=98gotcha=E2=80=99 here.=C2=A0 Is it simply that relying on a common nod= e name across multiple modules is generally a bad design as it ties the mod= ules together, or is there more to it?=C2=A0 If so, then in our case this is a reasonable restriction.

=C2=A0

Thanks,

=C2=A0

William

=C2=A0


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

=C2=A0


--001a1140149405d21a052f21db16-- From nobody Mon Mar 28 13:55:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2B712D992 for ; Mon, 28 Mar 2016 13:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOTHEd7GbXno for ; Mon, 28 Mar 2016 13:55:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4467312D54D for ; Mon, 28 Mar 2016 13:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17246; q=dns/txt; s=iport; t=1459198511; x=1460408111; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tA4bG+MeHveTdEx4TrJISU3LvbljumhNGE2kuLTXqEQ=; b=HJnaOtERTaawKF8fo7lkEDJYEzCMEPzeq+ZMQnKfr2f6RrAhDDDmJHZw dYeidwMs3lC/XUX+B7IMbRZhC5FpiLgD16sKGlFy+WLBNHtpiyQtbX1rw m6R16Qa2Z6rCusQ/6f9G1eFAOJTobWLV5FC4Yvd/JHnDFM8LFN6rpTKlt 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgCCfflW/5tdJa1cgmJMU30GtgCEb?= =?us-ascii?q?gENgXAXAQmFIkoCgSM4FAEBAQEBAQFkJ4RBAQEBBAEBAWkCCAMMBAIBCBEDAQE?= =?us-ascii?q?BAScHJwsUCQgCBAENBYgnDr9NAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYpihFwNE?= =?us-ascii?q?YUYBZMGhFsBhXCIFYFmTYN/gyiEFoEbg3SLFQEPDwEBQoIDGYFJbId8fgEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,408,1454976000"; d="scan'208,217"; a="91183881" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2016 20:55:09 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2SKt9lT031172 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Mar 2016 20:55:09 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Mar 2016 15:55:09 -0500 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1104.009; Mon, 28 Mar 2016 15:55:09 -0500 From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" To: Andy Bierman , "Clyde Wildes (cwildes)" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.txt Thread-Index: AQHRgrqqbdiJAOKHdkK+l/uGNO0H6J9ijKMAgAyYBUmAAIG8gIAACeMA//+ye4A= Date: Mon, 28 Mar 2016 20:55:09 +0000 Message-ID: References: <20160320151006.2321.64042.idtracker@ietfa.amsl.com> <01cb01d18914$ab13ae40$4001a8c0@gateway.2wire.net> <0CA65B1D-6699-42BC-8FD9-1EBEB692EE55@cisco.com> In-Reply-To: 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.82.218.10] Content-Type: multipart/alternative; boundary="_000_D31F03E413E22kkoushikciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.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, 28 Mar 2016 20:55:14 -0000 --_000_D31F03E413E22kkoushikciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy We did solicit and incorporate feature support from at least 5+ vendors for= this model. The model represents a minimal common feature set. They are also hierarchic= al as Clyde noted below. Thanks Kiran From: Andy Bierman > Date: Monday, March 28, 2016 at 3:32 PM To: "Clyde Wildes (cwildes)" > Cc: "t.petch" >, "netmod@ie= tf.org" >, = Kiran Koushik Agrahara Sreenivasa > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.txt On Mon, Mar 28, 2016 at 12:57 PM, Clyde Wildes (cwildes) > wrote: Tom, I understand your concern with the complexity of the model. That said, as w= e progressed we encountered some vendors and some IETF RFC authors who requ= ested that a particular feature of interest be included. We felt that we ha= d to make features that were not implemented by two or more vendors a YANG = feature to gain acceptance. Which is preferred in this case: augmentation t= o add features; deviation not-supported statements to remove features; or t= he use of feature statements? During early model development our YANG docto= r advisor advocated using feature. I read your post on "features - a Cartesian explosion" post. Note that in t= he case of the latest ietf-syslog model four of the features are nested suc= h that they are not encountered unless a higher level feature is enabled. What would your preference be: - remove the feature statements and ask vendors to supply deviation stateme= nts for those leaves not implemented - remove all leaves conditioned by feature and ask vendors to supply annota= ted models with augmentation - leave things as they are It sounds like B would be your preference? I agree with Tom. IMO if the functionality is not supported by at least 2 vendors then remove it from the standard. The vendor can write a module that augments the base module. Thanks, Clyde Andy On 3/28/16, 10:09 AM, "t.petch" > wrote: > >----- Original Message ----- >From: "Clyde Wildes (cwildes)" > >To: > >Cc: "Martin Bjorklund" >; "t.petch" >>; "Kiran Koushik Agrahara= Sreenivasa (kkoushik)" >> >Sent: Sunday, March 20, 2016 7:53 PM > >> Hi, >> >> This revision incorporates feedback from Martin Bjorklunk (19 >comments) and Tom Petch (10 comments). Thanks to both of you for your >valuable feedback! >> >> Regarding Tom's comment - "4.1 What a lot of features? Again, makes >things more complex, more error prone - are they all really needed?": We >started the draft two years ago and it has evolved from feedback >received from all of the folks that appear in the Acknowledgements >section. Please review the current draft where I believe that I address >all of your comments except possibly this one. The tradeoff is to leave >the feature specific functionality out of the draft and leave it to the >implementations to add back through augmentation. That said most of the >features that are called out have been implemented by at least two >vendors, but not all, leading to the feature designation. > >Clyde > >Yeeees; I did a separate post on the topic thinking that an implementor >might share my concerns about the large number of possible variations in >an implementation when there were a large number of features, that >perhaps there should be guidelines about it, but it did not get any >traction. It is one those issues where I think, in a year or two's >time, others might share my concern, but not yet:-(. > >I don't doubt that the variation exists and needs modelling, just that >such use of 'features' may have unfortunate consequences - but I have no >alternative suggestion. > >Tom Petch > >> Thanks, >> >> Clyde >> >> >> >> On 3/20/16, 8:10 AM, "netmod on behalf of internet-drafts@ietf.org" > on behalf of inte= rnet-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 : SYSLOG YANG Model >> > Authors : Clyde Wildes >> > Kiran Koushik >> > Filename : draft-ietf-netmod-syslog-model-07.txt >> > Pages : 34 >> > Date : 2016-03-20 >> > >> >Abstract: >> > This document describes a data model for the Syslog protocol which >is >> > used to convey event notification messages. >> > >> > >> >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-07 >> > >> >A diff from the previous version is available at: >> >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-syslog-model-07 >> > >> > >> >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 --_000_D31F03E413E22kkoushikciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9ADF891B471CAE4DA61515AE1687E876@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Andy
We did solicit and incorporate feature support from at least 5+ ve= ndors for this model.
The model represents a minimal common feature set. They are also hiera= rchical as Clyde noted below.

Thanks
Kiran


From: Andy Bierman <andy@yumaworks.com>
Date: Monday, March 28, 2016 at 3:3= 2 PM
To: "Clyde Wildes (cwildes)&qu= ot; <cwildes@cisco.com>
Cc: "t.petch" <ietfc@btconnect.com>, "netmod@ietf.org" <netmod@ietf.org>, Kiran Koushik Agrahara Sreenivas= a <kkoushik@cisco.com>
Subject: Re: [netmod] I-D Action: d= raft-ietf-netmod-syslog-model-07.txt



On Mon, Mar 28, 2016 at 12:57 PM, Clyde Wildes (= cwildes) <cwildes@cisco.com> wrote:
Tom,

I understand your concern with the complexity of the model. That said, as w= e progressed we encountered some vendors and some IETF RFC authors who requ= ested that a particular feature of interest be included. We felt that we ha= d to make features that were not implemented by two or more vendors a YANG feature to gain acceptance. Whic= h is preferred in this case: augmentation to add features; deviation not-su= pported statements to remove features; or the use of feature statements? Du= ring early model development our YANG doctor advisor advocated using feature.

I read your post on "features - a Cartesian explosion" post. Note= that in the case of the latest ietf-syslog model four of the features are = nested such that they are not encountered unless a higher level feature is = enabled.

What would your preference be:
- remove the feature statements and ask vendors to supply deviation stateme= nts for those leaves not implemented
- remove all leaves conditioned by feature and ask vendors to supply annota= ted models with augmentation
- leave things as they are

It sounds like B would be your preference?


I agree with Tom.
IMO if the functionality is not supported by at least 2 vendors then
remove it from the standard.  The vendor can write a module
that augments the  base module.



Thanks,

Clyde



Andy
 




On 3/28/16, 10:09 AM, "t.petch" <ietfc@btconnect.com> wrote:

>
>----- Original Message -----
>From: "Clyde Wildes (cwildes)" <cwildes@cisco.com>
>To: <netmod@ietf.org>
>Cc: "Martin Bjorklund" <= mbj@tail-f.com>; "t.petch"
><ietfc@btconnect.com>;= "Kiran Koushik Agrahara Sreenivasa (kkoushik)"
><kkoushik@cisco.com> >Sent: Sunday, March 20, 2016 7:53 PM
>
>> Hi,
>>
>> This revision incorporates feedback from Martin Bjorklunk (19
>comments) and Tom Petch (10 comments). Thanks to both of you for your >valuable feedback!
>>
>> Regarding Tom's comment - "4.1 What a lot of features?  = Again, makes
>things more complex, more error prone - are they all really needed?&quo= t;: We
>started the draft two years ago and it has evolved from feedback
>received from all of the folks that appear in the Acknowledgements
>section. Please review the current draft where I believe that I address=
>all of your comments except possibly this one. The tradeoff is to leave=
>the feature specific functionality out of the draft and leave it to the=
>implementations to add back through augmentation. That said most of the=
>features that are called out have been implemented by at least two
>vendors, but not all, leading to the feature designation.
>
>Clyde
>
>Yeeees; I did a separate post on the topic thinking that an implementor=
>might share my concerns about the large number of possible variations i= n
>an implementation when there were a large number of features, that
>perhaps there should be guidelines about it, but it did not get any
>traction.  It is one those issues where I think, in a year or two'= s
>time, others might share my concern, but not yet:-(.
>
>I don't doubt that the variation exists and needs modelling, just that<= br> >such use of 'features' may have unfortunate consequences - but I have n= o
>alternative suggestion.
>
>Tom Petch
>
>> Thanks,
>>
>> Clyde
>>
>>
>>
>> On 3/20/16, 8:10 AM, "netmod on behalf of internet-drafts@ietf.org"
><netmod-bounces@ietf.org<= /a> on behalf of internet-drafts@ietf.org>= ; wrote:
>>
>> >
>> >A New Internet-Draft is available from the on-line Internet-Dr= afts
>directories.
>> >This draft is a work item of the NETCONF Data Modeling Languag= e of
>the IETF.
>> >
>> >        Title        &= nbsp;  : SYSLOG YANG Model
>> >        Authors       =  : Clyde Wildes
>> >                 =         Kiran Koushik
>> > Filename        : draft-ietf-netmod-syslo= g-model-07.txt
>> > Pages           : 34
>> > Date            : 2016-03-20 >> >
>> >Abstract:
>> >   This document describes a data model for the Sysl= og protocol which
>is
>> >   used to convey event notification messages.
>> >
>> >
>> >The IETF datatracker status page for this draft is:
>> >https://datatracker.iet= f.org/doc/draft-ietf-netmod-syslog-model/
>> >
>> >There's also a htmlized version available at:
>> >https://tools.ietf.org/htm= l/draft-ietf-netmod-syslog-model-07
>> >
>> >A diff from the previous version is available at:
>> >https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-netmod-syslog-model-07
>> >
>> >
>> >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/net= mod
>>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 --_000_D31F03E413E22kkoushikciscocom_-- From nobody Mon Mar 28 14:35:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49D712D0C1 for ; Mon, 28 Mar 2016 14:35:42 -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 JA8o-W_sPpzK for ; Mon, 28 Mar 2016 14:35:40 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 3206A12D554 for ; Mon, 28 Mar 2016 14:35:40 -0700 (PDT) Received: by mail-lb0-x22e.google.com with SMTP id qe11so89173432lbc.3 for ; Mon, 28 Mar 2016 14:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=ydjHHJUiJWPWkM2qjXLZru05M2waa4yNH/2HGu/373Y=; b=upNFkwnJlcYEza71s6biZwGkGNSxXTnOtVBb3dggzcP0bnWsrw4BF27vC4AFpueT0c qMvPdND2MQ8TL8FKAT9nx/J2cV/FHqKHV9okmVJEJdDybENWXk9/VozE/v0Lpxrmnvdg ytq3fni2xV4rQ7/m6mbAZUBzCFDtESPlfhzIJjRNYXyFceeRiEDNeAVtL9EqrFbM52Vk M/Xu/ysHfrVyBFgTe17jXGL3AULtC3kuqwqLnxYDGGF5YpBExKa8aI1+p63+SGDWF2Kk +Zc2jUeQkDj6fBbmT807k1XId2Ic820EsUQeeeXIwQ5+OunN+y8x+zpcjGu1ONwTLvae sRag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=ydjHHJUiJWPWkM2qjXLZru05M2waa4yNH/2HGu/373Y=; b=Suf7iiLNYGvtuKhKia4LpBJORb3HbE3mdhMylE/asQOMHYVWRHlTQ3ZAWcYPLPzCjd Uvw3CZgIbk9ZJqtsGD0DeKDBsPga7CyKn7YCWSu0RWTP5zbYPiNYHOuTF3wJfi0+8AHL OT7oT0pvt5hcovEsvYYmAUeLvDassRc6IvoqxGvyaCMo/Vkv7kbWb3662dcTaSuCfo9X SyvGbcFygWMxDeVWH9XiM7WlPFmpsWRWZ71+xvjmdaCZhU95t16XcAp4zX3k8fkRHsLa Gkjh2ctWPaiVK2PZgSA4glqwPtnOe/8j/cg6/GswFYMlmKVenzLxCjZrbk6pwo/sNFZW 6zzg== X-Gm-Message-State: AD7BkJKkMCqbSg/DLya6rOguLN+FCEA6tww+9pZKFn7BA3dkIJoTb+kVtZqH52DUqAQ67OC4p2oaPyXzYdwjTg== MIME-Version: 1.0 X-Received: by 10.112.129.169 with SMTP id nx9mr10956963lbb.96.1459200938213; Mon, 28 Mar 2016 14:35:38 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Mon, 28 Mar 2016 14:35:38 -0700 (PDT) Date: Mon, 28 Mar 2016 14:35:38 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3441da941bb7052f22b11b Archived-At: Subject: [netmod] comments on YANG mount requirements draft 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, 28 Mar 2016 21:35:42 -0000 --047d7b3441da941bb7052f22b11b Content-Type: text/plain; charset=UTF-8 Hi, I was reading the requirements draft to see if that offered any insight wrt/ why I should like any of the solution drafts. https://tools.ietf.org/html/draft-voit-netmod-yang-mount-requirements-00 sec 1) I do not really agree that the priority should be to make the client as simple as possible. There is no mention of the overall system impact if the complexity is moved to the managed devices (where resources are more expensive than a workstation or laptop) I do not agree Alias Mount is needed at all. This is a local presentation issue. The client software can map /foo/bar/baz to /top/acme-objects/orange if they want. It is a client-side presentation issue. I do not understand why the client tool does not just use the object paths derived from the YANG modules. The only part of this problem space I support is the ability for a controller to provide a nested root, representing the document root of the mounted device. This allows the YANG to be mapped correctly and predictably. E.g, OK (mount from root) /mounts/mount/server1/interfaces/interface/mtu NOT OK (mount from arbitrary subtree) /mounts/mount/server1/interface/mtu All cases in which the YANG paths are supposed to be ignored because the relocated YANG is broken should not be allowed. I do not see why we need YANG Mount and YANG Push and Pub/Sub. Seems like they all do the same thing. The client needs push updates instead of polling the server. What the client does with the pushed data is an implementation detail. Andy --047d7b3441da941bb7052f22b11b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I was reading the requirements draf= t to see if that
offered any insight wrt/ why I should like any o= f the solution drafts.




sec 1) =C2=A0I do not really ag= ree that the priority should be to make the
client as simple as p= ossible.=C2=A0 There is no mention of the overall system
impact i= f the complexity is moved to the managed devices
(where resources= are more expensive than a workstation or laptop)

= I do not agree Alias Mount is needed at all.
This is a local pres= entation issue.=C2=A0 The client software
can map /foo/bar/baz to= /top/acme-objects/orange
if they want.=C2=A0 It is a client-side= presentation issue.
I do not understand why the client tool does= not
just use the object paths derived from the YANG modules.

The only part of this problem space I support
is the ability for a controller to provide a nested root,
repr= esenting the document root of the mounted device.
This allows the= YANG to be mapped correctly and predictably.

E.g,=

OK (mount from root)

=C2= =A0 =C2=A0/mounts/mount/server1/interfaces/interface/mtu

NOT OK (mount from arbitrary subtree)

= =C2=A0 =C2=A0/mounts/mount/server1/interface/mtu

=

All cases in which the YANG paths are supposed to be ig= nored
because the relocated YANG is broken should not be allowed.=

I do not see why we need YANG Mount and YANG Push= and Pub/Sub.
Seems like they all do the same thing.=C2=A0 The cl= ient needs
push updates instead of polling the server.=C2=A0 What= the client
does with the pushed data is an implementation detail= .


Andy

--047d7b3441da941bb7052f22b11b-- From nobody Tue Mar 29 00:10:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCC412D55C for ; Tue, 29 Mar 2016 00:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kmtiFqXBcL-d for ; Tue, 29 Mar 2016 00:09:57 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 1EE3712D541 for ; Tue, 29 Mar 2016 00:09:57 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id DDEA99EC15833 for ; Tue, 29 Mar 2016 07:09:53 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2T79sOr009993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 Mar 2016 07:09:55 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u2T79o3T011439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Mar 2016 09:09:54 +0200 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 29 Mar 2016 09:09:53 +0200 From: "Bogaert, Bart (Nokia - BE)" To: "netmod@ietf.org" Thread-Topic: string in when and must statement in YANG ABNF Grammar Thread-Index: AdGJifz7Dsi0IsP4QZyKWK2UH0HsNw== Date: Tue, 29 Mar 2016 07:09:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0380_01D1899A.C087F700" MIME-Version: 1.0 Archived-At: Subject: [netmod] string in when and must statement in YANG ABNF Grammar 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, 29 Mar 2016 07:10:03 -0000 ------=_NextPart_000_0380_01D1899A.C087F700 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0381_01D1899A.C087F700" ------=_NextPart_001_0381_01D1899A.C087F700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Is there a reason why the ABNF for example the when and must statement has been "restricted" to when-keyword sep string optsep As "string" can't be tokenized no errors are generated by YANG compilers if this string contains an error, e.g. referred leaf does not exit due to a typo. This problem only exposes itself at run-time. I was wondering why this string was not broken down into a number of specific parts that define the when statement so that these kind of errors can be trapped early in the development process? I am rather new in this so I did not follow all discussions that led to the definition of YANG and hence have no idea whether this was discussed and what were the reasons not to do it this way. Best regards - Vriendelijke groeten, Bart Bogaert ------=_NextPart_001_0381_01D1899A.C087F700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is there a = reason why the ABNF for example the when and must statement has been = “restricted” to when-keyword sep string = optsep

As = “string”  can’t be tokenized no errors are = generated by YANG compilers if this string contains an error, e.g. = referred leaf does not exit due to a typo…  This problem only = exposes itself at run-time.  I was wondering why this string was = not broken down into a number of specific parts that define the when = statement so that these kind of errors can be trapped early in the = development process?   I am rather new in this so I did not = follow all discussions that led to the definition of YANG and hence have = no idea whether this was discussed and what were the reasons not to do = it this way.

 

Best regards - = Vriendelijke groeten,

Bart = Bogaert

 

------=_NextPart_001_0381_01D1899A.C087F700-- ------=_NextPart_000_0380_01D1899A.C087F700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzI5MDcwOTUxWjAjBgkqhkiG9w0B CQQxFgQUpFwpXg6Y3s2dH63/WvAhPclaTOQwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQAI rsU1R4pa+aAdZyslNTtLNfpyJE0LvL68gde6wbm7+X1q1jSzIarlc5Bz7z2ujH/IxwSH2PnDgcf/ 63zEcSHI1RcwibU6aFzmQFaPHOocny54KYu3J7P4Ieb8/HFXRb7aQnMTOnunzRLyFV/4HrlNC8m9 +hnizPHbE11ZsmDplPMQEpqFIh4zX5fTP+BQG2EK7k5hZd87nEECfYo0vaFnK0p4JJpG80aFp+Vr 7pDiH1OBYZSqv4LLOC4LxKH14z7p0lyU1qh/UrphpR2IMXzeDu0k7ZHBKXcW+xzleBxShEaYmc9B jUa18d8pzz+W3VFYYBrlzBK5mezAkFMakbS8AAAAAAAA ------=_NextPart_000_0380_01D1899A.C087F700-- From nobody Tue Mar 29 00:22:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6373412D57D for ; Tue, 29 Mar 2016 00:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bl4qdhcz-QTZ for ; Tue, 29 Mar 2016 00: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 5DD1E12D55C for ; Tue, 29 Mar 2016 00:22:55 -0700 (PDT) Received: from localhost (h-53-58.a165.priv.bahnhof.se [46.59.53.58]) by mail.tail-f.com (Postfix) with ESMTPSA id 226871AE03B5; Tue, 29 Mar 2016 09:22:54 +0200 (CEST) Date: Tue, 29 Mar 2016 09:22:53 +0200 (CEST) Message-Id: <20160329.092253.1276119786966152225.mbj@tail-f.com> To: bart.bogaert@nokia.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] string in when and must statement in YANG ABNF Grammar 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, 29 Mar 2016 07:22:58 -0000 "Bogaert, Bart (Nokia - BE)" wrote: > Is there a reason why the ABNF for example the when and must statement has > been "restricted" to when-keyword sep string optsep > > As "string" can't be tokenized no errors are generated by YANG compilers if > this string contains an error, e.g. referred leaf does not exit due to a > typo. This problem only exposes itself at run-time. I was wondering why > this string was not broken down into a number of specific parts that define > the when statement so that these kind of errors can be trapped early in the > development process? I am rather new in this so I did not follow all > discussions that led to the definition of YANG and hence have no idea > whether this was discussed and what were the reasons not to do it this way. The arguments to the "when" and "must" statements are XPath 1.0 expressions. The syntax of XPath 1.0 is not defined by YANG, but by the XPath 1.0 spec. This is the reason that the YANG grammar isn't more specific. YANG compilers differ in their ability to detect errors in these XPath expressions. Some perform more checks than others (unfortunately, pyang is pretty bad in this regard... (patches are always welcome:)). [For your particular example, referencing a leaf that doesn't exist is not an error per se; it is perfectly valid XPath. But it probably warrants a warning by the compiler.] /martin From nobody Tue Mar 29 00:56:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8F412D10F for ; Tue, 29 Mar 2016 00:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 oD0qUNjwYjYS for ; Tue, 29 Mar 2016 00:56:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 95DBF12D0C9 for ; Tue, 29 Mar 2016 00:56:40 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 1E1CF7B8CD7E1; Tue, 29 Mar 2016 07:56:37 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2T7ubRx009720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Mar 2016 07:56:38 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u2T7uYt0022972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Mar 2016 09:56:36 +0200 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 29 Mar 2016 09:56:34 +0200 From: "Bogaert, Bart (Nokia - BE)" To: EXT Martin Bjorklund Thread-Topic: [netmod] string in when and must statement in YANG ABNF Grammar Thread-Index: AdGJifz7Dsi0IsP4QZyKWK2UH0HsN///4hyA///dyDA= Date: Tue, 29 Mar 2016 07:56:33 +0000 Message-ID: References: <20160329.092253.1276119786966152225.mbj@tail-f.com> In-Reply-To: <20160329.092253.1276119786966152225.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03A2_01D189A1.460F8FE0" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] string in when and must statement in YANG ABNF Grammar 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, 29 Mar 2016 07:56:43 -0000 ------=_NextPart_000_03A2_01D189A1.460F8FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Martin, Thanks for this feedback. A run-time crash of the NETCONF server is a bad "outcome" of a typo like this... I checked the W3C pages and there is grammar defined for an XPATH expression so ultimately the string could be parsed as an XPATH (I guess it is currently not done). Any other programming language ensures to eliminate typing errors during the compilation phase allowing early detection of issues like this. It is becoming a problem when the NETCONF server internally stores values (e.g. identityref) in a format different from what is specified in the string of the when statement resulting in unexpected options when trying to use the CLI generated from the model. In this specific case we were advised to prefix the leaf (as the leaf was stored in this way...) even though the leaf was in the local module itself. This makes development even less transparent... When we flagged this we received the following feedback: Quote: For YANG 1.1 that is underway it will be defined in the following way: " The string value of a node of type identityref in a "must" or "when" XPath expression is the referred identity's qualified name with the prefix present. If the referred identity is defined in an imported module, the prefix in the string value is the prefix defined in the corresponding "import" statement. Otherwise, the prefix in the string value is the prefix for the current module."" But as this is within a string that is not parsed (depending on the compiler) this is something that people need to do and if not done will still result in run-time problems. Best regards - Vriendelijke groeten, Bart Bogaert System Architect Data-Centric SW Architectures Fixed Networks - Broadband Access BU, Nokia Contact number +32 3 2408310 (+32 477 673952) -----Original Message----- From: EXT Martin Bjorklund [mailto:mbj@tail-f.com] Sent: 29 March 2016 09:23 To: Bogaert, Bart (Nokia - BE) Cc: netmod@ietf.org Subject: Re: [netmod] string in when and must statement in YANG ABNF Grammar "Bogaert, Bart (Nokia - BE)" wrote: > Is there a reason why the ABNF for example the when and must statement > has been "restricted" to when-keyword sep string optsep > > As "string" can't be tokenized no errors are generated by YANG > compilers if this string contains an error, e.g. referred leaf does > not exit due to a typo. This problem only exposes itself at run-time. > I was wondering why this string was not broken down into a number of > specific parts that define the when statement so that these kind of errors can be trapped early in the > development process? I am rather new in this so I did not follow all > discussions that led to the definition of YANG and hence have no idea > whether this was discussed and what were the reasons not to do it this way. The arguments to the "when" and "must" statements are XPath 1.0 expressions. The syntax of XPath 1.0 is not defined by YANG, but by the XPath 1.0 spec. This is the reason that the YANG grammar isn't more specific. YANG compilers differ in their ability to detect errors in these XPath expressions. Some perform more checks than others (unfortunately, pyang is pretty bad in this regard... (patches are always welcome:)). [For your particular example, referencing a leaf that doesn't exist is not an error per se; it is perfectly valid XPath. But it probably warrants a warning by the compiler.] /martin ------=_NextPart_000_03A2_01D189A1.460F8FE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzI5MDc1NjMyWjAjBgkqhkiG9w0B CQQxFgQUPfyprU9Er2KID51ytn8JvsjLhP8wgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQCG ZI6SWF5YccLOzAe8NVQ3rpM2DWTmthWp5RJAI+gxUX0huvwIB+XO2qVZb7PznAMK/ufPkOSqq9eh a+JQ4MKRg3YzJkEDKyoqP5WdiChYbdJ5VIXUSnK0igGSeX1OxlAhRJV6vVosRY53r0ZTSxs2wiub uxkJPyUAtVLL5AuRdLvSQVFDHX99CjDu/e21N+nzzOhR4TVKTm7c9NYZb4iGz9d2gse7WnGZLyFr zzX8wT4LYKD4UOYPj25D0W/LZ/Mb24KbbLuTYKG2lPNz0v+L4JC+z8CKK9msJBdezc2m3rSzGzeC bZjHoIxRfKRkVA9efhzSeo4SJorjwEZ7V/ZSAAAAAAAA ------=_NextPart_000_03A2_01D189A1.460F8FE0-- From nobody Tue Mar 29 01:13:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA4012D562 for ; Tue, 29 Mar 2016 01:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjM1M7JS_ZZg for ; Tue, 29 Mar 2016 01:12:57 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B394812D0B6 for ; Tue, 29 Mar 2016 01:12:57 -0700 (PDT) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u2T8BuAO024210; Tue, 29 Mar 2016 01:12:57 -0700 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 21yf2510q6-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 Mar 2016 01:12:57 -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.1104.5; Tue, 29 Mar 2016 02:12:55 -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.1104.5; Tue, 29 Mar 2016 10:12:53 +0200 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.1104.000; Tue, 29 Mar 2016 10:12:53 +0200 From: William Ivory To: "Bogaert, Bart (Nokia - BE)" , "EXT Martin Bjorklund" Thread-Topic: [netmod] string in when and must statement in YANG ABNF Grammar Thread-Index: AdGJifz7Dsi0IsP4QZyKWK2UH0HsN///4hyA///dyDD//7EsYA== Date: Tue, 29 Mar 2016 08:12:35 +0000 Deferred-Delivery: Tue, 29 Mar 2016 08:12:17 +0000 Message-ID: <3bf688ffb6584ba68627ff09f815370a@EMEAWP-EXMB12.corp.brocade.com> References: <20160329.092253.1276119786966152225.mbj@tail-f.com> In-Reply-To: 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.171] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-29_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603290105 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] string in when and must statement in YANG ABNF Grammar 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, 29 Mar 2016 08:12:59 -0000 Hi Bart, Maybe you need to use a different NETCONF server if your current one is crashing with badly formed XPATH expressions? Our YANG compiler validates XPATH expressions when we load in YANG files, and anything that slips through should certainly not cause a crash at runtime (unless there's a bug of course). I had assumed others would do likewise - as far as I'm concerned XPATH is an 'extension' of YANG and we validate it with the same level of scrutiny as the YANG itself. So, I don't think this is anything to do with the 'programming language' - it's all about individual implementations of the YANG / XPATH compiler. I don't quite follow your point about prefixing a leaf - if you don't explicitly prefix a leaf in an XPATH statement then there are clear (well, after the third or fourth reading!) rules that specify what prefix will be used, depending on whether the must statement is inside a grouping or an augment statement, or in 'plain' YANG. Is your NETCONF server doing something unexpected? Regards, William -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Bogaert, Bart (Nokia - BE) Sent: 29 March 2016 08:57 To: EXT Martin Bjorklund Cc: netmod@ietf.org Subject: Re: [netmod] string in when and must statement in YANG ABNF Grammar Martin, Thanks for this feedback. A run-time crash of the NETCONF server is a bad "outcome" of a typo like this... I checked the W3C pages and there is grammar defined for an XPATH expression so ultimately the string could be parsed as an XPATH (I guess it is currently not done). Any other programming language ensures to eliminate typing errors during the compilation phase allowing early detection of issues like this. It is becoming a problem when the NETCONF server internally stores values (e.g. identityref) in a format different from what is specified in the string of the when statement resulting in unexpected options when trying to use the CLI generated from the model. In this specific case we were advised to prefix the leaf (as the leaf was stored in this way...) even though the leaf was in the local module itself. This makes development even less transparent... When we flagged this we received the following feedback: Quote: For YANG 1.1 that is underway it will be defined in the following way: " The string value of a node of type identityref in a "must" or "when" XPath expression is the referred identity's qualified name with the prefix present. If the referred identity is defined in an imported module, the prefix in the string value is the prefix defined in the corresponding "import" statement. Otherwise, the prefix in the string value is the prefix for the current module."" But as this is within a string that is not parsed (depending on the compiler) this is something that people need to do and if not done will still result in run-time problems. Best regards - Vriendelijke groeten, Bart Bogaert System Architect Data-Centric SW Architectures Fixed Networks - Broadband Access BU, Nokia Contact number +32 3 2408310 (+32 477 673952) -----Original Message----- From: EXT Martin Bjorklund [mailto:mbj@tail-f.com] Sent: 29 March 2016 09:23 To: Bogaert, Bart (Nokia - BE) Cc: netmod@ietf.org Subject: Re: [netmod] string in when and must statement in YANG ABNF Grammar "Bogaert, Bart (Nokia - BE)" wrote: > Is there a reason why the ABNF for example the when and must statement > has been "restricted" to when-keyword sep string optsep > > As "string" can't be tokenized no errors are generated by YANG > compilers if this string contains an error, e.g. referred leaf does > not exit due to a typo. This problem only exposes itself at run-time. > I was wondering why this string was not broken down into a number of > specific parts that define the when statement so that these kind of > errors can be trapped early in the > development process? I am rather new in this so I did not follow all > discussions that led to the definition of YANG and hence have no idea > whether this was discussed and what were the reasons not to do it this way. The arguments to the "when" and "must" statements are XPath 1.0 expressions. The syntax of XPath 1.0 is not defined by YANG, but by the XPath 1.0 spec. This is the reason that the YANG grammar isn't more specific. YANG compilers differ in their ability to detect errors in these XPath expressions. Some perform more checks than others (unfortunately, pyang is pretty bad in this regard... (patches are always welcome:)). [For your particular example, referencing a leaf that doesn't exist is not an error per se; it is perfectly valid XPath. But it probably warrants a warning by the compiler.] /martin From nobody Tue Mar 29 01:15:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7905D12D0B6 for ; Tue, 29 Mar 2016 01:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOdm_Lr3zN_I for ; Tue, 29 Mar 2016 01:15:20 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 176C812D562 for ; Tue, 29 Mar 2016 01:15:19 -0700 (PDT) Received: from localhost (h-53-58.a165.priv.bahnhof.se [46.59.53.58]) by mail.tail-f.com (Postfix) with ESMTPSA id 011131AE0144; Tue, 29 Mar 2016 10:15:18 +0200 (CEST) Date: Tue, 29 Mar 2016 10:15:18 +0200 (CEST) Message-Id: <20160329.101518.89589799333114863.mbj@tail-f.com> To: bart.bogaert@nokia.com From: Martin Bjorklund In-Reply-To: References: <20160329.092253.1276119786966152225.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] string in when and must statement in YANG ABNF Grammar 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, 29 Mar 2016 08:15:23 -0000 Hi, "Bogaert, Bart (Nokia - BE)" wrote: > Martin, > > Thanks for this feedback. A run-time crash of the NETCONF server is a bad > "outcome" of a typo like this... Sure; but that's a tool issue, not a specification issue. > I checked the W3C pages and there is grammar defined for an XPATH expression > so ultimately the string could be parsed as an XPATH (I guess it is > currently not done). It all depends on the tool you are using. > Any other programming language ensures to eliminate typing errors during the > compilation phase allowing early detection of issues like this. It is > becoming a problem when the NETCONF server internally stores values (e.g. > identityref) in a format different from what is specified in the string of > the when statement resulting in unexpected options when trying to use the > CLI generated from the model. In this specific case we were advised to > prefix the leaf (as the leaf was stored in this way...) even though the leaf > was in the local module itself. This makes development even less > transparent... When we flagged this we received the following feedback: > > Quote: > For YANG 1.1 that is underway it will be defined in the following way: > " The string value of a node of type identityref in a "must" or "when" XPath > > expression is the referred identity's qualified name with the prefix > present. > If the referred identity is defined in an imported module, the prefix in the > > string value is the prefix defined in the corresponding "import" statement. > > Otherwise, the prefix in the string value is the prefix for the current > module."" > > But as this is within a string that is not parsed (depending on the > compiler) this is something that people need to do and if not done will > still result in run-time problems. Right; for this particular example, it is better to use the new (YANG 1.1) functions derived-from() and derived-from-or-self(). /martin > > Best regards - Vriendelijke groeten, > Bart Bogaert > System Architect Data-Centric SW Architectures > Fixed Networks - Broadband Access BU, Nokia > Contact number +32 3 2408310 (+32 477 673952) > > -----Original Message----- > From: EXT Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: 29 March 2016 09:23 > To: Bogaert, Bart (Nokia - BE) > Cc: netmod@ietf.org > Subject: Re: [netmod] string in when and must statement in YANG ABNF Grammar > > "Bogaert, Bart (Nokia - BE)" wrote: > > Is there a reason why the ABNF for example the when and must statement > > has been "restricted" to when-keyword sep string optsep > > > > As "string" can't be tokenized no errors are generated by YANG > > compilers if this string contains an error, e.g. referred leaf does > > not exit due to a typo. This problem only exposes itself at run-time. > > I was wondering why this string was not broken down into a number of > > specific parts that define the when statement so that these kind of errors > can be trapped early in the > > development process? I am rather new in this so I did not follow all > > discussions that led to the definition of YANG and hence have no idea > > whether this was discussed and what were the reasons not to do it this > way. > > The arguments to the "when" and "must" statements are XPath 1.0 expressions. > The syntax of XPath 1.0 is not defined by YANG, but by the XPath 1.0 spec. > This is the reason that the YANG grammar isn't more specific. > > YANG compilers differ in their ability to detect errors in these XPath > expressions. Some perform more checks than others (unfortunately, pyang is > pretty bad in this regard... (patches are always welcome:)). > > [For your particular example, referencing a leaf that doesn't exist is not > an error per se; it is perfectly valid XPath. But it probably warrants a > warning by the compiler.] > > > /martin From nobody Tue Mar 29 01:56:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AB912D57D for ; Tue, 29 Mar 2016 01:56:16 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 So1qCi1YMtex for ; Tue, 29 Mar 2016 01:56:15 -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 A7E1D12D573 for ; Tue, 29 Mar 2016 01:56:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 538601E5D6A; Tue, 29 Mar 2016 01:55:27 -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 rz0O84fT6Y1V; Tue, 29 Mar 2016 01:55:27 -0700 (PDT) Received: from [192.168.1.100] (host5-81-222-249.range5-81.btcentralplus.com [5.81.222.249]) by c8a.amsl.com (Postfix) with ESMTPSA id 755FA1E5D68; Tue, 29 Mar 2016 01:55:26 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: William Lupton In-Reply-To: <20160329.092253.1276119786966152225.mbj@tail-f.com> Date: Tue, 29 Mar 2016 09:56:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <64969BB4-640E-4523-AF67-44A9E87354F3@broadband-forum.org> References: <20160329.092253.1276119786966152225.mbj@tail-f.com> To: netmod@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [netmod] string in when and must statement in YANG ABNF Grammar 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, 29 Mar 2016 08:56:16 -0000 It might also be worth noting (see = https://github.com/mbj4668/pyang/wiki/InstanceValidation) that "DSDL = schemas can be used with generic off-the-shelf XML tools for both = syntactic and semantic validation of XML instance documents=E2=80=9D. = This includes validating =E2=80=9Cmust=E2=80=9D statements and so on. = William. > On 29 Mar 2016, at 08:22, Martin Bjorklund wrote: >=20 > "Bogaert, Bart (Nokia - BE)" wrote: >> Is there a reason why the ABNF for example the when and must = statement has >> been "restricted" to when-keyword sep string optsep=20 >>=20 >> As "string" can't be tokenized no errors are generated by YANG = compilers if >> this string contains an error, e.g. referred leaf does not exit due = to a >> typo. This problem only exposes itself at run-time. I was wondering = why >> this string was not broken down into a number of specific parts that = define >> the when statement so that these kind of errors can be trapped early = in the >> development process? I am rather new in this so I did not follow = all >> discussions that led to the definition of YANG and hence have no idea >> whether this was discussed and what were the reasons not to do it = this way. >=20 > The arguments to the "when" and "must" statements are XPath 1.0 > expressions. The syntax of XPath 1.0 is not defined by YANG, but by > the XPath 1.0 spec. This is the reason that the YANG grammar isn't > more specific. >=20 > YANG compilers differ in their ability to detect errors in these XPath > expressions. Some perform more checks than others (unfortunately, > pyang is pretty bad in this regard... (patches are always welcome:)). >=20 > [For your particular example, referencing a leaf that doesn't exist is > not an error per se; it is perfectly valid XPath. But it probably > warrants a warning by the compiler.] >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Tue Mar 29 06:21:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F71212D801; Tue, 29 Mar 2016 06:21:14 -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=kuatrotechnology.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 C1A--ck9oEzE; Tue, 29 Mar 2016 06:21:12 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0073.outbound.protection.outlook.com [104.47.2.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE22612D800; Tue, 29 Mar 2016 06:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nqL5n3jpbtKjTGpDyhcmy/58jTbTkOtRjH7geaAYa20=; b=rlkOQnNYCXC1ggUD21oPZN/Ik4IEkvKrvrhiMtpQzYYEjz1ywplNZGrJFUPVkERZBPm0IhYclvwQKB+VGZt8RhfyT4eq7CKILSFf0SRxbq9tNUj5w5xJr1mDMdmyVxx+Yw9FwhSJFu2tIB8CCiI8kmS4g56a9dvJovM+OMtodCc= Received: from DBXPR06MB623.eurprd06.prod.outlook.com (10.255.71.170) by DBXPR06MB624.eurprd06.prod.outlook.com (10.255.71.171) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 29 Mar 2016 13:21:07 +0000 Received: from DBXPR06MB623.eurprd06.prod.outlook.com ([169.254.1.248]) by DBXPR06MB623.eurprd06.prod.outlook.com ([169.254.1.248]) with mapi id 15.01.0447.023; Tue, 29 Mar 2016 13:21:07 +0000 From: Xufeng Liu To: Lou Berger , netmod WG Thread-Topic: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount Thread-Index: AQFwc+YAZCi7PadkR/VC43l5HaDbSqAyk7mg Date: Tue, 29 Mar 2016 13:21:06 +0000 Message-ID: References: <56F01EB7.5000804@labn.net> In-Reply-To: <56F01EB7.5000804@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 7e9286b5-dedb-4530-a99b-08d357d4fc82 x-microsoft-exchange-diagnostics: 1; DBXPR06MB624; 5:mMaxeaeW2hqa8qOvj+I2hme2bgkVcF86BVYnkDPLn4z5oVyMh67W7UMBAhK/Ret79yxZnX42TF4AFLVfZfphot0t2klmTa0+rBmQslnG00G0p2XAXA3v0jktRrMhVdyw2Py3EOMUGp/EjqoPV6qkwg==; 24:kVqlfA+RcoDi13eUXu2rxTKMdVU0GNkgGScfGpB6twoYm+Q0QkN+gRZF2TRY2RhvwODvbHnd4JRdwMQ6LcEqzEzJEMqN/IIZINZccRU4N1c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR06MB624; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040046)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041046)(6043046); SRVR:DBXPR06MB624; BCL:0; PCL:0; RULEID:; SRVR:DBXPR06MB624; x-forefront-prvs: 0896BFCE6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(377454003)(52044002)(66066001)(2906002)(5004730100002)(189998001)(230783001)(33656002)(81166005)(5003600100002)(19580395003)(76576001)(19580405001)(11100500001)(50986999)(86362001)(76176999)(54356999)(5002640100001)(4326007)(102836003)(2950100001)(3660700001)(6116002)(3846002)(3280700002)(1220700001)(1096002)(87936001)(586003)(5008740100001)(2900100001)(106116001)(122556002)(15975445007)(10400500002)(74316001)(5001770100001)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR06MB624; H:DBXPR06MB623.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2016 13:21:06.7668 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR06MB624 Archived-At: Cc: netmod chairs Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount 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, 29 Mar 2016 13:21:14 -0000 Support. - Xufeng > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Monday, March 21, 2016 12:18 PM > To: netmod WG > Cc: netmod chairs > Subject: [netmod] WG adoption poll draft-bjorklund-netmod-structural-moun= t- > 02 as draft-ietf-netmod-schema-mount >=20 > All, >=20 > This is start of a two week poll on making > draft-bjorklund-netmod-structural-mount-02 a working group document with > the name draft-ietf-netmod-schema-mount. >=20 > This adoption is a little bit unusual in that, per our last interim, we k= now that this > document is likely to see significant changes in technical (solution) det= ails as it > progresses through normal WG process. > And the -01 version is expected to be done in combination with Lada/draf= t- > lhotka-netmod-ysdl. >=20 > Please send email to the list indicating "yes/support" or "no/do not supp= ort". > Note that Yes indicates your support for working on a schema mount soluti= on, > rather than the specific solution. If you have specific technical > proposals/suggestions that you'd like to voice please feel free to also d= o so - but > please use a new/different thread so we can keep the process and technica= l > discussions separate. >=20 > The poll ends April 4, 2016 > (after our in-person meeting, but authors / main contributors are not exp= ected > to be present in BA. So please discuss on list.) >=20 > Thank you, >=20 > NETMOD Chairs >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Mar 30 02:08:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C2F12DFF1 for ; Wed, 30 Mar 2016 02:08:07 -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 bLVO1HdsJSTK for ; Wed, 30 Mar 2016 02:08:04 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 84CCE12DFC8 for ; Wed, 30 Mar 2016 02:07:47 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id CAD901CC00C3; Wed, 30 Mar 2016 11:07:48 +0200 (CEST) From: Ladislav Lhotka To: William Lupton , netmod@ietf.org In-Reply-To: <64969BB4-640E-4523-AF67-44A9E87354F3@broadband-forum.org> References: <20160329.092253.1276119786966152225.mbj@tail-f.com> <64969BB4-640E-4523-AF67-44A9E87354F3@broadband-forum.org> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 30 Mar 2016 11:07:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] string in when and must statement in YANG ABNF Grammar 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, 30 Mar 2016 09:08:07 -0000 William Lupton writes: > It might also be worth noting (see > https://github.com/mbj4668/pyang/wiki/InstanceValidation) that "DSDL > schemas can be used with generic off-the-shelf XML tools for both > syntactic and semantic validation of XML instance documents=E2=80=9D. This > includes validating =E2=80=9Cmust=E2=80=9D statements and so on. William. Right, although XPath expressions as they appear in YANG modules need to be massaged somewhat before they can be used in Schematron - e.g. explicit prefixes need to be added where they are missing. Lada > >> On 29 Mar 2016, at 08:22, Martin Bjorklund wrote: >>=20 >> "Bogaert, Bart (Nokia - BE)" wrote: >>> Is there a reason why the ABNF for example the when and must statement = has >>> been "restricted" to when-keyword sep string optsep=20 >>>=20 >>> As "string" can't be tokenized no errors are generated by YANG compile= rs if >>> this string contains an error, e.g. referred leaf does not exit due to a >>> typo. This problem only exposes itself at run-time. I was wondering w= hy >>> this string was not broken down into a number of specific parts that de= fine >>> the when statement so that these kind of errors can be trapped early in= the >>> development process? I am rather new in this so I did not follow all >>> discussions that led to the definition of YANG and hence have no idea >>> whether this was discussed and what were the reasons not to do it this = way. >>=20 >> The arguments to the "when" and "must" statements are XPath 1.0 >> expressions. The syntax of XPath 1.0 is not defined by YANG, but by >> the XPath 1.0 spec. This is the reason that the YANG grammar isn't >> more specific. >>=20 >> YANG compilers differ in their ability to detect errors in these XPath >> expressions. Some perform more checks than others (unfortunately, >> pyang is pretty bad in this regard... (patches are always welcome:)). >>=20 >> [For your particular example, referencing a leaf that doesn't exist is >> not an error per se; it is perfectly valid XPath. But it probably >> warrants a warning by the compiler.] >>=20 >> /martin >>=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 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 30 02:22:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D7312E03F for ; Wed, 30 Mar 2016 02:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 lEwXwZUI48cl for ; Wed, 30 Mar 2016 02:22:35 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 8B54B12DFCF for ; Wed, 30 Mar 2016 02:22:35 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 4F1F8DC4C326D for ; Wed, 30 Mar 2016 09:22:31 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2U9MVkZ014603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Mar 2016 09:22:33 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u2U9MSq7008550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 30 Mar 2016 11:22:30 +0200 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 30 Mar 2016 11:21:27 +0200 From: "Bogaert, Bart (Nokia - BE)" To: "netmod@ietf.org" Thread-Topic: Why is entAliasMappingEntry not included in the entity YANG model? Thread-Index: AdGKZYhfa5ifJWGGQ4Cj1bPDHR6rfQ== Date: Wed, 30 Mar 2016 09:21:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0074_01D18A76.4BF1D910" MIME-Version: 1.0 Archived-At: Subject: [netmod] Why is entAliasMappingEntry not included in the entity YANG model? 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, 30 Mar 2016 09:22:38 -0000 ------=_NextPart_000_0074_01D18A76.4BF1D910 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0075_01D18A76.4BF1D910" ------=_NextPart_001_0075_01D18A76.4BF1D910 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We are wondering why in the no provision has been forseen to link the "interface-world" to the "entity-world": when looking at the YANG modues for entity and interface it is not there. In the SNMP entity MIB there seems to be an object that serves this purpose: entAliasMappingEntry. Is there any reason why this was not considered in the YANG modules? It is also possible to do the linking from /interfaces to /entity as this would allow proper validation of interface settings immediately. If the linking is from /entity to /interfaces then both can be configured (and validated) separately but once an interface has to be associated with a real HW resource then again (maybe only partial) validation is required to ensure that this interface can actually be associated with the HW entity instantiation. If the linking is from interfaces to entity then all this validation can be done in 1 step (which to me seems more logical). Best regards - Vriendelijke groeten, Bart Bogaert ------=_NextPart_001_0075_01D18A76.4BF1D910 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We are = wondering why in the no provision has been forseen to link the = “interface-world” to the “entity-world”: when = looking at the YANG modues for entity and interface it is not = there.  In the SNMP entity MIB there seems to be an object that = serves this purpose: entAliasMappingEntry.  Is there any reason = why this was not considered in the YANG modules?

 

It is also = possible to do the linking from /interfaces to /entity as this would = allow proper validation of interface settings immediately.  If the = linking is from /entity to /interfaces then both can be configured (and = validated) separately but once an interface has to be associated with a = real HW resource then again (maybe only partial) validation is required = to ensure that this interface can actually be associated with the HW = entity instantiation.  If the linking is from interfaces to entity = then all this validation can be done in 1 step (which to me seems more = logical).

 

Best regards - = Vriendelijke groeten,

Bart = Bogaert

 

------=_NextPart_001_0075_01D18A76.4BF1D910-- ------=_NextPart_000_0074_01D18A76.4BF1D910 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzMwMDkyMTI1WjAjBgkqhkiG9w0B CQQxFgQUO5JBMIuRHchYpCFpUqi2Tpi5tYEwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQCD xDu1tkI5NuyMO+yyEE1bZAgQf1lhO10wSiEjYl0s02L521ZFKY+u8Ng2UpBOSbKwcXVuhFZ5m1Ir XOygSTyBBsK0CY57+Ij9HGxJF2F9hQwZDYec4D2BK+YJZN9x4+6r0wFAaXGZpcwFNwclyihyl+M/ S1UHSOywtW/CflZ3OQD4qP4gM9xcNGW5uHg5mNysuPQZE5xLfisdX+vFYF+qEmpGlPV3oE1jv02M tNGa0DGdGYGWjBFRK4ptNKpw35ssD2wQrnd2mHG/k8w/AiCywcjvF896BNVXRPO2XCilwJlNnUys G/KIRg7+5jWgyyCI/hIitVzkPKIbofRdw5abAAAAAAAA ------=_NextPart_000_0074_01D18A76.4BF1D910-- From nobody Wed Mar 30 03:28:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C2E12D0A4 for ; Wed, 30 Mar 2016 03:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCGi9yGKWSaR for ; Wed, 30 Mar 2016 03:28: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 ED64812D117 for ; Wed, 30 Mar 2016 03:28:43 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 54C101AE028E; Wed, 30 Mar 2016 12:28:42 +0200 (CEST) Date: Wed, 30 Mar 2016 12:28:49 +0200 (CEST) Message-Id: <20160330.122849.1958375683637496211.mbj@tail-f.com> To: andy@yumaworks.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] few more YANG-11 comments 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, 30 Mar 2016 10:28:49 -0000 Hi, Andy Bierman wrote: > 1.1 > > It does not mention: > - multiple import-stmt for the same module now allowed > - description-stmt and reference-stmt now allowed in > import-stmt and include-stmt > > (There are no examples of any of the above changes) Ok, fixed, including one example of a reference: import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types"; } > 5.1: > > o A module MUST include all its submodules. > > > This is not 100% correct. > A module MUST include one revision of all its submodules. > This includes a submodule with all obsolete definitions I guess. I don't understand what you mean. Do you have a concrete proposal? > 7.1.6 > > It does not say what happens if a nested submodule includes-by-revision > a different revision that the parent module. > > Multiple revisions of the same submodule MUST NOT be included. > > > It is not clear that this applies to all include-stmt for the same module > > > module A { > include A1 { > revision-date 2016-01-01; > } > include A2; > include A3; > } > > submodule A1 { ... } > > submodule A2 { > include A1; // which revision is included if no date? conflict w/ > module? > } > > submodule A3 { > include A1 { > revision-date 2015-01-01; // this is an error, right? > } > } I suggest: OLD: For backward compatibility with YANG version 1, a submodule is allowed to use the "include" statement to reference other submodules within its module, but this is not necessary in YANG version 1.1. A submodule can reference any definition in the module it belongs to and in all submodules included by the module. NEW: For backward compatibility with YANG version 1, a submodule is allowed to use the "include" statement to reference other submodules within its module, but this is not necessary in YANG version 1.1. A submodule can reference any definition in the module it belongs to and in all submodules included by the module. A submodule MUST NOT include different revisions of other submodules than the revisions that its module includes. > 9.12 > > It doesn't say what happens when a union containing a leafref > or instance-identifier becomes invalid or changes member types. > Is this just a server implementation detail? Is should at least be clear > a valid union leaf/leaf-list applies to a valid datastore > (e.g. running, not candidate). How this is handled internally is an implementation detail. But if you have a union between a leafref to a string leaf and an int32, and the referenced string doesn't exist, the config is invalid. However, if you have a union between a leafref to a string and a string, and the referenced string doesn't exist, the config is valid (since the value matches the next type in the union). /martin From nobody Wed Mar 30 09:47:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573DB12D7C5 for ; Wed, 30 Mar 2016 09:47:46 -0700 (PDT) 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 jiCzyb5IqyeE for ; Wed, 30 Mar 2016 09:47:44 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id D3D1712D7DD for ; Wed, 30 Mar 2016 09:47:43 -0700 (PDT) Received: (qmail 28793 invoked by uid 0); 30 Mar 2016 16:47:40 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 30 Mar 2016 16:47:40 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id cPnZ1s0162SSUrH01Pnctv; Wed, 30 Mar 2016 17:47:37 -0600 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=Fm8F0NncYRAA:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7OsogOcEt9IA:10 a=e5hV1Ss-hHVAXabqi7AA:9 a=QEXdDO2ut3YA:10 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; bh=b1Von9x1jDAqYMM2vDlrp5hiNX0oX/JLKLIdr71Q8GE=; b=uFVFSAruxxv9c2GzcZ2dli6c0J e9iAsH3tJODfoDVtSx/hVNSH5+Y8RFPu0JpARYW9HCJ4wi9Qg8Ho9OihkljmqWTz7/+0HIx536jTq WOnEGQgMP29AO4/zuNefU7mjT; Received: from box313.bluehost.com ([69.89.31.113]:52772 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1alJHM-00065l-RI; Wed, 30 Mar 2016 10:47:36 -0600 To: draft-openconfig-netmod-model-catalog@ietf.org From: Lou Berger Message-ID: <56FC031C.7020307@labn.net> Date: Wed, 30 Mar 2016 12:47:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod WG Subject: [netmod] Plans for draft-openconfig-netmod-model-catalog 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, 30 Mar 2016 16:47:46 -0000 Authors, Just wanted to check in with you on your plans for this document. My understanding is that the WG expressed some interest in this work when last presented. What are your plans for this work? Thanks, Lou (and Kent) From nobody Wed Mar 30 12:54:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD58712D91B for ; Wed, 30 Mar 2016 12:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R44zsc9bTog for ; Wed, 30 Mar 2016 12:54: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 1D12412D919 for ; Wed, 30 Mar 2016 12:54:53 -0700 (PDT) Received: from localhost (h-53-58.a165.priv.bahnhof.se [46.59.53.58]) by mail.tail-f.com (Postfix) with ESMTPSA id 067991AE028E; Wed, 30 Mar 2016 21:54:51 +0200 (CEST) Date: Wed, 30 Mar 2016 21:54:50 +0200 (CEST) Message-Id: <20160330.215450.1001247068721967632.mbj@tail-f.com> To: bart.bogaert@nokia.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] Why is entAliasMappingEntry not included in the entity YANG model? 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, 30 Mar 2016 19:54:55 -0000 Hi, "Bogaert, Bart (Nokia - BE)" wrote: > Hi, > > > > We are wondering why in the no provision has been forseen to link the > "interface-world" to the "entity-world": when looking at the YANG modues for > entity and interface it is not there. In the SNMP entity MIB there seems to > be an object that serves this purpose: entAliasMappingEntry. Is there any > reason why this was not considered in the YANG modules? No real reason; we decided to get a basic structure in place and then wait for comments from the WG. But when we published -00 the WG was still busy with lots of other work, and didn't have the cycles to adopt this draft contine to work on it. Thus the work stalled. But now it seems this document might get adopted by the WG soon, so hopefully we can re-start this work. > It is also possible to do the linking from /interfaces to /entity as this > would allow proper validation of interface settings immediately. If the > linking is from /entity to /interfaces then both can be configured (and > validated) separately but once an interface has to be associated with a real > HW resource then again (maybe only partial) validation is required to ensure > that this interface can actually be associated with the HW entity > instantiation. If the linking is from interfaces to entity then all this > validation can be done in 1 step (which to me seems more logical). I can see how a config false reference from interfaces-state to entity-state could work. It is common to have implicit hw info by embedding the hw location in the interface name ("ethernet-1/0"). The entAliasMappingEntry is more generic, and the same concept could be used in YANG as well (with an instance-identifier instead of the OID). /martin From nobody Wed Mar 30 13:50:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA60312D517 for ; Wed, 30 Mar 2016 13:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQkPAsNIQemA for ; Wed, 30 Mar 2016 13:50:28 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 858E412D50E for ; Wed, 30 Mar 2016 13:50:28 -0700 (PDT) Received: from localhost (h-53-58.a165.priv.bahnhof.se [46.59.53.58]) by mail.tail-f.com (Postfix) with ESMTPSA id 0FCC81AE028E; Wed, 30 Mar 2016 22:50:27 +0200 (CEST) Date: Wed, 30 Mar 2016 22:50:26 +0200 (CEST) Message-Id: <20160330.225026.1707013976170314590.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <017301d17bb9$288005e0$4001a8c0@gateway.2wire.net> References: <017301d17bb9$288005e0$4001a8c0@gateway.2wire.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] action and mandatory node 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, 30 Mar 2016 20:50:32 -0000 Hi Tom, t.petch wrote: > Given > > container... list... action > > with the usual twiddly brackets, and a separate mandatory data node > alongside the list in the top level container, is there a requirement to > include that mandatory data node in the XML RPC? No. > 6020bis s.7.15.2 says > > " The "action" element contains an hierarchy of nodes that identifies > the node in the datastore. It MUST contain all containers and list > nodes from the top level down to the list or container containing the > action. " > > which suggests, without quite clearly telling me, that it is only the > nodes in the direct path from the top level that have to be included, > not any off to one side in the tree. Yes. > If that is correct, I suggest > > OLD > "It MUST contain all containers and list > nodes from the top level down to the list or container containing the > action. " > NEW > " It MUST contain all containers and list > nodes in the direct path from the top level down to the list or > container containing the action (node). " I have applied your NEW clarified text. /martin From nobody Wed Mar 30 13:53:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C463612D947; Wed, 30 Mar 2016 13:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jatLJP_MN0QG; Wed, 30 Mar 2016 13:52:52 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E490612D88F; Wed, 30 Mar 2016 13:52:37 -0700 (PDT) Received: from [199.87.120.129] (helo=latte) by cappuccino.rob.sh with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1alN69-0005Wl-4O; Wed, 30 Mar 2016 21:52:17 +0100 Date: Wed, 30 Mar 2016 14:52:33 -0600 From: Rob Shakir To: Lou Berger , draft-openconfig-netmod-model-catalog@ietf.org Message-ID: In-Reply-To: <56FC031C.7020307@labn.net> References: <56FC031C.7020307@labn.net> X-Mailer: Airmail Beta (353) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="56fc3c91_38388ddf_141c" Archived-At: Cc: netmod WG Subject: Re: [netmod] Plans for draft-openconfig-netmod-model-catalog 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, 30 Mar 2016 20:52:54 -0000 --56fc3c91_38388ddf_141c Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Lou, We=E2=80=99re currently working to rev the model that it describes - ther= e are some issues we=E2=80=99ve come across when trying to utilise it - a= nd define bundles of the models that it defines. I expect that once this = work has been done we=E2=80=99ll rev the draft. None of the authors will be at the IET=46 mtg, so we did not request any = time to cover this =E2=80=94 but this is an actively interesting, and use= d model. Cheers, r. On 30 March, 2016 at 10:48:05 AM, Lou Berger (lberger=40labn.net) wrote: Authors, =20 Just wanted to check in with you on your plans for this document. =20 My understanding is that the WG expressed some interest in this work =20 when last presented. What are your plans for this work=3F =20 Thanks, =20 Lou (and Kent) =20 --56fc3c91_38388ddf_141c Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi all,
 
The ACL model is converging on a small core set of functionality that = is fairly common.
 
But I think the matching on input-interface should be removed from the= model (or at the least put inside a feature flag).
 
Matching on basic IPv4/IPv4/MAC header fields is common functionality.=   But having that input-interface match on metadata in the core model = is out of place.  It should be left to further extension drafts or ven= dor specific augmentations (along with whatever other metadata might be useful or vendor-specific).
 
ACLs are typically assigned to interfaces as shown in section A.3. of = the ACL draft.   That is the most common use case.
 
Actually matching on input-interface in the ACL rules themselves is no= t basic core ACL functionality.  Nokia SR OS does not have that capabi= lity.  Does IOS-XR ?  Brocade ?  others ?   &= nbsp; If some major implementations don’t do it, and it isn’t n= ecessary for typical basic ACL use, then it should be removed (or feature flagged).<= /div>
 
Regards,
Jason
 
 --_000_A125E53CE190A749957C19483DC79F9F5CC2295FUS70TWXCHMBA11z_-- From nobody Wed Mar 30 23:08:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CC912D93C for ; Wed, 30 Mar 2016 23:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0so6oJUOj3KA for ; Wed, 30 Mar 2016 23:08:33 -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 CB9B812D9B1 for ; Wed, 30 Mar 2016 23:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5583; q=dns/txt; s=iport; t=1459404509; x=1460614109; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=rgZuRQP0jfvMfsrAD4N8DnT2eG1vtdspP8NQWgPxOz0=; b=ZGm1CbH1KTdijACu2jgIO5rMmTGRbGGeaXKPcKR7Ei9bjN0v9W9B7XfB C0B8zwr5CVUftf5Lz6xXS8QnItGfS+x9KL2bsOvZ/lLFJfBpmouK8I9O+ G7ulH+HnvfF+EB4cGYOJf6FYTOyuG9OtNELOJ48kZlTPhVQEptEztyPJ+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADBQCpvfxW/xbLJq1DGoQGfbYchm0jh?= =?us-ascii?q?WoCggcBAQEBAQFmJ4RBAQEBBHgRHAMBAgoWDwkDAgECATsCCAYNBgIBAYgjDiz?= =?us-ascii?q?BHQEBAQEBAQEBAQEBAQEBAQEBAQEXhh6ERoRJFQyFKgWTEYRhhXOFXoI3gWYXN?= =?us-ascii?q?4N/gwWFVY8VYoIEGRWBNzowAYhsAQEB?= X-IronPort-AV: E=Sophos;i="5.24,420,1454976000"; d="scan'208,217";a="636687265" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2016 06:08:26 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2V68Q9s025844 for ; Thu, 31 Mar 2016 06:08:26 GMT References: <20160330213032.C31DB1804F0@rfc-editor.org> To: NETMOD Working Group From: Benoit Claise X-Forwarded-Message-Id: <20160330213032.C31DB1804F0@rfc-editor.org> Message-ID: <56FCBEDA.3020701@cisco.com> Date: Thu, 31 Mar 2016 08:08:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160330213032.C31DB1804F0@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------070509090403080105000307" Archived-At: Subject: [netmod] Fwd: [RFC State] has been added to the RFC Editor database 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, 31 Mar 2016 06:08:36 -0000 This is a multi-part message in MIME format. --------------070509090403080105000307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit And another one in the RFC editor queue. Thanks to the WG for your work on this one. Regards, Benoit -------- Forwarded Message -------- Subject: [RFC State] has been added to the RFC Editor database Date: Wed, 30 Mar 2016 14:30:32 -0700 From: rfc-editor@rfc-editor.org To: lhotka@nic.cz CC: netmod-ads@ietf.org, netmod-chairs@ietf.org, rfc-editor@rfc-editor.org, kwatsen@juniper.net Author(s), We have received notice that your document draft-ietf-netmod-yang-json-10 has been approved for publication as an RFC. The document has been added to the RFC Editor queue and you can check the status at If you submitted your XML file using the I-D submission tool, we have already retrieved it. If you did not submit the XML file via the I-D submission tool, or if you have an updated version (e.g., updated contact information), please send us the XML file at this time. Please attach the file as draft-ietf-netmod-yang-json-10.xml, and specify any differences between the approved I-D and the document that the XML produces. We recommend using xml2rfc v2 to create your document. See the RSE's message about the RFC Editor's transition to xml2rfc v2 here . If you created this document using -ms nroff, please send us the source file. This should help increase the pace with which documents move through the RFC Editor queue. Please let us know if you have any questions. Thank you. The RFC Editor Team . --------------070509090403080105000307 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit And another one in the RFC editor queue.
Thanks to the WG for your work on this one.

Regards, Benoit


-------- Forwarded Message --------
Subject: [RFC State] <draft-ietf-netmod-yang-json-10> has been added to the RFC Editor database
Date: Wed, 30 Mar 2016 14:30:32 -0700
From: rfc-editor@rfc-editor.org
To: lhotka@nic.cz
CC: netmod-ads@ietf.org, netmod-chairs@ietf.org, rfc-editor@rfc-editor.org, kwatsen@juniper.net 


Author(s),

We have received notice that your document draft-ietf-netmod-yang-json-10 has
been approved for publication as an RFC.  The document has
been added to the RFC Editor queue and you can check the status at
<https://www.rfc-editor.org/current_queue.php>

If you submitted your XML file using the I-D submission tool, we have
already retrieved it.  If you did not submit the XML file via the I-D
submission tool, or if you have an updated version (e.g., updated
contact information), please send us the XML file at this time.  Please
attach the file as draft-ietf-netmod-yang-json-10.xml, and specify 
any differences between the approved I-D and the document that the XML
produces.  We recommend using xml2rfc v2 <http://xml2rfc.ietf.org/> to create
your document.  See the RSE's message about the RFC Editor's transition to
xml2rfc v2 here 
<https://www.rfc-editor.org/pipermail/rfc-interest/2013-December/005835.html>.

If you created this document using -ms nroff, please send us the
source file.

This should help increase the pace with which documents move through
the RFC Editor queue. 

Please let us know if you have any questions.

Thank you.

The RFC Editor Team

.


--------------070509090403080105000307-- From nobody Thu Mar 31 02:25:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840BA12D0F2 for ; Thu, 31 Mar 2016 02:25:34 -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, 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 rYFZTpvBgOq8 for ; Thu, 31 Mar 2016 02:25:31 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 8C79812D096 for ; Thu, 31 Mar 2016 02:25:31 -0700 (PDT) Received: by mail-qg0-x229.google.com with SMTP id j35so60233482qge.0 for ; Thu, 31 Mar 2016 02:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=vqAL3Kh9PKOx+3PqKDfn5IOAtmdgbPLYWXAyV7FsEMg=; b=JBrvmKyXkayW9r+nNE75PQ85um0Vt1ud748GxVfAa0ge1xgwmJ3UJLf+w4jpM2fYHm MfXTF7Lcgeu1OLJdlGLJjSJMF5LFJyqgSnREKtPXgr0H8H1Z8rESSZS89H4sWw1SqszE LpdNgBCdap4Xe/fLpmPKRxz1xWyDjkY31CQXwbNrfqalBjnbPQEVWqXEMtxwUGHnlt1A EbWcn/J7BzI3HJUBbw0KH+F0bvfsmQfbYxoV9PeHBT4NPpuUC7S5j0Paz6joHW9JQr2m ub4rdAxgD55D/MRjQ5yo8AuikSHG0R5hKd9lUb1KDREvDMWF+T+iNKbaGxki7TnAtTgd TgOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vqAL3Kh9PKOx+3PqKDfn5IOAtmdgbPLYWXAyV7FsEMg=; b=lrb39aOMHP5pqMEL/0DmkyzqbhBaKmHOZivwlq2e+LA/XYbKzEfDm1RCOQNky4d6qy P209UgABTdW/FaHtckDruts8wx2x0gbl55KfGPpcJtLXp6Z5iY9uGNwJuE2+NiyTA0tX QZ0d9QSt0V+tvBkJzN3ONu1Zkb+zsQ6w/TWseHOQ2kX+Rrw8q/7mO77eX/ZlgYwXbZhf HhdlzOrNFz6Aa2qxnpo9Qs8uOkVl0mpyCQQSiJn7A2cTDp05ep8lUSFcFNZjndntllBI C9PlmVBFaHyeVcSAWjTqVIDqgOIKe7OlTLGUgkDEdnicJ2XZb+92NpJ4USxdBvJ6PKIi ULIg== X-Gm-Message-State: AD7BkJJdtK4c6yzMlhZRiAntMrADvesay/DIjMH07tqpzP3eMJs3Q1/kHuSzjD5rDgg93g== X-Received: by 10.141.7.130 with SMTP id j124mr15279210qhd.29.1459416330627; Thu, 31 Mar 2016 02:25:30 -0700 (PDT) Received: from [10.0.1.3] (c-75-68-179-118.hsd1.ma.comcast.net. [75.68.179.118]) by smtp.gmail.com with ESMTPSA id s8sm3532612qhb.20.2016.03.31.02.25.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Mar 2016 02:25:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3BFF7A32-2B2C-4168-B550-B828BD8D7EB4" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: Date: Thu, 31 Mar 2016 05:26:12 -0400 Message-Id: References: To: "Sterne, Jason (Nokia - CA)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: netmod WG Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? 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, 31 Mar 2016 09:25:34 -0000 --Apple-Mail=_3BFF7A32-2B2C-4168-B550-B828BD8D7EB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) = wrote: >=20 > Hi all, > =20 > The ACL model is converging on a small core set of functionality that = is fairly common. > =20 > But I think the matching on input-interface should be removed from the = model (or at the least put inside a feature flag). > =20 > Matching on basic IPv4/IPv4/MAC header fields is common functionality. = But having that input-interface match on metadata in the core model is = out of place. It should be left to further extension drafts or vendor = specific augmentations (along with whatever other metadata might be = useful or vendor-specific). > =20 > ACLs are typically assigned to interfaces as shown in section A.3. of = the ACL draft. That is the most common use case. > =20 > Actually matching on input-interface in the ACL rules themselves is = not basic core ACL functionality. Nokia SR OS does not have that = capability. Does IOS-XR ? Brocade ? others ? Cisco and Juniper support matching on input interface. It is useful when = you want to filter on general traffic coming from interface. Cisco match input-interface match input-vlan Junos family any { filter L2_filter { term t1 { from { interface fe-0/0/0.0; } then { policer p1; count c1; } } } } Brocade supports matching based on interface, Dell supports VLAN = matching, Arista supports input interface matching, Redback supports = matching against input interface for logging, so it is pretty standard = across multiple vendors Dean > If some major implementations don=E2=80=99t do it, and it isn=E2=80= =99t necessary for typical basic ACL use, then it should be removed (or = feature flagged). > =20 > Regards, > Jason=20 > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_3BFF7A32-2B2C-4168-B550-B828BD8D7EB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 30, 2016, at 9:36 PM, Sterne, Jason = (Nokia - CA) <jason.sterne@nokia.com> wrote:

Hi = all,
 
The ACL model is = converging on a small core set of functionality that is fairly = common.
 
But I think the = matching on input-interface should be removed from the model (or at the = least put inside a feature flag).
 
Matching on basic IPv4/IPv4/MAC header fields is common = functionality.  But having that input-interface match on metadata = in the core model is out of place.  It should be left to further = extension drafts or vendor specific augmentations (along with whatever = other metadata might be useful or = vendor-specific).
 
ACLs are typically assigned to interfaces as shown in section = A.3. of the ACL draft.   That is the most common use = case.
 
Actually matching = on input-interface in the ACL rules themselves is not basic core ACL = functionality.  Nokia SR OS does not have that capability.  = Does IOS-XR ?  Brocade ?  others = ?

Cisco and Juniper support matching on input = interface. It is useful when you want to filter on general traffic = coming from interface.

Cisco
match = input-interface
match input-vlan


Junos
family any {
filter = L2_filter {
term t1 {
= from {
interface = fe-0/0/0.0;
}
= then {
policer = p1;
= count c1;
}
= }
}
}

Brocade supports matching based on interface, Dell = supports VLAN matching, Arista supports input interface matching, = Redback supports matching against input interface for logging, so it is = pretty standard across multiple vendors

Dean

     If some = major implementations don=E2=80=99t do it, and it isn=E2=80=99t = necessary for typical basic ACL use, then it should be removed (or = feature flagged).
 
Regards,
Jason 
 
_______________________________________________
netmod mailing = list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_3BFF7A32-2B2C-4168-B550-B828BD8D7EB4-- From nobody Thu Mar 31 04:17:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE83E12D5D3 for ; Thu, 31 Mar 2016 04:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vliHd3Ojn5A for ; Thu, 31 Mar 2016 04:17:38 -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 9931512D5E8 for ; Thu, 31 Mar 2016 04:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17799; q=dns/txt; s=iport; t=1459423024; x=1460632624; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LHl7Vh3jbi2ewmswmdsP19SpUnqEPGuryjM//PDJH7o=; b=b9UrE82NtErqXJYeuL7bmsb6jfVm4weiA5X3phPYVBk0u6oDwCvqljou xxY2FsWj6tfvlc/CeWK7bv+jvi6KcIpVOVmc5aWvqSyH7VpG8zi6j65Yx fGk53hBFabIlDOGjALKN+jWV1UIgtkxSr1FlJ9rrZbl+ZBIwvlzW8GCbR w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQByBv1W/4sNJK1dgmhMU30Grz2LU?= =?us-ascii?q?gENgXAXAQmFIkoCHIEkOBQBAQEBAQEBZSeEQQEBAQQBAQEgSwsQAgEIDgMDAQI?= =?us-ascii?q?oAwICAh8GCxQJCAIEDgWIEgMSDrBMjAoNhQUBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QERBIpkgkCCHg2CU4JWBZJ+hEMxAYwSgXWKU4Q6h0GHUwEeAQFCg2dsh29+AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.24,422,1454976000"; d="scan'208,217";a="255805507" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Mar 2016 11:17:03 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u2VBH3Hr006444 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Mar 2016 11:17:03 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 31 Mar 2016 07:17:02 -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.1104.009; Thu, 31 Mar 2016 07:17:02 -0400 From: "Acee Lindem (acee)" To: Dean Bogdanovic , "Sterne, Jason (Nokia - CA)" Thread-Topic: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? Thread-Index: AQHRiy9QFzBlKCUK2Eu8wY4yL7QnTp9zZ1EA Date: Thu, 31 Mar 2016 11:17:02 +0000 Message-ID: References: In-Reply-To: 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.196] Content-Type: multipart/alternative; boundary="_000_D3227DFB55298aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: netmod WG Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? 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, 31 Mar 2016 11:17:43 -0000 --_000_D3227DFB55298aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGVhbiwNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGVhbiBCb2dkYW5vdmljIDxp dmFuZGVhbkBnbWFpbC5jb208bWFpbHRvOml2YW5kZWFuQGdtYWlsLmNvbT4+DQpEYXRlOiBUaHVy c2RheSwgTWFyY2ggMzEsIDIwMTYgYXQgNToyNiBBTQ0KVG86ICJTdGVybmUsIEphc29uIChOb2tp YSAtIENBKSIgPGphc29uLnN0ZXJuZUBub2tpYS5jb208bWFpbHRvOmphc29uLnN0ZXJuZUBub2tp YS5jb20+Pg0KQ2M6IG5ldG1vZCBXRyA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFJlbW92ZSBpbnB1dC1pbnRlcmZhY2UgKG1l dGFkYXRhKSBmcm9tIG5ldG1vZC1hY2wtbW9kZWwtMDcgPw0KDQoNCk9uIE1hciAzMCwgMjAxNiwg YXQgOTozNiBQTSwgU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQSkgPGphc29uLnN0ZXJuZUBub2tp YS5jb208bWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20+PiB3cm90ZToNCg0KSGkgYWxsLA0K DQpUaGUgQUNMIG1vZGVsIGlzIGNvbnZlcmdpbmcgb24gYSBzbWFsbCBjb3JlIHNldCBvZiBmdW5j dGlvbmFsaXR5IHRoYXQgaXMgZmFpcmx5IGNvbW1vbi4NCg0KQnV0IEkgdGhpbmsgdGhlIG1hdGNo aW5nIG9uIGlucHV0LWludGVyZmFjZSBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBtb2RlbCAo b3IgYXQgdGhlIGxlYXN0IHB1dCBpbnNpZGUgYSBmZWF0dXJlIGZsYWcpLg0KDQpNYXRjaGluZyBv biBiYXNpYyBJUHY0L0lQdjQvTUFDIGhlYWRlciBmaWVsZHMgaXMgY29tbW9uIGZ1bmN0aW9uYWxp dHkuICBCdXQgaGF2aW5nIHRoYXQgaW5wdXQtaW50ZXJmYWNlIG1hdGNoIG9uIG1ldGFkYXRhIGlu IHRoZSBjb3JlIG1vZGVsIGlzIG91dCBvZiBwbGFjZS4gIEl0IHNob3VsZCBiZSBsZWZ0IHRvIGZ1 cnRoZXIgZXh0ZW5zaW9uIGRyYWZ0cyBvciB2ZW5kb3Igc3BlY2lmaWMgYXVnbWVudGF0aW9ucyAo YWxvbmcgd2l0aCB3aGF0ZXZlciBvdGhlciBtZXRhZGF0YSBtaWdodCBiZSB1c2VmdWwgb3IgdmVu ZG9yLXNwZWNpZmljKS4NCg0KQUNMcyBhcmUgdHlwaWNhbGx5IGFzc2lnbmVkIHRvIGludGVyZmFj ZXMgYXMgc2hvd24gaW4gc2VjdGlvbiBBLjMuIG9mIHRoZSBBQ0wgZHJhZnQuICAgVGhhdCBpcyB0 aGUgbW9zdCBjb21tb24gdXNlIGNhc2UuDQoNCkFjdHVhbGx5IG1hdGNoaW5nIG9uIGlucHV0LWlu dGVyZmFjZSBpbiB0aGUgQUNMIHJ1bGVzIHRoZW1zZWx2ZXMgaXMgbm90IGJhc2ljIGNvcmUgQUNM IGZ1bmN0aW9uYWxpdHkuICBOb2tpYSBTUiBPUyBkb2VzIG5vdCBoYXZlIHRoYXQgY2FwYWJpbGl0 eS4gIERvZXMgSU9TLVhSID8gIEJyb2NhZGUgPyAgb3RoZXJzID8NCg0KQ2lzY28gYW5kIEp1bmlw ZXIgc3VwcG9ydCBtYXRjaGluZyBvbiBpbnB1dCBpbnRlcmZhY2UuIEl0IGlzIHVzZWZ1bCB3aGVu IHlvdSB3YW50IHRvIGZpbHRlciBvbiBnZW5lcmFsIHRyYWZmaWMgY29taW5nIGZyb20gaW50ZXJm YWNlLg0KDQpDaXNjbw0KbWF0Y2ggaW5wdXQtaW50ZXJmYWNlDQptYXRjaCBpbnB1dC12bGFuDQoN ClRoZXNlIGFyZSDigJxjbGFzcy1tYXDigJ0gIHN1Yi1jb21tYW5kcyAtIG5vdCDigJxhY2Nlc3Mt bGlzdCIgc3ViLWNvbW1hbmRzLiBTbyB5b3UgYXJlIHJlZmVycmluZyB0byB0aGUgZ2VuZXJhbCBm dW5jdGlvbmFsaXR5IHJhdGhlciB0aGFuIHNwZWNpZmljYWxseSBmdW5jdGlvbmFsaXR5IHN1cHBv cnRlZCBieSBhY2Nlc3MtbGlzdD8NCg0KDQoNCkp1bm9zDQpmYW1pbHkgYW55IHsNCmZpbHRlciBM Ml9maWx0ZXIgew0KdGVybSB0MSB7DQpmcm9tIHsNCmludGVyZmFjZSBmZS0wLzAvMC4wOw0KfQ0K dGhlbiB7DQpwb2xpY2VyIHAxOw0KY291bnQgYzE7DQp9DQp9DQp9DQp9DQoNCkJyb2NhZGUgc3Vw cG9ydHMgbWF0Y2hpbmcgYmFzZWQgb24gaW50ZXJmYWNlLCBEZWxsIHN1cHBvcnRzIFZMQU4gbWF0 Y2hpbmcsIEFyaXN0YSBzdXBwb3J0cyBpbnB1dCBpbnRlcmZhY2UgbWF0Y2hpbmcsIFJlZGJhY2sg c3VwcG9ydHMgbWF0Y2hpbmcgYWdhaW5zdCBpbnB1dCBpbnRlcmZhY2UgZm9yIGxvZ2dpbmcsDQoN CklmIHlvdSBhcmUgcmVmZXJyaW5nIHRvIOKAnGxvZy1pbnB1dOKAnSwgdGhpcyBpbmRpY2F0ZXMg dG8gaW5jbHVkZSB0aGUgaW5wdXQtaW50ZXJmYWNlIGluIHRoZSBsb2cgbWVzc2FnZS4gQ2lzY28g c3VwcG9ydHMgdGhpcyBhcyB3ZWxsLg0KDQpUaGFua3MsDQpBY2VlDQoNCg0Kc28gaXQgaXMgcHJl dHR5IHN0YW5kYXJkIGFjcm9zcyBtdWx0aXBsZSB2ZW5kb3JzDQoNCkRlYW4NCg0KICAgICBJZiBz b21lIG1ham9yIGltcGxlbWVudGF0aW9ucyBkb27igJl0IGRvIGl0LCBhbmQgaXQgaXNu4oCZdCBu ZWNlc3NhcnkgZm9yIHR5cGljYWwgYmFzaWMgQUNMIHVzZSwgdGhlbiBpdCBzaG91bGQgYmUgcmVt b3ZlZCAob3IgZmVhdHVyZSBmbGFnZ2VkKS4NCg0KUmVnYXJkcywNCkphc29uDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBs aXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg== --_000_D3227DFB55298aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1031A8BC86DD9B448EA76312EE9B3ECD@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBEZWFuLCZu YnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsg dGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7 IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1M RUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29s aWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5uZXRtb2QgJmx0OzxhIGhyZWY9 Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGVhbiBCb2dkYW5vdmljICZsdDs8YSBocmVmPSJtYWlsdG86 aXZhbmRlYW5AZ21haWwuY29tIj5pdmFuZGVhbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXksIE1hcmNoIDMx LCAyMDE2IGF0IDU6MjYgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86 IDwvc3Bhbj4mcXVvdDtTdGVybmUsIEphc29uIChOb2tpYSAtIENBKSZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20iPmphc29uLnN0ZXJuZUBub2tpYS5jb208 L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPm5l dG1vZCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDog PC9zcGFuPlJlOiBbbmV0bW9kXSBSZW1vdmUgaW5wdXQtaW50ZXJmYWNlIChtZXRhZGF0YSkgZnJv bSBuZXRtb2QtYWNsLW1vZGVsLTA3ID88YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9 IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAg MCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTWFyIDMwLCAy MDE2LCBhdCA5OjM2IFBNLCBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20iIGNsYXNzPSIiPmphc29uLnN0ZXJuZUBub2tp YS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2Ut bmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiIHN0 eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SGkgYWxsLDwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIEFDTCBtb2RlbCBpcyBjb252ZXJn aW5nIG9uIGEgc21hbGwgY29yZSBzZXQgb2YgZnVuY3Rpb25hbGl0eSB0aGF0IGlzIGZhaXJseSBj b21tb24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5C dXQgSSB0aGluayB0aGUgbWF0Y2hpbmcgb24gaW5wdXQtaW50ZXJmYWNlIHNob3VsZCBiZSByZW1v dmVkIGZyb20gdGhlIG1vZGVsIChvciBhdCB0aGUgbGVhc3QgcHV0IGluc2lkZSBhIGZlYXR1cmUg ZmxhZykuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5N YXRjaGluZyBvbiBiYXNpYyBJUHY0L0lQdjQvTUFDIGhlYWRlciBmaWVsZHMgaXMgY29tbW9uIGZ1 bmN0aW9uYWxpdHkuJm5ic3A7IEJ1dCBoYXZpbmcgdGhhdCBpbnB1dC1pbnRlcmZhY2UgbWF0Y2gg b24gbWV0YWRhdGEgaW4gdGhlIGNvcmUgbW9kZWwgaXMgb3V0IG9mIHBsYWNlLiZuYnNwOyBJdCBz aG91bGQgYmUgbGVmdCB0byBmdXJ0aGVyIGV4dGVuc2lvbiBkcmFmdHMgb3IgdmVuZG9yIHNwZWNp ZmljIGF1Z21lbnRhdGlvbnMgKGFsb25nDQogd2l0aCB3aGF0ZXZlciBvdGhlciBtZXRhZGF0YSBt aWdodCBiZSB1c2VmdWwgb3IgdmVuZG9yLXNwZWNpZmljKS48L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+ PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiIgc3R5bGU9ImZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QUNMcyBh cmUgdHlwaWNhbGx5IGFzc2lnbmVkIHRvIGludGVyZmFjZXMgYXMgc2hvd24gaW4gc2VjdGlvbiBB LjMuIG9mIHRoZSBBQ0wgZHJhZnQuJm5ic3A7Jm5ic3A7IFRoYXQgaXMgdGhlIG1vc3QgY29tbW9u IHVzZSBjYXNlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+QWN0dWFsbHkgbWF0Y2hpbmcgb24gaW5wdXQtaW50ZXJmYWNlIGluIHRoZSBBQ0wgcnVsZXMg dGhlbXNlbHZlcyBpcyBub3QgYmFzaWMgY29yZSBBQ0wgZnVuY3Rpb25hbGl0eS4mbmJzcDsgTm9r aWEgU1IgT1MgZG9lcyBub3QgaGF2ZSB0aGF0IGNhcGFiaWxpdHkuJm5ic3A7IERvZXMgSU9TLVhS ID8mbmJzcDsgQnJvY2FkZSA/Jm5ic3A7IG90aGVycyA/PC9kaXY+DQo8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Q2lz Y28gYW5kIEp1bmlwZXIgc3VwcG9ydCBtYXRjaGluZyBvbiBpbnB1dCBpbnRlcmZhY2UuIEl0IGlz IHVzZWZ1bCB3aGVuIHlvdSB3YW50IHRvIGZpbHRlciBvbiBnZW5lcmFsIHRyYWZmaWMgY29taW5n IGZyb20gaW50ZXJmYWNlLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+ Q2lzY288L2Rpdj4NCjxkaXY+bWF0Y2ggaW5wdXQtaW50ZXJmYWNlPC9kaXY+DQo8ZGl2Pm1hdGNo IGlucHV0LXZsYW48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlc2UgYXJlIOKAnGNs YXNzLW1hcOKAnSAmbmJzcDtzdWItY29tbWFuZHMgLSBub3Qg4oCcYWNjZXNzLWxpc3QmcXVvdDsg c3ViLWNvbW1hbmRzLiBTbyB5b3UgYXJlIHJlZmVycmluZyB0byB0aGUgZ2VuZXJhbCBmdW5jdGlv bmFsaXR5IHJhdGhlciB0aGFuIHNwZWNpZmljYWxseSBmdW5jdGlvbmFsaXR5IHN1cHBvcnRlZCBi eSBhY2Nlc3MtbGlzdD8mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0i T0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJ QlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQ QURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2Pkp1bm9zPC9kaXY+DQo8ZGl2Pg0KPGRpdj5mYW1pbHkgYW55IHs8L2Rpdj4NCjxk aXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48 L3NwYW4+ZmlsdGVyIEwyX2ZpbHRlciB7PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10 YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPnRlcm0gdDEgezwvZGl2Pg0K PGRpdj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUi Pjwvc3Bhbj5mcm9tIHs8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBz dHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+aW50ZXJmYWNlIGZlLTAvMC8wLjA7PC9kaXY+ DQo8ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnBy ZSI+PC9zcGFuPn08L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHls ZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+dGhlbiB7PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNz PSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPnBvbGljZXIg cDE7PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRl LXNwYWNlOnByZSI+PC9zcGFuPmNvdW50IGMxOzwvZGl2Pg0KPGRpdj48c3BhbiBjbGFzcz0iQXBw bGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj59PC9kaXY+DQo8ZGl2 PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9z cGFuPn08L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hp dGUtc3BhY2U6cHJlIj48L3NwYW4+fTwvZGl2Pg0KPGRpdj59PC9kaXY+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdj5Ccm9jYWRlIHN1cHBvcnRzIG1hdGNoaW5nIGJhc2VkIG9uIGlu dGVyZmFjZSwgRGVsbCBzdXBwb3J0cyBWTEFOIG1hdGNoaW5nLCBBcmlzdGEgc3VwcG9ydHMgaW5w dXQgaW50ZXJmYWNlIG1hdGNoaW5nLCBSZWRiYWNrIHN1cHBvcnRzIG1hdGNoaW5nIGFnYWluc3Qg aW5wdXQgaW50ZXJmYWNlIGZvciBsb2dnaW5nLDwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PklmIHlvdSBhcmUgcmVmZXJyaW5nIHRvIOKAnGxvZy1pbnB1dOKAnSwgdGhpcyBp bmRpY2F0ZXMgdG8gaW5jbHVkZSB0aGUgaW5wdXQtaW50ZXJmYWNlIGluIHRoZSBsb2cgbWVzc2Fn ZS4gQ2lzY28gc3VwcG9ydHMgdGhpcyBhcyB3ZWxsLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9U RSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsg TUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj5zbyBpdCBpcyBwcmV0dHkgc3RhbmRhcmQgYWNyb3NzIG11bHRpcGxlIHZlbmRvcnM8L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkRlYW48L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIiBzdHlsZT0iZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiBzb21l IG1ham9yIGltcGxlbWVudGF0aW9ucyBkb27igJl0IGRvIGl0LCBhbmQgaXQgaXNu4oCZdCBuZWNl c3NhcnkgZm9yIHR5cGljYWwgYmFzaWMgQUNMIHVzZSwgdGhlbiBpdCBzaG91bGQgYmUgcmVtb3Zl ZCAob3IgZmVhdHVyZSBmbGFnZ2VkKS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkphc29uPHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiIGNsYXNzPSIiPm5ldG1vZA0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+bmV0bW9kQGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Qi IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2Q8L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_D3227DFB55298aceeciscocom_-- From nobody Thu Mar 31 11:16:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD8012D6A7; Thu, 31 Mar 2016 11:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBRRoOaL3b_x; Thu, 31 Mar 2016 11:16:56 -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 00D3212D715; Thu, 31 Mar 2016 11:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6830; q=dns/txt; s=iport; t=1459448215; x=1460657815; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=17pYonsbB0TgBuX54pcu5nlioW4kLYWEoJ8ZxqwkZAs=; b=Qzf2LTur1tSqoKQdLZmRrs2n62+bFs3UkQyP38GBH1PzyN+WDPBt7reN owxMs/nrf2C0NTCvo9neuizhAgUVIrta2TPNJUWfcQDLitN4d9lVASXJD kH7UHbPrE8vQhZhfiDb8GQgt81rQryQlskhlnjCV/ZbJCfRpMGnQ2k7zf Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBACAaP1W/xbLJq1dgmiBH329FRcBC?= =?us-ascii?q?YUiSgKCDwEBAQEBAWYnhEIBAQQBAQFrCxALDgoJHgcPAhYfEQYBDAYCAQGIIw7?= =?us-ascii?q?CbgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhh6ERooUBYlTjh+OCIk4hVWPFWKCB?= =?us-ascii?q?BmBTDowiG0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,423,1454976000"; d="scan'208,217";a="634897134" 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; 31 Mar 2016 18:16:53 +0000 Received: from [10.61.199.34] ([10.61.199.34]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2VIGqN8017184; Thu, 31 Mar 2016 18:16:52 GMT To: Anees Shaikh , Rob Shakir References: <56FC031C.7020307@labn.net> From: Benoit Claise Message-ID: <56FD6994.60109@cisco.com> Date: Thu, 31 Mar 2016 20:16:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010403000404080704090807" Archived-At: Cc: draft-openconfig-netmod-model-catalog@ietf.org, netmod WG Subject: Re: [netmod] Plans for draft-openconfig-netmod-model-catalog 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, 31 Mar 2016 18:16:57 -0000 This is a multi-part message in MIME format. --------------010403000404080704090807 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 3/30/2016 11:16 PM, Anees Shaikh wrote: > Lou, you may know but just FYI it sounds like Benoit and Carl were > thinking about a hackathon project to populate a version of the > catalog model with IETF modules .... yes, for the information we can extract from the YANG models. Some other info will need to be populated manually. Regards, Benoit > > > > On Wed, Mar 30, 2016 at 1:52 PM, Rob Shakir > wrote: > > Hi Lou, > > We’re currently working to rev the model that it describes - there > are some issues we’ve come across when trying to utilise it - and > define bundles of the models that it defines. I expect that once > this work has been done we’ll rev the draft. > > None of the authors will be at the IETF mtg, so we did not request > any time to cover this — but this is an actively interesting, and > used model. > > Cheers, > r. > > > On 30 March, 2016 at 10:48:05 AM, Lou Berger (lberger@labn.net > ) wrote: > >> Authors, >> Just wanted to check in with you on your plans for this document. >> My understanding is that the WG expressed some interest in this work >> when last presented. What are your plans for this work? >> >> Thanks, >> Lou (and Kent) >> >> > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------010403000404080704090807 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 3/30/2016 11:16 PM, Anees Shaikh wrote:
Lou, you may know but just FYI it sounds like Benoit and Carl were thinking about a hackathon project to populate a version of the catalog model with IETF modules ....
yes, for the information we can extract from the YANG models.
Some other  info will need to be populated manually.

Regards, Benoit



On Wed, Mar 30, 2016 at 1:52 PM, Rob Shakir <rjs@rob.sh> wrote:
Hi Lou,

We’re currently working to rev the model that it describes - there are some issues we’ve come across when trying to utilise it - and define bundles of the models that it defines. I expect that once this work has been done we’ll rev the draft.

None of the authors will be at the IETF mtg, so we did not request any time to cover this — but this is an actively interesting, and used model.

Cheers,
r.


On 30 March, 2016 at 10:48:05 AM, Lou Berger (lberger@labn.net) wrote:

Authors,
Just wanted to check in with you on your plans for this document.
My understanding is that the WG expressed some interest in this work
when last presented. What are your plans for this work?

Thanks,
Lou (and Kent) 





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

--------------010403000404080704090807-- From nobody Thu Mar 31 11:44:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2519912D5AB; Thu, 31 Mar 2016 11:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOkrdPg6t3yF; Thu, 31 Mar 2016 11:44:08 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F0912D0F4; Thu, 31 Mar 2016 11:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2456; q=dns/txt; s=iport; t=1459449848; x=1460659448; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=E/Ie59HHp+v6QNcEUqzZ9lafHklb0yKwCFdrX2v3Wyw=; b=WVQf4lkrtNCJcCfeiVC7yU4K8fOqrPtFcGpOEOU4EyrofAVf9V5+dKya 5pEvkVKVh9U5xnMsz88oysBzRRZuEBfrkWS7ULzv2sG1ki/SDYkOg0L6t hIWwDCPIxPogZjWBmPCbHqtLx/4FXuuJGWcSMN68JYi5frGQzjz8cp2SE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgDAbv1W/5pdJa1dgzRTgQO5AIIPA?= =?us-ascii?q?Q2BcSGFbB6BJzgUAQEBAQEBAWUcC4REBCMRRRIBIgImAgQwFRIEDogsDrFxkHk?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBEwR8hSKBdYoPK4IrBZdyAYVyiBWPCwKPFAEeA?= =?us-ascii?q?QFCgjKBNYhbfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,423,1454976000"; d="scan'208";a="255896355" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2016 18:44:07 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u2VIi7T9031987 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Mar 2016 18:44:07 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 31 Mar 2016 13:44:06 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.009; Thu, 31 Mar 2016 13:44:06 -0500 From: "Rajiv Asati (rajiva)" To: "netmod@ietf.org" Thread-Topic: YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! Thread-Index: AQHRi31NmlAQiI8k5U+2ghmHbAtBnA== Date: Thu, 31 Mar 2016 18:44:06 +0000 Message-ID: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.102.241] Content-Type: text/plain; charset="utf-8" Content-ID: <1A8E4D1397CBFA4A8038302B6F60E6B9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! 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, 31 Mar 2016 18:44:10 -0000 DQpXaGlsZSB3b3JraW5nIG9uIE1QTFMgTERQIHlhbmcgbW9kZWwgKGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1yYXphLW1wbHMtbGRwLW1sZHAteWFuZyksIHdlIG5vdGljZWQgdGhl IHBvc3NpYmxlIGNvbmZ1c2lvbiBhcm91bmQgc3RydWN0dXJpbmcgaW50ZW5kZWQgY29uZmlnLCBh cHBsaWVkIGNvbmZpZyBhbmQgZGVyaXZlZCBzdGF0ZSAqLg0KDQpPbiBvbmUgaGFuZCwgb25lIG1h eSBoYXZlICdpbnRlbmRlZC1jb25maWfigJkgKFJXKSBhbmQg4oCYYXBwbGllZC1jb25maWfigJkg KFJPKSBpbiB0aGUgc2FtZSBjb25zdHJ1Y3QgKGNvbnRhaW5lciksIGFuZCDigJhkZXJpdmVkIHN0 YXRl4oCZIChSTykgaW4gYSBzZXBhcmF0ZSBjb25zdHJ1Y3QgKGNvbnRhaW5lcikuIA0KDQoJVGhp cyBrZWVwcyBjb25maWcgdG9nZXRoZXIsIGJ1dCBkb2VzbuKAmXQgaGVscCBvcGVyYXRpb25hbCBz dGF0ZSwgd2hpY2ggcmVxdWlyZXMNCglCb3RoIEFwcGxpZWQtY29uZmlnIGFuZCBkZXJpdmVkLXN0 YXRlLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCBoYW5kLCBvbmUgbWF5IGhhdmUg4oCYaW50ZW5kZWQt Y29uZmln4oCZIGluIG9uZSBjb25zdHJ1Y3QgKGNvbnRhaW5lciksIGFuZCDigJhhcHBsaWVkLWNv bmZpZ+KAmSBhbmQg4oCYZGVyaXZlZCBzdGF0ZeKAmSBpbiBhIHNlcGFyYXRlIGNvbnN0cnVjdCAo Y29udGFpbmVyKS4gDQoNCglUaGlzIHNpbXBsaWZpZXMgZmlndXJpbmcgb3BlcmF0aW9uYWwtc3Rh dGUsIGJ1dCBkaXZpZGVzIHRoZSBjb25maWcgdHlwZXMuDQoNClRoZXJlIGFyZSBwcm9zICYgY29u cyBlaXRoZXIgd2F5LiBJdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgc29tZSBndWlkYW5jZS90ZXh0 IGFyb3VuZCBndWlkaW5nIG9uZSBvdmVyIGFub3RoZXIsIHNvIHRoYXQgb3RoZXIgbW9kZWxzIGNh biBsZXZlcmFnZS4gT3RoZXJ3aXNlLCB3ZSBhcmUgZ29pbmcgdG8gZW5kIHVwIHdpdGggeWV0IG9u ZSBtb3JlIGRpc2NyZXBhbmN5IChhbW9uZyB2YXJpb3VzIHByb3RvY29scyBZQU5HIG1vZGVscyks ICYgY29uZnVzaW5nIGlmIG5vdCBpbmVmZmljaWVudCBtb2RlbGluZy4NCg0KUGVyaGFwcywgd2Ug ZGl0Y2ggYm90aCBvZiB0aGUgYWJvdmUgYXBwcm9hY2hlcywgYW5kIHNldHRsZSBvbiBrZWVwaW5n IGFsbCB0aHJlZSBvZiB0aGVtIGluIHRoZSBzYW1lIGNvbnN0cnVjdC4gSXQgbWlnaHQgc2ltcGxp ZnkgdGhlIG9yZ2FuaXphdGlvbiBhIGJpdC4gT2YgY291cnNlLCB0aGF0IGFsc28gaGFzIDIgb3B0 aW9ucyAtIGhhdmUgYWxsIHRoZSBkYXRhIHR5cGVzIGluIGludGVuZGVkLWNvbmZpZywgYW5kIHRo ZW4gaW4gYXBwbGllZC1jb25maWcgYW5kIHRoZW4gaW4gZGVyaXZlZC1zdGF0ZS4gT3IgaGF2ZSBp bnRlbmRlZC1jb25maWcsIGFwcGxpZWQtY29uZmlnIGFuZCBkZXJpdmVkLXN0YXRlIGZvciBlYWNo IGRhdGEgdHlwZS4gTGF0dGVyIG1pZ2h0IGJlIHNsaWdodGx5IGJldHRlciwgZ2l2ZW4gdGhhdCBu b3QgZXZlcnkgZGF0YSB0eXBlIHdpbGwgaGF2ZSBhbGwgdGhyZWUuDQoNCg0KVGhvdWdodHM/IA0K DQotLSANCkNoZWVycywNClJhaml2IEFzYXRpDQpEaXN0aW5ndWlzaGVkIEVuZ2luZWVyLCBDaXNj bw0KDQoNCiogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLW9w c3RhdGUtcmVxcyA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9k LW9wc3RhdGUtcmVxcy0wND4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vcGVu Y29uZmlnLW5ldG1vZC1vcHN0YXRlDQoNCg== From nobody Thu Mar 31 12:59:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C711412D7BD for ; Thu, 31 Mar 2016 12:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 GatDOQ3UkmoZ for ; Thu, 31 Mar 2016 12:59:11 -0700 (PDT) Received: from BAY004-OMC3S14.hotmail.com (bay004-omc3s14.hotmail.com [65.54.190.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973AB12D7DB for ; Thu, 31 Mar 2016 12:59:11 -0700 (PDT) Received: from BAY176-W39 ([65.54.190.188]) by BAY004-OMC3S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 31 Mar 2016 12:59:11 -0700 X-TMN: [hQDvoF+VdZStyvwb8u9e71iUB7gw2hy/] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_7a2289d1-f519-4fc0-9e3c-0caf13bccd32_" From: Ashesh Mishra To: "netmod@ietf.org" Date: Thu, 31 Mar 2016 12:59:10 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 31 Mar 2016 19:59:11.0390 (UTC) FILETIME=[CB0C93E0:01D18B87] Archived-At: Subject: [netmod] IETF-95 NETMOD Slides 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, 31 Mar 2016 19:59:15 -0000 --_7a2289d1-f519-4fc0-9e3c-0caf13bccd32_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Presenters=2C Please send your slides to netmod-chairs@ietf.org by April 3.=20 Agenda: https://www.ietf.org/proceedings/95/agenda/agenda-95-netmod Thanks=2CAshesh = --_7a2289d1-f519-4fc0-9e3c-0caf13bccd32_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Presenters=2C

Please send your slides to netmod-chairs@ietf.org by April 3. =3B

<= div>
Thanks=2C
Ashesh
= --_7a2289d1-f519-4fc0-9e3c-0caf13bccd32_-- From nobody Thu Mar 31 19:25:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14FD12D106 for ; Thu, 31 Mar 2016 19:25:18 -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 QQqIwtnUoTLG for ; Thu, 31 Mar 2016 19:25:17 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 A79F812D152 for ; Thu, 31 Mar 2016 19:25:16 -0700 (PDT) Received: by mail-lb0-x234.google.com with SMTP id u8so63470336lbk.0 for ; Thu, 31 Mar 2016 19:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=j7FPrsnK/QoGJ01lt0srJfbprObphxXEgC8mWfY09Eg=; b=BLw28x+dHG5roWU8Lq6Iab4eQkvNe/uz9ty5xJw7ExVNBhslfGLHJODv521PzXBok8 o+J4bscTs4Xa00p3tL4iM2QAPuQPtg7zgZ/9Yt4q+H/LVzxSLzMBlv6LnonUsKjVxrcA 18QHMFVLmQSih/D4DSHzWI7pSSfHY0bg4Rauvw7SrFUl6N26l1g1VrmoWoMwrc30DVhq ojum5TRLketJi7S+aeHewy360CZY23fAAIKKmH5q+1ZShJgwHzVwRJv2EXzK8yEo/BFg CQ2FD1Patd7c09e6KiHpJyILPZAsoQRtqSITV7hg490VcOissay7P1ET0oWvF+js0Ya/ 3XSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=j7FPrsnK/QoGJ01lt0srJfbprObphxXEgC8mWfY09Eg=; b=DV1/jU/O+avvZp6oPzvCt3tLhpSsefRhCLd0e/Brz4Sxz4BNpXHSbVA25obCDCvMlw TrwN2iOqelCGDW3BE6Tmg5mgB4G4Ydhj/gOK143ViwyKPp46qsoI/2eiRho9WCuje/tg wQQ+RDIdIe/M6LpEgrXln+xIR4ba80FPDUzwks40Alh9DPoG3iDYTUDMBTqdOihblJJx 01mMbWKvbuO7azzp1A6BDyLI5oV5JYXVRKodNARg3CqMSH9eXPMb8e1yeelmUzWBdOIj xC+3nrEoEWDZc1g5tejp/gvJ3yGx4NRlxaZq+aHcMzXH/V/lbLHe8nGBwMJo5WpKbSJ4 JNkg== X-Gm-Message-State: AD7BkJLoNGqCcyYoFSqRp8EhLnGnRIuHON6uZKiSSqA6Fx9TCiHS19knM9TMJl06phdOfbTe1gTz4TK6IV4Q4A== MIME-Version: 1.0 X-Received: by 10.112.147.101 with SMTP id tj5mr1242948lbb.119.1459477514753; Thu, 31 Mar 2016 19:25:14 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Thu, 31 Mar 2016 19:25:14 -0700 (PDT) Date: Thu, 31 Mar 2016 19:25:14 -0700 Message-ID: From: Andy Bierman To: Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a8bd2d32ca8052f631641 Archived-At: Subject: [netmod] yangcli-pro now free 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, 01 Apr 2016 02:25:18 -0000 --047d7b3a8bd2d32ca8052f631641 Content-Type: text/plain; charset=UTF-8 Hi, The yangcli-pro NETCONF client program is now free to use in binary form. It is supported on MacOSX and various Linux platforms. Info: https://www.yumaworks.com/yangcli-pro/ Files: https://www.yumaworks.com/pub/ Andy --047d7b3a8bd2d32ca8052f631641 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The yangcli-pro NETCONF client prog= ram is now free to use
in binary form.=C2=A0 It is supported on M= acOSX and various Linux platforms.


= Info:


Andy

--047d7b3a8bd2d32ca8052f631641--